Waterfall Model Interview Preparation Guide

The waterfall model derives its name due to the cascading effect from one phase to the other. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.

The waterfall model 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

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. 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.

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.

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.

► Testing is inherent to every phase of the waterfall model
► It is an enforced disciplined approach
► It is documentation driven, that is, documentation is produced at every stage

The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

1) It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.

2) As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.

3) The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

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

☛ Communication
☛ Planning
☛ Modeling
☛ Construction
☛ Deployment

Waterfall model is also called as the classic life cycle model as it suggests a systematic sequential approach to software development. This one of the oldest model followed in software engineering.