Practical No.

3 : Cost Estimation of Project Using COCOMO Model-1

AIM
Cost Estimation of Project Using COCOMO Model-1
Several software cost models are in use today. One popular, open, and well
documented software cost model is the Constructive Cost Model (COCOMO)
developed by Barry Boehm. The evolution of CO COMO provides an interesting
window for observing the evolution of software engineering economics over the
past 20 years. The COCOMO estimating equations follow this simple form:
Effort
Time

= Cl EAF (Size)Pl
= C2 (Effort)P2

where:
Effort
Cl
EAF
Size
P1

Time

P2

=
=
=

number of staff-months
a constant scaling coefficient for effort
an effort adjustment factor that characterizes the domain, per
sonnel, environment, and tools used to produce the artifacts of
the process
= size of the end product (in human-generated source code), mea
sured by the number of delivered source instructions (DSI)
required to develop the required functionality.
= an exponent that characterizes the economies of scale
inherent in the process used to produce the end product, in
particular the ability of the process to avoid non-valueadding
activities
(rework,
bureaucratic
delays,
communications overhead)
= total number of months
C2 = a constant scaling coefficient for
schedule
= an exponent that characterizes the inherent inertia and parallel
ism in managing a software development effort.

Key Points
The history of the COCOMO model provides insight
into the evolution of software economics priorities.
The original COCOMO model was well suited for
conventional software project cost estimation in the 1980s.
Ada COCOMO improved on the original version,
particularly through a parameterized exponent that
reflected modern process improvements and their impact on
economies of scale.
COCOMO II is better suited for estimating modern
software development projects.

[2014-2015]

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

COCOMO
The original COCOMO model [Boehm, 1981] was one of the minor
breakthroughs in software engineering during the early 1980s. It was a
breakthrough partly because of its inherent technology contribution but
primarily because it provided a well defined framework for communication of
trade-offs and priorities associated with software cost and schedule management.
As a naive graduate student at UCLA in
1980, I first encountered the COCOMO model as the subject of a new graduatelevel course taught by Boehm. At the same time, I was working at TRW as a lead
designer on a software-intensive proposal for which we' needed to plan and
defend the soft ware cost and schedule estimates. A huge benefit offered by the
COCOMO model was the ability to make an estimate, reference a credible basis
for it, reason about its strengths and weaknesses, and negotiate with stakeholders.
Since then, I have used CO COMO to rationalize technology insertions, process
improvements, project architecture changes, and new management approaches. In
these activities, I became experienced with its strengths and weaknesses, as well as
its use and misuse.
The original COCOMO model was based on a database of 56 projects. Its three
modes reflected the differences in process across a range of software domains.
These modes were identified as organic, semidetached, and embedded. Organic
mode projects were characterized by in-house, less-complex developments that had
flexible processes. Features, qualities, cost, and schedule could be freely changed
with mini mal overhead. Embedded mode systems represented typical defense
community projects: Complexity, reliability, and real-time issues were dominant, and
the contractual nature of the business resulted in a highly rigorous process.
Features, qualities, costs, and schedules were tightly controlled, and changes
required approvals by many stakeholders. Semidetached mode projects represented
something in between.
Basic Effort and Schedule Estimating Formulas
These were the original COCOMO cost estimation relationships:
Organic mode

Effort = 3.2 EAF (Size)1.05

Time (in months) = 2.5 (Effort)0.38

Semidetached mode

Effort = 3.0 EAF (Size)1.12

Time (in months) = 2.5 (Effort)O.35

Embedded mode

Effort = 2.8 EAF (Size)1.2

Time (in months) = 2.5 (Effort)O.32

where:
Effort = number of staff-months
EAF = product of 15 effort adjustment factors
Size = number of delivered source instructions (in units of thousands
of lines of code)

[2014-2015]

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

The effort adjustment factor (EAF) multiplier represents the combined effects
of multiple parameters. These parameters allow the project to be
characterized and normalized against the projects in the COCOMO database.
Each parameter is assessed as very low, low, nominal, high, or very high.
The effect of each parameter setting is a multiplier that typically ranges
from 0.5 to 1.5. The product of these 15 effects is used as the coefficient in the
cost equation.

COCOMO project characterization parameters

Cost
Driver(EAF)
ACAP
(Analyst
Capability)
AEXP
(Application
Experience)
CPLX
(Product
Complexity)
DATA
(Database
Size)
LEXP
(Language
Experience)
MODP
(Modern
Practices)
PCAP
(Programme
r Capability)
RELEY
(Realiablity)
TIME
(Execution
Time)
TOOL
(Use Of
Software
Tools)
VEXP
(Virtual
Machine
Experience)
STOR
(Main
Storage
[2014-2015]

Parameter Range
1.46

1.19

1.00

0.86

0.21

1.29

1.30

1.00

0.91

0.82

0.70

0.85

1.00

1.15

1.30,1.6
5

0.94

1.00

1.16

1.14

1.07

1.00

0.95

1.24

1010

1.00

0.91

0.82

1.02

1.17

1.00

0.86

0.7

0.75

0.88

1.00

1.15

1.4

1.0

1.11

1.3,1.66

1.24

1.10

1.00

0.91

0.83

1.21

1.10

1.00

0.9

1.0

1.06

1.21,1.5
6

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

Constraint)
Assumptions
Several assumptions are inherent in the COCOMO formulas. Delivered source
instructions include all (non comment) lines of computer-processed code. The
development life cycle starts at the beginning of product design and ends with
acceptance test at the conclusion of the integration and test phase. (The
requirements analysis effort and schedule are estimated separately as an additional
percentage of the development estimate.) The activities include only directcharged project efforts and exclude typical overhead activities such as
administrative support, facilities, and capital equipment. A staff-month consists of
152 hours. The project will be well managed. The project will experience stable
requirements.
Life-Cycle Description
The COCOMO life cycle includes five basic phases: plans and requirements,
product design, detailed design, code and unit test, and integration and test.
COCOMO pro vides recommendations for distributing the effort and schedule
across the basic phases of the conventional waterfall model. These
recommendations vary somewhat with mode and scale; Table B-2 provides a typical
profile for a large, embedded mode project. CO COMO estimates the effort and
schedule to develop the solution (product design through integration and test).
Formulating the problem (plans and requirements) is estimated as an additional
percentage over and above the development effort and schedule.
Software Work Breakdown Structure
Most conventional work breakdown structures are organized around the
product subsystems at the higher levels and around the detailed activities at the
lower levels. The standard activities estimated by COCOMO and included in the
software WBS are requirements analysis, product design, programming, test
planning, verification and validation, project office functions (management and
administration), configuration management and quality assurance, and manuals.
COCOMO also recommends
Effort and schedule partition across conventional life-cycle phases
ACTIVITY
Plans and requirements

[2014-2015]

EFFORT(%)
(+8)

SCHEDULE
(%)
(+36)

Product design

18

36

Detailed design

25

18

Code and unit test

26

18

Integration and test

31

28

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

Default effort allocations across CO COMO WBS activities

ACTIVITY

BUDGET(%)

Requirements analysis

Product design

12

Programming

44

Test planning

Verification and validation

14

Project office

Configuration management and quality assurance

Manuals

a top-level distribution of effort across the activities of the WBS. Again, these
profiles are dependent on mode and scale. Table B-3 identifies the expected
expenditure pro file among the activities in the WBS for a large, embedded mode
project. An important caveat is that in COCOMO, the "programming" activity
includes detailed design, coding, unit testing, and integration.
A Typical COCOMO Project Profile
The following discussion focuses on a specific example project in order to
illuminate some of the project planning implications. Assume a large, 100,000
source-line (100-KDSI) mission-critical system (for example, control of a power
plant) built under contract for a government agency. Figure B-1 illustrates
the CO COMO estimated profile for this project. CO COMO would estimate 900
staff-months for development plus 72 staff-months for requirements specification
for this project. The schedule required would be 22 months from initiation of design
through test, plus 8 months for requirements.
Ada COCOMO
In the mid-1980s, TRW confronted the challenge of transitioning several projects
to Ada. In some cases, a government mandate was the forcing function. (These
projects tended to struggle.) In other cases, the project engineers believed that Ada
technology was critical to a competitive bid and successful performance. (These
projects tended to succeed.) I developed the first prototype of Ada COCOMO on an
internal research and development project in 1985. The purpose of this effort was to
provide a frame work for convincing TRW management and a government customer
that the cost benefits of using Ada on a specific large-scale project were significant,
and that proposing

[2014-2015]

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

Example:

100,000-SLOCproject that requires 972 staff-months

of effort and 30 months of schedule

Effort
= 2.8 EAF (KDSI)1.2
= 208 (1.28) (100)1.2
= 900 staff-months of development effort
+ 72 staff-months for plans, requirements
972 staff-months 0f total effort

The total EAF (1.28 in

this example) is the product
of all the individual cost
driver effects.

Time
= 2.5(Effort)0.32
= 2.5(900)0.32
= 22 months of development schedule
+ 8 months for plans, requirements
=30 months

Cost Driver

Setting

Effect

Language experience
Schedule constraint
Database size
Turnaround time
Virtual machine experience

Nominal
Nominal
Nominal
Nominal
Nominal

1.0
1.0
1.0
1.0
1.0

Virtual machine volatility

Use of software tools
Modern programming practices

Nominal
High
Nominal

1.0
0.88
1.0

Storage constraint
Application Experience
Timing constraint
Required reliability
Product complexity
Personnel/team capability

Nominal
Low
Nominal
High
High
Nominal

1.0
1.10
1.0
1.15
1.15
1.0

[2014-2015]

Practical No. 3 : Cost Estimation of Project Using COCOMO Model-1

[2014-2015]