# A brief introduction to function points

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 Point measurement

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

• FP = Function Points
• count-total = a sum of the following measurement parameters:
1. Number of user input * input weight value
2. Number of user outputs * output weight value
3. Number of user inquiries * inquiry weight value
4. Number of files * file weight value
5. Number of external interfaces * external interface weight value
The input weight values depend on the estimated difficulty of the measurement parameters. They go as follows (simply, average, complex):
1. user inputs: 3, 4, 6
2. user outputs: 4, 5, 7
3. user inquiries: 3, 4, 6
4. files: 7, 10, 15
5. external interfaces: 5, 7, 10
• sum(Fi) = sum of "complexity adjustment values" based on responses to 14 questions [Art85]. Each question is rated on a scale 0 - 5 as follows:
• 0: No influence
1: Incidental
2: Moderate
3: Average
4: Significant
5. Essential
The questions are as follows:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
• The multipliers 0.65 and 0.01 are based on original empirical evidence.

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:

1. Number of user inputs. Each screen or window that provides some input to the system is calculated. If the window has several tabs, each tab is calculated as one input. If a window provides information from several sources that is not sent to the system at the same time, each source is calculated as one input. This is of course very bad design, but it is possible.
2. Number of user outputs. Each output that provides system-based information to the user is calculated here. This includes reports, message windows, error messages, etc. Individual fields are not calculated separately.
3. Number of user inquiries. A user inquiry is a direct input from the user that gets a direct response from the system. Each distinct inquiry is counted.
4. Number of files. Each logical group of permanent data is considered a file. This includes relational database tables, configuration files, help files, saved and restored project information files etc.
5. Number of external interfaces. This includes all interfaces to other systems. The interfaces must be machine-machine interfaces. If a human factor is present, the interface is counted as user input or inquiry.

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.

## FP relationships

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.

## References

[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.

Juha Taina