The Spiral Software Development Life Cycle Model

The Spiral Software Development Life Cycle Model

The spiral model, introduced by Dr. Barry Boehm and published in IEEE Computer, 1988, deals with these concerns about the waterfall model: It does not sufficiently deal with changes, it considers a comparatively uniform and orderly sequence of development steps, and it does not provide for such methods as quick prototyping or advanced languages.

The spiral model includes the strengths of the waterfall model while including risk analysis, risk management, and support and management processes. It also permits for the development of the product to be performed using a prototyping technique or rapid application development through the use of fourth-generation (and beyond) languages and development tools.

It reflects the underlying notion that each cycle involves a progression that addresses the same order of steps as the waterfall process model, for each portion of the product and for each of its levels of difficulty, from an overall statement of need to the coding of each individual program.

As shown in Figure (a), each quadrant of the model has a purpose and supporting activities. The quadrants are listed here:

■  Determine objectives, alternatives, and constraints - Objectives such as performance, functionality, ability to accommodate change, hardware/software interface, and critical success factors are identified. Substitute means of implementing this portion of the product (build, reuse, buy, subcontract, etc.) are determined; constraints imposed on the application of the alternatives (cost, schedule, interface, environmental limitations, etc.) are determined. Risks associated with lack of experience, new technology, tight schedules, poor processes, and so on are documented.

■  Evaluate alternatives, and identify and resolve risks - Alternatives relative to the objectives and constraints are estimated; the recognition and resolution of risks (risk management, cost-effective strategy for resolving sources, evaluation of remaining risks where money could be lost by continuing system development [go/no-go decisions], etc.) occurs.

■  Develop next-level product - Typical activities in this quadrant could be creation of a design, review of a design, development of code, inspection of code, testing, and packaging of the product. The first build is the customer's first look at the system. After this, a planning phase begins - the program is reset to respond to customer's reaction. With each subsequent build, a better idea of customer requirements is developed. The degree of change from one build to the next diminishes with each build, finally resulting in an operational system.

■  Plan next phase - Typical activities in this quadrant could be development of the project plan, development of the configuration management plan, development of the test plan, and development of the installation plan.

The Spiral Model

To read the spiral model shown in Figure (a), start in the center in Quadrant 1 (determine objectives, alternatives, and constraints), explore risks, make a plan to handle risks, commit to the approach for the next iteration, and move to the right.

For each iteration, determine objectives, alternatives, and constraints; identify and resolve risks; evaluate alternatives; develop the deliverables for that iteration and verify that they are correct; plan the next iteration; and commit to an approach for the next iteration, if you decide to have one.

There is no set number of loops through the four quadrants - as many should be taken as are suitable, and iterations may be tailored for a particular project.

A prominent factor is that coding is de-emphasized for a much longer period than with other models. The idea is to minimize risk through successive refinements of user requirements. Each "mini-project" (travel around the spiral) addresses one or more major risks, beginning with the highest. Typical risks include poorly understood requirements, poorly understood architecture, potential performance problems, problems in the underlying technology, and so on. "Determining Project Risks", will explain the most common software project risks and techniques for their mitigation. The first build, the initial operational capability (IOC), is the customer's first chance to "test-drive" the system, after which another set of planning activities takes place to kick off the next iteration. It is also important to note that the model does not dispense with traditional structured methods - they appear at the end (outside loop) of the spiral. Design through user acceptance testing appears before final operational capability (FOC), just as they do in the waterfall model.

When using a prototyping approach, there may be a tendency for developers to dismiss good system development practices and misuse the model as an excuse for "quick-and-dirty" development. Proper use of the spiral model or one of its simpler variants will help prevent "hacking" and instill discipline. As seen in Figure (a), after much analysis and risk assessment, the "tail" of the spiral shows a set of waterfall-like disciplined process phases.

Addressed more thoroughly than with other strategies, the spiral method emphasizes the estimation of alternatives and risk assessment. A review at the end of each phase ensures commitment to the next phase, or, if necessary, identifies the need to rework a phase. The advantages of the spiral model are its stress on procedures, such as risk analysis, and its adaptability to different life cycle approaches. If the spiral method is employed with demonstrations, baselining, and configuration management, you can get continuous user buy-in and a disciplined process.

Strengths of the Spiral Model

When applied to a project for which it is well suited, strengths of the spiral model contain the following:

■  The spiral model allows users to see the system early, through the use of rapid prototyping in the development life cycle.

■  It provides early indications of insurmountable risks, without much cost.

■  It allows users to be closely tied to all planning, risk analysis, development, and evaluation activities.

■  It splits a potentially large development effort into small chunks in which critical, high-risk functions are implemented first, allowing the continuation of the project to be optional. In this way, expenses are lessened if the project must be abandoned.

■  The model allows for flexible design by embracing the strengths of the waterfall model while allowing for iteration throughout the phases of that model.

■  It takes advantage of the strengths of the incremental model, with incremental releases, schedule reduction through phased overlap of releases, and resources held constant as the system gradually grows.

■  It does not rely on the impossible task of getting the design perfect.

■  It provides early and frequent feedback from users to developers, ensuring a correct product with high quality.

■  Management control of quality, correctness, cost, schedule, and staffing is improved though reviews at the conclusion of each iteration.

■  It provides productivity improvement through reuse capabilities.

■  It enhances predictability through clarification of objectives.

■  All the money needed for the project need not be allocated up-front when the spiral model is adopted.

■  Cumulative costs may be assessed frequently, and a decrease in risk is associated with the cost.

Weaknesses of the Spiral Model

When applied to a project for which it is not well suited, weaknesses of the spiral model contain the following:

■  If the project is low-risk or small, this model can be an expensive one. The time spent evaluating the risk after each spiral is costly.

■  The model is complex, and developers, managers, and customers may find it too complicated to use.

■  Considerable risk assessment expertise is required.

■  The spiral may continue indefinitely, generated by each of the customer's responses to the build initiating a new cycle; closure (convergence on a solution) may be difficult to achieve.

■  The large number of intermediate stages can create additional internal and external documentation to process.

■  Use of the model may be expensive and even unaffordable - time spent planning, resetting objectives, doing risk analysis, and prototyping may be excessive.

■  Developers must be reassigned during nondevelopment-phase activities.

■  It can be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration.

■  The lack of a good prototyping tool or technique can make this model clumsy to use.

■  The industry has not had as much experience with the spiral model as it has with others.

Some users of this technique have found the original spiral model to be complicated and have created a simplified version, shown in Figure (b).

A Simplified View of the Spiral Model

Another version, a modified view of the spiral model from the Software Productivity Consortium, may be seen in Figure (c).
A Modified View of the Spiral Model

When to Use the Spiral Model

A project manager may feel confident that the spiral model is suitable when several of the following conditions are met:

■  When the creation of a prototype is the appropriate type of product development;

■  When it is important to communicate how costs will be increasing and to evaluate the project for costs during the risk quadrant activities;

■  When organizations have the skills to tailor the model;

■  For projects that represent a medium to high risk;

■  When it is unwise to commit to a long-term project due to potential changes in economic priorities, and when these uncertainties may limit the available time frame;

■  When the technology is new and tests of basic concepts are required;

■  When users are unsure of their needs;

■  When requirements are complex;

■  For a new function or product line;

■  When significant changes are expected, as with research or exploration;

■  When it is important to focus on stable or known parts while gathering knowledge about changing parts;

■  For large projects;

■  For organizations that cannot afford to allocate all the necessary project money up-front, without getting some back along the way;

■  On long projects that may make managers or customers nervous;

■  When benefits are uncertain and success is not guaranteed;

■  To demonstrate quality and attainment of objectives in short period of time;

■  When new technologies are being employed, such as first-time object-oriented approaches;

■  With computation-intensive systems, such as decision support systems;

■  With business projects as well as aerospace, defense, and engineering projects, where the spiral model already enjoys popular use.


spiral model, configuration management, life cycle
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2017 SPMInfoBlog.
Designed by TechPlus