Software Design & Development · Independent pathway

Ready for the
next challenge?

Choose a challenge linked to the SDD work you have already completed. A finished solution includes a design, purposeful tests and an evidence-based explanation—not just code that ran once.

DEPTH 01
GeneraliseWork beyond the supplied example.
DEPTH 02
DefendHandle awkward and invalid data.
DEPTH 03
ProveUse tests as convincing evidence.
DEPTH 04
ImproveCompare, refine and evaluate.
How to use the hub
  • Finish the current lesson's core work first.
  • Filter by the latest SDD lesson you have completed.
  • Agree a challenge and starting depth with your teacher.
  • Keep your design, code, tests and evaluation together.
A challenge is complete when
  • the required outputs are present;
  • tests include normal, boundary and exceptional data;
  • results are correct for more than one dataset;
  • the explanation names evidence from the actual solution.

Choose a challenge

Start with the challenge attached to your current learning. The later filters assume all earlier SDD knowledge, so they should not be used to skip untaught content.

Show after
SDD-X01
The impossible client
Turn an ambiguous brief into a defensible analysis.
+
After SDD230–50 minutesAnalysis · written

Client brief: “The school fair needs a quick ticket system. It must prevent queues, work for everyone, store no personal data, remember every booking and be completely secure. It needs to be ready next week.”

Produce

  • Purpose, scope and boundaries
  • IPO analysis
  • Six testable functional requirements
  • Questions and assumptions log
  • Methodology recommendation
Depth 01
Generalise

Separate what is known, assumed and still unknown.

Depth 02
Defend

Identify contradictions and risks in the brief.

Depth 03
Prove

Make every requirement observable and testable.

Depth 04
Improve

Revise the analysis after a client change.

Teacher notes

Change card: “The organiser now needs names for refunds, but booking data must be deleted after 30 days.” Look for explicit boundary changes, a new input/storage requirement and a reasoned discussion of iteration. Do not accept “use agile because it is quick” without context.

SDD-X02
One problem, three designs
Make structure, data flow and interface agree.
+
After SDD445–70 minutesDesign · peer review

Design a program that accepts seven daily temperatures, displays the maximum, counts days below 5°C and identifies the first day matching a temperature entered by the user. Do not write Python yet.

Produce

  • Hierarchical structure diagram
  • Data flow with only necessary parameters
  • Detailed pseudocode refinements
  • Input/output wireframe
  • Requirement-to-design traceability table
Depth 01
Generalise

Make the design work for any number of days.

Depth 02
Defend

Add a sensible response when no match exists.

Depth 03
Prove

Trace one dataset through every refinement.

Depth 04
Improve

Ask a partner to implement from the design alone and record ambiguities.

Teacher notes

The peer implementability test is the key discriminator. Look for one count function with the threshold supplied as data, a linear-search sentinel such as −1, clear array notation and no unexplained data appearing inside a subprogram.

SDD-X03
Refactor without breaking it
Replace parallel arrays with records and preserve behaviour.
+
After SDD640–60 minutesImplementation · evaluation

Begin with three parallel arrays holding book titles, authors and loan status. Refactor the program to use a @dataclass record and an array of records. The original and refactored programs must produce identical results for the same data.

titles = ["Dune", "Noughts & Crosses", "The Hobbit"]
authors = ["Frank Herbert", "Malorie Blackman", "J. R. R. Tolkien"]
on_loan = [True, False, True]

Produce

  • Original working version
  • @dataclass record definition
  • Refactored version
  • Before-and-after test evidence
  • Specific maintainability evaluation
Depth 01
Generalise

Add a fourth field without creating another array.

Depth 02
Defend

Prevent mismatched or incomplete record data.

Depth 03
Prove

Show equivalent outputs for at least three datasets.

Depth 04
Improve

Compare readability and maintainability using named code evidence.

Teacher notes

Require the established course convention: @dataclass, not dictionaries. A strong evaluation identifies the precise indexing dependency removed by the refactor and explains the effect of adding another field.

SDD-X04
Zero-global modular toolkit
Build reusable algorithms with deliberate data flow.
+
After SDD1050–80 minutesFunctions · parameters · scope

Create a toolkit containing functions for linear search, maximum, minimum and count occurrences. Global variables are forbidden. Each subprogram may receive only the data it genuinely needs.

Produce

  • Top-level design
  • Four working functions
  • Purpose and parameter contract for each
  • Independent test calls
  • Explanation of parameter choices
Depth 01
Generalise

Use the same functions with integer and real arrays.

Depth 02
Defend

Define behaviour for an empty array and an absent target.

Depth 03
Prove

Test each function independently before integration.

Depth 04
Improve

Remove any repeated traversal that has no clear purpose.

Teacher notes

Useful conference question: “If I changed this parameter, which lines could behave differently?” Reject unnecessary parameters added merely because the top-level program happens to own the data.

SDD-X05
Dirty data rescue
Turn a damaged file into trustworthy output.
+
After SDD1260–90 minutesFiles · records · testing

A sports-club membership file contains blank lines, duplicate identifiers, invalid numbers and incomplete records. Read the file, preserve every valid record, reject invalid rows safely and write both a clean file and an error report.

Download starter file

Produce

  • Input-file format description
  • Array of member records
  • Clean output file
  • Error report with reasons
  • Comprehensive test table
Depth 01
Generalise

Process any number of input rows.

Depth 02
Defend

Handle missing fields, bad numbers, blanks and duplicates.

Depth 03
Prove

Reconcile input, accepted and rejected row totals.

Depth 04
Improve

Separate reading, validation, processing and writing into modules.

Teacher notes

The starter has 10 non-blank data rows: five valid unique records and five rejected rows if the first occurrence of duplicate ID M104 is retained. Accepted + rejected should equal processed non-blank rows. Pupils may choose another consistent duplicate policy if documented.

SDD-X06
Algorithm laboratory
Measure what an algorithm actually does.
+
After SDD1545–75 minutesAlgorithms · investigation

Modify linear search so it returns both the matching position and the number of comparisons made. Construct datasets that demonstrate the best case, a middle match, the last-position match and an absent value.

Produce

  • Instrumented search function
  • Four deliberate datasets
  • Results table
  • Explanation of the pattern
  • Prediction for 1,000 items
Depth 01
Generalise

Repeat the investigation across different array sizes.

Depth 02
Defend

Include duplicates, empty data and an absent target.

Depth 03
Prove

Explain why each count follows from the loop.

Depth 04
Improve

Research binary search, state its sorted-data precondition and compare results.

Teacher notes

Binary search is explicitly optional enrichment, not a Higher requirement. For a conventional early-exit linear search of n items: first match = 1 comparison; last match or absent target = n comparisons.

SDD-X07
Mutation testing challenge
Design the smallest tests that expose every fault.
+
After SDD1745–70 minutesTesting · debugging

The function below is intended to count scores at or above a supplied threshold. It contains more than one logic defect. Design tests before changing the code, predict the correct results, expose each defect and record every correction in a fault log.

def count_at_least(scores, threshold):
    count = 1
    for position in range(0, len(scores) - 1):
        if scores[position] > threshold:
            count = count + 1
    return count

Produce

  • Test plan with justification
  • Actual faulty results
  • Trace or breakpoint evidence
  • Corrected function
  • Fault log linking tests to fixes
Depth 01
Generalise

Test arrays of several different sizes.

Depth 02
Defend

Include empty, one-item, boundary and no-match data.

Depth 03
Prove

Use the minimum set of tests that still exposes all defects.

Depth 04
Improve

Create three new faulty mutations for a partner to test.

Teacher notes

Three seeded defects: count starts at 1, the loop omits the final item, and > excludes a value equal to the threshold. One strong compact set is: empty array; one value equal to threshold; and two values with only the final one above threshold.

SDD-X08
Evaluation evidence clinic
Replace generic claims with evidence that earns credit.
+
After SDD1825–40 minutesEvaluation · extended response

Improve these statements: “The program is robust because it works.” “It is efficient because it uses functions.” “It is maintainable because the variable names are good.” Each replacement must make a judgement, cite named evidence and explain its effect.

Produce

  • Three diagnosed weak claims
  • Three evidence-based replacements
  • One limitation or counter-example
  • A repeatable evaluation sentence frame
Depth 01
Generalise

Apply the method to fitness for purpose and usability too.

Depth 02
Defend

State what the available evidence cannot prove.

Depth 03
Prove

Link each judgement to code or a recorded test.

Depth 04
Improve

Moderate a partner's response against the rubric below.

Teacher notes

A useful frame is: judgement → named evidence → effect → limitation. The 2025 course report specifically warns against generic evaluation and National 5-level comments that do not refer to Higher concepts.

SDD-X09
The moving-target mini-project
Respond to a controlled client change without losing traceability.
+
After SDD202–4 periodsFull development process

Create a small event-entry system that loads entrant records, searches by identifier, counts entrants in a selected category and writes a results file. After the first working version, obtain a change card from your teacher.

Produce

  • Analysis and functional requirements
  • Structure diagram and refinements
  • Modular implementation
  • Comprehensive test plan
  • Change-impact log and evaluation
Depth 01
Generalise

Support any number of valid records and categories.

Depth 02
Defend

Handle absent files, malformed rows and unknown identifiers.

Depth 03
Prove

Trace every requirement to design, code and test evidence.

Depth 04
Improve

Implement the change and evaluate its impact across all stages.

Teacher notes

Change cards: (1) ties must be reported; (2) rejected rows must be written to a separate file; (3) category is no longer restricted to a fixed list; (4) a single reusable count function must replace separate category functions. Issue only one card per pupil or pair.

SDD-X10
Become the examiner
Write, solve and moderate an original Higher-style task.
+
After SDD2150–80 minutesRetrieval · assessment literacy

Write an original SDD question worth 8–12 marks. It must combine at least three of: analysis, data flow, implementation, testing, debugging or evaluation. Then produce a marking scheme and moderate another pupil's answer.

Produce

  • Unambiguous scenario and question
  • Mark allocation
  • Complete model response
  • Two plausible wrong responses
  • Moderation note after peer trial
Depth 01
Generalise

Use an unfamiliar context rather than a renamed class example.

Depth 02
Defend

Remove ambiguity that would allow conflicting valid answers.

Depth 03
Prove

Show exactly where every mark is earned.

Depth 04
Improve

Revise the task after blind peer moderation.

Teacher notes

Check command words, technical accuracy and whether the marking scheme rewards the wording actually asked. Strong pupils should include accessible marks as well as genuine discriminator marks, rather than writing an impossibly difficult puzzle.

Evidence rubric

Use the rubric for conferencing and feedback. It rewards quality and evidence rather than the quantity of code produced.

DimensionDevelopingSecureExtended
Problem and designSome requirements or design decisions are implicit.Requirements and design are complete and consistent.Assumptions, alternatives and trade-offs are justified.
ImplementationWorks for the supplied example.Works for multiple valid datasets and follows the design.Is modular, generalised and handles defined failures safely.
TestingTests mainly normal data.Includes normal, boundary and exceptional data with predicted results.Every test has a purpose and the set convincingly covers the requirements.
EvaluationMakes generic claims.Uses named evidence and explains its effect.Balances strengths, limitations and a justified improvement.
CommunicationThe final result can be followed with support.Design, code and evidence are clear to another programmer.A peer can reproduce or extend the solution independently.

Independent challenge routes

UK Bebras

Short, non-coding computational-thinking tasks. Use Seniors or Elites when a pupil needs a 15–30 minute independent challenge.

Open UK Bebras ↗

British Informatics Olympiad

Begin with ISBN, Roman Numerals, Time to Words, Mayan Calendar or Passwords before attempting a full paper.

Open the problem archive ↗

Project Euler

Problems 1, 2 and 4 are useful starting points. Submit a design, test evidence and explanation—not only the final number.

Open the problem archive ↗

Isaac Computer Science

Challenge questions combine multiple concepts and provide a structured route into wider GCSE and A-level material.

Open Isaac Computer Science ↗
Teacher notes · pathway management

Use Shift+T to reveal or hide all teacher notes. A simple operating rule is “core complete → one agreed challenge → evidence conference”. Avoid assigning later filters before the associated content has been taught. The page deliberately foregrounds evaluation and explanation because the 2025 Higher Computing Science course report identifies generic evaluation and extended responses as continuing weaknesses.