Function Point Analysis Overview
Frederick Brooks was among the first to draw attention to information technology (IT) productivity in his book The Mythical Man-Month (Addison-Wesley, 1975). Unfortunately, although Brooks raised awareness of serious problems, sig- nificant solutions have not been achieved.
In the mid-1970s,Allan Albrecht of IBM introduced function point analysis1as a form of sizing software develop- ment. As opposedto other methodssuch as counting lines of source code, function point analysis measured the func- tionality requested and received by the user independent of the technical details involved.1 Using this method, the mea- surement of an application remains consistent whether that applicationis coded in assembly language or Java.
Since its formation in 1986, the International Function Point Users Group (IFPUG) has continued to enhance the method Albrecht pioneered for functionally sizing software. The IFPUG Functional Size Measurement Method is known as function point analysis, and its units of functional size are called function points.1 Function point analysis conforms to the ISO/ IEC 14143-1:2007 standard for functional measurement.
Access to the size of the application is a starting point to answering important business questions. When used in conjunction with other measurements such as hours of effort, cost, and delivery time, function points can provide valuable information to the key decision makers with accurate projec- tions for resourcing, productivity and quality.1
Other techniquesexist to size software.Counting lines of source code is a popular method because the counting can be automated. Although it is easy to count lines of code, the results achieved are notoriously unreliable. First, there is no clear way to compare two applications written in dif- ferent computer languages; for example, how many lines of
1Refer to IFPUG, Function Point Counting Practices Manual (CPM), Release 4.3, Part 1, page iii.
COBOL are equal to a line of C++? Many organizations have tried to answer questions like these by providing con- version tables, but the results have been less than optimal. Second, comparing results is difficult using lines of code; two developers can vary widely in how they code a specific func- tion based on their individual style of coding. A study con- ducted at Sandia National Laboratories (Albuquerque, NM) compared the same small program written by students in a Personal Software Process (PSP) course using the same pro- gramming language and found a variation of not less than
200% and as much as 2200%.2
Balanced scorecards and return on investment (ROI) cal- culations have been used to portray IT performance. Both of these methodologies offer a moderate degree of success; how- ever, without a size measurement,they are unable to provide the fundamental metric of cost per unit of work. Function point analysis providesthe size measurementthat enables specific and accurate metrics.
Studies have found that two certified function point ana- lysts measuringthe same application will achieve the same result within a margin of error of ±10%. This margin of error approaches zero when the applicationis fully documented or there is access to a subject matter expert (SME) who is very familiar with the application.