ppt on problem with water fall model

1. Presented By–
Soni Singh
M- Tech (S.E)
1st Year

2.  Introduction
 Simple Waterfall Model
 Concept of Waterfall Model
 Main Faliure of a Waterfall Model
 Problems of Waterfall Model
 Conclusion
 References

3.  When developers attempt to create a project in addition to selecting
a development method they must create a plan or model for the
many task that will follow. In Software Development there are
different generic software process models which can be used. This is
basically the structure of the approach that will be taken to develop
the program .
 According to Systems Analysis and Design, Shelly Cashman(2008),
A structured analysis uses the system development life cycle
(SLDC) process. The SLDC describes activities and functions that
all systems developers perform, regardless of the approach used.
In the waterfall approach, the result of each phase is called a
deliverable or end product which flows sequentially into the next
phase.

4.  The waterfall model(approach) is a sequential software
development process, in which progress is seen as flowing
steadily downwards (like a waterfall) . In the unmodified
"waterfall model“, progress flows from the top to the bottom,
like a waterfall.
Requirements
Design
Implementation
Verification
Maintenance

6.  When we think of a Waterfall, what comes to mind ?.
 That it flows from top to bottom. Right?
 Well this is the main problem with the waterfall model .A
waterfall on the cliff of a steep mountain. Once the water has
flowed over the edge of the cliff and has begun its journey
down the side of the mountain, it cannot turn back. It is the
same with waterfall development. Once a phase of
development is completed, the development proceeds to the
next phase and there is no turning back.

7.  Most times a consumers or users mind is constantly
changing and most persons have a vague idea of their
software requirements and its as the software
develops that they specify their requirements.
 As a result of consumers having difficulty in
completely defining requirements they are clueless to
what they want) at the beginning, using this approach
we see the weakness of this approach come to light:-

8.  It is inadequate as developers cannot just go back and
change something in a previous phase as the
consumers requirement change but the developer has
to go back to where the requirement needs to change
and start that phase all over. Not until that phase is
complete can he move on to the next phase. We see
two set of weaknesses come to light:-

9.  This approach does not make allowance for the change of
defined requirements as the project progresses. Thus there is a
big potential that the software will not fully meet the
requirement of the user, it will be inefficient and have poor
functionality.
 If the user has made an error in their requirements then the
whole processes has to be restarted.
 As we know a users wants are always changing and so an
implementation using this approach to develop the software
may take so long that the original requirements may no longer
be valid by the time the system is implemented.

10.  It is a very time consuming process and especially with the
iteration (Repeating a whole process already completed).
Developers also underestimate the time it will take to finish the
project and so it runs over budget.
 There is also little communication and interaction between the
customers, engineers and project managers and this we know
can lead to bigger problems which is made worst by the
inadequacy of this approach.
 As a result of the above the development team does not
understand the structure of the customers organization.

11.  “Much reflection or revision is not allowed.” There
is no possibility for maintenance fitting or reuse in
such a format.
 There is also a big chance that the user interface
(design of software) will be difficult to carry out
(use). In other words the design will not be capable of
being used successfully (feasible).

12.  In documentation and reviewing the procedures,
massive delays occur.
 Developers spend a lot of time and effort on the early
phase to ensure that they have no error as all other
phases depend on them.

13.  We failed to deliver the application as intended to the
customer in the time frame we predicted.
 We now understand that the solution that we have in
process is somewhat off the mark.
 We likely don’t have anything to ship to the hold the
customer’s confidence.
 Reworking what we have may require ripping out some of
what we’ve already built.
 We haven’t driven the risk out of the project because
integration is not complete.

14.  Shelly Cashman ,(2008). Systems Analysis and Design
 (2003-2009). Waterfall Model. Retrieved from www.onestoptesting.com
 (2004-2007). The System Development Life Cycle. Retrieved from
www.startvbdotnet.com
 Parekh Nilesh. (2005, May 1). The Waterfall Model Explained.
www.buzzle.com
 Dr. Robertson David , Dr. Bednar James A. (2006). Development
Methodologies. Waterfall Model. Retrieved from
http://www.inf.ed.ac.uk/teaching/courses/seoc2/2004_2005/slides/methodologi
es_4up.pdf
 Als Adrian , Greenidge Charles. (2005, September 29). The Waterfall Model.
Retrieved from
http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm
 Anonymous(1998,April 4). The Waterfall Lifecycle Model and its Derivatives .
Retrieved from http://codecourse.sourceforge.net/materials/The-Waterfall-
Lifecycle-Model.html