- ✓The Waterfall model organises software development into sequential phases (requirements, design, implementation, testing, deployment, maintenance) that are completed one at a time, making it well-suited to projects with fixed and well-understood requirements.
- ✓Agile methodologies break development into short iterations (sprints) with regular review and adaptation, enabling teams to respond to changing requirements and deliver value incrementally rather than waiting until the project is complete.
- ✓Spiral development combines elements of Waterfall and iterative development, with a strong emphasis on risk analysis at each cycle: it is particularly suited to large, complex, high-risk projects where requirements are uncertain.
- ✓DevOps is not strictly an SDLC methodology but a cultural and technical movement that emphasises collaboration between development and operations teams, continuous integration and continuous delivery of software.
- ✓No single SDLC is universally appropriate: the right choice depends on the nature of the project, the stability of the requirements, the size and experience of the team, and the organisational context in which development is taking place.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Hello and welcome back to HTQ Digital Technologies: The Study Podcast. I'm Alex, and today Sam and I are starting Unit 7, which is about software development lifecycles. This is a really foundational unit, isn't it, Sam?
Sam: Genuinely foundational. Understanding how software is developed, the phases it goes through from initial idea to deployed product to eventual retirement, is essential context for everything else in digital technology. Every tool, every practice and every role in software development exists in relation to some part of this lifecycle.
Alex: Let's start by mapping the main SDLC models that exist. What are we looking at?
Sam: The major ones are Waterfall, Agile, Spiral and DevOps, though they're not all strictly the same kind of thing. Waterfall and Agile are process models that describe how development is organised. Spiral is a risk-driven model that sits somewhere between the two in terms of structure. DevOps is more of a cultural and technical movement that influences how development and operations work together rather than a distinct development process.
Alex: Let's take Waterfall first, since it's the oldest and in some ways the most intuitive.
Sam: Waterfall organises development into a sequence of distinct phases: requirements, where you define what the system needs to do; design, where you work out how it will be structured; implementation, where you actually build it; testing, where you verify that it works correctly; and deployment and maintenance. The key characteristic is that each phase is largely completed before the next begins, like water flowing down a series of steps. The plan is made upfront and is expected to hold throughout.
Alex: And the criticism of Waterfall?
Sam: The fundamental criticism is that it assumes requirements can be defined completely and accurately at the beginning of a project, before any working software exists. In practice, users and stakeholders often don't know exactly what they want until they see a working version, which means the requirements captured at the start are frequently incomplete or wrong. By the time this becomes apparent in a Waterfall project, significant investment has been made in design and implementation that may need to be substantially revised.
Alex: And Agile was developed as a response to those limitations?
Sam: The Agile movement crystallised with the Agile Manifesto in 2001, which articulated a set of values and principles that prioritised delivering working software frequently, welcoming changing requirements, collaborating closely with customers and responding to change over following a plan. Agile methods break development into short iterations, typically one to four weeks, each producing a potentially deliverable increment of working software. This enables much faster feedback and much greater flexibility to adapt.
Alex: Is there a place for Waterfall in modern development?
Sam: Absolutely. For projects with genuinely stable and well-understood requirements, fixed contractual scope, regulatory requirements for upfront documentation or large-scale systems where the cost of getting the architecture wrong is very high, elements of a more planned approach make sense. The dichotomy between Waterfall and Agile is often overstated in practice: many successful projects combine elements of both.
Alex: Great foundation. Thanks, Sam. We'll look at the feasibility study in our next lesson.