The generic process model: activities, actions, tasks, task sets

Three nested things, not three words for the same thing

A software process is the set of activities, actions and tasks a team carries out in order to produce something. Those three words are not synonyms; they name three different sizes of thing. A framework activity is broad, domain-independent, and applies to every project whatever its size: communication, planning, modeling, construction, deployment. A software engineering action sits inside one activity and produces a major work product — requirements elicitation is an action inside communication, architectural design is an action inside modeling. A work task is small, well defined, and has a tangible outcome that one person can finish and hand on: interview the depot manager; write the acceptance criteria for the waitlist story. Examiners test this hierarchy by handing you something and asking what it is. Using the three words interchangeably loses the mark before you have written anything else.

The task set is where adaptation actually happens

Each action is realised by a task set, and a task set answers four questions: which work tasks get done, what each of them leaves behind, where quality has to be checked before the work moves on, and which milestones mark that progress has actually happened. This is the load-bearing idea of the whole chapter. Two teams can both perform requirements elicitation and run completely different task sets — one a phone call and a written note, the other a stakeholder register, four separate interviews and a facilitated specification workshop — and both are doing software engineering correctly. You adapt a process by choosing a task set that fits the project and the team; you do not adapt it by deleting framework activities. A team that says it skipped planning has not adapted a process, it has abandoned one.

Process flow is not the same thing as a process model

Process flow describes how the activities, actions and tasks are organised with respect to sequence and time. There are four shapes. Linear: run all five once, front to back, and stop. Iterative: go round one of them again before you move on. Evolutionary: keep circling the whole set, and let every lap leave you holding a fuller version of the software than the last one did. Parallel: run two of them at the same time on different parts of the product — modelling the waitlist while the locker driver is under construction. A process model is more than a flow: it prescribes the elements and the flow. So a team that says it works iteratively has named a flow and told you nothing about which model it is using.

What makes a model prescriptive

The models in this module are called prescriptive because they hand you the pieces before the project starts: which framework activities you will run, which engineering actions sit inside them, which work tasks realise those actions, what each task has to produce, where quality gets checked, and how a change is permitted to enter afterwards. They also fix the order in which those pieces are used. They exist to buy structure, order and consistency. Crucially, every one of them still performs the same five framework activities. What separates waterfall from the spiral or from the Unified Process is the emphasis each places on those activities and the flow that invokes them, never the presence or absence of the activities themselves.

Worked example — one BorrowBox action, two task sets

BorrowBox is a neighbourhood tool library: members reserve a power tool in an app, collect it from a smart locker bank with a one-time QR code, and return it to any locker, where a librarian inspects and re-shelves it. Take one action — elicitation, inside the communication activity — and hand it to two different jobs.

Job A is a locker-status widget for the librarian's tablet. Its task set: list the two stakeholders; hold one 45-minute session at the depot; write six user stories with acceptance criteria; rank them; record the single open question. Work product: an accepted story list. Quality-assurance point: the librarian signs off the acceptance criteria. Milestone: stories accepted.

Job B is the whole reserve-and-collect subsystem. Its task set: build a stakeholder register (member, librarian, depot admin, grant officer, locker vendor); interview each separately; run a facilitated specification workshop with the vendor present; turn each usage scenario into a formal use case; prioritise with the depot manager holding the deciding vote; record the constraints — door open within three seconds of a scan, WCAG 2.2 AA, must run on a four-year-old Android; and agree in advance how each requirement will be validated. Work product: a reviewed requirements model. Quality-assurance point: a formal technical review. Milestone: requirements model baselined.

Same activity, same action, same five framework activities — a completely different task set. That difference is the entire mechanism of process adaptation, and it is why which model? and how much process? are two separate questions that a good answer keeps apart.