Waterfall Model is a sequential model that divides software development into pre-defined phases. Each phase must be completed before the next phase can begin with no overlap between the phases. Each phase is designed for performing specific activity during the SDLC phase. It was introduced in 1970 by Winston Royce. Explain Waterfall Model in SDLC Following are the different Waterfall Model phases:
When to use SDLC Waterfall Model?Waterfall Methodology can be used when:
Advantages and Disadvantages of Waterfall ModelHere are the popular advantages of Waterfall model in Software Engineering with some disadvantages:
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 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] 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 recognised alternatives for knowledge-based creative work.[3][better source needed] History[edit]The first known presentation describing use of such phases in software engineering was held by Felix Torres and Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956[citation needed].[4] 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.[3] Although the term "waterfall" is not used in the paper, the first formal detailed diagram of the process later known as the "waterfall model" is often[citation needed] cited as a 1970 article by Winston W. Royce.[5][6][7] However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure".[5] 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.[5] 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.[8][better source needed] The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer.[9][better source needed] In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A[citation needed], 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: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".[10] Model[edit]In Royce's original waterfall model[citation needed], the following phases are followed in order:
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.[5] 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).[11] 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.[12][failed verification] 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.[citation needed] 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.[13] 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.[14] 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.[15] 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.[16] 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.[17] 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".[11] 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.[18] 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.[19] 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":[11] 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.[20] 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). Royce notes to the final model are:
See also[edit]
References[edit]
External links[edit]
What is the sequential software development model?It is also known as "The Linear Sequential Model". The linear sequential model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, implementation, testing, and support or maintenance as shown in Figure 1.4.
Which SDLC model uses sequential phases?Waterfall model is the very first model that is used in SDLC. It is also known as the linear sequential model. In this model, the outcome of one phase is the input for the next phase. Development of the next phase starts only when the previous phase is complete.
What are the 5 software development phases?At the most basic level, we employ five stages during the software design process: research, ideation, design, development and iteration. These five elements parallel the most basic questions of “who, what, when, where and how” that are needed to fully answer any set of questions.
Which of the following follows the correct sequence in a waterfall model?Explanation: A correct order of the waterfall model phases are problem identification, analysis, design, implementation, testing, deployment, and implementation.
|
Which of the following is a software development model that is sequential in which each phase is followed by the next phase?
zusammenhängende Posts
Urheberrechte © © 2024 ihoctot Inc.
