0% found this document useful (0 votes)
8 views3 pages

Waterfall

The document discusses software process models and the waterfall model in particular. It provides the following key points: 1) A software process model defines tasks, inputs/outputs, pre/post conditions, and sequence of tasks to systematically develop software. 2) The waterfall model is a traditional, sequential process model consisting of requirements, design, implementation, testing, deployment, and maintenance phases. 3) The waterfall model works best for well-defined requirements, stable scope, and ample resources but lacks flexibility for changes.

Uploaded by

Teju Melapattu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views3 pages

Waterfall

The document discusses software process models and the waterfall model in particular. It provides the following key points: 1) A software process model defines tasks, inputs/outputs, pre/post conditions, and sequence of tasks to systematically develop software. 2) The waterfall model is a traditional, sequential process model consisting of requirements, design, implementation, testing, deployment, and maintenance phases. 3) The waterfall model works best for well-defined requirements, stable scope, and ample resources but lacks flexibility for changes.

Uploaded by

Teju Melapattu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

2.

1 SOFTWARE PROCESS AND PROCESS MODELS


The goal of a software process model is to provide guidance for systematically
coordinating and controlling the tasks that must be performed in order to achieve the end
product and the project objectives. A process model defines the following.
• A set of tasks that need to be performed
• The input to and output from each task
• The preconditions and post conditions for each task
• The sequence and flow of these tasks

Figure 2.1 : A Simple Process

 An abstract representation of a process is known as process model / software


paradigm.
 Example of types of software process model
• Workflow model
• Data flow or activity model
• Role / action model

2.1.1 PERSPECTIVE PROCESS MODEL


 Also known as “traditional process model”.
 It is defined as prescribe a set of process elements(framework activities, software
engineering actions, tasks, work products, quality assurance, and change control
mechanisms for each project) and prescribes a process flow (also called a work
flow)— in which the process elements are interrelated to one another.
 Traditional Process Model are
 Classical Waterfall Model
 Iterative Waterfall Model
 Evolutionary Model
 Spiral Model
 Prototyping Model

2.1.1.1 WATER FALL MODEL


The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modeling, construction, and deployment,
culminating in ongoing support of the completed software.
STAGES OF THE WATERFALL MODEL
Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification doc.
System Design: 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.
Implementation: With inputs from system design, 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 which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.

Fig2.2 Waterfall Model

Deployment of system: Once the functional and non functional testing is done, the product
is deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those
issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards like a waterfall through the phases. The next phase is started only after
the defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model phases do not overlap.

APPLICATION
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model
is most appropriate are:
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
ADVANTAGE
 The advantage of waterfall development is that it allows for departmentalization and
control.
 A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one.
 Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance.
 Each phase of development proceeds in strict order.
DISADVANTAGE
 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-documented or thought upon in the concept stage.

2.1.1.2 V- MODEL
 The V - model is SDLC model where execution of processes happens in a sequential
manner in V-shape.
 It is also known as Verification and Validation model.
 V - Model is an extension of the waterfall model and is based on association of a
testing phase for each corresponding development stage.
 This means that for every single phase in the development cycle there is a directly
associated testing phase.
 This is a highly disciplined model and next phase starts only after completion of the
previous phase.

V- MODEL DESIGN
 Under V-Model, the corresponding testing phase of the development phase is
planned in parallel.
 So there are Verification phases on one side of the .V. and Validation phases on the
other side.
 Coding phase joins the two sides of the V-Model.
 The below figure 2.3 illustrates the different phases in V-Model of SDLC.

VERIFICATION PHASES
Following are the Verification phases in V-Model:

Business Requirement Analysis: This is the first phase in the development cycle where
the product requirements are understood from the customer perspective. This phase
involves detailed communication with the customer to understand his expectations and exact
requirement. This is a very important activity and need to be managed well, as most of the
customers are not sure about what exactly they need. The acceptance test design planning
is done at this stage as business requirements can be used as an input for acceptance
testing.
Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
But, in this model before development is started, a system test plan is created. The test plan
focuses on meeting the functionality specified in the requirements gathering.
The high-level design (HLD) phase focuses on system architecture and design. It provide
overview of solution, platform, system, product and service/process. An integration test plan
is created in this phase as well in order to test the pieces of the software systems ability to
work together.
The low-level design (LLD) phase is where the actual software components are designed.
It defines the actual logic for each and every component of the system. Class diagram with
all the methods and relation between classes comes under LLD. Component tests are
created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test plans
developed earlier are now put to use.
Coding: This is at the bottom of the V-Shape model. Module design is converted into code
by developers.

You might also like