COCOMO - Constructive Cost Model

Source: Wikipedia: COCOMO

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.

The cocomo is a hierarchy of software cost estimation model. COCOMO Models are Basic Model and Intermediate Model. The Basic model aims at estimating in a quick and rough fashion, most of the small to medium sized software projects. Three modes of Basic model. Organic,Semideteched and Embeded.

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.

* 1 Basic COCOMO
* 2 Intermediate COCOMO
* 3 Detailed COCOMO
* 4 Projects using COCOMO
* 5 See also
* 6 References
* 7 Further reading
* 8 External links

[edit] Basic COCOMO

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.
[edit] Intermediate COCOMO

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
o Required software reliability
o Size of application database
o Complexity of the product
* Hardware attributes
o Run-time performance constraints
o Memory constraints
o Volatility of the virtual machine environment
o Required turnabout time
* Personnel attributes
o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience
* Project attributes
o Use of software tools
o Application of software engineering methods
o Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). An effort multiplier from the table below applies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.
Cost Drivers Ratings
Very Low Low Nominal High Very High Extra High
Product attributes
Required software reliability 0.75 0.88 1.00 1.15 1.40
Size of application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-time performance constraints 1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environment 0.87 1.00 1.15 1.30
Required turnabout time 0.87 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project attributes
Application of software engineering methods 1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10

The Intermediate Cocomo formula now takes the form:


where E is the effort applied in person-months, KLoC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi are given in the next table.

Software project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.
[edit] Detailed COCOMO

Detailed 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 software engineering process
[edit] Projects using COCOMO

* Ohloh

[edit] See also

* Estimation in software engineering
* Software engineering economics
* Cost overrun
* Putnam model

[edit] References

1. ^ Barry Boehm. Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. ISBN 0-13-822122-7
2. ^ Barry Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, and Bert SteeceSoftware cost estimation with COCOMO II (with CD-ROM). Englewood Cliffs, NJ:Prentice-Hall, 2000. ISBN 0-13-026692-2

[edit] Further reading

* Stan Malevanny. Case Study: Software Project Cost Estimates Using COCOMO II Model, 2005.
* Kemerer, Chris F. (May, 1987). "An Empirical Validation of Software Cost Estimation Models". Communications of the ACM.

[edit] External links

* COCOMO II website
* COCOMO II online calculator
* NASA basic COCOMO online calculator
* COCOMO 81 Calculator

Retrieved from ""
Categories: Software engineering costs

Source: x


COCOMO is an acronym for COnstructive COst MOdel, which was first introduced in 1981 by Barry Boehm in his book Software Engineering Economics. Based on LOC estimates, it is used to estimate cost, effort, and schedule (Boehm 1981). The original COCOMO model received widespread interest and is an open model, meaning that all of the underlying equations, assumptions, definitions, and so on are available to the public. The original COCOMO model was based on a study of 63 projects and is a hierarchy of estimation models.

COCOMO is an example of a parametric model because it uses dependent variables, such as cost or duration, based upon one or more independent variables that are quantitative indices of performance and/or physical attributes of the system. Often, parametric models can be refined and fine-tuned for specific projects or projects within specific industries (Rad 2002).

Estimating with COCOMO begins with determining the type of project to be estimated. Project types can be classified as:

* Organic—These are routine projects where the technology, processes, and people are expected all to work together smoothly. One may view these types of projects as the easy projects, where few problems are expected.
* Embedded—An embedded project is viewed as a challenging project. For example, it may be a system to support a new business process or an area that is new ground for the organization. The people may be less experienced, and the processes and technology may be less mature.
* Semi-Detached—If organic projects are viewed as easy and embedded as difficult or challenging, then semi-detached fall somewhere in the middle. These projects may not be simple and straightforward, but the organization feels confident that its processes, people, and technology in place are adequate to meet the challenge.

The basic COCOMO model uses an equation for estimating the number of person-months needed for each of these project types. A person-month can be thought of as a one-month effort by one person. In COCOMO, a person-month is defined as 152 hours. Once the project type is defined, the level of effort, in terms of person-months, can be determined using the appropriate equation:

* Organic: Person-Months = 2.4 × KDSI1.05
* Semi-Detached: Person-Months = 3.0 × KDSI1.12
* Embedded: Person-Months = 3.6 × KDSI1.20

Where: KDSI = Thousands of delivered source instructions, i.e., LOC

Let’s suppose that we are developing an application that we estimated to have 200 total adjusted function points. Using Table 6.3, we can convert function points into lines of code. If our application is going to be developed in Java, this would require approximately 10,600 lines of code. If we assume that our project will be of medium difficulty, then the semi-detached equation would be appropriate.
= 3.0 × KDSI1.12
 = 3.0 × (10.6)1.12
 = 42.21

In summary, our 200 function point project will require about 10,600 lines of code and take just over 42.21 person-months to complete. Once we have estimated the effort for our project, we can determine how many people will be required. Subsequently, this will determine the time estimate and associated cost for developing our application system.

As Frederick Brooks (1995) points out, people and months are not always interchangeable. More people may complicate communication and slow things down. Therefore, duration is determined using one of the following formulas:

* Organic: Duration = 2.5 × Effort0.38
* Semi-Detached: Duration = 2.5 × Effort0.35
* Embedded: Duration = 2.5 × Effort0.32

Since our semi-detached project requires 42.21 person-months, the duration of development will be:
= 2.5 × Effort0.35
 = 2.5 × (42.21)0.35
 = 9.26 months

Subsequently, we can determine how many people should be assigned to the development effort:
People Required
= Effort ÷ Duration
 = 42.21 ÷ 9.26
 = 4.55

Therefore, we need 4.55 people working on the project. Okay, so it is pretty tough getting .55 of a person, so we probably will need either four or five people. One could even make an argument that four full-time people and one part-time person will be needed for this project.

The example shows how the basic COCOMO model can be used. There are, however, two other COCOMO models: intermediate COCOMO and advanced COCOMO. Intermediate COCOMO estimates the software development effort as a function of size and a set of 15 subjective cost drivers that include attributes of the end product, the computer used, the personnel staffing, and the project environment. In addition, advanced COCOMO includes all of the characteristics of intermediate COCOMO but with an assessment of the cost driver’s impact over four phases of development: product design, detailed design, coding/testing, and integration/testing.

Today, COCOMO II is available and is more suited for the types of projects being developed using 4GLs or other tools like Visual Basic, Delphi, or Power Builder. However, for more traditional projects using a 3GL, the original COCOMO model can still provide good estimates and is often referred to as COCOMO 81.

Another estimating model that you should be aware of is SLIM, which was developed in the late 1970s by Larry Putnam of Quantitative Software Management (Putnam 1978; Putnam and Fitzsimmons 1979). Like COCOMO, SLIM uses LOC to estimate the project’s size and a series of 22 questions to calibrate the model.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License