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.
This approach is embodied in the Cleanroom approach, originally developed by IBM. Some authors consider it a variant of the waterfall model, with the development phase replaced by a chain of formal transformations. The classic variant is sometimes called the V-model when test planning is mirrored onto each specification stage.
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, infusion-pump dosing logic, and railway interlocking systems.
Problems
Applicability
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
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.
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 medical infusion-pump controller
Embedded software that controls the rate at which a hospital infusion pump delivers medication to a patient. A failure can kill. The software must be approved by a regulator before deployment.
Dominant factors. Failure consequences are catastrophic. Requirements come from a regulator and from clinical experts, 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 control loop (drug-rate calculation, alarm logic), 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 operator interface (which is where most clinical 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 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.