SDD21 — Past Paper Practice
- I can recognise SQA command words and know what kind of answer each one expects
- I can answer exam-style questions drawing on content from across the whole SDD unit (SDD1–20)
- I can match a command word to the depth and structure of answer it requires
- I can allocate my time and answer length based on a question's stated mark value
- I can answer mixed-topic questions spanning analysis, design, implementation, testing, and evaluation
Key vocabulary — command words
Exam technique across the whole SDD unit
Why exam technique is its own skill
Knowing SDD content and answering SDD exam questions well are related but distinct skills. A pupil who deeply understands parameter passing can still lose marks by writing a two-line answer to a four-mark "explain" question, or by describing a structure diagram in words when a question specifically says "design". This lesson does not teach new SDD content — every fact and function used below has already appeared in SDD1–20 — it teaches how to convert that knowledge into full marks under exam conditions.
Command words set the shape of the answer
SQA questions use command words deliberately and consistently: "identify" or "state" wants a short, specific answer with no justification; "describe" wants an account of what something is or does; "explain" specifically wants reasons — why or how, not just what; "design" wants a plan such as a structure diagram or pseudocode, not Python code; and "evaluate" wants a judgement against named criteria, reaching a conclusion, not simply a description. Misreading the command word is one of the most common and most avoidable ways marks are lost — writing a beautifully detailed description in response to an "explain" question can still score close to zero if it never actually gives a reason.
Mark allocation tells you how much to write
The number of marks a question is worth is a direct signal of how many distinct points are expected — a 1-mark question wants one clear fact; a 3-mark question wants three genuinely separate, creditable points, not one point repeated in different words. Writing far more than the marks justify wastes time that could go toward a later question; writing far less risks missing marks that were clearly available. This is exactly why SDD16's test plans and SDD18's evaluations were built around explicit, separately-listed points rather than a single flowing paragraph — that structure maps directly onto how marking schemes award credit.
Mixed-topic questions test whether skills transfer
Section 1 of the question paper (55 marks, SDD + Computer Systems) draws on the whole SDD spec at once, not one lesson at a time — a single scenario might ask for a structure diagram (SDD3/4), a traced algorithm (SDD13/14/15), a test plan (SDD16), and an evaluation (SDD18) about the very same program. This is exactly the skill SDD19 and SDD20 rehearsed by combining several lessons' content into one program — this lesson extends that same "combine what you know" skill to genuinely mixed exam-style questions across the entire unit, not just one program at a time.
Worked examples — exam-style questions with marking schemes
- 1 mark — identifies calculateAverage and findHighestScore as functions that both take the scores array and return a value
- 1 mark — identifies displayResults as a procedure that takes the average, highest value, and highest index as parameters
- 1 mark — shows the correct data flow: scores → functions → results → displayResults, not code
stockLevels = [30, 45, 20, 15, 60, 18], trace findMaximum(stockLevels) and state the final value returned. Show the value of the running maximum after each comparison.- 1 mark — running maximum starts at 30 (array[0])
- 1 mark — running maximum updates to 45 at index 1, then stays at 45 through indices 2–3 (20 and 15 are both smaller)
- 1 mark — running maximum updates to 60 at index 4, then stays at 60 at index 5 (18 is smaller)
- 1 mark — final value returned: 60
findMaximum(stockLevels) → 60, exactly as established in SDD14.
calculateAverage(100, 0) raises ZeroDivisionError: division by zero. Identify the type of error this is, and explain your reasoning.- 1 mark — identifies this as an execution (runtime) error
- 1 mark — explains that it occurs while the program is running, not before (ruling out a syntax error)
- 1 mark — explains that the program crashes rather than completing and producing a wrong result (ruling out a logic error)
readBooks("") (SDD20) raises IndexError rather than returning an empty array. Evaluate the program's robustness, and explain how this connects to fitness for purpose.- 1 mark — identifies robustness as only partially met, since the program crashes on this input
- 1 mark — explains that robustness specifically concerns handling unexpected/invalid input without crashing
- 1 mark — explains the connection to fitness for purpose: if reading an empty file was ever a stated requirement, this failure would also mean fitness for purpose is not fully met
- 1 mark — notes that if an empty file was never a stated requirement, fitness for purpose could still be judged as met, showing the two criteria are related but not identical
- Answering the topic instead of the command word. A correct fact about the right topic still loses marks if it doesn't match what "identify", "describe", "explain", "design", or "evaluate" specifically asks for.
- Writing code for a "design" question. As in Example 1, a design question wants a structural plan, not Python — even flawless code can score zero on a design-specific question.
- Under- or over-writing relative to the marks available. A 4-mark question needs roughly four distinct points (Example 2); a 1-mark question needs one clear fact, not a paragraph.
- Treating a mixed-topic question as several separate mini-questions to guess at. SDD19/20 showed that a single scenario's stages connect to each other — a mixed question's parts often build on each other rather than testing unrelated facts in isolation.
- Giving a vague evaluation instead of naming a specific SDD18 criterion. As Example 4 shows, "it's not very robust" alone is a weaker answer than one that also connects robustness to fitness for purpose with a specific reason.
Before writing an answer, underline or circle the command word and the mark value in the question. This takes seconds and directly shapes what kind of answer to write and how much time to spend on it — a habit worth building now, in low-stakes practice, rather than for the first time in the actual exam in May 2027.
Task Set A — Mixed past-paper-style questions
applyDiscount(75) function, state the value it returns.ord("A").stockLevels = [30, 45, 20, 15, 60, 18], state the index returned by linearSearch(stockLevels, 15)..split(",") is concatenated directly with another value using +, causing a TypeError. What is the most likely cause?findBookByTitle, issueLoan, and writeBooks sub-programs, showing the data flow between them.findMinimum bug (where smallest incorrectly stays at 0).countAffordable(prices, budget) that returns a count of how many prices in the array are less than or equal to the budget, reusing the count-occurrences standard algorithm generalised to a condition (as in SDD15/SDD20).Task Set B — Extension
Higher Computing Science → Software Design & Development → SDD21
Single period — pure retrieval/exam-technique practice, no new SDD content. Every fact and function reused in this lesson (applyDiscount, ord/chr, linearSearch, findMaximum, calculateAverage's ZeroDivisionError, readBooks' IndexError, breakpoints/watchpoints, the five evaluation criteria) was already Python-verified in its original lesson (SDD9/10/13/14/16/17/18/20) — no new facts were introduced here, only new question framings around existing, confirmed facts.
Suggested timing: 5 min warm-up + command-word vocab · 15 min notes + Examples 1–4 (work through the marking schemes explicitly, ideally letting pupils attempt each question cold before revealing the scheme) · 5 min "now you try" · remainder Task Set A; Task Set B as homework/extension, feeding directly into personal revision planning for SDD22.
Per §4's build-order note, this was built without an audit of a colleague's parallel SDD-equivalent past materials (unlike the CS unit's audit against Chris's materials) — worth doing before the next iteration of this lesson if such materials exist, since genuine past-paper-style questions from a marked source would strengthen this further.
SQA command words explicitly covered: identify, state, describe, explain, design, evaluate, compare.