Q&A

What is the COCOMO model?

By AlgoInsight Team2026-06-07software-engineering

Overview

Estimating how long a software project will take - and how many people it needs - is notoriously hard. COCOMO offers a structured, formula-based approach grounded in empirical data from real projects. It comes in increasingly sophisticated forms: Basic, Intermediate, and Detailed COCOMO. (A later revision, COCOMO II, modernizes it for iterative and component-based development.)

graph TD
    A[Estimated Size in KLOC] --> B[Choose Project Class]
    B --> B1[Organic: small, familiar]
    B --> B2[Semi-detached: medium]
    B --> B3[Embedded: complex, constrained]
    B1 & B2 & B3 --> C["Effort = a × KLOC^b"]
    C --> D["Time = c × Effort^d"]
    D --> E[People = Effort / Time]
    style C fill:#1e1b4b,color:#fff

The Three Project Classes

COCOMO first classifies a project, which sets the model's constants:

Basic COCOMO

Basic COCOMO uses two equations driven by size (KLOC):

Effort (E)      = a × (KLOC)^b      [person-months]
Development time = c × (E)^d         [months]
Average staff    = E / Development time   [people]

The constants by class:

Worked example

A 32 KLOC organic project:

E    = 2.4 × 32^1.05 ≈ 2.4 × 38.18 ≈ 91.6 person-months
Time = 2.5 × 91.6^0.38 ≈ 2.5 × 5.85 ≈ 14.6 months
Staff = 91.6 / 14.6 ≈ 6.3 people

Note the exponent b > 1 for non-organic classes: effort grows faster than linearly with size - the model captures the reality that big projects suffer disproportionate coordination overhead.

Intermediate COCOMO

Basic COCOMO ignores everything but size. Intermediate COCOMO multiplies the effort by an Effort Adjustment Factor (EAF) derived from 15 cost drivers grouped into four categories:

• Product attributes - required reliability, database size, product complexity.
• Hardware attributes - runtime/memory constraints, platform volatility.
• Personnel attributes - analyst capability, programmer capability, experience.
• Project attributes - modern tools, development practices, schedule pressure.

Effort = a × (KLOC)^b × EAF

Each driver is rated (Very Low → Extra High) and contributes a multiplier; the product of all 15 is the EAF. A team of experts on a simple product yields EAF < 1 (less effort); tough constraints push EAF > 1.

Detailed COCOMO

Detailed COCOMO applies the cost drivers per development phase (requirements, design, coding, testing) rather than across the whole project, giving phase-by-phase estimates and greater accuracy at the cost of more input data.

COCOMO II (1990s)

COCOMO II updates the original for modern practices: it supports estimation from function points or object points (not just KLOC), accounts for reuse and COTS components, and adds scale factors for team cohesion, process maturity, and architecture/risk resolution - better fitting iterative and agile-adjacent development.

Strengths and Limitations

Strengths: transparent, repeatable, grounded in empirical data, good for early ballpark estimates and "what-if" analysis.

Limitations: depends heavily on an accurate size estimate (KLOC is hard to predict up front and varies by language); the original assumes a waterfall-like process; constants reflect 1980s data unless recalibrated; KLOC is a poor proxy for value.

Why This Matters in Interviews

COCOMO is a staple of software engineering and project-management exams. Be able to name the three classes, write the Basic effort equation E = a × KLOC^b, explain why b > 1 (super-linear effort growth), and describe how Intermediate COCOMO adds cost drivers via the EAF. Mentioning COCOMO II's move toward function points shows current awareness.

Common Pitfalls

• Confusing the constants between classes.
• Forgetting that effort grows super-linearly with size.
• Treating COCOMO's output as precise rather than an estimate with wide error bars.
• Relying on KLOC when function points would be more stable.

References

• Barry Boehm, Software Engineering Economics (1981).
• COCOMO II resources, USC: http://csse.usc.edu/tools/cocomoii.php

More answers