Iterative Waterfall model + prototyping

As the primary goal of iterative waterfall model approach is rapid development. The design of the system can sometimes suffer because the system is built in a series of layers without a global consideration of the integration of all other components.

I am keeping blank miscellaneous database fields in database design of first module, which are replaced by entities of second module when I complete analysis of second module and so on.

I do not want to follow extreem programming concepts and traditional waterfall model. I am more interested in Iterative scheama of waterfall model with prototyping method


Is there any better option to mitigate this risk?

Hemang Joshi
Friday, April 30, 2004

must be exam time again.

mitigate the risk?  depends what you mean...its not so much as a risk as a certainty, there will definitely be changes and those changes will definitely result in people wishing that a different initial design had been chosen.

You can lower the pain by using your experience to plan ahead for the possibilities of design change.

but if you do that to much you end up designing for possibilities which will never occur.

So use your experience to avoid that trap as well.

eventually you will have to redesign some anyway, but with experience you can lessen the affect.

FullNameRequired
Friday, April 30, 2004

Suggestion: Read the essay "Plan to throw one away" in Mythical Man Month by Fred Brooks.

Matt H.
Friday, April 30, 2004

Actually, one of the big threats under the original waterfall model was the project drifting on an on from where the customer/client would like it to be.

With an interative waterfall method, rapid prototyping is the result, but the goal is to demonstrate to the customer/client that "this is what we think we heard you said, is it correct?"

This has some huge power...  think of the Titanic:
*  If the captain had turned a few hundredths of a degree a hundred miles before, no problem.
*  If the captain had turned a few tenths of a degree a few miles before, no problem.
*  If the captain had turned a few degrees a few hundred feet before, no problem.

By the time the iceberg was seen, there was no possible way to avoid it.

This is what rapid prototpying/iterative water/extreme programming/etc are meant to avoid.

KC
Friday, April 30, 2004

You say that the risk is "no global consideration of the integration of all other components" ... I think that the opposite is true: with a spiral lifecycle, you are integrating early and often.

You integrate at the end of every iteration. And, you begin each iteration (design the next component) from the basis of how this next component will fit in with what you have already completed.

So, it seems to me that it's the waterfall model, not the iterative model, that suffers ... in the waterfall model, although you may have "considered" integration, there is no real integration until the end when everything is completed (what they call "Big Bang integration").

Christopher Wells
Friday, April 30, 2004

IMHO the 'Iterative Waterfall' doesn't mean much. The whole point of the waterfall model is that stuff is not supposed to flow back up. You fix the requirements at each stage and move on 'knowing' that you are working on a fixed baseline. Now in reality, that doesn't happen and that is why the waterfall is discredited somewhat.

An iterative waterfall is, in fact, a set of rapids, with lots of backfloes and interconnected eddies. Anyone who has worked on a so-called waterfall model project where big chunks have late requirements will know what I mean. You avoid your big rock and think you are in clear water, when an eddy slaps you right back into the maelstrom.

Iterative prototypes make more sense. I can deal with that. Personally, I like sashimi.

WoodenTongue
Friday, April 30, 2004

  Recent Topics

  Fog Creek Home