Chapter 6

Software Cost Estimation&

Process Improvement

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1

Software cost estimation

 Predicting the resources required

for a software development
process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 2

Objectives
 To introduce the fundamentals of software
costing and pricing
 To describe three metrics for software
productivity assessment
 To explain why different techniques should be
used for software estimation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 3

Topics covered
 Productivity
 Estimation techniques
 Algorithmic cost modelling
 Project duration and staffing

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 4

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 and
interleaved management activities

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 5

Software cost components
 Hardware and software costs
 Travel and training costs
 Effort costs (the dominant factor in most
projects)
• salaries of engineers involved in the project
• Social and insurance costs
 Effort costs must take overheads into account
• costs of building, heating, lighting
• costs of networking and communications
• costs of shared facilities (e.g library, staff restaurant, etc.)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 6

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 7

Software pricing factors

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 8

Measurement problems
 Estimating the size of the measure
 Estimating the total number of programmer
months which have elapsed
 Estimating contractor productivity (e.g.
documentation team) and incorporating this
estimate in overall estimate

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 9

Lines of code ( LOC)
 What's a line of code?
• The measure was first proposed when programs were typed on
cards with one line per card
• How does this correspond to statements as in Java which can
span several lines or where there can be several statements on
one line
 What programs should be counted as part of the
system?
 Assumes linear relationship between system
size and volume of documentation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 10

 Productivity comparisons
 The lower level the language, the more
productive the programmer
• The same functionality takes more code to implement in a
lower-level language than in a high-level language.
 The more verbose the programmer, the higher
the productivity
• Measures of productivity based on lines of code suggest that
programmers who write verbose code are more productive than
programmers who write compact code.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 11

High and low level languages

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 12

System development times

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 13

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 14

Object points
 Object points are an alternative function-related
measure to function points when 4Gls or similar
languages are used for development
 Object points are NOT the same as object
classes
 The number of object points in a program is a
weighted estimate of
• The number of separate screens that are displayed
• The number of reports that are produced by the system
• The number of 3GL modules that must be developed to
supplement the 4GL code
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 15
Productivity estimates
 Real-time embedded systems, 40-160
LOC/P-month
 Systems programs , 150-400 LOC/P-month
 Commercial applications, 200-800
LOC/P-month
 In object points, productivity has been measured
between 4 and 50 object points/month
depending on tool support and developer
capability

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 16

Factors affecting productivity

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 17

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 18

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 19

Estimation techniques
 Algorithmic cost modelling
 Expert judgement
 Estimation by analogy
 Pricing to win

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 20

Algorithmic code modelling
 A formulaic approach based on historical cost
information and which is generally based on the
size of the software

©Ian Sommerville 2000 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!
©Ian Sommerville 2000 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 23

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 24

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 25

Pricing to win
 This approach may seem unethical and
unbusinesslike
 However, when detailed information is lacking it
may be the only appropriate strategy
 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 26
Algorithmic cost modelling
 Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers
• 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 27
Project planning
 Algorithmic cost models provide a basis for
project planning as they allow alternative
strategies to be compared
 Embedded spacecraft system
• Must be reliable
• Must minimise weight (number of chips)
• Multipliers on reliability and computer constraints > 1
 Cost components
• Target hardware
• Development platform
• Effort required

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 28

Management options

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 29

Management options costs

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 30

Staffing requirements
 Staff required can’t be computed by diving the
development time by the required schedule
 The number of people working on a project
varies depending on the phase of the project
 The more people who work on the project, the
more total effort is usually required
 A very rapid build-up of people often correlates
with schedule slippage

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 31

 Process Improvement

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 32

Process Improvement

 Understanding, Modelling
and Improving the Software
Process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 33

Objectives
 To explain the principles of software process
improvement
 To explain how software process factors
influence software quality and productivity
 To introduce the SEI Capability Maturity Model
and to explain why it is influential. To discuss
the applicability of that model
 To explain why CMM-based improvement is not
universally applicable

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 34

Topics covered
 Process and product quality
 Process analysis and modelling
 Process measurement
 The SEI process maturity model
 Process classification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 35

Process improvement
 Understanding existing processes
 Introducing process changes to achieve
organisational objectives which are usually
focused on quality improvement, cost reduction
and schedule acceleration
 Most process improvement work so far has
focused on defect reduction. This reflects the
increasing attention paid by industry to quality
 However, other process attributes can be the
focus of improvement
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 36
Process attributes

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 37

Process improvement stages
 Process analysis
• Model and analyse (quantitatively if possible) existing
processes
 Improvement identification
• Identify quality, cost or schedule bottlenecks
 Process change introduction
• Modify the process to remove identified bottlenecks
 Process change training
• Train staff involved in new process proposals
 Change tuning
• Evolve and improve process improvements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 38

The process improvement process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 39

Process and product quality
 Process quality and product quality are closely
related
 A good process is usually required to produce a
good product
 For manufactured goods, process is the
principal quality determinant
 For design-based activity, other factors are also
involved especially the capabilities of the
designers

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 40

Principal product quality factors

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 41

Quality factors
 For large projects with ‘average’ capabilities, the
development process determines product quality
 For small projects, the capabilities of the
developers is the main determinant
 The development technology is particularly
significant for small projects
 In all cases, if an unrealistic schedule is imposed
then product quality will suffer

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 42

The module testing activity

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 43

Activities in module testing

©Ian ©Ian Sommerville

Sommerville 2000 1995 Software
Software Engineering,
Engineering, 5th edition.
6th edition. Chapter
Chapter 23 31. SlideSlide
44 ##
Goal-Question-Metric Paradigm
 Goals
• What is the organisation trying to achieve? The objective of
process improvement is to satisfy these goals
 Questions
• Questions about areas of uncertainty related to the goals. You
need process knowledge to derive these
 Metrics
• Measurements to be collected to answer the questions

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 45

The SEI process maturity model

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 46

Maturity model levels
 Initial
• Essentially uncontrolled
 Repeatable
• Product management procedures defined and used
 Defined
• Process management procedures and strategies defined
and used
 Managed
• Quality management strategies defined and used
 Optimising
• Process improvement strategies defined and used
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 47
Key process areas

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 48

Process classification
 Informal
• No detailed process model. Development team chose their
own way of working
 Managed
• Defined process model which drives the development
process
 Methodical
• Processes supported by some development method such
as HOOD
 Supported
• Processes supported by automated CASE tools

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 49

Process applicability

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 50

Process choice
 Process used should depend on type of
product which is being developed
• For large systems, management is usually the principal problem
so you need a strictly managed process. For smaller systems,
more informality is possible.
 There is no uniformly applicable process which
should be standardised within an organisation
• High costs may be incurred if you force an inappropriate
process on a development team

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 51

Process tool support

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 52

 Key points
 Process improvement involves process analysis,
standardisation, measurement and change
 Process models include descriptions of tasks,
activities, roles, exceptions, communications,
deliverables and other processes
 Measurement should be used to answer specific
questions about the software process used
 The three types of process metrics which can be
collected are time metrics, resource utilisation
metrics and event metrics

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 53

 Key points
 The SEI model classifies software processes as
initial, repeatable, defined, managed and optimising.
It identifies key processes which should be used at
each of these levels
 The SEI model is appropriate for large systems
developed by large teams of engineers. It cannot be
applied without modification in other situations
 Processes can be classified as informal, managed,
methodical and improving. This classification can be
used to identify process tool support

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 54