SDD22 — Unit Review and Test
- I can recall and apply content from every strand of the Software Design & Development unit (SDD1–21)
- I can complete a full unit test sampling analysis, design, implementation, testing, and evaluation together
- I can answer questions correctly across every strand listed in the unit's coverage map below
- I can identify which lessons I am least confident in, based on my own unit test performance
- I can produce a specific, prioritised revision plan ahead of the January prelim
Key vocabulary — one term per strand
Reviewing the whole unit
What this lesson is for
This is the final SDD lesson of the course. It introduces no new content — every fact, function, and concept below has already been taught and Python-verified somewhere in SDD1–21. Its purpose is consolidation: confirming that skills from every strand can still be recalled and applied together, not just immediately after the lesson that first taught them, and identifying specific gaps to close before the January prelim.
The coverage map
The SQA content map (§2 of the delivery plan) lists every mandatory strand: development methodologies, analysis, design, data structures, computational constructs, algorithm specification, testing, debugging, evaluation, and the applied cycle. Task Set A below is built directly from this table as a checklist — one question per strand, confirming nothing from the whole unit has been left untested by the time SDD22 finishes. This mirrors exactly how the checklist should be used when auditing any teaching unit for completeness, rather than trusting from memory that "everything's probably covered".
Why revisiting old lessons matters more than it feels like it should
A skill that felt solid immediately after SDD7's lesson on functions and procedures can genuinely fade by the time SDD22 arrives, five weeks and fourteen lessons later — this is a normal feature of memory, not a sign the original teaching failed. Deliberately testing every strand again now, rather than assuming earlier confidence still holds, is exactly why this review exists as its own lesson instead of simply trusting that SDD1–21's individual task sets were enough on their own. It is also why each question in Task Set A below deliberately links back to the specific lesson it came from, rather than being presented as an anonymous mixed quiz — knowing exactly which lesson a wrong answer traces back to is what turns a single test result into something genuinely useful for revision.
How this connects to what comes next
The prelim (historically the first three weeks of January 2027) and the actual question paper (May 2027) will both draw on this entire unit at once, exactly as SDD21's mixed-topic questions began rehearsing. Task Set B's reflection at the end of this lesson is deliberately designed to turn today's specific results into a concrete, prioritised revision plan for the weeks between now and the prelim — a generic feeling of "I should revise SDD" is far less useful than a specific list of which strands actually need the most attention. The same coverage map used to build today's test can be reused later, unchanged, as a personal revision checklist — ticking off each strand once it has been actively revisited, rather than only once it has been taught for the first time.
Worked examples — one strand recapped in full detail
stockLevels = [30, 45, 20, 15, 60, 18] is a plain 1D array (SDD5); the equivalent array of records (SDD6) is itemRecords, where itemRecords[3].stock accesses the Flapjack record's stock field by name, rather than by matching index across two separate arrays.sum(stockLevels) → 188. This single number can be calculated identically whether the data is stored as a plain array or as an array of records — the choice between the two structures matters for readability and scalability (more fields, more meaning per item), not for whether this particular calculation is possible.isAffordable(90, 80), where 90 and 80 are actual parameters matched positionally to price and budget (formal parameters, SDD8), and the function itself is defined with local scope (SDD9) around those two parameters.isAffordable(90, 80) → False (price exceeds budget). Also recapping SDD10's pre-defined functions: int(68.75) → 68, while round(68.75) → 69 — the two behave differently, and only one (truncation via int()) is the specific Higher-spec function, not National 5's round().findMinimum bug (initialising smallest to 0 instead of array[0]) is the single example this unit has reused most — confirmed to incorrectly return 0 instead of the true minimum 15 against stockLevels.smallest would immediately reveal it never updates away from 0 across the whole loop. The same bug supports two different, equally important strands of the spec.- Assuming an early lesson's skill is still automatic. SDD7's functions/procedures distinction can genuinely fade by SDD22 — this review exists specifically to catch that, not to assume it away.
- Treating the unit test as unrelated topics in sequence. As Example 2/3 show, several strands often connect through the same underlying example (a function call, a bug) rather than being entirely separate.
- Skipping the coverage map's less exciting strands. Analysis and evaluation only carry 0–5 marks each in the question paper, but skipping them entirely in revision still risks losing marks that were straightforward to secure.
- Writing a vague "I should revise everything" plan. Task Set B specifically asks for a prioritised, strand-by-strand plan based on today's actual results, not a generic intention.
- Forgetting the prelim covers this whole unit at once. The prelim and the real exam both draw on SDD1–22 together, exactly like today's mixed test — revision should reflect that breadth, not focus only on the most recently taught lessons.
Use today's Task Set A result as a genuine diagnostic, not just a score — note down which specific strand (not just "the ones I got wrong") produced each incorrect answer, since a single wrong answer in "algorithm specification" points to a different revision action than a wrong answer in "evaluation". This turns one test into a specific, actionable prelim revision plan rather than just a percentage.
Task Set A — Unit test
stockLevels = [30, 45, 20, 15, 60, 18], state the sum of all six values.isAffordable(90, 80) compares a price of 90 against a budget of 80. What does it return?int(68.75).itemRecords array with a low-stock threshold of 20, state the result of countLowStock(itemRecords, 20).calculateAverage(100, 0) raises ZeroDivisionError. What type of error is this?findMinimum bug, would a breakpoint or a watchpoint be more directly useful, and why? (3 marks)calculateTotalCopies(copies) that returns the sum of all values in an array of book copy-counts, reusing the running-total pattern from SDD5/SDD7.Task Set B — Extension
Higher Computing Science → Software Design & Development → SDD22
Double period — final SDD lesson of the course. Every fact reused here (isAffordable, int(68.75), countLowStock, calculateAverage's ZeroDivisionError, findMinimum's bug, readBooks' IndexError) was already Python-verified in its original lesson (SDD8/10/15/16/17/20) — no new facts introduced, consistent with SDD21's approach.
Suggested timing: 5 min warm-up · 10 min notes + coverage map walkthrough (consider projecting the coverage grid and checking it off live against the class's collective confidence per strand) · 20 min Examples 1–3 · 5 min "now you try" · remainder Task Set A as the actual unit test, ideally under timed, individual conditions rather than collaborative — · Task Set B set as homework, directly informing each pupil's personal prelim revision plan.
This lesson completes the entire SDD1-22 sequence. Per CLAUDE.md's coverage-map instruction, every one of the ten SQA strands is represented in Task Set A by design, not by chance — worth reconfirming against §2 of the delivery plan if this lesson is ever revised.
SQA command words covered: identify, state, describe, explain, design, evaluate — the full set introduced across SDD21/22.