Lecture Nine · 11 June 2026
09Lecture Nine

Cost Estimation II —
COCOMO II

Boehm's empirical model — turn a size estimate into person-months and dollars, with calibration knobs you can defend.

Instructor
Dr. Zhijiang Chen
Session
No. 09 of 16
Date
11 June 2026
Room
YF302
Duration
110 minutes
Format
Lecture + Workshop
Bring your AFP count from yesterday's homework — we convert it to person-months today.
Lecture IXAgenda02 / 18
Today's Plan

From AFP to person-months.

§TopicMinutes
I.COCOMO 81 → COCOMO II10
II.The COCOMO II equation15
III.Scale factors15
IV.Effort multipliers15
V.Early Design vs Post-Architecture10
VI.Worked example: your group project25
Discussion: AI assistance in COCOMO10
HW9, questions10
Part — One
I

COCOMO —
twenty years of
industry data.

§ ILineage04 / 18
Boehm, 1981 → 2000

From 63 projects to a calibrated model.

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.

Part — Two
II

The equation —
a power-law
with knobs.

§ IIThe equation06 / 18
A power-law in size, with multiplicative adjustments

COCOMO II — Post-Architecture form.

PM  =  A  ×  SizeE  ×  ∏ EMi

Where:

  • PM — effort in person-months (1 PM ≈ 152 person-hours)
  • A — calibration constant (default 2.94)
  • Size — KSLOC (thousands of source lines of code)
  • E — exponent reflecting economies/diseconomies of scale: E = B + 0.01 × Σ SF
  • B — base exponent (default 0.91)
  • EMi — 17 effort multipliers (each typically 0.7 – 1.4)

The exponent E typically lands between 1.0 and 1.2 — a slight diseconomy of scale (bigger projects cost disproportionately more).

Part — Three
III

Scale factors —
five knobs that
set the exponent.

§ IIIThe five08 / 18
SFj ∈ {Very Low, Low, Nominal, High, Very High, Extra High}

Five scale factors.

CodeFactorWhat it captures
PRECPrecedentednessHow much the team has done before something similar
FLEXDevelopment flexibilityFreedom to vary specs, processes
RESLArchitecture / risk resolutionHow much architecture work is done up front
TEAMTeam cohesionQuality of cross-team collaboration
PMATProcess maturityCMMI 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.

Part — Four
IV

Effort multipliers —
seventeen
multiplicative knobs.

§ IVEM groups10 / 18
Seventeen, in four groups

Effort multipliers — the four groups.

Product (5)

RELY · DATA · CPLX · RUSE · DOCU

Platform (3)

TIME · STOR · PVOL

Personnel (6)

ACAP · PCAP · PCON · APEX · PLEX · LTEX

Project (3)

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.

Part — Five
V

Two sub-models —
match the resolution
to the phase.

§ VEarly Design vs Post-Architecture12 / 18
Different lifecycle phases, different precision

Estimate as well as you can — no better.

ModelWhenInputsPrecision
Application CompositionPre-specObject points (very rough)±50% / 200%
Early DesignSpec existsFP / KSLOC + 7 aggregated EMs±25% / 50%
Post-ArchitectureArchitecture existsKSLOC + 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.

Part — Six
VI

A worked example —
from your AFP to
person-months.

§ VIFP → KSLOC14 / 18
Language-specific conversion

Convert AFP to KSLOC.

Multiply AFP by a language conversion factor (lines per FP):

LanguageLOC / FP
C128
Java53
Python42
TypeScript / React48
SQL21

A 53-AFP project in Python: 53 × 42 = 2,226 LOC ≈ 2.2 KSLOC.

§ VIEffort calculation15 / 18
Three scenarios on the same project

PM under optimistic, nominal, and pessimistic ratings.

ScenarioE∏EMPM$ @ $18K/PM
Optimistic1.030.704.7$85K
Nominal1.101.006.9$125K
Pessimistic1.171.4010.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.

Discussion10 minutes16 / 18
A frontier question

How would you adjust COCOMO II to account for AI-assisted development?

No agreed answer exists in 2026. In pairs (4 minutes), propose a calibration.

  • Which EM would you alter? (Hint: TOOL, APEX, PLEX are candidates.)
  • Would you adjust the constant A?
  • Empirical claim to weigh: junior developers +10–30% productivity; senior developers −19% due to verification overhead. Where does this hit the equation?
HomeworkDue Lecture 1117 / 18
Homework 09 — due Saturday 13 June

Apply COCOMO II to your project.

  1. Use your AFP from HW8 (or recompute). Convert to KSLOC for your project's language.
  2. Apply COCOMO II Post-Architecture. List your 5 scale factor ratings and 17 EM ratings with one-sentence justifications each.
  3. Report PM under nominal, optimistic, and pessimistic scenarios. Convert to dollars at a defensible PM rate.
  4. Compare with your FP-only estimate from HW8. Which is more credible — and why?
EndLecture Nine18 / 18
&

Questions & conversation.

Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju