waterfall model software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte the unmodified waterfall model progress flows from the top to the bottom like a cascading waterfall the waterfall model is a relatively linear sequential design approach for certain areas of engineering design in software development 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 the waterfall development model originated in the manufacturing and construction industries where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process when first adopted for software development there were no recognized alternatives for knowledgebased creative work history the first known presentation describing 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 the first formal description of the waterfall model is often cited as a 1970 article by winston w royce the earliest use of the term waterfall may have been in a 1976 paper by bell and thayer in 1985 the united states department of defense captured this approach in dodstd2167a their standards for working with software development contractors which stated that the contractor shall implement a software development cycle that includes the following six phases preliminary design detailed design coding and unit testing integration and testing model in royces original waterfall model the following phases are followed in order system and software requirements captured in a product requirements document analysis resulting in models schema and business rules design resulting in the software architecture coding the development proving and integration of software testing the systematic discovery and debugging of defects operations the installation migration support and maintenance of complete systems thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified various modified waterfall models including royces final model however can include slight or major variations on this process these variations included returning to the previous cycle after flaws were found downstream or returning all the way to the design phase if downstream phases deemed insufficient 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 in common practice waterfall methodologies result in a project schedule with 2040 of the time invested for the first two phases 3040 of the time to coding and the rest dedicated to testing and implementation the actual project organisation needs 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 a further argument for the waterfall model is that it places emphasis on documentation such as requirements documents and design documents as well as source code 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 or even entirely new teams should be able to familiarise themselves by reading the documents 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 it is perhaps for this reason that the waterfall model is used as a beginning example of a development model in many software engineering texts and courses it is argued that the waterfall model can be suited to projects where requirements and scope are fixed the product itself is firm and stable and the technology is clearly understood criticism clients may not know exactly what their requirements are before they see working software and so change their requirements leading to redesign redevelopment and retesting and increased costs designers may not be aware of future difficulties when designing a new software product or feature in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints requirements or problems in response to the perceived problems with the pure waterfall model modified waterfall models were introduced such as sashimi waterfall with overlapping phases waterfall with subprojects and waterfall with risk reduction some organisations such as the united states department of defense now have a stated preference against waterfalltype methodologies starting with milstd498 which encourages evolutionary acquisition and iterative and incremental development while advocates of agile software development argue the waterfall model is an ineffective process for developing software some sceptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies rational unified process rup phases acknowledge the programmatic need for milestones for keeping a project on track but encourage iterations especially within disciplines within the phases rup phases are often referred to as waterfalllike modified waterfall models in response to the perceived problems with the pure waterfall model many modified waterfall models have been introduced these models may address some or all of the criticisms of the pure waterfall model these include the rapid development models that steve mcconnell calls modified waterfalls royces final model winston w royces final model his intended improvement upon his initial waterfall 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 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 list of software development philosophies agile software development big design up front chaos model devops iterative and incremental development objectoriented analysis and design rapid application development software development process spiral model structured systems analysis and design method ssadm system development methodology traditional engineering vmodel wikimedia commons has media related to waterfall models understanding the pros and cons of the waterfall model of software development project lifecycle models how they differ and when to use them going over the waterfall with the rup by philippe kruchten csc and ibm rational join to deliver crup and support rapid business change c2waterfall vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 