Software Estimations

Function Points and Use Cases

BSIT-6
University Institute of Information Technology (UIIT),
PMAS-Arid Agriculture University (AAUR), Rawalpindi
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
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
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
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
 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)
Function Point Analysis
Because function point analysis is independent of language
used, development platform, etc. it can be used to identify
the productivity benefits of . . .
▪ One programming language over another
▪ One development platform over another
▪ One development methodology over another
▪ One programming department over another
▪ Before-and-after gains in investing in programmer training
▪ And so forth . . .
 Function Point Analysis
But there are problems and criticisms:
▪ Function point counts are affected by project size
▪ Difficult to apply to massively distributed systems or to systems with very
complex internal processing
▪ Difficult to define logical files from physical files
▪ The validity of the weights that Albrecht established – and the
consistency of their application – has been challenged
▪ Different companies will calculate function points slightly different,
making intercompany comparisons questionable
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
Use Case Points
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
Do Use Cases Improve Estimates?

Use Cases provide a mechanism for articulating the

product scope from the user’s point of view
Size and Complexity can be attributed to each Use
Case, but are really based upon the artefacts
derived from Use Cases
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
Correlation between UCP and FP
yy==20,85x
20,85x
Correlation
Correlation between
between UCP
UCP and
and FP
FP 22
RR ==0,821
0,821
nn==48
48
4000
4000

3500
3500

3000
3000

2500
2500
FP
FP

2000
2000

1500
1500

1000
1000

500
500

00
00 20
20 40
40 60
60 80
80 100
100 120
120 140
140 160
160
UCP
UCP
DELPHI
▪ Based on the Hegelian Principle (George Wilhelm Friedrich
Hegel, 1770-1831 )
▪ Three-step process of
▪ Thesis
▪ All present their opinion or views on a given subject
▪ Antithesis
▪ Establishing views and opposing views
▪ Synthesis
▪ opposites are brought together to form the new thesis
DELPHI
▪ A group meeting is held to discuss the product and estimation issues
▪ Experts produce an independent estimate
▪ Estimates are returned indicating the median estimate and the
expert’s personal estimate
▪ Another group meeting is held to discuss results
▪ Experts prepare a revised independent estimate
▪ Steps 3-6 are repeated until the panel of experts reaches a
consensus
Wideband Delphi
▪ Rand corporation used original Delphi approach to predict future technologies
▪ 1970s, Barry Boehm and his RAND colleagues modified DELPHI method into
Wideband DELPHI, which included more estimation team interaction
▪ Group consensus approach
▪ This is a disciplined method of using the experience of several people to reach an
estimate that incorporates all of their knowledge.

▪ Present experts with a problem and response form

▪ Conduct group discussion, collect anonymous opinions, then feedback
▪ Conduct another discussion & iterate until consensus
Wideband Delphi
▪ 1) Get a few experts (typically 3 to 5)
▪ Include experience in all of the “risk” areas -- application domain, programming language, algorithms, target
hardware, operating system, etc.

▪ 2) Meet with them to discuss issues and describe the software to them
▪ Specifications, other source documents, WBS, etc.
▪ Let them add their own information, questions, etc.
▪ All take notes

▪ 3) Each expert develops an estimate

▪ min, expected, max -- or just expected
▪ independent and anonymous

▪ 4) Record estimates anonymously

▪ Usually done by a facilitator
WBD
▪ 5) Meet and have each expert discuss his/her estimate
▪ Assumptions
▪ Rationale

▪ 6) Seek consensus on assumptions, etc.

▪ May result in action items to gather factual data

▪ 7) Each expert updates his or her estimate based on the new information
▪ 8) Record the new estimates
WBD
▪ 9) Discuss again
▪ Typically, new questions will come up
▪ But this round is typically much shorter

▪ 10) Repeat from step 7 until you reach a consensus

▪ 11) If no consensus, break until you can gather additional data, then repeat from
step 7