How software actually gets built. Analysis, design, coding, testing — the four stages of the program development life cycle, which Paper 2 regularly tests. This lab covers the life cycle, decomposition, structure diagrams, flowcharts, pseudocode, validation, verification and the four types of test data.
Read this before you tap the activities. These notes give you everything you need to feel confident before hands-on work. When you're ready, tap 🎓 Learn to explore the Design Studio and Lifecycle Stepper.
This is how programmers actually build software. You'll learn the four-stage program development life cycle (analysis → design → coding → testing) and the tasks in each stage, the three design methods (structure diagrams, flowcharts, pseudocode), and how to check data and test a program using validation, verification and the four types of test data (normal, abnormal, extreme, boundary). Paper 2 algorithm questions regularly test these skills.
By the end of this lab you should be able to…
| Term | One-line definition |
|---|---|
| Algorithm | A sequence of steps to solve a problem. |
| Life cycle | Four stages: analysis · design · coding · testing. |
| Abstraction | Removing unnecessary detail so you can focus on what matters for the problem. |
| Decomposition | Breaking a problem into smaller parts: inputs, processes, outputs and storage. |
| Structure diagram | A tree showing a program and its subprograms. |
| Flowchart | A diagram of program flow using standard symbols. |
| Pseudocode | Structured English describing an algorithm. |
| Validation | Automatic check that data is sensible. |
| Verification | Check that data has been entered or copied accurately (it matches the original). Visual check or double entry check. |
| Test data | Normal · Abnormal (should be rejected) · Extreme (largest/smallest accepted) · Boundary (each limit and the value just outside it). |
| Stage | What happens |
|---|---|
| 1. Analysis | Identify the problem and the requirements. Use abstraction (remove unnecessary detail) and decomposition (inputs, processes, outputs, storage). |
| 2. Design | Plan the solution: decomposition, structure diagrams, flowcharts, pseudocode. |
| 3. Coding | Write the program code, with iterative testing (test each part as it is written, fix, retest). |
| 4. Testing | Test the finished program using test data: normal, abnormal, extreme and boundary. |
| Type | Enforces | Example |
|---|---|---|
| Range | Value within limits | Age between 0 and 120 |
| Length | Exact/max characters | Phone = 11 digits |
| Format | Data matches a pattern | Email contains @ |
| Presence | Field is not blank | Required name field |
| Type | Correct data type | Number, not letters |
| Check-digit | Last digit from others | ISBN, barcode |
The flowchart (in text form):
[ Start ] → INPUT Age → < Age ≥ 18 ? > YES → OUTPUT "Adult" NO → OUTPUT "Child" → [ Stop ]
The equivalent Cambridge pseudocode:
INPUT Age
IF Age >= 18
THEN
OUTPUT "Adult"
ELSE
OUTPUT "Child"
ENDIF
Syllabus style: THEN and ELSE on their own lines, indented two spaces; identifiers in PascalCase (Age).
| Type | Values | Expected outcome |
|---|---|---|
| Normal | 25, 33, 12 | Accepted |
| Abnormal | -3, 75, "cat" | Rejected → re-prompt |
| Extreme | 1, 50 | Accepted (the smallest and largest acceptable values) |
| Boundary | 0 and 1 · 50 and 51 | 1 and 50 accepted; 0 and 51 rejected (each limit and the value just outside it) |
Some textbooks call abnormal data "erroneous". The syllabus uses normal, abnormal, extreme and boundary.
Validation = data is sensible (follows the rules). Verification = data was entered or copied accurately (matches the original). They check different things.
An IF can carry out a validation check, but it only checks once. To keep asking until valid data is entered, put the check in a loop (REPEAT … UNTIL or WHILE … DO).
Examiners reject Array, x, temp, data. Use meaningful names like StudentScores, HighestMark.
The syllabus says solutions written in program code score no marks where pseudocode is required (the 15-mark scenario question is the exception). Use ENDIF, ENDWHILE, NEXT — not Python's if:, while:, def.
Mark-winning tips distilled from the 2023–2025 examiner reports:
<- when typing), not = or :=.StudentScore, not x. HighestMark, not temp.Tap each question to reveal the answer. Get most of these right and you're ready for activities.
Name the four life-cycle stages. Know the difference between validation and verification. Recognise the flowchart symbols. Give an example of normal, abnormal, extreme and boundary test data.
Ready? Tap the 🎓 Learn tab and try the Design Studio — the same algorithm shown three ways.
Programs don't get written in one go. A developer follows a life cycle: understand the problem (analysis), plan the solution (design), write the code (coding), then check it works (testing). Analysis uses abstraction (remove unnecessary detail) and decomposition to break big problems into parts — inputs, processes, outputs and storage. Design uses three tools — structure diagrams for the shape of the program, flowcharts for the flow of decisions, and pseudocode for the actual instructions in a language-independent way. Coding includes iterative testing. Testing uses four kinds of data — normal, abnormal, extreme and boundary — and the program checks its input with validation (is the data sensible?) and verification (has the data been entered or copied accurately?). Get these ideas locked in and Paper 2 algorithm questions open up.
Set up an obstacle course with chairs. Write instructions to guide a friend through it — how many steps, which way to turn. Copy them out neatly, then ask a second friend to compare your copy with the original (that's a visual check — a kind of verification). Get the first friend to follow them; if they hit something, your instructions failed testing. Amend and try again. That's the development life cycle in miniature.
Safety-critical software — airline booking, flight control, hospital systems — has to check every input and be tested with normal, abnormal, extreme and boundary data, then traced and retested, before it is allowed near real users. When designers cut analysis or design short to "just start coding", the bugs surface later in testing, where they are much harder and more expensive to fix than if they had been caught in design.
Why do you think the same four stages (analysis, design, coding, testing) appear in every life-cycle model? What might go wrong if a team skips one? Which stage do you think is hardest — and why do students usually spend the least time on it?
Examiner reports regularly flag this. Candidates confuse them, invent hybrid definitions, or answer one when the other was asked. Learn the two definitions.
What: checks whether input data is sensible / matches given rules.
When: during input.
Done by: the computer, automatically.
Types: range, length, format, presence, type, check-digit.
Re-input: to keep asking until valid data is entered, put the check in a loop (an IF on its own only checks once).
What: checks that data has been entered or copied accurately — it matches the original.
When: when data is input.
Types (syllabus): visual check (the user compares the data on screen with the original) and double entry check (the data is entered twice and the computer compares the two).
Not: checking whether the original data is true or sensible — only that it was copied accurately.
Parity, checksum and echo checks are Topic 2 error detection after transmission.
The syllabus asks you to write algorithms for these checks. Two patterns to learn:
A visual check is done by the user: the program outputs the data that was entered and asks the user to confirm it matches the original.
The syllabus lists six standard symbols: the four shapes below, plus the flow line (an arrow showing control passing between shapes) and the subroutine (a rectangle with double side lines — a call to a separate flowchart). Using the wrong shape (a decision inside a rectangle, for example) can cost the symbol mark (2024 s24 examiner report).
Rounded rectangle — the terminator. Begins and ends every flowchart.
Rectangle — a process. Any calculation, assignment, or step that isn't input/output/decision.
Parallelogram — input or output. INPUT reads from the user; OUTPUT displays to the screen.
Diamond — a decision. A Yes/No (True/False) question inside. Two arrows out, labelled.
The same algorithm shown three ways. Click any element in any view — the equivalent parts light up in the other two. This is how experienced programmers actually see code: as three overlapping mental models.
The problem: "Design a program that inputs 20 student scores, calculates the average, and outputs how many were above average." Click each stage below.
This is how pseudocode appears in the exam. The syllabus says the logic matters more than exact syntax, but where a question asks for pseudocode, program code (e.g. Python) scores no marks — except in the 15-mark scenario question. You'll practise the last few boxes in Topic 8.
If the question asks you to validate the input and re-prompt until it is valid, the check must be inside a loop that keeps asking. An IF only checks once — examiners regularly see this.
Cited: 2025 s25 Q12, 2024 s24 Q12, 2025 w25 Q7(c)(ii)Verification checks the data has been entered or copied accurately — that it matches the original. It can't tell whether the original was true or sensible (checking data is sensible is validation). The syllabus checks are the visual check and the double entry check.
Cited: 2025 s25 Q1(a), examiner-report wordingWhere a question asks for pseudocode, solutions written in program code (e.g. Python's if:, while ... :) score no marks (syllabus). Use IF … THEN … ELSE … ENDIF, WHILE … DO … ENDWHILE, FOR … NEXT.
Using Array, X, Data or Temp as variable/array names is flagged as "not meaningful". Names should describe what the variable holds: StudentScores, HighestScore, Counter. (Single letters are fine where conventional, such as i and j for array indexes.)
Decisions go in diamonds, processes in rectangles, input/output in parallelograms, start/stop in rounded terminators, subroutine calls in double-sided rectangles. Putting a decision inside a rectangle, or a process inside a diamond, can cost the shape mark.
Cited: 2024 s24 examiner report — "correct flowchart symbols need to be used"If a question says "using pseudocode", answer in pseudocode. If it says "using a flowchart", draw one. If it says "explain", write prose — pseudocode alone won't do. Match the format to the command word.
Cited: 2025 s25 general comments, 2024 s24 general commentsA description is shown. Pick the correct flowchart symbol.
A value is shown for a whole number in the range 1–100. Is it normal, abnormal, extreme or boundary data? Some values fit two types — both are accepted.
A rule is shown. Pick which validation check enforces it.
A developer action is shown. Which stage of the life cycle is it?
Rapid questions on pseudocode syntax — answer as many as you can in 60 seconds.
Cambridge-style questions modelled on Paper 2 (2023–2025) and the examiner reports — the tag shows the paper each is based on. Type your answer, then mark it.
If the question asks you to keep prompting until the input is valid, wrap the input in a loop. An IF only checks once.
2025 s25 · 2024 s24 · 2025 w25Verification checks data has been entered or copied accurately (visual check, double entry check). Checking data is sensible is validation.
2025 s25 examiner reportCommon in questions where one is asked for and candidates give the other. Read the question word carefully.
2025 s25 Q1, 2025 w25 Q6(c)Writing if x==5: is Python, and program code scores no marks where pseudocode is required. Write IF X = 5 THEN … ENDIF. Get the ENDs right — ENDIF, ENDWHILE, ENDCASE, ENDPROCEDURE, ENDFUNCTION.
"Array", "x", "temp", "data" — none are meaningful. Use names that describe the value: StudentScores, Counter, HighestMark.
Every loop needs its closing keyword. Missing END markers is a common pseudocode error.
Recurring across 2023–2025 examiner reportsA flowchart decision must be a diamond. Putting a Yes/No question inside a rectangle loses the symbol mark.
2024 s24 examiner report — "correct flowchart symbols need to be used"Cambridge uses INTEGER, REAL, STRING, CHAR, BOOLEAN. Writing text or number is not accepted.
When a procedure has a parameter, the CALL must pass a value: CALL Greet("Ali"), not CALL Greet.
Four letters, four life-cycle stages.
Analysis → Design → Coding → Testing. Every life-cycle model contains these four.
Four test-data types.
Normal (accepted) · Abnormal (rejected) · Extreme (largest/smallest accepted) · Boundary (each limit and the value just outside it).
Six validation checks.
Range · Length · Format · Presence · Type · Check digit.
Flowchart symbols mapped to shapes.
Terminator = rounded rectangle · Process = rectangle · Input/Output = parallelogram · Decision = diamond · Subroutine = rectangle with double side lines. Arrows = flow lines.
Validation vs Verification.
Validation = data is sensible (automatic checks; loop to re-prompt). Verification = data entered or copied accurately (visual check, double entry check).
Green = secured (≥70%). Yellow = focus (below 70%). Grey = not attempted. Tap any badge to override.
When you've finished this lab, move on to 7.7–7.10 Algorithms & Debugging: linear search, bubble sort, totalling, counting, max/min/average, trace tables and finding errors.