Spiral Methodologies

The Spiral Model was first defined in an article by Barry Boehm [6] and where first is introduced a combination the advantages of top-down and bottom-up strategies (see table2.1), in trying to achieve this he combined the use of pro-totyping and design. The spiral model can be seen as a meta-model because it is adaptable to any process development method. It’s innovation is brought by guiding the project by measuring risk levels within its development and its management (see table2.2). Other innovation in the Spiral Model it’s the fact that its evolution it’s cyclic instead of linear. This model emphasizes the design process for an identification and mitigation of the high risk problems and a dif-ferential reaction for the severity of the risk in cause.

The Spiral model is represented by a Cartesian diagram with a spiral with cen-ter in (0,0) of the diagram. The radius of the spiral is the representation of the accumulated process cost and the angular dimension its progress (see Figure 2.2).

The spiral model can be generally divided into this major steps:

1. System requirements definition: this requirements should be as detailed as possible. It is normal to involve users (internal and external) in this stage, with interviews or interactions that identifies the objectives to achieve within the project, such as which qualities (section2.3) it should achieve.

In this stage the possible alternatives are identified, whether you can buy a package, reuse some software or to make a project from scratch (designing it) This also requires that the constraints to each alternative are well identified.

Top-Down Bottom-Up This strategy is based in beginning into

a very not detailed analysis of the sys-tem, and then refining it into differ-ent sub-systems into greater detail go-ing through it until the entire definition is reduced to a set of base definitions.

The theme words for this strategy is analysis or decomposition.

This strategy is almost the reverse of the previous one. The definition of the system is began by its base elements, and then trying to linked them into a greater system (inferring the system, by a set of base elements). The theme words for this strategy is synthesis or induction.

Table 2.1: Top-Down and Bottom-Up Strategies

2. Then the alternatives and its constraints are then evaluated into all the potential risk (table2.2) of leading with this constraints. This risk mea-surement and how to manage it may require prototyping/simulation to find out the solution to deal with the constraints and potential changes of the requirements.

3. After the risks are measured the first prototype is developed and verified, this stage is also characterized by risk analysis of the other first version from the preliminary design, in this stage is normally done by using a linear/scale-down model (such as Waterfall model sub-section2.6.1) if the requirements are well defined and all risks are well analysed, the develop-ment can now be done linear, if the prototype is considered to be mature enough or, it turns to another spin in the spiral which will mature the first prototype into by defining new requirements (which will become evo-lutionary), even transformation can be performed during this stage, by refining a specification into a prototype. This is the stage where the com-bination of the different models is achieved. This stage ends with the different levels of testing and integration

4. The final stage and forth is where you analyse the work from the previous stage and develop a plan for what to do in the next iteration if needed.

It is also the phase where the project is evaluated and the qualities are measured.

In terms of qualities the robustness is increased in each iteration of the spiral, as you define requirements as part of the robustness of the product, if you identify new requirements to the next iteration, in each iteration the requirements become a part of the specification and design, so you increase the correctness of the product, and by that you approximate robustness to the correctness.

“(...)discipline whose objectives are to identify, address, and eliminate software risk items before they become either threats to successful software operation or a major source of expensive software rework“ - Boehm 1989 [7]

”Risks are potentially adverse circumstances that may impair the development process and the quality of the products.“ - Fundamentals of Software Engineer-ing 1991 [14]

Table 2.2: Risk in software projects

Figure 2.2: Spiral Model, Boehm,1988 (CC)

Critic to the Spiral Methodology

The Spiral Model as introduced the risk analysis into the planning a software product which the earlier process model did not have. This measure is occurs in a natural way in a real-life situations but it was not considered as a part of the management and planning of the project, was just performed taking intuition and empirical knowledge. This and a strong versatility of the model are the great advantages of using the spiral model.

Although the risk analysis can be hard to perform and if a high risk is measured as a low or not important (or the opposite) the development process can be easily become an disadvantage. Also the misuse of the spiral iterations can lead to a waste of time if the risk, tracking and control are not performed carefully.

Also from the point of view of the contractors you can have an image issue, where the work performed it’s not very tangible from his point of view in early stages of the spiral.