Function Point Analysis

Also found in: Acronyms, Wikipedia.

Function Point Analysis

(FPA) A standard metric for the relative size and complexity of a software system, originally developed by Alan Albrecht of IBM in the late 1970s.

Functon points (FPs) can be used to estimate the relative size and complexity of software in the early stages of development - analysis and design. The size is determined by identifying the components of the system as seen by the end-user: the inputs, outputs, inquiries, interfaces to other systems, and logical internal files. The components are classified as simple, average, or complex. All of these values are then scored and the total is expressed in Unadjusted FPs (UFPs). Complexity factors described by 14 general systems characteristics, such as reusability, performance, and complexity of processing can be used to weight the UFP. Factors are also weighted on a scale of 0 - not present, 1 - minor influence, to 5 - strong influence. The result of these computations is a number that correlates to system size.

Although the FP metric doesn't correspond to any actual physical attribute of a software system (such as lines of code or the number of subroutines) it is useful as a relative measure for comparing projects, measuring productivity, and estimating the amount a development effort and time needed for a project.

See also International Function Point Users Group.
References in periodicals archive ?
Applying function point analysis to effort estimation in configurator development.
Function Point Analysis is simply a technique that can be used to derive a measure of the size of a software system.
But the rules of function point analysis are so well defined and non-arbitrary that skilled analysts almost always arrive at very similar function point counts for a project.
In his letter, Patrick Brennan states that we did not encounter two potentially significant estimation improvement techniques, namely, auditing the estimate and function point analysis.