Show understanding of the need for different development life cycles depending on the program being developed

Program Development Life‑Cycle (12.1)

Learning Objective

Show understanding of why different development life‑cycles are required for different types of programmes.

1. The Five Core Stages (common to every model)

  1. Analysis – identify the problem, gather and agree requirements.

  2. Design – produce a solution blueprint (algorithms, data structures, UI layout, etc.).

  3. Coding – translate the design into executable code.

  4. Testing – verify that the programme meets the requirements and is free of defects.

  5. Maintenance – correct faults, improve performance, or add new features after delivery.

All life‑cycle models are built from these stages; they differ only in the order, repetition and overlap of the stages.

2. Why Use a Development Life‑Cycle?

  • Provides a clear, repeatable structure for planning and organising work.

  • Helps identify and manage risks early (e.g., misunderstood requirements, technical uncertainty).

  • Ensures that every essential activity (analysis‑to‑maintenance) is performed.

  • Facilitates communication between developers, users and managers.

  • Produces software that is easier to maintain, extend and test.

3. Common Life‑Cycle Models (Cambridge recognised)

ModelHow the five stages are performedFlexibilityTypical Use‑caseKey AdvantagesKey Disadvantages
WaterfallEach stage is completed once, in strict order.LowStable, well‑specified systems (e.g., embedded firmware).Clear milestones, easy cost/schedule estimation, thorough documentation.Very inflexible; changes are expensive; problems discovered late.
IterativeFull set of stages repeated in a series of cycles, each delivering a more refined version.MediumProjects where requirements mature over time.Early feedback, risk reduction, accommodates change.Requires good configuration management; cost estimation harder.
Rapid Application Development (RAD)Quick prototype built with high‑level tools, then iteratively refined; testing throughout.Very HighGUI‑intensive business apps with strong user input.Fast time‑to‑market, high user involvement, reusable components.Less suitable for large or safety‑critical systems; quality depends on prototype testing; tool‑dependency.
IncrementalSystem built as a series of functional increments; each increment passes through all five stages once.MediumWeb portals or systems needing phased delivery.Early usable parts, stakeholder sees value quickly, risk spread.Overall architecture must be solid; integration testing becomes more complex.
PrototypingFirst a quick, often incomplete prototype is produced; later cycles refine it into the final system.HighSystems with unclear UI/UX or ambiguous requirements.Clarifies requirements, encourages user participation, reduces risk of building the wrong system.Users may mistake prototype for final product; shortcuts in prototype can be hard to replace.
SpiralIterative cycles each begin with explicit risk analysis before proceeding to the next set of stages.Medium‑HighLarge, high‑risk or safety‑critical projects (e.g., aerospace, medical).Systematic risk handling, flexible iteration, strong decision documentation.Complex to manage, costly for small projects, needs risk‑assessment expertise.
Agile (Scrum, XP, etc.)Short, time‑boxed sprints; each sprint includes analysis, design, coding, testing and a mini‑maintenance review.Very HighFast‑changing markets – mobile apps, SaaS platforms.Welcomes change at any time, frequent delivery, close collaboration, self‑organising teams.Less upfront documentation (problematic for regulated domains); success depends on disciplined teams and active customers.

4. Choosing the Right Model – Decision Factors

FactorGuidance for Model Choice
Clarity of requirementsWell‑defined → Waterfall or Iterative.
Vague / evolving → Prototyping, RAD, Agile.
Project size & complexitySmall → Incremental or Iterative.
Large / high‑risk → Spiral or scaled‑Agile.
Time‑to‑market pressureNeed early release → Incremental, RAD, or Agile.
Stakeholder involvementHigh, continuous involvement → Agile or Prototyping.
Low involvement → Waterfall.
Risk toleranceLow → Spiral (explicit risk analysis).
Medium → Iterative or Incremental.
High → Agile.
Tool & technology constraintsAvailability of rapid‑development tools → RAD.
Strict standards (e.g., aerospace) → Waterfall/Spiral.

5. Illustrative Examples

  1. Payroll System for a Small Company

    • Requirements are stable and well understood.

    • Low risk, limited budget, infrequent updates.

    • Suitable models: Waterfall (straight‑forward) or Iterative if a small amount of refinement is expected.

  2. Social‑Networking Mobile App

    • Features evolve rapidly based on user feedback and market trends.

    • High competition demands frequent releases.

    • Suitable models: Agile (Scrum) for continuous delivery, or Incremental with regular integration.

  3. Air‑Traffic Control System

    • Extremely high safety and reliability requirements.

    • Complex architecture, long development horizon.

    • Suitable model: Spiral (explicit risk analysis) possibly combined with a final Waterfall verification phase.

6. Key Take‑aways

  • The five canonical stages (analysis, design, coding, testing, maintenance) underpin every life‑cycle model.

  • No single model fits all projects; the choice depends on requirement clarity, size, risk, time‑to‑market, stakeholder involvement and tool constraints.

  • Understanding each model’s strengths and weaknesses enables developers to manage cost, schedule and quality effectively.

  • Hybrid approaches (e.g., “Agile‑Waterfall” or “Iterative‑RAD”) are common in industry and can combine the best features of two or more models.

Suggested diagram: Flowchart contrasting the stage‑flow of Waterfall, Iterative, RAD, Incremental, Prototyping, Spiral and Agile models.