A critical integration fails halfway through development. New security requirements emerge, or a technical decision proves far more expensive than expected. For UK businesses investing in complex software, discovering such problems late can mean missed deadlines and substantial rework.
The spiral life cycle model takes a risk-driven approach, dividing development into cycles where teams test assumptions and address major uncertainties before committing further resources.
Our guide explains how the spiral software development life cycle model works, where it differs from Agile and Waterfall, and when its approach makes sense for UK projects with demanding technical or regulatory requirements.
The spiral model in SDLC requires teams to examine major uncertainties before approving further development. When comparing software development companies in the UK, founders should ask how each provider documents risks and handles decisions that affect the project’s budget or scope.
|
Question |
Short answer |
|
What is the spiral life cycle model? |
It is a development model where risks are assessed in every cycle. |
|
Who created it? |
Barry Boehm introduced it in a 1986 article and expanded the model in 1988. |
|
What are the four phases of the spiral model? |
The model is commonly explained through four stages: planning, risk analysis, engineering, and evaluation. |
|
What is it best for? |
It works best for large, complex, and high-risk projects where requirements may change. |
|
What is it not suitable for? |
It is generally unsuitable for small, simple, and low-risk projects. |
|
What is the main trade-off? |
It requires more management effort and experienced personnel. |
The spiral model of the software development life cycle uses the findings from each cycle to determine what happens next. Teams may test an unfamiliar technology, revise requirements, or develop part of the product, depending on the risks identified. Each cycle builds on previous results, with the scope of further work adjusted as uncertainties are resolved.
Barry Boehm first described the spiral model in his 1986 paper A Spiral Model of Software Development and Enhancement, published in ACM SIGSOFT Software Engineering Notes. A more detailed version appeared in IEEE Computer in 1988.
He later called it a “process model generator”, meaning that the choice of development activities depends on the specific risks a project faces.
Unlike approaches that follow a largely predefined sequence, the spiral model uses risk assessment to guide decisions throughout the software development life cycle. A failed integration, changing requirements, or unexpected costs could force the team to revise its plans.
The team evaluates the likelihood and potential impact of these problems before deciding what to test, develop, or change in the next cycle. High-risk issues receive attention first, helping prevent expensive rework later.
Each loop covers four phases of the spiral model: planning, risk analysis, engineering, and evaluation. The findings determine what the team develops next, which problems require further investigation, and whether the project is ready to proceed.
The team sets objectives for the current cycle, reviews requirements, and estimates the budget and timeline. It also identifies constraints and compares possible solutions before choosing what to investigate further.
What the business gets: Clear goals and priorities for the next loop.
The team identifies major technical, financial, and schedule risks and determines how to reduce them. Prototyping, technical tests, and user surveys help verify assumptions before further investment.
A banking app provides a practical spiral model example. Before building payment functionality, the team could test its connection to an existing banking system. This would help identify compatibility or security issues before committing to full development.
What the business gets: A list of significant risks and a plan for addressing them.
In the spiral model in software engineering, this phase covers the design, development, and testing of the next product version. Depending on the risks being addressed, the result may be a prototype or working software with additional features.
What the business gets: A product version that stakeholders can see and test.
The team presents the latest version to the client and users, collects feedback, and agrees on priorities for the next cycle.
What the business gets: An opportunity to change direction before further development increases the cost of doing so.
Boehm later identified three major project milestones that support stakeholder approval and go/no-go decisions at key points in development:
The main trade-off is between reducing expensive mistakes and spending more time on planning, reviews and specialist risk analysis.
|
Advantages |
Disadvantages |
|
Early risk detection: Problems can be identified before they lead to major costs. |
High management effort: Each cycle requires planning, review and documentation. |
|
Flexibility: Requirements can be adjusted between cycles as priorities or information change. |
Requires experienced personnel: Poor risk analysis can lead to incorrect decisions about the project. |
|
Client involvement: The client reviews the result of each cycle and can influence subsequent development. |
Unclear final budget and timeline: The scope becomes more precise as the project progresses through successive cycles. |
|
Clearer estimates: Each cycle provides new information about scope and resources, helping refine the expected software development cost. |
Risk of delays: Decisions at the end of each cycle can slow progress and extend the project beyond the planned duration. |
Selecting the spiral model in software development depends on how much uncertainty a project involves, the consequences of potential failures, and the team’s ability to manage risks throughout development.
Consider the spiral model when:
For enterprise software development, a proof of concept can help verify unfamiliar technologies or architectural decisions before the team commits to a full implementation.
Another development model may be preferable when:
In such cases, the Agile or Waterfall model may be a simpler choice.
Spiral, Waterfall, and Agile differ mainly in what guides development decisions: project risks, a predefined plan, or frequent product delivery.
|
Aspect |
Spiral |
Waterfall |
Agile |
|
Main focus |
Reducing risk in each cycle |
Executing a fixed plan |
Incremental delivery and adaptation to change |
|
Risk handling |
Formal risk analysis in each cycle |
Risks are managed through planned reviews and project controls. |
Risks are addressed through frequent feedback |
|
Reaction to changes |
Changes can be made between cycles |
Changes can be difficult and costly |
Changes are expected throughout development |
|
Client involvement |
Client reviews and approves the result of each cycle |
Participates at defined project milestones |
Continuous throughout development |
|
Best fit |
Large, complex, high-risk projects |
Stable projects with clearly defined requirements |
Products with rapidly changing requirements |
Spiral model vs. Waterfall
Boehm considered Waterfall a special case of the spiral model for projects with stable requirements and sufficiently understood risks. In such cases, teams may follow a predefined sequence without repeated risk-driven planning.
Spiral model vs. Agile
Both approaches use cycles, yet the priorities differ. Spiral focuses on identifying and mitigating risks in each cycle, while stakeholders decide how to proceed further. Agile focuses on producing software frequently and adjusting backlogs through continuous feedback.
Teams can also combine spiral principles with Agile software development, using spiral to assess architecture and major risks before developing functionality incrementally.
For UK projects, the spiral model can provide useful checkpoints for reviewing data protection, security and other regulatory risks as the product evolves. However, using the model does not itself guarantee compliance with UK law.
A Data Protection Impact Assessment (DPIA) helps organisations identify and reduce privacy risks when handling personal data. Under Article 35 of the UK GDPR, it is mandatory before processing begins if the planned activities are likely to pose a high risk to individuals.
The risk analysis phase of the spiral life cycle model provides a useful checkpoint for reviewing privacy concerns. If a new cycle introduces different types of personal data, technologies or processing activities, the team should check if the existing DPIA needs updating.
The Information Commissioner’s Office (ICO) advises keeping assessments under review as projects evolve.
Before choosing a development partner, ask how risk management will work in practice:
Clear answers can help you establish who identifies risks, who makes key decisions, and how changes to the project will be communicated before development begins.
Before choosing the spiral life cycle model, identify the decisions that could cause the greatest financial or technical damage if they prove wrong. Can the team test an unfamiliar integration, validate the architecture, or resolve a regulatory concern before committing to full development?
If these checks could prevent substantial rework, the additional planning may be justified. For projects with settled requirements and few technical uncertainties, a simpler development approach is likely to be sufficient.
Both approaches use iterative development, building software through repeated cycles. The main difference is that the spiral model requires risk analysis to guide each cycle, while a general iterative approach focuses on refining the product through successive versions without mandatory formal risk assessments.
Approval usually involves the client or project sponsor together with relevant stakeholders and the development team. The people involved depend on what is being evaluated, such as business goals, technical risks, budget, or regulatory requirements.
Common mistakes include treating risk analysis as a formality, starting another loop without clear objectives, involving stakeholders too late, and failing to update budget or schedule estimates as the project changes. Another problem is using the model for a simple, low-risk project where its management overhead provides little benefit.
There is no fixed number of loops in the spiral model. The number depends on project complexity, risks, and progress, with further cycles added until the product is ready and the major risks have been addressed.
Share this article:
