What stages does software pass through from idea to maintenance, and how do development models differ?
Describe the stages of the software development lifecycle and compare the waterfall and agile (iterative) approaches
A focused answer to the H2 Computing outcome on the software development lifecycle. The analysis, design, implementation, testing, deployment and maintenance stages, and the contrast between the waterfall and agile iterative models.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
SEAB wants you to describe the stages of the software development lifecycle (SDLC) and compare the waterfall and agile approaches. The central idea is that building software well is a managed process, not just coding, and that different models organise the same essential stages differently to suit how much the requirements are likely to change.
The answer
The stages of the lifecycle
Software typically passes through these stages:
- Analysis (requirements). Understand the problem and specify what the system must do, working with the client. Output: a requirements specification.
- Design. Decide how it will work - architecture, data structures, interfaces, algorithms. Output: design documents.
- Implementation (coding). Write the program from the design.
- Testing. Verify it meets the requirements and is free of defects (unit, integration, system and acceptance testing).
- Deployment. Release the working system to users.
- Maintenance. Fix bugs found in use, adapt to changing needs, and improve the system over its life - usually the longest and costliest stage.
Why testing runs throughout
Testing is not just the fourth box. Defects found early (during design or as code is written) are far cheaper to fix than those found after release, where they may force redesign. Good practice tests continuously - checking each unit as it is built and each integration as it is assembled - so quality is built in rather than inspected at the end.
The waterfall model
Waterfall is linear and sequential: each stage is completed and signed off before the next begins, with substantial upfront documentation.
- Strengths: simple to manage, clear milestones, thorough documentation.
- Weaknesses: inflexible - changing requirements late is costly because earlier stages are treated as finished, and a working system appears only near the end.
The agile (iterative) model
Agile develops in short iterations (sprints), each producing a small working increment, with frequent client feedback and the freedom to adapt requirements between iterations.
- Strengths: handles changing requirements well, delivers value early, and reduces risk through continuous feedback.
- Weaknesses: needs close collaboration, can be harder to predict and document fully in advance.
Choosing a model
Use waterfall when requirements are stable and well understood (regulated or safety-critical systems where the specification is fixed). Use agile when requirements are unclear or likely to evolve (a new product refined through user feedback).
Examples in context
Example 1. A banking core system. Replacing a bank's core ledger, where requirements are fixed by regulation and correctness is critical, favours a waterfall-style approach: the specification is settled and documented upfront, and each stage is verified before the next, because late change is unacceptably risky.
Example 2. A consumer mobile app. A startup's app evolves rapidly based on user behaviour, so it is built agile: each two-week sprint ships a working increment, analytics and feedback shape the next sprint's requirements, and features can be added or dropped between iterations without derailing a rigid plan.
Try this
Q1. List the software development lifecycle stages in order. [2 marks]
- Cue. Analysis (requirements), design, implementation (coding), testing, deployment, maintenance.
Q2. Give one strength and one weakness of the waterfall model. [2 marks]
- Cue. Strength: simple to manage with clear milestones and documentation. Weakness: inflexible to late requirement changes, with a working system only near the end.
Q3. When is an agile approach more suitable than waterfall? [1 mark]
- Cue. When requirements are unclear or expected to evolve, so iterative feedback can shape the product.
Exam-style practice questions
Practice questions written in the style of SEAB exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
Original6 marks(a) List, in order, the main stages of the software development lifecycle. (b) Briefly state what happens in the analysis stage and the maintenance stage. (c) Explain why testing is not a single stage at the end but happens throughout.Show worked answer →
(a) A standard ordering: analysis (requirements), design, implementation (coding), testing, deployment, maintenance.
(b) Analysis gathers and specifies what the system must do - understanding the problem and writing the requirements with the client. Maintenance is the ongoing work after release: fixing bugs found in use, adapting to new needs, and improving the system over its lifetime.
(c) Testing throughout catches defects early, when they are far cheaper to fix than after release. Unit tests check components as they are written, integration tests check they work together, and bugs found late may force expensive rework of design. Continuous testing reduces risk and improves quality rather than leaving all checking to one fragile final phase.
Markers reward the ordered stages, correct descriptions of analysis and maintenance, and the early-and-continuous testing argument (cheaper to fix early).
Original5 marksCompare the waterfall and agile (iterative) approaches to software development. Give one situation where each is the more suitable choice.Show worked answer →
Waterfall is a linear, sequential model: each stage (analysis, design, implementation, testing, deployment) is completed before the next begins, with heavy upfront documentation. It is simple to manage but inflexible - changing requirements late is costly because earlier stages are "finished".
Agile (iterative) develops in short cycles (iterations or sprints), each producing a working increment, with frequent feedback from the client and the freedom to adapt requirements between iterations. It handles change well but needs close collaboration and can be harder to predict precisely.
Suitable situations: waterfall suits projects with stable, well-understood requirements (for example, safety-critical or regulated systems where the specification is fixed and documentation is mandated). Agile suits projects where requirements are unclear or expected to evolve (for example, a startup product refined through user feedback).
Markers reward the linear-versus-iterative contrast, the flexibility difference, and a sensible matching situation for each.
Related dot points
- Design test cases using normal, boundary and erroneous data, distinguish levels of testing, and apply systematic debugging techniques
A focused answer to the H2 Computing outcome on testing and debugging. Choosing normal, boundary and erroneous test data, unit and integration and system testing, black-box versus white-box, and systematic debugging.
- Apply decomposition, modularity and abstraction to structure software, explaining the benefits for maintenance and reuse
A focused answer to the H2 Computing outcome on decomposition and abstraction. Breaking problems into modules, the role of interfaces, information hiding through abstraction, and the benefits for maintainability and reuse.
- Define classes with attributes and methods, create objects, and apply encapsulation, inheritance and polymorphism in Python
A focused answer to the H2 Computing outcome on object-oriented programming. Classes and objects, attributes and methods, the constructor, and the principles of encapsulation, inheritance and polymorphism in Python.
- Use Python selection, iteration and functions with parameters and return values to structure a solution, applying scope correctly
A focused answer to the H2 Computing outcome on Python control flow. Selection with if and elif, iteration with for and while, defining functions with parameters and return values, and local versus global scope.
- Model a problem domain with an entity-relationship diagram, identifying entities, attributes, relationships and cardinality, and map it to tables
A focused answer to the H2 Computing outcome on ER modelling. Entities, attributes and relationships, one-to-one, one-to-many and many-to-many cardinality, resolving many-to-many with a link table, and mapping an ER model to relational tables.