Sign inGet started
Skills / Engineering

Spiral Model

The primary distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process.

Barry Boehm's Spiral Model is a risk-driven software process framework that structures each development cycle into four quadrants — objectives setting, risk evaluation and resolution, development and verification, and next-phase planning. Unlike waterfall or agile, it insists that the highest-risk unknowns determine what gets built first. It is designed for software architects, project managers, and senior engineers who need to design and defend a development lifecycle for complex, high-stakes systems.

By Barry Boehm · Free
Specimen 01 · Live diagnosisSpiral Model
Input

“We're building an AI-assisted triage system for a hospital emergency department. The stakeholders are the hospital CIO, the ER medical director, and…”

Diagnosis
Welcome.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Drive software development by risk, not by schedule or fixed phase order

The Spiral Model organizes each development cycle into four quadrants executed in order: (1) Determine objectives, alternatives, and constraints; (2) Evaluate alternatives, identify and resolve risks — often via prototyping; (3) Develop and verify the next-level product; and (4) Plan the next spiral cycle. Each completed pass around the spiral moves outward on a cumulative-cost axis, representing increasing investment and completeness. The model is governed by three anchor point milestones — Life Cycle Objectives (LCO), Life Cycle Architecture (LCA), and Initial Operational Capability (IOC) — that serve as formal commitment gates between major spirals. Boehm later extended the model into the Incremental Commitment Spiral Model (ICSM) and a Win-Win variant that incorporates explicit stakeholder negotiation in each cycle.

The problem

Most software projects fail not because teams can't write code, but because they defer the highest-risk decisions until they are too expensive to undo. Waterfall locks in requirements before risks are understood; agile addresses this with iteration but provides no formal risk-triage mechanism. The Spiral Model was designed specifically to solve the problem of unknown risks driving late-phase failures by mandating that each cycle begins with risk identification and does not proceed to development until critical risks have a mitigation plan.

The solution

Work through each spiral cycle with a structured guide who surfaces your real risks before you commit to development — so you build what survives contact with reality, not what looked safe on a Gantt chart.

You bring
  • A description of the software project, its domain, and known unknowns
  • Your current phase or cycle number in the spiral
  • The team's risk tolerance and available budget or schedule constraints
  • Questions about where your project deviates from a standard spiral structure
You get
  • A four-quadrant activity map for your current spiral cycle
  • A prioritized risk register with prototype or analysis options for each risk
  • A set of anchor point milestone criteria (LCO, LCA, IOC) tailored to your project
  • A reasoned comparison of Spiral vs. Waterfall/Agile given your project context
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your team has spent three weeks on system architecture for a safety-critical healthcare application. The FDA regulatory pathway is still unclear, your ML model accuracy assumptions are unvalidated, and no one has formally committed to the scope — but the Gantt chart says architecture is due Friday.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With Spiral Model

“Before writing a line of architecture, you've exited Cycle 1 with a written FDA classification determination, a feasibility prototype confirming the model can hit clinical accuracy thresholds, and a signed stakeholder win-conditions document. The LCO milestone has been formally passed. Architecture work begins on solid ground with bounded risk.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
Spiral ModelClaude
Spiral Model
Welcome. The Spiral Model's first move is always the same: before we touch architecture or code, we identify what could kill this project. Tell me about your software system — what's the domain, who are the stakeholders, and what are the two or three things you're most uncertain about right now?
We're building an AI-assisted triage system for a hospital emergency department. The stakeholders are the hospital CIO, the ER medical director, and a compliance officer. I'm most uncertain about whether our ML model will be accurate enough for clinical use, whether clinicians will trust and adopt it, and what the FDA regulatory path looks like.
Good — you've named three distinct risk types: a technical risk (model accuracy), a human-factors risk (clinician adoption), and a regulatory/contractual risk (FDA pathway). In Spiral Model terms, these are your Quadrant 2 priorities for Cycle 1, and they need to be resolved — or at least bounded — before you commit to any architecture.
Let's triage them. Which of the three would cause the most expensive rework if you discovered it was a showstopper at the end of development rather than now?
Probably the FDA question — if we're classified as a Class II medical device, the entire development process changes. We might need a completely different validation approach.
Exactly. That's your highest-priority risk for Cycle 1, and the Spiral Model gives you a specific tool: not a prototype, but a risk-resolution activity — in this case, an FDA pre-submission meeting or a regulatory consultant engagement. The goal is to exit Quadrant 2 of Cycle 1 with a written FDA classification determination, not with a guess.
For the model accuracy risk, the appropriate Spiral instrument is a feasibility prototype: a minimal ML pipeline trained on historical triage data, evaluated against clinician gold-standard labels. The question it must answer is specific — 'Can we reach X% sensitivity on Y patient population?' — not 'build the real model.'
Shall I draft the full Quadrant 2 risk register for Cycle 1 with resolution approaches, owners, and timeline estimates for each of your three risks?
Yes, that would be really helpful. Also, when should we hold the LCO review — is that at the end of Cycle 1?
The Life Cycle Objectives milestone sits at the end of your first major spiral, once you've resolved enough risk to commit to the project's objectives, scope, and constraints. For your system, the LCO should not be called until you have: (1) a written FDA classification determination, (2) feasibility prototype results showing model accuracy is achievable, and (3) a stakeholder agreement document — Boehm's Win-Win variant calls this the 'stakeholder win conditions' — signed by the CIO, medical director, and compliance officer.
You are not ready to pass LCO if any of those three are open. That's the gate. Would you like the full LCO entry and exit criteria checklist specific to your project?
This is exactly what we needed. We were about to start architecture work next week but now I see we're not past LCO yet.
Reply to Spiral Model
What the skill is doing
01Four-Quadrant Cycle Design
02Risk Register Construction
03Prototype-to-Resolve Strategy
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
SMSpiral Modeltyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We're building an AI-assisted triage system for a hospital emergency department. The stakeholders are the hospital CIO, the ER medical director, and a…9:14✓✓
The Spiral Model's first move is always the same: before we touch architecture or code, we identify what could kill this project.9:14
Tell me about your software system — what's the domain, who are the stakeholders, and what are the two or three things you're most…9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Four-Quadrant Cycle Design

Maps out the four mandatory quadrants for your current spiral: what objectives and constraints you're committing to, what alternatives exist, what risks must be resolved, and what development activities follow. Produces a concrete activity sequence rather than a generic sprint plan.

Based directly on Boehm's four-quadrant structure from the 1988 IEEE paper — each quadrant has a defined entry criterion, activities, and exit criterion before the team proceeds clockwise to the next.
CapabilityC-02

Risk Register Construction

Elicits and documents the top risks for the current spiral cycle, ranks them by probability and impact, and identifies which can be resolved by prototyping versus analysis versus contractual negotiation.

Reflects Boehm's insistence that risk identification and mitigation — not a fixed phase sequence — determine what activities occur in Quadrant 2 of each spiral cycle.
CapabilityC-03

Prototype-to-Resolve Strategy

Determines which risks warrant a throwaway prototype, an operational prototype, or a simulation, and scopes the prototype to answer the specific risk question rather than gold-plate the solution.

Rooted in Boehm's positioning of prototyping as a first-class risk-reduction technique in Quadrant 2 — explicitly distinguished from waterfall's use of prototypes as deliverables.
CapabilityC-04

Anchor Point Milestone Planning

Defines entry and exit criteria for the three formal commitment milestones — Life Cycle Objectives (LCO), Life Cycle Architecture (LCA), and Initial Operational Capability (IOC) — that gate transitions between major spirals.

The LCO, LCA, and IOC anchor points are Boehm's formalization of commitment gates in the ICSM refinement of the original Spiral Model, preventing premature lock-in of objectives or architecture.
CapabilityC-05

Process Model Comparison and Selection

Analyzes your project's risk profile, team experience, stakeholder certainty, and contractual constraints to reason about whether the Spiral Model is more appropriate than Waterfall, incremental delivery, or agile frameworks.

Boehm explicitly framed the Spiral Model as a meta-model — a framework for selecting and tailoring development processes — making process selection analysis a native capability of the model.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Spiral Cycle Risk Register

A structured table of the top risks for the current cycle, each with a probability-impact rating, risk type (requirements, design, technical, operational), and a designated resolution approach (prototype, analysis, negotiation, or acceptance).

OutputD-02

Four-Quadrant Activity Map

A per-cycle breakdown of activities, responsible parties, inputs, and outputs for each of the four Spiral Model quadrants — from objectives-setting through planning the next spiral.

OutputD-03

Anchor Point Milestone Checklist

Entry and exit criteria for the LCO, LCA, and IOC gates relevant to your project, with a readiness assessment indicating which criteria are currently met and which require further risk resolution before commitment.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Barry Boehm

Barry Boehm is the TRW Professor of Software Engineering at the University of Southern California and one of the most cited researchers in the history of software engineering. He introduced the Spiral Model in his landmark 1988 IEEE Computer paper and later developed the COCOMO software cost estimation model and the Incremental Commitment Spiral Model (ICSM). He is a Fellow of both the IEEE and the ACM.

Status · Inspired by Barry Boehm’s work — not yet claimed. Are you Barry Boehm?
Primary sourceS-01

A Spiral Model of Software Development and Enhancement (IEEE Computer, 1988)

by Barry Boehm

TRW Professor of Software Engineering, USC; creator of COCOMO; IEEE Fellow; ACM Fellow; 1988 IEEE Computer paper with thousands of academic citations.

Read the original ↗
Citationieeexplore.ieee.org
In the build queue

Be first to run it.

Spiral Model is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI'm designing the development process for a high-stakes software system and need to run through the Spiral Model properly. Can we start with a risk triage for Cycle 1 — I'll describe the project and you help me identify what needs to be resolved before we can pass the LCO milestone?