Problems with water fall model ppt
- 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