Professional Documents
Culture Documents
Garmus Functionpointintro
Garmus Functionpointintro
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.
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.
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.
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.
ORDER
PARTS
PLANT INFORMATION CENTER External Inputs
SYSTEM USER
CHANGE
BILL
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.
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.
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
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