Estimation and Scheduling in Software Engineering: COCOMO, PERT and CPM Worked Examples

A size estimate, an effort estimate and a delivery date are three different outputs, but weak solutions often treat them as interchangeable. A functional description of 12 inputs, 8 outputs, 5 enquiries, 4 internal files and 2 interface files works out to 162 FP, then 8.1 KLOC, then 21.58 person-months of effort and an 8.03-month modelled duration. A separate six-activity dependency network gives a 15-week critical path. Carry the assumptions and the units with every number, because a model fitted to one set of projects describes yours only as far as its inputs hold.

Estimation and scheduling in software engineering: separate the outputs

Estimation predicts size, effort, resources and uncertainty before all work is known. Scheduling arranges activities against dependencies, people, milestones and calendar time. LOC or FP measure size, person-hours or person-months measure effort, and days, weeks or months measure duration. Thus, 21.58 person-months means neither 21.58 months nor 21.58 people for one month.

A sound flow is: clarify scope and assumptions, build a WBS, estimate size, choose calibrated productivity or a model, derive duration and staffing, map dependencies, add visible risk reserve, baseline, then re-estimate.

• Expert judgement or Wideband Delphi helps early, but can retain expert bias.

• Analogy uses a similar completed project, but differences weaken it.

• Top-down is quick for planning, but can hide difficult components.

• Bottom-up exposes component work, but needs stable decomposition.

• Parametric models are repeatable, but depend on calibration and inputs.

Estimation questions of this kind sit alongside the rest of a GATE CS Exam Preparation reading list, and the companion post on Software Quality in Software Engineering carries the metrics and testing side of the same discipline.

Function-point and LOC estimation: calculate project size

Function points measure externally visible functionality without tying size to a language. Count each component type, then multiply by its average-complexity weight. Low and high complexity carry different weights, so use whichever table the question hands you:

UFP = 12 x 4 + 8 x 5 + 5 x 4 + 4 x 10 + 2 x 7

= 48 + 40 + 20 + 40 + 14 = 162 UFP

With a general-system-characteristic total of 35:

VAF = 0.65 + 0.01 x 35 = 1.00

Adjusted size = 162 x 1.00 = 162 FP

At the question-specific conversion of 50 LOC/FP, 162 x 50 = 8,100 LOC = 8.1 KLOC.

Weights and conversions must come from the question, organisational history or a named standard. LOC is language-dependent and hard to know early. FP starts from requirements, but boundaries and complexity still matter. Label assumptions and use a range for uncertain counts.

Basic COCOMO: turn 8.1 KLOC into effort and duration

Basic COCOMO is a parametric model fitted to a historical project set. For this organic-mode example:

E = 2.4 x KLOC^1.05 person-months

T = 2.5 x E^0.38 months

Identify the mode and coefficients before substitution. Then:

E = 2.4 x 8.1^1.05 = 21.5834 = 21.58 person-months

T = 2.5 x 21.5834^0.38 = 8.0335 = 8.03 months

Average staffing is only a rough value: 21.58 / 8.03 = 2.69, or about 3 people. Staffing changes by phase, and rounding does not remove assumptions.

For sensitivity, a 10% larger size is 8.91 KLOC: E = 2.4 x 8.91^1.05 = 23.8552, about 23.86 person-months. The nonlinear exponent exposes input uncertainty. A historical model is not automatically a reliable modern-team forecast.

Project scheduling tools: WBS, dependencies, Gantt, CPM and PERT

A WBS splits a deliverable into estimable activities with an owner and completion condition. Finish-to-start dependencies express order; milestones have zero duration. Gantt charts show calendar placement, while network diagrams expose dependency arithmetic. A drawn date does not prove feasibility.

CPM uses stated durations to find times, slack and the critical path, the longest-duration path rather than the one with most activities. PERT uses t_e = (O + 4M + P) / 6 and variance ((P - O) / 6)^2.

Parallel tasks may compete for one engineer; leave, approvals and integration queues also constrain the plan. Keep justified reserve visible; hidden padding prevents baseline learning.

CPM worked example: find the 15-week critical path and slack

A precedes parallel B and C; B precedes D, C precedes E, and F waits for both. The two passes give:

In the forward pass, F starts at max(12, 11) = 12 and ends at 15. The paths are A-B-D-F = 3 + 4 + 5 + 3 = 15 weeks and A-C-E-F = 3 + 6 + 2 + 3 = 14 weeks. Project duration is 15 weeks; A-B-D-F is critical.

Backward from finish 15, LS/LF values are F 12/15, D 7/12, E 10/12, B 3/7, C 4/10 and A 0/3. Slack is LS - ES. C and E share one branch week, so spending it twice can delay the merge.

PERT uncertainty, schedule compression and progress control

For API integration with O = 2, M = 5 and P = 14 weeks:

t_e = (2 + 4 x 5 + 14) / 6 = 36 / 6 = 6 weeks

Variance = ((14 - 2) / 6)^2 = 4 weeks^2

Standard deviation = sqrt(4) = 2 weeks

The expected duration differs from the most likely because PERT weights three estimates. Uncertainty accumulates along the relevant path; do not add every activity's standard deviation.

Shorten D from 5 to 3 weeks. A-B-D-F falls to 13 weeks, but A-C-E-F stays 14, so the project finishes in 14 and the critical path switches. Shortening E by one week on its own leaves the 15-week finish unchanged, because E already carries a week of slack. Recompute all paths after compression.

At each review, record actual starts and finishes, remaining effort, blockers and scope changes. Compare the baseline, update estimate-to-complete, and retain the old baseline unless controlled re-baselining is approved. Honest forecast change creates information; silently moving dates destroys it.

Estimation and scheduling questions: exam formats, interviews and traps

IIT Guwahati's official GATE 2026 CS syllabus lists ten subject sections, and Software Engineering is not one of them, so these calculations reach you through university papers and GATE-style practice rather than a named GATE section. Response formats are set out in MCQ, MSQ or NAT? GATE Question Types Explained, and the subjects that do carry weight are ranked in GATE CS Subject Weightage: Where Hours Pay Off.

In interviews, replace a magic number with questions about scope, team familiarity, dependencies, quality and uncertainty. Decompose, give a range and confidence, name the critical dependency, state re-estimation triggers, and justify analogy, bottom-up or parametric estimation. Try: "You can shorten only one activity by two weeks. What changes, and why is the project gain only one week if D is chosen?"

Estimation and scheduling: the short version and next step

• Requirements become size: 162 FP, then 8.1 KLOC here.

• A calibrated model gives 21.58 person-months of effort.

• Effort is not 8.03 months of elapsed duration.

• Dependencies make A-B-D-F = 15 weeks critical.

• Slack belongs to the network, not to isolated tasks.

• PERT gives 6 weeks expected with a 2 weeks standard deviation for the API integration activity, and each review updates that forecast.

GATE Guidance by Sanchit Sir is the structured route through this discipline alongside the rest of GATE CS preparation. For one exercise tonight, take a blank page and recompute the FP total, both COCOMO outputs, both CPM passes and the path switch after crashing D.