12/27/12

A brief introduction to f unction points

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
www.cs.helsinki.f i/u/taina/ohtu/f p.html

1/4

12/27/12

A brief introduction to f unction points

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
www.cs.helsinki.f i/u/taina/ohtu/f p.html

2/4

12/27/12

A brief introduction to f unction points

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
Cobol

128
105

Fortran
Pascal
Ada

105
90
70

php
Java
object-oriented languages
fourth generation languages (4GLs)

67
31
30
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.

www.cs.helsinki.f i/u/taina/ohtu/f p.html

3/4

12/27/12

A brief introduction to f unction points

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
Last modified: Wed Oct 5 09:48:18 EEST 2005

www.cs.helsinki.f i/u/taina/ohtu/f p.html

4/4