Spiral model: the risk-driven software de­vel­op­ment process model

The de­vel­op­ment of new software poses a great challenge to all involved. The more complex the ap­pli­ca­tion is that is to be developed, the more difficult it is to make the de­vel­op­ment process clear and man­age­able in its com­plex­i­ty. For this reason, special step-by-step plans, also known as process models, are usually used. These subdivide the entire de­vel­op­ment process into several man­age­able phases, which are limited in time and content. One of the best-known models, which is par­tic­u­lar­ly oriented to risk reduction, is the so-called spiral model from 1986.

After Barry W. Boehm first presented his concept for the de­vel­op­ment of complex ap­pli­ca­tions in 1986, the American software engineer published his model in 1988 in the pub­li­ca­tion “A Spiral Model of Software De­vel­op­ment and En­hance­ment” in a more com­pre­hen­sive framework. In the pub­li­ca­tion, he describes the spiral model as a possible al­ter­na­tive to the pre­vi­ous­ly es­tab­lished waterfall model, which also served as a basis for ex­pe­ri­ence. In contrast to the waterfall model, the spiral model does not assume that the tasks of software de­vel­op­ment are designed linearly – but sees them as iterative tasks. In the spiral model, the phases are therefore not run through once step-by-step, but several times in a spiral shape. Although this cyclical rep­e­ti­tion means that the project ap­proach­es the goals set com­par­a­tive­ly slowly, the risk of a failed de­vel­op­ment process is de­ci­sive­ly minimized thanks to the regular controls.

Problems within the de­vel­op­ment process can have very different effects on the overall project. In­creas­ing costs, ad­di­tion­al effort, and a delayed release are to be expected in any case – factors that can quickly become a threat to your existence, es­pe­cial­ly for smaller companies. With its in­cre­men­tal, iterative approach – which also provides for regular risk as­sess­ment in the form of prototype drafts, analyses, or sim­u­la­tions – the spiral model is intended to prevent scenarios like these or at least mitigate their negative con­se­quences. The software project con­tin­u­ous­ly runs through the spiral model cycle up to the final status, which basically comprises the following four steps:

A typical cycle in a spiral model starts with con­sid­er­ing which ob­jec­tives should be as­so­ci­at­ed with the in­di­vid­ual steps of software de­vel­op­ment. This can be, for example, improving the per­for­mance or expanding the functions. At the same time, it is necessary to define al­ter­na­tives for im­ple­men­ta­tion (e.g. design A vs. design B) and to determine the framework con­di­tions as well as costs or time ex­pen­di­ture.

The next step is to evaluate the al­ter­na­tives, whereby the target and framework con­di­tions serve as decisive reference values. In this phase of the spiral model cycle, areas of un­cer­tain­ty should be iden­ti­fied that pose a sig­nif­i­cant risk to the progress of the software project. This will be followed by the de­vel­op­ment of the least risky and most cost-effective strategy, using methods such as pro­to­typ­ing, sim­u­la­tions, benchmark tests, an­a­lyt­i­cal models, and user surveys.

Following the risk analysis, the actual de­vel­op­ment of the software continues, which is always char­ac­ter­ized by the relative residual risks. If, for example, per­for­mance or user interface risks or internal interface control risks strongly dominate the de­vel­op­ment process, an evo­lu­tion­ary de­vel­op­ment strategy is the first option, in which the project is specified more precisely and pro­to­types are optimized. The actual code is written and tested several times until the desired result is achieved, which then serves as a low-risk basis for further de­vel­op­ment steps.

Once a cycle is completed, the planning of the next cycle begins. On the one hand, this can be the regular con­tin­u­a­tion of the project if the objective of the single cycle could be achieved and the de­f­i­n­i­tion of the next objective is pending. On the other hand, it can also be a matter of finding solutions if the previous de­vel­op­ment step was faulty. For example, the existing strategy can be replaced by one of the pre­vi­ous­ly defined al­ter­na­tives or a new al­ter­na­tive. With this you can then start a new attempt to reach the given goal.

Spiral software de­vel­op­ment is par­tic­u­lar­ly popular for large, complex projects where budget control is a priority for clients and de­vel­op­ers. In this case, all par­tic­i­pants benefit from the central role of risk analysis, which probably rep­re­sents the greatest advantage of the spiral model over other pro­ce­dur­al models. The regular as­sess­ment of risks pays off in par­tic­u­lar when novel technical en­vi­ron­ments are used, which are usually as­so­ci­at­ed with a par­tic­u­lar risk potential due to a lack of empirical values.

The cyclic structure is also one of the model's great strengths: conflicts between the design and the technical re­quire­ments placed on the software are virtually elim­i­nat­ed thanks to regular checks. In addition, feedback can be obtained and taken into account at any time due to the spiral-shaped progress. In this way, both customers and users can be in­te­grat­ed into the de­vel­op­ment process right from the start. In order to be able to enjoy these ad­van­tages, however, a very active and complex man­age­ment of the project is a pre­req­ui­site, in which the in­di­vid­ual cycles are con­tin­u­ous­ly and carefully con­trolled and doc­u­ment­ed.

The fact that the many small steps in software de­vel­op­ment according to the spiral model are not always ad­van­ta­geous has been proven by the fact that – despite versatile tests – it is not uncommon for un­fin­ished program parts to find their way into the pro­duc­tion system. As a con­se­quence, there is always the danger that any errors or con­cep­tu­al weak­ness­es will also affect the end product. In addition, there can be delays in de­vel­op­ment at any time if important decisions have to be made within a cycle or when planning the sub­se­quent cycle that affect further action.

Here are the ad­van­tages and dis­ad­van­tages of the spiral model in a tabular overview:

Click here for important legal dis­claimers.