Chapter 23

Software Cost Estimation

Predicting the resources required for a
software development process

©IS&JCH050420 Software Engineering. Chapter 23 Slide 0 of 57

Factors affecting productivity
 Individual ability - most important factor
 Application domain experience
 Process quality
 Project size
 Technology support
 Working environment

©IS&JCH050420 Software Engineering. Chapter 23 Slide 1 of 57

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 meaningful

©IS&JCH050420 Software Engineering. Chapter 23 Slide 2 of 57

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 people in 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

©IS&JCH050420 Software Engineering. Chapter 23 Slide 3 of 57

Estimation techniques
 Algorithmic cost modelling
 Expert judgement
 Estimation by analogy
 Parkinson's Law
 Pricing to win

©IS&JCH050420 Software Engineering. Chapter 23 Slide 4 of 57

Algorithmic code modelling
 A formulaic approach based on historical cost
information and which is generally based on the size
of the software
 Discussed later in this chapter
 A model based on historical cost information that
relates Some software metrics to the project cost is
used. An estimate is made of that metrics and model
predicts the effort required.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 5 of 57

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!
Several experts on proposed software development techniques and
application domain are consulted. They each estimate the project
cost. These estimates are compared and discussed. The estimation
process iterate until an agreed estimate is reached.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 6 of 57

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

©IS&JCH050420 Software Engineering. Chapter 23 Slide 7 of 57

Parkinson's Law
 Parkinson's Law states that work expand to fill
the time available. The cost is determined by
available recourses rather than by objectives
assessment. If the software has to be delivered in
12 months and 5 people are available, the effort
required is estimated to be 60 person-months.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 8 of 57

Pricing to Win
 The software cost is estimated to be whatever the
customer has available to spend on project. The
estimated effort depends on the customer’s budget
and not on the software functionality.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 9 of 57

Estimation methods
 Each method has strengths and weaknesses
 Estimation should be based on several methods
 If these do not return approximately the same result,
there is insufficient information available
 Some action should be taken to find out more in order
to make more accurate estimates
 Pricing to win is sometimes the only applicable
method

©IS&JCH050420 Software Engineering. Chapter 23 Slide 10 of 57

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

©IS&JCH050420 Software Engineering. Chapter 23 Slide 11 of 57

Top-down estimation
 Usable 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

©IS&JCH050420 Software Engineering. Chapter 23 Slide 12 of 57

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

©IS&JCH050420 Software Engineering. Chapter 23 Slide 13 of 57

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
• Off the shelf components
• Component-based software engineering
• CASE tools and program generators

©IS&JCH050420 Software Engineering. Chapter 23 Slide 14 of 57

Estimation accuracy
 The size of a software system can only be known
accurately when it is finished.
 Several factors influence the final size
• Use of COTS and components
• Programming language
• Distribution of system
 As the development process progresses, the size
estimate becomes more accurate.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 15 of 57

Estimate uncertainty
4x

2x

x Code
Feasibility Requirements Design Delivery

0.5x

0.25x

©IS&JCH050420 Software Engineering. Chapter 23 Slide 16 of 57

The COCOMO 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 II
 COCOMO II takes into account different approaches
to software development, reuse, etc.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 17 of 57

Algorithmic cost modelling
 Cost is estimated as a mathematical function of estimated value
of product, project and process attributes.
• Effort = A  SizeB  M
• A is an organisation-dependent constant, B reflects the disproportionate
effort for large projects and M is a multiplier reflecting product, process
and people attributes

 Most commonly used product attribute for cost estimation is

code size
 Most models are basically similar but with different values for
A, B and M

©IS&JCH050420 Software Engineering. Chapter 23 Slide 18 of 57

COCOMO 81
Project Formula Description
complexity
Simp le PM = 2 .4 (KDSI)1.05  M Well-understood applications
developed by small teams.
Moderate PM = 3 .0 (KDSI)1.12  M More complex projects where
team members may have limited
experience of related systems.
Embedded PM = 3 .6 (KDSI)1.20  M Complex projects where the
software is part of a strongly
coupled complex of hardware,
software, regulations and
operational procedures.

©IS&JCH050420 Software Engineering. Chapter 23 Slide 19 of 57

COCOMO effort and schedule equation

©IS&JCH050420 Software Engineering. Chapter 23 Slide 20 of 57

How to select mode for estimation

©IS&JCH050420 Software Engineering. Chapter 23 Slide 21 of 57

Cost Drivers

©IS&JCH050420 Software Engineering. Chapter 23 Slide 22 of 57