The Unified Process, and a prototype-driven model with a go/no-go gate

Three adjectives, and why they are the definition

The Unified Process is standardly characterised as use-case driven, architecture-centric, iterative and incremental, and those adjectives are not decoration — they are the definition. Use-case driven means the customer's view of the system, written as use cases, is what drives modelling, construction and the acceptance tests; a UP project that has no use cases is not doing UP. Architecture-centric means an architectural baseline is established early and everything after is fitted to it; the architecture is a first-class deliverable, not a by-product of coding. Iterative and incremental means the process flow circles, and each circuit delivers a usable increment. Naming the five phases without those three adjectives is the single commonest way to lose marks on this term, because the phases alone describe a shape that a badly run waterfall could also claim.

UP exists because neither camp was satisfactory on its own. It keeps what the traditional models are genuinely good at — an explicit architecture, real documentation, named phases with named outputs — while adopting the habits that make agile work: talk to the customer constantly, describe the system in the customer's own terms, and deliver in laps rather than in one delivery at the end. That is why it sits between the two camps rather than in either.

The five phases, and why they overlap

Inception is where customer communication and planning happen: fundamental business requirements are captured as a set of preliminary use cases, and planning identifies resources, assesses major risks and sets a preliminary schedule for the increments. Elaboration covers planning and modelling: it sharpens and extends those use cases and produces the architectural baseline — five coordinated views of the system (the use case, analysis, design, implementation and deployment models) that all later work is fitted to rather than allowed to contradict. The plan is normally revised here too. Construction builds every feature this increment owes, writing and running unit tests as components appear and integrating them as they come together; the acceptance tests are derived straight from the use cases. Transition puts the software and its documentation in front of real end users as a beta, and the defects and change requests they send back are worked before the increment is declared a usable release. Production is the phase in which the release is simply in use: someone watches how it behaves, someone keeps the environment it runs on alive, and the defect reports and change requests arriving from the field are triaged.

The thing candidates miss: the five phases do not run in sequence. They overlap in a staggered way — while this increment is in construction, transition or production, work on the next increment has already begun. That overlap is what makes UP genuinely iterative and incremental rather than a waterfall with new stage names.

A recommended model with a gate

The textbook's own prescription, developed at length in its fourth chapter, is a prototype-driven cycle: requirements definition, then preliminary architectural design, then an estimate of required resources, then construction of a first prototype, then evaluation of that prototype by stakeholders — and then an explicit go/no-go decision. That gate is the interesting part. A go sends you round again: redefine the scope, construct the next prototype, evaluate. But two other outcomes are equally legitimate at the same point. The prototype can become the software release, at which point the project moves into maintaining released software. Or the project can end.

Most process models have no place to say stop. This one does, and it puts it immediately after an evaluation, when the evidence for stopping is freshest and least expensive. Each pass through planning revises the cost estimate and the schedule against the previous ones, and the risk of overrunning the budget or missing the date is assessed by comparing the new numbers with the old — so the go/no-go decision is made on measured drift, not on mood.

Worked example — BorrowBox through one turn

Requirements definition. User stories with acceptance criteria for reserve, collect and return, plus the constraints: the locker door opens within three seconds of a scan, WCAG 2.2 AA, a four-year-old Android phone.

Preliminary architectural design. A layered application over a data-centred catalogue, with an event channel out to the locker estate — allocated to increment 2, an architectural decision made early precisely because it cannot be retrofitted.

Resource estimate. Four developers, ten weeks to the first evaluation.

First prototype. Reserve and collect, running against a simulated locker controller.

Evaluation. Eight members and two librarians. The three-second budget is met on depot Wi-Fi and missed on 4G against the outside wall, where the signal is poor.

Go/no-go. A go with redefined scope: an offline token cache moves into the next prototype and two lower-value features move out. A genuine no-go looks different — had the vendor refused to expose a door-open API at all, the honest outcome would be to end the project in this form and re-scope it around keypad lockers. The model gives that decision a place to be recorded rather than discovered six months later.