18.2 Function-Point Estimation

One alternative to the LOC measure is function points. A function point is a synthetic measure of program size that can be used to estimate size in a project's early stages (Albrecht 1979). Function points are easier to calculate from a requirements specification than lines of code are, and they provide a basis for computing size in lines of code. Many different methods for counting function points exist. The standard for function-point counting is maintained by the International Function Point Users Group (IFPUG) and can be found on their Web site at www.ifpug.org.

The number of function points in a program is based on the number and complexity of each of the following items:

External Inputs Screens, forms, dialog boxes, or control signals through which an end user or other program adds, deletes, or changes a program's data. They include any input that has a unique format or unique processing logic.
External Outputs Screens, reports, graphs, or control signals that the program generates for use by an end user or other program. They include any output that has a different format or requires a different processing logic than other output types.
External Queries Input/output combinations in which an input results in an immediate, simple output. The term originated in the database world and refers to a direct search for specific data, usually using a single key. In modern GUI and Web applications, the line between queries and outputs is blurry, but, generally, queries retrieve data directly from a database and provide only rudimentary formatting, whereas outputs can process, combine, or summarize complex data and can be highly formatted.
Internal Logical Files Major logical groups of end-user data or control information that are completely controlled by the program. A logical file might consist of a single flat file or a single table in a relational database.
External Interface Files Files controlled by other programs with which the program being counted interacts. This includes each major logical group of data or control information that enters or leaves the program.

Table 18-1 shows how the count of inputs, outputs, and so on gets converted to an Unadjusted Function Point count. You multiply the number of low-complexity inputs by 3, you multiply the number of low-complexity outputs by 4, and so on. The sum of those numbers gives you the Unadjusted Function Point count.

Table 18-1: Multipliers for Computing an Unadjusted Function Point Count
Function Points
Program Characteristic	Low Complexity	Medium Complexity	High Complexity
External Inputs	__ × 3	__ × 4	__ × 6
External Outputs	__ × 4	__ × 5	__ × 7
External Queries	__ × 3	__× 4	__ × 6
Internal Logical Files	__ × 4	__ × 10	__ × 15
External Interface Files	__ × 5	__ × 7	__ × 10
Source: Adapted from Applied Software Measurement, Second Edition (Jones 1997).

After you've computed the Unadjusted Function Point total, you compute an Influence Multiplier based on the influence that 14 factors have on the program. These factors include data communications, online data entry, processing complexity, and ease of installation. The influence multiplier ranges from 0.65 to 1.35. When you multiply the unadjusted total by the Influence Multiplier, you get an Adjusted Function Point count.

If you've read my earlier comments about "subjective control knobs," you can probably guess what I think about the Influence Multiplier and its 14 control knobs. Two studies have found that Unadjusted Function Points are more strongly correlated with ultimate size than Adjusted Function Points are (Kemerer 1987, Gaffney and Werling 1991). Some experts also recommend eliminating the "low complexity" and "high complexity" judgments, and classifying all counted items as "medium," which eliminates another source of subjectivity (Jones 1997). The ISO/IEC 20926:2003 standard is based on Unadjusted Function Points.

Table 18-2 provides an example of how you would come up with the final Adjusted Function Point total. The specific number of inputs, outputs, queries, logical internal files, and external interface files shown in the table were chosen solely for purposes of illustration.

Table 18-2: Example of Computing the Number of Function Points
	Function Points
Program Characteristic	Low Complexity	Medium Complexity	High Complexity
External Inputs	6 × 3 = 18	2 × 4 = 8	3 × 6 = 18
External Outputs	7 × 4 = 28	7 × 5 = 35	0 × 7 = 0
External Queries	0 × 3 = 0	2 × 4 = 8	4 × 6 = 24
Internal Logical Files	0 × 7 = 0	2 × 10 = 20	3 × 15 = 45
External Interface Files	2 × 5 = 10	0 × 7 = 0	7 × 10 = 70
Unadjusted Function Point total			284
Influence multiplier			1.0
Adjusted Function Point total			284

The example illustrated here works out to a size of 284 function points. You can convert that directly to an effort estimate (described in Chapter 19), or you can convert it first to a lines of code estimate, and then convert that to an effort estimate.

The terminology in the function-point approach is fairly database-oriented, but IFPUG has steadily updated the rules for counting function points, and the approach works well for all kinds of software. Studies have found that certified function-point counters will usually produce counts that are within about 10% of each other, so function-point counting presents a real possibility of narrowing the scope-related variability in the Cone of Uncertainty early in a project (Stutzke 2005).

Tip #81

Count function points to obtain an accurate early-in-the-project size estimate.

Converting from Function Points to Lines of Code

If you want to convert to lines of code, Table 18-3 lists the conversion factors between function points and lines of code for several popular languages.

Table 18-3: Programming Language Statements per Function Point
	Programming Statements per Function Point
Language	Minimum (Minus 1 Standard Deviation)	Mode (Most Common Value)	Maximum (Plus 1 Standard Deviation)
Ada 83	45	80	125
Ada 95	30	50	70
C	60	128	170
C#	40	55	80
C++	40	55	140
Cobol	65	107	150
Fortran 90	45	80	125
Fortran 95	30	71	100
Java	40	55	80
Macro Assembly	130	213	300
Perl	10	20	30
Second generation default (Fortran 77, Cobol, Pascal, etc.)	65	107	160
Smalltalk	10	20	40
SQL	7	13	15
Third generation default (Fortran 90, Ada 83, etc.)	45	80	125
Microsoft Visual Basic	15	32	41
Source: Adapted from Estimating Software Costs (Jones 1998), Software Cost Estimation with Cocomo II (Boehm 2000), and Estimating Software Intensive Systems (Stutzke 2005).

If your 284-function-point program were to be implemented in Java, you would take the range of 40 to 80 LOC per function point from the table and multiply that by 284 function points to arrive at a size estimate of 11,360 to 22,720 LOC, with an expected value of 55 times 284, or 15,675 LOC. To avoid conveying a false sense of accuracy, you might simplify these numbers to 11,000 to 23,000 LOC with an expected case of 16,000 LOC.

The conversion factors presented in the table use wide ranges, typically a factor of 2 to 3 between the high and low ends of the ranges. As with many other quantities you estimate, if you can collect historical data about how function points translate into lines of code in your organization, you will be able to estimate more accurately and probably with narrower ranges than if you use industry-average data.

This section's description of function-point counting just skims the surface of a sophisticated technique. While expert function-point counters can produce results that are within 10% of each other, counts of inexperienced function-point counters will vary by 20% to 25% (Kemerer and Porter 1992, Stutzke 2005). For more details on the technique, see the "Additional Resources" section at the end of this chapter.