Spiral model software development is the answer Barry Boehm gave in the 1980s to a problem that still sinks projects in 2026: teams commit their whole budget to a plan before they know which parts of that plan are wrong. Instead of marching through fixed phases, a spiral project loops through the same four activities again and again, and in every loop it spends its effort on whatever is most likely to make the project fail.
That makes the spiral model of software development a natural fit for the kind of work where a wrong early assumption is expensive: core banking replacements, clinical systems, logistics platforms, defence and aerospace software, and other forms of custom enterprise software development where integration, performance or regulatory risk can wipe out a year of effort. It is also the model most often misunderstood, because the famous diagram looks like a process to follow rather than a way of deciding what to do next.
This guide explains the spiral model in plain terms: where it came from, how to read the diagram, what happens in each quadrant, the milestones that stop a spiral from looping forever, a worked example, its real advantages and disadvantages, and how it compares with waterfall, the V-model and agile. The final section shows how we apply spiral thinking on modern projects without its historical paperwork.
What is the spiral model in software development?
The spiral model in software development is a risk-driven, iterative life-cycle model in which a project repeatedly cycles through four activities — set objectives, resolve risks, build and test, plan the next cycle — with each cycle producing a more complete version of the system. The key idea is that risk, not a predefined sequence, decides how much of each activity to do and when.
Each turn of the spiral is called a cycle, loop or iteration. Early loops are small and cheap: a concept of operations, a feasibility study, a throwaway prototype. Later loops are larger and look more like conventional development and deployment. The distance from the centre of the spiral represents cumulative cost, so the model makes it visible that every extra loop spends money and must earn its place.
Where the spiral model came from
Barry Boehm, then at TRW, first described the model in the 1986 paper A Spiral Model of Software Development and Enhancement and published the best-known version in IEEE Computer in May 1988. His example was the TRW Software Productivity System, an internal tooling programme whose requirements were too uncertain for a single waterfall pass. Boehm later formalised the model in a 2000 report for the Software Engineering Institute at Carnegie Mellon, and in 2014 co-authored the Incremental Commitment Spiral Model, the modern evolution of the idea.
The spiral also shaped public-sector acquisition. In 2000 the US Department of Defense adopted evolutionary acquisition with spiral development as a preferred approach for major systems, and Boehm wrote guidance on using the spiral for that purpose. That heritage explains why the model is still common in aerospace, defence, government and other high-stakes programmes.
Why the spiral model is called a meta-model
The spiral model is called a meta-model because it can contain the other process models instead of replacing them. If the main risk in a loop is unclear user needs, that loop behaves like evolutionary prototyping. If requirements and technology are well understood, a loop can run as a short waterfall. If the risk is late integration, the loop can deliver an increment. The spiral is the decision framework; the model used inside each loop is chosen per risk.
How do you read the spiral model diagram?
The spiral model diagram is read from the centre outwards: the spiral starts at the origin, crosses four quadrants in each loop, and every completed loop ends with a review and a commitment to the next one. The radius shows cumulative cost; the angle shows progress within the current loop.
Most diagrams online omit the elements that make the spiral useful, so it helps to know what each visual element means:
| Diagram element | What it means | Practical implication |
|---|---|---|
| Radial distance from centre | Cumulative cost spent so far | Outer loops are expensive; do risky learning in inner loops |
| Angular position | Progress through the current loop | Every loop must pass all four quadrants, even briefly |
| Horizontal axis crossing | Review and commitment point | Stakeholders decide to continue, change course or stop |
| Prototypes in quadrant 2 | Risk-reduction artefacts | Built to answer a question, not to ship |
| Outermost loop | Detailed design, coding, testing, deployment | Looks like conventional delivery once risks are retired |
What are the four phases of the spiral model?
The four phases of the spiral model are: determine objectives, alternatives and constraints; identify and resolve risks; develop and test the next-level product; and plan the next iteration. Every loop passes through all four, but the time spent in each depends on the risks of that loop.
1. Determine objectives, alternatives and constraints
The first quadrant defines what this loop must achieve and which ways of achieving it are on the table. The team records the objectives for the portion of the product in scope (performance, functionality, adaptability), the alternative designs or make-vs-buy options, and the constraints such as budget, schedule, regulation and interfaces to existing systems. Clear objectives here are what make the next quadrant’s risk analysis concrete.
2. Identify and resolve risks
The second quadrant is the heart of the spiral: the team evaluates the alternatives against the objectives, identifies the biggest sources of risk and spends just enough effort to reduce them. Typical techniques are throwaway prototypes, benchmarks, simulations, user interviews, reference checks on vendors and analytic models. The output is a decision: which alternative to pursue and which risks remain open.
3. Develop and test the next-level product
The third quadrant builds the next version of the product, using whichever development approach fits the remaining risk. In early loops that may be a specification or an architecture; in later loops it is working code, integrated and tested. Because the big unknowns were handled in quadrant 2, this work rests on validated assumptions rather than guesses.
4. Review and plan the next iteration
The fourth quadrant closes the loop with a review of the results by the people who own the money and the requirements, followed by a plan for the next loop. The review is a genuine commitment point: stakeholders can continue as planned, change the objectives, or stop the project while the cumulative cost is still low. Stopping early is a legitimate, and often valuable, outcome.
| Quadrant | Key question | Typical inputs | Typical outputs |
|---|---|---|---|
| 1. Objectives | What must this loop achieve? | Business goals, stakeholder needs, previous loop review | Objectives, alternatives, constraints |
| 2. Risk analysis | What could make us fail? | Alternatives, constraints, risk register | Prototypes, benchmarks, chosen approach |
| 3. Engineering | Can we build it? | Chosen approach, validated assumptions | Specification, design, code, test results |
| 4. Evaluation | Should we continue? | Results, updated estimates, stakeholder feedback | Go/no-go decision, plan for the next loop |
Why is risk analysis at the centre of the spiral?
Risk analysis sits at the centre of the spiral because the model uses risk to decide how much of every activity to do: if doing more of something reduces the chance of failure, do it; if it does not, stop. Boehm framed this as answering “how much is enough?” for prototyping, documentation, testing and planning.
In practice, that means maintaining a living risk register and reviewing it at the start and end of each loop. The register below shows the kind of risks a typical enterprise spiral project tracks and the technique used to retire each one:
| Risk | Likelihood | Impact | Resolution technique | Retired in loop |
|---|---|---|---|---|
| Users reject the new workflow | Medium | High | Clickable prototype tested with 8–10 users | 1 |
| Legacy ERP API cannot handle peak volume | High | High | Load benchmark against a staging copy | 2 |
| Third-party vendor misses delivery dates | Medium | Medium | Reference checks, contractual milestones, fallback option | 2 |
| Regulatory audit finds traceability gaps | Low | High | Traceability matrix reviewed by compliance | 3 |
| Key engineer leaves mid-project | Medium | Medium | Pairing, documentation, knowledge sharing | Ongoing |
Two habits make risk-driven work effective. First, size each risk by likelihood and impact so the team spends effort where the expected loss is greatest. Second, make every prototype answer a specific risk question with a pass/fail criterion; a prototype without a question is just early development. Our guide to proof of concept software development covers how to design those experiments.
What are the anchor-point milestones and invariants of the spiral model?
The anchor-point milestones are three checkpoints — Life Cycle Objectives (LCO), Life Cycle Architecture (LCA) and Initial Operational Capability (IOC) — that Boehm added to keep spiral projects moving towards a finished system instead of looping indefinitely. They are the part of the model most summaries leave out, and the part that makes it manageable.
- Life Cycle Objectives (LCO) — stakeholders agree on what the system should accomplish and that at least one feasible architecture exists.
- Life Cycle Architecture (LCA) — the architecture is chosen, its major risks are resolved, and the plan to build it is credible.
- Initial Operational Capability (IOC) — the first operational release is ready, with users trained and the site prepared.
In the 2000 report Spiral Development: Experience, Principles, and Refinements, published by the Carnegie Mellon Software Engineering Institute, Boehm also listed six “invariants” that every real spiral project shows. A process that skips them is not a spiral, even if it draws one:
- Key artefacts — operational concept, requirements, plans, design and code — are defined concurrently, not one after another.
- Each cycle covers objectives, constraints, alternatives, risks, review and commitment to proceed.
- The level of effort on each activity is driven by risk.
- The degree of detail in each artefact is driven by risk.
- The project uses the three anchor-point milestones (LCO, LCA, IOC).
- The project emphasises the whole system and life cycle, not just initial software development.
Spiral model example: how does a four-cycle project look?
A spiral model example makes the abstract quadrants concrete. Consider a regional hospital network replacing its medication-dispensing software, which must integrate with an existing electronic health record, run on automated dispensing cabinets and pass a regulatory review. The main risks are clinical usability, EHR integration and auditability.
| Cycle | Objective | Main risk attacked | Risk-reduction work | Outcome |
|---|---|---|---|---|
| 1 (4 weeks) | Confirm the concept with nurses and pharmacists | Clinicians reject the workflow | Paper and clickable prototypes, ward observation | LCO reached; scope cut by 20% |
| 2 (6 weeks) | Prove the integration architecture | EHR interface cannot meet response times | HL7/FHIR spike, load test on a staging EHR | LCA reached; message broker added |
| 3 (12 weeks) | Build the core dispensing and audit modules | Traceability gaps for the regulator | Traceability matrix, independent test review | Pilot-ready build in one ward |
| 4 (10 weeks) | Pilot and roll out to the first hospital | Operational disruption at go-live | Parallel run, staff training, rollback plan | IOC reached; network rollout planned |
The cycle lengths above are illustrative, but the pattern is typical: the first two loops are short and cheap, and they change the plan significantly before most of the budget is spent. Had the team discovered the EHR performance problem in month nine of a waterfall project, the fix would have meant redesign under deadline pressure. For more on healthcare integration specifics, see our EHR integration guide.
What are the advantages and disadvantages of the spiral model?
The spiral model’s main advantage is that it exposes and reduces the biggest risks before most of the budget is spent; its main disadvantage is that it depends on experienced people to judge those risks and adds management overhead. Whether the trade is worth it depends on how expensive failure would be.
Advantages of the spiral model
- Early risk reduction. Technical, usability and integration risks are tested in the cheapest loops.
- Flexible requirements. New or changed requirements can enter at the start of any loop.
- Built-in stop points. Every loop ends with a go/no-go decision, so failing projects can be stopped early.
- Better estimates over time. Each loop replaces assumptions with data, improving cost and schedule forecasts.
- Strong stakeholder involvement. Users and sponsors review real artefacts at every loop.
- Works for whole systems. Hardware, software, operations and training can all be planned in the same loops.
Disadvantages of the spiral model
- Needs risk expertise. Without skilled risk analysis, loops become open-ended prototyping.
- Management overhead. Reviews, risk registers and plans for every loop take time.
- Hard to fix a price. Total cost and duration are not known at the start, which complicates fixed-price contracts.
- Can loop indefinitely. Without anchor-point milestones, teams keep refining instead of shipping.
- Overkill for small projects. For low-risk, well-understood work, the ceremony costs more than it saves.
| Factor | Spiral model verdict |
|---|---|
| Project size and cost | Best for large, expensive programmes |
| Requirement clarity | Strong when requirements are unclear or evolving |
| Risk level | Strong when failure is costly or dangerous |
| Budget predictability | Weak at the start, improves loop by loop |
| Team maturity needed | High: senior architects and risk-aware managers |
| Speed for small apps | Weak: agile or a simple iterative model is faster |
The commercial side matters too. Because spiral projects learn their real scope as they go, they fit time-and-materials or phased contracts better than a single fixed price; our comparison of time and materials vs fixed price vs dedicated team explains the options.
When should you use the spiral model?
Use the spiral model when a project is large, costly to get wrong and full of unknowns that can be investigated before full-scale building. If you can answer yes to three or more of the questions below, spiral-style risk loops will likely pay for themselves:
- Is the budget large enough that a failed project would seriously hurt the business?
- Are the requirements unclear, contested or likely to change significantly?
- Does the project depend on new or unproven technology, or on a fragile legacy integration?
- Are there safety, financial or regulatory consequences if the system behaves incorrectly?
- Will the system run for many years, so operations and maintenance must be planned from the start?
- Do sponsors need explicit decision points before releasing each tranche of budget?
Typical fits include defence and aerospace programmes, core banking and payment platforms, clinical and medical-device software, large logistics and ERP replacements, and new products built on unproven hardware or AI components.
When the spiral model is not the right choice
The spiral model is not the right choice for small, low-risk or well-understood projects, for teams without senior people who can run risk analysis, or for work that must ship within weeks. A marketing site, a standard mobile app with known requirements or an MVP aimed at quick market feedback is better served by Scrum, Kanban or a simple iterative model.
How does the spiral model compare with waterfall, V-model and agile?
The spiral model differs from waterfall and the V-model by repeating its phases in risk-driven loops, and from agile by organising those loops around explicit risk analysis and formal commitment points instead of fixed-length sprints. The table summarises the practical differences.
| Aspect | Spiral | Waterfall | V-model | Agile (Scrum) |
|---|---|---|---|---|
| Driver | Risk | Documents and phases | Verification and validation | Customer value and feedback |
| Iterations | Variable-length loops | None (single pass) | None (single pass) | Fixed sprints of 1–4 weeks |
| Requirement changes | At the start of each loop | Costly after sign-off | Costly after sign-off | Every sprint |
| Risk handling | Explicit, every loop | Implicit, late | Through test planning | Implicit, via short feedback |
| Documentation | As much as risk requires | Heavy | Heavy | Light |
| Best for | Large, high-risk systems | Stable, well-defined scope | Safety-critical, regulated | Products with evolving needs |
Pure models are rare in practice. The PMI Pulse of the Profession 2024 report found that the share of projects run with hybrid approaches grew from 20% in 2020 to 31% in 2023, and a spiral-plus-agile hybrid is one of the most common patterns we see in enterprise programmes. For a broader overview, read our guides to software development methodologies and agile vs waterfall.
The Incremental Commitment Spiral Model (ICSM)
The Incremental Commitment Spiral Model is Boehm’s modern refinement of the spiral, published in 2014 with Jo Ann Lane, Supannika Koolmanojwong and Richard Turner. It keeps the risk-driven loops but frames each one around four principles: stakeholder value-based guidance, incremental commitment and accountability, concurrent multidisciplinary engineering, and evidence- and risk-based decisions. In ICSM, a project advances only when the evidence that it is feasible is strong enough for stakeholders to commit more resources.
How do you apply the spiral model in 2026?
The most effective way to apply the spiral model in 2026 is to keep its risk discipline and decision points while running the build work inside each loop with modern agile and DevOps practice. These seven steps describe how we do it on high-risk projects:
- Start with a risk-first discovery loop. Map objectives, constraints and the top ten risks before writing production code; our discovery phase guide shows what to produce.
- Turn risks into experiments. For each top risk, define a spike, prototype or benchmark with a clear pass/fail criterion and a time box.
- Time-box every loop. Keep early loops to 2–6 weeks and later ones to one quarter, so the spiral cannot drift.
- Use the anchor points as funding gates. Release budget for full delivery only after LCA, when architecture risks are resolved.
- Run sprints inside the loops. Use Scrum or Kanban for the engineering quadrant, with CI/CD, automated tests and feature flags.
- Keep the risk register alive. Review it at every loop review, retire risks with evidence and add new ones as they appear.
- Document by risk, not by template. Write detailed specifications where errors are costly, such as interfaces, security and regulated features, and keep the rest light.
The spiral also fits naturally around the broader software development life cycle: it does not replace requirements, design, build, test and deployment, it decides how many times and in how much detail you go through them.
FAQ
What is the spiral model in software development?
The spiral model in software development is a risk-driven, iterative life-cycle model introduced by Barry Boehm in 1986. A project moves through repeated loops, and each loop sets objectives, analyses and reduces the biggest risks, builds and tests a version of the product, and plans the next loop. Risk, not a fixed sequence of phases, decides what the team does next.
What are the four phases of the spiral model?
Each loop of the spiral model has four quadrants: determine objectives, alternatives and constraints; identify and resolve risks, often with prototypes or simulations; develop and test the next-level product; and review the results and plan the next iteration. Stakeholders commit to the next loop only after the review.
Why is the spiral model called a meta model?
The spiral model is called a meta model because it can contain other process models. Depending on the risks of a given loop, a team may run that loop like a waterfall stage, an evolutionary prototype or an incremental release. The spiral decides which approach fits; it does not prescribe a single one.
What is the main disadvantage of the spiral model?
The main disadvantage of the spiral model is its dependence on skilled risk analysis. Every loop needs people who can spot and size technical, schedule and business risks; without them the model turns into an expensive series of open-ended prototypes. It also adds management and documentation overhead, which makes it a poor fit for small or low-risk projects.
Is the spiral model agile?
Not exactly. The spiral model is iterative and accepts changing requirements, like agile, but it is driven by explicit risk analysis, formal reviews and stakeholder commitment points rather than short fixed-length sprints. Many teams in 2026 combine the two: spiral-style risk loops and milestones at programme level, with Scrum or Kanban sprints inside each loop.
Who created the spiral model of software development?
Barry Boehm created the spiral model of software development. He first described it in the 1986 paper A Spiral Model of Software Development and Enhancement and published the widely cited version in IEEE Computer in May 1988, using the TRW Software Productivity System as the example. He later refined it into the Incremental Commitment Spiral Model.
Published 24 October 2026. Sources: B. Boehm, “A Spiral Model of Software Development and Enhancement”, IEEE Computer, May 1988; B. Boehm, Spiral Development: Experience, Principles, and Refinements, CMU/SEI-2000-SR-008; B. Boehm and W. Hansen, The Spiral Model as a Tool for Evolutionary Acquisition; B. Boehm, J. A. Lane, S. Koolmanojwong and R. Turner, The Incremental Commitment Spiral Model, Addison-Wesley, 2014; PMI, Pulse of the Profession 2024. The hospital example and cycle lengths are illustrative.
