A-Level Computer Science / Unit 12: Software Design, Testing and Evolution

12.1.3 Building Software Through Iteration

🔒 Lesson slides are available to signed-in users. Sign in

12.1.3 Building Software Through Iteration

Iterative development creates software through a sequence of repeated development cycles. Instead of waiting until the entire system has been completed before users see it, the team builds a useful part, tests it, reviews the result and uses what it learns to plan further work.

Each iteration should move the system closer to its intended final form. Feedback, test results and newly discovered requirements can influence what the team builds next.

By the end of this section, you should be able to:

  • Explain the central principle of iterative software development.
  • Distinguish an iteration from a software increment.
  • Describe how review and feedback influence later cycles.
  • Explain the main benefits and limitations of iterative development.
  • Judge whether an iterative model is appropriate for a project scenario.

The Core Principle of Iterative Development

In an iterative project, the team does not attempt to deliver the entire final system in one uninterrupted sequence. It selects a manageable part of the problem, develops it and then reviews what has been produced.

The knowledge gained during one cycle informs the next. The team may improve existing functionality, add another feature, change a design decision or revise its priorities.

Iterative development: a development approach in which software is produced and improved through repeated cycles of planning, implementation, testing and review.

A simplified iterative path can be represented as:

Choose a goal → plan → build → test → review → choose the next goal

Common misconception: Iterative development does not mean repeatedly writing the same program. Each cycle should use evidence from previous work to improve or extend the system.

Iterations and Increments

The terms iteration and increment are related, but they describe different ideas.

Term Meaning Example
Iteration One repeated development cycle containing planning, building, checking and review. A two-week cycle used to create and evaluate a volunteer-registration feature.
Increment A working addition to the software produced by one or more iterations. A tested registration feature added to the existing application.
An iteration describes the process. An increment describes the working result added to the system.

An iteration does not always produce a large visible feature. It may improve an existing feature, reduce a technical risk or investigate a design problem before further development continues.

Exam tip: When explaining iterative development, mention repeated cycles and review. Merely saying that the program is “built in parts” is incomplete.

What Happens Inside an Iteration?

The exact organisation depends on the project, but a typical iteration contains a small version of several life-cycle activities.

Activity Question for the team Possible evidence
Select the goal What useful outcome should this cycle deliver? Prioritised requirement or iteration goal
Analyse What does this part of the system need to do? Clarified rules and acceptance conditions
Design How will this part fit into the existing system? Updated algorithm, data or interface design
Implement How will the planned behaviour be coded? New or revised source code
Test Does the new work behave as expected? Test results and corrected version
Review What has been learned, and what should happen next? Feedback, revised priorities and next-cycle plan

These activities happen on a smaller scope than the complete project. The team may, for example, analyse and design only the booking feature selected for the current cycle rather than every possible future feature.

Common mistake: Iterative development does not remove analysis, design or testing. It applies these activities repeatedly to smaller areas of work.

Early Working Versions

A major feature of iterative development is that useful software can become available before every planned function has been implemented.

The first version should not simply be unfinished code. It should provide a coherent piece of working functionality that can be demonstrated, tested or used by a limited group.

Early version What it might contain What it may reveal
Version 1 User accounts and a list of available activities Whether users understand the navigation and terminology
Version 2 Booking and cancellation Whether the proposed reservation rules are practical
Version 3 Coordinator reports and notifications Whether the stored data supports the required management information
Early working software allows assumptions to be checked using an actual implementation rather than relying only on descriptions and diagrams.

Using Feedback Between Iterations

At the end of an iteration, users, clients, testers and developers can review the working result. Their feedback may confirm that the feature is suitable or reveal that the original requirement was incomplete.

Feedback should be analysed rather than accepted automatically. The team needs to decide whether a suggestion:

  • corrects a misunderstanding;
  • improves an existing feature;
  • adds a genuinely necessary requirement;
  • has a high or low priority;
  • conflicts with another requirement;
  • would require disproportionate time or resources.
Feedback Possible response Effect on the next iteration
Users cannot locate the cancellation button. Redesign the booking screen. Improve the existing interface before adding more functions.
Coordinators need to limit places by age group. Clarify and prioritise a new rule. Update the data model and booking validation.
A user requests decorative profile animations. Record but assign a low priority. Continue with more important booking functionality.
Exam tip: Do not write only that iterative development “allows feedback.” Explain that feedback can alter requirements, design decisions or the priorities of later cycles.

Using Iterations to Manage Risk

A project does not always need to begin with the easiest feature. The team may choose to investigate a difficult or uncertain feature early so that a major risk is exposed before the rest of the system depends on it.

Project risk: an uncertain event or problem that could affect the cost, schedule, quality or feasibility of the software.

Imagine that a community application must import volunteer information from an older database. The team is uncertain whether the existing data are consistent.

An early iteration could:

  1. load a small sample of old records;
  2. identify missing or inconsistent fields;
  3. test a conversion method;
  4. measure how many records require correction;
  5. use the results to revise the migration plan.

Discovering that the data cannot be imported safely during an early iteration is less damaging than making the discovery shortly before release.

Worked Example: Community Garden Volunteer App

A network of community gardens wants an application that helps volunteers find activities and reserve places. The organisers understand the overall purpose, but they expect their detailed needs to become clearer after volunteers try the system.

Initial priorities

  • Volunteers can create an account.
  • Organisers can publish activities.
  • Volunteers can reserve and cancel a place.
  • Organisers can send weather-related updates.
  • Coordinators can view participation reports.
Iteration Planned working result Review outcome Decision for later work
1 Accounts and an activity list Volunteers want activities grouped by garden location. Add location filtering before developing reservations.
2 Location filters and reservations Organisers need a waiting list when an activity is full. Revise booking data and add waiting-list processing.
3 Waiting lists and weather notices Notification delivery works, but some users receive duplicate messages. Correct the notification logic before developing reports.
4 Corrected notifications and coordinator reports The core functions meet the agreed needs. Prepare the wider release and plan lower-priority improvements.

The first iteration does not attempt to implement every feature. Each working version gives the organisers something concrete to review, while the team preserves a usable system as new functionality is added.

Common mistake: The team should not add unrelated features whenever somebody suggests them. Feedback must be prioritised so the project retains a clear direction.

Benefits of Iterative Development

Working software is available earlier

Users can interact with useful functionality before the entire project is complete. This provides visible progress and creates opportunities for practical evaluation.

Problems can be discovered sooner

Design faults, unclear requirements and technical risks can become visible during an early cycle. Correcting a limited area is often easier than revising a fully developed system.

Feedback can influence development

Users can comment on real software. Their experience may reveal needs that were difficult to express at the beginning of the project.

Progress is easier to observe

Each completed increment provides evidence of what works. The team can review completed functionality instead of estimating progress only from unfinished tasks.

Priorities can change

The next iteration can focus on the most valuable requirement or the most serious unresolved risk.

Iterative feature Potential benefit
Small development cycles Testing and debugging focus on a manageable amount of new work.
Early increments Users can evaluate working functionality sooner.
Repeated review Lessons from one cycle improve later decisions.
Flexible priorities High-value or high-risk work can be addressed earlier.

Limitations of Iterative Development

The overall design can become inconsistent

If the team concentrates only on the current iteration, later additions may not fit the original architecture. Some understanding of the whole system is still necessary.

Repeated cycles require management

Every iteration needs planning, review, testing and coordination. This can require more management effort than a simple linear plan.

Priorities can change too often

Constantly accepting new suggestions can prevent important work from being completed. The project needs a controlled method for selecting requirements.

Dependencies may restrict the order of work

Some features cannot be delivered independently. A reporting module, for example, may depend on data that earlier features do not yet collect.

Existing functionality may be affected

Each increment changes a working system. Previously completed features may need regression testing to check that the new work has not introduced faults.

Limitation Possible consequence Possible response
Incomplete overall planning Later features do not fit the original structure. Maintain an overall architecture and review it regularly.
Frequent priority changes Important functions remain unfinished. Rank requirements and control the scope of each iteration.
Repeated coordination More time is spent planning and reviewing cycles. Use clear iteration goals and completion criteria.
Feature dependencies An increment cannot operate independently. Plan the order of dependent features carefully.
Common misconception: Iterative development does not mean that the whole system needs no initial planning. The team still needs enough architectural understanding to prevent later increments from becoming incompatible.

When Is Iterative Development Suitable?

Iterative development is particularly useful when a system can be divided into useful parts and when early experience is likely to improve later requirements or designs.

More suitable when... Less suitable when...
Useful functionality can be delivered in stages. The system works only when every major component is complete.
User feedback is likely to improve the requirements. The requirements and solution are already fixed and highly predictable.
Some technical risks should be investigated early. Repeated releases or reviews would be impractical.
Priorities may change during development. A strict contract prevents changes to the agreed scope.
The project needs visible progress at regular intervals. There is no meaningful way to produce a usable partial version.
Strong justification pattern: “Iterative development is suitable because [project characteristic]. An early increment would allow [specific review or test], so the team could [project benefit] before completing the whole system.”

Interactive: Iteration Planner

Explore three ways in which an iterative project can progress: following a planned roadmap, changing priorities after feedback or investigating a high-risk feature early.

Iteration sequence

Planned iterative roadmap

Each cycle adds a useful working result

The project progresses through a series of prioritised increments, with review after every release.

Iteration 1 of 4

Create accounts and list activities

The first working increment lets volunteers register and view available work.

Common Mistakes and Misconceptions

  • “Iteration means repeating work because the team failed.” Review and improvement are planned parts of the model.
  • “An increment is the same as an iteration.” The iteration is the cycle; the increment is the working addition.
  • “No requirements are needed at the start.” The team still needs an overall purpose and enough information to select sensible early goals.
  • “Every user suggestion must be implemented immediately.” Feedback must be evaluated and prioritised.
  • “Only new features are tested.” Existing functionality may also need regression testing after an increment.
  • “The easiest feature must always be built first.” A high-risk feature may be investigated early to reduce uncertainty.

Practice

Core questions

  1. Explain the main principle of iterative development.
  2. Distinguish between an iteration and an increment.
  3. Explain how feedback from one iteration can affect the next.
  4. Give two benefits of producing working software early.
  5. Explain why iterative development may expose risk earlier.
  6. Explain one reason why repeated iterations may require additional resources.
  7. Explain why some whole-system planning is still needed.

Scenario: Museum Audio Guide

A museum wants a mobile audio-guide application. The curators know that visitors need exhibit information, but they are uncertain whether visitors will prefer searching, room maps or automatically suggested tours.

  1. Explain two reasons why iterative development could be suitable.
  2. Suggest a useful first increment.
  3. Describe feedback that could be collected after the first iteration.
  4. Explain how that feedback could change the second iteration.
  5. Identify one risk of developing the application iteratively.
Challenge: Write a balanced conclusion explaining why iterative development is appropriate for the museum, while identifying one condition the team must manage carefully.

Review

Prompt A strong response should include
Iterative principle Repeated cycles of planning, building, testing and review.
Iteration One development cycle focused on a selected goal.
Increment A working addition or improvement produced for the system.
Role of feedback It can refine requirements, improve designs or change later priorities.
Main benefits Early working software, visible progress and earlier discovery of problems.
Main limitations Repeated management, possible design inconsistency and changing scope.
Suitable project A system that can grow through useful increments and benefits from early feedback.
Final exam tip: Avoid treating “flexible” as a complete advantage. Explain what can change, what evidence causes the change and how the next iteration responds.