Function Points (FP) were first proposed in late 70's by Albrecht [Alb79]. They are based on the idea that a good estimate is needed to calculate functionality and normalize the results between different types of products. Programming language based measurements, such as lines of code (LOC) are not suitable since by definition they depend on the chosen programming language. Since "functionality" cannot be measured directly, it must be derived indirectly using other direct measures [Pre97].
A Function Point result is just a number. It does not directly correspond to any program source code size. Instead, it gives a basis to compare program requirements, design, or final program size independent of chosen design and implementation details. It can be used to estimate the size of the final program by using a specific conversion table between Function Points and program code size (LOC/FP). It can also be used to estimate project effort (FP/person-month).
Currently a special interest group IFPUG (International Function Point User Group) maintains and develops the FP model. In their latest book, the model description needs over 200 pages. The IFPUG home page is in http://www.ifpug.com
A Function Point calculation is based on empirical evidence from a set of finished projects. Although the projects were from 70's, the results of the study are still surprisingly accurate. Although IFPUG has somewhat renewed the FP model, the original ideas still hold quite well. This introduction is based on the original model alone.
Function Points are always an estimation. Thus, different people may get the somewhat different FP values of the same problem domain or software. This is not a serious issue. Even an estimation is better than nothing at all, and FP allows developers to have early estimations before a single line of code has been written.
Function Points are calculated from the following formula:
FP = count-total x [0.65 + 0.01 x sum(Fi)],
where
Some of the terms in FP calculation need to be translated to modern software engineering terminology. After all, the original model is almost 30 years old and the complexity adjustment values are over 20 years old as well.
Here are the FP measurement parameters and their interpretations:
The FP method is suitable for data-driven software. In such software, most code is for processing some input to some output. Unfortunately, this is not always the case. We have a growing number of software projects where we also have to implement algorithms.
In order to include algorithm complexity in the FP model, an extension called Feature Points was proposed 1991 [Jon91]. In feature points, a new measurement parameter algorithms were introduced. However, we will not cover the Feature Points any more than this.
It is possible to add algorithms to the original FP model without modifications when we consider algorithms as separate components in the system. For the sake of the model, we can assume that each algorithm implementation is in an external component with an input interface and an output interface. These interfaces can be considered external to the system in the evaluation. Thus, for each algorithm we add two eternal interfaces to the calculation.
The addition of component interfaces counts only in algorithm components. Other component interfaces are included in normal measurement parameters.
The relationship between lines of code and function points depends upon the programming language that is used to implement the software and the quality of the design [Pre97]. The following table presents rough estimates for some old-fashioned programming languages. The paper describing these results was published in 1983 [AlG83]. I will include some very preliminary estimates for Java and php to the table. These estimates come from Summer 2005 Software Engineering Projects where both FP and lines of code were calculated.
Programming language | LOC/FP (average estimate) |
assembly language | 320 |
C | 128 |
Cobol | 105 |
Fortran | 105 |
Pascal | 90 |
Ada | 70 |
php | 67 |
Java | 31 |
object-oriented languages | 30 |
fourth generation languages (4GLs) | 20 |
code generators | 15 |
spreadsheets (excel programming) | 6 |
graphical languages (icons) (draw-a-program languages) | 4 |
The Java and php estimates give only a basic idea of the magnitude. The collected data (number of courses) is too small for any real estimate.
[Alb79] Albrecht, A., Measuring Application Development Productivity. Proceedings of IBM Application Development Symposium, October 1979, 83-92.
[AlG83] Albrecht A., Gaffney J., Software Function, source Lines of Code and Development Effort Prediction: A Software Science Validation. IEEE Transactions on Software Engineering 9(11), November 1983, 639-648.
[Art85] Arthur L., Measuring Programmer Productivity and Software Quality. Wiley-Interscience, 1985.
[Jon91] Jones C., Applied Software Measurement. McGraw-Hill, 1991.
[Pre97] Pressman R., Software Engineering, a Practitioner's Approach, fourth edition. McGraw-Hill, 1997.