Software Development Life Cycle (SDLC) for GCSE Computer Science

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.