What Are Function Points?
The standard economic definition of productivity is, "Goods
or services produced per unit of labor and expense." Until
1979, when A.J. Albrecht of IBM published his Function Point metric,
there was never a software definition of exactly what "goods
or services" were the outputs of a software project.
The previous metric for software was "cost per line of source
code," which unfortunately does not correlate at all to the
economic definition of productivity. All manufacturing managers
understand that if a manufacturing process involves a substantial
percentage of fixed costs, and there is a decline in the number
of units manufactured, then the cost per unit must go up.
Software, as it turns out, involves a substantial percentage of
fixed or inelastic costs that are not associated with coding. When
more powerful programming languages are used, the result is to reduce
the number of "units" that must be produced for a given
program or system. However, the requirements, specifications, user
documents, and many other cost elements tend to behave like fixed
costs, and hence cause metrics such as "cost per line of source
code" to move paradoxically upwards instead of downwards.
Table 1 provides an example showing two versions of a software
project. Case A is written in a primitive Assembler language and
Case B is written in the more powerful FORTRAN language. Observe
the paradox: the FORTRAN version of the application cost $50,000
less than the Assembler language version, for a savings of 40 percent
in terms of real economic cost. Yet the cost per source line metric
favors the Assembler language version by 2 to 1.
In Case A, some 40 percent of the costs were for coding, while
in Case B only 20 percent went to coding. The non-coding costs tend
to behave inelastically and act as fixed costs, hence invalidating
source code metrics as economic indicators.
Table 1. The Paradox of Source Code Metrics
| Activity |
Case A
Assembler Version
(10,000 Lines) |
Case B
Fortran Version
(3,000 Lines) |
Difference |
 |
 |
|
|
| Requirement |
2 Months
|
2 Months |
0 |
| Design |
3 Months |
3 Months |
0 |
| Coding |
10 Months
|
3 Months
|
-7 |
| Integration/Test |
5 Months
|
3 Months
|
-2 |
| User Documentation |
2 Months
|
2 Months |
0 |
| Management/Support |
3 Months |
2 Months
|
-1 |
|
|
|
|
| Total |
25 Months |
15 Months
|
-10 |
|
|
|
|
| Total Costs |
$125,000
|
$75,000 |
($50,000) |
| Cost Per Source Line |
$12.50 |
$25.00 |
$12.50 |
| Lines Per Person Month |
400 |
200 |
-200 |
In the late 1970's A.J. Albrecht of IBM took the position that
the economic output unit of software projects should be valid for
all languages, and should represent topics of concern to the users
of the software. In short, he wished to measure the functionality
of software.
Albrecht considered that the visible external aspects of software
that could be enumerated accurately consisted of five items: the
inputs to the application, the outputs from it, inquiries by users,
the data files that would be updated by the application, and the
interfaces to other applications.
After trial and error, empirical weighting factors were developed
for the five items, as was a complexity adjustment. The number of
inputs was weighted by 4, outputs by 5, inquiries by 4, data file
updates by 10, and interfaces by 7. These weights represent the
approximate difficulty of implementing each of the five factors.
In October of 1979, Albrecht first presented the results of this
new software measurement technique, termed "Function Points"
at a joint SHARE/GUIDE/IBM conference in Monterey, California. This
marked the first time in the history of the computing era that economic
software productivity could actually be measured.
Table 2 provides an example of Albrecht's Function Point technique
used to measure either Case A or Case B. Since the same functionality
is provided, the Function Point count is also identical.
Table 2. Sample Function Point Calculations
| Raw Data |
Weights |
|
Function Points |
|
|
|
|
| 1 Input |
X 4 |
= |
4 |
| 1 Output |
X 5 |
= |
5 |
| 1 Inquiry |
X 4 |
= |
4 |
| 1 Data File |
X 10 |
= |
10 |
| 1 Interface |
X 7 |
= |
7 |
| |
|
|
---- |
| Unadjusted Total |
|
|
30 |
| Compexity Adjustment |
|
|
None |
| Adjusted Function Points |
|
|
30 |
Table 3. The Economic Validity of Function Point
Metrics
| Activity |
Case A
Asssembler Version
(30 F.P.) |
Case B
Fortran Version
(30 F.P.) |
Difference |
|
|
|
|
| Requirements |
2 Months |
2 Months |
0 |
| Design |
3 Months |
3 Months |
0 |
| Coding |
10 Months |
3 Months |
-7 |
| Integration/Test |
5 Months |
3 Months |
-2 |
| User Documentation |
2 Months |
2 Months |
0 |
| Management/Support |
3 Months |
2 Months |
-1 |
|
|
|
|
| Total |
25 Months |
15 Months |
-10 |
|
|
|
|
| Total Costs |
$125,000 |
$75,000 |
($50,000) |
| Cost Per F.P. |
$4,166.67 |
$2,500.00 |
($1,666.67) |
| F.P. Per Person Month |
1.2 |
2 |
+ 0.8 |
The Function Point metrics are far superior to the source line
metrics for expressing normalized productivity data. As real costs
decline, cost per Function Point also declines. As real productivity
goes up, Function Points per person month also goes up.
In 1986, the non-profit International Function Point Users Groups
(IFPUG) was formed to assist in transmitting data and information
about this metric. In 1987, the British government adopted a modified
form of Function Points as the standard software productivity metric.
In 1990, IFPUG published Release 3.0 of the Function Point Counting
Practices Manual, which represented a consensus view of the rules
for Function Point counting. Readers should refer to this manual
for current counting guidelines.
Function Points give software engineering researchers a way of
sizing software through the analysis of the implemented functionality
of a system from the user's point of view. They provide a way to
predict the number of source code statements that must be written
for a program or system. Languages have varying, but characteristic,
levels. The level is the average number of statements required to
implement one Function Point.
This form of sizing is new and in rapid evolution. For some languages
(such as PL/I), the data is very closely grouped. Sizing by extrapolation
from Function Points is quite accurate. For other languages (such
as COBOL), the range of variation exceeds plus or minus 50 percent.
With COBOL, the Function Point sizing method is less accurate.
The level of languages is of considerable interest for the following
reasons:
| • |
The ability to size
a project, or predict the number of source code statements that
will be required, as early as the requirements or design phase; |
| • |
The ability to retrofit
Function Points to existing software without laborious hand
counting of Function Points; |
| • |
The ability to convert
the size of an application in any language (in lines of source
code) to the equivalent size if the application were written
in some other language; and |
| • |
The ability to measure
the productivity of projects that are written in multiple languages.
|
|
