Unit 2: Methodologies
Learning Objectives
- Describe and compare Waterfall, Spiral, Agile, and DevOps-oriented process models
- Evaluate the trade-offs between sequential and iterative approaches
- Select and justify an appropriate methodology for a given project context
- Critically assess the limitations of software process models
Core Input
Read through each tab before moving to the key concepts.
Sequential models organise the SDLC into distinct phases that complete in order, with each phase producing artefacts consumed by the next.
Waterfall
The Waterfall model is the canonical sequential approach: requirements → design → implementation → testing → deployment → maintenance. Each phase must be formally completed and signed off before the next begins. Changes after a phase is closed are expensive and discouraged.
Waterfall suits projects with stable, well-understood requirements and fixed scope — safety-critical systems (aerospace, medical devices), regulatory systems, and large-scale infrastructure where upfront specification is contractually required. Its weakness: requirements are rarely fully stable, and late-stage discovery of problems can be catastrophic.
Spiral
The Spiral model, introduced by Barry Boehm, adds risk management to the sequential framework. Each loop of the spiral passes through four quadrants: planning, risk analysis, engineering, and evaluation. Early iterations focus on high-risk elements; later iterations build out the full system. It suits large, complex, high-risk projects where identifying and mitigating risk at each iteration is more important than rapid delivery.
V-Model
An extension of Waterfall in which each development phase is paired with a corresponding testing phase. Requirements pair with acceptance testing; design pairs with integration testing; implementation pairs with unit testing. The V-shape reflects the relationship between specification (left arm) and verification (right arm). Used widely in regulated industries (automotive, medical devices).
Iterative models deliver software in repeated cycles, with each cycle producing a working increment and incorporating feedback.
Agile
Agile is a set of values and principles, articulated in the 2001 Agile Manifesto, that prioritise individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
In practice, Agile is implemented through frameworks. Scrum organises work into time-boxed sprints (typically 1–4 weeks), with a prioritised backlog, daily standups, sprint reviews, and retrospectives. Kanban uses a visual board to manage flow without fixed-length iterations. Extreme Programming (XP) emphasises technical practices: test-driven development, pair programming, continuous integration, and frequent small releases.
Agile works well when requirements are uncertain or evolving, when rapid feedback from users is possible, and when the team and client can collaborate closely. It struggles when contracts require fixed-price fixed-scope delivery, or when regulatory compliance demands upfront documentation.
Scaled Agile
Frameworks such as SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum) extend Agile principles to large organisations with multiple teams. They introduce coordination layers above the team level: programme increments, release trains, and portfolio backlogs. Their effectiveness is debated — they solve real coordination problems but can reintroduce the bureaucratic overhead Agile was designed to avoid.
DevOps extends Agile thinking beyond development into operations — breaking down the traditional wall between the team that builds software and the team that runs it. The core idea is that frequent, reliable delivery requires automation, shared responsibility, and continuous feedback loops spanning the full SDLC.
Key DevOps practices include:
- Continuous Integration (CI) — developers integrate code frequently (often multiple times per day); automated builds and tests run on every commit to detect defects early.
- Continuous Delivery (CD) — every build that passes automated testing is deployable to production. The deployment decision remains human; the capability is always ready.
- Continuous Deployment — every build that passes testing is automatically deployed to production. Requires very high confidence in automated test coverage.
- Infrastructure as Code (IaC) — infrastructure is defined and versioned as code, enabling reproducible, auditable environments.
- Monitoring and Observability — production systems are instrumented to surface performance, error, and usage data in real time, closing the feedback loop back to development.
DevOps does not replace Agile — it extends it. A team practising Scrum with a mature CI/CD pipeline and shared operational responsibility is practising DevOps-oriented Agile delivery. The culture shift — developers caring about production, operations caring about code quality — is as important as the tooling.
Key Concepts: Process Models
Expand each item. These concepts distinguish between the models at a level of precision appropriate for critical analysis.
Waterfall is frequently dismissed as outdated, but this reflects a misunderstanding of the contexts it was designed for. Its genuine strengths are:
- Contractual clarity — fixed scope, fixed cost, fixed timeline are possible when requirements are truly stable
- Documentation completeness — each phase produces auditable artefacts required for regulatory compliance
- Predictability — progress can be measured against a defined plan
Waterfall remains appropriate for safety-critical and regulated systems (medical devices, avionics, nuclear control systems) where comprehensive upfront specification is legally required and change during development is genuinely unacceptable. The error is applying it to projects with unstable or poorly understood requirements — not the model itself.
The 2001 Agile Manifesto states four value pairs:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Crucially, the manifesto says: "while there is value in the items on the right, we value the items on the left more." This is a statement of priority, not elimination. Agile does not mean no documentation, no planning, or no contracts. Misreading it as a licence to skip these has caused many failed projects labelled as "Agile failures" that were, in practice, failures of discipline and governance.
Technical debt is the accumulated cost of short-term engineering decisions that trade quality or completeness now for speed. Like financial debt, it accrues interest: the longer it is left unaddressed, the more expensive it becomes to resolve.
Common sources of technical debt:
- Skipping design in favour of coding immediately
- Writing incomplete or no automated tests to meet a sprint deadline
- Duplicating code rather than refactoring
- Choosing a quick architectural fix over a correct one
Iterative methodologies, particularly Agile, can accelerate technical debt accumulation if teams consistently prioritise feature delivery over code quality. A mature Agile team allocates capacity for technical debt reduction in every sprint. A team that never does this will find velocity declining over time as the codebase becomes increasingly difficult to change.
Methodology selection requires matching the characteristics of the process model to the specific conditions of the project. Key factors to assess:
- Requirement stability — are requirements well-understood and unlikely to change (→ sequential) or evolving and uncertain (→ iterative)?
- Risk profile — are there significant technical or business risks that must be addressed early (→ Spiral)?
- Stakeholder availability — can users and clients engage frequently for feedback (→ Agile), or is the relationship primarily contractual (→ Waterfall/V-Model)?
- Regulatory context — does the system require upfront documentation, formal verification, or audit trails (→ V-Model, Waterfall)?
- Team maturity — does the team have the discipline and tooling to support CI/CD, test-driven development, and continuous refactoring (→ DevOps/Agile)?
In practice, most real projects use hybrid approaches — Agile development with Waterfall-style contractual phases, or DevOps delivery within a risk-managed programme structure. The skill is understanding what each model provides and why.
Key Concepts: Trade-offs and Limitations
Process models are tools, not solutions. Each has genuine limitations worth examining critically.
Despite its widespread adoption, Agile has documented failure modes:
- Scope and cost unpredictability — in a fixed-budget project, iterative scope expansion can exhaust resources before the system is complete
- Documentation debt — prioritising working software can lead to insufficient documentation for maintenance teams who join later
- Stakeholder dependency — Agile requires sustained, informed stakeholder engagement; if this is unavailable, sprint reviews produce poor feedback
- "Zombie Agile" — organisations adopt Agile ceremonies (standups, sprints, backlogs) without the underlying culture change, producing bureaucratic overhead without the benefits
Agile and DevOps are complementary but distinct. Agile addresses how development teams organise their work. DevOps addresses how development and operations teams collaborate to deliver, run, and improve software.
An Agile team that delivers working software at the end of every sprint but then hands it to a separate operations team for a six-week deployment process has not achieved continuous delivery. DevOps removes this bottleneck by making deployment automation, monitoring, and operational responsibility part of the development team's remit.
The DORA (DevOps Research and Assessment) metrics provide evidence-based measures of software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. High-performing teams, as defined by DORA research, deploy multiple times per day with very low failure rates — outcomes that require both Agile and DevOps practices.
All process models are idealisations. Real projects depart from them in predictable ways:
- Requirements change even when formally frozen
- Estimates are systematically optimistic (Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law")
- Integration problems emerge that were not visible at the component level
- Organisational and personnel changes disrupt planned workflows
This is not an argument against process models — it is an argument for using them thoughtfully, with explicit acknowledgement of their assumptions and limitations, and with risk management practices that identify and address departures early.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
A team is building flight-control software for a commercial aircraft. Requirements are defined by detailed regulatory standards and cannot change once agreed. Which methodology is most appropriate?
According to the Agile Manifesto, which pairing correctly reflects Agile values?
AI tools are beginning to influence how teams organise and plan their development process — generating user stories from product descriptions, estimating sprint capacity, or suggesting backlog priorities based on historical velocity data.
- Assist: AI can draft initial backlog items, summarise stakeholder feedback into requirements, and generate release notes from commit histories — reducing the administrative overhead of Agile ceremonies.
- Risk: AI-generated plans lack contextual knowledge of team dynamics, organisational politics, and unstated constraints. A sprint plan that looks optimal on paper may ignore a key developer's leave, a dependency on a third-party API, or a client relationship that requires a particular sequencing of deliverables.
- Principle: Methodology selection depends on factors AI cannot observe — culture, regulation, risk appetite, and the specific humans involved. Use AI to reduce administrative friction; use engineering judgment to make process decisions.
Activities
Individual task
For each of the three project scenarios below, select the most appropriate methodology and write a 3–4 sentence justification. Address: requirement stability, regulatory context, stakeholder availability, and risk profile.
- A startup building an MVP mobile app to validate a new consumer product idea. Requirements are intentionally vague and will evolve based on user testing.
- A government agency procuring a new benefits payment system. The system must integrate with existing national infrastructure, and a fixed-price contract has been agreed with the vendor.
- A hospital trust replacing its electronic patient records system. The new system must meet NHS data standards, handle confidential patient data, and integrate with radiology and pharmacy systems.
Pair task
Exchange your scenario justifications with a partner. For each scenario:
- Did you choose the same methodology? If not, which argument is stronger and why?
- Identify one assumption your partner made that you would challenge.
- Are there any hybrid approaches that might better serve the scenario than a single methodology?
Prepare a brief position (2–3 sentences) for one scenario where you and your partner disagree — you will each defend your position.
Group task — methodology decision for the case study
Return to the hospital appointment booking system your group defined in Unit 1. As a group, decide which development methodology you will use for this system.
Your decision must be documented as a brief rationale covering:
- The methodology chosen (or hybrid approach)
- Three reasons this methodology suits the specific characteristics of this system
- Two risks or limitations of this choice and how you will mitigate them
- One alternative methodology considered and the reason it was rejected
You will refer back to this decision in Unit 10 — knowing what you know at the end of the course, was it the right choice?
Review
Waterfall treats change as a cost to be minimised — phases are formally closed, and changes after closure require expensive re-work across all subsequent phases. The model works when this cost is acceptable because requirements are genuinely stable.
Agile treats change as an expected input — short iterations mean the cost of incorporating new information is low, because no phase has been "completed" for very long. The model works when stakeholders can engage continuously and when the team has the discipline to maintain quality while moving quickly.
Technical debt is the accumulated cost of short-term engineering decisions that trade quality for speed. It accrues interest: deferred design decisions, absent tests, and architectural compromises become progressively more expensive to resolve.
It matters because no software is ever "finished" — it must be maintained, extended, and adapted throughout its lifetime. A system with high technical debt resists change: every modification risks breaking something unrelated, and the effort required to understand the system grows over time. Managing technical debt is an active responsibility, not something to address "when there is time."
Proceed to Unit 3: Requirements Engineering when ready.