Chapter 26

 Estimation for Software Projects

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 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!

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2
 Estimation of cost ,resources and schedule for
a software engineering effort requires
experience ,access to good historical
information
 Factors that affect project estimation
 Project complexity :it has a strong effect on the
uncertainty inherent in planning.
 Project size: can effect the accuracy and
efficiency of estimates. As size increases
,interdependency between various elements of
software grows and decomposition too
becomes difficult. 3
 The degree of structural uncertainty refers to
the degree to which the requirements are
frozen .

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4
Software scope and feasibility

project scope: Comprises of functions and

features that are to be delivered to the end
users,data input and output ,content presented
to the user ,performance ,constrints interfaces
etc.
Scope is defined using two techniques:
1.A narrative description of software scope is
developed after communication with all
stakeholders.
2.A set of use cases developed by the end users
 Determine feasibility

5
Resources
 Define required resources
 Determine require human resources
 The planner begins by evaluating the software scope
and selecting the skills required to complete
development.
 Both organizational position (manager ,senior
software engineer) and specialty
(telecommunications ,database ,client server) are
specified.
 The number of people required for a software project
can be determined only after an estimate of
development effort

6
Define reusable software resources
 Four software resource categories
 Off the shelf components: Existing software that can
be acquired form third party
 Full experience components: Existing specifications,
designs ,code or test data developed for past
projects that are similar to the software to be built
 Partial experience components: Existing
specifications ,designs, code or test data developed
for past projects that are related to the software to be
built but requires substantial modification.
 New components: Software components must be
built by the software team specifically for the needs
of the current project.

7
Environmental Resources
 Often called the software engineering
environment(SEE) incorporates hardware and
software .
 Hardware provides a platform that supports
tools required to produce the work products.

8
Resources
number software
tools
skills hardware

people
environment network
location resources

project

reusable
OTS
software
new
components components

full-experience part.-experience
components components

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9
Software project estimation
 To achieve reliable cost and effort estimates a
number options arise
 1.Delay estimation until late in the project
 2.base the estimates on similar projects
developed in the past
 3.Use relatively simple decomposition
techniques to generate project cost and effort
estimates
 4.use one or more empirical models for
software cost and effort estimation

10
Decomposition Techniques
 1.Software sizing
 The accuracy of a software project estimate is
predicted on a number of things
 1 the degree to which you have properly
estimated the size of the product to be built
 2.the ability to translate the size estimate into
human effort ,calendar time ,and dollars
 3.The degree to which project plan reflects the
abilities of the software team
 4.Stablity of requirements an software
environment
11
 Size is measured directly by loc and indirectly
by FP
 There are four approaches to sizing problem
 Fuzzy logic sizing :This approach uses
approximate reasoning techniques
 Function point sizing:
 Standard component sizing: Size determined
based on the number of software components
and their size
 Change sizing: used when the project
encompasses existing software that must be
modified in some way as a part of the project. 12
Problem based estimation
 Loc and FP are used in two ways during
software project estimation
 1.as estimation variables to size each element
of the software
2.as baseline metrics collected from the past
projects and used in conjunction with
estimation variables to develop cost and effort
projections.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13
Functional Decomposition

Statement functional
of decomposition
Scope
Perform a
Grammatical “parse”

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 14
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 Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15
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.
16
Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total * [0.65 + 0.01 *CAV)].where CAV is
computed form factors as 1.17
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.
17
Process-Based Estimation
Obtained from “process framework”

framework activities

application Effort required to

functions accomplish
each framework
activity for each
application function

18
Process-Based Estimation Example
Activity Risk Construction
CC Planning Analysis Engineering Release CE Totals
Task analysis design code test

Function

UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DSM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

% effort 1% 1% 1% 8% 45% 10% 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.
19
Estimation with Use-Cases
 Estimation with use cases has many problems:
 Use cases are described using many formats
and styles
 Use cases represent external view of the
software
 Use cases do not address the complexity of the
functions and features
 Use cases can describe complex behaviour

20
Estimation with Use-Cases
use cases scenarios pages Ź scenarios pages LOC LOC estimate
e subsystem
User interface subsystem 6 10 6 Ź 12 5 560 3,366
Engineering subsystem
subsystem group group 10 20 8 Ź 16 8 3100 31,233
Infrastructure subsystem
e subsystem group group5 6 5 Ź 10 6 1650 7,970
TotalLOC estimate Ź Ź Ź Ź
stimate Ź Ź Ź Ź 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 use-
case estimate and the historical productivity data, the total
estimated project cost is $552,000 and the estimated effort is
68 person-months.

21
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22
Introduction
 Constructive Cost Model was developed by
Boehm .
 This model estimates the total effort in terms
of person months.
 Cocomo model is commonly used because it is
based on the study of already developed
projects.
 In this model the size is measured in terms of
thousands of delivered lines of code (KDLOC).
Person months
If a project will take 2 months to finish with 3
people working full time on it, the project
requires 2*3 = 6 person-month effort.
If an employee worked 20 days on a project,
his contribution to the project is 1*20/30 =
0.6666 person-month. (Note that month is
considered 30 days in such calculations.)
Three categories
 Cocomo model divides the projects into three
categories.
1) Organic projects :These projects are small in
size and thus easy to develop. In organic
projects small teams with prior experience
work together to accomplish user
requirements which are less demanding.
Examples : Inventory management system,
Payroll management system
Three categories
2) Embedded projects
 These projects are complex in nature
and organizations have less experience in
developing such type of projects.
 These projects are developed under tight
constraints (hardware ,software and people.)
Examples
software systems used in avionics and military
hardware.
Three categories
3) Semi detached projects
 These projects are less complex as user
requirements are less stringent compared to embedded
projects.
 The size of semi-detached project is not more than 300
KDLOC
Examples
 Operating system
 Compiler design
 Database design

Introduction
The objectives of COCOMO II where

“to develop support capabilities for continuous model

improvement and provide a quantitative analytic

frame work , set of tools and techniques for

evaluating the effects of s/w technology

improvements on s/w development life cycle costs”

Four Estimation Model
Prototype systems
Number of Based on Application Used for developed using
Object points composition model
scripting, DB
prog ramming etc.

Based on Used for Initial effor t

Number of function estimation based on
Early design model
points system requirements
and design options

Number of lines of Based on Used for Effor t to integ rate

code reused or Reuse model reusable components
generated or automatically
generated code

Based on Used for Development effor t

Number of lines of Post-architecture
based on system
source code model
design specification
Application Composition
Model
 In this model projects are developed using prototyping

and existing software components.

 The model requires size as the input that is estimated in

terms of object points

 Object point considers complexity of screens , reports,

and third generation language components.

Application Composition
Model
Estimation method
1. Assess object counts: the number of screens (views and
sources), reports ( sections and sources) and 3GL components are
estimated.
2. Classification of complexity levels: each object instance
classified in to simple medium and difficult complexity levels.
3. Assigning complexity weight to each:
4. Determine object points: by adding all the numeric values for
each object instances.
5. Compute new object points: NOP = [object points x (100-%
reuse) ] X 100
6. Calculates productivity rate (PROD) : = NOP/Effort
7. Calculate effort: Effort =NOP/PROD

Early Design Model
The early design model is used for estimating cost once
the user requirements are known and the initial stage of
software design is in process.
 Effort is based on certain assumptions , such that the
effort involved in integrating reusable code is zero.
 The effort estimate produced by this model is based on
the following equation Effort = A * (size )B*M
 Based on the study of various projects and information
available ,the value of constant A should be as 2.94
Early Design Model
 As the size of project increases the effort required to
develop the project also increases .The Exponent B
reflects this increase in effort .The value of B is not
constant and varies from 1.1 t0 1.24.The value of B
depends on five scaling factors
Early Design Model
Scale factors Description
Precedentedness Shows the experience of
organization in current software
project.

Development flexibility Specifies the degree of flexibility in

the development process.

Architecture /risk resolution Shows the extent of risk involved.

Process maturity Specifies the process maturity of the
organization.

Team cohesion Shows how well development teams

interact with each other and work
together,
Early Design Model

 These factors are rated on a six point scale that ranges

from very low to extra high (5 to 0) to derive the value of
B use the following equation.
 B= sum of scaling factors /100 +1.01
Early Design Model
 The third variable in the equation is M which depends on
seven cost drivers that influence the total effort required
for the project.
 Cost drivers used in the early design model are product
reliability and complexity (RCPX), reuse required
(RUSE), platform difficulty (PDIF), personnel capability
(PERS), personnel experience (PREX), support facilities
(FCIL) and schedule (SCED)
 To calculate M, all these cost drivers are multiplied with
each other .That is,
 M= PERS * RCPX*RUSE*PDIF*PREX*FCIL*SCED
Early Design Model
 These cost drivers are estimated on a six point scale (1
to 6) where 1 corresponds to very low value and 6
corresponds to very high value.

 To understand early design model consider an

application of size 20 KDLOC.
Early Design Model
SCALE FACTORS Rating

precedentedness 2
Development flexibility 1

Architecture /risk resolution 4

Team cohesion 2

Process maturity 5

Total 14
Early Design Model
Cost Drivers
Factors Rating
PERS 4

RCPX 3

RUSE 2
PDIF 5

FCIL 2

SCED 3

PREX 2
Total 1440
Early Design Model
 The value of B is calculated as B= 14/100 +1.01 =1.15
 Value of M is calculated by multiplying the rating of
seven factors M= 1440
 Effort can be calculated as follows

 Effort = 2.94 *(20)1.15 *1440 = 132707PM


The Reuse Model
The reuse model estimates the efforts required to
integrate reusable or generated code.
 In COCOMO II two types of reused code are considered.
 Black box code and white box code.
 The black box code is used without understanding or
changing the code.
 The white box code needs to be adapted in order to
integrate it with the new code ,thus more effort is
required to reuse the white box code.
The Reuse Model
 Many systems include automatically generated code ,
effort required to integrate this code is estimated by
using the equation
 Effort = (ALOC *AT/100)/ATPROD
 Where AT = percentage of adapted code that is
automatically generated
 ATPROD = Engineers productivity in integrating code
 ALOC = Number of LOC that have to be adapted in a
component.
The Reuse Model
 The value of ATPROD is approximately 2400 LOC per
month. For example if there are 30,000 lines of reused
code in a system out of which 40% are automatically
generated then the effort required to integrate this code
is calculated by using equation
 Effort = (30000*40/100)/2400 =5PM
The Reuse Model
 The reuse model is also used when a new code has to
be integrated with the reused white box code.
 For example if 30000 lines of code are to be reused , the
new equivalent size estimate might be 5000.
 Equivalent number of lines of code can be calculated
using the equation
 ELOC = ALOC *(1-AT/100)*AAM
The Reuse Model
 Where
 ELOC = equivalent number of lines of new lines of code
 AAM =adaptation adjustment factor
 ALOC = total reused code
 AT = % of code used as such
 Various factors considered while calculating ELOC are
 Effort required for understanding software
 Effort required for making changes to reuse code
 Effort required for making changes to system to integrate
reusable code
The Post-architecture Model
 Post architecture model is the most detailed model of
COCOMO II and is used to estimate effort once design of
the software is complete and subsystem structure is known.
In post architecture model the effort is calculated using the
equation
 Effort = A *(size)B *M
The Post-architecture Model
 In this model the estimate of the software size is computed
using the following three components
 Estimating total number of lines of code to be developed.
 Estimating ELOC , calculated in reuse model
 Estimating lines of codes which have to be modified as a
result of change in user requirements.
These three estimates are added to calculate the total size
in terms of KDLOC
The Post-architecture Model
 The value of constant A is 2.94
 The value of exponent B is based on five scale factors as
in early design model.
 Value of B is calculated using the equation B= sum of
scaling factors /100 +1.01
The Post-architecture Model
The multiplier M that influences the initial effort estimate is
divided into four classes
 Product Attributes :describe the characteristics of the
software product.
 Computer attributes :Describe the constraints imposed by
hardware on the software
 Personnel attributes : describe the experiences and
capabilities of the people involved in the software project.
 Project attributes :Describe the characteristics of the
software development project
The Post-architecture Model
The post architecture model uses a set of 17 cost drivers to
calculate M
The cost drivers are
51
The Post-architecture Model
Example:
Project size is 10 KDLOC
.The value of B is calculated using the equation
B= 16/100 +1.01 = 1.17

Value of M is calculated by multiplying the rating of seventeen

factors .All the cost drivers have a nominal value of 1.
Hence the Value of M is 1
effort = 2.94 * (10) 1.17 * 1 = 43 PM
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

53
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

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

55
The Make-Buy Decision
simple (0.30)
$380,000

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

minorchanges
minorchanges $210,000
contract (0.70)

$400,000
majorchanges(0.30)

without changes (0.60) $350,000

$500,000
with changes (0.40)

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