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

12.1.2 Development Life Cycle Models

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

12.1.2 Development Life Cycle Models

Software projects can be organised in different ways. The most suitable approach depends on how clearly the requirements are known, how often users can give feedback, how quickly useful software is needed and how easily the project can be divided into smaller parts.

This section compares three development models: waterfall, iterative development and Rapid Application Development (RAD). The aim is to understand the principles, strengths and limitations of each model and then choose an appropriate model for a particular project.

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

  • Describe the main principle of waterfall, iterative development and RAD.
  • Explain benefits and drawbacks of each model.
  • Compare how the models respond to changing requirements and user feedback.
  • Justify a suitable development model for a given project.

Why Use Different Development Models?

The basic development activities may be similar, but projects are not all alike. A system with fixed rules can be organised differently from one whose users are still deciding what they need.

Project factor Question to consider
Requirements Are they clear and stable, or likely to change?
User involvement Can users review working versions during development?
Delivery time Is useful software needed quickly?
Project structure Can the system be divided into useful parts?
Resources Does the team have enough skill and time to manage repeated or parallel work?
Development model: an approach used to organise the activities involved in developing software.

Waterfall Model

Waterfall organises development as a mainly sequential process. The main work of one stage is completed before the project moves to the next, so early decisions guide later work.

Waterfall: a development model in which a project progresses through defined stages in a mainly sequential order.

Analysis → Design → Coding → Testing → Maintenance

Benefits Drawbacks
Clear stages make the project easier to organise. Users may wait a long time before seeing the complete system.
Detailed planning works well when requirements are stable. Late requirement changes may cause substantial rework.
Documentation can support later development and maintenance. It is less convenient when requirements change frequently.
Strong fit: requirements are clear, stable and can be planned reliably before most coding begins.

Example: Laboratory Calibration Report

A laboratory needs a program that imports measurements from a fixed file format and produces a standard calibration report. The file structure, calculations and report layout have already been agreed. Waterfall is suitable because the required behaviour is known in advance and is unlikely to change during development.

Iterative Development

Iterative development creates software through repeated cycles. A useful part of the system is developed, tested and reviewed, and the findings influence later cycles.

Iterative development: a development model in which software is created and improved through repeated cycles of development and review.

Plan → Build → Test → Review → Repeat

Benefits Drawbacks
Useful working versions can appear before the whole system is complete. Repeated planning, testing and review require management.
Problems and misunderstandings can be discovered earlier. Too many changes can make the overall design inconsistent.
Feedback can influence later versions. Some systems cannot be divided into useful partial versions.
Strong fit: useful parts can be developed separately and feedback from early versions can improve later work.

Example: Revision Planner

A school wants an online revision planner. Students know they need tasks, reminders and progress tracking, but they are unsure which interface will be easiest to use. A first version could provide task lists, a later version could add reminders, and feedback from each version could guide the next cycle.

Rapid Application Development (RAD)

RAD aims to produce useful software quickly through short development cycles, working prototypes and frequent user feedback. If a project can be divided into suitable components, several parts may also be developed at the same time.

Prototype: a working model of part of a proposed system that users can evaluate before the complete system is ready.
RAD: a development approach that uses rapid prototype cycles, regular user involvement and, where suitable, parallel component development.
Benefits Drawbacks
Users can evaluate working ideas very early. Users must be available regularly to review the developing system.
Requirements can be refined using feedback. Rapid decisions require an experienced team.
Short cycles can produce visible progress quickly. Parallel components can be difficult to integrate if interfaces are unclear.
Parallel development may reduce delivery time. RAD is difficult when the system cannot be divided into manageable components.
Strong fit: rapid delivery matters, users can give frequent feedback, and the system can be divided into components that can be developed and integrated effectively.

Example: Community Sports-Day App

A community event needs an app quickly. Organisers are still deciding how competitors should choose activities, but they can meet the development team several times each week. Registration, timetables and announcements can be built as separate components. These conditions support RAD, provided the components are integrated carefully.

Comparing the Models

Feature Waterfall Iterative RAD
Main organisation Mainly sequential stages Repeated development cycles Short prototype cycles, sometimes with parallel work
Requirements Preferably clear and stable Can develop as the project progresses Often refined through prototype feedback
Working software Usually appears later Useful versions can appear earlier Prototypes appear quickly
User feedback Usually less frequent during development Used between cycles Frequent and central to the approach
Main concern Late changes may cause rework Repeated cycles and changing priorities must be controlled User availability, team skill and integration

Choosing an Appropriate Model

A model should not be chosen from one keyword. Use several details from the scenario and connect them to the characteristics of the model.

Project evidence Likely implication
Requirements are fixed and formally agreed. Supports waterfall.
Users can review useful working versions regularly. Supports iterative development.
Useful functionality can be introduced in stages. Supports iterative development.
The deadline is short, users are available and the system is modular. Supports RAD.
Users cannot participate during development. Weakens RAD.
The system cannot provide a useful partial version. Weakens iterative and RAD approaches.
Reasoning chain: project evidence → model feature → consequence for the project

Worked Choice

A company wants a staff-training portal. The training content is fixed, but managers are uncertain how employees should move between lessons, quizzes and progress reports. Employees can test a new version every two weeks.

Model Reasoning
Waterfall The fixed content supports planning, but the uncertain navigation could cause late redesign.
Iterative Employees can test working versions, so the interface can improve over several cycles.
RAD RAD could work if very rapid delivery and frequent reviews were required, but the scenario gives stronger evidence for iterative development.
Judgement: iterative development is the strongest choice because representative users can review working versions while the uncertain interface is refined.

Common Mistakes

  • “RAD is always best when the deadline is short.” A short deadline supports RAD only when suitable users, components and skills are also available.
  • “Iterative and RAD are the same.” Both use repeated development, but RAD places stronger emphasis on rapid prototypes, frequent user review and fast delivery.
  • “Waterfall cannot change.” Changes are possible, but late changes may require substantial rework.
  • “One clue proves the answer.” A strong recommendation normally uses several project characteristics.

Practice

Core questions

  1. Describe the main principle of the waterfall model.
  2. Explain one benefit and one drawback of waterfall development.
  3. Describe the main principle of iterative development.
  4. Explain why feedback is useful between iterations.
  5. Explain the purpose of a prototype in RAD.
  6. Explain why RAD may require an experienced development team.
  7. Give one important difference between iterative development and RAD.

Scenario A: Fixed Data Export

A company needs a program that converts payroll data into a fixed format used by another system. The input and output formats are fully documented and are not expected to change.

  1. Recommend a development model.
  2. Give two reasons linked directly to the scenario.

Scenario B: Campus Navigation Tool

Students want a campus-navigation tool, but they disagree about whether routes should be shown as lists, maps or step-by-step directions. A student group can test a new version each month.

  1. Recommend a development model.
  2. Explain how feedback could affect later development.

Scenario C: Weekend Conference App

An organiser needs an app quickly for a conference. The schedule is still changing, organisers can review the system several times per week, and the app can be divided into sessions, maps, registration and announcements.

  1. Recommend a development model.
  2. Explain three project characteristics that support your choice.
  3. Identify one risk the team must manage.

Review

Model Core idea Strong fit Main concern
Waterfall Defined stages completed mainly in sequence Clear and stable requirements Late changes may create rework
Iterative Repeated cycles that improve or extend working software Feedback can improve later versions Repeated cycles and changing priorities must be controlled
RAD Rapid prototypes, frequent feedback and possible parallel development Short deadline, available users and separable components Requires skill, coordination and reliable user involvement
Final exam tip: Do not simply name a model. Explain why the project characteristics make that model suitable, and include a relevant limitation when a balanced judgement is required.