One of the most famous and widely used approaches for software development is the waterfall model. Waterfall approach is an old technique that has been in use for quite some time, but in modern times agile approach is gaining prominence.
Waterfall approach, as is evident from the name, refers to a systematic approach where one step comes after the other. It cannot go the other way round. The process works like the waterfall effect that flows in one direction, which is from up to down.
In this process the life cycle of the development process is predetermined. All the steps are defined before the start of the project. The approach is predictive, where the team is well aware of the order of each step and therefore works accordingly. It starts from the requirement analysis, the design phase and then proceeds on to the implementation, testing and the maintenance phases.
The waterfall approach can be quite beneficial for those who are quite clear on their requirements. A planned approach works for them because they want fixed processes and budget. Where fixed processes are beneficial, at the same time they can be inconvenient at times. In cases where the client is not clear on the requirements and finds in the middle of the project that he/she wants to change course, this approach can prove to be quite problematic.
Another point of the waterfall approach is that the requirement analysis and design of architectural structure can consume a lot of time. Extensive research is done initially as the next phases depend completely on the planning strategy. However, the good thing is that everything is thoroughly worked out and each aspect is studied beforehand. The developers in such cases know what is expected of them.
A waterfall approach works in a systematic order, with one step following the other and the testing phase comes in the end. If there are any big problems encountered in the testing phase, it means a long process to make the amends. The process can consume extra time and money.
We cannot conclude that one approach is better than the other, as every method would have its own strengths and weaknesses. The determination of success for each method depends on how it is being used and whether the approach suits the scope of work being undertaken. While one approach may be suitable for a particular project, it might become totally useless under different circumstances. For example, some believe that agile methods are not well suited for offshore development, as they require a closer contact and communication that is not possible in an offshore project.
Source by Scott Allerdice