You are on page 1of 37

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
users 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
applications boundary
An external output (EO) is an elementary process that sends data
or control information outside the applications 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
Distributed Data
Processing
Performance
Heavily Used
Configuration
Transaction Rate
Online Data Entry
End-User Efficiency
Online Update
Complex Processing
Reusability
Installation Ease
Operational Ease
Multiple Sites
Facilitate Change

Degrees of Influence
0 Not present, or no influence
1 Incidental influence
2 Moderate influence
3 Average influence
4 Significant influence
5 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 programs
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