The Spiral Model: A Risk Driven Approach

1. The Spiral Model: A Risk Driven Approach Prepared by Scott Sigalas

2. Barry Boehm • 1935 – • Chief Scientist of Defense Systems Group at TRW, 1973 – 1989 • Found waterfall model limiting • Presented spiral model in 1986

3. Waterfall Model • Was the predominant model at the time • Implements a rigorous phase by phase method • Requires a large investment of time/resources at the front end of the project • Prototypes via “build it twice” step • Requires lengthy documentation

4. Spiral Model • Driven by risk assessment • “What are the areas of uncertainty and what are the chances that they will slow the development of the project?”

5. Spiral Model

6. The phases of the spiral model • Risk Analysis • Prototype • Design/Validation • Planning • Alternatives? • Repeat • Measure of Cumulative Cost and Progress on y-axis

7. How do we ever get started? • Using the Mission Opportunity Model, decide if a software effort will improve the current situation • If yes, begin the cycle • Continue testing hypothesis • If hypothesis fails, terminate the spiral • Else, continue to completion • Allow easy way to analyze if cycle should even begin

8. Testing the Hypothesis

9. How to proceed with risk • If alternatives/uncertainties arise in analysis, they must be resolved • Other software models may be used to resolve risk • Development oriented risks like budget, schedule, and predictability should be resolved with the waterfall method • For user interface risks, continue with the spiral by developing, testing, and planning the next spiral

10. Finishing a cycle • At the end of the cycle, a review is done by all parties in the project • A commitment is made for the specifications of the next cycle • As the project progresses, each level of the spiral should be more detailed

11. Advantages • Promotes software reuse in the early stages • Allows objectives to be developed during the project • Does not invest too many resources on the front end of the project • Same approach can be taken for development and maintenance

12. Drawbacks • Requires that a member of the team be experienced in risk assessment • Improper risk evaluation may lead developers down the wrong path • Works best with internal projects where more freedom is given for alternatives

13. NASA TReK • NASA Telescience Resource Kit • Implemented with a slightly modified spiral model

14. Challenges facing TRek • Need for early product availability • Limited personnel • Limited time • Dependency on external systems built in parallel by different teams • Team decided on the risk based approach of the spiral model

15. Issues during development • External interfaces were not available early in the project • Team worked on tasks slated to be resolved in later iterations • Team unfamiliar with environment • Early cycles focused on small coding standards and worked up to larger chunks in later iterations • Tool did not integrate cleanly into development environment • Was already identified as a risk so the team was prepared

16. Conclusion • Risk driven approach to development allows adaptability within a single life cycle and across a range of projects • Does not replace all other models, but rather manages use of their best features