It is a traditional model
It is a sequential design process, often used in SDLC, in
which the progress is seen as flowing steadily downwards
(like a waterfall), through the different phases :
Requirements Collection :-
- done by Business Analysts and Product Analysts
- gathering requirements
- translates business language into software language
For ex, let us consider the example of a banking software.
Feasibility Study :-
- done by software team consisting of project managers,
business analysts, architects, finance, HR, developers but
- architect is the person who tells whether the product
can be developed and if yes, then which technology is best
suited to develop it.
- here we check for,
- technical feasibility
- financial feasibility
- resource feasibility
There are 2 stages in design,
HLD High Level Design
LLD Low Level Design
HLD gives the architecture of the software product to be
developed and is done by architects and senior developers
LLD done by senior developers. It describes how each and
every feature in the product should work and how every
component should work. Here, only the design will be there
and not the code.
For ex, let us consider the example of building a house.
Coding / Programming :-
- done by all developers seniors, juniors, freshers
- this is the process where we start building the software
and start writing the code for the product.
- done by test engineers
- it is the process of checking for all defects and
- done by installation engineers
- to install the product at a clients place for using after
the software has been developed and tested.
For ex, consider the example of a software to be developed
and installed at Reliance petrol bunk.
- here as the customer uses the product, he finds certain
bugs and defects and sends the product back for error
correction and bug fixing.
- bug fixing takes place
- minor changes like adding, deleting or modifying any small
feature in the software product
100 % testing is not possible because, the way testers
test the product is different from the way customers use the
Drawbacks of Waterfall Model :-
In waterfall model, backtracking is not possible i.e, we
cannot back and change requirements once the design stage is
reached. Change in requirements leads to change in design
thus bugs enter the design which leads to change in code
which results in more bugs. Thus the requirements are
freezed once the design of the product is started.
Drawback of requirements freezing the customer may not be
satisfied if the changes he requires is not incorporated in
the product. The end result of waterfall model is not a
Major drawback of waterfall model testing is a small phase
which is done after coding. Requirement is not tested,
design is not tested, if there is a bug in the requirement,
it goes on till the end and leads to lot of re-work.
Advantages of waterfall model requirements do not change
nor does design and code, so we get a stable product.
Applications of waterfall model :-
Used in developing a simple application
- for short term projects
- whenever we are sure that the requirements
will not change
For ex, waterfall model can be used in developing a simple
calculator as the functions of addition, subtraction etc and
the numbers will not change for a long time.
Every testing process follow the waterfall model of the
1.test strategy and planning
3.test environment setup
5.defect analysis and tracking
The standard life-cycle model of software is called a "waterfall model," because it is supposed to go down through a series of steps, reminding one of the route a natural waterfall takes over a series of rocks at different levels.
In the traditional waterfall model, the first step in the software life-cycle is requirements analysis--this is the stage where the customers are queried for their needs, and a formal description of the software requirements is created. The next step is design, where the software that is to meet the requirements is planned. The third stage is implementation, where teams of developers create the software. The fourth step is testing, at which time developers, as well as representatives of the user community, are allowed to use the software and are asked to report any bugs they find. Upon completion of this step, the software is declared operational, and only maintenance tasks are required thereafter.
The traditional waterfall model is much too simplistic, however, because each of the distinct steps it asks for is really itself a broad phase consisting of many sub-steps. To give a better perspective of what these smaller steps are, a more detailed waterfall model is usually described.
In the detailed waterfall model, the requirements analysis step is extremely important. It is necessary to understand the customer's needs and to translate them into appropriate desired system behaviors. Any miscommunication with the customer could be fatal to the project as a whole, as it could result in a product that does not meet the customer's expectations, thus giving the company a bad reputation--a real disaster in the competitive software vendor's marketplace. Yet, communicating with the customer is not always easy either, because the customer may have only vaguely-formulated objectives; or may have objectives that aren't vocalized very well and remain in the background for too long; or may have unrealizable or conflicting objectives. In some cases, it is necessary for the software development team to tell the customer exactly what he wants based on his vague utterances, and also whether he can get it--needless to say, this involves a fair amount of skill at diplomacy and personal communication, in addition to knowledge of software engineering. Once the customer's requirements are understood, it is then necessary to document those requirements in a formal manner and reach an agreement with the customer about them (this is most often done in the form of a legally binding contract).
Once the requirements analysis is over, design must happen. This itself has to have at least two distinct stages, system or architectural design at the large scale, and detailed design of modules, objects, and the like at the small scale.
After the design steps, module designs are coded by programmers, and are individually tested against their specifications. Such testing is usually called unit testing of modules. After the modules have been unit tested individually, they are put together as a functioning system in a step called system integration, and the system as a whole is tested to see if it meets behavior and performance requirements.
The customer cannot be left with just the system, of coursehe will also want very detailed documentation that shows him how to use the system, what things to do or not do, and the like. The customer may also need special training in the system. For this reason, the finished product must be delivered to the customer with documentation, and possibly with training support as well. This documenting of the system and creation of training resources is considered to be part of the delivery step, but actually goes on from almost the very beginning of the software life-cycle, right in parallel with the development effort itself.
The waterfall model is conceptually simple to understand and is useful to explain the basics of software development, but even with the added detail, it is highly limited in its application as a practical method for managing such development. It is much too simplistic in its view of the software life-cycle, and focuses largely on creation of software as though it were a physical product or fixed artifact, rather than the result of incremental problem solving by a large group of diverse people. In practical software development, there are also numerous feedback loops that arise between stages--for example, a problem with the design may be discovered during implementation, leading to a reversion to the design step. The waterfall model also does not deal with hardware upgrades (a constant feature in contemporary information technology practice), incremental development, or development of later versions of software based on earlier ones.
Classic Waterfall Model
In a typical model, a project begins with feasibility
analysis. On successfully demonstrating the feasibility of
a project, the requirements analysis and project planning
begins. The design starts after the requirements analysis
is complete, and coding begins after the design is
complete. Once the programming is completed, the code is
integrated and testing is done. On successful completion of
testing, the system is installed. After this, the regular
operation and maintenance of the system takes place.
This is the process where by water is flowing from one
place to another in a very high speed from the high(hill)
level to lower level.
This is very simple model,
This occors when there is continuation of rain full