Information about Cocomo calculation


Cocomo is a model designed bij Barry W. Boehm to give an estimate of the number of man month it will take to develop a software product.
This "COnstructive COst MOdel" is based on a study of about 60 projects at TRW, which is a company where many large software projects are being build. The programms examened where ranging in size from 2000 to 100.000 lines of code, and programming languages used range from assebly to PL/I.
Cocomo consists of a hierarchy of 3 increasingly detailed and accurate forms. For this project we only implemented the Basic and the Intermediate versions. We will go more into detail about these levels of Cocomo.
Cocomo calculates Effort (E) and Development time (D) using kilo lines of code (KLOC).

Basic Cocomo

Cocomo may be applied to three classes of software projects. These give a general impression of the software project. The basic Cocomo equations take the form...
...where E is the effort applied in person-months, D is the development time in chronological months, and KLOC is the estimated number of delivered lines of code for the project (express in thousands). 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, early, rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use o f modern tools and techniques, and other project attributes known to have a significant influence on software costs.

Intermediate Cocomo

The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories, with each a number of sub catagories: Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "extra high" (in importance or value). Based on the rating, an effort multiplier is determined from the table below. The product product of all effort multipliers results in an 'effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.
Very Very Extra
Cost Drivers Low Low Nominal High High 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 envionment 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
Software engineer capability 1.29 1.13 1.00 0.91 0.82
Applications experience 1.42 1.17 1.00 0.86 0.70
Virtuel machine experience 1.21 1.10 1.00 0.90
Programming Language experience 1.14 1.07 1.00 0.95
Project attributes
Use of software tools 1.24 1.10 1.00 0.91 0.82
Application of software engineering methods 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-month and LOC is the estimated number of delivered lines of code for the project and EAF the factor calculated above. The coedfficients 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 is calculated from E in the same way as with basic Cocomo.

Function Point calculation

To calculate Effort and Development time using Cocomo you need an estimate of delivered lines of code. A function point analysis is a method of calculation lines of code using function points. The function point method was originaly developed bij Albrecht. A function point is a rough estimate of a unit of delivered functionality of a software project. To calculate the number of function points for a software project one counts all the user inputs, user outputs, user inquiries, number of files and number of external interfaces splitting them up in simple, average and complex ones. By multiplying these found countings using the table below a total count is created.
Measurement parameter Weighting factor
Simple Average Complex
Number of user inputs 3 4 6
Number of user outputs 4 5 7
Number of user inquiries 3 4 6
Number of files 7 10 15
Number of external interfaces 5 7 10

This count total isn't the number of function points. To get those we have to use the following formula:

FP= count total x [0.65 + 0.01 x SUM(Fi)]
The only part of the formula we haven't explained yet is the SUM(Fi) part. This is anumber that says something about the Technical complexity. It is generated bij giving a rate on a scale of 0 to 5 for each of the next questions. The hig her the rate the more important the function is.
  1. Does the system require reliable backup and recovery?
  2. Are datacommunications required?
  3. Are there distributed processing functions?
  4. Is preformance critical?
  5. Will the system run in an existing, heavuly utilized operational enviroment?
  6. Does the system require on-line data entry?
  7. Does the on-line data entry require the input transaction to be build over multiple screens or operations?
  8. Are the master files updated online?
  9. Are the input, outputs, files or inquiries complex?
  10. Is the internal processing complex?
  11. Is the code designed to be reusable?
  12. Are conversions and installation included in the design?
  13. Is the system designed for multiple installations in different organizations?
  14. Is the applications designed to facilitate change and ease of use bij the user?
The final step is to get from function points to lines of code. That can be done by multiplying the number function points with a factor that is different for every programming language. This factor discribes how many source lines it takes to implement 1 function point.


Boehm, Barry W. (1981) Software engineering economics
Katwijk, J. van (1994) Inleiding software engineering
Pressman, Roger S.
(adapted by Darrel Ince)
(1994) Software engineering
"A practitioner's approach"