Chapter 26

Estimation for Software Projects

Slide Set to accompany

Software Engineering: A Practitioners Approach, 7/e

by Roger S. Pressman
Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only

May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Software Project Planning

The overall goal of project planning is to
establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical
project.
Why?
So the end result gets done on time, with quality!

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Project Planning Task Set-I

Establish project scope

Determine feasibility
Analyze risks

Risk analysis is considered in detail in Chapter 25.

Define required resources

Determine require human resources

Define reusable software resources
Identify environmental resources

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Project Planning Task Set-II

Estimate cost and effort

Decompose the problem

Develop two or more estimates using size, function
points, process tasks or use-cases
Reconcile the estimates

Develop a project schedule

Scheduling is considered in detail in Chapter 27.

Establish a meaningful task set

Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Estimation

Estimation of resources, cost, and schedule for

a software engineering effort requires

experience
access to good historical information (metrics)
the courage to commit to quantitative predictions
when qualitative information is all that exists

Estimation carries inherent risk and this risk

leads to uncertainty

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Write it Down!
Project Scope
Estimates
Risks
Schedule
Control strategy

Software
Project
Plan

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

To Understand Scope ...

Understand the customers needs

understand the business context
understand the project boundaries
understand the customers motivation
understand the likely paths for change
understand that ...
Even when you understand,
nothing is guaranteed!

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

What is Scope?

Software scope describes

the functions and features that are to be delivered to

end-users
the data that are input and output
the content that is presented to users as a
consequence of using the software
the performance, constraints, interfaces, and
reliability that bound the system.

Scope is defined using one of two techniques:

A narrative description of software scope is developed

after communication with all stakeholders.
A set of use-cases is developed by end-users.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Resources
number

software
tools

skills

hardware

people

environment

location

network
resources

project

OTS
components

reusable
software

full-experience
components

new
components

part.-experience
components

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Project Estimation

Project scope must be

understood
Elaboration (decomposition) is
necessary
Historical metrics are very helpful
At least two different techniques
should be used
Uncertainty is inherent in the
process

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

10

Estimation Techniques

Past (similar) project experience

Conventional estimation techniques

task breakdown and effort estimates

size (e.g., FP) estimates

Empirical models
Automated tools

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

11

Estimation Accuracy

Predicated on

the degree to which the planner has properly

estimated the size of the product to be built
the ability to translate the size estimate into human
effort, calendar time, and dollars (a function of the
availability of reliable software metrics from past
projects)
the degree to which the project plan reflects the
abilities of the software team
the stability of product requirements and the
environment that supports the software engineering
effort.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

12

Functional Decomposition
Statement
of
Scope

functional
decomposition
Perform a
Grammatical parse

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

13

Conventional Methods:
LOC/FP Approach

compute LOC/FP using estimates of

information domain values
use historical data to build estimates for
the project

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

14

Example: LOC Approach

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of
code is approximately $13.
Based on the LOC estimate and the historical productivity
data, the total estimated project cost is $431,000 and the
estimated effort is 54 person-months.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

15

Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated
project cost is $461,000 and estimated effort is 58 person-months.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

16

Process-Based Estimation
Obtained from process framework
framework activities
application
functions

Effort required to
accomplish
each framework
activity for each
application function

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

17

Process-Based Estimation Example

Activity

CC

Planning

Risk
Analysis

Task

Engineering

Construction
Release

analysis

design

code

test

0.50
0.75
0.50
0.50
0.50
0.25
0.50

2.50
4.00
4.00
3.00
3.00
2.00
2.00

0.40
0.60
1.00
1.00
0.75
0.50
0.50

5.00
2.00
3.00
1.50
1.50
1.50
2.00

4.50

16.50

CE

Totals

n/a
n/a
n/a
n/a
n/a
n/a
n/a

8.40
7.35
8.50
6.00
5.75
4.25
5.00

Function
UICF
2DGA
3DGA
CGDF
DSM
PCF
DAM
Totals

0.25

0.25

0.25

3.50

20.50

% effort

1%

1%

1%

8%

45%

10%

46.00

36%

CC = customer communication CE = customer evaluation

Based on an average burdened labor rate of $8,000 per

month, the total estimated project cost is $368,000 and the
estimated effort is 46 person-months.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

18

Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

19

Estimation with Use-Cases

use cases scenarios pages
e subsystem
6
10
6
User interface
subsystem
Engineering
subsystemgroup
group
subsystem
10
20
8
Infrastructure
subsystem
group
e subsystem group
5
6
5
Total LOC estimate
stimate

scenarios pages LOC LOC estimate

12
5
560
3,366

16
8
3100
31,233

10
6
1650
7,970

42,568

Using 620 LOC/pm as the average productivity for systems of

this type and a burdened labor rate of $8000 per month, the
cost per line of code is approximately $13. Based on the usecase estimate and the historical productivity data, the total
estimated project cost is $552,000 and the estimated effort is
68 person-months.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

20

Empirical Estimation Models

General form:
exponent
effort = tuning coefficient * size

usually derived
as person-months
of effort required

either a constant or
a number derived based
on complexity of project

empirically
derived
usually LOC but
may also be
function point

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

21

COCOMO-II

COCOMO II is actually a hierarchy of

estimation models that address the following
areas:
Application composition model. Used during the early
stages of software engineering, when prototyping of
user interfaces, consideration of software and system
interaction, assessment of performance, and evaluation
of technology maturity are paramount.
Early design stage model. Used once requirements
have been stabilized and basic software architecture
has been established.
Post-architecture-stage model. Used during the
construction of the software.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

22

The Software Equation

A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where

E = effort in person-months or person-years

t = project duration in months or years
B = special skills factor
P = productivity parameter

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

23

Estimation for OO Projects-I

Develop estimates using effort decomposition, FP analysis, and

any other method that is applicable for conventional
applications.
Using object-oriented requirements modeling (Chapter 6),
develop use-cases and determine a count.
From the analysis model, determine the number of key classes
(called analysis classes in Chapter 6).
Categorize the type of interface for the application and develop
a multiplier for support classes:

Interface type
No GUI
Text-based user interface
GUI
Complex GUI

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Multiplier
2.0
2.25
2.5
3.0

24

Estimation for OO Projects-II

Multiply the number of key classes (step 3) by the

multiplier to obtain an estimate for the number of support
classes.
Multiply the total number of classes (key + support) by
the average number of work-units per class. Lorenz and
Kidd suggest 15 to 20 person-days per class.
Cross check the class-based estimate by multiplying the
average number of work-units per use-case

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

25

Estimation for Agile Projects

Each user scenario (a mini-use-case) is considered separately

for estimation purposes.
The scenario is decomposed into the set of software
engineering tasks that will be required to develop it.
Each task is estimated separately. Note: estimation can be
based on historical data, an empirical model, or experience.

Estimates for each task are summed to create an estimate for

the scenario.

Alternatively, the volume of the scenario can be estimated in LOC,

FP or some other volume-oriented measure (e.g., use-case count).

Alternatively, the volume estimate for the scenario is translated into

effort using historical data.

The effort estimates for all scenarios that are to be implemented

for a given software increment are summed to develop the effort
estimate for the increment.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

26

The Make-Buy Decision

simple (0.30)

build

difficult (0.70)
minor changes
(0.40)

system X

reuse

buy

contract

major
changes
(0.60)

simple (0.20)

complex (0.80)
minor changes
(0.70)
major changes (0.30)

without changes (0.60)

with changes (0.40)

$380,000
$450,000
$275,000
$310,000
$490,000
$210,000
$400,000
$350,000
$500,000

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

27

Computing Expected Cost

expected cost =
(path probability) x (estimated path cost)
i
i
For example, the expected cost to build is:
expected cost
= 0.30 ($380K) + 0.70 ($450K)
build
= $429 K
similarly,
expected cost
expected cost
expected cost

= $382K
reuse
buy
contr

= $267K
= $410K

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

28