The software development life cycle (SDLC) is the structured process used to plan, design, create, test, and maintain software. It provides a framework that helps development teams build reliable software on time and to the client's requirements — rather than writing code immediately and fixing problems later.
Why does GCSE computing cover the SDLC?
Every non-trivial software project — from a school library system to a banking app — follows some version of the SDLC. The DfE national curriculum for KS4 computing requires students to understand systematic software development. The AQA, OCR, and Edexcel GCSE specifications all include questions on the stages of the life cycle, methodologies (waterfall vs iterative/agile), and software testing strategies. Understanding the SDLC also helps students approach their own programming projects more professionally.
What are the main stages of the SDLC?
The SDLC is typically divided into five or six stages, though different models present them slightly differently:
| Stage | Key activities | Output |
|---|---|---|
| 1. Analysis | Interview clients, identify requirements, define the problem | Requirements specification |
| 2. Design | Plan the solution: algorithms, data structures, UI mockups, system architecture | Design documentation, diagrams |
| 3. Implementation (Coding) | Write the program in a programming language, following the design | Working code |
| 4. Testing | Verify the software works correctly and meets requirements; find and fix bugs | Test results, bug-fix log |
| 5. Evaluation | Review whether the software meets all original requirements; identify limitations | Evaluation report |
| 6. Maintenance | Fix bugs found after release; add new features; update for new hardware/OS | Updated software |
Stage 1: Analysis in detail
The analysis stage answers: "What does the software need to do?"
Techniques include:
- Interviews with stakeholders (clients, end users).
- Questionnaires to gather information from many users efficiently.
- Observation of how current (often manual) processes work.
- Document analysis — studying existing paperwork or forms the software will replace.
The output is a requirements specification — a document listing what the software must do (functional requirements: "the system shall allow users to log in") and what constraints it must meet (non-functional requirements: "the system shall respond within 2 seconds").
Stage 4: Testing strategies
Testing is one of the most frequently examined SDLC topics at GCSE. The main types of testing:
| Testing type | Who does it | What is tested |
|---|---|---|
| Unit testing | Developer | Individual functions or modules in isolation |
| Integration testing | Developer | How modules work together |
| System testing | Testing team | The whole system against requirements |
| Acceptance testing | Client / end users | Whether the system meets real-world needs |
Black-box vs white-box testing
| Feature | Black-box testing | White-box testing |
|---|---|---|
| Knowledge of code | Tester does NOT see the code | Tester CAN see and analyse the code |
| Focus | Does the output match expected output for given inputs? | Are all code paths executed? Are all branches tested? |
| Who performs it | Often separate testing team or users | Developer |
Normal, boundary, and erroneous test data
For any input that accepts a range, test:
- Normal data — typical valid input within the accepted range (e.g. age = 15 for a teen app).
- Boundary data — values at the edges of the valid range (e.g. minimum age = 13, maximum = 18).
- Erroneous data — invalid input the program should reject (e.g. age = −1, or "fifteen" as text).
Worked example — a program that accepts exam scores from 0 to 100:
| Test data | Type | Expected result |
|---|---|---|
| 50 | Normal | Accepted |
| 0 | Boundary (lower) | Accepted |
| 100 | Boundary (upper) | Accepted |
| −1 | Erroneous | Rejected with error message |
| 101 | Erroneous | Rejected with error message |
| "abc" | Erroneous | Rejected with error message |
Waterfall vs iterative/agile development
The two main approaches to organising the SDLC stages are waterfall and iterative (agile):
| Feature | Waterfall model | Iterative / Agile model |
|---|---|---|
| Sequence | Strictly linear: each stage completes before the next begins | Cycles (sprints): analysis→design→code→test repeated in short loops |
| Flexibility | Low: changing requirements mid-project is costly | High: requirements can evolve between sprints |
| Client involvement | Mostly at start and end | Continuous: client reviews each sprint |
| Risk of wrong product | High: final product only seen at end | Low: each sprint delivers a working increment |
| Best for | Well-defined, stable requirements; regulated industries | Evolving requirements; modern consumer software |
| Documentation | Extensive upfront | Lighter; working software over comprehensive docs |
What is an iterative sprint?
In agile development, a sprint is a fixed-length period (typically 1–4 weeks) during which a small, working piece of software is designed, coded, and tested. At the end of the sprint, the client sees what has been built, provides feedback, and the team adjusts the plan for the next sprint. This rapid feedback loop prevents the classic waterfall problem of delivering a complete product that does not match what the client actually needed.
Frequently asked questions
Why can't you just start coding without a design stage?
Coding without a design stage — sometimes called "code and fix" — is tempting but produces brittle, hard-to-maintain software. Bugs discovered late in development (after many features have been built on a flawed design) are extremely expensive to fix. The design stage forces you to think through the solution systematically, identify potential problems before writing code, and produce documentation that other team members can work from. Studies of software projects consistently show that finding and fixing a design error in the design stage costs far less than fixing the same error after coding.
What is the difference between verification and validation in testing?
Verification checks that the software was built correctly — does the code match the design? Validation checks that the right software was built — does it meet the client's actual needs? A program can pass verification (it does exactly what the specification says) but fail validation (the specification turned out not to reflect what the client actually wanted). Both are necessary for successful software delivery.
What happens during maintenance?
Software maintenance begins after the software is released and typically accounts for the largest single share of total software cost over a product's lifetime. There are three types: corrective maintenance (fixing bugs found by users), adaptive maintenance (updating the software to work with new hardware, operating systems, or external services), and perfective maintenance (adding new features or improving performance based on user feedback). Some widely used systems (operating systems, enterprise software) continue to be maintained for decades.
What is meant by "requirements" in software development?
Requirements describe what a piece of software must do and how well it must do it. Functional requirements specify behaviours: "the system shall allow users to search for books by author." Non-functional requirements specify constraints: "search results shall be displayed within 1 second." Requirements are gathered during the analysis stage and form the basis for both the design and the acceptance testing criteria. A well-written requirements document is the single most important document in a software project — if it is wrong, all subsequent work may be wasted.
For Socratic GCSE Computer Science tutoring on the SDLC, programming projects, and algorithms, visit aitutors.me.