Software Cost
Estimation:
cont…
11/16/25 1
COCOMO 81
COCOMO (CONSTRUCTIVE COST
MODEL)
First published by Dr. Barry Boehm, 1981
Basic model:
effort = c x sizek
C and k depend on the type of system: organic,
semi-detached, embedded
Size is measured in ‘kloc’ ie. Thousands of lines
of code 2
COCOMO Mode & Model
Three development environments
(modes)
Organic Mode
Semidetached Mode
Embedded Mode
Three increasingly complex models
Basic Model
Intermediate Model
Detailed Model
3
COCOMO Modes
Organic Mode
Developed in familiar, stable environment
Product similar to previously developed product
<50,000 DSIs (ex: accounting system)
Semidetached Mode
somewhere between Organic and Embedded
Embedded Mode
new product requiring a great deal of innovation
inflexible constraints and interface requirements
(ex: real-time systems)
4
Modes
Feature Organic Semidetached Embedded
Organizational Thorough Considerable General
understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems
Need for software Basic Considerable Full
conformance with
pre- established
requirements
Need for software Basic Considerable Full
conformance with
external interface
specifications 5
COCOMO Models
Basic Model
Used for early rough, estimates of project cost, performance, and
schedule
Accuracy: within a factor of 2 of actuals 60% of time
Intermediate Model
Uses Effort Adjustment Factor (EAF) fm 15 cost drivers
Doesn’t account for 10 - 20 % of cost (trng, maint, Qual, etc)
Accuracy: within 20% of actuals 68% of time
Detailed Model
Uses different Effort Multipliers for each phase of project (Most project
managers use intermediate model)
6
Basic Effort Equation (COCOMO 81)
Effort=A(size)k
A is a constant based on the developmental mode
organic = 2.4
semi = 3.0
embedded = 3.6
Size = 1000s Source Lines of Code (KSLOC)
k is constant for a given mode
organic = 1.05
semi = 1.12
embedded = 1.20
7
The COCOMO Constants
System type A k
Organic (broadly, 2.4 1.05
information systems)
Semi-detached 3.0 1.12
Embedded (broadly, 3.6 1.20
real-time)
K helps adds disproportionately more effort to
the larger projects
takes account of greater complexity and
8
bigger management overheads 8
Basic Model:
Schedule Equation (COCOMO 81)
Nominal Development time=
2.5*(Effort)p
2.5 is constant for all modes
Value of exponent p based on mode
organic = 0.38
semi = 0.35
embedded = 0.32
9
Development Time
Observe: Development time is roughly
the same for all the three categories of
products:
For example, a 38 KLOC program can be
developed in approximately 9 months
regardless of whether it is of organic, semi-
detached, or embedded type. How come?
There is more scope for parallel activities for
system and application programs,
Compared to utility programs.
10
Exercise
Software package is required by a company to
mine existing customer data to select
prospective customers for a new launch.
Estimated to be 30KLOC of effort
Assume competent developers can be hired at
Rs50,000/- per month.
However, commercial offering supporting almost
all of the required features costs Rs. 100,000/-
Should the company buy or build?
11
Buy/Build Decision
The make/buy decision can be made based
on the following conditions
Will the software product be available sooner
than internally developed software?
Will the cost of acquisition plus the cost of
customization be less than the cost of
developing the software internally?
Will the cost of outside support (e.g., a
maintenance contract) be less than the cost of
internal support?
12
Example 1
Consider an MIS project of 38,000 lines
of code, what is the shortest time it
will take to develop?
Effort = ≈ 109 SM
Nominal time = T= 14.88 months
13
Intermediate COCOMO
Takes basic COCOMO as starting point
Identifies factors which affect cost and
development time:
Personnel, product, computer and project
attributes.
Multiplies basic cost by attribute
multipliers which may increase or
decrease costs
14
Attributes
Personnel attributes
Analyst capability
Virtual machine experience
Programmer capability
Programming language experience
Application experience
Product attributes
Reliability requirement
Database size
Product complexity
15
More Attributes
Computer attributes
Execution time constraints
Storage constraints
Virtual machine volatility
Computer turnaround time
Project attributes
Modern programming practices
Software tools
Required development schedule
16
Effort for
increasing LOC
3x 1.12
Duration for
increasing Effort
2.5x 0.35
<1
exponent:
>1
17
Intermediate Model
Effort Equation (COCOMO 81)
Effort=EAF*A(size)k
EAF (effort adjustment factor) is the product of
effort multipliers corresponding to each cost
driver rating
A is a constant based on the developmental
mode
organic = 3.2
semi = 3.0
embedded = 2.8
Size = 1000s Delivered Source Instruction (KDSI)
k is constant given mode
18
Drawbacks
For better accuracy:
COCOMO has to be calibrated to an
organizations’ environment.
Very sensitive to parameter change:
Over a person-year difference in a 10
KLOC project with minor adjustments
Broad brush model that can generate
significant errors
19
Cocomo 81:
Limitations as years
progressed…
Software reuse
Application generation of programs
Object oriented approaches
Need for rapid development
Agile models
21
COCOMO II
Main objectives of COCOMO II:
To develop a software cost and schedule
estimation model tuned to the life cycle
practices of the 1990’s and 2000’s
To develop software cost database and
tool support capabilities for continuous
model improvement
From “Cost Models for Future Software Life Cycle
Processes: COCOMO 2.0," Annals of Software
Engineering, (1995).
22
COCOMO 2 models
COCOMO 2 incorporates a range of sub-models:
Produces increasingly accurate estimates.
The 4 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.
23
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.
24
Staffing Level Estimation
Number of personnel required during
any development project:
Never a constant.
Norden in 1958 analyzed many R&D
projects, and observed:
Rayleigh curve represents the number of
full-time personnel required at any time.
25
25
Rayleigh Curve
Rayleigh curve is
specified by two Rayleigh Curve
parameters:
td the time at which Effort
the curve reaches
its maximum
td
K the total area
under the curve. Time
L=f(K, td)
26
Staffing
Norden was one of the first to investigate
staffing pattern:
Considered general research and development
(R&D) type of projects.
Norden concluded:
Staffing pattern for any R&D project can be
approximated by the Rayleigh distribution curve
Manpower
TD
27
Time
Putnam’s Work
In 1976, Putnam studied the problem of
staffing of software projects:
observed that the level of effort required in
software development efforts has a similar
envelope.
found that the Rayleigh-Norden curve
relates the number of delivered lines of code
to effort and development time.
28
28
Rayleigh Curve
Very small number of engineers are
needed at the beginning of a project
carry out planning and specification.
As the project progresses:
More detailed work is required,
Number of engineers slowly increases and
reaches a peak.
29
29
Rayleigh Curve
Putnam observed that:
The time at which the Rayleigh curve
reaches its maximum value
corresponds to system testing and
product release.
After system testing,
The number of project staff falls till
product installation and delivery.
30
Rayleigh Curve
From the Rayleigh curve
observe that:
Approximately 40% of the area
under the Rayleigh curve is to
the left of td
and 60% to the right.
31
Putnam’s Work (CONT.)
Putnam analyzed a large number of army
projects, and derived the expression:
L=CkK1/3td4/3
K is the effort expended and L is the size in
KLOC.
td is the time to develop the software.
Ck is the state of technology coefficient
reflects factors that affect programmer productivity.
32 32
Putnam’s Work (CONT.)
Ck=2 for poor development environment
no methodology, poor documentation, and
review, etc.
Ck=8 for good software development
environment
software engineering principles used
Ck=11 for an excellent environment
33 33
Putnam’s Model
Lines of code: L
Person months: K
Time to develop: td
Technology coefficient: Ck
34
Putnam’s Model
1/ 3 4 / 3
Lines of code: L Ck K t d
3
L
Person months: K
4/3
Ck t d
3/ 4
L
Time to develop: t d
1/ 3
Ck K 35
Putnam’s Work
Putnam adapted the Rayleigh-Norden
curve:
Related the number of delivered lines of
code to the effort and the time required
to develop the product.
Studied the effect of schedule
compression:
36
Effort Applied vs. Delivery Time
There is a nonlinear relationship between
effort applied and delivery time (Putnam-
Norden-Rayleigh Curve)
Effort increases rapidly as the delivery time
is reduced
Effort
cost
Impossible
region
E theoretical
E optimal
t minimum t theoretical t optimal
37
Development tim
Effect of Schedule Change on
Cost
Using the Putnam's expression for L,
K=L3/Ck3td4
Or, K=C1/td4
For the same product size, C1=L3/Ck3 is
a constant.
Or, K1/K2 = td24/td14
38
Effect of Schedule Change on
Cost
Observe:
A relatively small compression in delivery
schedule
can result in substantial penalty on human
effort.
Also, observe:
benefits can be gained by using fewer
people over a somewhat longer time span.
39
Example
If the estimated development time is 1
year, then in order to develop the
product in 6 months,
the total effort and hence the cost
increases 16 times.
In other words,
The relationship between effort and the
chronological delivery time is highly nonlinear.
40
Effect of Schedule Change on
Cost
Putnam model indicates extreme
penalty for schedule compression
and extreme reward for expanding the
schedule.
Putnam estimation model works
reasonably well for very large systems,
but seriously overestimates the effort for
medium and small systems.
41
41