Content deleted Content added
ClueBot NG (talk | contribs) m Reverting possible vandalism by 1.22.240.6 to version by Vrenator. False positive? Report it. Thanks, ClueBot NG. (993658) (Bot) |
Rescuing 3 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
| (709 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{Short description|Modelling software development in sequential phases}}
{{Update|date=October 2021}}
{{EngvarB|date=January 2023}}
The '''waterfall model''' is the process of performing the typical [[software development life cycle]] (SDLC) phases in [[sequence|sequential]] order. Each phase is completed before the next is started, and the result of each phase drives subsequent phases.<ref name=:0/> Compared to alternative SDLC methodologies, it is among the least iterative and flexible,<ref name=:0>{{Cite book|last1=Petersen|first1=Kai|last2=Wohlin|first2=Claes|last3=Baca|first3=Dejan|title=Product-Focused Software Process Improvement |chapter=The Waterfall Model in Large-Scale Development |date=2009|editor-last=Bomarius|editor-first=Frank|editor2-last=Oivo|editor2-first=Markku|editor3-last=Jaring|editor3-first=Päivi|editor4-last=Abrahamsson|editor4-first=Pekka|chapter-url=http://urn.kb.se/resolve?urn=urn:nbn:se:bth-8073|series=Lecture Notes in Business Information Processing|volume=32 |language=en|___location=Berlin, Heidelberg|publisher=[[Springer Science+Business Media|Springer]]|pages=386–400|doi=10.1007/978-3-642-02152-7_29|bibcode=2009pfsp.book..386P |isbn=978-3-642-02152-7}}</ref> as progress flows largely in one direction (like a [[waterfall]]) through the phases of conception, [[requirements analysis]], [[Software design| design]], [[Software construction| construction]], [[Software testing| testing]], deployment, and [[software maintenance| maintenance]].<ref>
{{cite journal
|author=[[Tom Gilb]]
|title=Evolutionary Delivery versus the "waterfall model"
|journal=ACM SIGSOFT Software Engineering Notes
|date=1985
|volume=10
|issue=3
|pages=49–61
|doi=10.1145/1012483.1012490}}
{{open access}}
</ref>
<!--
<ref>{{Cite web|title=The Traditional Waterfall Approach|url=https://www.umsl.edu/~hugheyd/is6840/waterfall.html|access-date=2022-02-23|website=www.umsl.edu}}</ref>
{{better source needed|date=January 2023|reason=The page referenced is a personal page from a university website with a big disclaimer at the bottom that it's not endorsed by the university.}}
-->
The waterfall model is the earliest SDLC methodology.<ref>
{{cite book
|author=Linda Sherrell
|chapter=Waterfall Model
|title=Encyclopedia of Sciences and Religions
|editor1=A. L. C. Runehov
|editor2=L. Oviedo
|date=2013
|pages=2343–2344
|publisher=[[Springer Science+Business Media|Springer]]
|___location=[[Dordrecht]], The Netherlands
|doi=10.1007/978-1-4020-8265-8_200285
|isbn=978-1-4020-8264-1
}}</ref>
<!--
{{Citation needed|date=January 2023|reason=That's a very specific claim. Needs a reference.}}
-->
When first adopted, there were no recognized alternatives for knowledge-based creative work.<ref>
{{cite conference
|title=Designing for knowledge maturing: from knowledge-driven software to supporting the facilitation of knowledge development
|author1=Andreas P. Schmidt
|author2=Christine Kunzmann
|conference=i-KNOW '14: Proceedings of the 14th International Conference on Knowledge Technologies and Data-driven Business
|date=September 16, 2014
|issue=10
|pages=1–7
|doi= 10.1145/2637748.2638421
|publisher=[[Association for Computing Machinery|ACM]]
}}</ref>
==History==
The first known presentation describing the use of such phases in software engineering was held by Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956.<ref>{{Citation |publisher=Office of Naval Research, Dept. of the Navy |___location=[Washington, D.C.] |title=Symposium on advanced programming methods for digital computers |author=United States, Navy Mathematical Computing Advisory Panel |date=29 June 1956 |oclc=10794738 }}</ref>
This presentation was about the development of software for [[Semi Automatic Ground Environment|SAGE]]. In 1983, Benington republished his paper with a foreword explaining that the phases were on purpose organized according to the specialization of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.<ref name="benington">{{cite journal |last=Benington |first=Herbert D. |title=Production of Large Computer Programs |journal=IEEE Annals of the History of Computing |date=1 October 1983 |volume=5 |issue=4 |pages=350–361 |doi=10.1109/MAHC.1983.10102 |publisher=IEEE Educational Activities Department |s2cid=8632276 |url=http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |access-date=2011-03-21 |archive-date=2011-07-18 |archive-url=https://web.archive.org/web/20110718084251/http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf |url-status=dead }}</ref>
{{better source needed|date=March 2021|reason=the referenced article neither uses the term waterfall nor describes that there was only one recognized way of developing software}}
Although the term "waterfall" is not used in the paper, the first formal, detailed diagram of the process is often<ref>{{cite journal |last1=Larman |first1=Craig |last2=Basili |first2=Victor |title=Iterative and Incremental Development: A Brief History |journal=Computer |date=June 2003 |volume=36 |issue=6 |pages=47–56 |doi=10.1109/MC.2003.1204375 |url=https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf}}</ref> cited as coming from a 1970 article by [[Winston W. Royce]].<ref name="royce">{{Citation |surname=Royce |given=Winston |title=Managing the Development of Large Software Systems |journal=Proceedings of IEEE WESCON |volume=26 |issue=August | year=1970 | pages=1–9 |url=https://dl.acm.org/doi/pdf/10.5555/41765.41801 }}</ref><ref>{{cite web | url=http://www.informatik.uni-bremen.de/uniform/vm97/def/def_w/WATERFALL.htm | title=Waterfall | website=Bremen University - Mathematics and Computer Science | access-date=2021-04-15 | archive-date=2022-01-19 | archive-url=https://web.archive.org/web/20220119095730/http://www.informatik.uni-bremen.de/uniform/vm97/def/def_w/WATERFALL.htm | url-status=dead }}</ref><ref>{{Cite book|last1=Abbas|first1=Noura|last2=Gravell|first2=Andrew M.|last3=Wills|first3=Gary B.|title=Agile Processes in Software Engineering and Extreme Programming |chapter=Historical Roots of Agile Methods: Where Did "Agile Thinking" Come From? |date=2008|editor-last=Abrahamsson|editor-first=Pekka|editor2-last=Baskerville|editor2-first=Richard|editor3-last=Conboy|editor3-first=Kieran|editor4-last=Fitzgerald|editor4-first=Brian|editor5-last=Morgan|editor5-first=Lorraine|editor6-last=Wang|editor6-first=Xiaofeng|chapter-url=https://eprints.soton.ac.uk/266606/1/xp2008camera_ready.pdf|series=Lecture Notes in Business Information Processing|volume=9 |language=en|___location=Berlin, Heidelberg|publisher=[[Springer Science+Business Media|Springer]] |pages=94–103|doi=10.1007/978-3-540-68255-4_10|isbn=978-3-540-68255-4}}</ref> However, he commented that it had major flaws stemming from how testing only happened at the end of the process, which he described as being "risky and [inviting] failure".<ref name="royce" /> The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach.<ref name="royce" /> Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.<ref>Conrad Weisert, [http://www.idinews.com/waterfall.html Waterfall methodology: there's no such thing!]</ref><ref name=":inheriting_agile">{{cite book |last1=Lineberger |first1=Rob |title=Inheriting Agile: The IT Practitioner's Guide to Managing Software Development in a Post-Agile World |date=Apr 25, 2024 |publisher=Sandprint Press |___location=Durham, NC |isbn=9798989149605 |page=36 |url=https://books.google.com/books?id=kTit0AEACAAJ}}</ref>
The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer.<ref>Bell, Thomas E., and T. A. Thayer.[[iarchive:software_requirements_are_they_really_a_problem|Software requirements: Are they really a problem?]] ''Proceedings of the 2nd international conference on Software engineering.'' IEEE Computer Society Press, 1976.</ref>{{better source needed|date=March 2021|reason=may have been? The use of a term in a paper doesn't mean it was the first use of the term.}}
In 1985, the [[United States Department of Defense]] adopted the waterfall model in the [[DOD-STD-2167]] standard for working with software development contractors. This standard referred for iterations of a software development<ref name=":1">{{Cite book |title=DOD-STD-2167 - Military Standard : Defence System Software Development" |date=1985-06-04 |publisher=Department of Defence, United States of America |pages=11}}</ref> to "''the sequential phases of a software development cycle''" and stated that "''the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing''".<ref name=":1" /><ref>{{Cite web|url=http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf|title=Military Standard Defense System Software Development}}</ref>
==Phases==
The model describes a linear sequence of steps. Although various different versions can be found, the following describes the essence.<ref name="US DJ03">US Department of Justice (2003). [https://www.justice.gov/archive/jmd/irm/lifecycle/table.htm INFORMATION RESOURCES MANAGEMENT] Chapter 1. Introduction.</ref><ref name="EverettSoftware07">{{cite book |chapter-url=https://books.google.com/books?id=z8UdPmvkBHEC&pg=PA29 |chapter=Chapter 2: The Software Development Life Cycle |title=Software Testing: Testing Across the Entire Software Development Life Cycle |author=Everatt, G.D. |author2=McLeod, R Jr |publisher=John Wiley & Sons |pages=29–58 |year=2007 |isbn=9780470146347}}</ref><ref>{{cite web |url=http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle |title=QuickStudy: System Development Life Cycle |first=Russell |last=Kay |date=May 14, 2002 |work=ComputerWorld}}</ref><ref name="TaylorIntro08">{{cite book |url=https://books.google.com/books?id=gqpZDNc5_Y4C&pg=SA12-PA6 |title=Introduction to Logistics Engineering |author=Taylor, G.D. |publisher=CRC Press |pages=12.6–12.18 |year=2008 |isbn=9781420088571}}</ref>
=== Preliminary analysis ===
Conduct with a preliminary analysis, consider alternative solutions, estimate costs and benefits, and submit a preliminary plan with recommendations.
:* Conduct preliminary analysis: Identify the organization's objectives and define the nature and scope of the project. Ensure that the project fits with the objectives.
:* Consider alternative solutions: Alternatives may come from interviewing employees, clients, suppliers, and consultants, as well as competitive analysis.
:* Cost-benefit analysis: Analyze the costs and benefits of the project.
=== Systems analysis, requirements definition ===
Decompose project goals{{Clarify|reason=Where did the goals come from?|date=January 2023}} into defined functions and operations. This involves gathering and interpreting facts, diagnosing problems, and recommending changes. Analyze end-user information needs and resolve inconsistencies and incompleteness:<ref>{{cite book|title=Information Systems Control and Audit |url=https://resource.cdn.icai.org/48513bos30870-sm-cp5.pdf |publisher=Institute of Chartered Accountants of India|chapter=Chapter 5|page=5.28|date=August 2013}}</ref>
:* Collect facts: Obtain end-user requirements by document review, client interviews, observation, and questionnaires.
:* Scrutinize existing system(s): Identify pros and cons.
:* Analyze the proposed system: Find solutions to issues and prepare specifications, incorporating appropriate user proposals.
=== Systems design ===
At this step, desired features and operations are detailed, including screen layouts, [[business rule]]s, [[process flow diagram|process diagram]]s, [[pseudocode]], and other deliverables.
=== Development ===
Write the code.
=== Integration and testing ===
Assemble the modules in a testing environment. Check for errors, bugs, and interoperability.
=== Acceptance, installation, deployment ===
Put the system into production. This may involve training users, deploying hardware, and loading information from the prior system.
=== Maintenance ===
Monitor the system to assess its ongoing fitness. Make modest changes and fixes as needed. To maintain the quality of the system. Continual monitoring and updates ensure the system remains effective and high-quality.<ref>{{cite web |last1=Shah |first1=Kazim |title=The Maintenance Phase Of Software Development Life Cycle |url=https://www.primetechnologiesglobal.com/blog/maintenance-phase-of-software-development-life-cycle |website=primetechnologiesglobal |publisher=kazim shah |access-date=12 May 2024}}</ref>
=== Evaluation ===
The system and the process are reviewed. Relevant questions include whether the newly implemented system meets requirements and achieves project goals, whether the system is usable, reliable/available, properly scaled and fault-tolerant. Process checks include review of timelines and expenses, as well as user acceptance.
=== Disposal ===
At end of life, plans are developed for discontinuing the system and transitioning to its replacement. Related information and infrastructure must be repurposed, archived, discarded, or destroyed, while appropriately protecting security.<ref>{{cite web |last=Radack |first=S. |date=n.d. |title=The system development life cycle (SDLC) |url=https://csrc.nist.rip/publications/nistbul/april2009_system-development-life-cycle.pdf |publisher=National Institute of Standards and Technology}}</ref>
==Supporting arguments==
Time spent early in the software production cycle can reduce costs at later stages. For example, a problem found in the early stages (such as requirements specification) is cheaper to fix than the same bug found later on in the process (by a factor of 50 to 200).<ref name="rapid">{{cite book |last=McConnell |first=Steve |title=Rapid Development: Taming Wild Software Schedules |publisher=Microsoft Press |year=1996 |isbn=1-55615-900-5 |url=https://archive.org/details/rapiddevelopment00mcco }}</ref>
In common practice, waterfall methodologies result in a project schedule with 20–40% of the time invested for the first two phases, 30–40% of the time to coding, and the rest dedicated to testing and implementation. With the project organization needing to be highly structured, most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project.<ref>{{ cite web |title=Waterfall Software Development Model |url=http://www.oxagile.com/company/blog/the-waterfall-model/ |access-date=11 August 2014 |date=5 February 2014 }}</ref>{{failed verification|date=March 2021}}
A further argument supporting the waterfall model is that it places emphasis on documentation (such as requirements documents and design documents) as well as [[source code]].{{Citation needed|date=March 2021|reason=Who argues this?}} In less thoroughly designed and documented methodologies, knowledge is lost if team members leave before the project is completed, and it may be difficult for a project to recover from the loss. If a fully working design document is present (as is the intent of [[big design up front]] and the waterfall model), new team members and new teams should be able to familiarise themselves to the project by reading the documents.<ref>{{ cite news |author=Arcisphere technologies |title=Tutorial: The Software Development Life Cycle (SDLC) |url=http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-LifeCycle-SDLC.pdf |year=2012 |access-date=2012-11-13 }}</ref>
The waterfall model provides a structured approach; the model itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand. It also provides easily identifiable milestones in the development process, often being used as a beginning example of a development model in many software engineering texts and courses.<ref>{{ cite web |last=Hughey |first=Douglas |title=Comparing Traditional Systems Analysis and Design with Agile Methodologies |url=http://www.umsl.edu/~hugheyd/is6840/waterfall.html |publisher=University of Missouri – St. Louis |access-date=11 August 2014 |date=2009}}</ref>
Similarly, simulation can play a valuable role within the waterfall model.<ref>{{Cite journal |last1=Saravanos |first1=Antonios |last2=Curinga |first2=Matthew X. |date=December 2023 |title=Simulating the Software Development Lifecycle: The Waterfall Model |journal=Applied System Innovation |language=en |volume=6 |issue=6 |pages=108 |doi=10.3390/asi6060108 |doi-access=free |issn=2571-5577|arxiv=2308.03940 }}</ref> By creating computerized or mathematical simulations of the system being developed, teams can gain insights into how the system will perform before proceeding to the next phase. Simulations allow for testing and refining the design, identifying potential issues or bottlenecks, and making informed decisions about the system's functionality and performance.
==Criticism==
Clients may not know the exact requirements before they see working software and thus change their requirements further on, leading to redesign, redevelopment, and retesting, and increased costs.<ref>{{cite journal |last1=Parnas |first1=David L. |last2=Clements |first2=Paul C. |title=A rational design process: How and why to fake it |journal=IEEE Transactions on Software Engineering|date=1986 |issue=2 |pages=251–257 |doi=10.1109/TSE.1986.6312940 |s2cid=5838439 |url=https://www.cs.tufts.edu/~nr/cs257/archive/david-parnas/fake-it.pdf |access-date=2011-03-21}}</ref>
Designers may not be aware of future difficulties when designing a new software product or feature, in which case revising the design initially can increase efficiency in comparison to a design not built to account for newly discovered constraints, requirements, or problems.<ref>{{cite book |last=McConnell |first=Steve |title=Code Complete, 2nd edition |publisher=Microsoft Press |year=2004 |isbn=1-55615-484-4 |url=https://archive.org/details/codecompleteprac00mcco }}</ref>
Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between [[systems analysis]] and programming,<ref>{{cite book|last=Ensmenger|first=Nathan|year=2010|title=The Computer Boys Take Over|url=https://archive.org/details/computerboystake00ensm|url-access=limited|isbn=978-0-262-05093-7|page=[https://archive.org/details/computerboystake00ensm/page/n50 42]|publisher=MIT Press }}</ref> as implementing any non-trivial system will often expose issues and edge cases that the systems analyst did not consider.
Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with [[MIL-STD-498]] released in 1994, which encourages ''evolutionary acquisition'' and ''[[iterative and incremental development]]''.<ref>{{cite journal |last1=Larman |first1=Craig |last2=Basili |first2=Victir |title=Iterative and Incremental Development: A Brief History |journal=IEEE Computer |year=2003 |edition=June |url=http://doi.ieeecomputersociety.org/10.1109/MC.2003.1204375 |doi=10.1109/MC.2003.1204375 |volume=36 |issue=6 |pages=47–56|s2cid=9240477 |url-access=subscription }}</ref>
==Modified waterfall models==
In response to perceived problems with the original, pure waterfall model, many modified versions have been devised to address the problems. These include the rapid development models that [[Steve McConnell]] calls "modified waterfalls":<ref name=rapid/> Peter DeGrace's "sashimi model" (waterfall with overlapping phases), waterfall with subprojects, and waterfall with risk reduction. Other [[software development model]] combinations such as "incremental waterfall model" also exist.<ref>{{cite web
| title=Methodology:design methods
| url=http://myprojects.kostigoff.net/methodology/development_models/development_models.htm
| access-date=2018-05-16
| archive-date=2016-03-03
| archive-url=https://web.archive.org/web/20160303215053/http://myprojects.kostigoff.net/methodology/development_models/development_models.htm
| url-status=dead
}}</ref>
[[File:1970_Royce_Managing_the_Development_of_Large_Software_Systems_Fig10.PNG|thumb|Royce final model]]
Royce's final model illustrated that feedback could (should, and often would) lead from code testing to design (as testing of code uncovered flaws in the design) and from design back to requirements specification (as design problems may necessitate the removal of conflicting or otherwise unsatisfiable/undesignable requirements).{{Citation needed|date=March 2021|reason=Who argues this?}} In the same paper Royce also advocated large quantities of documentation, doing the job "twice if possible" (a sentiment similar to that of [[Fred Brooks]], famous for writing the Mythical Man Month — an influential book in software [[project management]] — who advocated planning to "throw one away"), and involving the customer as much as possible (a sentiment similar to that of [[extreme programming]]).
Royce notes on the final model are:
# Complete program design before analysis and coding begins
# Documentation must be current and complete
# Do the job twice if possible
# Testing must be planned, controlled, and monitored
# Involve the customer
==See also==
{{cmn|
*[[List of software development philosophies]]
*[[Agile software development]]
*[[Big
*[[Chaos model]]
*[[DevOps]]
*[[Iterative and incremental development]]
*[[Monitoring Maintenance Lifecycle]]
*[[Object-oriented analysis and design]]
*[[Rapid application development]]
*[[Software development process]]
*[[Spiral model]]
*[[Structured Systems Analysis and Design Method]] (SSADM)
*[[System development methodology]]
*[[Traditional engineering]]
*[[V-Model (software development)|V-model]]
}}
==References==
{{
==External links==
{{Commons category|Waterfall models}}
* [http://
* [http://www.business-esolutions.com/islm.htm Project lifecycle models: how they differ and when to use them]
* [http://www-128.ibm.com/developerworks/rational/library/4626.html Going Over the Waterfall with the RUP] by [[Philippe Kruchten]]
* [http://www.ibm.com/developerworks/rational/library/3012.html CSC and IBM Rational join to deliver C-RUP and support rapid business change]
* [[
* [https://www.researchgate.net/profile/Wilfred-Van-Casteren/publication/313768756_The_Waterfall_Model_and_the_Agile_Methodologies_A_comparison_by_project_characteristics/links/58bec1a6a6fdcc7bd45e8418/The-Waterfall-Model-and-the-Agile-Methodologies-A-comparison-by-project-characteristics.pdf]
{{Software engineering}}
Line 137 ⟶ 173:
[[Category:Project management]]
[[Category:Design]]
| |||