Your choices and justifications are saved automatically.
Eight scenarios. Select a development approach, justify your choice using the scenario, then check the model answer. Scenarios 5 and 8 are marked DISCUSS — either answer can be correct if well-justified.
A software house has won a fixed-price contract to build a bin-collection scheduling system for a local council. The full requirements were agreed and signed off by both parties before any design work began. Design was completed and approved, then implementation started. Once every feature was coded, the whole system was tested for the first time, and only after that was documentation written and the system handed over.
A small team builds a basic version of a fitness tracker app with just the step-counting feature. They give it to ten test users, who report that the step count is inaccurate when a phone is carried in a bag. The team goes back and redesigns the counting algorithm, implements the change, and tests the app again with the same users before adding the next feature.
A payroll system is being built for a large employer under a strict project plan. Analysis was carried out and formally approved by finance and HR. Design documents were then produced and signed off by both departments in turn. Only once every design document was approved did the developers begin writing code, following the design exactly as specified.
A startup is building a project-management app. Every Friday they release a new build to 50 beta testers. Bug reports and feature requests from that week's build are reviewed on Monday, sometimes leading the team to redesign part of the interface before implementing the fix and testing it again, ready for the following Friday's release.
A developer builds a school library catalogue system to a fixed specification agreed at the start of the project. Analysis, design and implementation are each completed in sequence, exactly as planned. During the single testing phase at the end, a bug is found in the overdue-fines calculation, so the developer returns briefly to implementation to fix it before testing again and handing the system over.
If choosing Iterative: When the bug was found in testing, the developer went back to an earlier phase (implementation) before testing again — this is a feedback loop, which is the defining feature of iterative development, even though it only happens once.
Exam note: A weak answer just states "there was a bug, so it's iterative" or "the plan was fixed, so it's linear" without engaging with the other side. A strong answer recognises that most real projects sit somewhere between the two, and explains which feature of the scenario is the stronger piece of evidence for the chosen answer.
An exam board commissions a results-publishing portal. Requirements are gathered and formally approved in a single document. The design is produced next and approved by a steering group. Implementation then takes several months, followed by one system-wide testing phase, documentation, and a single evaluation meeting at project close where the board confirms it meets the original requirements.
A developer builds a rough prototype of a reading app and shows it to a group of primary teachers. Based on their comments, she redesigns the on-screen keyboard layout, rebuilds that part of the app, and shows the teachers a second prototype. This design-build-review cycle happens four times before a final version is agreed and released to schools.
A company builds a ticketing system for a museum. Analysis, design, implementation, testing and documentation each happen once, in order, and the finished system is handed over. The contract includes twelve months of maintenance, during which any bug reported by museum staff is fixed by returning to implementation, retesting, and updating the documentation before the fix is released.
If choosing Iterative: Every maintenance fix repeats the same cycle — implementation, testing, documentation — driven by feedback from museum staff, which is exactly the feedback loop that defines iterative development, even though it happens after the "finished" system was delivered.
Exam note: The strongest answers separate the two parts of the scenario explicitly — the initial build versus the maintenance period — rather than picking one label and ignoring the other half of the evidence.
Candidates can usually recite the definitions of iterative and linear development, but lose marks when asked to apply them to a scenario. The most common error is naming the approach without naming a phase — "it's iterative because they made changes" scores less than "it's iterative because testing sent the team back to design, which they then redid before implementing and testing again."
The second common error is treating "iterative" as meaning "anything went wrong" and "linear" as meaning "everything went to plan." A linear project can still contain a single bug fix; what matters is whether the process as a whole is built around repeating a cycle of phases, or whether each phase is completed once and signed off before moving on.
For the two Discuss scenarios: there is no single correct answer, but there is a mark-winning approach. State your choice, identify precisely which detail in the scenario supports it, and where the scenario contains evidence for both labels, say so rather than ignoring the half that doesn't fit your answer.