1. GENERIC SOFTWARE PROCESS MODELS THE WATERFALL APPROACH
Presenters:
Krystn Trowers
Kerisha Witter

2. INTRODUCTION
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.

3. 3

4. Not in our own words In our own words
Definitions
Not in our own words
In our own words

5. NOT IN OUR OWN WORDS
Dr. Winston W. Royce, in "Managing the Development of Large Software Systems", the first paper that describes the waterfall model, also describes the simplest form as "risky and invites failure".
Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a "wicked problem" — a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.

6. NOT IN OUR OWN WORDS
David Parnas, in "A Rational Design Process: How and Why to Fake It", writes:
“Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.”

7. THE WATERFALL APPROACH (IN OUR OWN WORDS)
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

8. When we say the Waterfall Approach, What exactly do we speak of?8

9. MOVES FROM TOP TO BOTTOM NOT RETURNING TO ANY STAGE

10. THERE ARE VARIATIONS TO A WATERFALL BUT THE CONCEPT IS SIMILAR

11. IN OUR OWN WORDS When we think of a Waterfall, what comes to mind?
That it flows from top to bottom. Right?
Well this is the basic concept of the waterfall approach just as the waterfall 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.

12. HOW DOES IT WORK?
In the waterfall model, you proceed from one phase to the next sequentially. This suggests that you would complete the specification requirements first then when this phase is completed you move onto the design phase. In this phase the software is designed and a blue print is drawn for the coders to follow when the design phase has ended. In the implementation stage, the design is implemented by the coders and in the final stages of the implementation phase, separate software components are combined to form new functionalities and reduce risks through the removal of errors. As a result the waterfall model suggests that you should move to a phase only when its preceding phase has been completed and perfected.

13. THERE ARE FIVE PHASES IN THE WATERFALL APPROACH
Requirements Specification
Design
Implementation
Verification (Testing and Debugging)
Maintenance (Installation)

14. BRIEF DESCRIPTION OF THE PHASES
Requirements-Developer analyses users requirement and, performs further investigation of requirements, produces developers version of requirements. Since oftentimes users are unable to describe what they need with precision. However, when the developer finally gets the users to accept the proposal they can now begin.
Design-this phase focuses on high level design; what programs are needed and how they will interact with low level design(how the individual programs will work), interface design(what the interface will look like) and data design(what data is required) . Hence the overall structure is defined.

15. BRIEF DESCRIPTION OF THE PHASES
Implementation-In this phase designs are translated into codes. The programs are written using a programming language or application generators.Various high level languages such as pascal , C, C++ and java are used with programming tools such as compilers, debuggers and interpreters to generate codes.
Verification- In this phase the system is tested; each module is tested separately and in detail then the system is tested as a whole. Therefore the whole system tested to ensure that the interface between modules work, the system works as intended with the expected volume of data and that it does what the user requires.

16. BRIEF DESCRIPTION OF THE PHASES
Maintenance- in this phase the system is maintained since the software will undergo change once delivered to the customers; these changes may stem from unexpected input values into the system. Therefore the software must be developed to accommodate changes that could happen during those periods before its implementation period.

17. TAKE NOTES
The waterfall approach is seemingly perfect but it is deemed inadequate as a process of software development therefore many persons wonder, Why spend time on this process?
It is for these reasons;
The waterfall approach is still used by many software standards documents today.
Other processes depend strongly on the waterfall approach(and its inadequacies) since it is a perquisite to the study of alternative processes.
And none technical managers and persons responsible for external developments still demand the waterfall approach.

18. Strengths
As a result of simplistic approach it is explainable to the user.
As a result of the linear sequential model it appears orderly and that appeals to management.
Testing (Verification) must be done at every stage of the waterfall model thus most errors are identified before the other phase is begun. Misinterpretations and other defaults are also detected at an early stage. 18

19. Strengths
According to Contributor Melonfire (2006,September 22) retrieved from “the staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met.”

20. Strengths
As a result of the first two phases of the waterfall approach producing a formal specification (when the user know what they want) when the developers go their different ways the transfer of information can be well-organized.
Retrieved from Freetutes.com “The stages and activities are well defined and helps to plan and schedule the project.”

21. Strengths
Documentation is provided at every stage and there is early functionality. As a result of each phase having to be fully completed before the next phase begin reports can be done on each phase.
The system is broken down into departments where they can be controlled by departmental managers.
It allows job specialization thus more competent person can do the task. 21

22. Weakness
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:- 22

23. Weakness
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:-

24. Weakness
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.

25. Weakness
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. 25

26. Weakness
Retrieved from “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). 26

27. Weakness
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. 27

28. Conclusion
In wrapping up basically we can say that the waterfall approach:-
A cascading effect each phase must be completed and “signed off” before the next phase can be started.
It is a linear sequential approach
It is best for a software where the system requirement is not vague but specific and is not subject to change.
As a result it has more disadvantages than advantages.

29. References Shelly Cashman ,(2008). Systems Analysis and Design
( ). Waterfall Model. Retrieved from
( ). The System Development Life Cycle. Retrieved from
Parekh Nilesh. (2005, May 1). The Waterfall Model Explained.
Dr. Robertson David , Dr. Bednar James A. (2006). Development Methodologies. Waterfall Model. Retrieved from
Als Adrian , Greenidge Charles. (2005, September 29). The Waterfall Model. Retrieved from
Anonymous(1998,April 4). The Waterfall Lifecycle Model and its Derivatives . Retrieved from 29