Function Points
Addams England
2/23/2004
CIS 6516
Dr. Roggio
Overview













Introduction
Function Point History
Function Point Variations
Problems with Lines of Code
What are Function Points?
Objectives of Function Points
How do Function Points Overcome LOC Problems?
Uses of Function Points
When Should You Count Function Points?
Who Should Count Function Points?
Function Point Counting
Function Point Counting Example
References
Introduction
 Increasingly important facet of software development is
the ability to estimate the associated cost of development
early in the development process
 Estimating software size is a difficult problem that requires
specific knowledge of the system functions in terms of
– Scope
– Complexity
– Interactions
 Most frequently cited sources of software size metrics are
– Lines of code
– Function point analysis
Function Point History
 Developed by Allan Albrecht in the late 1970s while




working at IBM
The function point technique was refined and a
counting manual was produced by IBM's GUIDE
organization in the early 1980s
The International Function Point Users Group
(IFPUG) was founded in the late 1980s and produced
its own Counting Practices Manual
In 1994, IFPUG produced Release 4.0 of its Counting
Practices Manual
The Function Point Counting Practices Manual 4.1
was released in 1999
Function Point Variations
 Mk II Function Points
– Discovered weaknesses in Albrecht's approach
 Feature Points
– Function points were not working for all classes
of applications
 3D Function Points
– Designed to solve two problems with Albrecht
approach
Problems with Lines of Code
 Lack of a universally accepted definition for
exactly what a line of code is
 Language dependence (high-level versus low-level
programming languages)
 It is difficult to estimate the number of lines of
code that will be needed to develop a system from
information that is available in analysis and design
phases
 Lines of code places all emphasis on coding,
which is only part of the implementation phase of
a software development project
Why IFPUG Thinks You Should
Not Use LOC?
 Lines of code tend to reward profligate design and
penalize concise design
 There is no industry standards (ISO or otherwise)
for lines of code
 Lines of code cannot be used for normalizing
across platform, language or by organization
 Some 4GL do not even use lines of code
 Lines of code can be positively misleading – refer
to Capers Jones Productivity Paradox.
What Are Function Points?
 Function Points measure software size by
quantifying the functionality provided to the user
based solely on logical design and functional
specifications
 Function point analysis is a method of quantifying
the size and complexity of a software system in
terms of the functions that the system delivers to
the user
 It is independent of the computer language,
development methodology, technology or
capability of the project team used to develop the
application
What Are Function Points? …
 Function point analysis is designed to
measure business applications (not
scientific applications)
 Scientific applications generally deal with
complex algorithms that the function point
method is not designed to handle
How Do Function Points
Overcome LOC Problems?
 Function points are independent of the language,
tools, or methodologies used for implementation
(ex. Do not take into consideration programming
languages, DBMS, or processing hardware)
 Function points can be estimated early in analysis
and design
 Since function points are based on the system
user’s external view of the system, non-technical
users of the software system have a better
understanding of what function points are
measuring
Uses of Function Points
 Measure productivity (ex. Number of function points




achieved per work hour expended)
Estimate development and support (cost benefit analysis,
staffing estimation)
Monitor outsourcing agreements (Ensure that the
outsourcing entity delivers the level of support and
productivity gains that they promise)
Drive IS related business decisions (Allow decisions
regarding the retaining, retiring and redesign of
applications to be made)
Normalize other measures (Other measures, such as
defects, frequently require the size in function points)
Why IFPUG Says We Should
Use Function Points?
 You cannot manage internally what you do not




measure
Approximately 40% of all projects fail due to lack of
management control (Coopers & Lybrand – Sept.
1995)
Measurement gives you a tool to communicate to your
customers the size of their request, and extrapolate
productivity, quality and estimating accuracy
Many competitors may already have these insights
You measure to understand and improve your
processes
Objectives of Function Point
Counting
 Measure functionality that the user requests
and receives
 Measure software development and
maintenance independently of technology
used for implementation
 Simple enough to minimize the overhead of
the measurement process
 A consistent measure among various
projects and organizations
When Should You Count
Function Points?
 Early and often
 The sooner you can quantify what a project is
delivering, the sooner it is under control
 Under IFPUG 4.1, there are rules and guidelines
that make it possible to count function points once
the requirements have been finalized
 During requirements gathering the estimate of size
in function points can be refined continuously
 Function points should be recounted throughout
the development process and counts can be
compared to measure scope creep and breakage
Who Should Count Function
Points?
 Recommended: One day class and on-the-job
training by an experienced counter
 Technical people have long been the main function
point counters
 Senior level users can also be trained to count
function points
 For a large organization, a small group involved
with function point counting and other estimating
activity is ideal
– Count frequently enough to stay current with the rules
– Independent of the projects/ less biased feedback
– Consistent counting and help from other group members
Function Point Counting Steps
 Determine the type of function point count
 Identify the counting scope and application
boundary
 Determine the Unadjusted Function Point Count
 Count Data Functions
 Count Transactional Functions
 Determine the Value Adjustment Factor
 Calculate the Adjusted Function Point Count
Function Point Counting Diagram
Early Counting Steps
 Determine the type of function point count
– Development project
– Enhancement project
– Application
 Identify the counting scope and application
boundary
Determine the Unadjusted
Function Point Count
 The unadjusted function point count (UFP) reflects
the specific countable functionality provided to the
user by the project or application.
 The UFP calculation is broken into two categories
with five sub-categories:
– Data Functions
• Internal Logical Files
• External Interface Files
– Transactional Functions
• External Inputs
• External Outputs
• External Inquiries
Count Data Functions
 Data functions represent the functionality provided to the




user to meet internal and external data requirements
Data functions are either internal logical files or external
interface files.
An internal logical file (ILF) is a user identifiable group of
logically related data or control information maintained
within the boundary of the application
An external interface file (EIF) is a user identifiable group
of logically related data or control information referenced
by the application, but maintained within the boundary of
another application
Assign each identified ILF and EIF a functional
complexity based on the number of data element types
(DETs) and record element types (RETs) associated with
the ILF or EIF
Count Data Functions…
Count Data Functions…
Count Transactional Functions
 Transactional functions represent the functionality provided to the





user to process data
Transactional functions are either external inputs, external
outputs, or external inquiries
An external input (EI) is an elementary process that processes
data or control information that comes from outside the
application’s boundary
An external output (EO) is an elementary process that sends data
or control information outside the application’s boundary
An external inquiry (EQ) is an elementary process that sends data
or control information outside the application boundary
Assign each identified EI, EO and EQ a functional complexity
based on the number of file types referenced (FTRs) and data
element types (DETs)
Determine the Value Adjustment
Factor
 The value adjustment factor (VAF) indicates the
general functionality provided to the user of the
application
 The VAF is comprised of 14 general system
characteristics (GSCs) that assess the general
functionality of the application
 Each characteristic has associated descriptions that
help determine the degree of influence of the
characteristic
 The degrees of influence range on a scale of zero
to five, from no influence to strong influence
Value Adjustment Factor 14
Characteristics
 Data Communications
 Online Update
 Distributed Data
 Complex Processing
Processing
 Performance
 Heavily Used
Configuration
 Transaction Rate
 Online Data Entry
 End-User Efficiency
 Reusability
 Installation Ease
 Operational Ease
 Multiple Sites
 Facilitate Change
Degrees of Influence
0
1
2
3
4
5
Not present, or no influence
Incidental influence
Moderate influence
Average influence
Significant influence
Strong influence throughout
Procedures to Determine the
VAF
 Evaluate each of the 14 general system characteristics on a




scale from zero to five to determine the degree of influence
(DI)
Add the degrees of influence for all 14 general system
characteristics to produce the total degree of influence
(TDI)
Insert the TDI into the following equation to produce the
value adjustment factor.
VAF = (TDI * 0.01) + 0.65
For example, the following value adjustment factor is
calculated if there are three degrees of influence for each
of the 14 GSC descriptions (3*14)
VAF = (42 * 0.01) + 0.65
VAF = 1.07
Calculate the Adjusted Function
Point Count
 The adjusted function point count is
calculated using a specific formula for a
development project, enhancement project,
or application (system baseline) function
point count
Development Project Function
Point Calculation
 The development project function point
calculation consists of three components of
functionality:
– Application functionality included in the user
requirements for the project
– Conversion functionality included in the user
requirements for the project
– Application value adjustment factor
Development Project Function
Point Calculation…
 Development project function point formula
– DFP = (UFP + CFP) * VAF
– DFP is the development project function point
count
– UFP is the unadjusted function point count for the
functions that will be available after installation
– CFP is the unadjusted function points added by the
conversion unadjusted function point count
– VAF is the value adjustment factor
Development Project Function
Point Count Example
Conclusions
 Function point analysis is a method of
quantifying the size and complexity of a
software system in terms of the functions
that the system delivers to the user
 Function point analysis is a complex process that
provides many benefits if it can be implemented
correctly
 Function point analysis has been around since the
late 1970s and is still used by many organizations
today
References
 http://www.ifpug.org
 Function Point Counting Practices Manual Release 4.1, The International








Function Point Users Group, 1999.
http://www.carfield.com.hk/document/software_engine/fpa.pdf
Matson, Jack E., Barrett, Bruce E., Software Development Cost Estimation
Using Function Points, IEEE Transactions on Software Engineering,
Volume 20, No. 4, April 1994.
Furey, Sean, Why We Should Use Function Points, IEEE Magazine,
March/April 1997, pp.28-31.
Orr, George, Reeves, Thomas E., Function point counting: one program’s
experience, The Journal of Systems and Software, Volume 53, 2000,
pp.239-244.
Jeffery, D.R., Low, G.C., A Comparison of Function Point Counting
Techniques, IEEE Transactions on Software Engineering, Volume 19, No.
5, May 1993.
Probasco, Leslee, Dear Dr. Use Case: What About Function Points and
Use Cases?, The Rational Edge e-zine, 2002.
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm
http://www.qpmg.com/fp-intro.htm
http://www.ifpug.com/fpafund.htm