You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
A software development methodology is a disciplined way of organising a project from first requirements to long-term maintenance. This lesson develops the five methodologies named by OCR H446 — Waterfall, Agile, Rapid Application Development (RAD), Spiral and Extreme Programming (XP) — and, crucially, how to choose between them for a given project's size, risk and rate of change.
This lesson develops OCR H446 section 1.2.2 (Applications Generation / software development methodologies). It requires you to describe the principal lifecycle models, state the merits and drawbacks of each, and justify which is most appropriate for a described scenario by reasoning about requirement stability, project scale, risk, deadlines and client availability. The methodologies frame the wider development process whose individual activities — design, translation, testing, maintenance — are owned by neighbouring lessons (Object-Oriented Design, Translators, Testing and Debugging). Here we own the process: the order of activities and the philosophy that drives it. The material also underpins the documentation and iteration discipline expected in your NEA programming project.
A methodology defines which activities a project carries out (requirements, design, implementation, testing, deployment, maintenance), in what order, and how often they repeat. Without one, teams drift: requirements are forgotten, testing is skipped under deadline pressure, and nobody can say how "done" the project is.
The two great families are plan-driven (predictive) approaches, which fix the plan up front and follow it (Waterfall, much of Spiral), and change-driven (adaptive) approaches, which expect requirements to evolve and build in short feedback loops (Agile, XP, RAD). Almost every exam judgement reduces to one question: how stable are the requirements, and how much risk is involved? Stable and low-risk leans plan-driven; volatile or exploratory leans adaptive.
The Waterfall model is a linear, sequential approach: each phase is completed and signed off before the next begins, like water cascading down a series of steps and never flowing back up.
flowchart TB
A["Requirements"] --> B["Design"]
B --> C["Implementation"]
C --> D["Testing"]
D --> E["Deployment"]
E --> F["Maintenance"]
| Stage | Description |
|---|---|
| Requirements | Gather and document the complete specification with the client; it is agreed before any design begins |
| Design | Produce system architecture, data structures, algorithms and interface designs from the requirements |
| Implementation | Write the code to the design specification |
| Testing | Test the built system against the requirements; fix defects |
| Deployment | Release the finished system to users |
| Maintenance | Fix later bugs, adapt to changing needs, add improvements |
Because each stage is fully documented and signed off, progress is highly visible and manageable — at any moment you know exactly which stage you are in. But the same rigidity means a requirement discovered to be wrong after sign-off is expensive to fix, and working software does not appear until late, so the client cannot react until much of the budget is spent.
| Advantages | Drawbacks |
|---|---|
| Simple, clearly staged, easy to manage and track | Inflexible — going back to an earlier stage is costly and disruptive |
| Thorough documentation at every stage aids maintenance and handover | Working software appears only late, so problems surface late |
| Excellent when requirements are well understood and stable | Poor fit for changing requirements; an early error can derail everything |
| Defined milestones make cost/time estimation straightforward | High risk concentrated in the requirements and design stages |
Best for: small, well-defined projects with stable requirements — e.g. a payroll system implementing fixed, known regulations.
Agile is an umbrella for change-driven methods that deliver working software in short, repeated cycles called iterations or sprints (typically 1–4 weeks). Requirements (captured as user stories) can be re-prioritised at the start of every iteration, so the product evolves with the client's understanding.
The Agile Manifesto sets out four value statements — each prefers the left over the right without discarding the right:
| Value | Preferred | Over |
|---|---|---|
| People | Individuals and interactions | Processes and tools |
| Output | Working software | Comprehensive documentation |
| Relationship | Customer collaboration | Contract negotiation |
| Change | Responding to change | Following a fixed plan |
The phrase "without discarding the right" matters in the exam: Agile does not mean no documentation, it means valuing working software more highly than documentation.
flowchart LR
BL["Product backlog<br/>(prioritised user stories)"] --> PL["Plan iteration"]
PL --> DV["Develop"]
DV --> TS["Test"]
TS --> RV["Review with client"]
RV --> RT["Retrospective"]
RT --> INC["Working increment"]
INC --> PL
Each iteration: plan (pick the highest-value stories), develop, test, review the increment with the client, then hold a retrospective to improve the process itself. The output of every iteration is a potentially shippable increment.
Two terms are worth separating. An iteration is a time period — the fixed-length cycle of work. An increment is the product of that cycle — the new, working slice of functionality added on top of what already exists. So across a project you have a series of iterations, each producing an increment, and the increments accumulate into the finished product. This "build a usable slice, then build the next slice" rhythm is what lets the client steer: after seeing increment 1 they may decide increment 2 should be something entirely different from the original guess, and Agile simply re-prioritises the backlog to suit.
| Advantages | Drawbacks |
|---|---|
| Embraces changing requirements — re-prioritise each iteration | Final cost and end date are hard to predict at the outset |
| Client sees working software early and often | Demands sustained client availability for reviews |
| Continuous feedback keeps the product aligned to need | Lighter documentation can hamper later maintenance/handover |
| Frequent testing lowers risk by surfacing problems early | Without a fixed scope, scope creep can inflate the project |
Best for: projects where requirements are expected to evolve — e.g. a consumer web app responding to user feedback and a shifting market.
Extreme Programming is a specific, highly disciplined Agile method that pushes good engineering practices to the "extreme". It keeps Agile's short feedback loops but adds concrete technical practices aimed at code quality.
| Practice | What it is |
|---|---|
| Pair programming | Two developers at one machine — a driver writes, a navigator reviews in real time, swapping roles often |
| Test-driven development (TDD) | Write an automated test before the code, then write just enough code to pass it |
| Continuous integration | Integrate changes into the shared codebase many times a day; automated tests run on each integration |
| Refactoring | Continuously improve internal structure without changing behaviour |
| Small, frequent releases | Ship little and often to get rapid feedback |
| Simple design | Build the simplest thing that works; avoid speculative complexity |
| Collective code ownership | Anyone may improve any part of the code |
| On-site customer | A client representative is continuously available to answer questions |
| Advantages | Drawbacks |
|---|---|
| Very high code quality — TDD and pair review catch defects early | Pair programming and an on-site customer are hard with distributed teams |
| Rapid feedback from CI and small releases | Demands high discipline; the practices fail if applied half-heartedly |
| Highly adaptable to change at any point | Pairing and constant review can be intense and tiring |
Best for: small, co-located teams building software where quality and adaptability both matter — and where a client can genuinely be on hand.
TDD is the practice most often misunderstood, so it is worth tracing. The cycle is red → green → refactor: write a failing test first (red), write the minimum code to pass it (green), then improve the structure (refactor) while the test keeps you safe. Suppose we need a function that returns whether a year is a leap year. We start with the test, before any implementation exists:
# Step 1 (RED): write the test first — it fails, because is_leap doesn't exist yet
def test_is_leap():
assert is_leap(2024) == True # divisible by 4
assert is_leap(1900) == False # century, not divisible by 400
assert is_leap(2000) == True # divisible by 400
assert is_leap(2023) == False # ordinary year
# Step 2 (GREEN): write the simplest code that makes the test pass
def is_leap(year):
if year % 400 == 0:
return True
if year % 100 == 0:
return False
return year % 4 == 0
# Step 3 (REFACTOR): tidy the logic into one expression — the test still passes,
# proving behaviour is unchanged
def is_leap(year):
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
The pedagogical point for the exam is that the test is written first, so the specification of "correct" is pinned down before the code, and the refactor step is safe precisely because the test re-runs and confirms behaviour is unchanged. This is how XP achieves high code quality without slowing to a crawl: the safety net is automated.
Critics ask how putting two developers on one task can be efficient. The answer is that the navigator performs continuous code review as the driver types, catching defects at the cheapest possible moment — the instant they are written — rather than days later in testing. Knowledge also spreads across the team (supporting collective code ownership), which reduces the "bus factor" risk of only one person understanding a module. The trade-off is real, though: two salaries are spent on one keyboard, and the intensity can tire developers, which is why XP teams rotate pairs and roles frequently.
The Spiral model is an iterative, risk-driven model that wraps Waterfall-like rigour inside repeating loops, each beginning with explicit risk analysis. The project literally spirals outward: each loop produces a more complete prototype/product while deliberately attacking the biggest remaining risk first.
flowchart LR
Q1["1. Determine objectives,<br/>alternatives, constraints"] --> Q2["2. Identify and<br/>resolve risks (prototype)"]
Q2 --> Q3["3. Develop and<br/>test this increment"]
Q3 --> Q4["4. Review and<br/>plan the next loop"]
Q4 --> Q1
| Quadrant | Action |
|---|---|
| 1. Determine objectives | Set goals, constraints and alternatives for this loop |
| 2. Risk analysis | Identify, evaluate and mitigate risks, often by building a prototype to explore the uncertain part |
| 3. Develop and test | Build and test this loop's increment |
| 4. Plan next iteration | Review progress, then plan the next loop |
| Advantages | Drawbacks |
|---|---|
| Risk is identified and tackled early and explicitly | Expensive — repeated risk analysis and prototyping add cost |
| Adapts across loops as understanding grows | Complex to manage; needs genuine risk-analysis expertise |
| Suits large, complex, high-stakes systems | Disproportionate overhead for small projects |
Best for: large, expensive, high-risk systems — e.g. a new air-traffic-control or banking core, where the cost of an unmitigated risk dwarfs the cost of analysing it.
RAD trades heavy up-front planning for rapid prototyping and tight user feedback. Developers build a quick working prototype, show it to users, and refine it repeatedly until it is right — then harden it for release.
| Phase | Action |
|---|---|
| 1. Requirements planning | Quickly agree high-level requirements (no exhaustive spec) |
| 2. User design | Users and developers co-create prototypes; users try them and feed back |
| 3. Construction | Build the system incrementally, folding in prototype feedback |
| 4. Cutover | Final testing, data conversion and deployment |
Key features that define RAD: heavy prototyping, timeboxing (fixed-length development windows), aggressive reuse of existing components/tools, and continuous user involvement.
| Advantages | Drawbacks |
|---|---|
| Very fast delivery of working software | Needs skilled developers able to prototype and adapt quickly |
| User-centred — prototypes keep it aligned to real needs | Scales poorly to large systems; quality can suffer if rushed |
| Flexible — change is folded in via the next prototype | Poor fit where strict performance/security demands need rigorous testing |
| Heavily dependent on continuous user availability |
Best for: smaller, UI-heavy applications on a tight deadline where users are available and the interface is best discovered by trying it — e.g. an internal data-entry tool.
| Feature | Waterfall | Agile | XP | Spiral | RAD |
|---|---|---|---|---|---|
| Approach | Linear / plan-driven | Iterative / adaptive | Iterative / adaptive | Iterative / risk-driven | Iterative / prototype-driven |
| Flexibility to change | Low | High | High | Medium–High | High |
| Risk management | Low | Medium | Medium | Very high | Low |
| Documentation | Extensive | Light | Light | Moderate | Light |
| Client involvement | Start and end | Continuous | Continuous (on-site) | At each loop | Continuous |
| Typical project size | Small–medium | Any | Small | Large | Small–medium |
| Best when... | Requirements fixed & clear | Requirements evolving | Quality + small co-located team | Large, high-risk | Fast UI delivery, users available |
flowchart TD
Q1{"Requirements stable<br/>and well understood?"}
Q1 -- "Yes" --> Q2{"Large and high-risk?"}
Q1 -- "No" --> Q3{"Quality-critical,<br/>small co-located team?"}
Q2 -- "No" --> W["Waterfall"]
Q2 -- "Yes" --> SP["Spiral"]
Q3 -- "Yes" --> XP["Extreme Programming"]
Q3 -- "No" --> Q4{"Tight deadline,<br/>UI-heavy, users on hand?"}
Q4 -- "Yes" --> R["RAD"]
Q4 -- "No" --> AG["Agile"]
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.