SPM Chapter5

Software effort estimation
CHAPTER
Software Project Management Slide# 1

CHAPTER
Objectives
• Avoid the dangers of unrealistic estimates;

• Understand the range of estimating methods that can be used;
• Estimate project using a bottom-up approach;
• Count the function points and object points for a system
• Estimate the effort needed to implement software using a
procedural programming language;
• Understand the COCOMO approach to developing effort models.

5.1 Introduction
Definition of successful project:

“on time and within budget and with the required quality.”
• Novel applications of software;
• Changing technology;
• Lack of homogeneity of project experience

5.1 Introduction
0
Select Project
1 Identify project 2 Identify project
scope and objective infrastructure
3
Analyze project
characteristics
4 Identify the
Review products and activities
5 Estimate effort
for activity
For each activity
Lower level detail 6 Identify
activity risks
10 Lower level planning

7 Allocate resources
9 Execute plan 8 Review/publicize plan
Software Estimation take place in step 3 and 5 in particular

5.1 Introduction
Table 5.1: Some project data – effort in work months
Project Design Coding Testing Total
Wm (%) Wm (%) Wm (%) Wm SLOC
A 3.9 (23) 5.3 (32) 7.4 (44) 16.7 6050

B 2.7 (12) 13.4 (59) 6.5 (26) 22.6 8363
C 3.5 (11) 26.8 (83) 1.9 (6) 32.2 13334
D 0.8 (21) 2.4 (62) 0.7 (18) 3.9 5942
E 1.8 (10) 7.7 (44) 7.8 (45) 17.3 3315
F 19.0 (28) 29.7 (44) 19.0 (28) 67.7 38988
G 2.1 (21) 7.4 (74) 0.5 (5) 10.1 38614
H 1.3 (7) 12.7 (66) 5.3 (27) 19.3 12762
I 8.5 (14) 22.7 (38) 28.2 (47) 59.5 26500
Calculate the productivity (i.e. SLOC per wm) of each of the projects in Table 5.1 and
also for the organization as a whole. If the project leaders for projects A and D has
Exercise 5.1 correctly estimated the source number of line of code (SLOC) and then used the
average productivity of the organization to calculate the effort needed to complete the
project, how far out would their estimates have been from the actual effort?

5.1 Introduction
Subjective nature of estimating

• Underestimate
• Overestimate
Political implications
• Different groups within an organization

have different objectives

5.2 Where are estimates done?
• Strategic planning
• Feasibility study
• System specification
• Evaluation of suppliers’ proposals
• Project planning

5.3 Problem with over- and under-estimates
Parkinson’s Law
Work expands to fill the time available
Brooks’ Law
Putting more people on a late job makes it later.

5.3 Problem with over- and under-estimates
Under-estimate
• Not be completed on time or to cost;

• Implement in a shorter time than project with more
generous estimate;
• The danger is the effect on quality;
• Reliability.

5.4 The basis for software estimating
1. The need for historical data

2. Measure of work
• It is impossible to calculate directly the actual cost
or time required to implement the project.
• Software measurement : source line of code

(SLOC) or thousands of line of code (KLOC).
3. Complexity

5.5 Software effort estimation techniques
Algorithmic models
Expert judgment A model is developed
using historical cost
One or more experts on the
Analogy information which relates
software development
some software metric
techniques
This technique to be used and
is applicable
Parkinson (usually its size) to the
when other on the application
projects the Andomain
projectincost. estimate
same
The effort are
application consulted.
domain
is determined by metric
Price to win is made of that
have been resources
available completed.
and modelratherpredicts the
Theby
than estimated
objective effort
effort required.
Top-down depends on the customer’s
assessment.
Estimates are made on the
budget and not on the
Bottom-up basis of the logical function
software functionality.
Each component is
rather than components
estimated. Allthat
implementing of them are
function.
added to product a final
estimate.
Bottom-up estimating
The estimator breaks the project into its component tasks
and then estimates how much effort will be required to
carry out this task.
With a large project, the process of breaking down into
tasks would be a repetitive one: each task would be
analyzed into its component sub-tasks and these in turn
would be further analyzed.
This is repeated until you get to components that can be
executed by a single person in about a week or two.
The bottom-up part comes in adding up the calculated
effort for each activity to get an overall estimate.

The top-down approach and parametric models

• The top-down approach is normally associated with parametric
models.
• Form of parametric models’ formulation:
Effort = (system size) X (productivity rate)
The top-down and bottom-up approaches are not mutually exclusive. Project
managers will probably try to get a number of different estimates from
different people using different methods. Some parts of an overall estimate
could be derived using a top-down approach while other parts could be
calculated using a bottom-up method.

The top-down approach and parametric models
Example
Amenda at IOE might estimate that the first software module to be constructed is 2KLOC. She might
then judge that if Kate undertook the development of the code, with her expertise she could work at
a rate of 40 days per KLOC.

5.6 Expert judgement
It is shown that experts tend to use a

combination of an informal analogy approach
where similar projects from the past are
identified, and bottom-up estimating.

5.7 Estimating by analogy
• Case-based reasoning;
• Estimator seeks out project that have been completed –
“Source cases”;
• That has been similar characteristics to the new project –
“Target cases”;
• The effort that has been recorded for the matching source
case can then be used as a base estimate for the target;
• The estimator should then try to identify any differences
between the target and the source and make adjustments to
the base estimate for the new project.

The Euclidean distance is calculated:
distance = tp 1  sp 1   ...  tp n  sp n 

2 2

Where tp = target parameter
sp = source parameter

Example 5.1
The new project is known to require 7 inputs and 15 outputs. One of the
past cases, project A, has 8 inputs and 17 outputs. The Euclidean distance
between source and the target is =
Project B has 5 inputs and 10 outputs. What would be the Euclidean
distance between this project and the target new project being considered
above? Is the project B a better analogy with the target than project A?

Summary
Methodology Description
Analogy (Comparative) Compare project with past similar projects
Individuals assess components, then component

Bottom-up (Grass Roots) estimates are summed to obtain total estimate.
Project partitioned into lower level components & life
Top-down cycle phases beginning at highest level
Expert Judgment Consult with one or more experts.
Perform overall estimate using design parameters and

Parametric (Algorithm) mathematical algorithms.

Summary
Methodology Advantages
Analogy Estimates are based on actual experience.
Accurate estimates are possible because of detailed

Bottom-up basis for estimate; also promotes individual
responsibility, supports project tracking.
More applicable to early project estimates.
Top-down Considers system level activities,
faster, easier to implement.
Little or no historical data are needed; good for new
Expert Judgment or unique projects.
Models are usually fast and easy to use, and useful

Parametric early in a program. They are also objective and
repeatable.

Summary
Methodology Disadvantages
Analogy Truly similar projects must exist.
• Methods are time-consuming.

• Detailed data needed may not be available,
Bottom-up especially early in a program.
• Integration costs may be disregarded.
• Process is costly
• Less accurate than other methods,

Top-down • tends to overlook lower-level components,
• provides little detail.
Experts tend to be biased, and knowledge level is
Expert Judgment sometimes questionable.
• They are often inaccurate and unstable.

Parametric • Also, calibration to historical data may not be
relevant for new programs.
5.8 Albrecht function point analysis
The basis of function point analysis is that computer-based

information systems comprise five major components, or external
user types in Albrecht’s terminology, that are of benefit to the users:
External input types

External output types
Logical internal file types
External interface file types
External inquiry types

Case Study Examples: Assessing the complexity of a logical internal file
Table 5.2: Albrecht complexity multipliers
Multiplier
External user type Low Average High
External input type 3 4 6

External output type 4 5 7
Logical internal file type 7 10 15
External interface file type 5 7 10
External inquiry type 3 4 6

Format Examples: Assessing the complexity of a logical internal file

Complexity Tables: Albrecht Function point
External Input Table (EI) Shared EO and EQ Table
Values for transactions

Complexity Tables: Albrecht Function point
Internal Logical File & External Interface File (ILF & EIF)

Level of selected software languages relative to Assembler language
Language Ratio-source : Executable
Assembler 1:1
C 1 : 1.5
COBOL 1:3
FORTRAN 1:3
PASCAL 1 : 3.5
RPG 1:4
PL/1 1:4
BASIC 1:5
4GLs 1:8
QUERY LANG. 1 : 20
SPREADSHEET 1 : 50

5.8 Function points
FP = Total UFP X [0.65 + 0.01 x  (VAF)] ; VAF = Scale of 0 to 5

5.8 Function points - SLOC

5.9 Function points Mark II
The ‘Mark II’ label implies an improvement and replacement of

the Albrecht method.
The information processing size is initially measured in
unadjusted function points [UFPs] to which a technical complexity
adjustment [TCA] can then be applied.

For each transaction the UFPs are calculated:

Wi x (number of input data element types) +
We x (number of entity types referenced) +
Wo x (number of output data element types)
Here, W is weightings that might be derived by asking developers what proportion of effort
has been spent in previous projects developing those parts of the software that deal with
processing inputs, assessing, and modifying stored data and processing outputs.
Data Store
Input Output Return

From
User Process to user
Model of transaction
Note: Industry averages are 0.58 for W-input, 1.66 for W-entity and 0.26 for W-output. All ratios are 2.5
Case study Example: Calculating Mark II function points
• Two entity types – Invoice and CashReceipt

• Data elements – InvoiceNumber, DateReceived, CashReceived
• Output – error message
The unadjusted function points, using the industry average weightings,

for this transaction would therefore be:
(0.58 x 3) + (1.66 x 2) + (0.26 x 1) = 5.32

Example 5.7
The IOE maintenance group accounts subsystem for which Amanda is

responsible will have a transaction which sets up details of new group
account customers. The operator will input:
• Customer account number
• Customer Name
• Address
• Postcode
• Customer Type
• Statement production date
All this information will set up in a CUSTOMER record on the system’s

database. If a CUSTOMER account already exists for the account number that
has been input, an error message will be displayed to the operator. Calculate
the number of unadjusted Mark II function points for this transaction, using the
industry average weightings.

The original Albrecht FP method identified 14 technical complexity

adjustment factors – Mark II FPs identify five more factors:
• Interfaces to other applications;

• Special security features;
• Direct access for third parties;
• User training features;
• Documentation requirements.

If you have figures for the effort expended on past projects and also
the system size in FPs, you should be able to work out a productivity
rate, that is:
Productivity = size / effort.
For new projects, the function points can be counted and then the
effort can be projected using the productivity rate derived above:
Effort = size / productivity.
A more sophisticated way of doing this would be by using the

statistical technique, least squares regression, to derive an equation
in the form:
Effort = constant1 + size x constant2.

5.10 COSMIC Full Function Points
Common Software Measurement Consortium – Full Function Point
Full function point (FFP) method has its origins in the work of two
interlinked research group.
COSMIC requires the analyst to break down the system architecture
into a hierarchy of software layers.
Data groups can be moved about in four ways:
Entries (E)
Exits (X)
Reads (R)
Writes (W).
The overall FFP count is derived by simply adding up the counts for each of the four
types of data movement. The resulting units are Cfsu (COSMIC functional size units).
5.10 Object points
If you are building a system using a high level application

building tool – object-oriented techniques, the approach uses
counts of the screens, reports, and 3GL components that an
application might possess – it is these that are referred to as
objects.
Each object has to be classified as one of the following:
Simple;
Medium;
Difficult.

5.10 Object points
srvr is the number of server ( mainframe or equivalent ) data tables used in conjuction with the SCREEN or REPORT
clnt is the number of client ( personal workstation ) data tables used in conjuction with the SCREEN or REPORT

5.10 Object points
Complexity weighting
Object Type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL - - 10
Component
Object points complexity weightings

5.10 Object points
If application containing 840 object points, 20% can be supplied by

using existing components, then the adjusted new object points
(NOP) score would be:
NOP = 840 x (100 – 20)/100 = 672
Productivity rate (PROD) has to be identified. An estimate of the

person-months needed to carry out the project is then calculated by
dividing PROD into NOP.
Given 672 new object points and a development environment where

productivity was nominal, then estimated effort for the project would
be:
672/13 = 52 months.
Here, nominal of PROD = 13 (see Table 5.9 object point effort conversion).

5.11 A procedural code-oriented approach
1. Envisage the number and type of programs in

the final system
2. Estimate the SLOC of each identified program
3. Estimate the work content, taking into account

complexity and technical difficulty
4. Calculate the work-days effort

5.12 COCOMO : a parametric model
The COCOMO Model ( Barry Boehm 1981):
The COnstructive COst MOdel ( COCOMO) is an example of

regression models used for estimating software cost and effort.
These methods use a basic formula with parameters that are
determined via a historical database and current project
characteristics.
The COCOMO Model is the most widely used and accepted

of the cost / effort estimation models. This model as a size-driven
model is highly dependent upon the manager's ability to estimate
the size of the software system at an early stage. This method is
generally used in conjunction with one of the size estimation models
such as function points.

COCOMO (Constructive Cost Model) is often referred to in the

literature on software project management, particularly in
connection with software estimating. The term COCOMO really
refers to a group of models.
The basic model was built around the equation:
effort = c x sizek
Where effort is measured in pm, or the number of ‘person-months’ consisting of

units of 152 working hours, size is measured in kdsi, thousands of delivered source
code instructions, and c and k are constants (see Table 5.10).

5.12 COCOMO : a parametric model (ADD)
Small Projects:
Measurements of small to moderate projects resulted in a model of the following form:
EFFORT = a * SIZE + b
Here, the magnitude of the effort is a linear function of the size of the project ( Number of Lines of
Code, usually ). This model holds up until a certain point, usually for projects that can be reasonably
accomplished by small teams of two or three people. By increasing the size of the project, the above
model becomes less and less accurate an the need for a new model increases.
Large Projects:
Projects requiring teams of more than three or so people tend to behave in the following
way:
EFFORT = a * SIZE b
Here, the size of the project is scaled exponentially, therefore as a product increases in size, the
effort to produce the product grows more than linearly ( for b >= 1 ). It means that if we try to
develop a larger product, our productivity ( SIZE / EFFORT ) Decreases. This decrease in productivity
on larger projects is called a diseconomy of scale.

The Organic Mode
 Software developed “in house”

 Experienced developers
 Requires small developer teams
 Small communication overhead
 Stable development environment
 Small size (about 50 KSLOCs)
NOTE: Boehm’s notation for SLOCs: DSI (Delivered Source Instructions).

Semi-Detached Mode
 Developers have an intermediate level of experience

with related systems.
 Mixture of experienced and unexperienced
developers.
 Team can have experience relative only for some
project aspects.
 Size extends up 300 KDSI
This is the intermediate level between Organic and Embedded mode.

Embedded Mode
 Projects developed within tight constraints.

 Product must operate within (embedded in) a
strongly coupled complex of hardware, software
and operational procedures.
 High cost on changing parts.
 Projects on not very known fields.
 Any size

C K
2.4 1.05
• Organic Mode
• Embedded Mode 3.6 1.20
• Semi-detached Mode 3.0 1.12

The nominal estimate is then adjusted by a development effort

multiplier (dem):
pmest = pmnom x dem
Where dem is calculated by taking into account multipliers based on the effort drivers
in Table 5.11
The effect of analyst capability: ACAP

Very Low 1.46
Low 1.19
Nominal 1.00
High 0.8
Very High 0.71

Driver type Code Cost driver

Product attribute RELY Required software reliability
DATA Database size
CPLX Product complexity
Computer attribute TIME Execution time constraints
STOR Main storage constraints
VIRT Virtual machine volatility
TURN Computer turn around time
Personnel attribute ACAP Analyst capability
AEXP Application experience
PCAP Programmer capability
VEXP Virtual machine experience (OS)
LEXP Programming language experience
Project attribute MODP Use of modern programming practice
TOOL Use of software tools
SCED Required development schedule.
Attribute Very low Low Nominal High Very high

ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.80 0.70
VEXP 1.21 1.10 1.00 0.90 -
LEXP 1.14 1.07 1.00 0.95 -

COCOMO II has been designed to accommodate this by having models

for three different stages.
Application composition
Early design
Post architecture

5.12 COCOMO II : a parametric model

Different between Basic COCOMO and Intermediate COCOMO

To estimate the effort for application composition, the counting of

object points, which were described earlier, is recommended by the
developers of COCOMO II.
At the early design stage, FPs are recommended as the way of
gauging a basic system size. An FP count might be converted to a SLOC
equivalent by multiplying the FPs by a factor for the programming
language that is to be used.
The following model can then be used to calculate an estimate

of person-months:
pm  A  size  em1  em2  ...  emn
sf
A is a constant, size is measured in SLOC, sf is exponent scale factor, em is

effort multipliers.
sf  0.91  0.01  exp .driver.rate 

Effort Adjustment Factor (EAF)

Very Low Low Nominal High Very High
1. Product Distribution
- Software Reliability 0.75 0.88 1.00 1.15 1.40
- Database Size 0.94 0.94 1.00 1.08 1.16
- Product Complexity 0.70 0.85 1.00 1.15 1.30
2. Computer Distribution
- Execute time constraints 1.00 1.00 1.00 1.11 1.30
- Main storage constraints 1.00 1.00 1.00 1.06 1.21
- Virtual machine volitility 0.87 0.87 1.00 1.15 1.30
- Computer turnaround time 0.87 0.87 1.00 1.07 1.15
3. Personnel Distribution
- Analyst Capability 1.46 1.19 1.00 0.86 0.71
- Applications experience 1.29 1.13 1.00 0.91 0.82
- Programmer capability 1.42 1.17 1.00 0.86 0.70
- Virtual machine experience 1.21 1.10 1.00 0.90 0.90
- Programming Language experience 1.14 1.07 1.00 0.95 0.95
4. Project attributes
- Use of modern programming practice 1.24 1.10 1.00 0.91 0.82
- Use of software tools 1.24 1.10 1.00 0.91 0.83
- Require development schedule 1.23 1.08 1.00 1.04 1.10

The qualities that govern the exponent driver used to calculate the 5
scale factors are listed below:
Precedentedness
Development flexibility
Architecture/risk resolution
Team cohesion
Process maturity

COCOMO II Effort Equation

The COCOMO II model makes its estimates of required effort (measured in Person-Months
– PM) based primarily on your estimate of the software project's size (as measured in
thousands of SLOC, KSLOC)):
Effort = 3.0  EAF  (SIZE)E

Where
EAF is the Effort Adjustment Factor derived from the Cost Drivers
E is an exponent derived from the five Scale Drivers

COCOMO II Schedule Equation

The COCOMO II schedule equation predicts the number of months required to complete
your software project. The duration of a project is based on the effort predicted by the
effort equation:
Duration = 2.5  (Effort)SE
Where
Effort is the effort from the COCOMO II effort equation
SE is the schedule equation exponent derived from the five Scale Drivers
Effort
Staffing 
Duration

5.12 COCOMO II : Example
Consider a database system needed for an office automation project. The

requirements document shows 4 modules needed. The project is judged
to be ORGANIC
Sizes are estimated as follows:
data entry 0.6 KDSI

data update 0.6 KDSI
query 0.8 KDSI
report gen. 1.0 KDSI
The manager rates project details as follows:
Complexity (HIGH) EAF = 1.15

Storage (HIGH) EAF = 1.06
Experience Programmer (LOW) EAF = 1.13
Capabilities (LOW) EAF = 1.17

PROJECT SIZE = 0.6 + 0.6 + 0.8 + 1.0 = 3.0 KDSI
EAF = 1.15 x 1.06 x 1.13 x 1.17 = 1.61
Person Months for the project:
PM = 1.61 x 3.2 x (3.0)1.05

PM = 1.61 x 3.2 x 3.17
PM = 16.33
DURATION
DURATION = 2.5 x EFFORT 0.38

DURATION = 2.5 x (16.33)0.38
DURATION = 2.5 x 2.89
DURATION = 7.23 7 months to complete

Effort
Staffing 
Duration
How Many people to hire ?
Staffing = 16.33 pm / 7.23 months = 2.26 persons
3 team members needed

5.13 Conclusion
To summarize some key points:

 Estimates are really management targets
 Collect as much information about previous projects as possible
 Use more than one method of estimating
 Top-down approaches will be used at the earlier stages of project planning
while bottom-up approaches will be more prominent later on
 Be careful about using other people’s historical productivity data as a basis
for your estimates, especially if it comes from a different environment
 Seek a range of opinions
 Document your method of doing estimates and record all your
assumptions

SPM Chapter5

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPM Chapter5

Uploaded by

Copyright:

Available Formats

Software effort estimation

Software Project Management Slide# 1

• Avoid the dangers of unrealistic estimates;

Software Project Management Slide# 2

Definition of successful project:

• Novel applications of software;

• Lack of homogeneity of project experience

Software Project Management Slide# 3

10 Lower level planning

9 Execute plan 8 Review/publicize plan

Software Estimation take place in step 3 and 5 in particular

Software Project Management Slide# 4

A 3.9 (23) 5.3 (32) 7.4 (44) 16.7 6050

Software Project Management Slide# 5

Subjective nature of estimating

• Different groups within an organization

Software Project Management Slide# 6

Software Project Management Slide# 7

Work expands to fill the time available

Software Project Management Slide# 8

• Not be completed on time or to cost;

Software Project Management Slide# 9

1. The need for historical data

• Software measurement : source line of code

Software Project Management Slide# 10

Software Project Management Slide# 12

The top-down approach and parametric models

Effort = (system size) X (productivity rate)

Software Project Management Slide# 13

The top-down approach and parametric models

Software Project Management Slide# 14

It is shown that experts tend to use a

Software Project Management Slide# 15

Software Project Management Slide# 16

The Euclidean distance is calculated:

distance = tp 1  sp 1   ...  tp n  sp n 

Software Project Management Slide# 17

Software Project Management Slide# 18

Analogy (Comparative) Compare project with past similar projects

Individuals assess components, then component

Expert Judgment Consult with one or more experts.

Perform overall estimate using design parameters and

Software Project Management Slide# 19

Analogy Estimates are based on actual experience.

Accurate estimates are possible because of detailed

Models are usually fast and easy to use, and useful

Software Project Management Slide# 20

Analogy Truly similar projects must exist.

• Methods are time-consuming.

• Less accurate than other methods,

• They are often inaccurate and unstable.

The basis of function point analysis is that computer-based

External input types

Software Project Management Slide# 22

Case Study Examples: Assessing the complexity of a logical internal file

Table 5.2: Albrecht complexity multipliers

External input type 3 4 6

Software Project Management Slide# 23

Format Examples: Assessing the complexity of a logical internal file

Software Project Management Slide# 24

Complexity Tables: Albrecht Function point

External Input Table (EI) Shared EO and EQ Table

Values for transactions