Iterative development process — OCR A-Level Computer Science
Iterative development process explained
Iterative development process covers 2 specification points, including (a) Provide annotated evidence of each stage… and (b) Provide annotated evidence of prototype….
Read the full explanation
Open a point below for its explanation and revision guidance.
(a) Provide annotated evidence of each stage of the iterative development process justifying any decision made.
This statement asks you to present evidence for every stage of your iterative development and justify each decision you made. Provide means including the evidence itself, not only describing it. Cover each stage you went through, typically analysis, design, development, testing and evaluation, across every iteration. Annotated means each item has a note saying what it shows and why it matters. Justifying any decision means giving the reason for it, for example a redesign prompted by a failed test. The aim is a clear, traceable path from one iteration to the next.
(b) Provide annotated evidence of prototype solutions justifying any decision made.
Provide means supplying the evidence itself, so your submission must contain the prototype solutions and the annotations that explain them. Under section 3.3.1 the prototypes come from your iterative development cycle in the programming project, and each one needs annotations recording what it showed. Justifying any decision made means every choice that changes the solution after a prototype must be explained by evidence from that prototype. Examples include replacing a linear search with a binary search, changing an interface layout or dropping a data structure. Place each annotation beside its prototype so the chain from observation to decision is visible.
Your focus
- Provide dated evidence for each stage of one iteration of the development cycle.
- Annotate a piece of evidence to explain what it shows and why it matters.
- Justify a change made during development by citing the test result or feedback that prompted it.
Show all 6 objectives
- Produce annotated prototype solutions for each iteration of a programming project.
- Justify each post-prototype decision by citing specific evidence from the relevant prototype.
- Check that each recorded decision follows from the evidence presented.
Iterative development process exam tips
Marking Points
- Provides evidence for each stage of the iterative cycle, not only the final version of the solution.
- Annotates each piece of evidence to explain what it shows and how it was used.
- Justifies each decision made, including changes prompted by testing or evaluation.
- Shows how each iteration builds on the previous one, linking outcomes to later decisions.
- Includes prototype solutions drawn from the iterative cycle, not the final code alone.
- Annotates each prototype with what was tested, what was observed and the result.
- Links each post-prototype design or implementation change to specific evidence from that prototype.
- Explains why a rejected prototype was rejected, using observed behaviour or measured outcomes.
- Shows the sequence from evidence to decision so a reader can follow the reasoning without the author present.
Examiner Tips
- 💡Organise evidence by iteration and stage, with a short heading for each, so the progression is easy to follow.
- 💡Write each annotation as a reason linked to a requirement or test result, not as a plain description.
- 💡Keep a dated record of each change during development so you can accurately explain the decision behind it.
- 💡Build a dated record for each prototype so each annotation sits beside the version it describes.
- 💡Write each decision entry as trigger, evidence, change, so every decision has a visible reason.
- 💡Before submission, check that every change between prototypes has a matching annotation.
Common Mistakes
- Presents screenshots of the final solution only, with no earlier iterations; include evidence from each stage of the cycle.
- Adds captions that describe what is shown without explaining its significance; annotate to say why the evidence matters.
- Records changes without giving reasons; state the cause, such as a failed test or stakeholder feedback, and the resulting decision.
- Submits working code with no prototype evidence; include the prototypes that led to the final solution.
- Writes annotations that describe the code's features rather than the outcome observed; record what the prototype showed and what changed as a result.
- Justifies decisions with general reasons such as efficiency; cite the specific observation from the prototype that triggered the decision.