GENERIC SOFTWARE PROCESS
MODELS
THE WATERFALL APPROACH
Presenters:
Krystn Trowers
Kerisha Witter
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.
Definitions
Not in our own words
In our own words
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.
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.”
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
When we say the Waterfall
Approach, What exactly do we
speak of?
MOVES FROM TOP TO BOTTOM
NOT RETURNING TO ANY STAGE
THERE ARE VARIATIONS TO A
WATERFALL BUT THE CONCEPT
IS SIMILAR
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.
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.
IN THE WATERFALL
APPROACH
•
•
•
•
•
Requirements Specification
Design
Implementation
Verification (Testing and Debugging)
Maintenance (Installation)
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.
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.
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.
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.
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.
Strengths
• According to Contributor Melonfire (2006,September 22)
retrieved from http://articles.techrepublic.com.com/510010878_11-6118423.html “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.”
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.”
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.
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:-
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:-
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.
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.
Weakness
• Retrieved from http://www.onestoptesting.com/sdlc-
•
models/waterfall-model/advantage-disadv.asp “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).
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.
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.
References
• 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/methodol
ogies_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-LifecycleModel.html