Life cycle: analysis, design, code, test
Four stages. Analysis finds the problem and requirements via abstraction (keep only relevant detail) and decomposition (split into inputs, processes, outputs, storage). Design sets out the solution with the three design tools — structure diagram, flowchart, pseudocode. Coding writes the code with iterative testing. Testing runs the finished code with test data to find and remove errors.
Five standard methods of solution
The only five examined. Linear search: check each element in turn until the target is found or the list ends. Bubble sort: compare adjacent pairs and swap if out of order, repeating passes until none swap. Totalling: Total ← Total + Value. Counting: Count ← Count + 1. Max/min: track the largest/smallest so far. Average: total divided by count. Each needs a loop and variables initialised before the loop.
Validation, verification and test data
Validation is an automatic check that input data is reasonable / within the rules (e.g. a range check) — not that it is correct. Verification checks data was entered or transferred without change (visual or double-entry check). Test data is normal (accepted, in range), abnormal (rejected), extreme (the largest/smallest accepted value) or boundary (a pair: the accepted limit AND the rejected value just past it).
Drawn from real examiner reports.
Validation checks reasonable, not correct
Validation is an automatic check that data is reasonable / obeys the rules — not a human action, and not proof the data is correct. Reasonable data can still be wrong: the right format but the wrong value passes. Pair each check with what it tests, e.g. a range check confirms a number lies between set limits.
June 2023 Paper 2: candidates described validation as a manual action rather than an automatic check by the computer.
Verification checks unchanged, not correct
Verification confirms data has not changed when entered or transferred — by a visual check (read it back against the original) or a double-entry check (typed twice and compared). It does NOT make sure the value is correct. A verified value can still be the wrong value, so the two checks do different jobs.
November 2023 Paper 2: many wrongly said verification "makes sure a value entered is correct"; it checks the value has not changed.
Extreme vs boundary test data
Extreme is the largest or smallest value still accepted. Boundary is a pair at the limit: the accepted limit value AND the rejected value just past it (ages 18-65: 65 accepted, 66 rejected). Giving one value for a boundary, or calling an extreme value boundary, loses the mark.
June 2023 Paper 2 Q3b: candidates confused extreme and boundary test data.
Design tools vs programming concepts
Asked how a design can be presented, the only answers are the three design tools: structure diagram, flowchart and pseudocode. Sequence, selection and iteration are programming concepts; inputs, processes, outputs and storage are the parts of a decomposed problem — neither is a design tool.
June 2023 Paper 2: design tools confused with programming concepts and with problem component parts.
A standard method is not a design tool
A standard method (linear search, bubble sort, totalling, counting, finding max/min/average) names what an algorithm does; a flowchart or pseudocode is only the tool to present it. Asked which method it carries out, name the method (e.g. linear search), not the form it is written in. Calling it 'a flowchart' scores nothing.
June 2023 Paper 2: a linear-search algorithm was wrongly identified as "a flowchart".
Uninitialised totalling/counting variables
Totalling and counting variables must be set before the loop (Total ← 0, Count ← 0); otherwise the total or count is wrong from the start. In a trace, write these initial values first. Related slips: adding the wrong value, or updating in the wrong place. Missing initialisation is the most common trace-table error.
November 2023 Paper 2: trace-table errors from totalling/counting variables not initialised before the loop, and adding the wrong values.
State the test-data type and why
Naming the type is not enough. State the type AND why it is that type, plus whether it is accepted or rejected — e.g. 66 is abnormal for ages 18-65, above the upper limit, so rejected. The reason is where the marks are.
Build the trace table before you start
One column per variable, plus an OUTPUT column. Write initial values first, then work line by line, filling only the column that changes. Follow conditions exactly (> is not >=) and copy each OUTPUT exactly, rounding only when the scenario requires.
Choose a check that suits the context
Pick the check that fits the field: range for a value within limits, length for a character count, type for numbers vs text, presence for a required field, format for a pattern like a date. A check that does not suit the data earns no mark.
Use the published pseudocode style
Use the published Cambridge pseudocode — ← for assignment, INPUT, OUTPUT, IF ... THEN ... ENDIF, FOR ... NEXT, WHILE ... ENDWHILE — and the correct flowchart symbols. Each decision needs a Yes and a No exit.
This Paper 2 topic is about turning a problem into a correct, testable algorithm. You must know the program development life cycle, the three design tools, the standard methods of solution, validation and verification, test data, and how to trace and correct an algorithm.
Mark schemes reward precise, two-element answers. Learn these exactly:
Full notes, flashcards, Q&A and the topic quiz for every premium subject.
Premium plans are US$8.99/month or US$49.99/year — first month free.
Studying with a parent's blessing? Show them this.
