Lecture 4

COST ESTIMATION

1
Objectives
 To introduce the fundamentals of software costing and
pricing.
 To describe the principles of the COCOMO 2
algorithmic cost estimation model.

2
Topics covered
 Estimation techniques
 Algorithmic cost modeling

3
Fundamental Estimation Questions
How much effort is required to complete an activity?
* The effort required to complete each project activity.

How much calendar time is needed to complete an

activity?
* The time required to complete each activity.

What is the total cost of an activity?

* The total cost of each activity.

Project estimation and scheduling are interleaved

management activities.
4
Software Cost Components

Effort costs (the Effort costs must

Hardware and Travel and
dominant factor take overheads
software costs. training costs. in most projects) into account
• The price of • The traveling • The salaries of • Costs of
hardware and and training engineers building,
software used cost required to involved in the heating,
uphold the project; lighting.
knowledge • Social and • Costs of
required by the insurance costs. networking and
engineers communications
• Costs of shared
facilities (e.g
library, staff
restaurant,
etc.).

5
Why Estimates Software Cost?
 To discover the cost of producing software
 Charge to the customer
 Capital to start the project
 Value of the project
 Development cost & price charged -> Not a simple
relationship

6
Software pricing factors
Factor Description
Market •A development organisation may quote a low price because it wishes
opportunity to move into a new segment of the software market.
• Accepting a low profit on one project may give the opportunity of
more profit later.
•The experience gained may allow new products to be developed.
Cost estimate •If an organisation is unsure of its cost estimate, it may increase its
uncertainty price by some contingency over and above its normal profit.
Contractual •A customer may be willing to allow the developer to retain ownership
Term of the source code and reuse it in other projects.
•The price charged may then be less than if the software source code is
handed over to the customer.
Requirement •If the requirements are likely to change, an organisation may lower its
volatility price to win a contract.
•After the contract is awarded, high prices can be charged for changes
to the requirements.
Financial health •Developers in financial difficulty may lower their price to gain a
contract. 7
•It is better to make a smaller than normal profit or break even than to
go out of business.
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.

8
Estimation techniques

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

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

11
Bottom-up estimation
 Usable when the architecture of the system is
known and components identified.
 This can be an accurate method if the system has
been designed in detail.
 It may underestimate the costs of system level
activities such as integration and documentation.

12
“Pricing to win”
 This approach may seem unethical and un-
businesslike.
 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.

13
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 a constant factor that depends on local organizational practices and
the type of software that is developed. Size may be either an assessment
of the code size of the software or a functionality estimate expressed in
function or object points. The value of exponent B usually lies between 1
and 1.5. M is a multiplier made by combining process, product and
development attributes, such as the dependability requirements for the
software and the experience of the development team.

 The most commonly used product attribute for cost

estimation is code size.
 Most models are similar but they use different
values for A, B and M. 14
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 then the size estimate
becomes more accurate.

15
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 2.
 COCOMO 2 takes into account different approaches
to software development, reuse, etc.

16
COCOMO 2
 COCOMO 81 was developed with the assumption that
a waterfall process would be used and that all
software would be developed from scratch.
 Since its formulation, there have been many
changes in software engineering practice and
COCOMO 2 is designed to accommodate different
approaches to software development.

17
COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is
composed from existing parts.
 Early design model. Used when requirements are available
but design has not yet started.
 Reuse model. Used to compute the effort of integrating
reusable components.
 Post-architecture model. Used once the system
architecture has been designed and more information
about the system is available.

18
Use of COCOMO 2 models

19
Key Points
 Different techniques of cost estimation should be used when
estimating costs.
 Five principles estimation techniques such as Algorithmic cost
modeling, Expert judgment, Estimation by analogy, Parkinson's
Law and Pricing to win.
 The sub-models that are part of the COCOMO II model are
Application composition model, Early design model, Reuse
model and Post-architecture model.

20
End of Lecture 4
Cost Estimation

Next on Lecture 5
Requirement and Specification