Вы находитесь на странице: 1из 15

A

Seminar Report
On

“WATERFALL MODEL”

Submitted in partial fulfillment of the requirement


For the award of the
Degree of
Bachelor of Technology
In
Computer Science
(Sir Padampat Singhania University)

Submitted By
Ayush Jani

Department of Computer Science and Engineering


SIR PADAMPAT SINGHANIA UNIVERSITY
UDAIPUR

1
Department of Computer Science and Engineering
SIR PADAMPAT SINGHANIA UNIVERSITY
UDAIPUR

CERTIFICATE

This is to certify that Mr. Ayush Jani a student of B.Tech. (Computer Science
and Engineering) Eight (Viii) semester has submitted his Seminar entitled
“Waterfall Model” under my guidance.

Seminar Guide

Mr. Ajay Prasad

2
ABSTRACT

The waterfall model is a sequential design process, often used in software development
processes, in which progress is seen as flowing steadily downwards (like a waterfall) through
the phases of Conception, Initiation, Analysis, Design, Construction, Testing,
Production/Implementation and Maintenance.

The waterfall development model originates in the manufacturing and construction industries:
highly structured physical environments in which after-the-fact changes are prohibitively
costly, if not impossible. Since no formal software development methodologies existed at the
time, this hardware-oriented model was simply adapted for software development.

The first known presentation describing use of similar phases in software engineering was
held by Herbert D. Benington at Symposium on advanced programming methods for digital
computers on 29 June 1956.[1].This presentation was about the development of software for
sage. In 1983 the paper was republished] with a foreword by Benington pointing out that the
process was not in fact performed in strict top-down, but depended on a prototype.

The waterfall model is the oldest and most widely used paradigm for software engineering.
Although the waterfall model is often derived as old fashioned', it remains a reasonable
approach when requirements are well understood.

3
Table of Contents

1. Introduction to Waterfall Model 4


1.1.Concept 4
1.2.Need of waterfall model 6
1.3.Advantages Disadvantages 7
2. Waterfall Model Architecture 8
2.1.Waterfall Model Architecture 8
3. Methodologies 10
3.1.Waterfall Methodology 10
3.2.Waterfall Sequence 11
3.2.1 Waterfall Deliverable 11
References 13

List Of Figures

1.1 Waterfall model Architecture 8

1.2 Requirement Analyses 9

1.3 System Design 10

1.4 Testing Phase 11

4
1. Introduction to Waterfall model
1.1 Concept

There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred as
"Software Development Process Models". Each process model follows a particular life cycle
in order to ensure success in process of software development.

One such approach/process used in Software Development is "The Waterfall Model".


Waterfall approach was first Process Model to be introduced and followed widely in
Software Engineering to ensure success of the project. In "The Waterfall" approach, the
whole process of software development is divided into separate process phases. The phases in
Waterfall model are: Requirement Specifications phase, Software Design, Implementation
and Testing & Maintenance. All these phases are cascaded to each other so that second phase
is started as and when defined set of goals are achieved for first phase and it is signed off, so
the name "Waterfall Model". All the methods and processes undertaken in Waterfall Model
are more visible.

The stages of "The Waterfall Model" are:


Requirement Analysis & Definition: All possible requirements of the system to be
developed are captured in this phase. Requirements are set of functionalities and constraints
that the end-user (who will be using the system) expects from the system. The requirements
are gathered from the end-user by consultation, these requirements are analyzed for their
validity and the possibility of incorporating the requirements in the system to be development
is also studied. Finally, a Requirement Specification document is created which serves the
purpose of guideline for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to
understand what we are going to create and what it should look like? The requirement
specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in

5
defining overall system architecture. The system design specifications serve as input for the
next phase of the model.

Implementation & Unit Testing: On receiving system design documents, the work is
divided in modules/units and actual coding is started. The system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if
the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which
are developed and tested for their functionalities. These units are integrated into a complete
system during Integration phase and tested to check if all modules/units coordinate between
each other and the system as a whole behaves as per the specifications. After successfully
testing the software, it is delivered to the customer.

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending
phase (Very long). Generally, problems with the system developed (which are not found
during the development life cycle) come up after its practical use starts, so the issues related
to the system are solved after deployment of the system. Not all the problems come in picture
directly but they arise time to time and needs to be solved; hence this process is referred as
Maintenance.

There are some disadvantages of the Waterfall Model.


1) As it is very important to gather all possible requirements during the Requirement
Gathering and Analysis phase in order to properly design the system, not all requirements are
received at once, the requirements from customer goes on getting added to the list even after
the end of "Requirement Gathering and Analysis" phase, this affects the system development
process and its success in negative aspects.

2) The problems with one phase are never solved completely during that phase and in fact
many problems regarding a particular phase arise after the phase is signed off, this results in
badly structured system as not all the problems (related to a phase) are solved during the
same phase.

6
3) The project is not partitioned in phases in flexible way.

4) As the requirements of the customer goes on getting added to the list, not all the
requirements are fulfilled, this results in development of almost unusable system. These
requirements are then met in newer version of the system; this increases the cost of system
development.

1.2 Need Of Waterfall Model

The waterfall model is a popular version of the systems development life cycle model for
software engineering. Often considered the classic approach to the systems development life
cycle, the waterfall model describes a development method that is linear and sequential.
Waterfall development has distinct goals for each phase of development. Imagine 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.

The advantage of waterfall development is that it allows for departmentalization and


managerial control. A schedule can be set with deadlines for each stage of development and a
product can proceed through the development process like a car in a carwash, and

The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage. Alternatives to the waterfall
model include joint application development (JAD), rapid application development (RAD),
synch and stabilize, build and fix, and the spiral model.

7
1.3 Advantage and Disadvantage
1.3.1 Advantage

• Managers love waterfall models

• Minimizes change, maximizes predictability

• Costs and risks are more predictable

• Each stage has milestones and deliverables: project managers can use to gauge how
close project is to completion

• Sets up division of labor: many software shops associate different people with
different stages:

– Systems analyst does analysis,

– Architect does design,

– Programmers code,

– Testers validate, etc.

1.3.2 Disadvantage

• Offers no insight into how each activity transforms artifacts (documents) of one stage
into another

– For example, requirements specification à design documents?

• Fails to treat software a problem-solving process

– Unlike hardware, software development is not a manufacturing but a creative


process

– Manufacturing processes really can be linear sequences, but creative processes


usually involve back-and-forth activities such as revisions

– Software development involves a lot of communication between various


human stakeholders

• Nevertheless, more complex models often embellish the waterfall,

– incorporating feedback loops and additional activities

8
2.Waterfall model Architecture
2.1 Waterfall model Architecture

Fig 1.1 Waterfall model Architecture

The stages of "The Waterfall Model" are:


Requirement Analysis & Definition: All possible requirements of the system to be
developed are captured in this phase. Requirements are set of functionalities and constraints
that the end-user (who will be using the system) expects from the system. The requirements
are gathered from the end-user by consultation, these requirements are analyzed for their
validity and the possibility of incorporating the requirements in the system to be development
is also studied. Finally, a Requirement Specification document is created which serves the

9
purpose of guideline for the next phase of the model.

Fig 1.2 Requirement Analyses

System & Software Design: Before a starting for actual coding, it is highly important to
understand what we are going to create and what it should look like? The requirement
specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture. The system design specifications serve as input for the
next phase of the model.

10
Fig 1.3 System Design

Implementation & Unit Testing: On receiving system design documents, the work is
divided in modules/units and actual coding is started. The system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if
the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in units which
are developed and tested for their functionalities. These units are integrated into a complete
system during Integration phase and tested to check if all modules/units coordinate between

11
each other and the system as a whole behaves as per the specifications. After successfully
testing the software, it is delivered to the customer.

Fig 1.4 Testing Phase

Operations & Maintenance: This phase of "The Waterfall Model" is virtually never ending
phase (Very long). Generally, problems with the system developed (which are not found
during the development life cycle) come up after its practical use starts, so the issues related
to the system are solved after deployment of the system. Not all the problems come in picture
directly but they arise time to time and needs to be solved; hence this process is referred as
Maintenance.

There are some disadvantages of the Waterfall Model.


1) As it is very important to gather all possible requirements during the Requirement
Gathering and Analysis phase in order to properly design the system, not all requirements are
received at once, the requirements from customer goes on getting added to the list even after
the end of "Requirement Gathering and Analysis" phase, this affects the system development
process and its success in negative aspects.

2) The problems with one phase are never solved completely during that phase and in fact

12
many problems regarding a particular phase arise after the phase is signed off, this results in
badly structured system as not all the problems (related to a phase) are solved during the
same phase.

3) The project is not partitioned in phases in flexible way.

3.Methodologies
Software engineering is the practice of using selected process techniques to improve the
quality of a software development effort. This is based on the assumption, subject to
endless debate and supported by patient experience, that a methodical approach to
software development results in fewer defects and, therefore, ultimately provides shorter
delivery times and better value. The documented collection of policies, processes and
procedures used by a development team or organization to practice software
engineering is called its software development methodology (SDM) or system
development life cycle (SDLC).
3.1 Water Fall Methodology
Rather than try to give an all-encompassing definition for methodologies that should be
classified as waterfall approaches, it easier to describe some common characteristics.
Primarily, a waterfall methodology structures a project into distinct phases with defined
deliverables from each phase. The phases are always named something different,
depending on which company is trying to differentiate its own particular flavor, but the
basic idea is that the first phase tries to capture What the system will do (its
requirements), the second determines How it will be designed, in the middle is the actual
programming, the fourth phase is the full system Testing, and the final phase is focused
on Implementation tasks such as go-live, training, and documentation.

3.2 Waterfall Sequence


333333333333333333
Waterfall Deliverables
Requirements .Screens Database Objects Test Plan UI Logic Report Test Scripts Defect
Report User Feedback Training Documentation
Project Management Project Charter, Status Reports, Change Requests
Typically waterfall methodologies result in a project schedule with 20-40% of the time

13
budgeted for the first two phases, 30-40% of the time to the programming, and the rest
allocated to testing and implementation time. The actual project organization tends to be
highly structured. Most medium to large size projects will include a rigidly detailed set of
procedures and controls to cover everything from the types of communications to use in
various situations, to authorizing and tracking change orders, to the specific ways that
defects are logged, communicated, resolved, and re-tested.
Perhaps most importantly, waterfall methodologies also call for an evolution of project
staffing throughout the various phases. While typical consulting companies will refer to
the differences in staffing as simply “roles,” which imply that the same people could
remain on the project and simply switch roles, the reality is that the project staff
constantly changes as it progresses. Reasons for the change include economics,
mentoring, and expertise - economics in the sense that the project budget encourages
the replacement of a relatively highly paid architect with a lower paid staff programmer
as soon as possible. On the other hand, an architect with a particular skill set or an
analyst with valuable subject area knowledge may be demanded on another project. A
fundamental assumption is that the extensive project documentation and control
procedures enable relatively easy knowledge transfer to new project staff.

3.2.2Waterfall Resources
SMEs Analysts ProjMgr. SMEs Analysts Architects Proj. Mgr.Architect Coders Proj.
MgrTestrs Coders Proj. Mgr .AnalystsCoders Proj. Mgr.
Waterfall Strengths
Most of the benefits from using a waterfall methodology are directly related to its
underlying principles of structure. These strengths include:
■ Ease in analyzing potential changes
■ Ability to coordinate larger teams, even if geographically distributed
■ Can enable precise dollar budget
■ Less total time required from Subject Matter Experts
Waterfall Weaknesses
While waterfall has advantages, its highly structured approach also leads to
disadvantages such as the following:
■ Lack of flexibility
■ Hard to predict all needs in advance
■ Intangible knowledge lost between hand-offs

14
■ Lack of team cohesion
■ Design flaws not discovered until the Testing phase

References
1) www.google.com
2) www.wikipedia.org
3) www.toodoc.com
4) www.bitpipe.com

15

Вам также может понравиться