WATERFALL MODEL

The waterfall model is a sequential software development process, in

which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of Conception, Initiation, Analysis, Design, Construction,
Testing and Maintenance.
The waterfall development model has its origins 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 formal description of the waterfall model is often cited to be an
article published in 1970 by Winston W. Royce,[1] although Royce did not use
the term "waterfall" in this article. Royce was presenting this model as an
example of a flawed, non-working model (Royce 1970). This is in fact the
way the term has generally been used in writing about software
development—as a way to criticize a commonly used software practice.[2]

Model
In Royce's original waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a sequential manner.
For example, one first completes requirements specification, which after sign-off are considered
"set in stone." When the requirements are fully completed, one proceeds to design. The software
in question is designed and a blueprint is drawn for implementers (coders) to follow — this

1
design should be a plan for implementing the requirements given. When the design is fully
completed, an implementation of that design is made by coders. Towards the later stages of this
implementation phase, separate software components produced are combined to introduce new
functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is completed and perfected. However, there are various modified waterfall models
(including Royce's final model) that may include slight or major variations upon this process.
Supporting arguments
Time spent early in the software production cycle can lead to greater economy at later stages. It
has been shown that a bug found in the early stages (such as requirements specification or
design) is cheaper in terms of money, effort and time, to fix than the same bug found later on in
the process. ([McConnell 1996], p. 72, estimates that "a requirements defect that is left
undetected until construction or maintenance will cost 50 to 200 times as much to fix as it would
have cost to fix at requirements time.") To take an extreme example, if a program design turns
out to be impossible to implement, it is easier to fix the design at the design stage than to realize
months later, when program components are being integrated, that all the work done so far has to
be scrapped because of a broken design.
This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent
early on making sure that requirements and design are absolutely correct will save you much
time and effort later. Thus, the thinking of those who follow the waterfall process goes, one
should make sure that each phase is 100% complete and absolutely correct before proceeding to
the next phase of program creation. Program requirements should be set in stone before design is
started (otherwise work put into a design based on incorrect requirements is wasted); the
program's design should be perfect before people begin work on implementing the design
(otherwise they are implementing the wrong design and their work is wasted), etc.
A further argument for the waterfall model is that it places emphasis on documentation (such as
requirements documents and design documents) as well as source code. In less designed and
documented methodologies, should team members leave, much knowledge is lost and may be
difficult for a project to recover from. Should a fully working design document be present (as is
the intent of Big Design Up Front and the waterfall model) new team members or even entirely
new teams should be able to familiarize themselves by reading the documents.
As well as the above, some prefer the waterfall model for its simple approach and argue that it is
more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model
provides a structured approach; the model itself progresses linearly through discrete, easily
understandable and explainable phases and thus is easy to understand; it also provides easily
makeable milestones in the development process. It is perhaps for this reason that the waterfall
model is used as a beginning example of a development model in many software engineering
texts and courses.
It is argued that the waterfall model and Big Design up Front in general can be suited to software
projects which are stable (especially those projects with unchanging requirements, such as with
shrink wrap software) and where it is possible and likely that designers will be able to fully
predict problem areas of the system and produce a correct design before implementation is
started. The waterfall model also requires that implementers follow the well made, complete
design accurately, ensuring that the integration of the system proceeds smoothly.

Criticism

2
The waterfall model is argued by many to be a bad idea in practice. This is mainly because of
their belief that it is impossible for any non-trivial project to get one phase of a software
product's lifecycle perfected, before moving on to the next phases and learning from them.
For example, clients may not be aware of exactly what requirements they need before reviewing
a working prototype and commenting on it; they may change their requirements constantly.
Designers and programmers may have little control over this. If clients change their requirements
after the design is finalized, the design must be modified to accommodate the new requirements.
This effectively means invalidating a good deal of working hours, which means increased cost,
especially if a large amount of the project's resources has already been invested in Big Design Up
Front.
Designers may not be aware of future implementation difficulties when writing a design for an
unimplemented software product. That is, it may become clear in the implementation phase that
a particular area of program functionality is extraordinarily difficult to implement. If this is the
case, it is better to revise the design than to persist in using a design that was made based on
faulty predictions and that does not account for the newly discovered problem areas.
Even without such changing of the specification during implementation, there is the option either
to start a new project from scratch, "on a green field", or to continue some already existing, "a
brown field" (from construction again). The waterfall methodology can be used for continuous
enhancement, even for existing software, originally from another team. As well as in the case
when the system analyst fails to capture the customer requirements correctly, the resulting
impacts on the following phases (mainly the coding) still can be tamed by this methodology, in
practice: A challenging job for a QA team.
Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall
model) refers to design as a "wicked problem" — a problem whose requirements and limitations
cannot be entirely known before completion. The implication of this is that it is impossible to
perfect one phase of software development, thus it is impossible if using the waterfall model to
move on to the next phase.
David Parnas, in "A Rational Design Process: How and Why to Fake It", writes:[3]
“Many of the [system's] details only become known to us as we progress in the [system's]
implementation. Some of the things that we learn invalidate our design and we must backtrack.”
Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully
aware of the capabilities of the technology being implemented. This can lead to their
expectations, and requirements, being defined by what they "think is possible". Which may not
take advantage of the full potential of what the new technology can deliver, or simply be trying
to replicate the existing application or process with the new technology? This can result in
substantial changes to the implementation requirements once the stakeholders become more
aware of the functionality available from the new technology. An example is where an
organization is migrating from a paper based process to an electronic process. While the key
deliverables of the paper process should be maintained, the benefits of real-time data input
validation, traceability, and automated decision point routing may not be anticipated at the early
planning stages of the project.
The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the
waterfall model argue that this idea tends to fall apart when the problem being measured is
constantly changing due to requirement modifications and new realizations about the problem
itself. A potential solution is for an experienced developer to spend time up front on refactoring
to consolidate the software, and to prepare it for a possible update, no matter if such is planned

3
already. Another approach is to use a design targeting modularity with interfaces, to increase the
flexibility of the software with respect to the design.
Modified models
In response to the perceived problems with the pure waterfall model, many modified waterfall
models have been introduced. These models may address some or all of the criticisms of the pure
waterfall model.[citation needed] Many different models are covered by Steve McConnell in the
"lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
While all software development models will bear some similarity to the waterfall model, as all
software development models will incorporate at least some phases similar to those used within
the waterfall model, this section will deal with those closest to the waterfall model. For models
which apply further differences to the waterfall model, or for radically different models seek
general information on the software development process.
INCREMENTAL BUILD MODEL
The incremental build model is a method of software development where the model is
designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined as
finished when it satisfies all of its requirements. This model combines the elements of the
waterfall model with the iterative philosophy of prototyping.
The product is decomposed into a number of components, each of which are designed and built
separately (termed as builds). Each component is delivered to the client when it is complete. This
allows partial utilization of product and avoids a long development time. It also creates a large
initial capital outlay with the subsequent long wait avoided. This model of development also
helps ease the traumatic effect of introducing completely new system all at once.
There are some problems with this model. One is that each new build must be integrated with
previous builds and any existing systems. The task of decomposing product into builds is not
trivial either. If there are few builds and each build degenerates this turns into Build-And-Fix
model. However if there are too many builds then there is little added utility from each build.

SPIRAL MODEL
The spiral model is a software development process combining which elements of
both design and prototyping-in-stages, in an effort to combine advantages of top-
down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral
development), it is a systems development method (SDM) used in information
technology (IT). This model of development combines the features of the
prototyping model and the waterfall model. The spiral model is intended for large,
expensive and complicated projects.

4
History
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software
Development and Enhancement"[1]. This model was not the first model to discuss iterative
development, but it was the first model to explain why the iteration matters.[citation needed]

As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts
with a design goal and ends with the client (who may be internal) reviewing the progress thus
far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward
the end goal of the project.

[edit] Steps
The steps in the spiral model iteration can be generalized as follows:

1. The system requirements are defined in as much detail as possible. This

usually involves interviewing a number of users representing all the external
or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system. This phase is the most
important part of "Spiral Model". In this phase all possible (and available)
alternatives, which can help in developing a cost effective project are
analyzed and strategies to use them are decided. This phase has been added
specially in order to identify and resolve all the possible risks in the project
development. If risks indicate any kind of uncertainty in requirements,
prototyping may be used to proceed with the available data and find out
possible solution in order to deal with the potential changes in the
requirements.
3. A first prototype of the new system is constructed from the preliminary
design. This is usually a scaled-down system, and represents an
approximation of the characteristics of the final product.

5
 4. A second prototype is evolved by a fourfold procedure:
1. evaluating the first prototype in terms of its strengths, weaknesses,
and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.

[edit] Applications
Game development is a main area where the spiral model is used and needed, that is because of
the size and the constantly shifting goals of those large projects.[2]

The spiral model is mostly used in large projects. For smaller projects, the concept of agile
software development is becoming a viable alternative. The US military has adopted the spiral
model for its Future Combat Systems program. The FCS project was canceled after six years
(2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive
prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009. Spiral model
thus may suit small (up to $3M) software applications and not complicated ($3B) distributed,
interoperable, system of systems.

Also it is reasonable to use the spiral model in projects where business goals are unstable but the
architecture must be realized well enough to provide high loading and stress ability. For
example, the Spiral Architecture Driven Development is the spiral based SDLC which shows the
possible way how to reduce a risk of non effective architecture with the help of spiral model in
conjunction with the best practices from other models.

V-MODEL
The V-model is a software development process (also applicable to hardware
development) which can be presumed to be the extension of the waterfall model.
Instead of moving down in a linear way, the process steps are bent upwards after
the coding phase, to form the typical V shape. The V-Model demonstrates the
relationships between each phase of the development life cycle and its associated
phase of testing. The horizontal and vertical axes represents time or project

6
completeness (left-to-right) and level of abstraction (coarsest-grain abstract

ion uppermost), respectively.

Verification Phases
[edit] Requirements analysis

In the Requirements analysis phase, the requirements of the proposed system are collected by
analyzing the needs of the user(s). This phase is concerned about establishing what the ideal
system has to perform. However it does not determine how the software will be designed or
built. Usually, the users are interviewed and a document called the user requirements document
is generated.

The user requirements document will typically describe the system’s functional, physical,
interface, performance, data, security requirements etc as expected by the user. It is one which
the business analysts use to communicate their understanding of the system back to the users.
The users carefully review this document as this document would serve as the guideline for the
system designers in the system design phase. The user acceptance tests are designed in this
phase. See also Functional requirements.

[edit] System Design

Systems design is the phase where system engineers analyze and understand the business of the
proposed system by studying the user requirements document. They figure out possibilities and
techniques by which the user requirements can be implemented. If any of the requirements are
not feasible, the user is informed of the issue. A resolution is found and the user requirement
document is edited accordingly.

The software specification document which serves as a blueprint for the development phase is
generated. This document contains the general system organization, menu structures, data
structures etc. It may also hold example business scenarios, sample windows, reports for the

7
better understanding. Other technical documentation like entity diagrams, data dictionary will
also be produced in this phase. The documents for system testing are prepared in this phase.

[edit] Architecture Design

The phase of the design of computer architecture and software architecture can also be referred
to as high-level design. The baseline in selecting the architecture is that it should realize all
which typically consists of the list of modules, brief functionality of each module, their interface
relationships, dependencies, database tables, architecture diagrams, technology details etc. The
integration testing design is carried out in the particular phase.

[edit] Module Design

The module design phase can also be referred to as low-level design. The designed system is
broken up into smaller units or modules and each of them is explained so that the programmer
can start coding directly. The low level design document or program specifications will contain a
detailed functional logic of the module, in pseudocode:

• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.

The unit test design is developed in this stage.

[edit] Validation Phases

[edit] Unit Testing

In computer programming, unit testing is a method by which individual units of source code are
tested to determine if they are fit for use. A unit is the smallest testable part of an application. In
procedural programming a unit may be an individual function or procedure. Unit tests are created
by programmers or occasionally by white box testers.

[edit] Integration Testing

In integration testing the separate modules will be tested together to expose faults in the
interfaces and in the interaction between integrated components. Testing is usually black box as
the code is not directly checked for errors.

[edit] System Testing

System testing will compare the system specifications against the actual system.After the
integration test is completed, the next test level is the system test. System testing checks if the

8
integrated product meets the specified requirements. Why is this still necessary after the
component and integration tests? The reasons for this are as follows:

Reasons for system test

a) In the lower test levels, the testing was done against technical specifications, i.e., from the
technical perspective of the software producer. The system test, though, looks at the system from
the perspective of the customer and the future user. The testers validate whether the requirements
are completely and appropriately met.

Example - The customer (who has ordered and paid for the system) and the user
(who uses the system) can be different
groups of people or organizations with their own specific interests and
requirements of the system.

b) Many functions and system characteristics result from the interaction of all system
components, consequently, they are only visible on the level of the entire system and can only be
observed and tested there.

[edit] User Acceptance Testing

Acceptance testing is the phase of testing used to determine whether a system satisfies the
requirements specified in the requirements analysis phase. The acceptance test design is derived
from the requirements document. The acceptance test phase is the phase used by the customer to
determine whether to accept the system or not. The following description is unacceptable in and
overview article Acceptance testing:
- To determine whether a system satisfies its acceptance criteria or not.
- To enable the customer to determine whether to accept the system or not.
- To test the software in the "real world" by the intended audience.
Purpose of acceptance testing:
- To verify the system or changes according to the original needs.

Procedures for conducting the acceptance testing:

Define the acceptance criteria:
- Functionality requirements.
- Performance requirements.
- Interface quality requirements.
- Overall software quality requirements.
Develop an acceptance plan:
- Project description.
- User responsibilities.
- Acceptance description.
- Execute the acceptance test plan.
- to develop

9
The General Model
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. There are tons of models, and many companies adopt their own, but all
have very similar patterns. The general, basic model is shown below:

General Life Cycle Model

Each phase produces deliverables required by the next phase in the life cycle. Requirements are
translated into design. Code is produced during implementation that is driven by the design.
Testing verifies the deliverable of the implementation phase against requirements.

Requirements

Business requirements are gathered in this phase. This phase is the main focus of the project
managers and stake holders. Meetings with managers, stake holders and users are held in order
to determine the requirements. Who is going to use the system? How will they use the system?
What data should be input into the system? What data should be output by the system? These
are general questions that get answered during a requirements gathering phase. This produces a
nice big list of functionality that the system should provide, which describes functions the system
should perform, business logic that processes data, what data is stored and used by the system,
and how the user interface should work. The overall result is the system as a whole and how it
performs, not how it is actually going to do it.

Design

The software system design is produced from the results of the requirements phase. Architects
have the ball in their court during this phase and this is the phase in which their focus lies. This
is where the details on how the system will work is produced. Architecture, including hardware
and software, communication, software design (UML is produced here) are all part of the
deliverables of a design phase.

Implementation

Code is produced from the deliverables of the design phase during implementation, and this is
the longest phase of the software development life cycle. For a developer, this is the main focus
of the life cycle because this is where the code is produced. Implementation my overlap with
both the design and testing phases. Many tools exists (CASE tools) to actually automate the
production of code using information gathered and produced during the design phase.

10
Testing

During testing, the implementation is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific
component of the system, while system tests act on the system as a whole.

So in a nutshell, that is a very basic overview of the general software development life cycle
model. Now lets delve into some of the traditional and widely used variations.

Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linear-sequential
life cycle model. It is very simple to understand and use. In a waterfall model, each phase must
be completed in its entirety before the next phase can begin. At the end of each phase, a review
takes place to determine if the project is on the right path and whether or not to continue or
discard the project. Unlike what I mentioned in the general model, phases do not overlap in a
waterfall model.

Waterfall Life Cycle Model

Advantages

• Simple and easy to use.

• Easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.

11
Disadvantages

• Adjusting scope during the life cycle can kill a project

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Poor model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes. Each phase must be completed before the next phase begins. Testing is emphasized
in this model more so than the waterfall model though. The testing procedures are developed
early in the life cycle before any coding is done, during each of the phases preceding
implementation.

Requirements begin the life cycle model just like the waterfall 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 phase focuses on system architecture and design. 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 phase is where the actual software components are designed, and unit 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.

V-Shaped Life Cycle Model

12
Advantages

• Simple and easy to use.

• Each phase has specific deliverables.
• Higher chance of success over the waterfall model due to the development of test plans
early on during the life cycle.
• Works well for small projects where requirements are easily understood.

Disadvantages

• Very rigid, like the waterfall model.

• Little flexibility and adjusting scope is difficult and expensive.
• Software is developed during the implementation phase, so no early prototypes of the
software are produced.
• Model doesn’t provide a clear path for problems found during testing phases.

Incremental Model
The incremental model is an intuitive approach to the waterfall model. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up
into smaller, more easily managed iterations. Each iteration passes through the requirements,
design, implementation and testing phases.

A working version of software is produced during the first iteration, so you have working
software early on during the software life cycle. Subsequent iterations build on the initial
software produced during the first iteration.

Incremental Life Cycle Model

Advantages

• Generates working software quickly and early during the software life cycle.
• More flexible – less costly to change scope and requirements.
• Easier to test and debug during a smaller iteration.
• Easier to manage risk because risky pieces are identified and handled during its iteration.
• Each iteration is an easily managed milestone.

13
Disadvantages

• Each phase of an iteration is rigid and do not overlap each other.

• Problems may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.

Spiral Model
The spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is
undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk
analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The
evaluation phase allows the customer to evaluate the output of the project to date before the
project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral
represents cost.

14
Spiral Life Cycle Model

Advantages

• High amount of risk analysis

• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.

Disadvantages

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

15