1 / 7

Waterfall Approach

Waterfall Approach. By : Robin & Sankara. Objectives. To define Waterfall Approach State weaknesses and strength. Waterfall Approach.

lilia
Download Presentation

Waterfall Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Waterfall Approach By : Robin & Sankara

  2. Objectives • To define Waterfall Approach • State weaknesses and strength

  3. Waterfall Approach The waterfall model is the classical model of software engineering. This model is one of the oldest models and is widely used in government projects and in many major companies. A software life-cycle or product life-cycle model, described by W. W. Royce in 1970, in which development is supposed to proceed linearly through the phases of requirements analysis design, implementation, testing (validation), integration and maintenance. The Waterfall Model is considered old-fashioned or simplistic by proponents of object-oriented design which often uses the spiral model instead. Earlier phases are sometimes called "upstream” and later ones "downstream".

  4. Waterfall Approach

  5. Strengths of Waterfall Easy to understand and implement Widely used and known (in theory). Reinforces good habits: define before-design and design before-code Identifies deliverables and milestones Document driven URD, SRD etc Published Documentation standards Works well on mature products and weak teams

  6. Weaknesss of Waterfall • Idealized, doesnt match reality well • Doesn't reflect iterative nature of exploratory development • Unrealistic to expert accurate requirement so early in project • Software is delivere late in project, delays discovery of serious errors • Difficult to integrate risk management • Expensive to make changes to documents "swimming upstream" • Significant administrative overhead, costlyfor small teams and projects

More Related