Formal Scheduling, Estimation & Tracking

The Project Schedule exam

Before anyone signs a contract or approves a budget for a software project, somebody has to say how long it will take and what it will cost. In a formal (also called plan-driven) life cycle, such as waterfall or the V-model from Part II, the project manager answers those questions up front by building a detailed schedule, analysing it, and then steering the project against it. This Part is about that whole loop. The agile alternative, where the plan is rebuilt every sprint from story points and velocity, is in Part VI.

An artefact here just means a document or model the project produces. A task (also called an activity) is a piece of work that takes time and resources, such as "design the database". A deliverable is something tangible handed over, such as a requirements document or a working release, and a milestone is the moment a significant deliverable or phase is finished. §8.7 defines these terms precisely.

The W07 slides say a schedule contains four things: (1) the duration and dependencies of each task; (2) the people and physical resources each task needs; (3) the milestones and deliverables; and (4) the project timeline. A dependency is a rule that one task can't start (or finish) until another has, which §8.4 covers. A schedule without any one of the four is incomplete. A list of dates with no resources, for example, can't tell you whether anyone is free to do the work.

Two kinds of chart present a schedule. A Gantt chart is a bar chart of the tasks against a calendar, so you can see when each one runs. A PERT chart is an activity network, a diagram of boxes and arrows that shows which tasks depend on which and picks out the critical path, the chain of tasks that sets the project's length. §8.7 builds one step by step.

The schedule doesn't stand alone. It is part of the Project Management Plan (Part V), it feeds the budget and the business case (Part I), and its estimates are one of the biggest sources of risk (Part IV): an optimistic estimate is a risk you have built into the plan yourself.

Five Steps to a Schedule exam

A schedule for a project of hundreds of tasks can't be written down in one go: you can't estimate work you haven't identified, and you can't put dates on tasks until you know what order they must run in. So the slides break schedule development into five steps, each using the output of the one before.

1. Work Breakdown Structure (WBS). Break the work into small chunks you can deal with (§8.3).
2. Identify the interdependencies between the tasks, and use them to build a task network (§8.4).
3. Estimate the effort and time for each task (§8.5).
4. Allocate resources to the tasks and validate the effort (§8.6).
5. Develop the schedule itself, using PERT/critical path analysis and a Gantt chart (§8.7 and §8.9).

The tutorial version has four steps: identify the tasks (the WBS); identify the dependencies (the network diagram); estimate the duration and resources (staff, hardware, artefacts); and construct the schedule (allocate dates and resources). Once the plan is approved, you track and control the project against it (§8.10), and re-plan when needed.

Pressman's scheduling principles

Pressman, the textbook the W07 slides cite, lists seven principles of software scheduling. They map neatly onto the steps, which makes them easy to remember:

Step 1: the Work Breakdown Structure exam

"Build the patient-records system" is far too big to estimate, assign or track: nobody can say how long it will take, and three months in nobody can say how much of it is done. The Work Breakdown Structure (WBS) solves that by breaking the work into manageable units, each with a specific outcome or deliverable, small enough that each one can be estimated and owned.

The five rules of a good WBS

A WBS can be drawn badly: it can miss work, count work twice, or stop at chunks still too big to estimate. Five rules guard against that.

The 8–80 hour rule has a reason at each end. Below about a day, a package is so small that tracking it costs more than doing it. Above about two weeks, it is too big to estimate well, and it can sit at "in progress" for a long time without anyone noticing that it has stalled. Making a package last no longer than one reporting period means every package is either done or not done at each progress report.

Two ways to draw a WBS

The W07 slides show a WBS in two forms. One is an indented list, an outline in which each level is indented under its parent. The other is a tree graph, which draws the same hierarchy as boxes joined by lines. They hold exactly the same information.

The fishbone (cause-and-effect) diagram

The W07 slides also introduce a tool for when the schedule goes wrong. A fishbone diagram, also called a cause-and-effect or Ishikawa diagram, identifies, sorts and displays the possible causes of a specific problem, such as a late or over-budget project. The problem is the head of the fish and the categories of cause are the bones. The slide's categories are People, Process, Equipment, Materials, Environment and Management; for software they are typically People, Processes, Tools and External influences.

The slides list four benefits: problem solving (it pushes the team towards root causes instead of symptoms), visualisation (everyone sees all the candidate causes at once), team collaboration (it is built together, so knowledge from everyone goes in) and focus on factors (it keeps the discussion on causes, not on blaming people). It is also one of the quality tools of Part VII, and in §8.10 it is the first step when a project drifts from its plan.

Step 2: Dependencies and Task Networks

A WBS lists what has to be done but says nothing about order. Some tasks can only happen after others: you can't test code that hasn't been written. Step 2 records those ordering rules and draws them as a network, which is what later lets you work out dates and find the tasks that control the end date.

Tasks come in two kinds. Unconstrained tasks can start at any time; the slides' example, from redecorating a room, is buying paint. Constrained tasks depend on another task: you can't remove the wallpaper until the decorations are off. When B depends on A, written A → B, A is the predecessor and B the successor. A dependency arises when a task needs either (1) a work product of another task (the design document, the built module), or (2) resources used by another task (the one database expert, the one test lab).

The four types of dependency exam

A dependency links one end of the predecessor (its start or its finish) to one end of the successor, so there are four combinations. Finish-to-start is by far the most common, and start-to-finish is rare.

A dependency can also carry a lag, which forces a wait before the successor (for example FS + 2 days), or a lead, which lets the successor overlap the end of its predecessor.

Task networks

A task (activity) network is a graphic representation of the task flow. It is used to show the dependencies, to find the critical path (§8.7), and to feed task sequences into scheduling tools such as MS Project. The course uses activity-on-node (AON) networks, in which the boxes are tasks and the arrows are dependencies. Older texts, and the 2002 past exam's Q14, use activity-on-arrow (AOA) instead, where the arrows are the activities and the numbered circles are events (moments when activities start or end).

The lecture example

The W07 lecture uses one small network throughout, and this Part does too. Tasks a and b have no predecessor. Tasks c and d both follow a; e follows b and c; f follows d; and g follows e. The figure turns that list into a network, adding a Start node before the tasks with no predecessor and an End node after those with no successor.

A software example

The slides' second network (compare Pressman Fig. 25.5) is a concept-development phase. It starts with 1.1 Concept Scoping, followed by 1.2 Concept Planning. Three tasks then follow 1.2: 1.3a Technical Risk Assessment, 1.3b Initial Requirements and 1.3c Build Configuration. All three lead into 1.4 Proof of Concept, which is followed by 1.5a/b/c Concept Implementation A, B and C. These come together in 1.6 Integrate Prototypes, and the network ends with 1.7 Evaluate with Customer.

Step 3: Estimating Effort and Duration

Once you know what the tasks are and what order they run in, you need numbers: how much work each task is, and how long it will take on the calendar. Those are two different quantities, and confusing them is a classic beginner's mistake.

Three-point estimating

Ask a developer "how long will the login page take?" and you get one number, a single-point estimate. It hides the fact that the real answer is uncertain: it might take 3 days if all goes well, or 9 if the authentication library fights back. Three-point estimating captures that uncertainty with three values:

• Optimistic (O): the duration if everything goes right;
• Most likely (M): the duration you would expect normally;
• Pessimistic (P): the duration if things go wrong (but not a catastrophe).

O, M and P come from experience on similar projects; the W07 slides admit this is often "a well-informed best guess".

The W07 slides apply both formulas to the seven activities of the lecture network. Step through the calculation below, then check the full table.

TE comes out greater than M whenever P is further from M than O is. That skew is typical of software, where things go wrong more often than right. Activity a is the only symmetric one (2, 4, 6), so its TE equals M.

PERT:       TE = (6 + 4×8 + 16) / 6 = (6 + 32 + 16) / 6 = 54/6 = 9.00 days
Triangular: TE = (6 + 8 + 16) / 3 = 30/3 = 10.00 days

Spread and probability standard PERT, beyond the 2026 slides

PERT can also say how sure an estimate is. The spread of each activity is its standard deviation, σ = (P − O) / 6, and its variance is σ². A wide O-to-P range means a large σ and an uncertain task. To combine the activities along a path you add the variances, not the σs, and then take the square root. With the expected path length and its σ, a normal-distribution table gives the chance of finishing by any date.

The Putnam–Norden–Rayleigh (PNR) curve

The Week 12 revision lecture lists the PNR curve under this step, although the 2026 W07 slides have no slide on it, so know the idea. It comes from Pressman, the textbook the slides cite as reference [2]. Norden found that the effort spent on a development project, plotted against time, follows a Rayleigh curve: staffing builds up to a peak and then tails off. Putnam applied this to software, and the consequence for scheduling is that effort and delivery time trade off non-linearly.

Effort is lowest when delivery is unhurried, and as you try to deliver earlier the effort needed rises steeply. Pressman puts the practical limit at about 0.75 t_d, three-quarters of the nominal delivery time; compressing further enters the "impossible region", where the risk of failure becomes very high. From Putnam's software equation he derives the trade-off as

E_a = m × (t_d⁴ / t_a⁴)

E_a  effort in person-months for the delivery time you want
t_a  the delivery time you want
t_d  the nominal (unhurried) delivery time
m    a constant: set t_a = t_d and E_a = m, so m is the effort at the nominal time

Compress to 90%:  t_a = 0.9 t_d  →  E_a = m × (1/0.9)⁴ = 1.52 m   (+52% effort for −10% time)
Stretch to 110%:  t_a = 1.1 t_d  →  E_a = m × (1/1.1)⁴ = 0.68 m   (−32% effort for +10% time)

The fourth power is what makes the curve so steep. This is the quantitative form of Brooks' point in §8.6 that people and months are not interchangeable: compressing a schedule costs far more effort than the time it saves, while a modestly later date saves a great deal of effort.

t_a / t_d = 18/20 = 0.9
E_a = m × (1/0.9)⁴ = 1.52 m

Step 4: Allocating Resources

An estimate in person-months says nothing yet about who will do the work or whether they are free. Step 4 assigns people (and equipment) to tasks and checks that the plan never asks for more of them than exist. The arithmetic is easy; the judgement is not.

The calculation is simple, but allocation is complicated. The project manager has to weigh each person's expertise (only some people can do the 3D rendering) and availability (they may be on leave or on another project), and that may force the schedule to be validated and adjusted (W07, citing Brooks' The Mythical Man-Month, ch. 2).

People and months are not interchangeable

The formula above quietly assumes that 4 people for 6 months equals 6 people for 4 months. Fred Brooks showed why it doesn't. Some tasks are sequential and can't be split at all (nine women can't make a baby in one month). New people need training, usually from the experienced people who were doing the work. And the number of communication paths grows much faster than the team: n people have n(n − 1)/2 pairs who may need to talk.

People = Effort / Duration = 36 / 9 = 4 people
Paths  = n(n − 1)/2 = 4 × 3 / 2 = 6

Resource loading and levelling

Resource loading is the demand for a resource in each period (people needed per day, say), usually drawn as a histogram under the Gantt chart. Over-allocation means that the demand exceeds what is available in some period: the plan books more people than exist.

Resource levelling fixes over-allocation by delaying non-critical tasks within their float (the slack they have before they would delay the project, §8.7) so that demand stays within the limit. If the float runs out, the end date slips, and the chain linked by logic and by shared resources becomes the resource-constrained critical path. PMBOK calls it smoothing when the end date doesn't move. Past exam Q2(D) in §8.14 works a full example.

Step 5: the PERT Chart and Critical Path

You now have tasks, dependencies and durations. Step 5 turns them into dates and answers the most important scheduling question: which tasks control the end date? A delay to most tasks is absorbed by spare time, but a delay to a few of them delays the whole project. Finding those few is critical path analysis.

A PERT chart is a task network that shows the dependencies together with timing information and the critical path. It helps the project manager to understand the project's characteristics and make scheduling trade-offs, to perform critical path analysis, and to monitor progress and re-plan.

Why is the critical path the longest path? Because every path through the network has to be completed, so the project can't finish before its longest path does. The longest path therefore is the project's duration, and it has no spare time anywhere along it.

The PERT node

In the course each node of a PERT chart is a box with the task's name and duration, its early and late start and finish times, and its slack:

The procedure exam

1. Draw the AON network from the predecessor table, with Start and Finish nodes.
2. Forward pass (left to right). Tasks with no predecessor have ES = 0. For every task, EF = ES + D, and ES = the MAXIMUM EF of its predecessors, because a task can't start until all of them are done. The project duration is the largest EF.
3. Backward pass (right to left). Tasks with no successor have LF = project duration. Working backwards, LS = LF − D, and LF = the MINIMUM LS of its successors, because a task must finish in time for whichever successor has to start first.
4. Compute the floats: Total float = LS − ES = LF − EF, and Free float = earliest successor ES − EF.
5. The critical path is the chain of TF = 0 tasks. Check it by summing every path: the longest is critical, and there may be several. Time starts at 0, so a task ending at 4 lets its successor start at 4.

Worked example 1: the lecture chart

The lecture network from §8.4, with the durations rounded to M: a 4, b 5, c 5, d 6, e 5, f 4, g 5. Step through the forward pass first.

Every number in one table, including the free float (FF = earliest ES of the successors − own EF; for a task feeding only End, use the project duration):

Free float, task by task
a: successors c, d start at 4        → FF = 4 − 4  = 0
b: successor e starts at 9            → FF = 9 − 5  = 4
c: successor e starts at 9            → FF = 9 − 9  = 0
d: successor f starts at 10           → FF = 10 − 10 = 0
e: successor g starts at 14           → FF = 14 − 14 = 0
f: End at 19                          → FF = 19 − 14 = 5
g: End at 19                          → FF = 19 − 19 = 0

Summing the paths confirms the result, as step 5 of the procedure says to:

Total float versus free float

Task d is the example to remember. It has TF 5 but FF 0. Total float says d can slip 5 days before the project is late; free float says any slip at all pushes back its successor f, because f starts the moment d ends. The 5 days are shared along the chain d–f: if d uses 3 of them, f has only 2 left.

The slide adds that two parallel paths could both be critical. And with the unrounded TE values from §8.5 the critical path is the same, a–c–e–g, at 19.5 days (4 + 5.17 + 5.17 + 5.17); this version appears in the slides' MS Project Gantt chart (§8.9).

Worked example 2: the tutorial walkthrough

The tutorial uses durations A 4, B 5, C 5, D 6, E 5, F 4, G 16, H 4. C and D depend on A; F and H depend on D; E depends on B and C; and G depends on E.

Critical path A–C–E–G = 4 + 5 + 5 + 16 = 30 days. D's LF = min(LS F, LS H) = min(26, 26) = 26, since both of its successors have LS 26. D's free float is 0, because F and H start right after it (ES 10 = D's EF 10). F and H each have FF 16, since they feed only the End at 30.

A–C–E–G = 4 + 5 + 5 + 8 = 22
B–E–G   = 5 + 5 + 8     = 18
A–D–F   = 4 + 6 + 4     = 14
A–D–H   = 4 + 6 + 4     = 14

Worked example 3: the software chart (W07)

The durations for the Pressman-style network of §8.4 are 1.1 = 2, 1.2 = 2, 1.3a = 1, 1.3b = 4, 1.3c = 2, 1.4 = 1, 1.5a = 5, 1.5b = 2, 1.5c = 3, 1.6 = 4 and 1.7 = 3. (The slide's table mislabels 1.5b and 1.5c as "1.5a".)

Forward pass
1.1  0 → 2         1.2  2 → 4
1.3a 4 → 5         1.3b 4 → 8         1.3c 4 → 6
1.4  ES = max(5, 8, 6) = 8  → 9
1.5a 9 → 14        1.5b 9 → 11        1.5c 9 → 12
1.6  ES = max(14, 11, 12) = 14 → 18
1.7  18 → 21                                   project = 21 days

Slack: 1.3a = 8 − 5 = 3   1.3c = 8 − 6 = 2   1.5b = 14 − 11 = 3   1.5c = 14 − 12 = 2

That leaves the critical path 1.1–1.2–1.3b–1.4–1.5a–1.6–1.7, 21 days (2 + 2 + 4 + 1 + 5 + 4 + 3).

Near-critical paths and merge bias

Near-critical paths have little float, like b–e–g in the lecture network with its 4 days. A small slip makes them critical, so monitor them as well. This is also a weakness of classic PERT: because it looks at a single path, it understates the risk when several paths are almost as long. This effect is called merge bias.

Merge and burst activities

The W07 slides don't use these two terms, but the official practice exam asked for the merge activities of a network (see Part XII), so know them. A merge activity has two or more immediate predecessors: it is where paths join. A burst activity is the opposite, with two or more immediate successors, where paths split. To find merge activities, read down the predecessor column for any task with more than one entry.

They matter for two reasons you can use when justifying an answer. The forward pass takes the maximum EF at a merge activity, so a slip on any feeding path, critical or not, can delay it once that path's float is used up. And merge activities are where merge bias comes from: a task that needs several paths to finish is less likely to start on time than any one path suggests, so they are worth monitoring closely.

Delays, Acceleration, Crashing and Fast-Tracking exam

A schedule is only a prediction. Tasks will slip, and sponsors will ask whether the date can be brought forward. The floats from §8.7 let you answer both kinds of question precisely, and without redrawing the whole network.

The lecture example shows all three effects on the 19-day network. Each step below changes one task and re-measures the three paths.

Crashing and fast-tracking

When the sponsor needs the project earlier, there are two ways to shorten it. The W07 slides define crashing as shortening the project by shortening the critical path, and give two ways of doing it: (1) by removing dependencies between critical activities, or (2) by shortening the durations of critical activities.

PMBOK splits these apart. It reserves crashing for (2), adding resources (people, overtime, tools) to critical tasks at the least extra cost, and calls (1) fast-tracking: overlapping or parallelising activities that were sequential, which raises the risk of rework.

Least-cost crashing older exam topic

Older exams ask for the cheapest way to shorten a project. Every day saved also saves indirect costs (office, management, overheads that accrue per day), so crashing is worth it as long as a day of crashing costs less than a day of overheads. It is found step by step:

1. Compute each activity's cost slope = (crash cost − normal cost) / (normal duration − crash duration), the extra cost per day saved.
2. Crash the cheapest critical activity by one unit. If there are several critical paths, crash the cheapest combination that shortens all of them.
3. Repeat while the marginal cost is less than the indirect cost saved per day and the crash limits allow.
4. At each step, total cost = direct cost + indirect cost × duration.

slope = (2,000 − 1,200) / (6 − 4) = 800 / 2 = $400 per day

Gantt vs PERT vs Milestone Charts exam

A finished schedule has to be shown to people who want different things from it: the team wants to know what to do next week, the project manager wants to know which tasks can't slip, and the sponsor just wants the dates. The three chart types show the same schedule from different angles. The Gantt chart shows when, the network shows why, and the milestone chart shows only the key dates.

The slides' MS Project Gantt chart shows the 7-task lecture example with TE durations. Critical tasks are red, slack appears as black lines, and the bars stretch across weekends because weekends are non-working days: a 5-day task that starts on a Thursday ends the following Wednesday on the calendar.

Past exam: drawing a Gantt chart from a brief

A question like this has no single right answer: the marks are for a chart that meets every constraint and for stating your assumptions. The guide's answer rests on three:

• The whole-system SRS (software requirements specification) must be ready for the T0+4 review, so the B and C analysis both run in months 2–4.
• C's design starts after B's acceptance review, which is the go/no-go on B's success. Overlapping C's design with B's test would add float, but it risks rework.
• Sections act as summary tasks, and T0 is drawn as January 2027.

Project Tracking and Control exam

An approved schedule is a prediction, and predictions drift. A project still needs control after it starts, because estimates are uncertain. Risks, requirement changes, staff turnover and technical surprises push reality away from the plan, and the slips accumulate silently: every task is "90% done" for weeks (the "90% done" syndrome). Detecting a deviation early makes correction cheap and lets stakeholders be warned in time. Control also keeps scope, time, cost and quality balanced, and keeps the living schedule current.

Six ways to track progress

Earned value analysis (EVA)

Comparing money spent with money budgeted is not enough. If a project has spent exactly what was planned by month 6, is that good? Only if it has also done what was planned. EVA fixes this by measuring the work done in budget dollars. It reports current and past performance and predicts future performance from it, in dollars and/or percentages. It rests on three quantities plus the total budget (definitions from W07; the old names in brackets are the ones the 1999 past exam uses):

From these come the variances, indices and forecasts below. In the variances and indices EV always comes first, so a positive variance or an index above 1 is good news.

Reading SPI and CPI together

Each index on its own tells half the story. Together they place the project in one of four positions, each calling for a different response:

The tutorial also asks for the reasons and the actions. The reasons are scope change without change control, the loss of key staff and the ramp-up time that follows, the haptics risk not being mitigated, and optimistic estimates. The actions are to re-baseline through change control, negotiate the scope or the deadline, put experienced people on the critical tasks, prototype the risky parts, and not add people late (Brooks).

CV  = 220 − 180 = +$40k        CPI = 220/180 = 1.22
SV  = 220 − 200 = +$20k        SPI = 220/200 = 1.10
ETC = (240 − 220)/1.222 = 20/1.222 = $16.4k
EAC = 180 + 16.4 = $196.4k     (about $43.6k under BAC)
Time ≈ 12/1.1 = 10.9 months    (about one month early)

Past exam: the old names

Worst: c, which is behind schedule and over budget. BCWS is PV, BCWP is EV and ACWP is AC in today's terms.

Past exam: budget versus actual

The cumulative budget at week 6 = 10 + 25 + 15 + 10 + 25 + 15 = $100k (Task 1 30 + Task 2 60 + Task 3 10). The actual, summed the same way, is also $100k, so there is no over- or under-run to explain. Method: compare the cumulative actual against the cumulative budget, then go task by task to locate the source.

Caveat: comparing budget with actual ignores how much work has been done, so it needs EV as well. If Task 2 were only 70% complete, EV = 30 + 0.7 × 70 + 10 = 30 + 49 + 10 = 89 and CV = 89 − 100 = −$11k. That over-run is caused by Task 2, even though spending matches the plan.

When actual progress differs from the plan exam

1. Diagnose the cause, using variance analysis, a fishbone diagram (§8.3) and a check of the estimates.
2. Re-forecast the EAC and the end date, and inform the stakeholders.
3. Recover. Move people from non-critical to critical tasks (using the float), add skilled staff early, use short-term overtime, crash or fast-track (§8.8), and remove blockers.
4. Trade off scope, time and cost with the client through change control, for example by deferring features to a later release or extending the date or budget.
5. Re-baseline if the change is permanent.
6. If the project is ahead, verify the quality and that "done" really is done, then release resources.

Why Scheduling Software Is Hard; Valid vs Invalid Schedules

Construction projects are scheduled with the same tools, yet software projects are notorious for running late. The reasons are worth knowing both for exam questions that ask "why?" and for justifying the techniques in this Part.

Software is hard to schedule for many reasons. The product is intangible and progress is invisible: you can see half a bridge, but not half a program. Each project is novel, with little comparable history, and its size is uncertain early on (the cone of uncertainty). Requirements change, productivity varies widely between developers, and people and months are not interchangeable (§8.6). Integration and testing effort is non-linear, and there are new technologies and third-party dependencies. On top of all that, estimators are optimistic and deadlines are imposed from outside.

Pressman's eight reasons projects run late

1. An unrealistic deadline is set by someone outside the team.
2. Changing requirements are not reflected in the schedule.
3. There is an honest underestimate of the effort or resources needed.
4. Risks were not considered at the start.
5. Unforeseen technical difficulties arise.
6. Unforeseen human difficulties arise.
7. There is miscommunication among staff.
8. Management fails to recognise the slip and act on it.

Valid and invalid schedules

Estimation Methods and Models older exam topic

This material comes from older exams (of predecessor subjects 433-443 and 433-341) rather than the 2026 slides, but the exam's calculation questions can draw on it. So far, estimates have come from experience and three-point guesses. This section covers the systematic ways of producing them: building an estimate from the top or the bottom, measuring size with function points, and turning size into effort with a model such as COCOMO.

Top-down and bottom-up

An estimate can be built in two directions, from the whole system down or from the work packages up, and each has its own strengths and weaknesses.

Function points (Albrecht / IFPUG)

Lines of code can't be counted until the code exists, and depend on the language. Function points (FP) instead measure functional size from the user's view: how much the system does, counted from the requirements. You count five kinds of component, rate each one simple, average or complex, and weight it.

Mark II function points (Symons)

Mark II FP is counted per logical transaction (one complete user request and its response) instead of per component. Each transaction scores

UFP = 0.44 × input data element types + 1.67 × entity types referenced + 0.38 × output data element types

These are the weights given in the 1999 exam. A data element type is a distinct field (an account number, a name); an entity type is a kind of thing the system stores (ACCOUNT, CUSTOMER).

UFP = 0.44 × 5 + 1.67 × 1 + 0.38 × 1
    = 2.20 + 1.67 + 0.38
    = 4.25          (4.63 if a confirmation message is also counted: + 0.38)

COCOMO (Boehm 1981)

The COnstructive COst MOdel turns size in thousands of lines of code (KLOC) into effort and schedule. The basic model is

E = a × KLOC^b   person-months
D = 2.5 × E^c    months
people ≈ E / D

Intermediate COCOMO multiplies E by 15 cost drivers (in four groups: product, computer, personnel, project), and COCOMO II accepts FP or object points as the size instead of KLOC.

Worked example: 32 KLOC, organic
E = 2.4 × 32^1.05 = 2.4 × 38.05 = 91.3 person-months
D = 2.5 × 91.3^0.38 = 2.5 × 5.56 = 13.9 months
people ≈ 91.3 / 13.9 ≈ 6.6

Algorithmic models

Function points and COCOMO are both algorithmic models, which come in two kinds. Mathematical (parametric) models compute effort = f(size, cost drivers) from a fixed formula. Regression models fit that equation to historical project data (for example, log effort against log size), and the organisation calibrates it to its own projects.

$3M at an assumed $15k per person-month ≈ 200 PM
D = 2.5 × 200^0.38 ≈ 2.5 × 7.49 ≈ 19 months
people ≈ 200 / 18.7 ≈ 11

E = 2.4 × 10^1.05 ≈ 2.4 × 11.22 ≈ 26.9 person-months
D = 2.5 × 26.9^0.38 ≈ 2.5 × 3.49 ≈ 8.7 months
people ≈ 26.9 / 8.7 ≈ 3.1

Applying It to the Medic Case

The tutorials' running case, Medic, is a virtual-reality surgical simulator for the RVEEH (Royal Victorian Eye and Ear Hospital) surgeons: trainees practise cochlear-implant and temporal-bone surgery on a 3D model with haptic (force-feedback) devices instead of scarce cadavers. The team is 12 inexperienced developers (new to C++, stereoscopic 3D and haptics) and 2 experienced managers. The T07 tutorial applies the whole scheduling procedure to it, starting with its WBS.

The next table gives the dependencies and durations in days from the T07 table, together with the guide's own forward and backward pass (ES–EF and total float).

Critical path: 1.2 → 2.1 → 2.2 → 3.3 → 4.2 → 5.1 → 5.2 → 5.3 → 5.5 = 5 + 7 + 7 + 15 + 30 + 10 + 4 + 8 + 2 = 88 days.

Interpretation

The critical path runs through the 3D algorithms (3.3, 4.2, 5.1), which is exactly where the team is weakest: its 12 developers are inexperienced and unfamiliar with C++, 3D stereoscopic rendering and haptics. That is where three-point estimates should be used. Illustration: if 4.2 is estimated at O = 20, M = 30, P = 55 days,

TE = (20 + 4×30 + 55) / 6 = (20 + 120 + 55) / 6 = 195/6 = 32.5 days
σ  = (55 − 20) / 6 = 35/6 ≈ 5.8 days
4.2 is critical, so the end date moves out by 32.5 − 30 = 2.5 days (88 → 90.5)

So the strongest developers should go on 3.3, 4.2 and 5.1. The 3D and haptics work should be prototyped early (spiral thinking, Part II), the 5.1 tests prepared in parallel (a start-to-start dependency), and a buffer kept before Release. The UI, mobile and database chains have 19–34 days of float, which allows resource levelling across the 12 developers.

Pitfalls and Exam Practice

Calculation questions lose marks in predictable places. Check this list before the exam, then work the three network questions below: they are the kind of extended question the exam asks.

Q1 · T07 class activity

Q2 · Past exam 433-341 2009 Q3

Every path starts with T1–T2–T3, which takes 2 + 15 + 10 = 27 on shortest durations, 2 + 18 + 11 = 31 on expected and 3 + 21 + 13 = 37 on longest. The four paths after T3 compare as follows:

Q3 · Past exam 433-341 2008 Q1