The process framework: five activities, eight bands

A process is activities, actions and tasks

A software process is a collection of activities, actions and tasks performed when a work product is to be created. Those three words are a size ladder, and using them interchangeably costs marks. An activity pursues a broad objective — communicating with stakeholders — and applies regardless of application domain, project size, or how much rigour the team wants. An action is a set of tasks that produces a major work product: architectural design is an action, and the architectural model is what it leaves behind. A task has a small, well-defined objective and a tangible outcome you can point at — writing one use case, running one unit test.

The move to practise is to place any piece of work on the ladder. "Modelling" is an activity. "Build the class model" is an action. "Add multiplicity to the Reservation–ToolCopy association" is a task. A plan written entirely at the activity level cannot be scheduled; a plan written entirely at the task level cannot be understood. Note also what a process is not: it is not a rigid prescription, but an adaptable approach that lets the team pick the actions and tasks that suit the work in front of them.

The five framework activities

A process framework identifies a small number of framework activities that apply to every software project regardless of size or complexity, and surrounds them with umbrella activities that apply across the whole process. The five framework activities are:

• Communication — talk and collaborate with the customer and the other stakeholders before technical work starts, to understand their objectives and gather the requirements that define features and functions.
• Planning — draw the map. The software project plan describes the technical work to be done, the risks that are likely, the resources required, the work products expected, and a schedule.
• Modeling — create models of the requirements and of the design, so the problem and the intended solution can be understood before either is committed to code.
• Construction — code generation, manual or automated, together with the testing that uncovers errors in it.
• Deployment — deliver the product, or an increment of it, to the customer, who evaluates it and gives feedback.

Two additions are always worth making. First, the same five serve a hundred-line script and a hundred-person programme; what differs is the detail, not the list. Second, they are applied iteratively — each pass through the five produces a software increment that gives stakeholders a working subset of the features, and the product becomes more complete with each pass.

The umbrella activities that run across them

Umbrella activities complement the five. They are applied throughout a project rather than at one point in it, and their job is to help the team manage and control progress, quality, change and risk. The typical eight are software project tracking and control; risk management; software quality assurance; technical reviews; measurement; software configuration management; reusability management; and work product preparation and production.

Here is the test that keeps the two kinds apart under exam pressure: ask whether the activity has a start and an end you could write in a diary. Modelling does — on BorrowBox it began the week the reservation requirements settled and ended when the design review closed. Configuration management does not: it starts with the first controlled document and is still running when a vendor firmware patch ships two years after release. Framework activities are stages of work; umbrella activities are bands drawn across all the stages. Calling an umbrella activity a "phase" throws away the whole metaphor, and markers notice.

Worked example — one BorrowBox increment, end to end

Take increment three of BorrowBox: waitlist a tool that is already on loan.

Communication is two conversations with the library coordinator plus a read of six months of "sorry, it is out" messages; the work product is a set of usage scenarios. Planning takes half a day and yields three tasks, one named risk (the notification provider throttles bulk sends), and a two-week window. Modelling adds one class, WaitlistEntry, one association to Member, and one new state on Tool; the work product is an updated class-and-state model. Construction is the code plus unit tests for the expiry rule. Deployment puts it in front of eleven members for a fortnight and collects their complaints.

Now the bands across it. Technical reviews catch, in the design walkthrough, that a member who is overdue on a different tool must not be offered a waitlisted one. Risk management already carried the notification-provider row, so the throttle was budgeted rather than discovered. Measurement counts the review findings and the increment effort, feeding next increment’s planning. Configuration management baselines the updated models and records that the notification path depends on locker firmware 2.4. None of those four started or stopped during this increment: they were running before it and will be running during increment four. That is the difference, shown rather than asserted — and showing it is what turns a 6 into a 9.