An Introduction

1. Waterfall Model
Submitted to:
Inam Ul-Haq
Lecturer in Computer Science
University of Education, Okara Campus
Submitted by:
Hira Mehar (3006)
BS-IT-Eve
IV Semester
UniversityofEducationOkara
Campus
1

2. Table Of Content
UniversityofEducationOkara
Campus
2
Sr. # Topic Pg. #
01 SDLC 02
02 Software Engineering 04
03 Waterfall Model 05
04 Diagram 08
05 History & Features 09
06 Phases 10
07 Design 12
08 Coding 14
09 Testing 15
10 Maintenance 16
11 Advantages 18
12 Disadvantages 19
13 Problems 20
14 Conclusions 21

3. Software Development Life Cycle
UniversityofEducationOkara
Campus
3

4. Software Engineering
• Study of the techniques and theory that support the development of high-
quality software.
End result: we are looking to meet the needs of the:
• Client (person or organization)
• User (the people using the software)
Lifecycle Model:
A (software/system) lifecycle model is a description of the sequence of
activities carried out in an SE project, and the relative order of these
activities.
• It provides a fixed generic framework that can be tailored to a specific
project.
• Project specific parameters will include:
 Size, (person-years)
 Budget,
 Duration.
Project plan = lifecycle model + project parameters
UniversityofEducationOkara
Campus
4

5. Waterfall Model
The waterfall model is the classic lifecycle model – it is
widely known, understood and used.
• In some cases, waterfall is considered ”common sense”
approach.
• Introduced by Royce in 1970.
• Defined a number of phases, e.g., “requirement phase”,
“design phase”, etc.
• Assumption behind the model:
A phase takes place in sequence to another.
Each activity is completed before the next starts.
UniversityofEducationOkara
Campus
5

6. Waterfall Model
In theory:
• Each phase produces documents that are:
 Verified and validated.
 Assumed to be complete.
• Each phase depends on the documents of the previous stage to
precede → it has to wait for the completion of previous stage.
In practice:
The phases overlap and feedback to each other
Intuitive, sensible and general purpose:
Emphasize planning before action.
Recommend a top-down perspective. See the big picture before
zooming down.
UniversityofEducationOkara
Campus
6

7. Waterfall Model
Requirements: defines needed information,
function, behavior, performance and
interfaces
Design: includes flowcharts, data structures,
software architecture, interface
representations, algorithmic details
Implementation: source code, database,
user documentation, testing.
UniversityofEducationOkara
Campus
7

8. Waterfall Model
UniversityofEducationOkara
Campus
8

9. History & Features
History of Water Fall Model
• The first formal description of the waterfall model is often cited as a
1970 article by ‘’Winston W. Royce’’
• Royce did not use the term "waterfall" in this article.
• Royce presented this model as an example of a flawed, non-working
model.
Features of Water Fall Model
• A Water Fall Model is easy to flow.
• It can be implemented for any size of project.
• Every stage has to be done separately at the right time so you
cannot jump stages.
• Documentation is produced at every stage of a waterfall model
allowing people to understand what has been done.
• Testing is done at every stage.
UniversityofEducationOkara
Campus
9

10. Phases of Water Fall Model
Waterfall model has 5 different phases,
which are following.
• Requirement gathering and Analysis.
• Design.
• Coding.
• Testing.
• Maintenance.
UniversityofEducationOkara
Campus
10

11. Brief Description of Phase
Requirement gathering and Analysis.
• This is the first phase of waterfall model which includes a meeting
with the customer to understand his requirements.
• This is the most crucial phase as any misinterpretation at this stage
may give rise to validation issues later.
• The software definition must be detailed and accurate with no
ambiguities.
• It is very important to understand the customer requirements and
expectations so that the end product meets his specifications.
• Requirement gathering and Analysis phase the basic requirements
of the system must be understood by software engineer, who is also
called ANALYST.
• All this requirements are then well documented and discussed
further with the customer for reviewing.
UniversityofEducationOkara
Campus
11

12. Design
• The customer requirements are broken down into logical
modules for the ease of implementation. Hardware and
software requirements for every module are Identified and
designed accordingly.
• Also the inter relation between the various logical modules is
established at this stage. Algorithms and diagrams defining
the scope and objective of each logical model are developed.
• In short, this phase lays a fundamental for actual
programming and implementation
• It is an intermediate step between requirements analysis and
coding.
UniversityofEducationOkara
Campus
12

13. Design
Design focuses on program attribute such as-
• Data Structure.
• Software Architecture.
• Algorithm Details
etc…….
• The requirements are translated in some easy to represent
form using which coding can be done effectively and
efficiently.
• The design needs to be documented for further use.
UniversityofEducationOkara
Campus
13

14. Coding
14
UniversityofEducationOkara
Campus
• Coding is a step in which design is translated into
machine-readable form.
• If design is done in sufficient detail then coding
can be done effectively. Programs are created in
this phase.
• In this phase all software divided into small
module then after doing coding for that small
module rather than do coding whole software.
• According to design programmers do code and
make class and structure of whole software.

15. Testing
15
UniversityofEducationOkara
Campus
• In this stage, both individual components and the
integrated whole are methodically verified to ensure
that they are error-free and fully meet the requirements
outlined in the first step.
• In this phase testing whole software into two parts
1) HARDWARE
2) SOFTWARE.
• Type of testing is 2-types
1) Inside test.
2) Outside test.

16. Maintenance
16
UniversityofEducationOkara
Campus
• This is the final phase of the waterfall model, in which the completed
software product is handed over to the client after alpha, beta testing.
• After the software has been deployed on the client site, it is the duty of
the software development team to undertake routine maintenance
activities by visiting the client site.
• If the customer suggests changes or enhancements the software
process has to be followed all over again right from the first phase i.e.
requirement analysis.
• The usually the longest stage of the software. In this phase the software
is updated to:
• Meet the changing customer needs
• Adapted to accommodate changes in the external environment
• Correct errors and oversights previously undetected in the testing
phases
• Enhancing the efficiency of the software
Observe that feed back loops allow for corrections to be incorporated into
the model.

17. When to use the Waterfall
Model?
17
UniversityofEducationOkara
Campus
• Requirements are very well
known
• Product definition is stable
• Technology is understood
• New version of an existing
product
• Porting an existing product
to a new platform.

18. Advantages
18
UniversityofEducationOkara
Campus
• Easy to understand, easy to use
• Provides structure
• Milestones are clear
• Good for management control (plan, staff, track)
• Works well when quality is more important than
cost or schedule

19. Disadvantages
• All requirements must be known
upfront
• Deliverables created for each phase
are considered frozen – inhibits
flexibility
• Can give a false impression of
progress
• Does not reflect problem-solving
nature of software development ,
i.e. iterations of phases
• One big integration at the end
• Little opportunity for customer to
preview the system (until it may be
too late)
UniversityofEducationOkara
Campus
19

20. Problems
• Specification is frozen early, because:
It is costly and time consuming.
Later stages can be carried out.
• Cannot adapt to changing or incorrect specification:
Ignore or code around.
Does not meet user requirement.
• Testing at the very end of development:
Work or die situation.
UniversityofEducationOkara
Campus
20

21. Conclusion
• Whether you should use it or not depends
largely on:
how well you believe you understand your customer's needs
how much volatility you expect in those needs as the project progresses
• The model is recommended for use only in
projects which are relatively stable and where
customer needs can be clearly identified at an
early stage.
UniversityofEducationOkara
Campus
21

22. References
• www.slideshare.com
• https://www.google.com.pk/url
• www.nada.kth.se/~karlm/prutt05/lectures/prutt05_lec6.ppt
• www.uni-obuda.hu/.../Software%20Development%20Methodologies.ppt
• solomon.ipv6.club.tw/Course/.../20100310-liwen-waterfall.ppt
22
UniversityofEducationOkara
Campus