SLIDE 1
CSZone.co.uk
Click to advance · Arrow keys also work
CAIE 9618 · Paper 2 · Topic 2.5.2

Program Design
Methodologies

Waterfall · Agile · RAD · Prototyping · SDLC Phases

CSZone Cambridge International AS & A Level Computer Science 9618
The Software Development Life Cycle

SDLC — 6 Core Phases

A methodology is a structured process for building software. All methodologies follow these phases in some order.
1. ANALYSIS
Define problem, gather requirements from stakeholders, feasibility study.
2. DESIGN
System architecture, database design, UI design, algorithm design (pseudocode, structure charts).
3. IMPLEMENTATION
Write and compile the actual code. Coding standards applied.
4. TESTING
Unit, integration, system, acceptance testing. Fix identified bugs.
5. DEPLOYMENT
Install and release the product to end users.
6. MAINTENANCE
Bug fixes, updates, performance improvements post-release.
Waterfall Model

Linear Sequential Methodology

HOW IT WORKS
Each phase completed fully before the next begins
Requirements frozen at the start — no changes allowed mid-project
Progress flows downwards: Analysis → Design → Code → Test → Deploy → Maintain
Documentation produced at each stage
ADVANTAGES
Easy to manage and understand
Clear milestones per phase
Extensive documentation
Good for well-understood projects
Easy to estimate time and cost
DISADVANTAGES
Inflexible to changing requirements
Customer sees product only at end
Testing happens late — bugs found late
Unsuitable for complex/unclear projects
Agile Methodology

Iterative & Incremental Development

Agile breaks the project into short cycles called sprints (typically 1–4 weeks). Each sprint delivers a working increment. Requirements can evolve throughout the project.
KEY PRINCIPLES
Customer collaboration over contract negotiation
Responding to change over following a plan
Working software over comprehensive documentation
Individuals and interactions over processes and tools
ADVANTAGES
Fast delivery of working software
Adapts well to changing requirements
Continuous customer feedback
Early detection of problems
Improved team communication
DISADVANTAGES
Hard to predict final cost and timeline
Less documentation produced
Requires constant customer involvement
Scope creep risk (ever-changing requirements)
RAD — Rapid Application Development

Prototyping & User Feedback Loops

RAD uses prototypes — early working models — shown to users for feedback, then refined iteratively until the system meets requirements.
RAD CYCLE
Requirements planning with user
Build initial prototype quickly
User evaluates and gives feedback
Refine prototype based on feedback
Repeat until prototype becomes final product
ADVANTAGES
User involved throughout development
Requirements clarified early via prototypes
Faster delivery than waterfall
Reduced risk of major failures at end
DISADVANTAGES
Requires committed user involvement
Not suitable for very large systems
Prototype code may be poor quality if kept
Hard to plan final timeline
Comparison Table

Waterfall vs Agile vs RAD

FeatureWaterfallAgileRAD
FlexibilityLow — fixed requirementsHigh — requirements evolveMedium — prototype-driven
Customer involvementStart and end onlyContinuous throughoutFrequent feedback sessions
DeliverySingle delivery at endWorking increments each sprintPrototype refined to final
DocumentationExtensiveMinimal — working code preferredModerate
Best forWell-defined, stable projectsChanging or unclear requirementsUI-heavy or user-facing systems
Risk of late failureHigh — testing at endLow — continuous testingLow — user sees early versions
Exam Practice

Cambridge-style questions

Question 1
A software company is developing a mobile banking app for a client. The client's requirements are expected to change frequently as the project progresses. State which development methodology would be most appropriate and explain why. [3]
1
Agile methodology.
2
Because Agile accommodates changing requirements throughout development — requirements are not fixed at the start, meaning the team can adapt as the client's needs evolve.
1
Agile delivers working increments of the software after each sprint, allowing the client to review and provide feedback regularly rather than waiting until the end.
Common Mistakes

Don't lose easy marks

1
Saying Waterfall is "bad" — the exam expects you to match methodology to context. Waterfall is appropriate for stable, well-defined projects (e.g. a payroll system with fixed government rules). Saying it's always wrong will cost marks.
2
Confusing prototype with final product — a prototype is a preliminary working model used to gather feedback. It may be thrown away after use (throwaway prototyping) or evolved into the final system (evolutionary prototyping). Distinguish these clearly.
3
Not linking methodology choice to the scenario — exam questions always describe a specific scenario. You must explain why the methodology suits this scenario (e.g. "changing requirements" → Agile; "fixed government specification" → Waterfall). Naming the methodology alone without justification scores 1/3 at best.
Topic Summary — 2.5.2

What You Need to Know

WATERFALL
Linear sequential
Requirements fixed at start
Good: stable, well-defined projects
Bad: inflexible to change
AGILE
Iterative sprints
Requirements evolve
Good: changing requirements
Bad: hard to plan cost/time
RAD
Prototype → feedback loops
User heavily involved
Good: UI-heavy, unclear requirements
Bad: scope creep, poor prototype quality
CSZone

Next Video

2.5.3
Software Maintenance & Documentation
Corrective · Adaptive · Perfective · Internal & External Docs
Head to CSZone.co.uk for the complete worksheet, quiz, and interactive tools