The spiral model is a software development process that repeats in loops, and in each loop the bvrw ksvlfsa mboh bv tz vnzk keeah nx the tlqpvah cyxo zlub. It is also called the spiral process model, and Barry Boehm introduced it for projects where a wrong guess is expensive. This guide explains how the loops work, walks through an example and gives a test for when the spiral model fits a custom software development project.
What is the spiral approach in software engineering?
The spiral is a risk-driven process model: the team finds what could go wrong, deals with the biggest problem first, and then decides what to build next. Each pass through that cycle is one loop, and in spiral software development, a project runs as many loops as its risks require.
Boehm presented it as a model that can accommodate other SDLC models as special cases. Depending on the risks, the same project can behave like waterfall or like evolutionary development.
In TekRevol’s reading, the spiral model is a way of sequencing the software development life cycle, not a different set of activities. Its real difference is the question it asks at every step: what is the biggest thing that could sink this project right now?
Where the spiral came from
Barry Boehm published the spiral approach in 1988 in IEEE Computer, in the paper A Spiral Model of Software Development and Enhancement. Wikipedia dates an earlier version to 1986, in ACM SIGSOFT Software Engineering Notes.
Boehm wrote the paper at TRW’s Defense Systems Group, and he argued that document-driven models put too much weight on paperwork. Later work added stakeholder win conditions to every cycle. He later described the spiral methodology as a generator of process models, where the risks of a project determine the process it uses.
The spiral diagram: how to read it
In the spiral diagram, the distance from the center shows the cost spent so far, and the angle shows progress through the current loop. Each full turn is one loop, so the spiral widens as the project builds up cost and commitment.
The four quadrants hold the four steps of every loop, and the dot at the end of each turn marks the review where stakeholders decide whether to continue. Early loops are small and cheap, and late loops are large and costly. In TekRevol’s reading, that is why the model tries to settle the big risks in the early loops.
The four steps of every spiral loop
Every spiral loop runs the same four steps in the same order. Boehm’s paper describes them as setting objectives, evaluating risks, developing and verifying the next-level product, and planning the next loop.
| Step | What happens | The question it answers |
| 1. Set objectives | The team states the goal for this part of the product, the ways to reach it, and the limits | What are we trying to achieve in this loop? |
| 2. Evaluate risks | The team compares the options and lists the significant risks | What could go wrong? |
| 3. Resolve risks and build | The team picks a way to reduce the top risk, such as a prototype, then develops and verifies the next-level product | Did the work reduce the risk? |
| 4. Review and plan | Stakeholders review the results, and the team plans the next loop | Do we start another loop? |
How risk decides what each loop does
Risk analysis is the step that sets the spiral approach apart: the largest open risk picks the action for the loop. A risk can be technical, such as an unproven integration, or it can be about people, such as users who cannot say what they need.
A prototype suits a risk about what users want. A simulation or a benchmark suits a risk about whether the system will perform.
Boehm also used risk to set how much detail each part gets. Parts with high risk get detailed design, and parts with low risk get little. This is how the spiral approach answers the question of how much planning or testing is enough.
When does a spiral loop end?
A loop ends at a stakeholder review that decides whether to start the next one. Boehm’s later work defined three anchor point reviews, which Wikipedia summarizes:
- Life Cycle Objectives: is there an approach that satisfies every stakeholder’s goals?
- Life Cycle Architecture: is the preferred approach defined, with the major risks removed or reduced?
- Initial Operational Capability: are the software, the site, the users, and the operators ready for launch?
If the answer at a review is no, the project runs another loop or stops. In TekRevol’s judgment, stopping is a feature, because it ends a risky project before the full cost is spent.
A spiral example: a clinic booking platform in four loops
Each loop in this example targets a different top risk, so the work follows risk. The example is TekRevol’s illustration: a clinic group wants an online booking platform that must read appointment data from an old records system.
| Loop | Biggest risk | How the team reduces it | Decision at review |
| 1 | Will patients and front-desk staff use online booking at all? | A clickable prototype shown to both groups | Go ahead, because both groups tested it |
| 2 | Can the new platform read the old records system? | A small technical test against a copy of the data | Change course and use a data feed instead of direct access |
| 3 | Will the system stay fast when many clinics book at once? | A load test on the core booking flow | Go ahead, because the results met the target |
| 4 | Can clinics switch over without losing bookings? | A pilot at one clinic, then a staged rollout | Release to all clinics |
Loop 2 changed the plan instead of continuing it. Finding the integration problem in a small test costs far less than finding it after the full booking system is built. A real project may run more loops or fewer.
Advantages of the spiral software development model
The main advantage of the spiral approach is that the riskiest problems surface early, while they are still cheap to fix. Boehm’s paper lists these benefits among others:
- Early error removal. Errors and weak options are eliminated in the early loops.
- A risk-based answer to “how much is enough”. Risk sets how much planning, design, and testing each part needs.
- Preparation for change. The model looks for reuse of existing software and plans for later evolution.
- Quality built in. Quality objectives are part of the process from the first loop.
- One approach for new work and updates. Development and later enhancement follow the same cycle.
Disadvantages of the spiral approach and how to soften them
The main disadvantage of the spiral approach is that it depends on people who can judge risk well. Boehm warned that, without insightful review, a poorly staffed team’s specification can give an illusion of progress. The fixes below are TekRevol’s judgment.
- Dependence on risk expertise. A team that misses a risk runs a spiral that looks healthy and is not. Put an experienced architect or an outside reviewer on the risk list.
- Poor fit with fixed contracts. Boehm writes that contract software acquisition has a harder time achieving the flexibility the spiral approach offers. In TekRevol’s judgment, a fixed scope and price leave no room to change course, so contract one loop at a time or fund an early risk loop on its own.
- Cost and overhead. Reviews and prototypes add work, and a small, low-risk project does not earn it back. Apply the spiral only to the risky part of the project.
- No obvious finish. Without exit criteria, loops can keep going. Agree on the review questions and a loop budget before loop 1.
The spiral methodology vs waterfall and agile
The spiral approach differs from waterfall and agile because risk decides the next step. Boehm described waterfall as what the spiral becomes when budget and schedule risk is high, and user-interface and performance risk is low. The table is TekRevol’s reading of the three approaches.
| Aspect | Spiral | Waterfall | Agile |
| What decides the next step | The biggest open risk | The signed-off plan | The product backlog |
| Planning | Repeated in every loop | Fixed up front | Repeated every sprint |
| When users see software | When a loop needs a prototype or a pilot | Near the end | After every sprint |
| Cost of change | Low in early loops, rising with each one | Highest late in the project | Kept low by short cycles |
| Best fit | Large projects with a serious unknown | Stable scope and a fixed contract | Needs that change, with an available client |
In spiral vs agile, both repeat a loop, but an agile loop ends with working software and a spiral loop may end with a test result that retires a risk. In TekRevol’s judgment, the two combine well: one risk loop first, then agile sprints. Our guide to software development methodologies compares the other approaches.
When to use the spiral approach
Use the spiral approach when the project carries a risk that a prototype, a test, or a review can reduce before the full build. The TekRevol Spiral Fit Check turns that into five questions. The check is TekRevol’s judgment.
| Question | Points toward spiral | Points away from spiral |
| How big is the biggest unknown? | A technical or user question that could sink the project | The problem and the technology are well known |
| How costly is a wrong guess? | High, such as a rebuild or a safety issue | Low and easy to reverse |
| Can requirements be written up front? | No, they depend on what early loops find | Yes, and they will hold |
| What does the contract allow? | Funding in stages or loops | Fixed scope and fixed price |
| Does the team have risk experience? | Yes, a senior person owns the risk list | No, nobody can judge the risks |
Four or five answers in the middle column point to a spiral approach, and four or five in the last column point to a simpler process. Anything in between suggests a lighter version. In TekRevol’s judgment, if one unknown dominates, a proof of concept followed by Scrum sprints often settles it at lower cost.
Mistakes that turn a spiral development into something else
Boehm lists running waterfall in increments among the most dangerous misconceptions about the spiral. Wikipedia reports the list from Boehm’s later work. Another misconception is the belief that every activity in the diagram must happen in a fixed order.
A loop with no risk analysis is a spiral loop, whatever the project calls it. In TekRevol’s judgment, the test is simple: if you cannot name the risk that a loop exists to reduce, it is not a spiral loop.
Not sure if your project carries enough risk for a spiral approach?
If one big unknown could sink your project, the cheapest time to test it is before the full build. Bring your risk list to a conversation, and we will help you decide whether it needs an early validation step or can go straight to a build plan.
TekRevol is a software development company that applies the same idea in its custom software development process. It starts with discovery, validates the idea with an MVP, and only then builds in two-week agile sprints, with the delivery model written into the statement of work.
Choose the model after you list the risks. Start with a Free Consultation.
