AIM Cost Estimation of Project Using COCOMO Model-1: Key Points

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

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

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]
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

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
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]
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]
[2014-2015]

AIM Cost Estimation of Project Using COCOMO Model-1: Key Points

Uploaded by

Copyright:

Available Formats

AIM Cost Estimation of Project Using COCOMO Model-1: Key Points

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AIM Cost Estimation of Project Using COCOMO Model-1: Key Points

Uploaded by

Copyright:

Available Formats

Practical No.

3 : Cost Estimation of Project Using COCOMO Model-1

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

Effort = 3.2 EAF (Size)1.05

Effort = 3.0 EAF (Size)1.12

Effort = 2.8 EAF (Size)1.2

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

COCOMO project characterization parameters

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

Code and unit test

Integration and test

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

Default effort allocations across CO COMO WBS activities

Verification and validation

Configuration management and quality assurance

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

100,000-SLOCproject that requires 972 staff-months

The total EAF (1.28 in

Virtual machine volatility

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

You might also like