Hong Life CalculatorsUnderstanding the basic COCOMO effort estimator — concept and principle
Basic COCOMO (Constructive Cost Model) turns an estimate of program size in thousands of delivered lines of code (KLOC) into development effort in person-months, a nominal schedule in months and the average team size that schedule implies. Barry Boehm published it in 1981 from data on dozens of completed projects. Today it is mainly used for teaching and early ballpark estimates.
How it is calculated
- Effort E = a × KLOC^b (person-months)
- Schedule D = 2.5 × E^c (months)
- Average team size = E ÷ D (people)
The coefficients depend on the project type:
- Organic (small, experienced team, familiar problem): a = 2.4, b = 1.05, c = 0.38
- Semi-detached (mixed experience, moderate constraints): a = 3.0, b = 1.12, c = 0.35
- Embedded (tight hardware, real-time or regulatory constraints): a = 3.6, b = 1.20, c = 0.32
The principle
The exponent b is greater than 1, so effort grows faster than size: doubling the code more than doubles the work, because larger systems need more coordination, integration and testing. This is called a diseconomy of scale, and it is strongest for embedded projects. The schedule exponent c is well below 1, meaning that calendar time grows much more slowly than effort; big projects are finished by adding people, but not in proportion, since communication overhead limits how far work can be split.
Worked example
- Inputs: 50 KLOC, organic (a = 2.4, b = 1.05, c = 0.38).
- 50^1.05 = 60.802, so E = 2.4 × 60.802 = 145.93 person-months.
- E^0.38 = 145.925^0.38 = 6.643, so D = 2.5 × 6.643 = 16.61 months.
- Team size = 145.925 ÷ 16.608 = 8.79 people on average.
The same 50 KLOC as an embedded project gives about 393.6 person-months, 16.9 months and 23.3 people.
| Size (KLOC) | Effort (person-months) |
|---|---|
| 12.5 | 34.03821329 |
| 25 | 70.47713659 |
| 37.5 | 107.8807788 |
| 50 | 145.9250149 |
| 62.5 | 184.4528033 |
| 75 | 223.3703724 |
| 100 | 302.1420988 |
How to read the result
Treat the numbers as an order-of-magnitude guide. Boehm reported that basic COCOMO estimates were often well off the actual figures, which is why intermediate COCOMO added cost drivers and COCOMO II (2000) replaced it. A schedule much shorter than D usually requires disproportionately more effort.
Common mistakes
- Counting comments, blank lines or generated code as KLOC.
- Picking "organic" for a project with hard real-time or safety constraints.
- Reading the team size as a fixed head count; staffing normally ramps up and down.
- Applying 1981 productivity to modern tooling without adjustment.
Frequently asked questions
How do I estimate KLOC before writing code?
Compare with similar past systems, or count function points and convert them with a language-specific ratio from your own data.
What is the difference between basic COCOMO and COCOMO II?
COCOMO II uses scale factors and effort multipliers for team, process and product traits, and was recalibrated on newer projects.
Why does the team size come out as a fraction?
It is an average over the whole schedule (effort ÷ months), not a hiring plan.
Sources: Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981 · Barry W. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000