06 Cost and Schedule Estimation After COCOMO

Learning objectives

After this chapter you should be able to:

1. Compute a COCOMO II post-architecture estimate, say which activities its effort covers, and apply its reuse and automatic-translation adjustments.
2. Explain Brooks's law and why adding people to a late project can make it later.
3. State COCOMO's load-bearing assumption, apply the negation test, and say what a fair test of the verdict requires.
4. Build an agent-aware cost model whose terms reconcile with a complete work log, and present its estimate as a range with stated scenarios.
5. Compare that model with COCOMO II at its strongest on held-out projects.
6. Restate Brooks's law for agent teams in terms of review capacity.

Opening case

A composite case, not a real engagement.

A consultant is asked to price a fixed-scope internal tool for a regional logistics company: a dispatch dashboard of about 120 function points, which she converts to roughly 6,000 lines of Java. COCOMO II at nominal settings gives about 21 person-months, over 3,200 hours. Knowing her team uses coding agents heavily, she tries the model's adjustments. The tool-use multiplier at its most favorable value gives about 16 person-months. Treating the generated code as adapted code her team must assess and understand gives about 15. Both are far too high, so she discounts by gut feel and bids 800 hours.

The chapter continues from here.

What the chapter covers

1. 6.1 The classical method
   • 6.1.1 Why estimate at all
   • 6.1.2 COCOMO II
   • 6.1.3 Why the exponent is greater than one
   • 6.1.4 A worked example: the naive baseline
   • 6.1.5 Brooks's law
   • 6.1.6 Reuse, translation and local calibration
   • 6.1.7 What it got right
2. 6.2 The assumption it depends on
3. 6.3 What agents change
   • 6.3.1 Generation cost falls; comprehension cost doesn't
   • 6.3.2 What COCOMO II's mechanisms can and cannot say
   • 6.3.3 Size returns, in a different place
   • 6.3.4 New cost drivers
   • 6.3.5 Brooks's law for agents
4. 6.4 The verdict
5. 6.5 What replaces it: an agent-aware cost model
   • 6.5.1 The effort equation
   • 6.5.2 The schedule equation
   • 6.5.3 The same example, re-estimated
   • 6.5.4 Which parameter matters most, and how wide the range is
   • 6.5.5 Calibrating on your own data
   • 6.5.6 COCOMO II at its strongest, compared fairly
   • 6.5.7 What the replacement keeps
6. 6.6 Lab: Pre-registered estimates
7. 6.7 What would make this verdict false

Lab and prediction

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

• P4 Agent-aware cost model has lower error against actuals than COCOMO II calibrated on delivered LOC; tested on held-out projects against COCOMO II at its strongest

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

• COCOMO II prices the whole development, requirements to acceptance test, through code size, with mechanisms for reuse, automatic translation and local calibration of A. Its nominal run on Dispatch (about 3,200 hours) is a naive baseline, not its strongest form.
• Load-bearing assumption: effort is a function of the size of human-written code, with coefficients fitted on projects where people wrote it. Delivered lines are not unrelated to effort; alone, they are inadequate.
• Verdict: breaks. The variables I expect to dominate (lines presented, review rate, properties, steering, rework) are not in the model. This is a prediction for a held-out test that has not yet been run (Section 6.5.6), not a result of fitting the project being scored.
• Replacement: H = H_spec + H_steer + (1 + ρ)(H_review + H_verify) + H_comp. Every hour belongs to one term (γ counts first presentations, ρ everything after), and a crosswalk sends every log category to a term, with other unmodeled.
• Dispatch: 105 hours in the base case, within a range of 90 to 200; the review terms move it most.
• Brooks's law for agents: adding agents raises generation, not review, so past review capacity it lengthens the queue.

Key terms

COCOMO II

the Constructive Cost Model, revised 2000; effort and schedule from size, scale factors and effort multipliers.Also used in 1, 2, 5, 18

Equivalent size (ESLOC)

adapted code converted to equivalent new lines through AAM, built from DM, CM, IM, AA, SU and UNFM.

Automatic translation (AT, ATPROD)

percent of code translated by tool, and its productivity, priced apart from development.

Scale exponent (E)

the power on size in COCOMO II; E > 1 means diseconomy of scale.

Brooks's law

adding people to a late software project makes it later.Also used in 8, 18

Cone of uncertainty

the narrowing range of estimate error as a project progresses.

Naive baseline

COCOMO II at default settings with no local calibration.

Generation ratio (γ)

first-pass lines presented for review per line delivered, each counted once.Also used in 5, 7, 11

Review rate (r)

lines reviewed carefully per hour; 400 is this book's illustrative figure, the fast end of verified rates.Also used in 2, 3, 5, 7, 11, 12, 18

Steering (H_steer)

prompting, hand-coding and debugging per agent task, t_s × n.Also used in 3, 5, 7, 11, 12, 13, 18

Rework fraction (ρ)

re-review, re-verification and re-prompting after defects, as a share of first-pass effort.Also used in 3

Leave-one-project-out

estimating each project from a model fitted to the others.

Verification debt

the gap between code generated and code verified (Hassan 2026, §10.1, pp. 289–290).

Magnitude of relative error / PRED(25)

the error of one estimate; the share of estimates within 25%.Also used in 18

Connections

Where this chapter and another point to each other most often.

• Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
  The measurements graded in Section 2.6 point the same way: more output and more review time, a dated slowdown for experienced developers using early-2025 tools, and weaker delivery outcomes.
• Chapter 3: Life-Cycle Models When Iteration Is Cheap
  From Chapter 3: It is the schedule bound of Section 6.5.2 applied to one loop.
• Chapter 4: Requirements as the Primary Artifact
  From Chapter 4: It is the dispatch dashboard of Chapter 6, seen from the specification side.* The ticket was four sentences, written by a consultant after a thirty-minute call with a logistics company's operations manager. "Dispatchers can reassign jobs to other drivers.
• Chapter 5: Size Estimation: What Function Points Still Measure
  It can be converted from function points (Chapter 5). - A is a constant calibrated from the project database.
• Chapter 7: Project Management and Where Value Is Earned
  From Chapter 7: Table 7.3 gives the first level for Dispatch, the dashboard from Chapter 6. ### 7.1.3 The critical path method Kelley and Walker (1959) presented the critical path method (CPM) for scheduling activities with durations and precedence relations. 1.
• Chapter 8: Coordination at Scale: Shared Context vs. Shared Messages
  From Chapter 8: The assumption is load-bearing; secondary ones (limited working memory, Chapter 10; training time, Chapter 6) leave the logic intact when negated.
• Chapter 9: Risk Management: Project Risk and Adversarial Risk
  That third choice belongs in the risk register (Chapter 9) as a decision, with the unreviewed fraction recorded, not as something that happens by default. ### 6.5.3 The same example, re-estimated Return to the dispatch dashboard.
• Chapter 10: Design for Change, and for Agents
  From Chapter 10: An excerpt for Dispatch: Three Do Not lines come from defects in Chapter 6's opening case: the nonexistent dependency, the access check missing from the API, and tests written to accept a defect.
• Chapter 11: Construction When Code Is Cheap
  Steering takes t_s = 1/3 hour for each of n = 30 agent tasks (6,000 lines at up to 200 delivered lines per task; Section 11.5.1).
• Chapter 12: Reviews: Inspecting Evidence, Not Diffs
  Does it plausibly transfer to agent-generated code, which may contain different kinds of defects (Chapter 12)?
• Chapter 13: Testing, Evaluation, and Tests as Steering
  From Chapter 13: State what evidence would overturn the verdict. ## Opening case A composite case, not a real team. The dispatch dashboard from Chapter 6 reaches review with a strong-looking report: 214 tests, all passing, 93% line coverage, a green CI badge.
• Chapter 14: Configuration Management When Agents Commit
  From Chapter 14: Chapter 6 assumed γ = 2.0, so a 6,000-line system presents about 12,000 lines for review.
• Chapter 15: Reliability of Nondeterministic Systems
  Reading faster looks cheaper but only moves the cost into rework and defects, which ρ and Chapter 15's reliability analysis will catch later.
• Chapter 16: Roles and the Four Conditions for Assurance
  An estimate requested from the agent that will do the work is a self-report (Chapter 16). ### 6.3.5 Brooks's law for agents Two of Brooks's three mechanisms weaken.
• Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
  Likewise an actual inside a range produced by refitting parameters is compatible with the model; it does not show the model is right (Section 18.6). ### 6.5.6 COCOMO II at its strongest, compared fairly A replacement should beat the best version of what it replaces.

See it on the map

Further reading

• Boehm et al. (2000), Software Cost Estimation with COCOMO II. The full model, its calibration and its rationale. Read chapter 2 for the model and the sections on local calibration.
• USC CSE (2000), COCOMO II Model Definition Manual. The primary source here: reuse (§2.4), automatic translation (§2.6), what the effort covers (§6) and calibrating A (§7).
• Brooks (1975), The Mythical Man-Month, chapter 2. The clearest account of why people and months are not interchangeable.
• Becker et al. (2025). The randomized trial on AI tools and experienced developers; read the method section to see how productivity can be measured rather than reported.
• McConnell (2006), Software Estimation: Demystifying the Black Art. The practitioner's guide to estimation discipline.