Software Cost Estimation
COMP 3663
D. L. Silver, Ph.D.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 1
Software Cost Estimation
 Predicting the resources
required for a software
development process
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 2
Topics covered





Feasibility Analysis
Productivity measures
Estimation techniques
Algorithmic cost modelling
Project duration
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 3
Feasibility Analysis
Feasibility – the measure of how beneficial or
practical an information system will be to an
organization.
Feasibility analysis – the process by which
feasibility is measured.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 4
Three Tests For Feasibility
Technical feasibility – a measure of the practicality
of a technical solution and the availability of
technical resources and expertise.
Economic feasibility - a measure of the costeffectiveness of a project or solution.
Operational feasibility – a measure of how well a
solution will work or be accepted in an
organization.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 5
Economic Feasibilty =
Cost-Benefit Analysis
Costs:
 Development costs are one time costs that will not recur
after the project has been completed.
 Operating costs are costs that tend to recur throughout the
lifetime of the system. Such costs can be classified as:
 Fixed costs — occur at regular intervals but at relatively fixed rates.
 Variable costs — occur in proportion to some usage factor.
Benefits:
 Tangible benefits are those that can be easily quantified.
 Intangible benefits are those benefits believed to be
difficult or impossible to quantify.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 6
Three Popular Techniques to
Assess Economic Feasibility
 Payback Analysis
 Return On Investment
 Net Present Value
The Time Value of Money is a concept that should be
applied to each technique. The time value of money
recognizes that a dollar today is worth more than a
dollar one year from now.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 7
Software cost components
 Hardware and software costs
 Travel and training costs
 Personnel costs (the dominant factor in most
projects)


salaries of people involved in the project
benefits and insurance costs
 Must also take project overhead into account



costs of building, heating, lighting
costs of networking and communications
costs of shared facilities (e.g library, staff restaurant, etc.)
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 8
Costs for a Proposed System
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 9
Fundamental estimation questions
 How much effort is required to complete an
activity?
 How much calendar time is needed to complete
an activity?
 What is the total cost of an activity?
 Project estimation and scheduling are interleaved
management activities
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 10
Costing and pricing
 Estimates are made to discover the cost, to the
developer, of producing a software system
 There is not a simple relationship between the
development cost and the price charged to the
customer
 Broader organisational, economic, political and
business considerations influence the price
charged
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 11
Productivity measures
 Size related measures based on some output from
the software process. This may be lines of
delivered source code, object code instructions,
etc.
 Function-related measures based on an estimate
of the functionality of the delivered software.
Function-points are the best known of this type of
measure
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 12
Lines of code
 What is a line of code?
 Productivity measures will vary from language to
language – consider difference between lines of
code in assembler versus Java
 Relationship to functionality must be based on
past efforts in the same language
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 14
Productivity estimates - LOC
System Category
LOC/person-month
Real-time embedded systems
40-160
Systems programs
150-400
Commercial applications
200-800
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 15
Productivity estimates –
Function points
 Based on a combination of program
characteristics




external inputs and outputs
user interactions
external interfaces
files used by the system
 A weight is associated with each of these
 The function point count is computed by
multiplying each raw count by the weight and
summing all values
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 16
Function points


Function point count modified by complexity of the
project
FPs can be used to estimate LOC depending on the
average number of LOC per FP for a given language



LOC = AVC * number of function points
AVC is a language-dependent factor varying from 200-300 for
assemble language to 2-40 for a high-level languages
FPs are very subjective. They depend on the estimator.

Automatic function-point counting is impossible
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 17
Factors affecting productivity
Factor
Application domain
experience
Process quality
Project size
Technology support
Working environment
Description
Knowledge of the application domain is essential for
effective software development. Engineers who already
understand a domain are likely to be the most
productive.
The development process used can have a significant
effect on productivity. This is covered in Chapter 31.
The larger a project, the more time required for team
communications. Less time is available for
development so individual productivity is reduced.
Good support technology such as CASE tools,
supportive configuration management systems, etc.
can improve productivity.
As discussed in Chapter 28, a quiet working
environment with private work areas contributes to
improved productivity.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 18
Quality and productivity
 All metrics based on volume/unit time are
flawed because they do not take quality into
account
 Productivity may generally be increased at the
cost of quality
 It is not clear how productivity/quality metrics
are related
 If change is constant then an approach based on
counting lines of code is not as meaningful
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 19
Estimation techniques
 There is no simple way to make an accurate
estimate of the effort required to develop a
software system



Initial estimates are based on inadequate information in a user
requirements definition
The software may run on unfamiliar computers or use new
technology
The skills of people working on the project may be unknown
 Project cost estimates may be self-fulfilling

The estimate defines the budget and the product is adjusted to
meet the budget
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 20
Estimation techniques





Expert judgement
Estimation by analogy
Parkinson's Law
Pricing to win
Algorithmic cost modelling
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 21
Expert judgement
 One or more experts in both software
development and the application domain use
their experience to predict software costs.
Process iterates until some consensus is
reached.
 Advantages: Relatively cheap estimation
method. Can be accurate if experts have direct
experience of similar systems
 Disadvantages: Very inaccurate if there are no
experts!
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 22
Estimation by analogy
 The cost of a project is computed by comparing
the project to a similar project in the same
application domain
 Advantages: Accurate if project data available
 Disadvantages: Impossible if no comparable
project has been tackled. Needs systematically
maintained cost database
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 23
Parkinson's Law
 The project costs whatever resources are
available (typically used within an organization)
 Advantages: No overspend
 Disadvantages: System is usually left unfinished
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 24
Pricing to win
 The project costs whatever the customer has to
spend on it
 Advantages: You get the contract
 Disadvantages: Costs do not accurately reflect the
work required. Either:


The customer does not get the desired system, or
The customer overpays.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 25
Pricing to win
 This approach may seem unethical and
unbusiness-like
 However, when detailed information is lacking it
may be the only appropriate strategy
 The most ethical approach:


The project cost is agreed on the basis of an outline proposal and
the development is constrained by that cost
A detailed specification may be negotiated or an evolutionary
approach used for system development
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 26
Top-down and bottom-up estimation
 Any of these approaches may be used top-down
or bottom-up
 Top-down

Start at the system level and assess the overall system
functionality and how this is delivered through sub-systems
 Bottom-up

Start at the component level and estimate the effort required for
each component. Add these efforts to reach a final estimate
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 27
Top-down estimation
 Can be used without knowledge of the system
architecture and the components that might be
part of the system
 Takes into account costs such as integration,
configuration management and documentation
 Can underestimate the cost of solving difficult
low-level technical problems
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 28
Bottom-up estimation
 Usable when the architecture of the system is
known and components identified
 Accurate method if the system has been designed
in detail
 May underestimate costs of system level activities
such as integration and documentation
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 29
Estimation methods
 Each method has strengths and weaknesses
 Estimation should be based on several methods
 If these do not return approximately the same
result and the differences cannot be reconciled,
there is insufficient information available
 Some action should be taken to find out more in
order to make more accurate estimates
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 30
Experience-based estimates
 Estimating is primarily experience-based
 However, new methods and technologies may
make estimating based on experience inaccurate





Object-oriented rather than function-oriented development
Client-server systems rather than mainframe systems
Many off-the-shelf components
Component-based software engineering
Use of new CASE tools and program generators
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 31
Algorithmic cost modelling
 A formulaic approach based on historical cost
information and which is generally based on the
size of the software
 Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 32
Algorithmic cost modelling
 Effort in PM = A ´ SizeB ´ M

A is depends in on the type of software that is being
developed (simple, moderate, embedded) [will vary 2.43.5]

Size is an estimate of the code size or other functional
assessmemt [thousands of lines of code, ie. 5,400 LOC
5.4]

B reflects the disproportionate effort for large projects over
small projects [typically 1.0-1.5]

M is a multiplier reflecting a combination of product,
process and people attributes (e.g. desired reliability, reuse
required, personnel capability and expereince, support
facilities) [will vary up from 1.0]
PM = person months
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 33
Estimate uncertainty
Estimate uncertainty:
As the project progresses
the probablilty of a difference in
actual to estimate decreases
4x
2x
Actual
personmonths
x
Feasibility Requirements
Design
Code
Delivery
0.5x
0.25x
x = estimated person-months
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 35
COCOMO






Constructive Cost Model
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
COCOMO 2 takes into account different approaches to
software development, reuse, etc.
Can be used as a sanity check
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 36
COCOMO 81
Effort (PM) = A * SizeB * M
Description
Formula
Project
complexity
Simple
PM = 2.4 (KDSI)1.05 ´ M
Moderate
PM = 3.0 (KDSI)1.12 ´ M
Embedded
PM = 3.6 (KDSI)1.20 ´ M
Well-understood applications
developed by small teams.
More complex projects where
team members may have limited
experience of related systems.
Complex projects where the
software is part of a strongly
coupled complex of hardware,
software, regulations and
operational procedures.
PM = person-months
KDSI = thousand of delivered software instructions
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 37
Basic COCOMO Formulae (Boehm)
Effort in Person-months = aKLOC b
Duration in Months = c Effort d
Where c = labour estimate, d = complexity of project type
These values are selected from a table such as the one below.
Software Project
a
b
c
d
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
(See page 105 of text)
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Due to Boehm [Bo]
Slide 38
Computing COCOMO Case Study Models
a
K
b
2.4
2.4
4.2 1.05
300 1.05
c
P
Effort
LO
HI
d
Duration
LO
HI
2.5
10 0.38
2.5 1000 0.38
Portions
from
slides by An
IanObject-Oriented
Sommerville,Perspective
Softwareby
Engineering,
edition.
23
Adapted from
Software
Engineering:
Eric J. Braude6th
(Wiley
2001),Chapter
with permission.
approx.
aK^b
10
1000
approx.
cP^d
6
35
Slide 39
Workshop





Estimate Actual
80 60 , 1 error
52.5 44 , 1 error??
70 50 , 100% correct
37.5 45 , 1 error
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23
Slide 40