You are on page 1of 4

An Introduction to Function Point Counting

David Garmus
It’s often stated that you can’t manage what you can’t measure. The function point metric
has been used successfully to measure software size and, as a result, to determine
delivery rates and quality metrics. It is a synthetic method, much the same as BTUs or
temperature, which provides a methodology to calculate the relative size of individual
applications or subsystems.

A unit-of-work measure must be able to accurately quantify the functionality (value)


being delivered to the business user. When a user specifies a desired functionality, the
unit of work must measure that functionality in a direct way; e.g., the user asks for one
widget, and that is exactly what gets measured.

The function point method has proven to be an effective way to establish a meaningful
unit-of-work measure and can be used to establish baseline costs and performance level
monitors. Function point analysis centers around its ability to measure the size of any
software deliverable in logical, user-oriented terms. Rather than counting lines of code,
function point analysis measures the functionality being delivered to the end user.

This article will address the origination of function points as a metric and describe the
counting process.

Origination of Function Points

Allan Albrecht of IBM published the function point metric in 1979. He determined that
software could be sized by evaluating the external transactions processed by an
application or subsystem and the databases that were used.

IBM further enhanced the definition of function points in 1984 to provide individual
complexities and a set of system characteristics. In 1986, the International Function Point
Users Group (IFPUG) was formed to take over the standardization and promulgation of
the metric. Today, IFPUG has more than 1400 member organizations.

The counting process included in this article is not all-inclusive and must be
complimented with the rules defined in the IFPUG Counting Practices Manual.

Identifying Function Points

The function point method evaluates the software deliverable and measures its size based
on well-defined functional characteristics of a software system. It accounts for:

Data that is entering a system: external inputs (EIs) such as logical transaction inputs or
system feeds.
Data that is leaving the system: external outputs (EOs) or external inquiries (EQs) such as
online displays, reports or feeds to other systems.

Data that is manufactured and stored within the system: internal logical files (ILFs) such
as logical groups of user defined data.

Data that is maintained within a different system but is necessary to satisfy a particular
process requirement: external interfaces (EIFs) such as interfaces to other systems.

These five functional elements (as depicted in Figure 1) are assessed based on their
complexity and used to determine a function point count. Low, average, and high ILFs,
EIFs, EIs, EOs, and EQs are totaled using IFPUG matrices. Values for each category are
calculated using the standard weights shown in Table 1 to determine the total number of
function points.

External Inquiries External Interface


USER USER VENDOR SYSTEM
WORK
LIST OF MOLDS CENTERS

PARTS External Output


PLANT MOLDS
PARTS
Internal Logical Files LISTING
BILL OF MATERIALS USER

ORDER
PARTS
PLANT INFORMATION CENTER External Inputs
SYSTEM USER

CHANGE
BILL

Figure 1 — Identification of functional elements.

The final function point calculation yields a single number that represents the total
amount of functionality being delivered. Once completed, the function point size of an
application or a new development project can be communicated in a variety of ways. As a
stand-alone value, the function point size of a system tells us how large the overall
software deliverable will be. When the function point value is segmented into a more
detailed display, it can communicate to end users the functional value of specific
components of the system. Finally, organizations that have reached a certain level of
software measurement maturity can use function points to predict outcomes and monitor
program progress.
A Simple Example in Counting Function Points

An ILF consisting of employee information can be updated with EIs that add an
employee, delete an employee, or update employee information. An EQ permits display
of current information. A telephone listing that is produced monthly is counted as an EO.
The telephone listing includes information retrieved form a personnel file maintained by
another application---an EIF.

If all the complexities for each function were low except the EO, we would have three
low EIs valued at three points each, one low EQ valued at three points, one low ILF
valued at seven points, and one low EIF valued at five points. If the EO were average, its
value would be five. The total function point count would, as a result, be 29.

Using Function Points

As projects are completed and software deliverables are produced, function point sizing,
together with a collection of other meaningful measures, are used to produce a baseline of
performance. These other measures may include level of effort, cost, duration and quality.
From this baseline, a cost per unit of functionality delivered can be derived. The cost
associated with producing the required deliverable or support service is divided by the
total number of delivered, enhanced or supported function points. The result is a cost per
function point — or a cost per unit of work.

Baselining an organization’s level of performance has become a standard industry


practice, particularly in companies in which IT organizations are required to track and
improve their delivery of products and services relative to improved time to market, cost
reduction, and customer satisfaction. Creation of an IT performance baseline (often
referred to as benchmarking) gives an organization the information it needs to properly
direct its improvement initiatives and monitor progress of outsourcing contract.

Summary

Establishing a cost per unit of work delivered is critical measure in the successful
management and monitoring of the outsourcing arrangement. The function point method
permits the creation of a unit-of-work measure that monitors both the cost performance as
well as the functional deliverable. This measure can satisfy both the IT organization’s
need to monitor the outsourcing contract and the user’s need to ensure the value of the
deliverable. In addition, the use of function points provides the opportunity to make
comparisons to industry performance levels.
Table 1. Function Point Counting

Function Point Counting Weights


Type Low Avg High Total
EI __ x 3 + __ x 4 + __ x 6 = ___
EO __ x 4 + __ x 5 + __ x 7 = ___
EQ __ x 3 + __ x 4 + __ x 6 = ___
ILF __ x 7 + __ x10 + __ x15 = ___
EIF __ x 5 + __ x 7 + __ x10 = ___

ILF and EIF Complexity Matrix


RETs 1-19 DETs 20-50 DETs 51+ DETs
1 Low Low Avg
2-5 Low Avg High
6+ Avg High High

EI Complexity Matrix
FTRs 1-4 DETs 5-15 DETs 16+ DETs
0-1 Low Low Avg
2 Low Avg High
3+ Avg High High

EO and EQ* Complexity Matrix


FTRs 1-5 DETs 6-19 DETs 20+ DETs
0-1 Low Low Avg
2-3 Low Avg High
4+ Avg High High

* an EQ must have at least 1 FTR

Note: DETs are equivalent to non-repeated fields or attributes.


RETs are equivalent to mandatory or optional sub-groups.
FTRs are equivalent to ILFs or EIFs referenced by that transaction

You might also like