How software actually gets built. Analysis, design, coding, testing — the four stages every professional programmer follows, and every Cambridge paper tests. This is the design phase of Topic 7: structure diagrams, flowcharts, pseudocode, and the test-data mistakes that cost candidates marks year after year.
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 professional programmers actually build software. You'll learn the four-stage life cycle (analysis → design → coding → testing), the three tools of design (structure diagrams, flowcharts, Cambridge pseudocode), and how to test a program using validation, verification, and three kinds of test data. Every Cambridge Paper 2 algorithm question tests one of these skills.
By the end of Topic 7.1–7.6 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. |
| Decomposition | Breaking a problem into smaller subproblems. |
| 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 not been changed during input or transfer. |
| Test data | Normal (in range) · Boundary (on the edge) · Erroneous (rejected). |
| Stage | What happens |
|---|---|
| 1. Analysis | Understand the problem. Decompose it. Identify inputs, processes, outputs. |
| 2. Design | Plan the solution. Structure diagrams, flowcharts, pseudocode. |
| 3. Coding | Translate pseudocode into a programming language. |
| 4. Testing | Feed test data to check the program works. |
| 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"
→ [ End ]
The equivalent Cambridge pseudocode:
INPUT age
IF age >= 18 THEN
OUTPUT "Adult"
ELSE
OUTPUT "Child"
ENDIF
| Type | Values | Expected outcome |
|---|---|---|
| Normal | 25, 33, 12 | Accepted |
| Boundary | 1, 50 | Accepted (exactly on the limit) |
| Erroneous | 0, 51, -3, "cat" | Rejected → reprompt |
Validation = data is sensible. Verification = data is unchanged. They check different things.
Validation needs a loop (WHILE or REPEAT-UNTIL) that keeps prompting until valid data is entered. An IF only allows one retry.
Examiners reject Array, x, temp, data. Use meaningful names like StudentScores, HighestMark.
Cambridge uses ENDIF, ENDWHILE, NEXT — not Python's if:, while:, def. Match the syllabus exactly.
Mark-winning tips distilled from the 2023–2025 examiner reports:
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 four flowchart symbols. Give an example of normal, boundary and erroneous 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 decomposition to break big problems into small subproblems. 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. Testing uses three kinds of data — normal, boundary and erroneous — and two related but different checks: validation (is the data sensible?) and verification (has the data been entered correctly?). Get these ideas locked in and every Paper 2 algorithm question opens up.
Set up an obstacle course with chairs. Write instructions to guide a friend through it — how many steps, which way to turn. Ask a second friend to check your instructions before you give them to the first (that's 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.
The reason airlines run on decades-old software isn't laziness — it's testing. New code has to be validated, verified, tested with normal / boundary / erroneous data, traced, and retested at every layer before it's allowed near a live booking. When designers cut analysis or design short to "just start coding", the bugs surface in testing, and the cost of fixing them there is 10× the cost of catching them in design. Every pro developer you'll ever meet has learned this the hard way.
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?
Every examiner report on Paper 2 flags this. Candidates confuse them, invent hybrid definitions, or answer one when the other was asked. Learn the two definitions word-for-word.
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.
Requires: a loop that keeps asking until valid data is entered (an IF alone is NOT validation — that only allows one extra try).
What: checks the data hasn't been changed / corrupted during input or transfer.
When: at input (double-entry / visual) or transfer (checksum / parity).
Done by: the user (visual, double-entry) or the computer (checksum, parity).
Types: double-entry check, visual check, checksum, parity, echo.
Not: checking whether data is correct — only whether it's unchanged.
Every Cambridge flowchart uses these four shapes. Using the wrong shape (a decision inside a rectangle, for example) costs the symbol mark — flagged in every 2023–2025 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. Must have a Yes/No question inside. Two arrows out.
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.
The exact syntax you're expected to use. Examiners routinely dock marks for candidates who write "correct-looking pseudocode" that doesn't match the Cambridge syllabus style.
If the question says "validate the input", it must be inside a loop that keeps asking until the entry is valid. An IF only allows one retry — the examiner sees this every year and it costs marks.
Cited: 2025 s25 Q12, 2024 s24 Q12, 2025 w25 Q7(c)(ii)Verification checks whether the data has changed / been corrupted during input or transfer. It does NOT check whether the data is factually correct — that's not something the computer can know. Double-entry, visual check, checksum, parity.
Cited: 2025 s25 Q1(a), examiner-report wordingCandidates who write "Python-y" pseudocode (using if:, while ... :) instead of Cambridge syntax lose marks even when the logic is right. Use IF … THEN … ELSE … ENDIF, WHILE … ENDWHILE, FOR … NEXT — the exact spellings from the syllabus.
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.
Decisions go in diamonds, processes in rectangles, input/output in parallelograms, start/end in rounded terminators. Putting a decision text inside a rectangle, or a process inside a diamond, costs 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 the range 1–100. Sort it into normal, boundary, or erroneous.
A rule is shown. Pick which validation check enforces it.
A developer action is shown. Which stage of the life cycle is it?
10 rapid questions on Cambridge pseudocode syntax. Beat your best.
Every question below is drawn from a real Cambridge Paper 2 (2023–2025) or the examiner report describing that question. Type your answer, then reveal the mark scheme.
If the question asks for validation, wrap the input in a loop that keeps prompting until valid. An IF only allows one retry — that isn't validation.
2025 s25 · 2024 s24 · 2025 w25Verification checks data has not been changed. Correctness is a separate concept the computer can't judge.
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. Cambridge wants 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 one of the top pseudocode syntax errors in every session.
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.
Three test-data types.
Normal (in-range) · Boundary (on the edge) · Erroneous (rejected). Every test set should include all three.
Six validation checks.
Range · Length · Format · Presence · Type · Check-digit.
Four flowchart symbols mapped to shapes.
Terminator = rounded rectangle · Process = rectangle · Input/Output = parallelogram · Decision = diamond.
Validation vs Verification.
Validation = data is sensible (computer, automatic, needs a loop). Verification = data is unchanged (user or computer, at input or transfer).
Green = secured (≥70%). Yellow = focus (30–69%). Grey = not attempted. Tap any badge to override.