Software development |
---|
Core activities |
Paradigms and models |
Methodologies and frameworks |
Supporting disciplines |
Practices |
Tools |
Standards and Bodies of Knowledge |
Glossaries |
Key Difference – Waterfall vs Spiral Model. The key difference between waterfall and iterative model is that waterfall model is used for smaller projects and projects with clear requirements while the spiral model is used for large, complex projects that require continuous risk analyzing. Software Development Life Cycle (SDLC) is a process followed by a software organization to develop a. Difference between Prototype Model and Waterfall Model. Prototype Model Vs Waterfall Model. Which model you should prefer Waterfall or Prototype?
The unmodified 'waterfall model'. Progress flows from the top to the bottom, like a cascading waterfall.
The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks. The approach is typical 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 recognised alternatives for knowledge-based creative work.[1]
History[edit]
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.[2] This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.[1]
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.[5]
The earliest use of the term 'waterfall' may have been in a 1976 paper by Bell and Thayer.[6]
In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A, 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'.[7]
Model[edit]
In Royce's 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 Royce's final model), however, can include slight or major variations on this process.[3] 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[edit]
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).[8]
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. 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.[9]
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.[10]
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.[11]
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.[12]
Criticism[edit]
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.[13]
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.[14]
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.[15] This is because implementing any non-trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider.
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'.[8]
Some organisations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and Incremental Development.[16]
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.[17]
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 'waterfall-like'.[citation needed]
Modified waterfall models[edit]
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'
- [8] 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.[18]
Royce's final model[edit]
Winston W. Royce's 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).
See also[edit]
- Structured Systems Analysis and Design Method (SSADM)
References[edit]
- ^ abBenington, Herbert D. (1 October 1983). 'Production of Large Computer Programs'(PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Retrieved 2011-03-21.
- ^United States, Navy Mathematical Computing Advisory Panel (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC10794738
- ^ abRoyce, Winston (1970), 'Managing the Development of Large Software Systems'(PDF), Proceedings of IEEE WESCON, 26 (August): 1–9
- ^Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Retrieved on 2007-11-28 from http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html
- ^Conrad Weisert, Waterfall methodology: there's no such thing!
- ^Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem?Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.
- ^Military Standard Defense System Software Development
- ^ abcMcConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN1-55615-900-5.
- ^'Waterfall Software Development Model'. 5 February 2014. Retrieved 11 August 2014.
- ^Arcisphere technologies (2012). 'Tutorial: The Software Development Life Cycle (SDLC)'(PDF). Retrieved 2012-11-13.
- ^Hughey, Douglas (2009). 'Comparing Traditional Systems Analysis and Design with Agile Methodologies'. University of Missouri – St. Louis. Retrieved 11 August 2014.
- ^'When should you use Waterfall Model?'. Retrieved 2016-09-28.
- ^Parnas, David L.; Clements, Paul C. (1986). 'A rational design process: How and why to fake it'(PDF). IEEE Transactions on Software Engineering: 251–257. Retrieved 2011-03-21.
- ^McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN1-55615-484-4.
- ^Ensmenger, Nathan (2010). The Computer Boys Take Over. p. 42. ISBN978-0-262-05093-7.
- ^Larman, Craig; Basili, Victir (2003). 'Iterative and Incremental Development: A Brief History'. IEEE Computer (June ed.). 36: 47–56. doi:10.1109/MC.2003.1204375.
- ^A Waterfall Systems Development Methodology … Seriously? by David Dischave. 2012. Archived July 2, 2014, at the Wayback Machine
- ^'Methodology:design methods'.
External links[edit]
Wikimedia Commons has media related to Waterfall models. |
- Going Over the Waterfall with the RUP by Philippe Kruchten
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Waterfall_model&oldid=913171517'
* Prototyping includes more customer attention or intractionrather than waterfall model. * Prototypes have a model to study andwork, where waterfall do not have any model till last, what ever wedeveloped that comes in last.
What is the difference between waterfall and throw away prototype model?
Waterfall model does not involve customer's feedback and there is no generation of any prototype,however in throw away prototype model a rough prototype is generated
What are the differences between throwaway and evolutionary prototypes?
In throwaway prototype model we discard the prototype and start from scratch. In evolutionary prototype model we make changes in the prototype and refine it.
What are the similarities between waterfall model and spiral model?
There are many differences exists between waterfall model and spiral model. In waterfall model if any sudden change takes place in the project, then its very hard to fix the issue. Wherein spiral model we can change according to our requirement.
What is the differences between incremental and waterfall development models?
The waterfall development model is primarily used by large software companies. The incremental model is used by small companies and individuals.
Which of the process model is best to understand the user requirements. a Prototype model b Waterfall model c Incremental model d None of the above?
Prototype model is the best way to understand customer's requirements. A prototype is re- generated until it meets the expectations of the user
How the waterfall model and prototyping model can be accommodated in the spiral process model?
Expalin different between waterfall model and prototyping model ? Expalin different between waterfall model and prototyping model ?
What are waterfall prototyping models?
In waterfall model we have 5 stages, that gives a software product at the end. In prototyping model, a prototype is made instead to refine the requirements more properly.
What is advantage of using prototyping model instead of using waterfall model?
There are many advantages of using prototype model over waterfall model . Some of the advantages are: 1) Excellent for gathering and refining requirements. 2) Useful for assessing and reducing risks.
Deference between classical waterfall model and iterative waterfall model?
Major difference between waterfall and iterative model is that waterfall model has a linear process in which full product is available after the last phase, while incremental model full product is available after several such phases.
What are the different types of SDLC?
1. Waterfall Model 2. Spiral Model 3. Iterative Model 4. Prototype Model 5. RAD Model 6. COCOMO Model 7. V-Model 8. Fish Model
What is the diffference between waterfall model and modified waterfall model?
Modified waterfall model verified and validate the user requirements for every phase. Meanwhile, waterfall did not, it only verify and validate user requirement at the end of the phase.
Deference between prototype and incremental model?
In incremental model the real product is designed, implemented, integrated and tested as a series of incremental builds. while In prototype model the prototype (not the real product) is designed, implemented, integrated and tested as a series of incremental builds
What is the Difference between RAD model and waterfall model?
The RAD model, also known as the Rapid Application Development, is a linear software for creating prototypes. The Waterfall model is a sequential software.
What is difference between Spiral model and Prototype?
prototype model is suitable when user requirement are not very clear, while spiral model suitable for large projects whether customer requirement are not known in the beginning
What is the difference between waterfall model iterative waterfall model successive model prototyping model and spiral model?
I will try to answer this quickly as I don't have much time. As the name suggests, the waterfall model follows the path of an waterfall. It starts in the first stage of orientation, and ends at the release. It can only go one way (to the end goal) and the stages are very strict (you cant go back to a earlier stage). The Spiral model understands that reality doesn't always follow theory, and that…