01What is a process?
Whenever we provide a service or build a product, we follow a sequence of steps to accomplish a set of tasks. We do not paint the wall before the wiring of a house is installed. That ordered series of activities is what we call a process.
- It prescribes all the major activities
- It uses resources and produces intermediate and final products
- It may include sub-processes, with entry and exit criteria
- The activities are organised in a sequence
- Constraints or controls may apply (budget, availability of resources)
From process to software life cycle
When the process involves the building of a product, we refer to it as a life cycle. The software development process, also called the software life cycle, is a coherent set of activities for specifying, developing (designing and implementing), and validating (testing) software systems.
The four fundamental activities
Every software process, regardless of model, contains four core activities. Different models arrange them differently and revisit them at different cadences, but the activities themselves are universal.
These four activities are studied in depth in the third companion in this series. Here we focus on how the different process models organise them.
- Stakeholder. Anyone affected by, or who can affect, the system: customers, end users, regulators, the development team, support staff. The plural matters – different stakeholders often want different things.
- Requirement. A statement of what the system must do, or a constraint on how it must do it. Split into user requirements (high-level, in the customer's language) and system requirements (detailed, technical, used by developers).
- Component. A self-contained unit of software with well-defined interfaces. May be developed in-house, bought as commercial off-the-shelf (COTS), or taken from an open-source library.
- Architecture. The high-level structure of a system: which components exist, how they are arranged, how they communicate. The decisions hardest to change later.
- Increment. A working slice of the final system, delivered partway through development, that adds value on top of what was delivered before.
- Iteration. A repeated pass through the development activities. Each iteration may produce an increment, refine an existing increment, or both.
What is a process model?
A software process model is an abstract representation of a process. It describes a process from a particular perspective. The same software project can be described by different models that emphasise different things – the order of phases, the flow of artifacts, the management of risk, the role of feedback. No model is the truth; each is a useful lens.
Why we need process models at all
The classic cartoon below is funny because it is true. Without a process that brings the customer, the developer, and the deliverable together at the same level of understanding, projects routinely produce something nobody actually wanted.
02The five generic process models
The first split: plan-driven or evolutionary
Before naming individual models, it is worth seeing the highest-level division. Almost every software process can be classified along one axis: how much of the work is planned upfront versus how much is discovered as we go.
Plan-driven
Requirements are settled, then design, then code, then test. Each stage produces formal documents that are signed off before the next begins. Change is allowed but expensive. Strong on predictability and audit; weak on responsiveness.
Examples in this companion: waterfall, formal systems development, the V-model, reuse-oriented development when applied in a phased way.
Evolutionary
An initial version is built quickly, then evolved through repeated cycles in conversation with the customer. Specification, development, and validation overlap in time rather than running in sequence. Strong on responsiveness and learning; weak on predictability and document-heavy sign-off.
Examples in this companion: evolutionary development, prototype-driven development, and the whole Agile family covered in detail in the second companion.
The five named models we will examine
Within the hierarchy above, Sommerville names five generic models. We will examine each in turn:
Two further mechanisms – incremental development and spiral development – describe how iteration is layered on top of any of these. They are covered in the second companion in this pair, on iteration and Agile process models.
031. Waterfall model
The idea
Waterfall partitions a project's development into distinct sequential stages. Each stage produces a definitive output that is the input to the next. The model is named for the way work flows downward from one stage to the next, with little expectation of going back upstream once a stage is complete.
The model is based on hardware engineering practice and was widely used in military and aerospace industries – environments where requirements are typically well defined early and change is minimal.
The problems
Waterfall partitions projects rigidly. The drawback is the difficulty of accommodating change once the process is underway. More fundamentally, software is unlike hardware in ways that strain the model:
Where waterfall still fits
Despite its limitations, waterfall is the right choice in some circumstances:
Strengths
- Simple, well-known structure
- Each stage produces formal documentation
- Easy to manage and audit
- Suitable for stable, well-understood domains
Limitations
- Inflexible to change once stages are committed
- Working software not visible until late
- Risks discovered late are expensive to fix
- Poor fit for most modern software contexts
042. Evolutionary / Agile development
The idea
Evolutionary development reverses waterfall's central assumption. Rather than fixing requirements upfront, the system evolves toward a final form by repeatedly producing versions that are shown to the customer. The customer reacts; the team adjusts; the next version goes further. Specification and development are interleaved rather than sequential.
Sommerville distinguishes two kinds:
Problems
Applicability
Examples of agile process models
Evolutionary / Agile is itself a family. Specific named models that fit under it include:
The second companion in this pair, on iteration and Agile process models, covers Scrum, XP, Kanban, and the Spiral model in detail. The other names listed here are mentioned for completeness – students may encounter them in industry but they are less commonly used than Scrum or XP.
05Software prototyping
What it is
Software prototyping is a development technique, not a process model. It is used to help understand system requirements, especially when the requirements are poorly understood at the start. The pattern is simple: develop a quick-and-dirty version of the system; expose it to user feedback; refine and re-develop. Repeat until an adequate system is developed, or until enough has been learned to specify the real system properly.
an initial version of a system used to demonstrate concepts and try out design options. It is not the system that ships – it is a tool for learning.
Where prototyping is used
The four-step prototyping process
Benefits
Prototyping work is often described with the principle KISS – Keep It Simple and Stupid. The point is not that the prototype must be unsophisticated; it is that the goal of the prototype is to learn, and any complexity beyond what is needed for that learning is waste.
Phase 1 of the project asks the customer group to write a 1–2 page business outline, followed by an interview workshop with the developer group. That interview is, in effect, a chance to use prototyping techniques in their lightest form. If the developer group finds the customer's outline ambiguous, drawing a quick paper sketch of a screen, or describing a concrete user scenario, often surfaces hidden requirements faster than re-reading the document. You do not need to build software to prototype; sketches, mock screens, and scenario walk-throughs all count.
063. Formal systems development
The idea
Formal systems development is based on the transformation of a mathematical specification through different representations to an executable program. Each transformation is correctness-preserving, so showing that the program conforms to its specification is straightforward – the proof is built in.
Its relationship to waterfall. Scientifically, formal systems development is not a wholly separate paradigm so much as a specialisation of the waterfall model. It keeps the same plan-driven, sequential, document-driven lifecycle – requirements definition, then specification, then implementation, then integration and testing – but replaces the ordinary implementation phase with a chain of correctness-preserving formal transformations. Sommerville presents it in exactly this way, and the approach is embodied in IBM's Cleanroom method; the closely related V-model simply mirrors a test-planning activity onto each specification stage. So when you weigh it against the other models, treat it as “waterfall with a mathematically verified implementation step”, not as an unrelated fifth process. That also explains its shared limitations with waterfall: it commits to the requirements early and does not deliver incrementally.
First, what "formal transformation" actually means
The name of this model is the idea itself. You begin from a formal specification – a description of what the system must do written in a notation with a precise mathematical meaning instead of in ordinary English – and you transform it, step by step, into running code, where each step is proven to preserve meaning (that is the chain in the figure below). An English requirement such as “the controller shall never show green on both roads at once” can be read more than one way; a formal specification re-states it as a logical statement that is either true or false. Because it is mathematics, you can prove that a property can never be violated. That is the whole point: testing can only show that bugs are present, whereas a proof over a formal specification can show that a class of bugs is absent. (One common, visual way to write such a specification is a state machine: a set of states the system can be in and the transitions between them, as in the traffic-light example used further down.)
The slides also name four notations without explaining them. Z, B, VDM and TLA+ are not algorithms or tools you run; they are formal specification languages – mathematical “dialects”, each with its own style and tools. You are not expected to write in them in this course, only to recognise what they are:
All four exist for the same reason: to pin down what a system must do precisely enough that conformance can be proven rather than merely tested. Which one a team reaches for depends on the domain – Z and VDM for data and state, B for refinement down to code, TLA+ for concurrency. With that vocabulary in hand, the transformation chain below reads cleanly.
What T1, T2, T3, T4 and P1, P2, P3, P4 actually mean: a worked example
The figure is abstract. To make it concrete, consider a small system: a traffic-light controller for a single intersection where two perpendicular roads meet. The safety property that must hold is simple: at no time may both roads show green simultaneously. Here is what the chain of refinements would look like.
The point of all this work is the chain of guarantees: if FS is correct, and every Tᵢ–Pᵢ pair is correct, then by construction the executable cannot violate the safety property. This is what we mean by correctness-preserving transformations. The cost is real – every Pᵢ is a proof obligation that someone has to discharge – but for safety-critical systems the alternative is testing alone, and tests can only show the presence of bugs, never their absence.
A real traffic-light controller has more states (yellow flashing for failure modes, pedestrian crossings, emergency-vehicle preemption), more invariants, and far more proof work. The example here has been deliberately stripped to its bare bones so the structure of the T-and-P chain is visible. Each Tᵢ refines the representation toward implementation; each Pᵢ rebuilds the safety guarantee at the new level. The same shape applies to airbag controllers, aircraft flight-control laws, and railway interlocking systems.
Problems
Applicability
Formal transformation is the right main model when several of these signals hold together:
A railway signalling interlocking, the logic that decides which trains may enter which sections of track and which signals may show “proceed”, is the kind of system formal transformation was made for. The core is small, the safety rule (no two trains are ever granted conflicting routes over the same track) is precise and can be written as mathematics, a wrong decision can cause a collision, and there is no value in shipping “half” the interlocking logic early. The B-method was used in exactly this way on the driverless Paris Métro Line 14. The mathematics of the safety rule is what a formal specification captures, and the correctness proofs are the evidence a railway safety authority wants to see. Plausible runners-up are waterfall (the trackside hardware still has to be built and certified around the software) or, if one is being lenient, agile, but neither gives the proof-based guarantee the critical core needs.
074. Reuse-oriented development
The idea
Reuse-oriented development is based on systematic reuse: systems are integrated from existing components or commercial off-the-shelf (COTS) systems. Rather than build from scratch, the team finds, evaluates, and assembles. This approach is becoming more important and popular, but we still have limited experience with its wide use across different domains.
Process stages
Problems
Applicability
Reuse-oriented development is the right main model when several of these signals hold together:
A holiday-booking website that lets travellers search flights, reserve hotels, hire a car and pay, by calling an airline-search service, a hotel-inventory service, a car-hire service, a payment gateway and a maps provider, is almost pure integration. The team writes very little novel logic; the value is in selecting, combining and orchestrating components that other companies build and maintain. It is not critical, the requirements are easy to establish, and there is no reason to deliver it in safety-driven increments. That profile points straight at reuse-oriented development, with waterfall as a plausible runner-up for the surrounding structure.
The course project does not reach the implementation phase – it ends with system modelling and design (component, architecture, deployment diagrams). Even so, when you draw your component diagram in Phase 4, you should think about which components you would write yourself and which you would buy or take from a library: a payment component, an authentication component, a mapping component. The component diagram is more honest – and more realistic – when it acknowledges what would actually be reused. The point of reuse-oriented thinking is to make that reuse a deliberate design decision, not an afterthought.
08Side by side
A single-page comparison of the four generic models, with prototyping shown as a technique that can be applied within any of them.
| Waterfall | Evolutionary / Agile | Formal | Reuse-oriented | |
|---|---|---|---|---|
| Core idea | Distinct sequential phases | Specification and development interleaved | Specification transformed into code by correctness-preserving steps | System assembled from existing components |
| Best when | Requirements are stable and well understood | Requirements will evolve during the project | Failure is unacceptable; correctness must be proven | Common functionality already exists as components |
| Worst when | Requirements will change | Process visibility and formal sign-off are needed | System has heavy human-interface content | Project is small; integration costs dominate |
| Documentation | Heavy, per stage | Lean, evolves with the system | Heavy, formal specifications and proofs | Component contracts, integration design |
| Customer involvement | Mostly at start (specification) and end (acceptance) | Continuous | At specification; less during transformation | At requirements and at adjustment of requirements |
| Risk profile | Late discovery of problems | Drift if not disciplined | Specialist skill bottleneck | Component suppliers' future |
| Typical domain | Aerospace, defence, regulated | Most modern commercial software | Safety-critical, security-critical kernels | Enterprise applications, ERP, integration projects |
How to choose at the broadest level
The honest answer is that real projects rarely use a pure form. A safety-critical project will use formal methods for the kernel, waterfall-like discipline for the structure, and prototyping for the user-facing parts. A start-up will use evolutionary development for the application, reuse-oriented development for non-differentiating parts, and prototyping for the user interface. The model is a lens, not a cage.
The factors that drive the choice:
The next section makes these factors concrete with four worked examples.
09What process for what software?
To make the choice tangible, here are four examples drawn from systems you may know. Each example states the problem, names the dominant factors, and proposes a process – usually a blend of models, not a pure one. The reasoning matters more than the conclusion.
When you are asked to pick the single best main model for a described system, the move is always the same: read off the system’s profile (its size, how critical it is, how settled the requirements are, how much already exists to reuse, and whether delivery has to be incremental), then match that profile to the model whose strengths fit it. The table below is that mapping in one place. Name the dominant factor first, then justify the model against it; a one-line reason for why the obvious runner-up is weaker earns the rest of the marks.
| Best main model | Choose it when the system… | Typical runner-up |
|---|---|---|
| Waterfall (plan-driven) |
is relatively large; requirements are well understood and not difficult to establish up front; the scope and deadline are fixed; delivery does not need to be incremental; it is not safety-critical. E.g. a payroll system for a large organisation, where the rules are fixed by well-documented regulations and the launch date is set in advance. | Agile, where the user interface or a sub-part still needs feedback; reuse-oriented if much of it already exists. |
| Agile (evolutionary) |
is small to medium; requirements are hard to establish without prototyping or user feedback (a consumer product in an uncertain market); adaptation and speed matter more than a signed-off specification. E.g. a new social or content-sharing app whose key features can only be pinned down by putting early versions in front of real users and iterating. | Waterfall, if one wrongly assumes the requirements are already clear. |
| Formal transformation |
is critical (safety or security); its core is small to medium; the requirements are precise, stable, and can be expressed mathematically; provable correctness matters more than early delivery. E.g. a railway signalling interlocking that must never grant two trains conflicting routes, or an avionics flight-control law. | Waterfall (there may be a hardware fabrication step); agile only if one is being lenient. |
| Reuse- oriented |
can be assembled largely from existing components or external/cloud services; the effort is mainly integration; it is not critical and not complex; requirements are easy to establish; size is medium to large. E.g. an e-commerce store assembled from off-the-shelf payment, search, shipping and email components. | Waterfall, for the surrounding structure and procurement. |
The four worked examples below show the same reasoning at length. Note that a real project is usually a blend: the table names the dominant model, the one a single-best-answer question is asking for.
Example 1 – A university course registration portal
A web application where students browse the catalogue, enrol in courses, drop or add up to the deadline, and view their schedule. Faculty manage class lists; the registrar approves overrides. Replaces a paper-and-spreadsheet system.
Dominant factors. Requirements are well understood (every university already has a registration process); the organisation is bureaucratic and prefers to sign off documents; the system must integrate with existing student records; security and audit are important; the user community is captive (students must use it).
Proposed process. A largely plan-driven approach with a waterfall-like backbone for the integration and audit work, but with prototyping heavily used for the student-facing interface. The reason: the back end (catalogue, enrolment rules, transcript integration) maps cleanly onto a stable specification, but the user interface is where students will actually judge the system, and there the only reliable way to get it right is to put a prototype in front of real students. Reuse-oriented thinking applies to authentication, payment, and notification components – none of which the team should build from scratch.
What you would not do. Pure agile with no upfront documentation – the registrar will not sign off on anything that has not been specified. Pure waterfall – the user interface will be wrong on the first try.
Example 2 – A food-delivery mobile app start-up
A mobile app and back end where customers order food from local restaurants, pay in-app, and track delivery. Drivers use a separate app to accept jobs and navigate. Restaurants use a dashboard to manage their menu and incoming orders.
Dominant factors. Requirements are not well understood at the start – the team needs to discover what users will actually pay for, what makes drivers stay, and what restaurants tolerate. The market changes faster than any specification document can keep up with. The team is small and co-located. There is no regulator to satisfy. Speed to market is critical.
Proposed process. Strongly evolutionary / agile, with two-week iterations and continuous customer feedback. Prototyping is used at the start to validate the core flows before any real engineering. Reuse-oriented for the parts that are not differentiators – maps, payments, push notifications, identity – buy or use third-party APIs rather than build. Waterfall would actively damage this project; the team needs to learn from real users in weeks, not produce a specification document over months.
What you would not do. Lock the specification before the first release. Build in-house what already exists as a paid API. Skip user testing because "we know what users want".
Example 3 – A railway signalling and train-control system
Embedded software that decides which trains may enter which sections of track and which signals may show “proceed”, so that two trains are never routed into collision. A failure can kill many people at once. The software must be certified by a railway safety authority before it is allowed to operate.
Dominant factors. Failure consequences are catastrophic. Requirements come from safety regulations and signalling engineers, and they are stable but voluminous. Documentation must be exhaustive – every requirement must be traceable to a design decision, to code, and to a test. Cost is a secondary concern; correctness is primary.
Proposed process. A formal systems development approach for the safety-critical interlocking logic (route locking, signal-aspect rules), surrounded by a waterfall-like structure with full V&V (verification and validation) at every stage for the rest of the system. Prototyping may be used for the signaller's control console (which is where most operating errors actually originate), but the prototype is then re-specified and re-built rigorously, not handed over as a finished product. Agile and Spiral are unsuitable for the safety core here: the regulator does not accept "we will refine the requirements as we go".
What you would not do. Use evolutionary development for the safety kernel. Skip the formal proof obligations. Treat documentation as overhead.
Example 4 – A national tax-filing system being modernised
A government department wants to replace a thirty-year-old mainframe tax-filing system with a modern web-based one. The new system must integrate with banks, employers, and existing audit databases. It must handle millions of submissions during the filing window.
Dominant factors. Requirements are mostly fixed by tax law (and change yearly when the law changes). Integration with legacy systems dominates the technical effort. The timeline is constrained by the tax year. The user base is enormous and politically visible – any failure makes the news. The procurement process favours fixed-price contracts and formal sign-off.
Proposed process. A primarily reuse-oriented approach – very little of this system should be written from scratch when commercial tax-engine components, identity-verification services, and government-cloud platforms exist. Plan-driven structure to satisfy procurement and political accountability. Incremental rollout (covered in detail in the second companion): launch first to a small pilot region, then expand. Prototyping for the citizen-facing forms, where errors translate into a flood of help-desk calls. Pure agile would not survive the procurement process; pure waterfall would deliver too late and too rigid to absorb annual tax-law changes.
What you would not do. Build a tax engine from scratch when several mature ones exist. Promise a single big-bang launch on a fixed date for the whole country.
The pattern across the four examples
Notice that none of the four answers was a single pure model. Every real project blends. The dominant model usually comes from the dominant factor – criticality drives the medical pump toward formal methods; market uncertainty drives the start-up toward agile; integration cost drives the tax system toward reuse; institutional process drives the registration portal toward plan-driven. But every project also borrows from the others where it makes sense.
The course project follows a structure that is closest to a plan-driven approach – fixed phases (Initiation, Business Definition, Requirements Engineering, Requirements Analysis and Modelling, System Modelling and Design), each with defined outputs, and a milestone interview between phases. This is deliberate: it gives you the chance to practise each activity carefully. But the milestone interviews themselves are evolutionary in spirit – they exist to surface misunderstandings and let the customer-developer pair correct course before the next phase. So even your project, at the activity level, is a small blend.
10What is next
The four generic models above describe how a project is organised at the highest level. They do not yet say how iteration is structured, how risk is managed, or how Agile teams actually work day to day.
The second companion in this pair, Iteration and Agile process models – Agile, Scrum, XP, Kanban and Spiral, takes that next step. It covers:
Beyond this companion, the four core activities – Specification, Design, Validation, and Evolution – each become the focus of subsequent topics in the course. Requirements engineering covers specification in depth. The system modelling block covers design through UML. Validation is interleaved throughout and revisited in the design block.
11References
Primary sources for this lecture
- Sommerville, I. (2016). Software Engineering, 10th edition, Chapter 3 (Software Processes). Pearson. (R2)
- Bruegge, B. and Dutoit, A. (2013). Object-Oriented Software Engineering Using UML, Patterns, and Java, 3rd edition, Chapter 2. Prentice Hall. (R1)
Foundational papers and books
- Royce, W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970. The paper that defined the waterfall model – and warned against using it as a strict sequence.
- Mills, H., Dyer, M. and Linger, R. (1987). Cleanroom Software Engineering. IEEE Software, 4 (5), 19–25. The foundational paper on the formal-methods-based Cleanroom approach.
- Beck, K. et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org
Recommended further reading
- Pressman, R. and Maxim, B. (2020). Software Engineering: A Practitioner's Approach, 9th edition, Chapters 3 and 4. McGraw-Hill. (R5) Treats the same models with somewhat different framing, especially Pressman's process taxonomy.
- Szyperski, C. (2002). Component Software: Beyond Object-Oriented Programming, 2nd edition. Addison-Wesley. The standard reference on reuse-oriented and component-based development.