Decomposition

Decomposition is the breaking down of the problem scenario identified in criterion A into smaller, more manageable sub-problems or components. The decomposition can be effectively constructed using diagrams. A reasonable decomposition breaks the problem down into essential components that support the construction of a plan. IBO

Why Decompose a Problem?

Decomposition turns a broad brief into a small set of essential parts you can plan, build, and test. It clarifies scope, reveals dependencies, and makes it easier to map work to success criteria and a timeline. A good decomposition shows how pieces connect, and supports a realistic schedule.

What it produces

  • A short list of components (for example: Inputs & Validation, Core Logic/Algorithms, Visualisation & UI, Data & Saving, Controls, Testing & Evidence).
  • Clear boundaries between components (what data each part needs/outputs).
  • Dependencies and order of work you can move into a Gantt or sprint plan.

Why it helps

  • Prevents scope creep by focusing on essentials.
  • Supports estimating effort per part and scheduling weekly goals.
  • Highlights risks/unknowns early (research tasks can be time-boxed).
  • Makes assessment clearer by tying work directly to success criteria.

Recap

A student is planning to build a projectile simulator.

Decomposition

This plan is organised into sensible stages. Each stage is broken into short, practical sub-tasks that a student team could actually schedule. Links show which published success criteria each stage supports.

1) Research

  • Review classroom examples of single-object flight and note typical inputs and expected shapes of paths.
  • Study simple ways to animate on screen and choose one approach that remains smooth on school laptops.
  • Check how to save and reload a simulation so that a run can be repeated later without re-typing settings.
  • Decide what information should appear on the axes and grid so distances and times are easy to judge.
Links to success criteria:
  • SC-1 - Single object, drag OFF: the arc and landing are identical to classroom examples; time of flight and maximum height are within a small tolerance for a test case.
  • SC-2 - Single object, drag ON: with the same inputs as drag OFF, the arc is visibly lower/shorter and lands closer.
  • SC-10 - Animation is smooth (≈30 FPS or better).
  • SC-11 - Trajectories have labelled axes (metres, seconds) and gridlines.
  • SC-12 - I can save/export the settings to a CSV file.
  • SC-13 - I can load previously saved simulations.

2) Algorithm Design

  • Choose a simple step-by-step update for position and speed, with a switch to include or ignore air resistance.
  • Decide how to recognise the first moment when two circles touch and make sure it happens only once per encounter.
  • Describe what changes immediately after contact so the objects separate cleanly and continue on believable paths.
  • Confirm that when two objects never touch, they simply follow their own paths and land without any collision marker.
Links to success criteria:
  • SC-1 - Single object, drag OFF …
  • SC-2 - Single object, drag ON …
  • SC-3 - Two objects (any angles): until the first touch (centre distance = r₁ + r₂), each object follows its own path.
  • SC-4 - No collision case: if the distance stays > r₁ + r₂ for the simulation, objects fly and land with smooth motion.
  • SC-8 - First contact: detect the first frame where centre distance ≤ r₁ + r₂; show a brief visual cue (e.g. colour pulse).
  • SC-9 - Separation: objects continue with new trajectories and velocities.

3) Implementation

  • Build input panels for each object with units shown and sensible checks for missing or impossible values.
  • Add global settings with a “Reset to defaults” button so common values can be restored quickly.
  • Implement the run/pause/reset loop so repeating the same inputs gives the same animation every time.
  • Code the single-object case first, then add the two-object case, including collision and no-collision behaviour.
  • Implement save, load, and export so settings and runs can be stored and shared.
Links to success criteria:
  • SC-5 - For each object I can set mass, radius, start position, speed, and angle. Units are shown and invalid inputs are rejected.
  • SC-6 - Global settings (gravity, time step, duration) are editable; “Reset to defaults” restores values like g = 9.81 instantly.
  • SC-7 - Run, Pause, and Reset work reliably. Re-running with the same inputs gives the same animation.
  • SC-1, SC-2 - Single-object behaviour with and without air resistance.
  • SC-3, SC-4, SC-8, SC-9 - Two-object motion, first contact cue, clean separation, and correct “no collision” runs.
  • SC-12, SC-13 - Save/export settings and load saved simulations.

4) Visualisation & UI

  • Draw a clear canvas with labelled axes and a light grid so distances and times are readable at a glance.
  • Keep animation smooth and responsive so the motion feels natural and easy to follow.
  • Show short, simple cues at key moments (for example, a brief colour change when objects touch) so users notice important events.
Links to success criteria:
  • SC-10 - Animation is smooth (≈30 FPS or better).
  • SC-11 - Trajectories have labelled axes (metres, seconds) and gridlines.
  • SC-8 - First contact: brief visual cue at the touch point.

5) Testing & Refinement

  • Run a small set of classroom-style cases to check the single-object path with drag off and on.
  • Try several two-object launches at different angles to confirm correct collision and no-collision behaviour.
  • Check that animation remains smooth and that the axes and grid stay readable on typical screens.
  • Confirm that saving, exporting, and loading work as expected across multiple runs.
Links to success criteria:
  • SC-1, SC-2 - Single-object checks against classroom expectations.
  • SC-3, SC-4 - Paths before contact and no-collision behaviour.
  • SC-8, SC-9 - One contact cue and clean separation.
  • SC-10, SC-11 - Smooth animation and readable axes/grid.
  • SC-12, SC-13 - Save/export and load tests.

6) Evaluation & Reporting

  • Collect screenshots and saved files that demonstrate each success criterion and label them clearly.
  • Write a short evaluation that explains which criteria were met, what could be improved, and any limitations noticed during testing.
  • Include a brief mapping from the plan to the success criteria so the evidence is easy to follow.
Links to success criteria:
  • Evidence assembled for all published criteria (SC-1 to SC-13) using saved runs, CSV files, and screenshots.