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

12.1.5 Choosing an Appropriate Development Model

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

12.1.5 Choosing an Appropriate Development Model

Waterfall, iterative development and Rapid Application Development organise software projects in different ways. None of them is automatically suitable for every project. A sensible choice depends on the characteristics of the proposed system, its users, its development team and the conditions under which it must be delivered.

This section develops a structured way to compare the available evidence and produce a justified recommendation rather than choosing a model from one isolated clue.

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

  • Compare the main characteristics of waterfall, iterative development and RAD.
  • Identify project factors that affect the choice of development model.
  • Link project evidence to the strengths and limitations of a model.
  • Recognise when more than one model could be reasonably justified.
  • Write a balanced recommendation for a project scenario.

There Is No Universal Best Model

A development model is useful only when its way of organising work matches the needs of the project. A feature that benefits one project may disadvantage another.

For example, detailed early planning can provide stability when requirements are fixed. The same planning may create expensive rework when users are still discovering what they need.

Project suitability: the degree to which the characteristics of a development model match the requirements, risks, resources and working conditions of a particular software project.
Model feature Can be beneficial when... Can be limiting when...
Detailed early planning The requirements are stable and well understood. The requirements are likely to change after users see the software.
Repeated development cycles Feedback and early evidence can improve later work. The complete system cannot be divided into useful partial versions.
Rapid prototypes Users can review working models frequently. Users are unavailable or the team lacks suitable technical skill.
Parallel component development The system has clear component boundaries and interfaces. The components depend closely on one another.
Common misconception: A development model should not be selected because it is described as generally “better,” “faster” or “safer.” Its suitability must be connected to evidence from the scenario.

Quick Comparison of the Three Models

The table summarises the broad tendencies of each model. It should be used as a starting point rather than as an automatic decision formula.

Characteristic Waterfall Iterative development RAD
Main organisation Defined stages completed mainly in sequence Repeated cycles that develop or improve working increments Short prototype cycles, often with parallel component development
Initial requirements Expected to be clear and relatively stable An overall purpose is known, but details may develop over time Detailed needs may be discovered through frequent prototype reviews
Working software A complete version generally appears later Useful increments can appear earlier Working prototypes appear quickly
User involvement Important during requirements and acceptance, but may be less frequent Regular review can influence later iterations Frequent user participation is central to the approach
Response to change Late change may require substantial rework Later cycles can respond to evidence and changing priorities Prototype revisions can accommodate rapid requirement changes
Modularity Helpful but not the defining principle Useful features should be deliverable in manageable increments Clear components support parallel development and early integration
Team requirements Benefits from formal planning and documentation Needs effective prioritisation and repeated coordination Needs skilled developers, suitable tools and available users
Exam tip: Avoid copying an entire comparison table into an answer. Select the factors that are directly relevant to the scenario and explain their effect.

Factors That Influence the Decision

A strong model choice considers several pieces of evidence. The most useful factors normally include:

Factor Question to ask Why it affects the choice
Requirements stability Are the required functions already clear and unlikely to change? Stable requirements support dependable early planning.
User availability Can representative users review working software regularly? Iterative development and RAD depend more heavily on repeated feedback.
Need for early software Must users receive useful functionality before the whole system is finished? Iterative development and RAD can produce earlier working results.
Modularity Can the system be divided into useful components or increments? RAD and iterative development are harder when no meaningful partial system exists.
Delivery time Is there a short and important deadline? RAD may reduce delivery time when other RAD conditions are also present.
Technical uncertainty Are important design or technology questions unresolved? Iterations can investigate difficult areas before the whole system depends on them.
Development skill Does the team have the experience needed for rapid decisions and integration? RAD can fail when the team cannot build and revise prototypes reliably.
Documentation and approval Does the project require formal stage approval and detailed records? Waterfall naturally supports defined deliverables and handovers.
Budget and resources Can the project support repeated reviews, testing and user involvement? Repeated cycles and parallel teams may require additional coordination.

Requirements and Feedback

Stable requirements support waterfall

When the organisation can specify the required inputs, processing, outputs and rules accurately before development begins, a sequential model may be effective. The team can complete a detailed design against a dependable specification.

Evolving requirements support repeated review

Some users cannot describe the most suitable system until they interact with working software. Iterative development or RAD allows evidence from early versions to refine later requirements and design decisions.

Project evidence Likely implication
A government reporting format is fixed by published rules. Waterfall may benefit from the stable specification.
Students are unsure how they want to organise a revision dashboard. Iterative review could improve the interface over several increments.
Retail staff can review a checkout prototype every three days. RAD may use rapid prototypes to refine the workflow.
The intended users cannot participate until after delivery. This weakens the case for feedback-dependent models, especially RAD.
Common mistake: “Requirements may change” does not automatically prove that RAD is best. The team must also consider user availability, modularity, time, technical skill and integration.

Early Delivery, Modularity and Integration

Need for early working software

An organisation may gain value from using some functions before the full system is complete. This supports iterative development when useful increments can be released independently.

RAD may also provide early prototypes or components, especially when a short deadline makes rapid review and parallel work valuable.

Ability to divide the system

The team should identify whether each proposed part can provide a meaningful result. A system may have modules internally but still be unsuitable for partial delivery if none of those modules is useful without all the others.

System characteristic Effect on model choice
Accounts, search, booking and reports can each be demonstrated separately. Supports iterative increments or parallel RAD components.
The system has no useful output until every calculation component is complete. Reduces the value of partial releases.
Component inputs and outputs are already standardised. Makes parallel development and integration more manageable.
Every component shares frequently changing global data. Creates a risk for parallel RAD development.
Exam tip: A short deadline alone is not enough to justify RAD. Explain how prototypes, modular components, user reviews or parallel work would actually help meet the deadline.

Technical Risk, Team Skill and Project Control

Technical uncertainty

A project may depend on unfamiliar hardware, an unreliable data source or a difficult algorithm. An iterative approach can investigate the uncertain area early and use the findings to guide later development.

Team expertise

RAD requires developers who can create useful prototypes quickly, make sound design decisions and integrate changing components. A short deadline does not create the required expertise.

Formal control and documentation

Some projects need formal approval before moving between stages. Detailed requirements, design records and test evidence may be required by a contract, organisation or regulator. A waterfall structure may make these approvals easier to organise.

Evidence Model implication
An uncertain data-conversion method could prevent the entire project. An early iterative investigation could reduce the risk.
The team has extensive experience with reusable mobile components. This strengthens a RAD proposal for a modular mobile system.
Each stage requires documented customer approval. This supports the defined handovers of waterfall.
The development team is small and users are available only once. This weakens a plan that depends on frequent prototypes and parallel work.

A Structured Decision Method

The following process helps prevent decisions based on a single memorised phrase.

  1. Identify the project evidence. Find details about requirements, users, deadlines, modularity, risk and resources.
  2. Identify the strongest matching model feature. Decide which model responds most directly to that evidence.
  3. Explain the project benefit. State what the model allows the team to do and why that helps.
  4. Check for conflicting evidence. Look for a factor that weakens the proposed model.
  5. Give a conditional judgement. Recommend the model while stating an important limitation or condition.
Step Example reasoning
Evidence The festival programme changes weekly and organisers can review twice a week.
Model feature RAD uses frequent working prototypes and user feedback.
Benefit The developing application can reflect programme changes before release.
Conflicting evidence The ticket component must integrate with an external payment service.
Judgement RAD is appropriate provided the integration interface is agreed and tested early.
A strong decision is usually conditional: the model is recommended because of specific evidence, provided that an identified risk is controlled.

Worked Examples

Scenario 1: Historic Records Conversion

A university archive needs a program that converts records from a documented fixed-width file into a new standard format. The old and new formats are fully specified, formal approval is required after each stage and users do not need a partial version.

Evidence Interpretation
Both formats are fully specified. The requirements are stable enough for detailed early planning.
Approval is required after each stage. Formal waterfall deliverables support the required control.
A partial converter provides little value. Early incremental delivery is not a major project benefit.
Recommendation: Waterfall is the strongest choice because the conversion rules are stable and the project requires formal stage approval. The team should still test representative and unusual source records early enough to detect incorrect assumptions about the archive data.

Scenario 2: Student Wellbeing Platform

A school wants a platform that helps students find support resources, request an appointment and record personal goals. The broad purpose is understood, but students and counsellors are uncertain about the most usable workflow. Useful features can be introduced separately.

Evidence Interpretation
The preferred workflow is uncertain. Early working versions can reveal usability requirements.
Students and counsellors can review each version. Feedback can guide later cycles.
Resources, appointments and goals can be delivered separately. The system supports useful increments.
Recommendation: Iterative development is suitable because working increments can be reviewed by representative users. The project must protect privacy and maintain a consistent data design as new functions are added.

Scenario 3: Temporary Festival Application

A city festival needs an application in nine weeks. The schedule changes frequently, organisers can attend prototype reviews twice each week and experienced developers can divide the application into listings, maps, bookings and announcements.

Evidence Interpretation
The deadline is short. Rapid prototype cycles and parallel work may reduce delivery time.
Organisers can review frequently. Changing details can be reflected in revised prototypes.
The application has clear components. Listings, maps and announcements can progress in parallel.
The developers are experienced. The team is better able to make rapid decisions and manage integration.
Recommendation: RAD is appropriate because the project combines a tight deadline, available users, skilled developers and modular functionality. Shared data and component interfaces must be agreed early to prevent integration delays.

Writing a Balanced Judgement

Model-selection questions are usually stronger when the recommendation includes a reason, an explanation and a limitation.

Weak response

“RAD should be used because it is fast.”

This answer does not explain which project feature enables RAD or how the speed would be achieved.

Stronger response

“RAD is suitable because the festival application can be divided into listings, maps and announcements, allowing experienced developers to work on several components at the same time. Organisers can review prototypes twice each week, so changing programme details can be incorporated before release. However, the teams must agree shared data formats and test integration early.”

Useful answer structure

  1. Name the proposed model.
  2. Quote or paraphrase one relevant project characteristic.
  3. Link it to a feature of the model.
  4. Explain the resulting project benefit.
  5. Add a relevant drawback, risk or condition.
Common mistake: Do not write three independent descriptions and then choose a model in the final sentence. Compare the models through the evidence in the project.

Interactive: Development Model Decision Lab

Choose a scenario and examine each decision factor. The model-fit indicators are teaching aids rather than an automatic formula: the final judgement still needs a written explanation.

Decision factors

Recommended model: Waterfall

Historic archive conversion

The source and destination formats are fixed, and formal approval is required after each stage.

Factor 1 of 7

Requirements stability

Both data formats are completely specified. This supports detailed early planning and reduces the expected amount of redesign.

Common Mistakes and Misconceptions

  • Choosing from one clue. A short deadline does not automatically mean RAD, and a small project does not automatically mean waterfall.
  • Giving generic advantages. Each point should be connected to the specific project.
  • Treating flexibility as unlimited change. Iterative development and RAD still need priorities and controlled scope.
  • Ignoring user availability. RAD loses a central benefit when representative users cannot review prototypes.
  • Ignoring modularity. Parallel or incremental development is difficult when no useful component can work independently.
  • Giving an absolute conclusion. A strong recommendation often includes a condition or limitation.
  • Claiming that only one answer is possible. Some scenarios support more than one model when the reasoning is sound.

Practice

Core questions

  1. Explain why there is no development model that is best for every project.
  2. Identify four factors that influence model selection.
  3. Explain why stable requirements may support waterfall.
  4. Explain why user availability is important when considering RAD.
  5. Explain why modularity matters for iterative development and RAD.
  6. Explain how technical uncertainty may support an iterative approach.
  7. Explain why a short deadline alone is not enough to justify RAD.

Scenario A: Examination Results Export

A school needs a program that exports examination results to a nationally specified file format. The required fields and validation rules are fixed. Each stage must be approved by the examinations manager.

  1. Recommend a development model.
  2. Give two reasons linked directly to the scenario.
  3. Identify one risk or limitation that should still be considered.

Scenario B: Personal Study Planner

Students want a study-planning application, but they disagree about how tasks, reminders and progress should be displayed. A small group can test a new version every two weeks. Accounts, task lists and progress reports can be delivered separately.

  1. Recommend a development model.
  2. Explain why early working software would help.
  3. Explain one problem the team must control.
  4. Explain whether RAD could also be justified.

Scenario C: Emergency Event Dashboard

An organisation needs a temporary dashboard within six weeks. Experienced developers can divide it into alert feeds, maps, volunteer assignments and reports. Managers can attend prototype reviews three times each week.

  1. Recommend a development model.
  2. Explain three supporting project characteristics.
  3. Identify one integration risk.
  4. Write a balanced final judgement.
Challenge: Choose one scenario and argue for a second plausible model. Explain why it is possible but less convincing than your first choice.

Review

Project evidence Likely model implication
Clear, stable requirements and formal stage approval Supports waterfall
Useful functionality can be delivered and reviewed in stages Supports iterative development
Frequent user reviews, modular components and a short deadline Supports RAD
Major technical uncertainty should be investigated early Supports iterative risk reduction
Users are unavailable during development Weakens RAD and other feedback-dependent approaches
Components cannot operate meaningfully on their own Weakens incremental and parallel development
Final exam tip: Use the chain project evidence → model feature → project consequence → limitation. This produces a reasoned judgement rather than a memorised list.