Measuring with Function Points

Like this article? We recommend 

Because it is neither practical nor of particular value to identify every known function point-related measure, we will focus on a selection of key metrics that we have seen used effectively within numerous client organizations. To put this list of primary metrics in the proper context, we have divided the function point measures into four categories: productivity, quality, financial, and maintenance. In each case, we identify the meaning of the measure, how it can be used, and how it is calculated.

The function point size serves as a normalizing metric. For example, two systems are monitored for defects, and system A is found to have twice as many defects as system B. An immediate assessment is that system B has higher quality than system A. Without a sizing metric, however, there can be no practical point of comparison. If we added function points to the scenario and realized that system B is one-fourth the size of system A, we would view system A as possessing higher quality than system B. System A would have fewer defects per functionality maintained.

Function Point Measures

The four categories of productivity, quality, financial and maintenance will be addressed in the following paragraphs.

Productivity

Hours per function point is an industry-accepted unit-of-work measure. It measures the number of hours required to develop one function point. It is most often used as a measure of productivity, which is usually evaluated at a project level. It should never be used as a measure of individual performance. This metric is calculated as follows:

Total number of project hours divided by

Number of function points delivered

The total number of hours and the number of function points represent values for a specific project. The total number of hours recorded for a project most often includes all effort associated with the project. This value can vary significantly among departments, organizations, and industries. When performing comparative analysis, the metrics analyst must ensure that the total number of hours recorded for a project is consistent when making comparisons either internal or external to the organization.

This measure is often used to represent productivity for various different categories—for example, new development, enhancements, or different technologies. An organization may show varying rates of productivity for new development versus enhancements or for client/server productivity versus mainframe productivity.

Frequently this measure is displayed as function points delivered per person-month. However, using person-months as a measure is problematic because no industry standards define a person-month. Using an hour as the metric permits greater consistency.

Rate of delivery is an industry-accepted measure that measures calendar time to deliver the required software solution to the end user. It is often used as a service-level measure to demonstrate how quickly an organization introduces functionality into use. It is frequently described as a time-to-market measure. The measure is calculated as follows:

Number of function points divided by

Elapsed calendar time

Elapsed time is usually defined as calendar time in months. It represents the time from the introduction of requirements through software installation. When using this measure for comparative analysis, one should ensure that elapsed time is consistently sized within the organization. In some companies, elapsed time begins with project start activities prior to requirements and ends when the system is fit for use (but not necessarily installed). Elapsed time should also exclude dead time, any period during which project development has been temporarily stopped.

Quality

Functional requirement size measures the total number of functions requested by the end user, expressed in terms of function points. As a meaningful metric, it may have limited value to the end user, but the developer should be able to use this value as an important input parameter to any one of several estimating models. The calculation derives the functionality (function points) required by a requesting user organization.

The use of this metric can ultimately benefit both the developer and the requesting end user. Imagine a scenario in which the developer seeks to ensure an understanding of the functional requirements. The developer engages the end user in an interactive session by creating a context diagram or another vehicle to communicate a common understanding of the requested deliverables. Using a diagramming technique and the function point components of input, output, inquiries, data stores, and interfaces, the analyst and the end user discuss the functionality in terms that they both understand. At the conclusion of the session, the analyst has the basic information required to perform a high-level function point sizing.

Rate of change measures the amount of functional specification change that occurs during the development process. It can be used to track "scope creep" (added functionality) within a project for purposes of more effectively managing project costs and schedules. It may also be used to determine the effectiveness of the requirements process. We calculate this measure by counting function points during each primary milestone deliverable, commencing with the functional requirements.

Change can be tracked through the various phases of the development life cycle. As the scope of the project expands, the project manager can use this information to substantiate increases in budgeted project dollars or schedule extensions.

Test case coverage measures the number of test cases that are necessary to adequately support thorough testing of a development project. This measure does not indicate the effectiveness of the test cases, nor does it guarantee that all conditions have been tested. However, it can be an effective comparative measure to forecast anticipated requirements for testing that may be required on a development system of a particular size. This measure is calculated as follows:

Number of test cases divided by¹

Number of function points

Volume of documentation can be used to measure or estimate the number of pages produced or anticipated in support of the development effort. Pages per function point value can be derived for any of the documents produced during the development life cycle. This measure is calculated as follows:

Number of pages (per document) divided by²

Total number of function points

Like test case coverage, this measure should not be considered a measure of quality.

Financial

Cost per function point identifies the cost for each function point developed. This measure is usually applied at the project or organizational level. At the project level, cost per function point is calculated and compared to a baseline organizational value. An overall cost per function point is calculated for the entire organization and establishes the baseline. Cost per function point may also be used to compare the cost of developing an internal solution to the cost of purchasing a commercial package solution, or to compare internal cost to an external industry (benchmark) cost. The metric is computed as follows:

Total cost divided by³

Total function points

The ability to compare an organization's internal cost per function point to industry averages or best-in-class benchmarks depends on a consistently applied cost basis. Project cost usually consists of total project labor, project-related tools, project-related travel and living expense, and a fully defined burden rate (includes overhead costs).

Repair cost ratio is used to track the costs to repair applications that are operational. It is commonly used as a monitoring metric for newly installed applications. During the first six months of operation, this measure should include all fixes and all costs of repair for the newly installed system. The metric is calculated as follows:

(Total hours to repair * Cost) divided by⁴

Release function points

The measure may be used to monitor required systems fixes. It can be applied prior to installation to monitor project expenses directly related to the repair of defects. The function point component of the equation usually represents the total number of function points for the release; however, it can be modified to represent only those function points associated with each repair. Many outsourcing arrangements use this measure as a basis for tracking maintenance support service levels on a repair-by-repair basis.

Maintenance

Maintainability is the measure of effort (cost) required to maintain an application. The metric is used to monitor maintenance cost on an application-by-application basis. It is most often applied to core business applications or to applications that have demonstrated a high cost of maintenance. It is calculated as follows:

Maintenance cost divided by⁵

Application function points

Some maintenance activities do not directly relate to size (function points). Outsourcing arrangements often refer to this category of costs as zero function point maintenance. For example, the required maintenance repair does not generate any new or changed functionality and cannot be measured in function points; however, a cost is incurred to accomplish the repair. The organization should establish a policy on accounting for this zero function point maintenance. Most often the cost is either accounted for as general maintenance expense or charged on a full-time equivalent (FTE) basis.

Assignment scope is a measure of the number of FTE resources required to support an application. This measure may be used to monitor resource levels required to adequately support an application being maintained in production. As an application increases in functional size during its life span (see the upcoming discussion of growth rate), the resources required to support the application are expected to increase. The measure is sometimes referred to as maintenance assignment scope. Assignment scope is one of several measures that should be used to identify the potential for increased resource requirements. It is calculated as follows:

Total application function points divided by⁶

Number of full-time resources required to support the application

As with most of the measures defined here, this measure should not be used as a single source of information. For example, staffing levels do not equate to quality of support. Each of these measures must be viewed and analyzed in conjunction with other measures.

Portfolio size is a measure of the organization's portfolio of function points. This metric is often used for budgeting purposes or in conjunction with outsourcing arrangements. Outsourcing an organization's application development and maintenance activities requires sizing of the organization's suite of applications. Levels of service can be based on the total number of function points that must be serviced by the third-party vendor. Portfolio size is the total number of function points for all applications in the organization's portfolio.

Table 1 identifies each of the function point measures discussed above and indicates the life cycle phase when they should be used.

Table 1

Use of Function Point Measures in the Systems Development Life Cycle

	Phase of Development
Measure	Requirements	Design	Build	Test	Implementation	Maintenance
PRODUCTIVITY
Hours per function point	X	X	X	X	X
Rate of delivery	X	X	X	X	X
QUALITY
Functional requirement size	X
Rate of change	X	X	X	X	X
Test case coverage				X
Volume of documentation					X
FINANCIAL
Cost per function point					X
Repair cost ratio						X
MAINTENANCE
Maintainability						X
Assignment scope						X
Portfolio size						X