Creates a risk-driven approach to the software process rather than a primarily document-driving or code-driven process.
Emphasize management to evaluate and resolve risks in the software project.
In 1988, Dr. Barry Boehm introduced the concept of a spiral life cycle. Emphasizing the use of repeated prototyping, the Spiral Model was developed to address some of the risks associated with system development with new technology or in new application areas. The focus of early prototype spirals is to expose risks and “tease out” requirements from the technology or the business community. Examples of the risks that might be examined with the prototypes include network capacity, ineffective application user interface interaction, or poorly defined business needs.
The approach used with the Spiral Model includes developing enough of an understanding of the requirements to initiate the development activities and to field something for user feedback and requirements clarification or confirmation. The lessons learned from each spiral are then fed into the next loop. Often, several iterations of the spiral are needed before a real understanding of the requirements is achieved, or before the technical risks associated with the project are fully understood.
It is important to realize that, when using a spiral approach, the software developed in support of the prototypes should be viewed as “managed throw-away” code. That is, the code should be managed through the team’s configuration management practices, and a certain amount of quality control should be applied. If there is an interest in leveraging those prototype components in the final production system, then the software should be subjected to the same degree of rigor with regards to code reviews, standards compliance, testing, and change control.
Use of the Rapid Application Development technique (RAD) in these early prototypes is often applicable. However, if this technique is chosen, it is important that the Project Team have a clear goal in mind, with well-defined requirements for that particular prototype. Also, the “user” being served by the prototype must be engaged. By “user,” we mean either the technical subject matter expert who is concerned about how a certain technology might respond, or the business subject matter expert with concerns about a particular business function.