Function Points

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
 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

IFPUG = International Function Point Users Group

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
Function Point Analysis
How is Function Point Analysis done?
Working from the project design specifications, the following
system functions are measured (counted):
▪ Inputs
▪ Outputs
▪ Files
▪ Inquires
▪ Interfaces
Function Point Analysis
These function-point counts are then weighed (multiplied) by their
degree of complexity:
Simple Average Complex
Inputs 2 4 6
Outputs 3 5 7
Files 5 10 15
Inquires 2 4 6
Interfaces 4 7 10
Function Point Analysis
A simple example:

inputs

3 simple X 2 = 6

4 average X 4 = 16

1 complex X 6 = 6

outputs

6 average X 5 = 30

2 complex X 7 = 14

files

5 complex X 15 = 75

inquiries

8 average X 4 = 32

interfaces

3 average X 7 = 21

4 complex X 10 = 40
Function Point Analysis
In addition to these individually weighted function points, there are factors that affect the project
and/or system as a whole. There are a number (~35) of these factors that affect the size of the
project effort, and each is ranked from “0”- no influence to “5”- essential.
The following are some examples of these factors:
▪ Is high performance critical?
▪ Is the internal processing complex?
▪ Is the system to be used in multiple sites and/or by multiple organizations?
▪ Is the code designed to be reusable?
▪ Is the processing to be distributed?
▪ and so forth . . .
Function Point Analysis
Continuing our example . . .
Complex internal processing = 3
Code to be reusable= 2
High performance = 4
Multiple sites = 3
Distributed processing = 5
Project adjustment factor = 17

Adjustment calculation:
Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)]
= 240 X [0.65 + ( 17 X 0.01)]
= 240 X [0.82]
= 197 Adjusted function points
Function Point Analysis
But how long will the project take and how much will it cost?
▪ As previously measured, programmers in our organization
average 18 function points per month. Thus . . .
197 FP divided by 18 = 11 man-months
▪ If the average programmer is paid $5,200 per month (including
benefits), then the [labor] cost of the project will be . . .
11 man-months X $5,200 = $57,200
Use Case Points
▪ 1993 Gustav Karner for estimating a project size
▪ Use case and function points have similarity
▪ Use case technique for estimation is similar as function point
▪ Count key aspects of your requirements to form an unadjusted point
count
▪ Use several sets of questions about your team and their environment to
create a fudge factor.
▪ Multiply your original count by the fudge factor to come up with an
adjusted point count
▪ UCP = UUCP * TCF * ECF
Steps to generate estimates
▪ Identify, classify and weight actors
▪ Identify, classify and weight use cases
▪ Calculate Unadjusted Use Case Points
▪ Identify and Weight Technical Complexity Factors
▪ Identify and Weight Environmental Complexity Factors
▪ Calculate Adjusted Use Case Points
▪ Converting Points into Time
Identify, classify and weight actors
Actor Type Description Weight

Simple The Actor represents another 1

system with a defined API.

Average The Actor interacting through a 2

protocol, like TCP/IP.

Complex The Actor is a person interacting 3

via an interface.

The UAW is calculated by counting the number of actors in each category,

multiplying each total by its specified weighting factor, and then adding the
products.
Identify, classify and weight use cases
Use Case Description Weight
Type
Simple • Its success scenario has 3 steps or 5
less (transactions) OR
• Its implementation involves less
than 5 classes.
Average • Between 4 to 7 steps OR 10
• Its implementation involves between
5 to 10 classes.
Complex • Over seven steps OR 15
• Its implementation involves more
than 10 classes.
The UUCW is computed by counting the number of use cases in each category,
multiplying each category of use case with its weight and adding the products.
a transaction is defined as an atomic set of activities that is performed entirely or not at all.
Unadjusted Use Case Points (UUCP)
▪ UUC Points are computed based on two computations:
▪ The Unadjusted Use Case Weight (UUCW)
▪ based on the total number of activities (or steps) contained in all the
use case Scenarios.
▪ Alternatively may be based on number or classes
▪ The Unadjusted Actor Weight (UAW)
▪ based on the combined complexity of all the use cases Actors.
▪ UUCP = UUCW + UAW
Technical Complexity Factors
Factor Description Weight
T1 Distributed System 2
T2 Performance 2
T3 End-user efficiency 1
T4 Complex internal processing 1
T5 Reusability 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Security features 1
T12 Access for third parties 1
T13 Special user training required 1
Technical Complexity Factors
▪ The technical factors are evaluated by the development team
and assigned a value from 0 to 5 according to their perceived
complexity
▪ A perceived complexity of
▪ 0 means factor is irrelevant
▪ 3 is average
▪ 5 means it has strong influence.
▪ Each factor’s weight is multiplied by its perceived complexity to
produce its calculated factor. The calculated factors are
summed to produce the Total TFactor.
▪ TCF = 0.6 + (0.01 * TFactor)
Environment Factors
Factor Description Weight

F1 Familiar with UML 1.5

F2 Application experience 0.5
F3 OO experience 1
F4 Lead analyst capability 0.5
F5 Motivation 1
F6 Stable requirements 2
F7 Part-time workers -1
F8 Difficult programming language 2
Environment Factors
▪ Influence
▪ 0 means no influence
▪ 3 means average influence
▪ 5 means strong influence
▪ EFactor
▪ Each factor’s weight is multiplied by its perceived complexity to
produce its calculated factor. The calculated factors are summed to
produce the Total EFactor.
▪ ECF = 1.4 + (-0.03 * EFactor)
Adjusted UCP and Effort
▪ UCP = UUCP * TCF * ECF
▪ UCP is the size
▪ Time? Effort?
▪ Productivity Factor (PF)
▪ a ratio of the number of person hours per use case point based on past
projects.
▪ If no historical data has been collected, a figure between 15 and 30 is
suggested by industry experts.
▪ Sun’s Experience
▪ A typical value is 20.
▪ Use PF to calculate person hours required