Choosing a process model and defending the choice

Attributes first, models second

The question which process model would you use? is the most likely twelve-mark applied question on this paper, and weak answers all fail the same way: they argue from properties of models rather than attributes of the project. "The spiral manages risk well, so I would use the spiral" earns almost nothing, because it never established that this project's risk is the kind a spiral manages.

Start with the project and let the model fall out. List the attributes that actually discriminate — not everything true about the project, only what a model choice is sensitive to:

• Requirement clarity and volatility. Can the requirements be stated up front, and will they hold?
• Where the risk is concentrated. One external dependency, or diffuse technical uncertainty across the whole build?
• The cost of being wrong late. What does it cost to discover in month six that the design was wrong?
• Customer availability. Can you get a decision from them weekly, or only at contract milestones?
• Contractual and regulatory need. Is there a fixed scope, an audit trail, a required sign-off?
• Team size and distribution. Four people in one room behave nothing like forty across three time zones.
• External hardware or vendor dependencies. Anything you cannot rewrite yourself.
• Time-to-market pressure. Is a limited version now worth more than a complete version later?

No model is perfect for every project. In practice a team adapts one model, or blends two, to fit the job in front of them — and saying so, with the adaptation named, is a stronger answer than picking one model off the shelf.

The four-beat answer

1. Frame the project by naming the three or four attributes that will drive the decision. Two marks.
2. Choose, and map. Name the model and connect each attribute to a property of that model — attribute because property, in that order. Four marks.
3. Reject two named alternatives, each for a specific attribute it mishandles. Not "waterfall is old" but "waterfall gates on a requirements document, and attribute 1 says the requirements cannot be written yet". Four marks.
4. State the cost and the condition. Name what your choice costs you, how you will pay for it, and the change in attributes that would make you choose differently. Two marks.

Beat four is where most candidates stop early, and it is worth as much as the entire framing.

What each model buys, compressed

Waterfall buys a document trail, a fixed contractual scope and inspectable sign-offs; it costs you late delivery of anything runnable and expensive change. Prototyping buys early answers about things nobody can specify; it costs you the standing risk that the prototype ships and its shortcuts harden. The spiral buys per-circuit risk analysis and continuous customer involvement on large, extensible products; it costs you formal management, real risk expertise, and a project whose end date is genuinely hard to see. The Unified Process buys an early architectural baseline, use-case traceability and strong documentation; it costs you the overhead of five phases and an integration problem across staggered increments, and it expects an experienced team.

Worked example — BorrowBox, argued

Attributes. (1) The physical interaction is unspecifiable in advance — gloves, sunlight, one-handed use. (2) The risk is concentrated in exactly one place: an external locker vendor whose firmware SDK has slipped twice. (3) The team is four developers in one room. (4) The launch date is fixed by a council grant and cannot move. (5) The depot manager is available weekly and enjoys being asked. (6) There is no regulator and no fixed-scope contract.

Choice. The prototype-driven evolutionary model with a go/no-go gate at each prototype. Attribute 1 needs a requirements instrument, and a prototype in the car park is one. Attribute 2 wants the risky dependency exercised early and cheaply, which a simulated locker in increment 1 and real hardware in increment 2 gives you. Attribute 4 wants a model that can drop scope rather than slip a date, and an increment-based flow can ship a smaller product on the day. Attribute 5 supplies the evaluator the gate needs.

Rejected: waterfall. It gates on a requirements document, and attribute 1 says the interaction requirements cannot be written yet — so the gate would certify a confident guess. Worse, its single late integration would meet the vendor's real firmware for the first time close to the launch date, which is where attribute 2 does the most damage.

Rejected: the pure spiral. Its per-circuit formal risk programme is designed for large teams and large projects, and this risk is not diffuse — it is one named vendor. Four people would spend a disproportionate share of every circuit on ceremony to manage a risk that one line in a risk table and one simulator already handle. The spiral would be the right answer if the same product were being built by thirty people across two organisations.

Cost accepted. Architectural coherence. Increment-by-increment delivery lets the structure drift, so we buy it back deliberately: one written architecture decision record per increment, and a standing refactoring allocation in each iteration. Condition to change. If the council attaches a fixed-scope audited grant with a required sign-off, the attributes change and a waterfall-shaped final increment becomes defensible for the contracted part of the work.