MIRPUR UNIVERSITY OF SCIENCE AND TECHNOLOGY (MUST), MIRPUR

DEPARMENT OF SOFTWARE ENGINEERING

 Software Project Management
SE-4701

Lecture 12: Software Project Cost Estimating using COCOMO

Engr. Shamila Nasreen

(shamila.se@must.edu.pk)
 Project Cost Estimation
• Good cost estimation is essential for keeping a project under budget
• Many costs can appear over the life cycle of a project
• Accurate estimation method can be helpful in making a project
successful
• Projects bring risks, and risks bring unexpected costs
• Cost estimation is the process that takes these factors into account,
and calculates a budget that meets the financial commitment necessary
for a successful project
• Project cost estimation applies to everything from building a bridge to
developing a new mobile application
• It all costs money, so the clearer you are on the amount required, the
more likely you’ll achieve your objective
 Project Cost Estimation

• There are three main parameters that you should use when
computing the costs of a software development project:
a) Effort costs (the costs of paying software engineers and
managers)
b) Hardware and software costs, including maintenance
c) Travel and training costs
 Project Cost Estimation
Techniques for Cost Estimation

(1) Algorithmic Cost Model:

• An estimate is made based on historical cost information using a
software metric (usually the size of the software)

(2) Expert Judgment:

• One or more experts on the software techniques to be used on the
application domain are consulted
• They estimate the project cost and then final cost is achieved
• They are guided by historical information, provides valuable insight
about the environment and information from prior similar projects
 Project Cost Estimation
Techniques for Cost Estimation (Contd…)
(3) Estimation by analogy:
• Cost of a new project is estimated by analogy with already completed
(same sort) of projects
• These estimates use the values such as scope, cost, budget, duration,
size, and complexity from a previous, similar project as the basis for
estimating the same parameter for a current project
(4) Parkinson’s Law:
• States that work expands to fill the time available
• i.e. only by using available material like hardware, software or any
other resources like electricity or space etc, to compute the cost.
• E.g. if the customer requirement is to complete the software within 10
months, and only 4 peoples are available
• In this case the cost is estimated to be 10 *4 means 40 person/months
 Project Cost Estimation

Techniques for Cost Estimation (Contd…)

(5) Pricing to win:
• Software cost is estimated to the customer’s capacity to pay, customer’s
budget and not on software’s functionality
• E.g., if the customer can spent 40 person/month, but actual effort is 60
person/month. Then estimator is asked to modify in estimation and fit
in 40 person/months

(6) Top-down estimation: Cost is estimated by the overall functionality of

the product

(7) Bottom-up estimation: Cost of each component is estimated and then

added to produce a final cost estimate
 Algorithmic Cost Modeling: Sizing by LOC
Or “ Function Points”
Empirical Estimation Model
¨ Models consist of one or more empirically derived equations that predict:

(1) Effort (in person-months)

(2) Project duration (months)
¨ Mostly used models are:
(1) COCOMO (Constructive Cost Model)
(2) Putnam Estimation Model

COCOMO/ COCOMO-II
¨ Barry Bohem introduced a hierarchy of software estimation models called
COCOMO
¨ Became one of the well-known and widely-used estimation models in the
industry
 The COCOMO Model
COCOMO (COnstructive COst MOdel)

Model 1: Basic COCOMO computes software development effort (and

cost) as a function of program size expressed in estimated LOCs

Model 2: Intermediate COCOMO computes s/w development effort (and

cost) as a function of program size and a set of “Cost Drivers” that
include subjective assessments of product h/w, personnel and project
attributes

Model 3: Advanced COCOMO incorporates all characteristics of the

intermediate version with an assessment of the cost driver’s impact
on each step (analysis, design, etc) of the s/w engineering process
 COCOMO
Organic mode
• A small team of experienced developers in a very familiar development environment
• Size of software is small 1 KDSI to 50 KDSI (Kilo Delivered Source Instruction)
• There are very few quality constraints
• Examples of this type of projects are simple business systems, simple inventory
management systems, and data processing systems.
Semi-detached
• An intermediate (in size and complexity) s/w project, a team with mixed experience levels
and Team members are unfamiliar with the system under development.
• Example of Semidetached system includes developing a Database Management System
(DBMS), and complex inventory management system.

Embedded mode
• Software is required to run under tight (and strongly coupled) h/w, s/w and operational
constraints (e.g. flight control s/w for aircraft)
• Size is between 10 KDSI to 500 KDSI
• Development team has not worked together before and development environment is not
familiar to them
• Examples: ATM, Air Traffic control.
COCOMO
 COCOMO Basic
• is a static, single-valued model that computes software development effort
(and cost) as a function of program size expressed in estimated lines of code
• Basic COCOMO is good for quick estimate of software costs.
• However it does not account for differences in hardware constraints,
personnel quality and experience, use of modern tools and techniques.
 COCOMO Basic
• Basic equations for COCOMO
Effort (PM) = A * SizeB
Time (TDEV) = C * PMD
• Organic mode
A=2.4, B=1.05, C=2.5, D=0.38
• Semi-detached
A=3.0, B=1.12, C=2.5, D=0.35
Mode Effort Schedule
• Embedded mode
A=3.6, B=1.20, C=2.5, D=0.32 Organic E=2.4*(KDSI)
1.05
TDEV=2.5*(E)
0.38

• Productivity = KDSI / PM 1.12 0.35

Semidetached E=3.0*(KDSI) TDEV=2.5*(E)
• Average Staffing = PM / TDEV
1.20 0.32
Embedded E=3.6*(KDSI) TDEV=2.5*(E)
 COCOMO Basic

¨ Example: for 32,000 delivered source instructions of SIMPLE project:

1.05
PM=2.4 (32) = 91 PM

0.38
TDEV=2.5 (91) = 14 months

¨ To determine the # of people :

N=PM/TDEV
= 91/14 = 7
 COCOMO Basic
Example2: A project size of 200 KLOC is to be developed. Software development team has average
experience on similar type of projects. The project schedule is not very tight. Calculate the Effort,
development time, average staff size, and productivity of the project.
Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and
experience of development time.
Hence
E=3.0(200)1.12=1133.12PM
D=2.5(1133.12) 0.35=29.3PM

P = 176 LOC/PM
 COCOMO Intermediate
• The intermediate COCOMO Model includes the effect of 15 factors (cost drivers)
• Cost drivers are multiplier for nominal (minor) cost
Effort Adjusted (PM actual) = PM(nominal) x EAF (Effort Adjustment Factor)
The product of all effort multipliers results in an effort adjustment factor (EAF).

• Nominal Cost equations are:

Effort (PM) = A * SizeB (where A=3.2, 2.8, 3.0)
Time (TDEV) = C * PMD

Constants B, C and D are the same as COCOMO Basic

• Cost drivers categories

i. Product attributes
ii. Computer attributes
iii. Personnel attributes
iv. Project attributes 16
 COCOMO Cost Drivers

• Product attributes
• RELY : Software reliability
• DATA : Database size
• CPLX : Product Complexity
• Computer attributes
• TIME : Execution time constraints
• STOR : Main storage constraints
• VIRT : Virtual Machine volatility (instability)
• TURN : Computer turnaround time (response time)

17
 COCOMO Cost Drivers

• Personnel attributes
• ACAP : Analyst Capability

• AEXP : Application Experience of team

• PCAP : Programmer Capability

• VEXP : Virtual machine experience

• LEXP : Programming language experience

• Project attributes
• MODP : Modern programming practices

• TOOL : Use of tools

• SCED : Schedule constraints

18
 15 Effort Multipliers
Typical values for EAF(effort adjustment factor)
Cost Very Low Low Normal High Very High Extra High
drivers
REPLY 0.75 0.88 1.00 1.15 1.40
DATA 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
ACAP 1.19 1.00 0.86 0.71
AEXP 1.13 1.00 0.91 0.82
PCAP 1.17 1.00 0.86 0.70
VEXP 1.10 1.00 0.90
LEXP 1.07 1.00 0.95
MODP 1.10 1.00 0.91 0.82
TOOL 1.10 1.00 0.91 0.83
SCED 1.08 1.00 1.04 1.10

19
 Example-I COCOMO Intermediate

• Find the effort and the time for development of a 32KDSI software product that has very
low required reliability and which is produced by a small team.

• This Problem requires Organic mode

• Effort (PM) = 3.2 * KDSI1.05

• Time (TDEV) = 2.5 * PM0.38

• Productivity = KDSI / PM

• Average Staffing = PM / TDEV

• Nominal Effort (PMnom)= 3.2 * 321.05

• RELY cost driver, “very low” = 0.75

• Adjusted effort (PM)= (PMnom) * 0.75 = ___ PM

20
 Example-II COCOMO Intermediate

• Suppose a project was estimated to be made in 400 kLOC. Let's calculate its effort,
time, and the number of people required while considering the project is of organic
type and has a normal complexity (CPLX). The developer has a high virtual
machine experience (VEXP).
• The value of the nominal complexity of a project is 1.00, and the high virtual
experience of the developer is 0.90:

21
 COCOMO Detailed Model

• The detailed COCOMO model is a further development of the original

COCOMO framework, which aims to provide a comprehensive and
accurate estimate of software work, time, and resource requirements.
• Unlike its predecessor, Detailed COCOMO delves into complex project
dynamics and includes a wide range of cost factors and scale factors to
capture the complexities of modern software projects.
• Phases of the Detailed COCOMO Model:
• Preparation and Requirements Phase
• System Design and Architecture Phase
• Detailed Design Phase
• Coding and Unit Testing Phase
• Integration and Testing Phase
• Delivery and Maintenance Phase

22
Make vs. Buy Decision

• In many software application areas, it is often more cost effective to

acquire rather than develop computer software

• SE managers are faced with a make/ buy decision that can be further
complicated by several acquisition options:
i. Software may be purchased (or licensed) off-the-shelf

ii. “Full-experience” or “Partial-experience” software components may

be acquired and then modified and integrated to meet specific needs
iii. Software may be custom built by an outside contractor to meet the
purchaser’s specifications

23
Make vs Buy Decision
The make/buy decision is made based on the following conditions:

(1) Will the delivery date of the software product be

sooner than that for internally developed software?

(2) Will the cost of purchasing of software product plus the cost
of customization be less than the cost of developing the
software internally?

(3) Will the cost of outside support (e.g., a maintenance contract)

be less than the cost of internal support?
24
Creating a Decision Tree for Make vs Buy Decision

• The steps just described can be explained using statistical

techniques such as decision tree analysis
• For example, Figure on next slide depicts a decision tree for a
software based system X
• In this case, the SE organization can:
i. Build system X from scratch
ii. Reuse existing partial-experience components to construct
the system
iii. Buy an available software product and modify it to meet
local needs
iv. Contract the software development to an outside vendor

25
Decision Tree

26
Decision Tree - CALCULATION

• If the system is to be built from scratch, there is a 70 % probability that

the job will be difficult
• Using the estimation techniques, the project planner estimates that:
• Difficult development effort will cost $450,000
• Simple development effort will cost $380,000
• The expected value for cost, computed along any branch of the decision
tree, is:

27
Decision Tree - CALCULATION

• Following other paths of the decision tree, the projected costs for reuse,
purchase, and contract, are also shown
• The expected costs for these paths are:

Based on the probability and projected costs that have been noted in
Figure the lowest expected cost is the “buy” option.

28
Decision Tree

• It is important to note, however, that many criteria—not just

cost— must be considered during the decision-making
process
• Few of the criteria that may affect the ultimate decision to
build, reuse, buy, or contract includes:
• Availability
• Experience of the developer / vendor / contractor
• Conformance to requirements
• Local “politics”
• Likelihood of change

29
THANKS