Spiral Model of Software Development and Enhancement

The traditional software models discouraging the old software models. 

               While the Waterfall Model presents a straightforward view of the software life cycle, this view is only appropriate for certain classes of software development. Specifically, the Waterfall Model works well when the software requirements are well understood (e.g., software such as compilers or operating systems) and the nature of the software development involves contractual agreements. The Waterfall Model is a natural fit for contract-based software development since this model is document driven; that is, many of the products such as the requirements specification and the design are documents. These documents then become the basis for the software development contract.

                According to Boehm, however, this model "does not work well for many classes of software, particularly interactive end-user applications." Specifying the requirements for such applications is notoriously difficult since interface design is highly subjective and clients rarely ever understand the real needs the software should meet. As a result, "document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decision-support functions, followed by the design and development of large quantities of unusable code" [Boehm 1988]. The problem is that a contract is signed before the real requirements of the system are properly understood.

                In addition to this shortcoming, the Waterfall model provides no means for risk assessment and management during the life cycle. Consider the case of the baggage-handling system at the Denver International Airport (DIA) again. Initially, DIA had intended that each individual airline would be responsible for building its own baggage-handling system. However, when American Airlines (AA) decided to use DIA as its second-largest hub airport, AA commissioned BAE Automatic Systems to develop an automated baggage-handling system efficient enough to allow AA to turn aircraft around in under thirty minutes. As the construction of the airport progressed, a larger vision emerged "for the inclusion of an airport-wide integrated baggage-handling system that could provide a major improvement in the efficiency of luggage delivery." To accommodate the vision, DIA negotiated a new contract with BAE to develop the airport-wide baggage system. This new plan, however, "underestimated the high complexity of the expanded system, the newness of the technology, and the high level of coordination required among the entities housed at DIA that were to be served by the system" [Montealegre 1996]. Despite the enormous change in the specifications of the project, no one gave any thought to risk assessment. Had the developers considered the risks involved with changing the system requirements radically at a late stage of development, they may have concluded that the expanded plan was infeasible. In the end, DIA had to settle with a much less ambitious plan, and Montealegre reports that "six months after the de-scaling of the system, the airport was able to open and operate successfully."

In 1988, Barry Boehm proposed a more comprehensive life cycle model called the Spiral Model to address the inadequacies of the Waterfall Model. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. Software projects encompass many different areas of risk such as project cost overruns, changed requirements (e.g., the DIA baggage system), loss of key project personnel, delay of necessary hardware, competition from other software developers, technological breakthroughs which obsolete the project, and many others. The essential concept of the Spiral Model is "to minimize risks by the repeated use of prototypes [emphasis added] and other means. Unlike other models, at every stage risk analysis is performed... The Spiral Model works by building progressively more complete versions of the software by starting at the center of the spiral and working outwards. With each loop of the spiral, the customer evaluates the work and suggestions are made for its modification. Additionally, with each loop of the spiral, a risk analysis is performed which results in a 'go / no-go' decision. If the risks are determined to be too great then the project is terminated" [Frankovich 1998]. Thus, the Spiral Model addresses the problem of requirements engineering through development of prototypes, and it addresses the need for risk management by performing risk analysis at each step of the life cycle. In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].

Template	Explanation	Example Phase
Objectives	The goals of the software project	Significantly improve software quality
Constraints	Limitations which the project must meet	Within three years Without large-scale capital investment Without radical change to company standards
Alternatives	Possible ways to achieve the objectives	Reuse existing certified software Introduce formal specification and verification Invest in testing and validation tools
Risks	Potential risks for this phase	No cost effective quality improvement possible Quality improvements may increase costs excessively New methods might cause existing staff to leave
Risk Resolution	Strategies for reducing the risks	Literature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars
Results	Results of applying risk resolution strategies	Experience of formal methods is limited - very hard to quantify improvements Limited tool support available for company standard development system Reusable components available but little reuse tool support
Plans	Development plans for the next phase	Explore reuse option in more detail Develop prototype reuse support tools Explore component certification scheme
Commitment	Resources needed to achieve the plans	Fund further 18-month study phase

Spiral Model Template

In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.

The animation below illustrates how the eight management elements of the Spiral Model template are organized in each phase. Click "Start Tutorial" to view the animation.

The final phase of the Spiral Model is analogous to the Waterfall Model. At this point in the project, the software requirements should be well-understood through the development of several prototypes. The project should also have resolved the major risks involved with building the final version of the software. With these issues resolved, the detailed design of the software enters the last three processes of the Waterfall Model, and the software is created. Although some of the labels in the Spiral Model are different, the same processes are represented. The table below shows the correspondence between the final phase of the Spiral Model and the Waterfall model.

Waterfall Model Spiral Model Design Specifications Detailed design Programming Code, Unit test Integration Integration and test Delivery Acceptance test, Implementation

Notice, however, that the maintenance process which appeared as dashed lines in the complete Waterfall Model seems to be missing from the Spiral Model. What happened to this process? Boehm [1988] explains: "The answer to [this question] involves an observation that the spiral model applies equally well to development or [maintenance] efforts. In either case, the spiral gets started by a hypothesis that a particular operational mission could be improved by a software effort." Thus maintenance simply becomes another spiral or phase in the life cycle of the software. Like the previous phase, the maintenance efforts undergo risk assessment to evaluate whether changes are feasible.

References

• Boehm, B. (1988), "A Spiral Model of Software Development and Enhancement," IEEE Computer 21, 5, 61-72.
• Frankovich, J. (1998), "Synopsis of the Carnegie Mellon University course on Requirements Engineering," http://sern.ucalgary.ca/courses/seng/621/W97/johnf/reqeng.htm.
• Montealegre, R. (1996), "What Can We Learn from the Implementation of the Automated Baggage-Handling System at the Denver International Airport," In Proceedings of the Association for Information Systems Americas Conference.
• Schach, R. (1999), Software Engineering, Fourth Edition, McGraw-Hill, Boston, MA.
• Sommerville, I. (1996), Software Engineering, Fifth Edition, Addison-Wesley, Reading, MA, pp. 14.