Waterfall Methodology

The waterfall method attempts to structure development as a single sequence of non-overlapping heterogenous phases, the output of each being the input to the next. Typical phases are: analysis, design, code, test, deployment

A dangerous misunderstanding of Waterfall and other methodologies can be found here:

http://www.ncycles.com/e_whi_Methodologies.htm

Strengths cited are:

• Ease in analyzing potential changes
• Ability to coordinate larger teams, even if geographically distributed
• Can enable precise dollar budget
• Less total time required from Subject Matter Experts
  • Demonstrably false, as this is the slowest model to produce a working prototype and also requires the most paperwork.

Weaknesses cited are:

• Wildly inaccurate at predicting the impact and length of implementation, as it performs poorly at predicting all needs in advance.
• Since the coordination is mostly via paper, unlike, e.g. ExtremeProgramming, where you talk to the customer on a daily basis and developers pair coordinate, gross misunderstandings are guaranteed.
• Budget has no correlation to actuals.
• Projects invariably run over-scope, over-schedule, and over-budget; they require a much larger budget or adjustments thereto if the client wants to have their needs met.
• Increased total time required from Subject Matter Experts.
• Intangible knowledge gets lost between hand-offs.
• Lack of flexibility.
• Lack of team cohesion.
  • Not necessarily.
  • Designers often dictate to developers who are in a much better position to improve the design in cases of emergent design, yet often lack the clout to do so.
• Design flaws not discovered until the Testing phase
  • However, you can inspect the design during build
  • Design flaws that affect the underlying architecture often introduce large delays and waste that could have been much easily addressed is Agile methods

---

In the most strict interpretation WaterFall, it does no good to "inspect the design during build". The DesignPhase is over, there is no going back. If, during build, the design is found to be flawed, well, then what?

 Actually, I have always understood the waterfall flow to be like this:

 .-----------------------------+------------------+---------------------+----------------------------.
 |                             |                  |                     |                            |
 |                             |  not ok?         | not ok?             | not ok?                    |
 |   +--------------+     +----+---+     +--------+-------+     +-------+------+     +-------------+ |
 `-> | Requirements | --> | Design | --> | Implementation | --> | Verification | --> | Maintenance |-'
     +--------------+     +--------+     +----------------+     +--------------+     +-------------+

 The idea is, if written programmatically:

 10 R = REQUIREMENTS
 20 D = DESIGN(R)
 30 IF NOT OK(D) THEN GOTO 10
 40 I = IMPLEMENTATION(D)
 50 IF NOT OK(I) THEN GOTO 10   'Notice the target!
 60 V = VERIFY(I)
 70 IF NOT OK(V) THEN GOTO 10   'This would drive me batty...
 80 M = MAINTAIN(D, I, V)
 90 GOTO 10

Should this page be moved to, or combined with WaterFall, or WaterfallMethod, or WaterfallModel? Probably ought to be deleted once we've agreed whether the link has any value!

[Why deleted? Rebuttals have good value.]

Good rebuttals have good value. Saying "No" doesn't qualify as a good rebuttal.

---

The waterfall method structures development as a single sequence of non-overlapping heterogenous phases, the output of each being the input to the next. Typical phases are: analysis, design, code, test, deployment

The word 'phase' is a misnomer since every one of these overlaps with nearly every other at every stage of the software lifecycle. Coding almost always involves analysis, designing and testing.

---

CategoryApplicationDevelopment