The Spiral Model Incremental Waterfall Creative Commons License

  • Slides: 12
Download presentation
The Spiral Model Incremental Waterfall Creative Commons License – Curt Hill.

The Spiral Model Incremental Waterfall Creative Commons License – Curt Hill.

Introduction • This was first introduced to combine the best features of the waterfall

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 Creative Commons License – Curt Hill.

Four Phases • • Identification Design Build Risk Analysis Creative Commons License – Curt

Four Phases • • Identification Design Build Risk Analysis Creative Commons License – Curt Hill.

Diagram Creative Commons License – Curt Hill.

Diagram Creative Commons License – Curt Hill.

Identification • Starts with gathering the business requirements • In subsequent iterations there is

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 Creative Commons License – Curt Hill.

Design • Starts with the conceptual design in the first iteration • Subsequent spirals

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 Creative Commons License – Curt Hill.

Construct or Build • Refers to production of the actual software product at every

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 Creative Commons License – Curt Hill.

Evaluation and Risk Analysis • This includes identifying, estimating, and monitoring technical feasibility and

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 Creative Commons License – Curt Hill.

Reasons to Use • Budget constraints and risk evaluations are important • Medium to

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 Creative Commons License – Curt Hill.

Pros • Changing requirements can be accommodated • Allows for extensive use of prototypes

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 Creative Commons License – Curt Hill.

Cons Management is more complex. • • End of project may not be known

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 Creative Commons License – Curt Hill.

Finally • Has some of the aspects of waterfall and prototyping • Much greater

Finally • Has some of the aspects of waterfall and prototyping • Much greater risk consideration • Has much of the flavor of several agile methods Creative Commons License – Curt Hill.