Boehm's empirical model — turn a size estimate into person-months and dollars, with calibration knobs you can defend.
| § | Topic | Minutes |
|---|---|---|
| I. | COCOMO 81 → COCOMO II | 10 |
| II. | The COCOMO II equation | 15 |
| III. | Scale factors | 15 |
| IV. | Effort multipliers | 15 |
| V. | Early Design vs Post-Architecture | 10 |
| VI. | Worked example: your group project | 25 |
| — | Discussion: AI assistance in COCOMO | 10 |
| HW9, questions | 10 |
COCOMO 81 (Constructive Cost Model) — Boehm 1981 — fitted an effort-vs-size curve to 63 industrial projects across 3 modes (organic, semi-detached, embedded).
COCOMO II (2000) — re-calibrated against 161 projects, introduced multiple sub-models (Application Composition, Early Design, Post-Architecture), and modernised the cost drivers for object-oriented and component-based development.
COCOMO II is the de-facto reference model in software-economics literature. Modern variants (Use-Case Points, SLIM, PRICE) exist but typically calibrate similar curves on smaller datasets.
Where:
The exponent E typically lands between 1.0 and 1.2 — a slight diseconomy of scale (bigger projects cost disproportionately more).
| Code | Factor | What it captures |
|---|---|---|
| PREC | Precedentedness | How much the team has done before something similar |
| FLEX | Development flexibility | Freedom to vary specs, processes |
| RESL | Architecture / risk resolution | How much architecture work is done up front |
| TEAM | Team cohesion | Quality of cross-team collaboration |
| PMAT | Process maturity | CMMI level or equivalent |
Higher ratings = lower scale factor values = smaller exponent = LESS diseconomy of scale. A mature team building a precedented system scales gracefully; an unprecedented project with low team cohesion compounds painfully.
RELY · DATA · CPLX · RUSE · DOCU
TIME · STOR · PVOL
ACAP · PCAP · PCON · APEX · PLEX · LTEX
TOOL · SITE · SCED
Each EM is rated Very Low → Extra High and translated to a multiplier (≈ 0.71 – 1.43). The product of all 17 EMs forms the second factor in the COCOMO II equation.
The Personnel group has the largest range of impact. Team capability and continuity move the equation more than any other lever.
| Model | When | Inputs | Precision |
|---|---|---|---|
| Application Composition | Pre-spec | Object points (very rough) | ±50% / 200% |
| Early Design | Spec exists | FP / KSLOC + 7 aggregated EMs | ±25% / 50% |
| Post-Architecture | Architecture exists | KSLOC + 17 EMs | ±10% / 20% |
For the group project, use Early Design or Post-Architecture. Don't pretend to precision you can't justify — the rubric rewards defensible assumptions over confident numbers.
Multiply AFP by a language conversion factor (lines per FP):
| Language | LOC / FP |
|---|---|
| C | 128 |
| Java | 53 |
| Python | 42 |
| TypeScript / React | 48 |
| SQL | 21 |
A 53-AFP project in Python: 53 × 42 = 2,226 LOC ≈ 2.2 KSLOC.
| Scenario | E | ∏EM | PM | $ @ $18K/PM |
|---|---|---|---|---|
| Optimistic | 1.03 | 0.70 | 4.7 | $85K |
| Nominal | 1.10 | 1.00 | 6.9 | $125K |
| Pessimistic | 1.17 | 1.40 | 10.3 | $185K |
The pessimistic estimate is more than 2× the optimistic. Reporting only the nominal number hides a real decision — funding a project at the optimistic number guarantees a budget overrun if the pessimistic case materialises.
No agreed answer exists in 2026. In pairs (4 minutes), propose a calibration.
Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju