Revise Development Life Cycle for Computer Science 0478 (O Level) — revision notes and instant AI marking. Free to start.
📖 Revision notes · preview
Cambridge (CIE) IGCSE · Computer Science
Program Development Life Cycle
Big idea: Good software isn't just "written" — it's understood, planned, built and checked
in four deliberate stages (Analysis → Design → Coding → Testing), so nothing important gets missed
and the final program actually solves the right problem.
The Four Stages at a Glance
1. Analysis
→
2. Design
→
3. Coding
→
4. Testing
In real projects this isn't strictly one-way — testing often sends developers back to fix coding, and even design, before moving on. Think of it as a cycle, not just a straight line.
Summary — The Whole Chapter in 5 Bullets
Analysis = figuring out exactly what problem needs solving, using abstraction to strip away irrelevant detail and focus on core functionality and requirements.
A requirements document is produced during analysis — it lists each requirement with a description and a success criteria so everyone knows when it's "done."
Design = turning the understood problem into a blueprint, shown using structure diagrams, flowcharts, or pseudocode.
Coding = writing the actual program in modules, with iterative testing happening constantly as each module is built and re-tested.
Testing (the final stage) = running the whole finished program repeatedly with varied test data to check it meets requirements and handles invalid input correctly.
Stage 1: Analysis
What actually happens here?
Before anyone writes a single line of code, the team has to be brutally clear about what problem
they're actually solving. This sounds obvious, but it's the stage most beginner programmers skip —
and it's exactly why their programs end up solving the wrong problem, or missing half the features
the client actually wanted.
The analysis stage is defined as: precisely understanding the problem the program is intended to solve.
Not "roughly understanding" — . That word matters in exam answers.
Abstraction
The act of removing unimportant details from a problem so you can focus on what actually matters —
the core functionality and the requirements. Abstraction is about deciding what to ignore just
as much as what to include.
The London Underground analogy (straight from the syllabus):
When you look at a Tube map, you don't see the real geography of London — the actual curves of tunnels,
the exact distances between stations, or how deep underground each line runs. All of that detail is
abstracted away because it's irrelevant to what you actually need: knowing that getting on at
Stop A will eventually get you to Stop B. The map keeps only the useful information (which lines connect,
which stations interchange) and throws away everything else. That's exactly what abstraction does to a
programming problem — it keeps the "core functionality and requirements" and discards the noise.
Core Functionality
Using abstraction helps identify the fundamental components of what the program is actually going
to solve — i.e. the essential jobs the program must do, stripped of extra detail.
Two things need to be nailed down before any coding starts:
The problem must be clearly understood by everyone working on it — not just the lead developer. If the team has different mental models of what they're building, the modules won't fit together later.
The overall goal of the solution must be agreed, along with any constraints — for example, limited resources (a small budget, limited processing power) or a requirement that the solution works on a specific platform (e.g. must run on Android, must work offline).
Requirements Document
To turn the "understood problem" into something a team can actually build against, a
requirements document is created. This document defines the problem and breaks it into
clear, manageable, understandable parts — using both abstraction (removing irrelevant detail)
and decomposition (splitting a big problem into smaller sub-problems).
KEY RULE
Each entry in a requirements document should have three parts:
1. A label (a short reference name/number for that requirement)
2. A description (what the requirement actually is)
3. Success criteria — a measurable statement of how you know the requirement has been achieved
Why success criteria matter
Without success criteria, "the login system should work well" is impossible to test objectively.
With success criteria — "the system must reject any password under 8 characters and display an error
message" — a tester can tick it off with certainty. Exam questions love asking you to write a success
criterion for a given requirement, so get comfortable making vague goals measurable.
Practice Questions
Question 1
Using the London Underground map example, explain what abstraction means in the context of program analysis.
Question 2
A requirements document states: "The app must let users reset their password." Write a suitable success criterion for this requirement.
Stage 2: Design
Once you know precisely needs to be solved, design is about working out .
The design stage involves using techniques to come up with a blueprint for a solution —
note the word "blueprint": nothing is coded yet. This stage exists so that mistakes get caught
on paper (cheap to fix) rather than in code (expensive to fix).
Think of it like building a house: an architect draws blueprints before anyone
pours concrete. If the blueprint has a mistake — say, a bathroom with no plumbing access — it's far
cheaper to fix on paper than after the walls are built. Program design works the same way: catching a
logic error in a flowchart takes minutes; catching it after 500 lines of code are written can take days.
THREE WAYS TO PRESENT A DESIGN
1. Structure diagrams — show how a program is broken into modules/sub-modules and how they relate to each other
2. Flowcharts — show the logical sequence of steps, decisions, and loops using standard symbols
3. Pseudocode — writes the logic in structured, plain-English-like code, without worrying about the exact syntax of a real programming language
Exam tip
If a question gives you a scenario and asks you to "design a solution," you're usually expected to
produce one of these three — a flowchart or pseudocode is most common. Don't jump straight into writing
actual Python/Java-style code unless the question specifically asks for it.
Practice Question
Question
Name and briefly describe two different ways a solution's design can be presented.
Stage 3: Coding
This is the stage most people picture when they think "programming" — but notice it's only the
third of four stages. By the time coding starts, the problem is understood (Analysis) and
the blueprint exists (Design), so coding is really just translating that blueprint into a real
programming language.
Developers write the program in modules — self-contained chunks of code, each handling one
part of the overall problem — using a suitable programming language that lets those modules
work together to deliver the full solution.
Iterative testing
As each developer writes a module, they don't wait until the whole program is finished to test it.
Instead, each module is tested and debugged thoroughly as it's built, to make sure it interacts
correctly with other modules and accepts data without crashing or causing errors. This is "iterative"
because it happens repeatedly, in small cycles, throughout coding — not once at the end.
IMPORTANT DETAIL
Developers often need to retest existing modules as new modules are created or changed —
because a new module might interact badly with one that used to work perfectly fine on its own.
This is a very common exam point: testing during coding is ongoing, not a one-time event.
Why this matters
This is precisely why "iterative testing" during coding is different from the final "Testing" stage —
iterative testing checks that individual modules work correctly and play nicely together as they're
being built, while the Testing stage (Stage 4) checks the whole finished system against the original
requirements.
Practice Question
Question
Explain why a developer might need to retest a module that was already working correctly.
Stage 4: Testing
Once the overall program (or set of programs) is fully created, it enters the final Testing stage.
Here, the complete system is run many times using varying sets of test data — not just the
"happy path" data that you'd expect a user to type in, but also unusual, extreme, and outright
invalid inputs.
The goal of this stage is twofold:
Confirm the program works as intended, exactly as outlined in the original requirements specification and design.
Confirm the program correctly rejects any invalid data that's input, rather than crashing or producing wrong results.
Test data (example)Alphanumeric sequences are given as a specific example — used to test password validation
routines. For instance, a password field might be tested with a mix of letters and numbers to check
whether the validation rules (minimum length, requires a number, etc.) are being enforced correctly.
Common misconception
Students often think "testing" only means checking the program works with normal, correct input.
In reality, good testing deliberately throws and data at the program
too — because a real user (or attacker) absolutely will, eventually, type something you didn't expect.
A program that only works with "nice" data isn't finished.
Practice Question
Question
A program has a field where users must enter their age. Suggest one piece of test data you would use, and explain what it is testing for.
What to Memorise
Term
Definition
Analysis
Precisely understanding the problem the program is intended to solve.
Abstraction
Removing unimportant details from a problem to focus on core functionality and requirements.
Requirements document
Defines the problem, broken into clear parts using abstraction and decomposition; each requirement has a label, description, and success criteria.
Success criteria
A measurable statement of how you know a requirement has been achieved.
Design
Using techniques to produce a blueprint for a solution — shown via structure diagrams, flowcharts, or pseudocode.
Module
A self-contained section of a program, coded to work with other modules to form the full solution.
Iterative testing
Ongoing testing/debugging of each module during coding to ensure correct interaction with other modules.
Testing (final stage)
Running the complete program repeatedly with varied test data to check it meets requirements and rejects invalid data.
Concepts Checklist
Exam Tips
Watch your wording
The syllabus says analysis is about "precisely" understanding the problem — examiners reward exact
keywords. Don't just say "understand the problem," say "precisely understand the problem the program
is intended to solve."
Don't confuse the two "testing" ideas
Iterative testing happens during coding (module by module). The Testing stage happens after the whole
program is built. If a question asks specifically about one, don't describe the other.
Abstraction ≠ deleting information
Abstraction removes irrelevant detail, but it still keeps everything needed to solve the problem
correctly. Don't describe it as just "simplifying" — mention that it focuses on core functionality
and requirements specifically.
Always mention BOTH goals of testing
When asked what the Testing stage does, examiners want two things: (1) confirming the program works as
intended per the requirements/design, AND (2) confirming it rejects invalid data. Missing either one
usually costs a mark.