Jump to content

Talk:Waterfall model: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
The waterfall: new section
Tags: Mobile edit Mobile web edit
Line 17: Line 17:


While the term "waterfall" certainly exists, none of the references on the page support that it was ever an actual project management approach. It seems to be nothing more than a pejorative term. A sort of bucket into which all bad project management approaches can be put. Is there any evidence that the "waterfall model" ever existed? [[User:Twasonasummersmorn|Twasonasummersmorn]] ([[User talk:Twasonasummersmorn|talk]]) 18:27, 6 March 2021 (UTC)
While the term "waterfall" certainly exists, none of the references on the page support that it was ever an actual project management approach. It seems to be nothing more than a pejorative term. A sort of bucket into which all bad project management approaches can be put. Is there any evidence that the "waterfall model" ever existed? [[User:Twasonasummersmorn|Twasonasummersmorn]] ([[User talk:Twasonasummersmorn|talk]]) 18:27, 6 March 2021 (UTC)

:Yes, it absolutely existed. I first started doing software development in the 1980's at Accenture (then Andersen Consulting). The SDLC we were all taught at the time was called Method/1 and it was a classic waterfall model. Ironically, I did a lot of research work for the DoD and we had to use the same methodology for research as all other DoD software developers did. I think it was called Mil Standard 2167a. In any case it was absolutely a waterfall model. In both cases we always filled out the required forms and made the required project plans and then essentially ignored them. One of my bosses had a great name for them: "Write Only Documentation" which was what they were. We did things using what is now called Agile because we just knew that was the better way to do it. [[User:MadScientistX11|MadScientistX11]] ([[User talk:MadScientistX11|talk]]) 19:46, 26 April 2023 (UTC)


Having looked more deeply at the references on this page, they're dreadful. Royce (the reference on which the whole article almost depends) does not say what he's supposed to have said in the referenced paper and the rest of the references are full of "some say". If no-one has better references I'm going to do a pretty tight cropping of the whole article. [[User:Twasonasummersmorn|Twasonasummersmorn]] ([[User talk:Twasonasummersmorn|talk]]) 20:41, 15 March 2021 (UTC)
Having looked more deeply at the references on this page, they're dreadful. Royce (the reference on which the whole article almost depends) does not say what he's supposed to have said in the referenced paper and the rest of the references are full of "some say". If no-one has better references I'm going to do a pretty tight cropping of the whole article. [[User:Twasonasummersmorn|Twasonasummersmorn]] ([[User talk:Twasonasummersmorn|talk]]) 20:41, 15 March 2021 (UTC)

Revision as of 19:46, 26 April 2023

Incorrect characterization

The statement "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified." is not a correct interpretation of what Royce wrote. In fact, he explicitly warns against this as "risky and invites failure". KeithC (talk) 22:14, 19 October 2020 (UTC)[reply]

Be bold and fix it then, but this is' the main problem with waterfall. Walter Görlitz (talk) 23:10, 19 October 2020 (UTC)[reply]

Does or did the waterfall model ever even exist?

While the term "waterfall" certainly exists, none of the references on the page support that it was ever an actual project management approach. It seems to be nothing more than a pejorative term. A sort of bucket into which all bad project management approaches can be put. Is there any evidence that the "waterfall model" ever existed? Twasonasummersmorn (talk) 18:27, 6 March 2021 (UTC)[reply]

Yes, it absolutely existed. I first started doing software development in the 1980's at Accenture (then Andersen Consulting). The SDLC we were all taught at the time was called Method/1 and it was a classic waterfall model. Ironically, I did a lot of research work for the DoD and we had to use the same methodology for research as all other DoD software developers did. I think it was called Mil Standard 2167a. In any case it was absolutely a waterfall model. In both cases we always filled out the required forms and made the required project plans and then essentially ignored them. One of my bosses had a great name for them: "Write Only Documentation" which was what they were. We did things using what is now called Agile because we just knew that was the better way to do it. MadScientistX11 (talk) 19:46, 26 April 2023 (UTC)[reply]

Having looked more deeply at the references on this page, they're dreadful. Royce (the reference on which the whole article almost depends) does not say what he's supposed to have said in the referenced paper and the rest of the references are full of "some say". If no-one has better references I'm going to do a pretty tight cropping of the whole article. Twasonasummersmorn (talk) 20:41, 15 March 2021 (UTC)[reply]

Still no satisfactory references on here. The article seems to be based on misquoting a few articles - generally from very long ago - and then claiming (without reference) that the "waterfall" approach so demonized in previous years as a counterpoint to Agile, existed. Twasonasummersmorn (talk) 15:34, 26 March 2021 (UTC)[reply]

Perhaps it's the question that is lacking. The "model" adjective is shorthand and synonymous with approach. Feel free to correct the term or make adjustments, but the tags of shame you've place are childish. Walter Görlitz (talk) 15:55, 26 March 2021 (UTC)[reply]

This definately exists, it's a recommended product development process by the FDA in https://www.fda.gov/media/116573/download linked from https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-control-guidance-medical-device-manufacturers. Poisonadder1 (talk) 09:21, 2 June 2021 (UTC)[reply]

That paper mentions waterfall, but doesn't recommend it. Nor does it give any reason to believe they're not just talking about something everyone seems to have heard of but perhaps never actually existed. Twasonasummersmorn (talk) 21:12, 9 October 2021 (UTC)[reply]

Seriously - this whole article is cantering around almost without any decent references. Should the whole page be just blanked out until some can be found? The ones I've found would indicate that the term is largely a bogey man term and that the method never actually existed. But I'm not sure they prove the negative either. Twasonasummersmorn (talk) 23:35, 2 January 2023 (UTC)[reply]

the article fails to explain most fundamental thing

waterfall on a timeline, as seen in project management application

the waterfall model exists on a timeline, it's not some random bunch of boxes in a drawing. i couldn't figure this out when i was first reading the article, thus, the article is quite worthless, because it fails to actually inform the reader of what the waterfall model actually means. this article doesn't look like it was written for encyclopedia. 5.184.25.166 (talk) 13:23, 17 October 2021 (UTC)[reply]

Waterfall project management

Waterfall model help to restraint required analysis and definitions on system and software development by implementing the specific units of testing and execution of operations and maintenance as itself shows to be cumbersome and liable to cause application delivery lag. 2405:201:C00F:60AF:251B:472B:6159:E14A (talk) 18:21, 19 December 2022 (UTC)[reply]

The waterfall model

Waterfall Model Description

Mannepallinaveen05@gmail.com The waterfall model

The waterfall model is a software development methodology that follows a linear, sequential approach. It is named after the way in which tasks flow, like a waterfall, from one phase to the next in a predetermined order. The waterfall model is also sometimes referred to as the "linear-sequential" model.

In the waterfall model, the development process is divided into distinct phases, each of which must be completed before moving on to the next. The phases of the waterfall model are:

1.Requirements gathering and analysis: In this phase, the project requirements are gathered and documented.

2. Design: In this phase, the system is designed based on the requirements gathered in the previous phase.

3.Implementation: In this phase, the code is written based on the design created in the previous phase.

4.Testing: In this phase, the system is tested to ensure it meets the requirements and functions correctly.

5.Deployment: In this phase, the system is deployed and made available for use.

6.Maintenance: In this phase, the system is maintained and any necessary updates or changes are made.

The waterfall model is a linear approach to software development and is well-suited to projects with well-defined requirements and a clear understanding of the problem to be solved. However, it can be inflexible and may not be the best choice for projects with rapidly changing or complex requirements 106.78.85.100 (talk) 11:25, 27 December 2022 (UTC)[reply]

Ehm...where's that from? Twasonasummersmorn (talk) 23:27, 2 January 2023 (UTC)[reply]

The waterfall

The waterfall model is a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.[1] The approach is typical for certain areas of engineering design. In software development,[1] it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.[2][better source needed] The waterfall model is the earliest SDLC approach that was used in software development.[citation needed]

The waterfall development model originated in the manufacturing and construction industries,[citation needed] where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process.[citation needed] When first adopted for software development, there were no recognized alternatives for knowledge-based creative work.[3][better source needed] 103.255.145.74 (talk) 14:15, 8 January 2023 (UTC)[reply]