Talk:Waterfall model/Archives/2013

Previous discussion...

In practice, the process rarely proceeds in a purely linear fashion. Iterations, by going back to or adapting results of the precedent stage, are common.

Would it be correct to state that this actually mutates the waterfall model into a spiral model? (and hence, waterfall method is *almost never* used in its "pure state"? ) 80.126.238.189 13:13, 15 Feb 2004 (UTC)

• In my opinion ... almost, but not quite. In the waterfall model, the end of each iteration is (supposedly) a fully-functional, deployable, saleable product. In the spiral model, the end of each iteration (except the last) is never intended to be fully-functional; it merely finishes the goals laid out for that particular iteration. Jim Huggins 04:40, 3 Apr 2005 (UTC)

POV check

This article seems to focusses on the disadvantages of the model, rather than explaining just what the model is. --huwr 01:28, 8 October 2005 (UTC)

It is recognized that the model does not work in reality and indeed it wasn't even proposed by Royce which as the article explains advocated iterative development. It has never been anything more than a straw man model. The only people who advocate anything like it are Dilbert's pointy haired boss and his real life counterparts. If the article simply presents the model without explaining the well known problems with it which are historically the very motivation for developing more workable approaches, this would be a violation of neutrality. I can't see why anyone would want to leave out the facts unless they are embarrassed by the fact that they themselves have been using a waterfall approach without knowing better. Kuratowski's Ghost 11:41, 18 October 2005 (UTC)

It might be nice to add some of the reasons why people think that BDUF and the waterfall model work "in theory" and then point out why they don't in practice. Maybe with some references to publications supporting this; would Parnas' "a rational design process (and how to fake it)" be suitable? There's no way a page on this could omit to mention that the waterfall model is widely regarded as fatally flawed though. :S GeorgeBills 03:58, 17 November 2005 (UTC)

I've added a lot of stuff to try and get in a better explanation of what waterfall actually is and explain the thinking behind it (and to try and clarify the objections raised against it for people who haven't heard this all before). Can someone please check over what I've written? Thanks. GeorgeBills 04:43, 17 November 2005 (UTC)

OK, I've just added a fair bit of work on what the waterfall method actually is, and arguments for it, including a supporting quote for BDUF from someone who gets a fair bit of respect in software circles (as far as I can see). I feel that both views on the waterfall models usefulness are now included, and that neither argument can be removed in the interests of NPoV. Maybe some clarification of points. As per Wikipedia:POV_check ("may be removed by anyone if they feel that the issue has been resolved") I'm going to delete the "PoV check" template. Feel free to argue here or replace it with a "NPoV" template if you feel that this was bad. GeorgeBills 12:58, 17 November 2005 (UTC)

NPOV violation - add pros

this article should first simply present what the methodology is. The negative aspects of this model should be listed but balanced with the positive, even if the positives are from circa 1970 and the negatives circa 1990. What it "is" should be the bulk of the article, the negative and positive should be a foot note.

That would make sense if it was a real methodology that was actually advocated by methodologists, but it isn't. "Waterfall" has always been used as a straw man example of how not to do software development, even Royce who coined the term never proposed such a methodology he proposed iterative development. It only occurs in practice by accident in companies that know little about formal methodologies in general but which try to institute formal processes and they typically don't know the term "Waterfall" or that their processes are doomed (although they quickly discover it). Kuratowski's Ghost 21:56, 28 October 2005 (UTC)

Unfortunately you are wrong, the "waterfall model" in the common use of the term (i.e. not the originally intended use) has only recently been recognized as being completely unsuitable for actual software development. In fact, it has been intentionally used, and is currently intentionally used. I've personally worked on projects that utilze it (one project in college and one project for with the government). Agile, iterative software development methodologies are having a difficult time gaining foothold because everyone "knows" that software should be designed once, then implemented. Entire university textbooks are written every year citing the waterfall (and similar methods of linear, monolithic, inflexible design methods) as being a "classic" methodology, and teach it in its misrepresented form. The fact of the matter is: the Waterfall Methodology as it is commonly perceived against the original intentions of W. W. Royce, is a *real* software engineering methodology, with a lot of history.

I don't know if you call 1989 "recently", but here is a refernce to a paper whose authors deeply believe that the Waterfall model of software development does not work: Floyd, C., Reisin, F.-M., Schmidt, G., STEPS to Software Development with Users., In: C. Ghezzi, J.A. McDermid (Eds.). ESEC '89, Lecture Notes in Computer Science no. 387. Berlin, Heidelberg: Springer, 1989. 48–64. -- Nevertheless, I do fear that many people still believe that the Waterfall model is the ideal model for software development that one should strive for. —Preceding unsigned comment added by 85.177.207.189 (talk) 16:40, 14 February 2008 (UTC)

I don't think college examples count; my university did the same thing, but that's not 'real usage' (by industry). But I'd be interested if anyone has any concrete evidence of experienced developers with a history of successful projects behind them actually choosing waterfall, or alternately projects that consciously chose waterfall and succeeded. Caveat: teams of at least 5 developers, more developers better, with project lengths of at least six months, more duration better. If someone has no clue how to do it, and says "oh, I'm doing the pinkrainbows methodology", that doesn't mean the pinkrainbows methodology page should talk about the postives balanced with the negatives. Articles about dysfunctions should talk about the dysfunction at a meta-level, about their role in society and why they exist. If, on the other hand, waterfall actually works for some significantly-difficult projects, then maybe there are some positives which could be discussed. --jholman (talk) 19:19, 9 November 2010 (UTC)

Still too POV

As an Extreme Programming practitioner and coach, I personally believe that the waterfall model is generally unworkable. However, quite a lot of people don't, and I don't think the article reflects that. For example, the phrase, "The waterfall model however is widely believed to be a bad idea in actual practice" seems overly strong to me. Ditto value-laden terms like "inflexible". The organization and writing are very good, though! --William Pietri 15:58, 17 November 2005 (UTC)

OK, made some changes but it might need more. I changed "The waterfall model however is widely believed to be a bad idea in actual practice" to "The waterfall model however is believed by many to be a bad idea in practice, mainly because of the belief that it is impossible to get one phase of a software products lifecycle "perfected" before moving on to the next phase (or at least, the belief that this is impossible for any non-trivial program)". Now it doesn't imply that everyone dislikes the waterfall model, just that many people believe that it isn't the best model available. I've added some counter-arguments to some of the criticisms of the waterfall model, and I've tried to make it more clear that many of the arguments for and against the waterfall model presented here are opinions. Thanks heaps for the help, it seems that it's hard to spot PoV when you don't realise that you're biased. :S Feel entirely free to jump in and correct me if I'm still not being NPoV enough. :D GeorgeBills 04:14, 18 November 2005 (UTC)

User "72.244.140.113"

Hi to "72.244.140.113".

You've just deleted a large chunk of text which could have remained in the article - I would kind of prefer it if you could have just moved it in order to remove the implication that Joel uses the waterfall model (edit summary was "It is extremely misleading to describe Joel Spolsky as a "user of the waterfall model.") For now I'll re-include the text somewhere other than under the heading "users of the waterfall model".

I also note for future reference that your only edits concern Joel Spolsky and projects managed and worked upon by Joel Spolsky. I'd like to ask that PoV be kept out of this, and the text be allowed to stay.

He has argued in favour of Big Design Up Front (see the quote you deleted...), and Big Design Up Front is what many people think is wrong with the waterfall model. :S Is there any way you would like this to be phrased? I'd like the quote to stay, because it's one of the few arguments in favour of Big Design Up Front, and this article needs them for NPoV. Thanks. GeorgeBills 15:48, 18 November 2005 (UTC)

OK, I've moved that text, added a new reference, and added some clarification to remove the mistaken implication (my bad) that Spolsky is a user of the waterfall model. GeorgeBills 16:05, 18 November 2005 (UTC)

Peer review, redux

I started out thinking I would do a copy edit, but the issues are bigger, so I'll just comment.

1. Wikipedia itself is a poorly chosen example of what is being specified and built. It's not quite a violation of "no self-references", but it is still going to be very unfriendly to anyone who wants to reuse the content. At the very least, this should be "an online encyclopedia". More likely, we should pick another example entirely.
2. Most of the criticisms are uncited.
3. If we are going to use phrases like "…followed perfectly in order…" (is that yours or Royce's?), we should make it clear that this is a "straw man" model.
4. While the spiral model is, indeed, an alternative, probably more relevant are the models that Steve McConnell (Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996, ISBN 1-55615-900-5) calls "modified waterfalls" (see especially p.143-147): Peter DeGrace's "sashimi model" (waterfall with overlapping phases), waterfall with subprojects, and (my own personal favorite) waterfall with risk reduction (living in the Pacific Northwest, I like to think of it as letting salmon jump up the waterfall and carry information: the volume of salmon will never be nearly as much as the volume of water, but, hey, information doesn't weigh much).

If you want to see my own writing on the topic (from a few years back), see [1], a whitepaper for a company I was helping through a transition on the tech side. -- Jmabel | Talk 20:09, 19 November 2005 (UTC)

OK, those are good points, thanks for the review.  :)

I was thinking that to fix them:

1. Change the Wikipedia example to an example based on another well known software program; in order for the "requirements explanation example" to work it needs to be something that most people recognize as having multiple components that seperate teams work on - maybe if we said the "Microsoft Office" project, with the "Word" and "Excel" teams needing to integrate their components? This might not be the right thing though, as Word and Excel could still work as seperate components. This example might not indicate how difficult it is to integrate example component pieces. :S What was that "baggage handling" program that had large integration problems? I seem to remember it being touted as an example of bad project management around three months ago...
2. Find citations - I think Parnas covers most of them, and Code Complete and some Agile / XP bibles might cover the others. I guess the counter-arguments need citing too, and they might be hard to find reputable references for given the academic stigma of arguing for the waterfall model. :S
3. Make this more clear, got it. Something like "in the so called "pure" waterfall model (Royces first example) people do this...however, there are various "modified" waterfall models (including Royces final model) that may include slight or major variations (see the modifed waterfall models section below)"
4. A modified waterfall models section, incorporating all of your examples. Some help here would be great, because you seem to be pretty well read on the topic. It probably has to come after the "criticisms" section because it might need to refer to it - as an example, we might need to write "the sashimi model handles criticisms x, y and z by blah blah blah". Unfortunately, if it comes after the criticism section people might think that we're biasing people against the modified models by dumping all of these criticisms on them before we cover models that the criticism may not apply to. :S

GeorgeBills 12:35, 20 November 2005 (UTC)

Essentially all modern methodologies are "modified waterfall", all agree that you have to have some sort of requirement first (e.g. user story in XP), some sort of design and then code and then a test (even if the unit test was developed before the code its applied after). Kuratowski's Ghost 14:44, 20 November 2005 (UTC)

Just included a modified waterfalls section; as per "Ghosts" comments, I've tried to make it clear that all models bear at least some similarity to the waterfall model, but that this article will only deal with the waterfall models closest neighbours. Everything else can be found under the software project lifecycle article. I'm not sure of my information on both "waterfall model with subprojects" and "waterfall model with risk reduction" as I'm going off google only on these two. :S Can someone look at these? I'll try and find some reputable books for checking when I get back from holidays... Actually, scratch that, I'm not going to include info I don't have a reasonable amount of confidence in. Can someone else who knows the exact meaning of these terms add and fill in the subheadings "the waterfall model with subprojects" and "the waterfall model with risk analysis" under the "modified waterfall models" section? Thanks. GeorgeBills 16:19, 20 November 2005 (UTC)

You don't need to find online sources for what I can cite from McConnell. If you get the rest of this in order, I'll gladly add that. -- Jmabel | Talk 04:14, 21 November 2005 (UTC)

Focus of article

• (I don't know where to put my comments!) This article puts forth a lot of solid info. Thanks! However the focus is constantly on what's wrong with the waterfall model... frankly, this author is not the right person to write this article. Lastly, the amount of 5th grade mistakes is just sad - grammar, capitalization, layout, clarity, typos.
• And finally, just as a "small world" side note, I worked with Joel Spolsky for the past two years. But that's not why I'm writing. It's just a small world.
• Okay one more thought! BDUF is only good for shrink wrappers (like Joel), anyone doing consulting or in-house work (i.e. anyone who has to listen to their clients) has to use an iterative approach. I didn't see this basic distiction in the article and I think it is essential and supports a more balanced POV. Dkalmar 22:37, 27 November 2005 (UTC)

Thanks for the comments Dkalmar. It would be great if you could add some more information, particular improving and expanding upon the arguments for the waterfall model if you feel the article is still biased. Fell free to fix any spelling or grammar mistakes you see too. :) GeorgeBills 09:20, 28 November 2005 (UTC)

Daily builds

The article remarks that daily builds are "a practice not used within the waterfall model." True engough, in a straw-man version of the model where (probably unlike any practice ever known in the history of computing) you completely build the system before you begin any verification. Carried to a logical extreme, one could imagine coding the whole system before attempting to compile. But, of course, no one ever does this. Daily builds are completely compatible with any reasonable real-world version of the waterfall model. To say that they are not would be like saying that someone doing Extreme Programming would never be allowed to go off for a couple of hours and think about a data structure. -- Jmabel | Talk 05:44, 7 December 2005 (UTC)

Dead Link

Noting that the link http://asd-www.larc.nasa.gov/barkstrom/public/The_Standard_Waterfall_Model_For_Systems_Development.htm was dead on May 04 2006. I may or may not be back after some time to update remove this. Someone more familiar with this page is invited to correct this. - Cullen

Kruchten Reference

This article by Kruchten lists some situations in which use of the Waterfall model is likely to be successful: Going Over the Waterfall with the RUP (See the paragraph titled "When Is a Waterfall Approach Suitable.") It is one of the few articles I have seen by an authoritative sources seems to at least grudgingly support the use of waterfall in some situations. However, I think in the corporate domain there are many software projects that meet the Kruchten's list of constraints, which may help explain why Waterfall continues to be widely used. --GFLewis 13:27, 9 July 2006 (UTC)

"Change of naming description"

The following was edited into the page by User:Iftikharzafar; I'm guessing he wants to start a discussion so I'm moving it here and notifying him on his talk page...

Inspite of the fact that I am interested in implementing this model in many of my projects, I still believe that name of this model should be modified in order to incorporate the changes in the new waterfall model. Waterfall can't come back after hitting ground to enough extent to be named in a case where we have fair bit of iteration involved. I just suggest that name should be rather Tennis Ball Modeling Method. Atleast, it sounds slightly more reasonable. <izafar@pitb.gov.pk>

Iterative = Waterfall ?

Hello, once I read the Waterfall and the Iterative methods and I understood that iterative method was equal or an specialization of a waterfall method. But, reading Agile method article, I found an ASCII diagram where iterative and waterfall methods are distinguished. What are the relation and differences between iterative and waterfall methods? I think it would help to add some additional information about it in waterfall and iterative method articles. —The preceding unsigned comment was added by 62.43.153.45 (talk • contribs) August 26, 2006.

Prob wrong in theory but right in practice, since I've seen, in real reality, Waterfall models with a lot of backloops and the whole bunch of steps bended into a V form. Those who use Waterfall that way, prob don't follow the initial philosophy, but yet peruse the conceptual steps and a rule chain that traffic concepts to grow modules in the allowed stream direction in the original Waterfall, i.e. much more like a waterfall than the original Waterfall. ... said: Rursus (^mbork³) 16:20, 21 November 2009 (UTC)

Iterative = Waterfall ? (v2)

Sorry, I am the "Iterative = Waterfall ?" writer. I got confused, the models that seem to be equal but have different names are iterative and spiral, not iterative and waterfall. —The preceding unsigned comment was added by 62.43.153.45 (talk • contribs) August 26, 2006.

what is a water fall model

what are the advantages of using waterfall model . which development model is more advantageous? {{subst:undigned|61.95.205.43|10 November 2006}}

The advantages are discussed in the article. As for "more advantageous": for what? The issue is to match an appropriate development lifecycle model to a particular project, not that one model will somehow be best for all projects. - Jmabel | Talk 21:48, 12 November 2006 (UTC)

Benington

In a Software Project Management book, the waterfall approach is described by the author as having its roots in "Production of Large Computer Programs" by H. D. Bennington in 1956. From what I understood, it not the term "Waterfall" but the aproach itself. I was not able to find the article so I could not confirm this. As anyone have any knowledge of this? Theups 14:22, 26 November 2006 (UTC)

Only that a quick Google turned up

• Bennington H D, Production of Large Computer Programs, Proc. Symp. on Advanced Computer Programs for Digital Computers, sponsored by ONR, June 1956, Republished in Annals of the History of Computing, Oct. 1983,350 - 361

A good computer science library should have the republished version; I don't know where you are geographically, so I don't have any specific recommendations. - Jmabel | Talk 23:57, 28 November 2006 (UTC)

I got a paper copy of the republication already in 90's (from the library of Helsinki University of Technology, which apparently qualifies as a good computer science library). Now I stumbled on this page and looked up both the paper copy and Google found it for me at http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf. I think this definitely should be in the article as well as the reference to SAGE. At least History of software engineering should also mention this. Marko (talk) 20:13, 21 March 2011 (UTC)

"Waterfall" misunderstood?

To me it seeems that the waterfall model has been misunderstood and teached wrong by quite a big audience(-including me). When thinking about the flow of actions in software development( and furthermore, any system development)-I just can't think of any other way to model the flow of actions in the development process than the one suggested by the waterfall model. To me the waterfall model does not seem a model that applies to only software systems-but any system development.

How could any other action of the waterfall be performed without taking the the previous action? Some examples:

• how would anyone be able to design and model something without knowing what is the problem/requirement? Just start drawing models and boxes without any context?
• what about implementation without design? Just open up some editor and start programming? Write a mixture of instructions mixing any programming languages you know? And not even knowing what the system should do eventually?
• How could something have a verification without knowing what it should do, having no design how the system would do it -and finally having nothing implemented?
• ...

Considering these issues, the waterfall model looks like a pretty perfect model.

I would separate the business and project management issues, which (as I nowadays see it...) has nothing to do with the waterfall model. I would consider that the project size, amount of requirements, the way of organizing work, overlapping the work of different subproject and phases, prioritizing requirements, etc, was never insisted or dominated by the waterfall model -these issues have been brought up by the people using the model for their purposes. Hmmm... maybe I'm suggesting that waterfall is not a process but a model about the actions that follow each other when developing systems. Putting it that way, all system development processes actually use the waterfall model

I was happy to find some similar thoughts in the links of the article: Conrad Weisert at http://www.idinews.com/waterfall.html:

There's no such thing as the Waterfall Approach!(and there never was)

Alistair Cockburn at http://members.aol.com/acockburn/papers/vwstage.htm:

For all that, it is safe to say that the subsystem does not ship without being validated, cannot be validated until it the bugs are removed, cannot be tested until it is built, cannot be built without design, is not designed without requirements.

I think this is one way waterfall could be understood nowadays: not as a process that tells how tho manage work and business -but a model about sequential actions in system development. KariJaakkoNiemi 10:40, 11 February 2007 (UTC)

Right, up to a point, but what characterizes the "waterfall" model is the emphasis on performing these phases sequentially, rather than moving back and forth in a more experimental and experiential manner. Imagine trying to build the first guitar by starting out specifying how you want it to sound (requirement); then indicating the technique of playing (functional specification); then determining exactly what type of wood you would need, how thick the strings should be, where the frets should be positioned etc. (technical specification); then building it (implementation); and only trying to make any sounds with it once it is finished (testing). - Jmabel | Talk 20:19, 3 March 2007 (UTC)

risky and invites failure

The "risky and invites failure" citation from Royce's paper is actually about an iterative approach, and not anything like the waterfall model. Do others agree? If so, the first paragraph should be changed. Yaxu 19:15, 8 April 2007 (UTC)

I removed a sentence accordingly. Yaxu 18:35, 11 April 2007 (UTC)

code monkeys

Wouldn't the word coder suffice as denoting someone specialized in coding (whereas the word programmer has conotations with design or at least is more general)? Is it just me or does anyone else find the term code monkey a little derogatory? Otherwise I propose the term "design orangutans". ;) Kuroboushi 12:45, 10 July 2007 (UTC)

Replaced as proposed. Kuroboushi 18:39, 11 July 2007 (UTC)

Contradiction in first paragraph

The last two sentences of the very first paragraph are contradictory (unbelievable!). The first states (or at least heavily implies) that the term "waterfall" was originated by Royce. The very next sentence states that he never used the term. It is hard to imagine how someone could have originated a term without ever using it. Perhaps he originated the idea rather than the term? I don't know which sentence is correct, but they can't both be correct without further explanation. -pgenty 198.81.125.18 17:37, 2 August 2007 (UTC)

Comments

Hello everyone, the following are my comments on the waterfall model. Waterfall model can only be applied to the systems that are developed from scratch. It has several disadvantages. For example, if the system's analyst fails to capture the customer requirements corretly, then this will have an impact on the following phases : Design, Implementation, Testing, and so on. --Wikiuser183 (talk) 18:56, 17 June 2008 (UTC)

"Waterfall model can only be applied to the systems that are developed from scratch." Line a new project on a green field? That's not true: faterfall can be used for continuous enhancementing repeatadly, even for already existyng SW, not from scratch.

"if the system's analyst fails to capture the customer requirements corretly, then this will have an impact on the following phases: Design, Implementation, Testing, and so on." Yes, that's the disadvantage of this methodology, but can be tamed, in practice. ...I am QA, so that's a piece of my everyday bread. ;) Franta Oashi (talk) 15:25, 29 June 2009 (UTC)

Origin?

"It should be readily apparent that the waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. Ironically, the use of the waterfall model for software development essentially ignores the 'soft' in 'software'."

I believe the whole paragraph above is not encyclopedic. First, I believe the waterfall model follows the basic problem solving approach. Secondly this whole paragraph seems to be supposition, with no references or citations. finally the whole 'soft' in 'software' part is presumptive and trite.

I will delete this paragraph next month unless it is adjusted to be more encyclopedic. Tee Owe (talk) 22:11, 12 April 2009 (UTC)

I agree with you on this. I was going to tag:fact this, but I noticed your comment. I will tag it with a note that the issue was opened for discussion and is pending removal. Gendut (talk) 01:25, 24 May 2009 (UTC)

Kissu Hoi nai, vandalism?

I have noticed there a new edit: "Kissu Hoi nai"... Is it a vandalism? Franta Oashi (talk) 15:17, 29 June 2009 (UTC)

Phases of waterfall modell wrong?

The waterfall model as described by Royce has the following phases (just like he describes them in his paper "Managing the development of large software systems"):

1. System Requirements
2. Software Requirements
3. Analysis
4. Program Design
5. Coding
6. Testing
7. Operations

I therefore think that all reference to Royce should cite the above model and the beginning of the Model chapter starts witha wrong citation. When you cite Rocye you have to use the model from his paper without changes, simplifications, etc. period. —Preceding unsigned comment added by 195.212.29.187 (talk) 13:22, 19 May 2010 (UTC)

This issue also annoyed me. The article cites Royce but doesn't IMHO quote "Managing the development of large software systems" correctly. Royce's paper illustrates several waterfall-like approaches (Royce's Figs. 2, 3 and 4), none of which appear here. The waterfall concept has evolved over time. One approach for handling this in the article might be to summarize Royce's original material followed by summaries of more recent viewpoints. Comments/critique? Conr2286 (talk) 00:25, 11 August 2010 (UTC)

An Apparent Agenda

Although there are some more-or-less objective parts to this article, most of it appears to be a straw-man presentation by someone (or perhaps multiple people) whose agenda is to denigrate the idea of designing software ahead of coding it. Consider the following paragraph:

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model: time spent early on making sure requirements and design are absolutely correct saves you much time and effort later. Thus, the thinking of those who follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before you proceed to the next phase. Program requirements should be set in stone before design begins (otherwise work put into a design based on incorrect requirements is wasted). The program's design should be perfect before people begin to implement the design (otherwise they implement the wrong design and their work is wasted), etc.

The word "absolutely" (used twice -- I took the liberty of removing one of them from the article itself, it's just left in here as it was when I found it) adds no information and has no real meaning. I submit it is there just to illustrate how inflexible and unreasonable those people are who advocate a period spent designing before any period spent coding.

Likewise, consider "The program's design should be perfect..." -- The only people I've ever heard use the term perfect to refer to software design are people who are trying to make it sound like an unreasonable thing to do.

I think the same people were helping with the article on software engineering: that used to say that the two most common software development methodologies were Waterfall and Agile; they didn't give a reference, which isn't surprising since the statement was patently false. But that's another article (which doesn't say that any more -- I changed it to list the 4 methods that have their own sections in Wikipedia's software methodology section).

I think it would be good if the article made clear that BDUF and Waterfall are not the same thing; that, in fact, doing a design phase before coding starts is one but not the primary characteristic of the Waterfall Model.

Does anyone have a reference of a major project that actually used an unmodified Waterfall Model for its development?

rc (talk) 20:51, 25 September 2010 (UTC)

agenda, or reality? I'm curious too!

I too am curious about your final question ("Does anyone have a reference of a major project that actually used an unmodified Waterfall Model for its development?").

If "pure waterfall" means Royce's parody of a no-feedback waterfall, then how could anyone ship a project like this? What happens if a problem is found during verification, the code is shipped anyway? So, when other writers (on this discussion page and elsewhere) say that people really do use waterfall, what are they talking about? This can't be right!

On the other hand, I agree with you that BDUF shouldn't be absolutely equated with "pure waterfall". BDUF might be the right approach for some systems (space vehicles seem to be a common and plausible example given, e.g. google for 'they write the right stuff'). And I'm sure it is used for lots of projects, correctly or not, some of which are probably even successful (perhaps in spite of BDUF).

I wonder if the key point here is that "pure waterfall" is arguable an endpoint on a continuum, and the endpoint is clearly undesirable and impossible (again, if there's no feedback from verification to implementation, why verify?), but that moving toward that endpoint along the continuum may be desired by some stakeholders (wisely or unwisely).

All that said, I almost feel like the article isn't sufficiently clear that pure waterfall is incoherent. If you're casting around for a methodology, putting pure waterfall on your list of options is not a sane move, any more than putting "get on knees and pray until software appears full-formed by divine intervention" is a sane option, and this is more than an opinion (isn't it? I'm experiencing POV-anxiety!).

--jholman (talk) 19:35, 9 November 2010 (UTC)

Royce 1970 citation

Not sure that the link to "Managing the Development of Large Software Systems" paper used in this wiki article is actually the original paper published in 1970. It looks to me that the destination document is in fact this one:

W. W. Royce. 1987. Managing the development of large software systems: concepts and techniques. In Proceedings of the 9th international conference on Software Engineering (ICSE '87). IEEE Computer Society Press, Los Alamitos, CA, USA, 328-338.

Check the pdf that is being opened from this link: http://portal.acm.org/citation.cfm?id=41801 —Preceding unsigned comment added by 194.80.32.8 (talk) 21:41, 16 November 2010 (UTC)

Shrink Wrap Software

The article currently contains a link to shrink wrap contract under the name "shrink wrap software" in the section "Supporting arguments" in the following sentence:

"It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that are stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started."

The article for shrink wrap contract, however, does not appear to explain what a "project with unchanging requirements" is. Since it seems that this might be a fairly important part of why someone might support the Waterfall Model, could someone add some information on this? (I myself don't know enough.) Raptortech97 (talk) 00:08, 3 April 2013 (UTC)