Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In “The Waterfall” approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially. Waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downward (like a waterfall) through phases of conception, initiation, Analysis, Design, construction, Testing, Production/implementation, and Maintenance. The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are: –
i. Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document. Managers discuss with their clients/customers to determine the need(s) the software will address, problems the software will solve and functionality the customer desires/ requires.
ii. System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture. Includes Logical and physical design. Logical Design is an abstract presentation of how the software data flows from input to output. Physical design determines how hardware such, storage, network
hardware meets the logical design reality.
iii. Implementation – Yielding the design into actual software. i.e. the software programmer does the actual coding to build the software according to the designed document. With inputs from the 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.
iv. Integration and Testing – Testing the software against the requirement. 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. If the requirements are not met, the system is returned back to software developers.
v. Deployment of system – Actual release of the new software into IT world. Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.
vi. Maintenance – Refers to as stabilization process. 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. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time. Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approvals/ signoff by the initial investigation, requirements definition, system Design, coding, testing, implementation, operation and support.
Advantages of Waterfall Model:
i. Waterfall model is very simple and easy to understand and use a method that is why it is really beneficial for the beginner or novice developer
ii. The orderly sequence of development steps and strict control ensures the adequacy of documentation.
iii. Design and reviews help to ensure quality and reliability of developed software.
iv. It is easy to manage, because of the rigidity of the model. Moreover, each phase has specific deliverables and individual review process
v. In this model phases are processed and completed are at once in a time thus it saves a significant amount of time
vi. Progress of software development is measurable.
vii. This type of development model works more effectively in the smaller projects where requirements are very well understood
viii. Ideal for supporting less experienced project teams and managers.
ix. The testing is easier as it can be done by reference to the scenarios defined in the earlier functional specification
x. Clearly defined stages.
xi. Well understood milestones
xii. Easy to arrange tasks.
xiii. Process and results are well documented.
Disadvantages of Waterfall Model:
i. Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
ii. Little room for use of iteration, which can reduce manageability if used.
iii. Depends upon early identification and specification of requirements, yet users may not be able to clearly define what they need early in the project.
iv. Requirements inconsistencies, missing system components, and unexpected development needs are often discovered during design and coding.
v. Problems are often not discovered until system testing.
vi. System performance cannot be tested until the system is almost fully coded; and under capacity may be difficult to correct.
vii. Difficulty to respond to changes. Changes that occur latter in the life cycle are more costly and thus discouraged.
viii. Produces excessive documentation and keeping it updated as the project progresses is time consuming.
ix. This model can only be used when very precise up-front requirements are available
x. This model is not applicable for maintenance type of projects
xi. The main drawback of this method is that once an application is in the testing stage, it is not possible to go back and edit something
xii. There is no possibility to produce any working software until it reaches the last stage of the
cycle
xiii. In this model, there is no option to know the end result of the entire project
xiv. This model is good for a small project but not ideally suitable for long and ongoing projects
xv. Not ideal for the projects where requirements are very moderates, and there is great scope for modification
Situation Where most Appropriate
• Project is large, expensive and complicated
• Project has clear objectives and solution.
• Pressure does not exist for immediate implementation.
• User community is fully knowledgeable in the business application.
• 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.
Situation Where Least Appropriate
• Large projects where the requirements are not well understood or are changing for any reason such as external changes, changing expectations, budget changes or rapidly changing technology.
