Barry Boehm published the spiral model in software development twice, in 1986 (ACM SIGSOFT Software Engineering Notes) and again in 1988 (IEEE Computer). He aimed it at large projects with unclear requirements.
Baeldung and Codecademy both file it under a mix of waterfall and iterative development. Boehm doesn’t. He calls it a “process model generator”, and the Software Engineering Institute’s 2000 report on spiral development lists six invariants that any authentic application has to show.
What Is the Spiral Model?
Boehm designed it for large projects where requirements, technology or cost could not be pinned down on day one. Every loop repeats the same four activities, and risk analysis decides what gets built next instead of a fixed phase order.
Among the lifecycle models teams pick from, it’s the one that puts risk at the center, not deliverables.
Origin and Publication
Boehm built a conceptual version at TRW in 1978 and first applied it in 1981, leading development of a corporate TRW software development environment.
The first paper appeared in August 1986, in ACM SIGSOFT Software Engineering Notes, Vol. 11, No. 4, pp. 14-24. The better-known one followed in May 1988 in IEEE Computer, Vol. 21, No. 5, pp. 61-72.
Sources don’t agree on the year. Baeldung says 1988 and Codecademy says 1986.
Neither is wrong, since both point to a real paper, and the 1986 one came first. Pearson InformIT’s biography of Boehm dates the formal publication to 1988, and the IEEE Computer version is the one that reached a wider audience.
A Hybrid Model or a Process Model Generator?
Most tutorials call the spiral a mix of waterfall and iterative development. Boehm’s later description doesn’t match that.
The SEI Special Report CMU/SEI-2000-SR-008 calls it a “process model generator”. The project’s risk pattern picks incremental development, evolutionary prototyping, waterfall or some other subset of the steps.
That puts the waterfall approach inside the spiral as a special case, not beside it.
When all six waterfall assumptions hold (requirements known in advance, no unresolved high-risk implications, little change expected, stakeholders aligned, a well-understood architecture, enough calendar time), skipping extra loops is itself the risk-driven choice.
How the Spiral Model Works Loop by Loop
On Boehm’s diagram, distance from the center shows cumulative cost and the angle shows progress. How many loops a project needs depends on its risk.
What Happens in One Loop
- Determine objectives, alternatives and constraints, which means stakeholders state what the loop must deliver and which limits apply.
- Evaluate alternatives and resolve risks by comparing options and removing the biggest risks with a prototype, simulation or benchmark.
- Develop and verify the next-level product. Work moves one level deeper, for example from requirements to design to code.
- Plan the next phase. Stakeholders review the result and commit to continue or stop, then the team plans the next loop.
Many tutorials relabel these quadrants as planning, risk analysis, engineering and evaluation (Codecademy’s SDLC reference does). The order matches.
What gets lost is the wording. Boehm’s version keeps alternatives and stakeholder commitment visible, and the shorter labels hide both.
The third quadrant carries the checking. Software verification shows up in the diagram as requirements validation, design validation and verification, then unit, integration and acceptance tests.
Reading the Spiral Diagram
The radial dimension is cumulative cost, so it grows as the spiral widens. The angular dimension is progress through the steps of the current loop.
Moving outward, Boehm’s original figure runs from concept of operation through software requirements, product design, detailed design, code, unit test, integration and test, acceptance test and implementation, with prototypes along the way (as redrawn in the SEI report).
That drawing is also where the most common misreadings come from, and Boehm lists them himself:
- the spiral is just a sequence of waterfall increments
- everything on the project follows a single spiral sequence
- every element in the diagram must be visited in the order shown
- there can be no backtracking to revisit earlier decisions
He says these may fit a few rare risk patterns and aren’t true for most. The last one is probably the stickiest, because a neat outward curve really does look like a one-way trip.
How Many Loops a Project Runs
There’s no fixed number.
Boehm frames any process model as answering two questions: what to do next, and how long to continue. Under the spiral model, risk answers both, so the answers change between projects and sometimes between one loop and the next (SEI, 2000).
The number of cycles between anchor point milestones is open as well, and the report lists it as a variant. So are mini-cycles inside a single loop, such as separate prototypes for a COTS check or an algorithm, or for the user interface.
How Risk Analysis Decides What Gets Built Next
The biggest open risk sets the work of the next loop. An unproven requirement gets tested first, using whichever of the usual techniques fits, while a loop with no serious risk left goes straight to building.
Boehm ranks risks by risk exposure, which is the probability of an unsatisfactory outcome multiplied by the loss if it happens (Boehm, IEEE Software, 1991). Written out, that’s RE = P(UO) × L(UO).
A simple risk assessment matrix, with probability on one axis and loss on the other, shows which items to resolve first.
Each loop picks the technique best suited to the risk in front of it. The SEI report lists these:
- Prototyping
- Simulation
- Modeling
- Benchmarking
- Reference checking
Building a quick software prototype is a common choice, because users often can’t describe a screen until they see one. Boehm calls this the IKIWISI syndrome, short for “I’ll know it when I see it.”
The same logic sets how much of any activity is enough. Plot the exposure from shipping defects against the exposure from losing market share, and the total reaches a minimum at some level of testing.
So test until total risk exposure stops falling, then ship. For a dot-com product that point comes much sooner than it does for a nuclear power plant.
An early-1980s TRW contract shows what a first loop can save. The customer and TRW had fixed a one-second response time into a waterfall contract.
Two thousand pages of requirements later, the only design that met it used more than 25 super-minicomputers and cost an estimated $100 million (the report says nearly that figure). A prototype of the user interface then showed that a four-second response satisfied users 90 percent of the time, and a client-server design cut the estimate to $30 million (Boehm’s account in the SEI report, 2000).
That project ran as waterfall. The prototype is the risk-resolution step the spiral places at the start.
What Separates a True Spiral From a Look-Alike
Every authentic spiral cycle displays all six of Boehm’s invariants. Drop any one and you have a hazardous look-alike, a process that loops but carries the failure risks the spiral was built to avoid (SEI, 2000).
| Invariant | What it requires | Look-alike it excludes |
|---|---|---|
| 1. Concurrent artifacts | Operational concept, requirements, plans, design and key code defined together | Incremental waterfall passes where waterfall assumptions fail |
| 2. Four activities per cycle | Stakeholder objectives, alternatives, risk resolution, review, commitment | Sequential phases that exclude key stakeholders |
| 3. Risk sets level of effort | Effort per activity follows risk exposure | Risk-insensitive evolutionary or incremental development; spiral plans with no risk follow-through |
| 4. Risk sets degree of detail | Specify precisely only where vagueness is risky | Full specifications for GUI, COTS or deferred decisions |
| 5. Anchor point milestones | LCO, LCA and IOC as stakeholder commitment points | Evolutionary development with no life cycle architecture |
| 6. System and life cycle focus | Hardware, software, operations and evolution, not only code | Purely logical object-oriented methods that ignore performance and cost risk |
The first invariant is the easiest to break. A team that finishes its requirements engineering before any risk is resolved is running a waterfall pass with a spiral label on it.
Anchor Point Milestones
The 1988 diagram had no milestones, so cycles lacked commitment points and progress checks (SEI, 2000). Boehm added them later, as questions stakeholders have to answer:
- Life Cycle Objectives (LCO) asks whether at least one architecture choice is viable from a business perspective, with stakeholders committed to support architecting.
- Life Cycle Architecture (LCA) asks whether the preferred approach is defined and all significant risks are eliminated or mitigated.
- Initial Operational Capability (IOC) comes down to whether the software, site, users, operators and maintainers are ready to launch.
Rational adopted all three as phase gates in the Rational Unified Process. LCO falls between Inception and Elaboration, LCA between Elaboration and Construction, and IOC between Construction and Transition.
Xerox’s Time-to-Market process uses the same milestones as hardware-software synchronization points for its printer business line (SEI, 2000).
WinWin Spiral Model
The original diagram never said how to find the objectives and constraints for step one.
The WinWin spiral model fixes that by putting some negotiation in front of each loop. The team identifies the next-level stakeholders and their win conditions, then reconciles those conditions into next-level objectives (Boehm and Bose, 1994). It rests on Theory W, which uses negotiation to reach a set of objectives every stakeholder can accept.
Steps four to seven are the original quadrants: evaluate alternatives and resolve risks, define the next level of product and process, validate those definitions, then review and commit.
Spiral Model Advantages and Disadvantages
Removing risk early is the whole selling point, and overhead is what you pay for it. On a project with no risks worth removing, that money buys nothing.
Advantages
- Nonviable alternatives get eliminated in an early loop, before any build money is spent.
- Risk-driven experimentation exposes mismatches while they’re still cheap to fix, so there’s less rework.
- Backtracking is allowed, so earlier decisions can be revisited when something changes.
- Every loop ends with a stakeholder review and a commitment to proceed, which keeps buy-in from drifting.
Boehm credits the first two to the cyclic approach itself, in the SEI report on spiral development (2000).
Each loop buys information before the next one spends money. All of the advantages above trace back to that one mechanic.
Disadvantages
- Overhead on small or low-risk projects
- A heavy dependence on how well the team assesses risk
- No built-in end point
- A complex process that needs experienced management
- Poor fit with fixed-scope, fixed-price funding
The skill dependence is the one that hurts. A loop’s risk analysis is only as good as the people doing it, and Boehm’s look-alike list includes impeccable spiral plans that never commit to managing the risks they identify.
The open-ended loop count is the second problem. Anchor point milestones give stakeholders a defined moment to abandon the project or commit to another cycle.
Documentation and Cost
On documentation, GeeksforGeeks lists strong approval and documentation control as an advantage, while A Plus Topper calls the volume of early documentation a disadvantage.
Both are describing a tailoring choice. Boehm ties the degree of detail of each artifact to risk, so documentation volume is a project decision, not a fixed property of the model. A team that specifies everything in detail is drifting toward a look-alike.
Cost is murkier. Tutorials call the model expensive and attach no figure to the claim.
Boehm argues the other way. Funding follows a stud poker pattern, with a few chips in the pot per round, so a team can drop out after a cheap early loop instead of funding the whole build up front. Developers who need technical documentation for audits can scale it to the loop’s risk rather than to a template.
When the Spiral Model Fits and When It Does Not
It earns its keep when risk is high and requirements are fuzzy, as long as prototypes can test the biggest unknowns cheaply. Small, low-risk projects and anything tied to fixed-scope funding should skip it.
A quick test: if a prototype, a simulation or a stakeholder review can’t shrink the biggest risks before build money is committed, the extra loops add cost and nothing else.
Projects That Fit
- Large systems where several stakeholder groups want conflicting things
- Volatile or unclear requirements, as in a new product line
- Unproven technology that needs testing before anyone commits to it
- Long programs where funding can be released in stages
C-Bridge’s RAPID approach used the equivalent of the anchor point milestones as phase gates and delivered e-commerce applications in 12 to 24 weeks, per the workshop cases in Boehm’s SEI report.
The same report explains why e-commerce suits the model. Technology and market volatility run high enough that requirements and traceability updates swamp a team that specifies everything first.
Projects That Do Not
Small or low-risk work gets little back from the model, since the time spent evaluating risks outweighs anything the analysis can find.
Fixed-scope, fixed-price contracts are a bad match too. The model sets scope loop by loop, and Boehm points to the Department of Defense funding process, which commits to full program funding on very incomplete early information, as the opposite of staged commitment.
A team without risk-assessment skill will run the loops and leave the risks unresolved, so the result is a look-alike.
Well-understood systems cost less with a sequential or incremental process when requirements are stable. For replacing a legacy system piece by piece, Boehm names incremental development, with increments set by how easily each part can be evolved out of the old system, as the better-fitting model.
Looping without a risk to resolve is pure overhead. A low-risk project is better served by a simpler pick from the wider set of software development methodologies.
Spiral Model vs Waterfall, V-Model, Incremental, Agile and RUP
What sets the spiral apart from the other process models is that risk analysis in every loop decides the next step. Here’s how it lines up against the rest.
| Model | Structure | Risk handling | Best fit |
|---|---|---|---|
| Waterfall | Sequential phases | Checked mostly at the start | Stable, well-understood requirements |
| V-model | Sequential, each phase paired with a test phase | Defects caught early by paired tests | Mission-critical work with fixed requirements |
| Incremental | Working builds delivered in sequence | Not required by the model | Stable requirements, staged delivery |
| Spiral | Repeated loops of four activities | Risk analysis in every loop sets the next step | Large, high-risk projects with unclear requirements |
| Agile | Short iterations of working software | Frequent feedback, light formal analysis | Changing requirements, small teams |
Comparison tables, GeeksforGeeks’ among them, treat risk as a fixed property, low for the spiral and high for waterfall. Boehm puts risk in the project instead, which is why any waterfall versus spiral comparison depends on the project rather than on the model.
The V-model pairs a test phase with each development phase but stays sequential. It checks quality early, yet it has no loop for testing a risky assumption.
Incremental and evolutionary development are subsets of spiral steps, not rivals. An evolutionary approach only holds up if certain assumptions are true, and Boehm lists them:
- The first release satisfies stakeholders enough to keep them involved.
- Its architecture scales to the full life cycle requirements.
- User organizations can adapt at the pace of evolution.
- The direction of evolution fits the legacy system being replaced.
Agile and the spiral model both iterate. The spiral asks for risk analysis and a stakeholder commitment at the end of every loop, while Agile leans on short feedback cycles.
Boehm and Turner (Addison-Wesley, 2004) weigh agile against plan-driven methods using 5 factors: personnel, criticality, size, culture and dynamism. They pair the factors with a risk-based method for balancing the two.
For a small product team with changing requirements, Agile is the simpler answer. The spiral model earns its overhead on large, high-criticality programs, which is the plan-driven home ground in Boehm and Turner’s terms.
The Rational Unified Process is a refinement of the spiral model, not a competitor. Boehm lists it, along with the Software Productivity Consortium’s Evolutionary Spiral Process, as a major elaboration of the original.
Spiral Model FAQ
Is the spiral model Agile?
No. Both iterate, but the spiral model is organized around risk analysis and a stakeholder commitment at the end of each loop, not around short feedback cycles.
Boehm and Turner argue that real projects need both agility and discipline.
Why do some tutorials call the spiral model a meta model?
Because it can contain other lifecycle models. GeeksforGeeks uses the label for that reason, but meta model is a tutorial term. Boehm’s own wording is “process model generator”.
What is the difference between the spiral model and iterative development?
The spiral model counts as one form of iterative development, just with stricter rules.
Plain iterative software development only repeats cycles to refine the product. The spiral demands risk resolution in every cycle, followed by a stakeholder review and a commitment decision.
Is the spiral model still used today?
Yes, mostly in evolved forms. Boehm and colleagues refined it into the Incremental Commitment Spiral Model (ICSM), and its anchor point milestones survive as phase gates in the Rational Unified Process.
What do stakeholders review at the LCO and LCA milestones?
They go through the operational concept description, prototyping results, requirements description, architecture description, life cycle plan and a feasibility rationale.
The feasibility rationale answers the pass-or-fail question of whether a product built with the specified architecture and processes will support the operational concept, realize the prototyping results, satisfy the requirements and finish within the plan’s budget and schedule (SEI report, 2000).
Can the spiral model be used outside software?
Yes. The SEI report on spiral development says the model also applies to hardware and to integrating software, hardware and systems, though it is most useful for software.
Keeping Spiral Model Loops and Cost Under Control
A project stays within budget when every loop ends with a go, stop or repeat decision tied to the risk exposure that’s left. That way the loop count follows the risk instead of the calendar.
The working rule is to run another loop only while it removes more expected loss than it costs. It combines two points from Boehm’s work: effort follows risk exposure, and milestones let stakeholders abandon a project.
- Agree the pass criteria for each milestone before loop one, and record the decision at every gate
- Rank risks by exposure and fund only the top ones
The rule has a limit. Calculating risk exposure requires an organization to accumulate calibrated experience with probabilities and loss sizes, according to Boehm’s SEI report (2000).
Staged funding carries a trade-off too. Budget owners accept an unknown total cost until the later loops, in exchange for the option to stop early.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
