The Spiral Model Incremental Waterfall Copyright 2015 2017

The Spiral Model Incremental Waterfall Copyright © 2015 -2017 Curt Hill

Introduction • This was first introduced to combine the best features of the waterfall and interation from the prototyping models • It also emphasizes risk analysis • It dates from a paper by Boehm in 1986 Copyright © 2015 -2017 Curt Hill

Four Phases • • Identification Design Build Risk Analysis Copyright © 2015 -2017 Curt Hill

Diagram Copyright © 2015 -2017 Curt Hill

Identification • Starts with gathering the business requirements • In subsequent iterations there is the identification of system requirements, subsystem requirements and unit requirements • Each spiral requires communication between the user and developers Copyright © 2015 -2017 Curt Hill

Design • Starts with the conceptual design in the first iteration • Subsequent spirals involve architectural design, logical design of modules, physical product design and final design Copyright © 2015 -2017 Curt Hill

Construct or Build • Refers to production of the actual software product at every spiral. • In first spiral the design is being developed as a proof of concept to get customer feedback. • In the subsequent spirals requirements and design details are refined – A working model of the software is produced – These are sent for customer feedback Copyright © 2015 -2017 Curt Hill

Evaluation and Risk Analysis • This includes identifying, estimating, and monitoring technical feasibility and management risks – Including schedule slippage and cost overrun • After testing the software the user evaluates and gives feedback Copyright © 2015 -2017 Curt Hill

Reasons to Use • Budget constraints and risk evaluations are important • Medium to high-risk projects • User is unsure of requirements • Requirements are complex and/or not well understood • Product lines will be released in phases to get customer feedback • Significant changes are expected in the product during the development cycle Copyright © 2015 -2017 Curt Hill

Pros • Changing requirements can be accommodated • Allows for extensive use of prototypes • Requirements can be captured more accurately • Users see the system early • Development can be divided into smaller parts and more risky parts can be developed earlier – This aids risk management Copyright © 2015 -2017 Curt Hill

Cons Management is more complex. • • End of project may not be known early • Not suitable for small or low risk projects and could be expensive for small projects • Process is complex • Spiral may go on indefinitely • Large number of intermediate stages requires much documentation Copyright © 2015 -2017 Curt Hill

Finally • Has some of the aspects of waterfall and prototyping • Much greater risk consideration • Has much of the flavor of several agile methods Copyright © 2015 -2017 Curt Hill