Spiral model
The Spiral model is a risk-driven software development process model introduced by Barry Boehm in 1986. It treats software development as an iterative process in which each cycle explicitly addresses the highest-risk elements of the project first. The process spirals outward through repeated cycles of risk analysis, prototyping, and stakeholder evaluation, with each cycle producing a more complete and refined system.
The spiral model was a direct response to the limitations of both the waterfall model, which assumes stable requirements, and early agile approaches, which sometimes treated risk as a secondary concern. By making risk the primary driver of process structure, the spiral model provides a disciplined framework for managing uncertainty in large-scale, safety-critical systems — defense, aerospace, medical devices — where the cost of late-discovered failure is catastrophic.
Each cycle of the spiral involves four activities: determining objectives, identifying and resolving risks, developing and verifying the next-level product, and planning the next cycle. The model is not a prescriptive methodology but a meta-model that can accommodate different development techniques within each cycle, from formal specification to rapid prototyping.
The Systems Critique: Risk as Feedback Topology
The spiral model treats risk as a driver of process structure: each cycle addresses the highest-risk elements first. This is sound project management. But it is not systems thinking. The spiral model assumes that risk is a property of individual components — requirements, design, implementation — that can be identified, prioritized, and addressed in sequence. This assumption is false for any system whose risks are not component properties but topological properties: emergent properties of the feedback structure that couples components together.
In a systems-theoretic framework, risk is not a list of hazards to be mitigated one by one. Risk is a property of the system's feedback topology: the sign, delay, and gain of the loops that connect decisions to consequences. The spiral model's risk analysis asks: What could go wrong with this component? The feedback topology asks: What happens when this component's failure couples to that component's response? The Air France Flight 447 accident was not a component failure; it was a topological failure: a sensor anomaly coupled to an autothrottle response that coupled to a pilot confusion that coupled to a stall. No spiral cycle could have identified this risk because the risk was not in any single component; it was in the coupling.
The spiral model's implicit ontology is linear: objectives → risks → development → planning. But real systems exhibit circular causality: the development of a prototype changes the stakeholders' understanding of their objectives, which changes the risks they perceive, which changes the next cycle's development priorities. The spiral is not a line that loops; it is a loop that spirals. The distinction matters because a looping line can be managed by iteration; a spiral loop must be managed by topology.
The deeper critique is that the spiral model, like all process models, treats the development process as separable from the system being developed. But the development process is itself a system: a sociotechnical network of stakeholders, engineers, tools, and organizational incentives with its own feedback topology. The spiral model's risk analysis rarely analyzes this meta-system. It asks what risks the product faces; it does not ask what risks the process faces. A process that rewards early prototyping may amplify architectural risk by making early decisions sticky. A process that defers formal verification may create a positive feedback loop in which informal testing becomes the only validation, and the absence of formal methods becomes self-justifying.
Resilience engineering offers a more adequate framing. Resilience is not the absence of risk but the presence of adaptive capacity: the ability to anticipate, monitor, respond, and learn. The spiral model's four activities — objectives, risk analysis, development, planning — map roughly onto these capacities. But resilience engineering insists that safety is a property of processes, not systems, and that the people who operate the process are the source of flexibility, not error. The spiral model, in contrast, treats the process as a machine and the people as operators of the machine. The systems critique is that this inversion is itself a risk: the more the process is automated, the less the people can adapt it, and the more fragile the system becomes.
The spiral model is not wrong. It is incomplete in a way that matters for the systems it is used to build. It treats risk as a list when risk is a topology. It treats process as linear when process is circular. It treats people as operators when people are the source of resilience. A spiral model that incorporated feedback topology, circular causality, and resilience engineering would not be a process model at all. It would be a systems model — and that is precisely what software engineering, and every other engineering discipline, actually needs.