The Waterfall Model of software development is by far the most widely known approach to creating software. As a popular section, included in introductory programming courses throughout the educational system, many would at least recall hearing about t…

In your original citation, Royce is clearly discussing problems with iteration (which he then goes on to suggest solutions for), not with the figure you show.

In your original citation, Royce is clearly discussing problems with iteration (which he then goes on to suggest solutions for), not with the figure you show.

They aren’t different.

Here’s the quote:

“Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.”

So he is in fact discussing the problem with Waterfall in general.

But thanks for the comment; you made me go look very closely. :)

They aren’t different.

Here’s the quote:

“Figure 3 portrays the iterative relationship between successive development phases for this scheme. The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.”

So he is in fact discussing the problem with Waterfall in general.

But thanks for the comment; you made me go look very closely. :)

I’m no supporter of the waterfall method but look at the paper again. The sentence you quote does not relate to that particular figure. It relates to discussion above the figure, which is illustrated by figure 3, not figure 2.

Please retract your post.

I’m no supporter of the waterfall method but look at the paper again. The sentence you quote does not relate to that particular figure. It relates to discussion above the figure, which is illustrated by figure 3, not figure 2.

Please retract your post.

http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

It’s essentially the same article I just did, but arguably much better. I like the angle of not elaborately describing and making diagrams of stuff you DON’T want people to do. :)

This guy has a cool blog, too. I’m subscribed as of now.

http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

It’s essentially the same article I just did, but arguably much better. I like the angle of not elaborately describing and making diagrams of stuff you DON’T want people to do. :)

This guy has a cool blog, too. I’m subscribed as of now.

The project manager I had to work with was around there for several decades, and ironically enough, even candidly admitted to me that in the past he was so stressed out in his job that he had a nervous breakdown.

Regardless, he outlined to me the methodology the government departments agreed upon using, and it was immediately apparent it was a slightly modified Waterfall (although at the time, I didn’t recognize Waterfall for how horrible it truly was). It wasn’t until after I returned to college that we covered Project Management, and I was glad to have the horrible first-hand experience of it.

Also, the manager was decent enough to let me tweak the schedule and stages of the plan to be iterative… and he himself showed a genuine interest in RUP because I think he actually started to glean the beauty of it and saw too many failed projects.

When I left my co-op job, I left him a copy of “UML Distilled: A Brief Guide to the Standard Object Modeling Language” :-P

The project manager I had to work with was around there for several decades, and ironically enough, even candidly admitted to me that in the past he was so stressed out in his job that he had a nervous breakdown.

Regardless, he outlined to me the methodology the government departments agreed upon using, and it was immediately apparent it was a slightly modified Waterfall (although at the time, I didn’t recognize Waterfall for how horrible it truly was). It wasn’t until after I returned to college that we covered Project Management, and I was glad to have the horrible first-hand experience of it.

Also, the manager was decent enough to let me tweak the schedule and stages of the plan to be iterative… and he himself showed a genuine interest in RUP because I think he actually started to glean the beauty of it and saw too many failed projects.

When I left my co-op job, I left him a copy of “UML Distilled: A Brief Guide to the Standard Object Modeling Language” :-P

First link (wikipedia): “Royce originally described what is now known as the waterfall model as an example of a method that he argued “is risky and invites failure”.”

Link 2 is a presentation that lists “Waterfall Process Limitations” and proposes RUP as better alternative. First benefit of RUP listed is “iterative process”

Link 3 is probably the most positive: “The traditional or waterfall methodology is the most universally known and understood of methodologies. We find it is most suitable for projects where the requirements are clearly stated and static or where it helps to have a rigid management structure.”

Link 4 is a presentation from OSCON 2001: “The waterfall model is a simplistic sequential model….The waterfall model is obviously targeted at commercial projects, and even there it doesn’t do terribly well.”

Next link is an “Agile Testing” blog: “I couldn’t help laughing at that point, and I told him that maybe that should have been a red flag concerning the validity of the Waterfall methodology. I couldn’t have found a better counter-example to Waterfall myself if I tried.”

So it is much harder to find a reference in favour of the Waterfall method than one that disparages it.

First link (wikipedia): “Royce originally described what is now known as the waterfall model as an example of a method that he argued “is risky and invites failure”.”

Link 2 is a presentation that lists “Waterfall Process Limitations” and proposes RUP as better alternative. First benefit of RUP listed is “iterative process”

Link 3 is probably the most positive: “The traditional or waterfall methodology is the most universally known and understood of methodologies. We find it is most suitable for projects where the requirements are clearly stated and static or where it helps to have a rigid management structure.”

Link 4 is a presentation from OSCON 2001: “The waterfall model is a simplistic sequential model….The waterfall model is obviously targeted at commercial projects, and even there it doesn’t do terribly well.”

Next link is an “Agile Testing” blog: “I couldn’t help laughing at that point, and I told him that maybe that should have been a red flag concerning the validity of the Waterfall methodology. I couldn’t have found a better counter-example to Waterfall myself if I tried.”

So it is much harder to find a reference in favour of the Waterfall method than one that disparages it.