Planning

The plan should address the requirements of the solution in terms of the success criteria, and include a proposed chronology for the steps involved in planning, designing, developing, testing and evaluating the solution.

A plan can be presented in different forms, but popular diagram formats such as GANTT and AGILE charts can effectively support the planning process.

The plan may include any relevant research, such as the use of existing code libraries. IBO

Why Create a Plan?

  • The Decomposition breaks the project down into manageable tasks. It has a focus on ensuring your success criteria are addressed, but without any reference to sequencing.
  • The Plan turns your Decomposition into an organised schedule.

The Plan shows how the work is decomposed, when each part will be tackled, how much time to assign to each task, and how tasks connect to the published success criteria. This keeps the scope realistic, makes testing and evaluation deliberate, and helps an assessor see clear progress from problem to product.

A strong plan makes your intentions visible. It sets a sensible timeline (research → design → build → test → evaluate). It also identifies checkpoints (what to capture and when) and maps tasks to success criteria (SC-#) so success can be demonstrated, not just described. You may present the schedule as a simple list, a Gantt chart, or an agile sprint view - whichever best communicates the timeline and milestones.

Recap

A student is planning to build a projectile simulator.

The following plan is built on an assumption that, for this (any) IA, there are ~2–2.5 hours per week for 15 weeks (≈35 hours total). Each week lists a clear focus and the success criteria it supports. Note that many schools assign a different number of hours to the IA.

Schedule: ~2–2.5 hours per week for 15 weeks (≈35 hours total). There are some overlaps in tasks that highlight occasional, brief concurrency (i.e. a task may begin before another ends).

Plan

  1. Week 1 - Research: Clarify scope and classroom-style test cases. Prioritise the first success criteria to meet; list required inputs and outputs.
    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.
  2. Week 2 - Research & Prototype: Trial two lightweight animation approaches; select the one that stays smooth on school machines. Note save/load and export needs.
    Links to success criteria:
    • SC-10 - Animation is smooth (≈30 FPS or better).
    • SC-12 - I can save/export the settings to a CSV file.
    • SC-13 - I can load previously saved simulations.
  3. Week 3 - Algorithm Design: Define the single-object update with a toggle for drag on/off. Decide time step and sensible defaults. Draft validation rules.
    Links to success criteria:
    • SC-1 - Single object, drag OFF …
    • SC-2 - Single object, drag ON …
    • 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.
  4. Week 4 - Implementation (Foundations): Build input panels with units and checks. Add a canvas with axes and grid. Create the Run/Pause/Reset loop.
    Links to success criteria:
    • SC-5 - Object inputs with units and validation.
    • SC-6 - Editable globals and “Reset to defaults”.
    • SC-7 - Run, Pause, and Reset work reliably; identical inputs give identical animation.
    • SC-11 - Trajectories have labelled axes and gridlines.
  5. Week 5 - Implementation - Single Object (drag OFF): Animate launch → flight → landing and draw the trajectory. Check time of flight and peak height against expectations.
    Links to success criteria:
    • SC-1 - Single object, drag OFF …
    • SC-10 - Animation is smooth (≈30 FPS or better).
  6. Week 6 - Implementation - Single Object (drag ON): Add a drag toggle and overlay paths for comparison with drag OFF; verify a lower/shorter arc and nearer landing.
    Links to success criteria:
    • SC-2 - Single object, drag ON …
    • SC-11 - Trajectories have labelled axes and gridlines.
  7. Week 7 - Algorithm Design (Two Objects): Specify first-touch detection and “no collision” behaviour. Describe post-contact update and clean separation.
    Links to success criteria:
    • 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.
  8. Week 8 - Implementation - Two Objects (Detection): Implement two launches at any angles; detect first contact once and show a brief visual cue. (Starts mid-Week 7; light overlap.)
    Links to success criteria:
    • SC-3 - Paths remain unaffected until first touch.
    • SC-8 - First contact cue appears at the touch point.
    • SC-10 - Animation is smooth (≈30 FPS or better).
  9. Week 9 - Implementation - Two Objects (Response): After contact, update directions and speeds smoothly; ensure clean separation; confirm “no collision” runs remain unchanged. (Starts mid-Week 8; light overlap.)
    Links to success criteria:
    • SC-4 - No collision case behaves smoothly with no cue.
    • SC-9 - After contact, objects separate and continue with new trajectories and velocities.
  10. Week 10 - Visualisation & Performance: Polish axes, grid, markers, and timing labels; keep animation ≈30 FPS or better.
    Links to success criteria:
    • SC-10 - Smooth animation.
    • SC-11 - Readable axes and gridlines.
  11. Week 11 - Data, Export, and Saving: Implement Export settings (CSV); include Load to reproduce runs. (Starts mid-Week 10; light overlap.)
    Links to success criteria:
    • SC-12 - Save/export the settings to a CSV file.
    • SC-13 - Load previously saved simulations.
  12. Week 12 - Structured Testing: Run classroom-style cases (single and two-object, angled/no-collision). Log results and fix obvious defects. (Starts mid-Week 11; light overlap.)
    Links to success criteria:
    • SC-1–SC-4 - Single-object behaviour (drag off/on) and two-object paths/collision/no-collision.
    • SC-8–SC-11 - Contact cue, separation, animation smoothness, and axes/grid.
    • SC-12–SC-13 - Save/export and load checks.
  13. Week 13 - Usability & Predictability: Improve defaults, error messages, and “Reset to defaults”; verify identical inputs produce identical animations. (Starts mid-Week 12; light overlap.)
    Links to success criteria:
    • SC-5 - Clear object inputs with validation.
    • SC-6 - Editable globals and quick reset.
    • SC-7 - Deterministic Run/Pause/Reset behaviour.
  14. Week 14 - Buffer & Finishing Touches: Address remaining issues from testing, tidy UI text, organise code, and prepare a task→criteria checklist for traceability.
    Links to success criteria:
    • Affected criteria as bugs are resolved; checklist provides traceability across SC-1…SC-13.
  15. Week 15 - Evidence & Reporting (Final): Capture screenshots, saved runs, and CSV files for each success criterion; write the evaluation and reflections; compile the submission bundle.
    Links to success criteria:
    • Evidence assembled for all published criteria (SC-1 to SC-13).

From the list-based plan above, we can produce a more visual version, with the following GANTT chart. Notice that the overlapping (concurrent) tasks are easier to spot.

Plan as a GANTT Chart

Gantt Chart