The Waterfall Model What It Is Not and Has Never Been

Transcription

1 The Waterfall Model What It Is Not and Has Never Been Dr. Peter Hantos The Aerospace Corporation 14th Annual NDIA Systems Engineering Conference, San Diego, California October 24-27, 2011 The Aerospace Corporation

2 Acknowledgements This work would not have been possible without the following: Reviewers Asya Campbell Suellen Eslinger Zane Faught Leslie Holloway Funding Source The Aerospace Corporation s Sustained Experimentation & Research Program 2

3 Outline Motivation Parsing the Title The Canonical Waterfall Model Model Characterization What Does the Waterfall Life Cycle Really Look Like? Clarifying the Model s Intent Hidden Concurrency in the Waterfall Incremental Integration and Pair-wise Testing Scaling Conclusion Acronyms References 3

4 Motivation Your first reaction might be Why are we talking about the waterfall? I thought that the Waterfall was dead Indeed, since the Waterfall model was published, the literature has been full with critiques and proposals for alternative processes, most recently Agile Development However, a substantial percentage of waterfall project failures can be attributed to lack of understanding of some fundamental issues, issues that are also present when modern methodologies are used Ignoring such issues will lead to project failure, regardless of the methodology that is used Also, the waterfall (or, a mini waterfall) is still an essential building block of all the more complex life cycle models, such as incremental, evolutionary, spiral, or iterative incremental development (IID) 4

5 Parsing the Title-1: Waterfall is a metaphor Glade Creek Spring Waterfalls 5

6 Parsing the Title-2: Model Definition of a model* A model is always a reproduction of an original system However, a model is an abstraction and does not reproduce all attributes of the original system Models serve a certain purpose and they are to be used in a certain context What we are going to do Start with the prevailing description of the Waterfall Model Highlight the hidden abstractions of the model Develop successively more complex descriptions to facilitate the understanding of underlying issues All models are wrong. Some models are useful. ~~~ George Box * [Stachowiak 1973] 6

7 The Canonical Waterfall Model* SRR PDR CDR Plans and requirements Product and unit Integration and Feasibility Organization and planning Software requirements Product s s Legend CDR critical review PDR product review SRR software requirements review Integration and Acceptance * [Boehm 1981] 7

8 Model Characterization SRR PDR CDR Plans and requirements Product and unit Integration and Feasibility Organization and planning Software requirements Product s s Legend CDR critical review PDR product review SRR software requirements review Integration and Acceptance Scaling: No Seems to depict a macro view of software development Depiction of feedback loops: No Depiction of concurrency: No Presence of other technical disciplines: No The product is software only 8

9 Hidden Feedback Loops SRR PDR CDR Plans and requirements Product and unit Integration and Feasibility Organization and planning Software requirements Product s Having feedback loops is a matter of reality* There are successive, small iteration feedbackloops between successive Legend steps CDR critical review The correction of defects discovered during PDR product review the final phases SRR requires software requirements review changes or ultimately, requirements changes The basic interpretation of the metaphor (one-directional flow) needs to be challenged s Integration and Acceptance * Based on [Royce 1970] 9

10 Phase Overlap Added the Sashimi Model* Overlap is suggested between phases This overlap can reduce belated problem discovery However, in most cases this is not really concurrency but iteration Correcting while coding is essentially iteration It was shown earlier that to deal with defects such small-scale iteration is inherently present in the Waterfall model * Source: [McConnell 1996]. Note his slightly more up-to-date terminology. 10

11 What Does the Waterfall Life Cycle Really Look Like? PDR CDR High-level Product and unit Integration and Product Integration and Feedback loops impact on the life cycle Activities don t neatly map into the life cycle phases anymore Diagram does not even show the impact of failed integration and regression s Length of the Integration and life cycle phase is becoming more uncertain Design rework Integration and Regression 11

12 Selected Name Changes to Clarify the Model s Intent SWRR SPDR SCDR Feasibility Software plans and requirements High-level * and unit Integration and Representative work products Some of the terminology in the original model is outdated or confusing Changes reflect that in this version of the model software is the product New phase and review names now clearly show that they relate to software These clarifications are helpful if we need to place the model in an 12 Organization and planning Software requirements Legend: DBDD Database Design Description IDD Interface Design Description IRS Interface Requirements Specification SCDR Software Critical Design Review SDD Software Design Description SDP Software Development Plan SPDR Software Preliminary Design Review SRS Software Requirements Specification SWRR Software Requirements Review High-level s acquisition or a software-intensive system development context -level work Integration and Acceptance SDP SRS/IRS SDD/IDD/DBDD * Note that in modern terminology high-level is replaced with architectural and the work product is Software Architecture Description (SAD)

13 Hidden Concurrency in the Waterfall Model SPDR SCDR High-level High-level and and unit unit Integration and level work represents independent and concurrent processes This is where the waterfall is a truly fitting metaphor The streams don t meet before hitting the pool at the bottom Note that SCDR positioning and content are ambiguous due to the fact that phase boundaries are now blurred 13 Integration and

14 Incremental Integration and Pair-wise* Testing SPDR SCDR High-level High-level and and unit unit Integration and Integration and Integration and Regression This strategy can reduce the problems stemming from belated problem discovery In terms of the metaphor, note the intermediate pools in the picture As a side-effect, phase boundaries are further blurred and the life cycle aspects of the model are less-and-less valid * Pairs should not be taken literally; multiple units can be integrated as well 14

15 Scaling As it was discussed, the model seems to be a macro-model However, the mentioned shortfalls are amplified if the process is indeed executed on the macro level Many of the problems can be dealt with if Incremental/Evolutionary strategies are used on the macro-level (including acquisition,) and Waterfall is applied only on lower levels For example, the following strategy hierarchy can be implemented in a space system Acquisition Once-through (Equivalent of the Waterfall) or Evolutionary System Incremental Development involving segments Segment Incremental Development involving elements Elements Incremental Development involving subsystems Subsystems Incremental Development involving Software Items Software Items* Waterfall Development involving Software s The requirements volatility problem stemming from requirements ambiguity can be mitigated via stronger requirements engineering processes such as prototyping * Larger software Items could be also incremental where each increment is a waterfall 15

16 Some Whimsical Remarks on Requirements The Waterfall Model assumes that the requirements can be determined with high-fidelity before actual development starts The mantra in real estate is Location, location, location The key to successful software development is Requirements, requirements, requirements Unfortunately, requirements volatility is a fact of life New, agile methodologies are ed to cope with the influx of new requirements we have come to value responding to change over following a plan * However, I still suggest listening to Yogi Berra: "If you don't know where you are going, you will wind up somewhere else" * Source: [Agile 2001] 16

17 Conclusion - The Experts Voice I believe in this [ wat erf all] concept, but the implementation is risky and invites failure ~~~ Winston Royce, 1970 [Iterative development] projects are not easier to set up, to plan, or to control just because they are iterative. The project manager will actually have a more challenging task, especially during his or her first iterative project, and most certainly during the early iterations of that project, when risks are high and early failure is possible. ~~~ Philippe Kruchten, 2000 Concurrency, scaling, and scope management are equally difficult problems in all methodologies 17

18 To Get Back to the Mood after the Q/A It winds along the face of a cliff This path which I long to explore, And over it dashes a waterfall, And the air is full of the roar And the thunderous voice of waters which sweep In a silver torrent over some steep. It clears the path with a mighty bound And tumbles below and away, And the trees and the bushes which grow in the rocks Are wet with its jeweled spray; From A Coloured Print by Shokei, by Amy Lowell 18

19 Acronyms CDR Critical Design Review DBDD Database Design Description IDD Interface Design Description IRS Interface Requirements Specification PDR Product Design Review SCDR Software Critical Design Review SAD Software Architecture Description SDD Software Design Description SDP Software Development Plan SPDR Software Preliminary Design Review SRR Software Requirements Review SRS Software Requirements Specification SWRR Software Requirements Review 19

20 References Agile 2001 Agile Alliance, Manifesto for Agile Software Development, 2001 Boehm 1981 Boehm, B., Software Engineering Economics, Prentice-Hall, 1981 McConnell 1996 McConnell, S., Rapid Development, Microsoft Press, 1996 Royce 1970 Stachowiak 1973 Royce, W. W., Managing the Development of Large Software Systems, Proc. IEEE WESCON, August 1970 Stachowiak, H., Allgemeine Modelltheorie (General Model Theory), Springer, Wien, New York,

21 Use of Trademarks, Service Marks and Trade Names Use of any trademarks in this material is not intended in any way to infringe on the rights of the trademark holder. All trademarks, service marks, and trade names are the property of their respective owners. Glade Creek Spring Waterfalls image is courtesy of ForestWander Nature Photography: (accessed August 24, 2011) Clip Art used on Slide 17 is courtesy of Open Clip Art Library: (accessed May 11, 2011) Poem passage on Slide 18 is courtesy of themargins.net: Lowell, A., A Dome of Many-Coloured Glass. (accessed September 9, 2011). Originally published by Boston: Houghton Mifflin, Reprint, New York: AMS,