Estimation·Playbook
DARK
SE423 · Software Project Management · Chapter 03

You can't schedule
what you can't size.

Estimating a software project is like guessing how long your drive home will take: you can use experience ("I've done this before"), an average, or run the numbers. None of it is exact — most software estimations are off by 25–100% — but a good estimate is a disciplined, repeatable guess, not a shrug. This chapter walks the full chain: size → effort → schedule, the math behind three-point and COCOMO estimating, and the human politics of presenting a number nobody wants to hear.

Size → Effort → Schedule
Three-Point & PERT math
COCOMO worked examples
Function Points
O M P (O + 4M + P) / 6
§ 01 — WHAT IS ESTIMATION

A disciplined guess, not a promise

Estimation is difficult because of evolving requirements, technical unknowns, team skill/availability, and external dependencies. Remember: an "exact estimate" is not possible.

📏
Memory hook
"See Every Schedule" — Size, Effort, Schedule.
The basic estimation process, always in this order: 1) estimate the size of the product, 2) estimate the effort (person-months), 3) estimate the schedule. Note: not every project explicitly performs all three steps.
Where estimates get created or refined
Strategic planning — aligns project goals with organizational capacity/timelines.

Feasibility study / SOW (Statement of Work — defines scope, deliverables, timelines, responsibilities) — determines whether the project is viable.

Proposals — justify cost, scope, timeline to stakeholders/clients.

Vendor & sub-contractor evaluation — compares bids, assesses realism, negotiates.

Project planning (iteratively) — refines estimates as more information appears.
Target vs. Committed dates
Target date: proposed by business or marketing. Do not commit to this too soon — learn to say no, and how to say it.

Committed date: what the team agrees to, based on actual planning, after a schedule has been developed.
Rule of thumb from class: the "get home from class today" exercise — you estimate using experience and something like a historical "average," but for most software projects there is no such reliable average.

As project size increases, so does uncertainty

post-requirements variance

Variance from post-requirements estimates grows sharply with size — measured in Function Points (FPs):

Project size FP range Typical variance
Small 10–99 FPs 7%
Medium 100–999 FPs 22%
Large 1,000–9,999 FPs 38%
Very large > 10,000 FPs 51%
Takeaway: push back on target dates, and understand that variance is normal — not a sign you did the estimate wrong.
§ 02 — THE CONE OF UNCERTAINTY

Estimates converge as the project moves forward

The upper curve is the maximum possible overestimation; the lower curve is the maximum possible underestimation. Early estimates (feasibility/proposal stage) can swing from 0.25x to 4x the actual scope. As the project moves through requirements gathering, design, and development, the curves converge toward 1x — the estimate becomes more accurate and reliable.

Why this matters: a number given at kickoff and a number given after requirements are locked are not the same kind of promise — treat them differently when communicating to stakeholders.
4x overestimate 0.25x underestimate 1x actual Time / project progress →
§ 03 — ESTIMATION METHODOLOGIES

Six ways to arrive at a number

🧭
Memory hook
"Every Team Builds Amazing Prices, Precisely."
Expert Judgment · Top-down · Bottom-up · Analogy · Priced to Win · Parametric/Algorithmic. Note: Analogy, Expert Judgment, and Algorithmic methods can all also be "types" of Top-down estimation.
🧠

Expert Judgment

Someone with recent experience on a similar project gives a "guesstimate." Accuracy depends on their real expertise, and the comparable application must be accurately chosen.

🔽

Top-down

Starts with an overall project estimate, then breaks it into components. Useful early, when only high-level scope is known.

✓ Fast, strategic, effective early
✗ May overlook task-level complexity
🔼

Bottom-up

Build a WBS (Work Breakdown Structure), identify individual tasks, then sum from the bottom up. Needs a well-defined scope.

✓ More accurate, granular
✗ Time-consuming; needs detail
🪞

Analogy

Compares the current project to a sufficiently similar past project (technology, type, organization) using comparable attributes like # of inputs/outputs.

✓ Based on real historical data
✗ Hard to "match" projects; no two are exact
🏷️

Priced to Win

Estimation driven by competitive pricing or client budget (via an RFQ — Request for Quote). The quote may not reflect actual cost or effort required.

✓ Aligns with market expectations
✗ May undercut realistic effort → overruns
🧮

Parametric / Algorithmic

Uses mathematical models and historical data to generate estimates automatically — COCOMO, Function Point analysis, and similar.

Priced to Win — the "priced to lose" trap

RFQ risk

Vendors need market intelligence (previous bids, client budget expectations — competitor pricing itself is not public) to price competitively. Some vendors intentionally underbid to win the contract, knowing they'll cut corners, request scope changes later, or absorb losses for strategic reasons (e.g. market entry). The purchaser must watch the trade-off: is the low price realistic, or will quality/scope suffer?

Wideband Delphi

group consensus

A group-consensus approach — Rand Corp. used the original Delphi method in the 1940s to estimate future projects.

The process

1. Present experts with a problem and response form — they fill out initial estimates independently.
2. Conduct group discussion, collect anonymous opinions, then share feedback — this surfaces hidden factors and clarifies misunderstandings.
3. Repeat discussion & iterate until consensus.

Advantages / Disadvantages
+ Easy, inexpensive, uses expertise of several people; doesn't require historical data.

− Difficult to repeat; may fail to reach consensus, reach the wrong one, or everyone may share the same bias.
§ 04 — ALGORITHMIC MEASURES

Lines of Code vs. Function Points

LOC and Function Points are the two most common algorithmic size measures — though most projects actually use neither. Other possible measures: number of bubbles on a DFD, number of ERD entities, number of processes on a structure chart.

Lines of Code (LOC)

code-based
Advantages
Commonly understood, intuitive metric (no matter what language); permits specific comparison; actuals are easy to measure once code is written.
Disadvantages
Hard to estimate early (before requirements/design are clear); counts vary by language, reusable components, and programmer style (avg. productivity ≈ 3,000 LOC/yr); ignores many costs (requirements, UI design, etc.); rewarding developers on LOC can incentivize bloated code; auto-generated/code-generator output inflates LOC without reflecting real effort.

Function Points

functionality-based

Software size measured by the number and complexity of the functions it performs — more methodical than a raw LOC count. Language-independent, which is exactly what LOC is not. Variants include Feature Points and Object Points.

§ 05 — FUNCTION POINT PROCESS

Four steps from function count to FP total

Step 1

Count business functions per category

Categories: outputs, inputs, DB inquiries, files/data structures, and interfaces.

Step 2

Apply a Complexity Factor to each

Rate each function Simple, Average, or Complex; apply a weighting multiplier (0–15). This produces the "unadjusted function-point total."

Step 3

Compute and apply an "influence multiplier"

Based on 14 factors rated 0–5 (performance requirements, data communications, transaction rates, reusability, etc.).

Step 4

Result: the "function point total"

Used in comparative estimates.

Complexity multiplier table

used in three-point FP example
Function type Low Average High
External inputs ×3 ×4 ×6
External outputs ×4 ×5 ×7
External queries ×3 ×4 ×6
Internal logical files ×7 ×10 ×15
External interface files ×5 ×7 ×10
Each function is placed into one of these five categories and multiplied by the appropriate weight for its Low/Average/High complexity — this is the mechanism behind Step 2's "unadjusted function-point total."
§ 06 — EFFORT ESTIMATION & DURATION

Effort, duration, and the two clocks that never agree

Once you know the "size" (FPs, LOC, etc.), determine the "effort" needed to build it, in person-months / staff-months. Models are Empirical (historical data), Mathematical (formulas/algorithms, e.g. Effort = a × Sizeb), or Subjective (expert judgment / team intuition, e.g. Wideband Delphi). Effort depends on the efficiency/productivity of people: motivation, ability of the team, application experience, range of personnel.

⏱️
Memory hook
"Duration Divides, Effort multiplies."
Duration is the elapsed time in business working days (excludes weekends, holidays, other nonworking days) — it is not the same as work effort.
Duration = Work Effort ÷ Number of People
→ more useful for scheduling.
Work Effort = Duration × Number of People
→ more useful for cost estimation. Work effort is the labor required to complete an activity. Example: five people reviewing a document — the duration may be 10 hours, but the work effort is 50 staff-hours.
Labor time vs. clock time
Labor time: actual effort required (staff-hours).
Clock time: elapsed calendar time needed.

Example: a task needing 40 hours of labor typically needs at least 50 business hours of clock time. Why? Productivity is usually only 50–75% of a business day — a developer might get just 5–6 productive hours out of 8 office hours (meetings, email/communication, breaks, fatigue, task-switching/setup, etc.).
Causes of variation in actual activity duration
Varying skill levels — estimate assumes an average-skilled engineer; actual assignment may differ.

Unexpected events — natural events, vendor delays, power failures, etc.

Efficiency of work time — every interruption costs extra time to regain the prior productivity level.

Mistakes and misunderstandings — rework impacts duration even in organizations with a documented process.
Useful rule of thumb: keep all times in the same units — don't mix increments. Schedule everything in hours, then convert to days/fractions as a last step. (Most PM software enforces this via a uniform time unit and increment.)
§ 07 — THREE-POINT ESTIMATING

Turning three guesses into one number

Used whenever there's potential variance in an estimate — because of uncertainties in Duration, Effort, and Size. Three-point techniques mathematically combine three estimates: Most likely (M), Optimistic (O), and Pessimistic (P) (i.e. best-case, worst-case, expected — gathered from experts).

🎯
Memory hook
"One meeting, four likelies, one pessimist — divide by six."
The weighted (PERT) formula gives the Most Likely value 4× the weight of Optimistic or Pessimistic, then divides by the total of 6 "votes" (1 + 4 + 1). This assumes a Gaussian (beta) distribution of estimates.
Estimate = (M + O + P) / 3
Basic three-point: a plain average of the three estimations.
Estimate = (O + 4M + P) / 6
PERT-weighted: weights the Most Likely value 4×, per the Gaussian distribution assumption.

Worked example — three-point LOC estimation of a CAD program

PERT formula

CAD program to represent mechanical parts. Estimated LOC = (Optimistic + 4×Most Likely + Pessimistic) / 6, applied per major software function:

Major software function ID Optimistic Most Likely Pessimistic Estimated LOC
User interface and control facilities UICF 1,500 2,300 3,100 2,300
Two-dimensional geometric analysis 2DGA 3,800 5,200 7,200 5,300
Three-dimensional geometric analysis 3DGA 4,600 6,900 8,600 6,800
Database management DBM 1,600 3,500 4,500 3,350
Computer graphics display features CGDF 3,700 5,000 6,000 4,950
Peripheral control PC 1,400 2,200 2,400 2,100
Design analysis modules DAM 7,200 8,300 10,000 8,400
Estimated lines of code 23,800 33,400 41,800 33,200
Check the math for UICF: (1,500 + 4×2,300 + 3,100) / 6 = (1,500 + 9,200 + 3,100) / 6 = 13,800 / 6 = 2,300 ✓ — and the row totals sum to the same 33,200 as summing all seven per-function estimates.

Reserve analysis

contingency reserves

To improve schedule accuracy and resilience, contingency or time reserves can be added to allow for schedule risks (uncertainty). Contingency reserves may be used or adjusted as more precise project information becomes available — this is known as buffer time. Do not confuse it with slack time.

§ 08 — COCOMO

The COnstructive COst MOdel

An algorithmic software cost estimation model. Uses a basic regression formula with parameters derived from historical project data and current project characteristics. Input: LOC. Output: person-months (effort).

🔤
Acronym breakdown
CO-CO-MO
COnstructive COst MOdel — the "constructive" part refers to how the model incrementally builds the estimate up from size, mode, and (in the Intermediate version) cost drivers.
🌱

Organic

Small, simple projects, experienced teams, flexible requirements. 2–50 KLOC, stable, little innovation.

🔗

Semi-Detached

Medium complexity, mixed experience, some constraints. 50–300 KLOC, average abilities, medium time constraints.

🛰️

Embedded

Complex, needs creativity, tightly coupled with strict requirements (e.g. real-time / safety-critical). >300 KLOC, large team, severe constraints.

🧬
Memory hook
"Old Systems Expand" — Organic → Semi-detached → Embedded.
As you move O → S → E, both the coefficient a and the exponent b increase — bigger, more complex projects cost proportionally more effort per KLOC.

Basic COCOMO constants

a, b, c, d
Mode a b c d
Organic 2.4 1.05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
a, b
used to calculate Effort from KLOC
c, d
used to calculate Time (TDEV) from Effort
E = a × (KLOC)b
Basic COCOMO — Effort. E is Effort in staff-months. a and b are coefficients determined by project mode. KLOC is thousands of lines of code.
TDEV = c × (E)d
Development time. TDEV is time for development (months); c and d are constants (see table above); E is the effort just computed.
SS = E ÷ TDEV
Average Staff Size. SS = Effort Applied ÷ Development Time = staff-months ÷ months = staff. COCOMO's three primary outputs are Effort (E), Time to Develop (TDEV), and Staff Size (SS).
P = Size ÷ E
Productivity. P = [KLOC] ÷ [staff-months]. Once you have Size and Effort, Productivity tells you how efficiently your team is (or should be) working.

Worked example — 200 KLOC across all three modes

Effort only
Mode Calculation Effort (staff-months)
Organic 2.4 × (200)1.05 626
Semi-Detached 3.0 × (200)1.12 1,133
Embedded 3.6 × (200)1.20 2,077
Feeding each Effort value into TDEV = 2.5 × (E)d with its mode's d (0.38 / 0.35 / 0.32 respectively) happens to converge on the same ≈29 months for all three modes here — a reminder that TDEV grows much more slowly than Effort as complexity rises.

Complete example — Organic

7.5 KLOC

Suppose an organic project has 7.5 KLOC:

Item Organic
Effort (staff-months) 2.4×(7.5)1.05 = 20
Development Time 2.5×(20)0.38 = 8
Average Staff 20 ÷ 8 = 2.5
Productivity 7,500 ÷ 20 = 375 LOC/staff-mo
Conclusion: target productivity is 375 lines of code monthly, on average, per staff member.

Complete example — Embedded

50 KLOC

Suppose an embedded project has 50 KLOC:

Item Embedded
Effort (staff-months) 3.6×(50)1.20 = 394
Development Time 2.5×(394)0.32 = 17
Average Staff 394 ÷ 17 = 23
Productivity 50,000 ÷ 394 = 127 LOC/staff-mo
Compare: the embedded project needs ~23 people instead of ~2.5, and each person produces roughly a third of the LOC/month — complexity, not just size, drives cost.

Intermediate COCOMO — Cost Drivers

15 multipliers

Basic COCOMO assumes effort is purely a function of LOC and a couple of constants — unrealistic, since no system's effort/schedule can be calculated from LOC alone. Intermediate COCOMO adds 15 cost drivers, each rated Very Low → Extra High, grouped into four attribute categories.

Four cost-driver categories
Product attributes Hardware attributes Personnel attributes Project attributes
Examples: required software reliability, size of application database, complexity of the product (Product); run-time performance constraints, memory constraints (Hardware); analyst capability, application experience, programming language experience (Personnel); use of software tools, required development schedule (Project).
Why cost drivers are used
They're statistically significant to project cost, and they're not correlated to project size (KLOC) — so they capture what raw size can't.

To obtain the multiplier: look up each driver's rating on the grid, then multiply them all together — the product is C, the effort adjustment factor.
E = a × (KLOC)b × C
Same a, b as Basic COCOMO; C is the effort-adjustment factor — the product of all 15 cost-driver ratings.
COCOMO advantages
Based on history; repeatable; unique adjustment factors; has different modes; works well on similar projects; highly calibrated; well-documented; easy to use.
COCOMO limitations
Ignores requirements volatility, documentation, customer "skill," software safety; oversimplifies security; ignores personnel turnover and many hardware issues; personnel experience ratings may go obsolete; you must already know the cost drivers and be able to predict project size — its single biggest weakness is needing a reliable LOC estimate as input.
§ 09 — ESTIMATION ISSUES

The politics and pitfalls of a number

Structural issues
Quality estimates are needed early, when information is limited. Precise data is only available at the end — but is it "not needed anymore"? What about the next project? At project end you should determine just how accurate your original estimate was. Best estimates are based on past experience; for many software projects there is little or no data (technologies change, historical data unavailable, wide variance in project types, subjective nature of software estimation).
Politics of estimation: you may anticipate a "cut" by upper management, so you add some contingency duration.
Over- vs. Under-estimation
Over-estimation risks Project may not get funded (100%-success conservative estimates push funding probability toward zero); Parkinson's Law (work expands to fill time allowed); danger of feature/scope creep; "double-padding" — both the project member and the business manager pad the number.
Under-estimation risks Quality issues (key phases like testing get shortened); inability to meet deadlines; morale and team motivation issues.
§ 10 — FINAL NOTES

Reuse, Agile, deadlines, and how you say the number

Code reuse & estimation

New / Modified / Reused

Code reuse is not free — understanding, adapting, testing, and integrating reused code still consumes time and effort.

If code is more than 50% modified, it's estimated as fully "new." Reuse factors have a wide range: reused code takes ~30% of the effort of new code; modified code takes ~60% of new. Integration effort with reused code is almost as expensive as with new code.

Estimation for Agile

user stories

Agile estimation starts with user stories/scenarios, each treated as a mini-project.

Decompose the scenario into engineering tasks (UI, backend, ...). Estimate each task separately (historical data, empirical model, or experience) — scenario volume can be estimated in LOC, FP, use-case count, etc. Sum task estimates for a total scenario estimate (translating volume to effort via historical data or COCOMO), then sum all scenario estimates in the increment for an increment estimate.

Know your deadlines

real vs. artificial
Real deadlines
Tied to an external event; must be met for the project to be a success. Ex: end of financial year, contractual deadline, Y2K.
Artificial deadlines
Set by an arbitrary authority; may have some flexibility if pushed on.

Estimation presentation (communication)

how you say the number

How you present an estimate can have a huge impact. Techniques:

Technique Example
Plus-or-minus qualifiers "6 months ± 1 month" — communicates a central estimate with a buffer.
Ranges "6–8 months."
Risk quantification ± with added info about uncertainty — e.g. "+1 month if new tool isn't working as expected," "−2 weeks if hiring new developers happens sooner."
Cases Scenario-based estimates: Best / Planned / Current / Worst case.
Coarse dates Useful when finer estimates aren't feasible, e.g. "Q3 of 2026."
Confidence factors "April 1 with 10% probability, July 1 with 50% probability," etc.

Final estimates — aggregation

Contingency vs. Management Reserves

For time/cost estimates: aggregate into larger units (Work Packages, Control Accounts, etc.), perform risk analysis to calculate Contingency Reserves (controlled by the PM), and add Management Reserves — set aside from total company funds to cover unforeseen risks/changes, which require Change Control activities to access.

Bottom

Activity + Activity + Activity

Individually estimated tasks.

↑

Work Package + Work Package + Work Package

Activities roll up into work packages.

↑

Control Account + Control Account + Control Account

Work packages roll up into control accounts.

↑

Project Estimate + Contingency Reserves

Control accounts + PM-controlled contingency = the project estimate.

↑

Cost Baseline + Management Reserves

Project estimate + contingency, plus company-level management reserves.

Top

Cost Budget

The final, fully aggregated number.

Estimation guidelines
Estimate iteratively — a process of gradual refinement. Make your best estimate at each planning stage, then refine estimates and adjust plans as you go. Balance too many revisions against too few.
Other estimation factors
Account for resource experience/skill (up to a point — often needed more on the "low" end, e.g. a new/junior person). Allow for "non-project" time and common tasks (meetings, phone calls, web surfing, sick days). Commercial estimation tools exist but typically require configuration from past data.
Human behavior around deadlines
🌀
Parkinson's Law
"Work expands to fill the time available." Give a task 3 weeks instead of 1, and it will somehow take 3 weeks.
🎓
The Student Syndrome
Procrastination until the last minute — "cramming" — regardless of how much lead time was given.
§ 11 — CHEAT SHEET

Every formula and method, one scroll away

Concept Formula / Rule
Basic estimation process Size → Effort (person-months) → Schedule
Duration Duration = Work Effort ÷ Number of People (scheduling)
Work Effort Work Effort = Duration × Number of People (cost estimation)
Three-point (Basic) Estimate = (M + O + P) / 3
Three-point (PERT) Estimate = (O + 4M + P) / 6
COCOMO — Effort (Basic) E = a(KLOC)b
COCOMO — Effort (Intermediate) E = a(KLOC)b × C, where C = product of 15 cost-driver ratings
COCOMO — Development time TDEV = c(E)d
COCOMO — Average Staff Size SS = E ÷ TDEV
COCOMO — Productivity P = Size (KLOC) ÷ E (staff-months)
COCOMO modes Organic (2–50 KLOC) · Semi-Detached (50–300 KLOC) · Embedded (>300 KLOC)
Reserves Contingency reserves (PM-controlled, known risks) vs. Management reserves (company funds, unforeseen risks, need change control)
Methodologies Expert Judgment · Top-down · Bottom-up · Analogy · Priced to Win · Parametric/Algorithmic
§ 12 — COMMON MISTAKES

Where exam answers usually go wrong

Eight places this chapter's terminology and formulas get tangled — drill these until the "right" side is automatic.

1. Duration vs. Work Effort — dividing the wrong way
✗ WRONG"Duration = Work Effort × Number of People" — students flip the operator under exam pressure.
✓ RIGHTDuration = Work Effort ÷ Number of People (useful for scheduling). Work Effort = Duration × Number of People (useful for cost). More people shortens duration but doesn't change total effort.
2. Basic three-point average vs. PERT-weighted
✗ WRONGAlways using (O + M + P) / 3 because it's "the average," even when the question says "weighted" or "PERT."
✓ RIGHTBasic = (M + O + P) / 3, a plain average. PERT/weighted = (O + 4M + P) / 6, which weights Most Likely 4× under the Gaussian-distribution assumption — the two give different numbers on the same inputs.
3. Target date vs. Committed date
✗ WRONGTreating a marketing-proposed "target" date as something the team has already agreed to.
✓ RIGHTA target date is proposed by business/marketing — do not commit to it too soon. A committed date only comes after the team has built an actual schedule.
4. LOC vs. Function Points — which is language-independent?
✗ WRONGSaying Function Points vary by programming language the way LOC does.
✓ RIGHTLOC counts vary by language, reusable components, and programmer style. Function Points measure functionality, not code — they are far less language-dependent, which is the whole reason FP analysis exists.
5. Mixing up COCOMO's a/b/c/d coefficients across modes
✗ WRONGPlugging Semi-Detached's a=3.0 into an Embedded-mode problem, or forgetting that a and b (not c and d) compute Effort.
✓ RIGHTa, b → Effort from KLOC. c, d → Time (TDEV) from Effort. Coefficients rise from Organic (2.4/1.05) → Semi-Detached (3.0/1.12) → Embedded (3.6/1.20) — always match the mode to the project description first.
6. Contingency Reserves vs. Management Reserves
✗ WRONGCalling both "the buffer" and treating them as interchangeable or PM-accessible at will.
✓ RIGHTContingency reserves cover known/identified risks and are controlled by the PM, added inside the project estimate. Management reserves cover unforeseen risks, are drawn from total company funds, and require formal Change Control to access.
7. "40 hours of labor = 40 hours on the calendar"
✗ WRONGAssuming labor time and clock/duration time are the same thing.
✓ RIGHTProductivity is typically only 50–75% of a business day, so 40 hours of labor needs roughly 50 business hours of clock time — meetings, communication, breaks, and task-switching all eat into the day.
8. "A bigger estimate is always the safer choice"
✗ WRONGPadding an estimate as much as possible to "guarantee" success.
✓ RIGHTOver-estimation has its own risks: conservative estimates that guarantee 100% success may push funding probability toward zero, invite Parkinson's Law (work expands to fill the time), and encourage scope creep or "double-padding" by both the team member and the manager.
§ 13 — POP QUIZ

Click a question to reveal the answer

No reload, no tracking — just click each question (or its "Reveal" button) to check yourself.

1. What is the correct order of the basic estimation process?
Size → Effort → Schedule. You can't estimate the effort (person-months) until you know the size, and you can't build a schedule until you know the effort.
2. A task needs 40 hours of labor. Why should you budget more than 40 clock-hours to finish it in a normal business setting?
Because productivity is usually only 50–75% of a business day — a developer might only get 5–6 productive hours out of 8 office hours due to meetings, communication, breaks, and task-switching. 40 labor-hours needs roughly ~50 business hours of clock time.
3. Which methodology carries the risk that a vendor deliberately underbids, planning to cut corners or request scope changes later?
Priced to Win (sometimes called "priced to lose" when a vendor knowingly underbids for strategic reasons, e.g. market entry).
4. Using the PERT formula, compute the estimate for Optimistic = 10, Most Likely = 14, Pessimistic = 24.
(10 + 4×14 + 24) / 6 = (10 + 56 + 24) / 6 = 90 / 6 = 15.
5. A COCOMO project is classified "Embedded." Which best describes it?
Complex, creativity-needed, tightly coupled systems with strict requirements (e.g. real-time or safety-critical), typically >300 KLOC — not the small/flexible "Organic" case or the medium "Semi-Detached" case.
6. What's the difference between Contingency Reserves and Management Reserves?
Contingency reserves cover identified/known risks, are controlled by the PM, and sit inside the project estimate. Management reserves cover unforeseen risks, come from the company's total available funds, and require formal Change Control to access.
7. A COCOMO project has Effort E = 100 staff-months and TDEV = 10 months. What's the average staff size?
SS = E ÷ TDEV = 100 ÷ 10 = 10 staff.
8. Name the two behavioral phenomena from "Final Notes" that explain why people don't finish work early even with plenty of lead time.
Parkinson's Law ("work expands to fill the time available") and the Student Syndrome (procrastination/cramming until the last minute).
§ 14 — PRACTICE LAB

Full worked calculations, exam-style

Grab a calculator. These use the exact formulas above on new numbers, worked step by step.

1. A project is sized at 15 KLOC and classified Organic (a=2.4, b=1.05). Calculate the Effort using Basic COCOMO.
E = 2.4 × (15)^1.05 ln(15) = 2.708 → 2.708 × 1.05 = 2.843 e^2.843 ≈ 17.18 E = 2.4 × 17.18 ≈ 41.2 staff-months
→ E ≈ 41.2 staff-months
Why: plug KLOC and the Organic coefficients directly into E = a(KLOC)^b — no cost drivers needed since this is Basic, not Intermediate, COCOMO.
2. Using the Effort from Q1 (≈41.2 staff-months, Organic mode, c=2.5, d=0.38), calculate the development time (TDEV) and the average staff size (SS).
TDEV = 2.5 × (41.2)^0.38 ln(41.2) = 3.718 → 3.718 × 0.38 = 1.413 e^1.413 ≈ 4.11 TDEV = 2.5 × 4.11 ≈ 10.3 months SS = E ÷ TDEV = 41.2 ÷ 10.3 ≈ 4.0 staff
→ TDEV ≈ 10.3 months, SS ≈ 4 staff
Why: TDEV always takes the just-computed E as its input (TDEV = c(E)^d); SS is simply Effort divided by that duration.
3. A vendor bids well below the estimated realistic cost for a government contract, planning to recover the loss later via change orders. Which estimation approach — and which specific risk within it — does this describe?
→ Priced to Win, specifically the "priced to lose" risk
Why: the estimate is driven entirely by what will win the bid rather than actual cost/effort — exactly the disadvantage called out on the Priced-to-Win slide.
4. Three specialists estimate a task at Optimistic = 8 days, Most Likely = 12 days, Pessimistic = 20 days. Compute both the Basic three-point average and the PERT-weighted estimate, and explain why they differ.
Basic: (8 + 12 + 20) / 3 = 40 / 3 ≈ 13.3 days PERT: (8 + 4×12 + 20) / 6 = (8 + 48 + 20) / 6 = 76 / 6 ≈ 12.7 days
→ Basic ≈ 13.3 days · PERT ≈ 12.7 days
Why: PERT weights the Most Likely value 4×, pulling the estimate toward the "expected" case and away from the Pessimistic outlier — so it lands lower than the flat average whenever Pessimistic is far from Most Likely.