SOEN 341

week 6
Software project management II
Estimation techniques
The problem

You must make initial estimates on:

 incomplete user requirements definition
 the software that may have to run on:
 unfamiliar platforms or
 use new development technology
 the people involved in the project and their skills (likely
unknown)

2
Result:

 It is impossible to estimate system development costs

accurately during the early stages of a project.
 Nevertheless, organizations need to make software effort
and cost estimates

3
Estimation techniques

EXPERIENCE-BASED ALGORITHMIC COST

TECHNIQUES MODELING

4
Estimation techniques

 In both cases, you need to use your judgment to

estimate either the effort directly
 or the project and product characteristics

5
Estimate uncertainty

B. Boehm et al. 1995 6

 Some Popular Experience-based
estimation approaches

ESTIMATION BY ESTIMATION BY EXPERT

ANALOGY JUDGMENT
7
Estimation by Analogy

 Estimate new projects by comparing them to similar past

projects, preferably decomposing the estimate.
 Using analogies to determine size measure.

8
Estimation by Analogy (1)
• Step 1: Get detailed size results for a similar previous
project:
• Find the subsystems (DB, UI, Graphs/reports, Foundation
classes, Business rules,…etc.).
• Find the number of elements such as tables in DB, web
pages for each subsystem.
• Scope out the new system.

9
Example: AccSellerator is a past
project, Triad is a new similar project

Subsystem Actual Size of Estimated Size of Multiplication

AccSellerator 1.0 Triad 1.0 Factor
Database 10 tables 14 tables 1.4
User interface 14 web pages 19 web pages 1.4
Graphs and repor 10 graphs + 8 14 graphs + 16 1.7
ts reports reports
Foundation class 15 classes 15 classes 1.0
es
Business rules ??? ??? 1.5

10
Estimation by Analogy (2)
 Step 2: Compare the size of the new Project to a similar
past project.

 Multiplication factor (subsystem) =

 (number of elements in New) / (number of elements in Old)

11
Example: Step 2

Subsystem Actual Size of Estimated Size of Multiplication

AccSellerator 1.0 Triad 1.0 Factor
Database 10 tables 14 tables 1.4
User interface 14 web pages 19 web pages 1.4
Graphs and repor 10 graphs + 8 14 graphs + 16 1.7
ts reports reports
Foundation class 15 classes 15 classes 1.0
es
Business rules ??? ??? 1.5

12
Estimation by Analogy (3)
 Step 3: Build up estimate for the size of the new project.:

 Size (new subsystem) =

 Size (old subsystem) * Multiplication factor
 Size (New project) =
 sum of the sizes of its subsystems

13
Example: Step 3

Subsystem Code Size of Multiplication Estimated Code

AccSellerator Factor size of Triad 1.0
1.0
Database 5,000 1.4 7,000
User interface 14,000 1.4 19,600
Graphs and report 9,000 1.7 15,300
s
Foundation classe 4,500 1.0 4,500
s
Business rules 11,000 1.5 16,500
TOTAL 45,500 62,900

14
Estimation by Analogy (4)
 Step 4: Create an effort estimate based on the size of
the new Project.
 Size Ratio =
 Size(New Project)/Size (Old Project)
 Estimated Effort (New Project) =
 Effort (Old Project) * Size Ratio
 If uncertain in a case of a subsystem:
 produce an effort range, for instance, factor of 0.75 to 2.25 for
50% uncertainty.

15
Example: Step 4

Term Value
Size of Triad 1.0 62,900 LOC
Size of AccSellerator 1.0 ÷ 43,500 LOC
Size ratio = 1.45
Effort for AccSellerator 1.0 30 staff months
Estimated effort for Triad 1.0 30 x 1.45 = 44 staff months

16
 Some Popular Experience-based
estimation approaches

ESTIMATION BY ESTIMATION BY EXPERT

ANALOGY JUDGMENT
17
Expert Judgment
• Asking for an estimate of task effort from someone who
is knowledgeable about either the application or the
development environment.
• The estimator would have to examine the existing code
to judge the proportion of code affected and from that
derive an estimate.
• There may be cases where the opinions of more than
one expert need to be combined (Delphi technique)

18
 “It is better to be roughly right than
precisely wrong”

• Use historical values

• Use ranges
– Example:
1. Estimated effort is 15
person-month
2. The estimated effort is in the
range
[0.6  15p-m, 1.6  15p-m] =
[9 p-m, 24 p-m]

19
Team Effort Estimate for a Project (Delphi)

1. Have each team member estimate pieces of the project

individually, and then meet to compare estimates.
2. Discuss the differences among the individual results.
3. Average your estimates.
4. Arrive at a consensus estimate E that the whole group accepts.
5. Calculate a range of effort estimation values:

– At the beginning of the project the range is approximately within +-

25%
– [min, max]: min = [E * 75%, E * 125%]
– When the project advances the range is within +- 15% [min, max]: min
= [E * 85%, E * 115%]

20
Experience-based approaches

 Experience-based techniques rely on judgments based

on experience of past projects and the effort expended in
these projects on software development activities.
 Typically, you identify the deliverables to be produced
in a project and the different software components or
systems that are to be developed.
 You document these in a spreadsheet, estimate them
individually and compute the total effort required.
 It usually helps to get a group of people involved in the
effort estimation and to ask each member of the group to
explain their estimate.
21
Problem with experience-based
approaches
 The difficulty with experience-based techniques is that a
new software project may not have much in common
with previous projects.
 Software development changes very quickly and a
project will often use unfamiliar techniques such as
machine learning, Large-Language Models, etc.
 If you have not worked with these techniques, your
previous experience may not help you estimate the effort
required, making it more difficult to produce accurate
costs and schedule estimates.

22
Algorithmic cost modelling

 Cost is estimated as a mathematical function of

product, project and process attributes whose
values are estimated by project managers:
 Effort = A * SizeB * M
 A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier
reflecting product, process and people attributes.
 Most models are similar, but they use different values for
A, B and M.
 The most used product attribute for cost estimation is
code size.

23
Estimate number of lines of code in a
system
 Compare the system to be developed with similar
systems and use their code size as the basis for your
estimate
 Estimate the number of function or application points in
the system and formulaically convert these to lines of
code in the programming language used
 Rank the system components using judgment of their
relative sizes and use a known reference component to
translate this ranking to code sizes

24
Estimation accuracy

 The size of a software system can only be known

accurately when it is finished.
 Several factors influence the final size
 Use of reused systems and components;
 Programming language;
 Distribution of system.
 As the development process progresses then the size
estimate becomes more accurate.
 The estimates of the factors contributing to B and M are
subjective and vary according to the judgment of the
estimator.

25
Effectiveness of algorithmic models

 Algorithmic cost models are a systematic way to estimate

the effort required to develop a system. However, these
models are complex and difficult to use.
 There are many attributes and considerable scope for
uncertainty in estimating their values.
 This complexity means that the practical application of
algorithmic cost modeling has been limited to a
relatively small number of large companies, mostly
working in defense and aerospace systems
engineering.

26
Question

Which of the following statements is

correct about estimating effort
a) It is impossible to say whether
experience-based or algorithmic
approaches are more accurate
b) Experience-based are more
accurate than algorithmic
approaches
c) Experience-based are less
accurate than algorithmic
approaches

27
COCOMO cost modeling

28
COCOMO cost modeling

 An empirical model based on project experience.

 Well-documented, ‘independent’ model which is not tied
to a specific software vendor.
 Long history from initial version published in 1981
(COCOMO-81) through various instantiations to
COCOMO 2 (1995) .
 COCOMO 2 considers different approaches to software
development, reuse, etc.

29
COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models
that produce increasingly detailed software
estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software
is composed from existing parts.
 Early design model. Used when requirements are
available but design has not yet started.
 Reuse model. Used to compute the effort of
integrating reusable components.
 Post-architecture model. Used once the system
architecture has been designed and more information
about the system is available.
30
CoCoMo 2

• The basic CoCoMo model assumes that the

effort is only a function of the number of lines
of code and some constants evaluated
according to the type of software system.
• However, no system’s effort and schedule can
be calculated based just on kdsi.
• Moreover, estimates are required at different
stages in the system life cycle and CoCoMo II
has been designed to accommodate this by
having models for three different stages.
31
COCOMO estimation models

32
Early-design stage example

 The following model can be used to calculate an estimate

of person-months.
p-m = A * (SIZE )sf  em1  em2 …  emn

 where p-m is the effort in ‘person-months’, A is constant

(which was set in 2000 at 2.94), size is measured in kdsi,
and sf is exponent scale factor and em are the effort
multipliers.
sf = B+0.01  (exponent driver ratings)

 where B is a constant currently set at 0.91. The effect of

the exponent scale factor is to increase the effort
predicted for large projects.
33
Scale factor values

 Development flexibility (FLEX)

 The number of possibilities to meet the requirements
 Architecture/risk resolution (RESL)
 The degree of uncertainty about the requirements
 Team cohesion (TEAM)
 The degree to which there is a large dispersed team
 Process maturity (PMAT)
 The more structure and organized the software is produced, the
lower the uncertainty and the lower the rating for this exponent
driver

34
Scale factor values

• Precedentedness (PREC)
 The degree to which there are similar cases in the past, for the
project that is being planned.

Driver Very low Low Nominal High Very High Extra high
PREC 6.2 4.96 3.72 2.48 1.24 0
FLEX 5.07 4.05 3.04 2.03 1.01 0
RESL 7.07 5.65 4.24 2.83 1.41 0
TEAM 5.48 4.38 3.29 2.19 1.10 0
PMAT 7.80 6.24 4.68 3.12 1.56 0

35
Example

 A new project has ‘average’ novelty for the software

supplier that is going to execute it and is given a nominal
rating on this account for precedentedness.
 Development flexibility is high, but requirements may
change radically so the risk resolution exponent is rated
very low.
 The dev. team are all located in the same office which
leads to team cohesion rated as very high, but the
software house tends to be very informal in its standards
and procedures, hence the process maturity driver has
therefore given a rating of low.

36
Exercise 1

1. What would be the scale factor in this case?

2. What would be the estimate of effort if the size of the
application was estimated as 2000 LOC?

37
Solution

Driver rating value

PREC Nominal 3.72
FLEX High 2.03
RESL Very low 7.07
TEAM Very high 1.10
PMAT low 6.24

sf= 0.91+0.01(3.72+2.03+7.07+1.10+6.24)
sf= 1.112
EFFORT = 2.94  21.112
EFFORT = 6.35 p-m

38
Effort multipliers (em)

 Adjust the estimate to take account of productivity

factors.
 A value greater than 1 increases development effort,
while a value less than 1 decreases it.
 The nominal rating means that the multiplier has no
effect.

39
Early design effort multipliers

Code Effort modifier Extra Very Low Nominal High Very Extra
low low high high
RCPX Product 0.49 0.60 0.83 1 1.33 1.91 2.72
reliability and
complexity
RUSE Required 0.95 1 1.07 1.15 1.24
reusability
PDIF Platform 0.87 1 1.29 1.81 2.61
difficulty
PERS Personnel 2.12 1.62 1.26 1 0.83 0.63 0.5
capability
PREX Personnel 1.59 1.33 1.12 1 0.87 0.74 0.62
experience
FCIL Facilities 1.43 1.30 1.10 1 0.87 0.73 0.62
available
SCED Schedule 1.43 1.14 1 1 1
pressure

40
Example

 A software supplier must produce an app that controls a piece of equipment

in a factory.
 A very high degree of reliability is needed as malfunction could injure the
operators.
 The algorithms to control the equipment are quite complex.
 The company plan to reuse the control system, with suitable modifications in
the future.
 Developers are familiar with the platform.
 The current staff is very capable.
 The project is a typical application domain for them.
 The toolsets available for developers are judged to be typical.
 The degree of schedule pressure to meet a deadline is typical too.

41
Exercise 2

1. What would be the value for each of the effort

multipliers?

2. What would be the impact of all the effort multipliers on a

project estimated as taking 200 p-m?

42
Solution

Code Effort modifier Rating Effort multiplier

RCPX Product reliability and complexity Vh 1.91
RUSE Required reusability Vh 1.15
PDIF Platform difficulty L 0.87
PERS Personnel capability Vh 0.63
PREX Personnel experience Nominal 1
FCIL Facilities available Nominal 1
SCED Schedule pressure Nominal 1

EM= 1.911.15 0.87 0.63 1 1 1

EM= 1.20
EFFORT = 200  1.20
EFFORT = 240 p-m

43
Key points

 Estimation techniques for software may be experience-based,

where managers judge the effort required, or algorithmic, where the
effort required is computed from other estimated project parameters.
 The COCOMO II costing model is a mature algorithmic cost model
that takes project, product, hardware and personnel attributes into
account when formulating a cost estimate.

44
References

 Ch. 23.5 23.6, Sommerville, Ian. Software Engineering.

10th edition. Pearson, 2016.
 Ch. 5. Hughes, Bob. Software Project Management 5e.
McGraw Hill, 2009.
 https://www.codeproject.com/Articles/9266/Software-Proj
ect-Cost-Estimates-Using-COCOMO-II-Mo

45