SDLC Models

The Software Development Life Cycle (SDLC) is the framework that describes the activities performed at each stage of building software — from the first idea to a running system in production and its eventual retirement. An SDLC model is a particular way of sequencing and repeating those activities. The phases stay broadly the same; what changes between models is how rigidly they are ordered and how often you loop back through them.

The SDLC Phases

Almost every model is built from the same underlying phases. Understanding them makes the differences between models easy to see.

1. Requirements — gather and document what the software must do, from both business stakeholders and end users. The output is a specification.
2. Design — translate requirements into an architecture: components, data models, interfaces, and the technology stack.
3. Implementation — write the code that realises the design.
4. Testing — verify the software meets the requirements and is free of defects, through unit, integration, system, and acceptance testing.
5. Deployment — release the software into a production environment where users can access it.
6. Maintenance — fix bugs, adapt to changing requirements, and improve the system over its operational life.

Waterfall

The Waterfall model runs the phases strictly in sequence — each one completes fully before the next begins, like water flowing down a series of steps. Every phase produces a signed-off document that becomes the input to the next.

Strengths: simple to understand and manage; works well when requirements are fixed, well understood, and unlikely to change. Heavy documentation makes it easy to onboard people and audit progress.

Weaknesses: no working software until late in the cycle; expensive to change a decision once a phase is closed; assumes requirements can be fully known up front, which is rarely true. A misunderstanding in the requirements phase may not surface until testing, where it is most costly to fix.

Best suited to short, well-defined projects — or regulated domains where a complete paper trail is mandatory.

V-Model

The V-Model (Verification and Validation model) is an extension of Waterfall that pairs each development phase with a corresponding testing phase. The phases descend down the left side of a "V" and the matching test activities ascend the right side.

1. Requirements ↔ Acceptance testing
2. System design ↔ System testing
3. Architectural design ↔ Integration testing
4. Module design ↔ Unit testing

The key idea is that test planning happens alongside the matching design phase rather than being deferred to the end. This catches defects earlier and forces requirements to be testable. It shares Waterfall's core weakness, though: it is still rigid and assumes stable requirements.

Iterative & Incremental

Rather than building the whole system in one pass, the iterative and incremental approach delivers it in slices. Each cycle produces a working — if incomplete — version of the product, and successive cycles add functionality and refine what already exists.

1. Incremental — the system is partitioned into features that are built and delivered one increment at a time. Each increment adds new capability.
2. Iterative — the same feature is revisited across cycles, improving and refining it based on feedback rather than getting it perfect the first time.

Working software arrives early and feedback steers later cycles, so misunderstandings surface sooner than in Waterfall. The trade-off is that it needs good architectural planning up front — without it, repeated changes erode the design.

Spiral

The Spiral model combines iterative development with a strong focus on risk management. The project moves through repeated loops of the spiral, and every loop covers four quadrants:

1. Determine objectives — identify goals, alternatives, and constraints.
2. Identify & resolve risks — analyse risks and build prototypes to reduce the biggest unknowns.
3. Develop & test — build and verify this iteration's deliverable.
4. Plan the next iteration — review progress and plan the following loop.

By tackling the highest risks first, the Spiral model suits large, expensive, or high-stakes projects where failure is costly. Its downside is overhead: the constant risk analysis and prototyping make it heavyweight and demand experienced risk-assessment skills.

Agile

Agile is less a single model and more a family of methodologies built on the values of the 2001 Agile Manifesto: 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.

Software is delivered in short iterations (typically one to four weeks), each producing a potentially shippable increment. Requirements and solutions evolve through continuous collaboration with the customer. The two most common frameworks:

1. Scrum — work is organised into fixed-length sprints. A prioritised product backlog feeds a sprint backlog; daily stand-ups keep the team aligned; each sprint ends with a review and a retrospective. Roles include the Product Owner, Scrum Master, and development team.
2. Kanban — a continuous-flow approach with no fixed sprints. Work items move across a board (To Do → In Progress → Done), and work-in-progress limits prevent the team from taking on too much at once. Optimises for steady throughput rather than time-boxed batches.

Strengths: embraces changing requirements, delivers value continuously, and keeps the customer in the loop. Weaknesses: light documentation can hurt long-term maintenance; harder to predict final cost and timeline; depends heavily on a committed, collaborative team and customer.

Choosing a Model

In practice, modern teams rarely follow a single model purely. Most blend approaches — running Agile sprints while borrowing Spiral-style risk reviews for major architectural decisions, or wrapping an Agile delivery inside the documentation requirements of a regulated Waterfall contract. The model is a starting point, not a straitjacket.