Chapter 33

 Estimation for Software Projects

Slide Set to accompany
Software Engineering: A Practitioner’s
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.

1
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!

2
Project Planning Task
Set-I
1. Establish project scope
2. Determine feasibility
3. Analyze risks
1. Risk analysis already discussed in
Project Management chapter.
4. Define required resources
1. Determine require human resources
2. Define reusable software resources
3. Identify environmental resources

3
Project Planning Task
Set-II
5. Estimate cost and effort
Decompose the problem
Develop two or more estimates using size,
size
function points, process tasks or use-cases
Reconcile the estimates

6. Develop a project schedule

Establish a meaningful task set

Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms
4
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

5
Write it Down!

Project Scope Software

Estimates Project
Risks Plan
Schedule
Control strategy

6
To Understand
Scope ...
 Understand the customers needs
 understand the business context
 understand the project boundaries
 understand the customer’s
motivation
 understand the likely paths for
change
 Even when
understand that you
... understand,
nothing is guaranteed!

7
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.

8
Resources

9
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

10
Estimation
Techniques
 Past (similar) project experience
 Conventional estimation
techniques
 task breakdown and effort estimates
 size (e.g., FP) estimates
 Empirical models
 Automated tools

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.

12
Functional
Decomposition
Statement functional
of decomposition
Scope
Perform a
Grammatical
“parse”

13
Conventional Methods:

1. LOC/FP Approach
 compute LOC/FP using estimates
of information domain values
 use historical data to build
estimates for the project

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. 15
2. FP Approach

 A Function Point (FP) is a unit of

measurement to express the amount
of business functionality, an
information system (as a product)
provides to a user.

 FPs measure software size. They are

widely accepted as an industry
standard for functional sizing.

16
Example: FP
Approach

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 17
∑fi =
52
18
 Process-Based
Estimation
Obtained from “process framework”

framework activities

application Effort required to

functions accomplish
each framework
activity for each
application
function

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 19
Process-Based Estimation
Example

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

month, the total estimated project cost is $368,000 and the 20
estimated effort is 46 person-months.
 Tool-Based
Estimation

project characteristics

calibration factors

LOC/FP data

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 21
Estimation with Use-
Cases

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 use-
case estimate and the historical productivity data, the total
estimated project cost is $552,000 and the estimated effort is
68 person-months.
22
Empirical Estimation
Models
General form:

exponent
effort = tuning coefficient * size

usually derived
as person-months empirically
of effort required derived

usually LOC but

may also be
function point
either a constant or
a number derived based
on complexity of project

23
 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
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 24
 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”
Pto =
These slides are designed “productivity
accompany Software Engineering: A parameter”
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 25
 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 Multiplier
 No GUI 2.0
 Text-based user interface 2.25
 GUI 2.5
 Complex GUI 3.0

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 26
 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

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 27
 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.”
 Alternatively, the ‘volume’ of the scenario can be
estimated in LOC, FP or some other volume-oriented
measure (e.g., use-case count).
 Estimates for each task are summed to create an
estimate for the scenario.
 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
These slides areincrement.
designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 28
The Make-Buy
Decision simple (0.30)
$380,000

$450,000
difficult (0.70)
build
$275,000
minor changes
(0.40)
reuse
system X $310,000
simple (0.20)
major
changes
buy (0.60) $490,000
complex (0.80)

minor changes $210,000

contract (0.70)

$400,000
major changes (0.30)

without changes (0.60) $350,000

$500,000
with changes (0.40)

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 29
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 = $382K

reuse
expected cost = $267K
buy
expected cost = $410K
contr
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 30