COCOMO MODEL

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model
developed by Barry Boehm. The model uses a basic regression formula, with parameters that
are derived from historical project data and current project characteristics.

COCOMO was first published in 1981 Barry W. Boehm's Book Software engineering
economics as a model for estimating effort, cost, and schedule for software projects. It drew
on a study of 63 projects at TRW Aerospace where Barry Boehm was Director of Software
Research and Technology in 1981. The study examined projects ranging in size from 2,000 to
100,000 lines of code, and programming languages ranging from assembly to PL/I. These
projects were based on the waterfall model of software development which was the prevalent
software development process in 1981.

References to this model typically call it COCOMO 81. In 1997 COCOMO II was developed
and finally published in 2000 in the book Software Cost Estimation with COCOMO II[2].
COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern
software development projects. It provides more support for modern software development
processes and an updated project database. The need for the new model came as software
development technology moved from mainframe and overnight batch processing to desktop
development, code reusability and the use of off-the-shelf software components. This article
refers to COCOMO 81.

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first
level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of
software costs, but its accuracy is limited due to its lack of factors to account for difference in
project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into
account and Detailed COCOMO additionally accounts for the influence of individual project
phases.

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model
developed by Barry Boehm. The model uses a basic regression formula, with parameters that
are derived from historical project data and current project characteristics.

COCOMO was first published in 1981 Barry W. Boehm's Book Software engineering
economics[1] as a model for estimating effort, cost, and schedule for software projects. It
drew on a study of 63 projects at TRW Aerospace where Barry Boehm was Director of
Software Research and Technology in 1981. The study examined projects ranging in size
from 2,000 to 100,000 lines of code, and programming languages ranging from assembly to
PL/I. These projects were based on the waterfall model of software development which was
the prevalent software development process in 1981.
References to this model typically call it COCOMO 81. In 1997 COCOMO II was developed
and finally published in 2000 in the book Software Cost Estimation with COCOMO II[2].
COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern
software development projects. It provides more support for modern software development
processes and an updated project database. The need for the new model came as software
development technology moved from mainframe and overnight batch processing to desktop
development, code reusability and the use of off-the-shelf software components. This article
refers to COCOMO 81.

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first
level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of
software costs, but its accuracy is limited due to its lack of factors to account for difference in
project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into
account and Detailed COCOMO additionally accounts for the influence of individual project
phases. Basic COCOMO computes software development effort (and cost) as a function of
program size. Program size is expressed in estimated thousands of lines of code (KLOC).

COCOMO applies to three classes of software projects:

* Organic projects - "small" teams with "good" experience working with "less than rigid"
requirements

* Semi-detached projects - "medium" teams with mixed experience working with a mix of
rigid and less than rigid requirements

* Embedded projects - developed within a set of "tight" constraints (hardware, software,

operational, ...)

The basic COCOMO equations take the form

Effort Applied = ab(KLOC)bb [ man-months ]

Development Time = cb(Effort Applied)db [months]

People required = Effort Applied / Development Time [count]

The coefficients ab, bb, cb and db are given in the following table.

Software project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

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, and so on.

Intermediate COCOMO computes software development effort as function of program size

and a set of "cost drivers" that include subjective assessment of product, hardware, personnel
and project attributes. This extension considers a set of four "cost drivers", each with a
number of subsidiary attributes:-

* Product attributes

Required software reliability

Size of application database

Complexity of the product

* Hardware attributes

Run-time performance constraints

Memory constraints

Volatility of the virtual machine environment

Required turnabout time

* Personnel attributes

Analyst capability

Software engineering capability

Applications experience
 Virtual machine experience

Programming language experience

* Project attributes

Use of software tools

Application of software engineering methods

Required development schedule

The four main elements of the COCOMO II strategy are: • Preserve the openness of the
original COCOMO;

• Key the structure of COCOMO II to the future software marketplace sectors described
earlier;

• Key the inputs and outputs of the COCOMO II sub models to the level of information
available;

• Enable the COCOMO II sub models to be tailored to a project's particular process strategy.
COCOMO II follows the openness principles used in the original COCOMO.

Thus, all of its relationships and algorithms will be publicly available. Also, all of its
interfaces are designed to be public, well-defined, and parametrized, so that complementary
pre processors (analogy, case-based, or other size estimation models), post-processors
(project planning and control tools, project dynamics models, risk analyzers), and higher
level packages (project management packages, product negotiation aids), can be combined
straightforwardly with COCOMO II. To support the software marketplace sectors above,
COCOMO II provides a family of increasingly detailed software cost estimation models,
each tuned to the sectors' needs and type of information available to support software cost
estimation.

COCOMO II Models for the Software Marketplace Sectors

The COCOMO II capability for estimation of Application Generator, System Integration, or
Infrastructure developments is based on two increasingly detailed estimation models for
subsequent portions of the life cycle, Early Design and Post Architecture.

COCOMO II Model Rationale and Elaboration

The rationale for providing this tailorable mix of models rests on three primary premises.
First, unlike the initial COCOMO situation in the late 1970's, in which there was a single,
preferred software life cycle model, current and future software projects will be tailoring their
processes to their particular process drivers. These process drivers include COTS or reusable
software availability; degree of understanding of architectures and requirements; market
window or other schedule constraints; size; and required reliability for an example of such
tailoring guidelines). Second, the granularity of the software cost estimation model used
needs to be consistent with the granularity of the information available to support software
cost estimation. In the early stages of a software project, very little may be known about the
size of the product to be developed, the nature of the target platform, the nature of the
personnel to be involved in the project, or the detailed specifics of the process to be used.

Advantages of COCOMO estimating model are:

COCOMO is factual and easy to interpret. One can clearly understand how it works.
Accounts for various factors that affect cost of the project.
Works on historical data and hence is more predictable and accurate.
The drivers are very helpful to understand the impact on the different factors that affect the
project costs.

Disadvantages:

COCOMO model ignores requirements and all documentation.

It ignores customer skills, cooperation, knowledge and other parameters.
It oversimplifies the impact of safety/security aspects.
It ignores hardware issues
It ignores personnel turnover levels
It is dependent on the amount of time spent in each phase.

Overview of COCOMO
The COCOMO cost estimation model is used by thousands of software project managers, and
is based on a study of hundreds of software projects. Unlike other cost estimation models,
COCOMO is an open model, so all of the details are published, including:

 The underlying cost estimation equations

 Every assumption made in the model (e.g. "the project will enjoy good management")
 Every definition (e.g. the precise definition of the Product Design phase of a project)
 The costs included in an estimate are explicitly stated (e.g. project managers are
included, secretaries aren't)

Because COCOMO is well defined, and because it doesn't rely upon proprietary estimation
algorithms, This model offers these advantages to its users:
  COCOMO estimates are more objective and repeatable than estimates made by
methods relying on proprietary models
 COCOMO can be calibrated to reflect your software development environment, and
to produce more accurate estimates

This model is a faithful implementation of the COCOMO model that is easy to use on small
projects, and yet powerful enough to plan and control large projects.

Typically, you'll start with only a rough description of the software system that you'll be
developing, and you'll use This model to give you early estimates about the proper schedule
and staffing levels. As you refine your knowledge of the problem, and as you design more of
the system, you can use This model to produce more and more refined estimates.

This model allows you to define a software structure to meet your needs. Your initial estimate
might be made on the basis of a system containing 3,000 lines of code. Your second estimate
might be more refined so that you now understand that your system will consist of two
subsystems (and you'll have a more accurate idea about how many lines of code will be in
each of the subsystems). Your next estimate will continue the process -- you can use This
model to define the components of each subsystem. This model permits you to continue this
process until you arrive at the level of detail that suits your needs. It is so easy to use This
model to make software cost estimates, that it's possible to misuse it -- every This model user
should spend the time to learn the underlying COCOMO assumptions and
definitions from Software Engineering Economics and Software
Cost Estimation with COCOMO II.

References

http://www.softstarsystems.com/overview.htm

http://www.mhhe.com/engcs/compsci/pressman/information/olc/COCOMO
.html

http://www.nptel.ac.in/courses/Webcourse-
contents/IIT%20Kharagpur/Soft%20Engg/pdf/m11L28.pdf