Академический Документы
Профессиональный Документы
Культура Документы
Seminar Report
On
“WATERFALL MODEL”
Submitted By
Ayush Jani
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
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
List Of Figures
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.
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.
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.
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 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
• 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:
– Programmers code,
1.3.2 Disadvantage
• Offers no insight into how each activity transforms artifacts (documents) of one stage
into another
8
2.Waterfall model Architecture
2.1 Waterfall model Architecture
9
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
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.
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.
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.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.
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