Waterfall Model
22
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 University of Education Okara Campus 1
-
Upload
university-of-educationlahore -
Category
Education
-
view
500 -
download
11
Transcript of Waterfall Model
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
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
1
Table Of Content
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
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
Software Development Life Cycle
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
3
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
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
4
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. U
niv
ers
ity o
f E
du
catio
n O
kara
C
am
pu
s
5
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
6
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
7
Waterfall Model
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
8
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
9
Phases of Water Fall Model
Waterfall model has 5 different phases,
which are following.• Requirement gathering and Analysis.• Design.• Coding.• Testing.• Maintenance.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
10
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
11
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
12
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. Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
13
Coding
14
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
• 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.
Testing
15
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
• 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.
Maintenance
16
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
• 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.
When to use the Waterfall Model?
17
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
• 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.
Advantages
18
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
• 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
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)
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
19
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
20
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.
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
21
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
Un
ive
rsity
of
Ed
uca
tion
Oka
ra
Ca
mp
us
