1.3 Spiral, RAD & V-Model

1. The Spiral Model (Boehm, 1988)

Barry Boehm's Spiral model is the first explicitly risk-driven model. The project advances by spiralling outward — each loop adds functionality and the radius represents accumulated cost. Each loop has four quadrants:

       Quadrant 1                  Quadrant 2
   Determine Objectives        Identify & Resolve
   alternatives, constraints       Risks
            │                          │
            └─────────┬────────────────┘
                      │  spiral grows
            ┌─────────┴────────────────┐
            │                          │
   Plan next iteration         Develop & Verify
   Customer evaluation         next-level product
       Quadrant 4                  Quadrant 3

The four quadrants

Each spiral loop is divided into four quadrants that the team works through in order. Quadrant I — Determine objectives, alternatives, and constraints is where the team writes down what this loop must achieve, what design alternatives are on the table, and which constraints (budget, technology, schedule, regulation) bound the choices. The output is a small project plan for this loop. Quadrant II — Identify and resolve risks is the quadrant that distinguishes Spiral from every earlier model: the team enumerates the risks that could derail the project (technical, business, personnel, market) and builds prototypes or simulations specifically to retire those risks before more money is committed. Quadrant III — Engineering is where the actual deliverable for this loop is built — requirements, design, code, and test for the increment the loop is supposed to produce. Quadrant IV — Evaluation and planning of next loop is where the customer reviews the increment, and the team decides whether to spiral again with a larger scope or stop with what has been built.

Characteristics

• Combines features of waterfall and prototyping
• Each loop is a mini-project producing a deliverable
• Risk is the primary driver — high-risk items get resolved first
• Suitable for large, complex, high-risk projects

Advantages

• Risk-driven — most expensive failures avoided early
• Realistic costing — costs accumulate visibly with each loop
• Customer is involved every loop
• Late changes can be absorbed in future loops

Disadvantages

• Process is complex — requires experienced risk managers
• Cost can balloon if too many loops are needed
• Not ideal for small projects (overhead dominates)
• Success depends on accurate risk analysis (a hard skill)

Famous use: Spiral was used in major NASA, DoD, and large enterprise projects in the 1990s. The model's risk-first thinking influenced modern agile risk management (e.g. "spike" stories in Scrum).

---

2. The RAD Model (Rapid Application Development)

RAD (James Martin, 1991) emphasises rapid delivery via component reuse, GUI builders, and parallel development. The system is split into modules that are developed simultaneously by separate teams and integrated at the end.

Phases

1. Business modeling — what data flows, when, who uses it
2. Data modeling — refine data flows into a coherent data model
3. Process modeling — turn data models into the business processes
4. Application generation — code via 4GLs, code generators, reusable components
5. Testing & turnover — integration testing of modules

Characteristics

• Short development cycle (60–90 days target)
• Heavy use of CASE tools and component libraries
• Multiple teams work in parallel on modules
• Strong user involvement

Advantages

• Very fast delivery
• Reuse reduces effort
• High user satisfaction (continuous involvement)
• Productivity gains from tools

Disadvantages

• Needs strong, available users — many real customers cannot commit time
• Requires componentisable systems — large monolithic legacy is unsuitable
• Demands skilled designers
• Not suitable for projects with high technical risk

When to use: Information systems with well-understood data flows (employee management, expense claim systems, simple e-commerce admin panels). RAD does NOT suit embedded, scientific, or real-time systems.

---

3. The V-Model (Verification & Validation)

Requirements ────────────────────→ Acceptance Testing
     │                                    ↑
     ↓                                    │
   System Design ──────────────→ System Testing
     │                                    ↑
     ↓                                    │
   High-Level Design ──────→ Integration Testing
     │                                    ↑
     ↓                                    │
   Module Design ──→ Unit Testing
     │                       ↑
     └───→ CODING ───────────┘

The V-Model is a variant of Waterfall that pairs each development phase with a corresponding testing phase. Going down the left side is development; going up the right is testing. The bottom of the V is coding.

The pairs

Characteristics

• Verification = "are we building it right?" (left side)
• Validation = "are we building the right thing?" (matching levels on the right)
• Test plans are written during the matching development phase, not later

Advantages

• Testing is planned early — defects caught sooner
• Each phase has a tangible verification activity
• Disciplined, easy to manage
• Excellent for safety-critical software (avionics, medical, automotive)

Disadvantages

• As rigid as Waterfall — cannot accommodate change
• No working software until very late
• Heavy documentation overhead

Famous use: V-Model is required by DO-178C (aviation software) and ISO 26262 (automotive). Pacemaker, autopilot, anti-lock-braking-system software all use V-Model derivatives.

---

Comparison of process models (quick exam table)

---

Key Terms — Lesson 1.3

The three models in this lesson — Spiral, RAD, V-Model — share core vocabulary that examiners expect you to deploy precisely.

Spiral Model — Barry Boehm's 1988 risk-driven process model in which development advances by spiralling outward, with each loop comprising four quadrants — objectives, risk analysis, engineering, and evaluation. The radius of the spiral represents accumulated cost; the angular dimension represents progress. Spiral was the first model to make explicit risk management a core activity rather than an afterthought.

Risk-Driven Process — A process where the next activity is selected based on the highest-impact unresolved risk, not by a fixed phase order. If the biggest risk is "will the third-party API actually scale?", the next activity is a load test against that API — not the next phase of waterfall. Spiral institutionalised this idea; modern Agile inherits it via spikes and risk-first sprint planning.

Risk Item — A specific identifiable threat to project success — technical (new technology fails), business (market shifts), personnel (key person leaves), schedule (vendor delays), or external (regulatory change). Each risk has a probability, an impact, and a mitigation strategy. Spiral and modern risk management methodologies catalogue and track risk items explicitly.

Risk-Resolution Prototype — A prototype built specifically to reduce a known risk, not to deliver functionality. For example, a 50-line proof-of-concept that runs the planned database under projected load to retire the "will it scale?" risk before the team commits to the architecture.

RAD (Rapid Application Development) — James Martin's 1991 model that targets rapid delivery (60–90 day cycles) through component reuse, GUI builders and CASE tools, parallel development by multiple teams, and continuous user involvement. RAD's modern descendants include low-code/no-code platforms (OutSystems, Mendix, ServiceNow App Builder) and component-driven frontend development.

4GL (Fourth-Generation Language) — A high-level programming or specification language (PowerBuilder, FoxPro, SQL forms, Visual Basic) designed for rapid application development of data-driven applications, where the developer specifies what rather than how. 4GLs were the productivity lever behind classical RAD.

CASE Tool (Computer-Aided Software Engineering) — Software that automates parts of the software development process — requirements modelling, ER diagram generation, code generation from designs, reverse engineering, test generation. Examples: Rational Rose, Enterprise Architect, ArgoUML. The "CASE" label is dated; modern equivalents are IDEs (IntelliJ, VS Code), model-driven platforms, and code generators (OpenAPI, Prisma).

Componentisation / Reusable Components — Architecting a system as a set of independently developed, reusable building blocks rather than a monolithic codebase. Component reuse is the productivity multiplier behind RAD; modern equivalents include component libraries (React components, Vue components), microservices, and shared SDKs.

V-Model — A variant of Waterfall that pairs each development phase on the left side of a V with a corresponding testing phase on the right side. Going down the left side is development (requirements → design → coding); going up the right side is testing (unit → integration → system → acceptance). The point: test plans are written during the matching development phase, not after coding.

Verification vs Validation — The two complementary V&V activities. Verification answers "are we building the product right?" — does the implementation match the specification? Reviews, inspections, static analysis, and unit tests are verification. Validation answers "are we building the right product?" — does the specification match what the user actually needs? Acceptance testing, user acceptance reviews, and beta programs are validation.

Acceptance Testing — Testing performed (often by the customer) to determine whether the delivered system meets the agreed requirements — usually the SRS or a contract Statement of Work. In V-Model, acceptance testing on the right side pairs with requirements analysis on the left side. Successful acceptance testing is the formal trigger for delivery sign-off.

System Testing — Testing of the complete, integrated system as a whole against its system-level specification — functionality, performance, security, scalability, usability. System testing pairs with system design in the V-Model. Conducted in a production-like environment.

Integration Testing — Testing that focuses on interfaces between modules — that data passed from module A to module B is in the correct format, that error conditions are propagated correctly, that performance does not collapse when modules are wired together. Integration testing pairs with high-level (architectural) design in the V-Model.

Unit Testing — Testing of a single module / class / function in isolation, usually by the developer who wrote it, using a unit-testing framework (JUnit, pytest, NUnit). Unit testing pairs with module / detailed design in the V-Model. Modern test-driven development (TDD) writes unit tests first.

Safety-Critical System — A system whose failure can cause loss of life, serious injury, or major environmental or financial damage — pacemakers, autopilots, anti-lock braking systems, nuclear plant controls, drug-infusion pumps. Safety-critical software is regulated (DO-178C for aviation, ISO 26262 for automotive, IEC 62304 for medical) and almost always developed under V-Model or its derivatives.

DO-178C — The civil-aviation software standard (Software Considerations in Airborne Systems and Equipment Certification) governing software in aircraft. Defines five Design Assurance Levels (DAL) A through E based on the consequence of failure; DAL A (catastrophic — full aircraft loss) requires the most stringent V-Model practice.

ISO 26262 — The international standard for functional safety of road-vehicle electrical/electronic systems. Defines ASIL (Automotive Safety Integrity Level) A through D — the automotive equivalent of DAL. ASIL-D applies to the most safety-critical subsystems (steering, braking, airbag).

Boehm's Two-Question Heuristic — A quick selection rule for process models: How well are requirements understood, and how well is the technology understood? Both well-understood → Waterfall or RAD; both vague → Spiral; requirements clear, technology novel → Prototype or Spiral; safety-critical with stable requirements → V-Model. Useful for the "recommend a model for scenario X" PYQ.

---

Study deep: choosing a model

1. Boehm's two-question test. Boehm proposed a quick heuristic for picking a model:

• Q1: How well are requirements understood? (Well → Waterfall / V; vague → Prototype / Spiral)
• Q2: How well is the technology understood? (Well → Waterfall / RAD; vague → Spiral)
• High-risk on both axes → Spiral; low-risk on both → Waterfall or RAD.

1. Modern context. Pure waterfall, RAD, and spiral are rare in 2025 — most teams use Agile (Scrum/Kanban) for general business software and DevOps pipelines for SaaS. The classical models are still relevant on IPU papers and in regulated industries (aviation, medical, defence).

1. The V-Model's depth varies. Some companies extend the V with sub-levels (component testing between unit and integration). Automotive ASPICE defines a richer V with capability levels.

1. RAD vs Agile. Both emphasise speed and user involvement, but RAD assumes component reuse and CASE tools as the productivity lever, while Agile assumes short iterations and team self-organisation. Agile is more flexible; RAD is more dependent on tooling.

PYQ pattern (frequently appears): "Compare Waterfall, Prototyping and Spiral models. Suggest which model would be most appropriate for: (a) a banking core system, (b) a startup mobile app, (c) a flight-control system." — Banking → Waterfall/V (stable, regulated); Mobile startup → Prototype/Agile (unclear, fast); Flight-control → V-Model (safety-critical).