Estimation

Dumitru Radoiu

Under the water

line
Client
Problem

P j
Project

0
IS Project
j Management
g

Project Planning
Estimation t, $
Planning
Project Development
Execution of Vision
Coordination
Outsourcing
O
i
Risk management
HR, Time, Cost, Mngm
j Closingg
Project
Project Evaluation

An IT Solution

IS Dev Models

time

IS Dev Technology
gy

Life cycle

IS Architectures (e.g.SOA)

Spiral

IS Modelling Languages (e.g. UML)

Prototype

IS Tools (e.g. Rational tools)

4GT
RAD
XP
RUP

A d
Agenda
A. What and how to estimate?
- size
- effort
- schedule
- cost

B. The Basic Project Estimation Process + Tools architecture

C. Holistic Models for Cost Estimation
- COCOMO (simple and intermediate)

Project Size

Project Type
Operational
Model
Selection

Development Model
Effort

Duration

Cost
Development Model

Project
Size
LARGE
MEDIUM

WATERFALL

ITERATIVE

ITERATIVE &
INCREMENTAL

If duration > 3 months,

splitting into increments
/ iterations suggested

SMALL

VERY
SMALL

Not recommended

Not recommended

Not recommended

Not recommended

Not recommended

Large

Medium

Small / Very Small

Requirements

Requirement Analysis

Requirement Analysis

Analysis

Design

Development

Design

Coding & Unit Testing

Delivery

C di
Coding
& Unit
U it TTesting
ti

I t
Integration
ti
/ System
S t
Testing
T ti

A
Acceptance
t
Test
T t

Integration Testing

Delivery

System Testing

Acceptance Test

Delivery

Implementation Support

Acceptance Test

Post Implementation
Support

Implementation Support
Post Implementation
p
Support

E ti ti Size
Estimating
Si
By analogy:
A.
B.

Use a similar project done in the past, knowing its size OR

Estimate each major piece of the new project as a percentage of the size of a
similar ppiece of the pprevious pproject;
j ; total size byy addingg upp

By counting product features:

Step 1: Count features (e.g. subsystems, classes/modules, methods/functions, screens,
dialogs, files, database tables, reports, messages)
St 2 Use
Step2:
U an algorithmic
l ith i to
t convertt features
f t
into
i t size
i (e.g.
(
Functional
F ti l Points)
P i t)

E ti ti Effort
Estimating
Eff t
Direct estimation:
Based on historical data (same expertise, same tools, etc)
Step1: Chose a software development process you follow (e.g. RUP or DSDM)
Step2:
p Identify
y all sub-processes
p
((e.g.
g biz. modeling,
g, business req.,
q , design,
g , coding,
g, etc))
Step3: Estimate the Effort for all sub-processes by analogy
Step4: Sum up

OR
Indirect Estimation: Derive Effort from Size:
Use a generally accepted algorithmic approach
a.
Barryy Boehms COCOMO model COCOMO = COnstructiveCOstMOdel
b. Putnam Methodology

E ti ti Schedule
Estimating
S h d l
Estimate the project schedule from the effort estimate:
-

Storyboard with Work Breakdown Structure: Analysis, Design, Coding, etc

Staffing profile for each phase + start & end time (concurrent / successive)
Sum upp calendar schedule

Staffing profile:
A.
B.

Use historical data

Use a schedule estimation rule of thumb [McConnell 1996]:

Schedule in months = 3.0 * (effort-months) 1/3

Opinions
p
vary
y as to whether 2.0 or 2.5 or even 4.0 should be used in place
p
of the 3.0
value only by trying it out will you see what works for you.

The p
pregnant
g
woman p
paradox:
If a woman delivers a baby in 9 months, it follows 9 women deliver a baby in one
month.

E ti ti Cost
Estimating
C t
Direct estimation of cost :
Labor
HW
SW licenses
Travel
Testing
Communication
Trainingg
Office Space, and so on.
Often, a software development project manager will only estimate
Labor cost
Organization
g
overhead (average)
(
g )
Project budget

A d
Agenda
A. What and how to estimate?
- size
- effort
- schedule
- cost

B. The Basic Project Estimation Process + Tools architecture

C. Holistic Models for Cost Estimation
- COCOMO (simple and intermediate)

The Basic Project Estimation Process

Commercial Estimation Tool Context

Check Cost Xpert

A d
Agenda
A. What and how to estimate?
- size
- effort
- schedule
- cost

B. The Basic Project Estimation Process + Tools architecture

C. Holistic Models for Cost Estimation
- COCOMO (simple and intermediate)

Holistic Models for Cost Estimating

SDM (Software Development Model - Putnam - 1978)

SLIM (Software Lifecycle Management - Putnam - 1979)
COCOMO (Constructive Cost Model - Boehm - 1981)
COPMO (Cooperative Programming Model - Conte,
Conte Dunsmuir,
Dunsmuir Shen - 1986)

Of these models, COCOMO is most widely used, and will suffice if there is
y out activity-based
y
cost estimation.
insufficient data to carry

COCOMO: An empirical estimation model

A.
B.

Basic COCOMO and Intermediate COCOMO (based on Static

single variable equations)
Advanced COCOMO (based on Static multi-variable equations)

COCOMO = COnstructiveCOstMOdel; The best documented

software costing
g model.
Classifies projects in three classes (for better estimation):
Organic
Semidetached
Embedded

Classes of software projects

Organic Mode Projects Semi-detached
Semi detached Mode Projects
Small size
Small team
Low complexity
Familiar
N rigid
Non
i id requirements
i
t

Intermediate size
Mixed experience team
Medium complexity
Some parts familiar
S
Some
requirements
i
t are rigid
i id

Embedded Mode Projects

Large size
Little experience available
High validation cost
Tight HW, SW, operational
constraints

Basic COCOMO
Static single valued model that calculates software development effort and
cost as a function of program size
Effort = constant1 * (Size)constant2
[Effort] = person x month
S hed le = constant3*(Effort)
Schedule
t t3*(Eff t)constant4
[Schedule] = chronological months

The proposed constants (Boehm) vary depending on the class of the project
Software Project

Constant1

Constant2

Constant3

Constant4

Organic

2.4

1.05

2.5

0.38

Semidetached

3.0

1.12

2.5

0.35

Embedded

3.6

1.20

2.5

0.32

Basic COCOMO
Software Project

Effort

Development Time

Organic

Effort=2.4*(Size)1.05

Schedule=2.5*Effort0.38

Semidetached

Effort=3.0*(Size)
Effort=3
0*(Size)1.12

Schedule=2.5*Effort
Schedule=2
5*Effort0.35

Embedded

Effort=3.6*(Size)1.2

Schedule=2.5*Effort0.32

Basic COCOMO
Observations:
oThe definition of a line of code is not critical
oThe values of the constants could be modified
oThe model assumes requirements will not change significantly during development
oThe model assumes the project will be well managed by both the customer and the
developer.

Basic COCOMO
Example 1. For an organic mode software project with an estimated size
of 32,000 deliverable lines of code

Effort = 2.4(32)
2 4(32)1.05 = 91 person months
months.
Schedule = 2.5(91)0.38 = 14 months.
A
AverageNrPersons
NP
= 91/14 = 66.5
5 persons.
The pproductivityy of pprogrammers
g
is predicted
p
to be 352 LOC/person-month
p
or
about 16 LOC/day.

Basic COCOMO
Example 2. For a large embedded mode software project consisting of an
estimated 128,000 deliverable lines of code

Effort = 3.6(128)
3 6(128)1.2 = 1216 person months
months.
Scedule = 2.5(1216)0.32 = 24 months
A
AverageNrPersons
NP
= 1216/24 = 51 persons.
The ppredicted programmer
p g
productivity
p
y is about 105 LOC/month or about 4
LOC/day.

Basic COCOMO
Observations:
These estimates are consistent with productivity estimates from other
research.
The model also gives a minimum project duration which is dependent on
effort rather than the number of software engineers working on the project.
This is consistent with the experience that adding staff to a project which is
behind schedule will not help.
The model does not predict the result of using less staff over a longer
period of time.

Intermediate COCOMO Model

Attempts to include factors in addition to project size which effect the
resources required by a project, related to:
1. Product Attributes
2. Hardware Attributes
3. Project Attributes
4. Personnel Attributes
The values for the cost drivers are multiplied together to obtain an Effort
Adjustment
j
Factor ((EAF).
) EAF [0,9-1,4]
[ , , ]

Intermediate COCOMO Model

Effort = ai * (KLOC)bi * EAF
Software Project
j

ai

bi

Organic

3.2

1.05

Semidetached

3.0

1.12

Embedded

2.8

1.20

The values for the multipliers

are organisation specific should be calibrated for a
particular organisation.
organisation

Intermediate COCOMO Model

1. Product Attributes
1.

Required Software Reliability

Low (failure minor inconvenience) . very high (failure = risk to human

life)
2.

Size of application database

Low (size of DB (in bytes) is less than 10 times the code size (in lines of
code)), through nominal (10x to 100x) to very high (>1000x)
3.

Complexity
p
y of the project
p j

Low = simple I/O operations, simple data structures, Nominal = use of

library routines and inter-module communication.
Very high = recursive code,
code parallel processing,
processing complex data
management etc.

1. Product Attributes

Product Attribute
Cost Driver

Very
Low

Low

Nomin
al

High

Very
High

Extra
High

S/W Reliability

0 75
0.75

0 88
0.88

10
1.0

1 15
1.15

14
1.4

Database Size

0.94

1.0

1.08

1.16

Project
Complexity

0.7

0.85

1.0

1.15

1.3

1.65

Intermediate COCOMO Model

2. Hardware Attributes
Run-time Performance constraints Nominal means less than 50% of
available execution time used; extra high means >95% of available
execution time used.
used
Storage Constraints Nominal means less than 50% of storage is used; extra
high is >95% of storage used.
Volatility of the virtual machine environment. Low rating means that the
combination of h/w and s/w is changed at most once a year; very high is
once every
y two weeks.
Required turnaround time. Low means interactive system development;
high means turnaround of more than 12 hours

The multipliers for the hardware attributes are:

Hardware
Attribute Cost
Di
Driver

Very
Low

Low

Nomin
al

High

Very
High

Extra
High

Run time

1.0

1.11

1.3

1.66

1.0
.0

1.06
.06

1.21
.

1.56
.56

0.87

1.0

1.15

1.3

0.87

1.0

1.07

1.15

S o age
Storage
constraints
Virtual machine
Turnaround time

Intermediate COCOMO Model

3. Project Attributes
Use
U off S
Software
f
tools
l Low
L value
l means only
l basic
b i tools
l (e.g.,
(
compiler)
il )
available. Nominal value means a more complete set of implementation,
testing and debugging tools. High value implies tools to support all
development phases.
phases
Application of software engineering methods Low no use, Nominal means
some use, Very high - these methods in routine use.
Required development schedule A measure of how well the required
development schedule fits the nominal development schedule estimated
usingg the basic COCOMO model. Very
y low means an accelerated schedule,,
very high an extended schedule. Both high and low values increase the
effort required for the software development.

The multipliers for the project attributes are:

Project Attribute
Cost Driver

Very
Low

Low

Nomin
al

High

Very
High

Extra
High

S/W Tools

1.24

1.1

1.0

0.91

0.83

SWE methods

1.24

1.1

1.0

0.91

0.82

Required
schedule
h d l

1.23

1.08

1.0

1.04

1.1

Intermediate COCOMO Model

4. Personnel Attributes
Analyst capability
Software engineer capability
Application experience
Virtual machine experience
Programming language experience

The multipliers
p
for the ppersonnel attributes are:
Personnel
Attribute Cost
Driver

Very
Low

Low

Nomi
nal

High

Very
High

Extra
High

Analyst

1.46

1.19

1.0

0.86

0.71

S/W Engineer

1.42

1.17

0.86

0.7

Application
pp
exp.
VM Experience

1.29

1.13

1.0

0.91

0.82

1.21

1.1

1.0

0.95

Prog. Lang.
exp.

1.14

1.07

1.0

0.95

Intermediate COCOMO Model

Effort = ai * (KLOC)bi * EAF
Software Project

ai

bi

Organic

3.2

1.05

Semidetached

3.0

1.12

Embedded

2.8

1.20

The
h values
l
for
f the
h cost drivers
di
are multiplied together to
obtain an effort adjustment
factor (EAF)
(EAF). Typical range
is 0.9 to 1.4.

The Advanced COCOMO Model

The basic and intermediate COCOMO models consider the project as a
single entity.
Large systems are made up of a number of sub-systems which are not
homogeneous - some sub-systems
sub systems organic,
organic some intermediate
intermediate, some
embedded.
The advanced COCOMO model allows for estimates to be made for subsystems and the estimates combined for the project estimates.

Exemple:
Suppose basic COCOMO model predicts 45 person
person-months
months of effort to
develop an embedded application on a workstation.
Suppose the effort multipliers for the intermediate model all have nominal
value (i.e.,
(i e 1.0)
1 0) except
Requires S/W Reliability = 1.15
Storage Constraint = 1.21
1 21
Execution Time Constraints = 1.10
Software Tools = 1.10.

E
Exemple:
l
The intermediate COCOMO model thus gives an estimate:
pm = 45*1.15*1.21*1.10*1.10 = 76 person months
Assume the average cost per software engineer is $7000 per pm, the cost is:
cost = 76*7000 = $532,000.

Suppose 1:
The intermediate COCOMO model thus gives an estimate:
pm = 45*1.15*1.21*1.10*1.10 = 76 person months
Assume the average cost per software engineer is $7000 per pm, the cost is:
cost = 76*7000 = $532,000.

Suppose
pp
1:
If an upgrade of the workstation was available with twice the processor
speed and twice the memory
memory, the new effort multipliers are:
Requires S/W Reliability = 1.15
Storage
S
o ge Co
Constraint
s
=1
Execution Time Constraints = 1
Software Tools = 1.24
(Requires additional hardware interfaces to be developed at a cost of
$30,000 and reduced the s/w tools attribute from low to very low (new
value 1.24).

Suppose
pp
1:
The predicted cost is now:
cost = 45*1.24*1.15*7000 = $449,190.
We get a predicted cost saving of about $90,000 for an expenditure of
$ ,
$30,000!!!
!!!
Conclusion: it is worth upgrading the hardware.