The Spiral Model
In terms of software development, the term risk may be defined as the state or property of a development project that, if ignored of left unresolved, will increase the likehood of project failure (Repponen & Lyytinen 2000). Alternatively, Boehm (1991) defined risk as "potential loss times the probability of loss." Perhaps one should call risk neither necessarily a clear nor a present danger, but a threat nonetheless. Even a straightforward risk analysis of a basic problem may be quite complex. As an illustration, considr the case of the risk involved if a firewall has security hole. A certain probability is that the hole will be detected by a potential intruder and used for exploitation. Another probability is that the perpetrator or the intrusion will be detected. There is an estimated cost to the intruder if detected as well as an estimated damage to the organization if the perpetrator is successful.
It is easy to see that, for a full-scale development project, a risk analysis can be daunting. Risk is information dependent because the more certain information is available about a project and its global context, the lower the expectation of risk will be. Some recent investigators have considered a more nuanced understanding of risk, differentiating among risk, uncertainty, danger, and chance. thus, Stahl, Lichtenstein, and Mangan (2003) identify uncertainty as referring to the lack of knowledge of the future, danger to factors beyond the control of the participants, and chance to the possibility that future events may produce unforeseen opportunities that can lead to a positive or negative reevaluation of the current project. However, these terms do not have a uniformly agredd on meaning. Any software development incurs a risk of failure because the system is large or novel, or because resources may prove inadequate.
Addressing risk in software development has been an important driving factor in the evolution of process models. Boehm (1984) seems to have been the first to emphasize ecplicity the importance of the concept of risk factors in development, although previous models addressed risk implicitly. In any case, the introduction of risk-driven models was a major advance over the existing document-driven or code-driven models. As benchmarking and simulation. If the performance characteristics of the proposed system are decisive, then prototyping may be used to resolve outstanding risk issues with the expectation that the prototype can exhibit a solution that is "operationally useful and robust enough to serve as a low-risk base for future product evolution" with subsequent phases also evolving through a series of prototypes. If the performance risks are decided to be acceptable or resolved and program development risks come to predominate, then the next cycle of the sprial may follow a waterfall appraoch. Yamamichi et al. (1996) describe the Spiral model as similar to a prototyping approach in which an initial software core or kernel is repeatedly confirmed through testing as functions are added. This makes the model quite effective in evaluating and verifying qulaity and performance as development proceeds.
The model is highly fiexible and designed for customization (Boehm 1988), It allows one to incorporate other process models (such as the Waterfall, Evolutionary, Incremental, or Transform models) in an inclusive framework driven by project requirement and the dual objective or maximizing user satisfaction while minimizing development uncertainty. As an example of the flexible choice o methodology at each phase, the developers may choose to use simulation rather than prototyping to test the feasibility of the project.
Alternative development models can be used as tools on an as-needed basis rather than being adopted in their entirety. The Spiral Model illustrates how process models can be combined with one another to good effect, such as by integrating prototyping (or, say, simulation) in order to reduce risk Additionally, formal methods can be combined with prototyping to further a process-model generator by combining it with a model decision table that automates guided decisions on process selection (Boehm & Belz 1988).
The sprial model's sturcture enforces close attention to user satisafaction and approval as it iterates through the succession of cycles of validation and verification. Each cycle closes with a review by the stakeholders of the system being developed that has the objective of ensuring a consensus that "all concernes parties are mutually committed to the approach for the next phase" (Boehm 1988). The consensus points act as anchors or project milestones. Furthermore, the stakeholder consensus entails agreement not only on the plan for the following phase, but also on the resources required to carry out the plan. These spiral risk-reduction reviews can be as simple as a programmer walk-through or, at the other extreme, may involve all classes of stakeholders from customers and users to developers and maintainers. Boehm proposes a hypothesis-testing view of the entire development process.
The Spiral gets started with the hypothesis that a "particular operational mission (or set of missions)" can be improved by a proposed software effort. This hypothesis is then recurrently tested and perhaps modifies as the spiral develops, with termination of the development process if, at any point, the hypothesis is shown to fail the test. The failure may well be for exogenous reasons, such as because a window of opportunity for the product passes or because a better product becomes available. Terminologically, Boehm describes the model as comprising a sucession of different types of rounds in the spiral.
The starup round 0 consists of a preliminary feasibility study. The following round 1 is the concept-of-operation round. Round 2 is a top-level requirements specifications round. Succeeding rounds vary depending on the project. Eventually a finished system or product is produced; however, because of the compromises and revisions made along the way, it may vary considerably from the initial intention.