The Waterfall Methodology It was the best of methods, it was the worst of methods. Copyright © 2015-2016 Curt Hill

Waterfall Model This is a classic engineering model Predates software engineering in its use by other engineering disciplines Consider the construction of a building for a business Copyright © 2015-2016 Curt Hill

A Building Consider what is needed, what is wanted and what can be afforded Always a compromise Architect the building Construct the building from the plans Furnish the building Occupy the building Copyright © 2015-2016 Curt Hill

Commentary In the building approach each of the steps is finished before the next one is started We do not redesign the building after construction is done It requires that each step gets it right before proceeding In software development this is called the waterfall model or linear sequential model Copyright © 2015-2016 Curt Hill

Operation & Maintenance Waterfall Model Requirements Design Unit Implementation System Integration Operation & Maintenance Copyright © 2015-2016 Curt Hill

Waterfall Model A sequential process Several phases Each largely completes before the next one starts There may be some overlap Backing up is expensive – it throws away work already done Copyright © 2015-2016 Curt Hill

Adaptation This technique works rather well for building and heavy manufacturing Thus it was adapted to software engineering rather early The term first appears in an 1976 paper although the model appears before this In 1985 DOD required a process that included these steps: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing Copyright © 2015-2016 Curt Hill

The Original Phases System and software requirements Analysis Design A product requirements document Analysis Models, schema, and business rules Design Software architecture Coding Development, unit testing and integration Testing System debugging Operations Installation, support, and maintenance Copyright © 2015-2016 Curt Hill

Incorrect Assumptions Constructing a building is much different than constructing software Building construction has been fairly well understood for centuries Seldom hear: Never heard of anything like that before Physics makes backing up difficult Many software development projects are knowledge acquisition projects We do not know what we are getting into Copyright © 2015-2016 Curt Hill

A Thought Experiment Think about a steel frame building like the Empire State Building Now we cut out one of the corner pillars In a building this is preposterous In software it is reasonable We do it all the time This illustrates one of the serious differences between building and software construction Copyright © 2015-2016 Curt Hill

Waterfall Problems Works better for very large projects Must have solid managerial support There should be no technical questions that have not been answered Many such projects are canceled before rolling out the product Complete loss of investment The volatility of requirements is fatal Technical debt accumulates and is not visible until late in the project Copyright © 2015-2016 Curt Hill

Technical Debt Technical debt refers to the eventual consequences of any system design AKA design debt or code debt Unfinished work that is required by a design Most often seen in projects that are released early Like financial debt this accrues interest making changes more difficult later Prevents or makes more difficult enhancements Copyright © 2015-2016 Curt Hill

Waterfall Debt We do not see the problems early enough Requirements were insufficient Design was poor Early code was not good These problems come home to roost at the end of the project This is when it is most difficult to change Copyright © 2015-2016 Curt Hill

Times Have Changed If it is worth doing it is worth doing wrong until you figure out how to do it right In the early days this was the best we knew how to do The types of projects were often more compatible with this model However, now only about 18% of real world projects are using Waterfall Copyright © 2015-2016 Curt Hill

In Contrast This method is very linear This is a problem that many approaches have attempted to deal with The notion is that unlike a building a software system evolves This gives rise to incremental and evolutionary approaches These produce a sequence of usable systems Each more complete than the previous Copyright © 2015-2016 Curt Hill

When to use Requirements are very well documented, clear and fixed No ambiguous requirements Product definition is stable Technology is understood and is not dynamic Ample resources with required expertise are available to support the product The project is short Copyright © 2015-2016 Curt Hill

Pros Easy to understand and use Easy to manage Phases are completed one at a time Works well for smaller projects where requirements are very well understood Clearly defined stages Well understood milestones Easy to arrange tasks Process and results are well documented Copyright © 2015-2016 Curt Hill

Lots of Cons No working software is produced until late Plenty of risk and uncertainty Poor model for long and ongoing projects Poor where requirements are at a moderate to high risk of changing It is difficult to measure progress within stages Copyright © 2015-2016 Curt Hill

More Cons Cannot accommodate changing requirements Adjusting scope during the life cycle can end a project Integration is done as a "big-bang. at the very end Does not allow identifying technological or business bottleneck or challenges early Copyright © 2015-2016 Curt Hill

Historical Analogy The first high level language was FORTRAN in the late 1950s Every language that came out in the 1960s was intended to do things better than FORTRAN Similarly Waterfall was the first methodology for software development Most of what followed tries to correct a perceived flaw in it Copyright © 2015-2016 Curt Hill

Finally The Waterfall methodology does well only with good specifications, good design and solid organizational support Software development organizations should only use this in cases of unusual stability Finally for now Copyright © 2015-2016 Curt Hill