Sequential phases, each completed and signed off before the next begins. REQUIREMENTS ↓ DESIGN ↓ IMPLEMENTATION ↓ TESTING ↓ DEPLOYMENT ↓ MAINTENANCE ✔ simple to understand and manage; clear milestones ✔ heavy documentation — necessary for certification (aviation, medical, defence) ✔ works well when requirements are genuinely stable and understood ✗ NO WORKING SOFTWARE until late — so no feedback until late ✗ requirements freeze is unrealistic for most projects ✗ a requirements error is found at TESTING, where the cost-of-change curve says it costs 30–70× more ✗ high risk: the first real test of the whole idea comes at the end THE V-MODEL is waterfall with testing planned in parallel: each development phase has a corresponding test phase defined at the same time. requirements ←──────→ acceptance testing design ←──────→ system testing module design ←─────→ integration testing coding ←──────→ unit testing ✔ forces you to ask "how will I test this?" while designing — which catches untestable requirements early ✔ standard in embedded and automotive (ISO 26262) WHEN WATERFALL IS THE RIGHT ANSWER: when the cost of changing direction is higher than the cost of getting it wrong up front. Building a bridge, or software that must be certified against a fixed specification.

INCREMENTAL MODEL deliver the system in slices, each adding function. The first increment is usually a CORE product. increment 1: requirements → design → code → test → DELIVER increment 2: requirements → … → DELIVER increment 3: requirements → … ✔ working software early → feedback early ✔ risk spread across increments ✔ staffing can be lower (no need for everyone at once) ✗ needs a good architecture up front, or later increments fight the early design PROTOTYPING MODEL build a quick prototype to clarify requirements, then throw it away (or evolve it). ✔ excellent when the customer cannot articulate requirements ✔ resolves interface and usability uncertainty cheaply ✗ THE CLASSIC DANGER: the customer sees a working prototype and asks why it cannot ship. A prototype has no error handling, no security, no performance work — shipping it creates years of debt. Agree in writing that it will be discarded. RAD (Rapid Application Development) short cycles (60–90 days) with heavy component reuse and parallel teams working on separate modules. ✔ very fast when the system decomposes cleanly ✗ needs modular systems, committed users and enough people ✗ unsuitable for high technical risk SPIRAL MODEL (Boehm) — the risk-driven model iterative, and each iteration passes through four quadrants: 1. determine objectives, alternatives, constraints 2. IDENTIFY AND RESOLVE RISKS ← the defining step 3. develop and verify 4. plan the next iteration Each loop outward produces a more complete system, and each loop begins by asking "what is the biggest risk right now?" and attacking it — often with a prototype. ✔ RISK IS EXPLICIT: the model's whole purpose ✔ suits large, expensive, uncertain projects ✔ can incorporate any other model inside a loop ✗ requires genuine risk-assessment expertise ✗ heavy for small projects; no clear end condition THE KEY IDEA WORTH TAKING: attack the riskiest unknown FIRST, not the easiest work first. Most failing projects did the easy parts early and discovered the hard part too late.

The AGILE MANIFESTO (2001) — four value statements, each of the form "we value X over Y", NOT "Y is worthless": individuals and interactions OVER processes and tools working software OVER comprehensive documentation customer collaboration OVER contract negotiation responding to change OVER following a plan The clause everyone forgets: "That is, while there is value in the items on the right, we value the items on the left more." Agile does not say documentation is bad. Misreading that is the most common cause of "agile" projects with no design at all. SCRUM — the dominant framework ROLES Product Owner (what), Scrum Master (process), Development Team (how) ARTEFACTS product backlog, sprint backlog, increment EVENTS sprint (1–4 weeks), daily standup, sprint planning, sprint review, retrospective VELOCITY: story points completed per sprint, used for forecasting — NOT for comparing teams, since points are team-relative. EXTREME PROGRAMMING (XP) — the engineering practices pair programming · test-driven development · continuous integration · refactoring · simple design · small releases · on-site customer XP is where the technical practices come from; Scrum is a management framework and specifies no engineering practice at all. That gap is why "we do Scrum" often coexists with poor code quality. KANBAN visualise the workflow, LIMIT WORK IN PROGRESS, measure cycle time. No fixed-length iterations. ✔ suits support and operations work with unpredictable arrival ✔ WIP limits expose bottlenecks instead of hiding them AGILE'S HONEST LIMITS: ✗ hard with fixed-price, fixed-scope contracts ✗ needs a genuinely available customer representative ✗ scaling to hundreds of developers is unsolved (SAFe, LeSS are attempts, all contested) ✗ "responding to change" can become an excuse for no architecture, which the cost-of-change curve punishes ✗ poorly suited where a complete specification must be certified before build

Whatever model you use, these run THROUGHOUT rather than as phases: project tracking and control · risk management · quality assurance · configuration management · technical reviews · measurement · reusability management · documentation THE GENERIC PROCESS FRAMEWORK (Pressman's five activities): COMMUNICATION → PLANNING → MODELING → CONSTRUCTION → DEPLOYMENT Every model above is a different way of ORDERING and REPEATING these five. PROCESS ASSESSMENT — how you know your process is any good: CMMI five maturity levels (covered in ACtE0803) SPICE ISO/IEC 15504 ISO 9001 quality management, not software-specific CHOOSING A MODEL — the honest summary: model requirements risk feedback documents ───────────────────────────────────────────────────────────── waterfall stable high late heavy V-model stable medium late heavy incremental evolving medium early moderate prototyping unclear low very early light spiral uncertain LOWEST each loop moderate RAD stable+modular medium fast light agile/Scrum volatile low continuous light In practice most organisations run a HYBRID: agile delivery inside a phase-gated governance structure, because the business needs commitments and the engineering needs feedback. That hybrid is often criticised, and it is what actually happens.