Waterfall Software Development Methodology

In one of our recent blog posts, we looked at various development models and what makes them different. One of the models we discussed was Waterfall Software Development. In this article we’ll look at the Waterfall model in a bit more detail, exploring its advantages and disadvantages.

What is the Waterfall Model?

The Waterfall model has been around for more than forty years. It was first described in a 1970 article, as one of the very first formal software development process models.
We often describe Waterfall as a ‘linear-sequential lifecycle model’. This means that it follows a simple structure of phases where the results of each phase cascade down to the next level of development. In other words, we’re not so much looking at one big Niagara Falls, but a series of cascading waterfalls – each with their own little pool of activities.

The original model consisted of five stages:

  1. Requirements
  2. Design
  3. Implementation
  4. Verification
  5. Maintenance

There are several well-recognised waterfall methodologies. One of them is PRINCE2, which was created by the UK Government and is still held in high regard in the public sector.

Waterfall is often placed on the opposite end of the software development spectrum to Agile development. One of the key differences between the two methodologies is that Waterfall requires everything to be described in written documentation before any code is created. This approach makes it crucially important that all requirements are meticulously defined from the start, as it might be difficult to revise them later.

The pros and cons of Waterfall Development

  • Pro: Everyone gets up to speed quickly
    Since technical documentation is a necessary part of the initial requirements phase, this means that everyone understands the objectives. New developers can get up to speed quickly – even during the maintenance phase.
  • Pro: Timescales are kept
    The phased development cycle enforces discipline. Each step has a clearly defined starting point and conclusion, which makes progress easy to monitor. This helps reduce any project “slippage” from agreed timescales.
  • Pro: No financial surprises
    Costs can be estimated with a fairly high degree of accuracy once the requirements have been defined.
  • Pro: Testing is made easy
    Test scenarios are already detailed in the functional specification of the requirements phase, which makes the testing process easier and more transparent.
  • Pro: The outcome is crystal clear
    Even before the software development starts, the design is hammered out in detail which makes the needs and the outcome clear to everyone.
  • Pro: Deal with issues in the design
    Potential development issues can be researched and tackled in the design stage – and alternative solutions planned – before any programming takes place.
  • Pro: What you plan is what you get
    Many organisations appreciate the attention to documentation right at the beginning, as it also means there should be no surprises with the end product.
  • Con: Needs can be difficult to define
    Clients may find it challenging to conceptualise their needs in terms of a functional specification during the requirements phase. This means that they may change their minds once they see the end product, which is difficult to address if the application needs to be re-engineered to any large extent.
  • Con: Potential lack of flexibility
    There may be issues with the flexibility of the model to cater for new developments or changes of requirements which may occur after the initial consultation. Changes due to business plans or market influences may not have been taken into account when planning is all done up front.
  • Con: Longer delivery time
    Projects may take longer to deliver, compared to using an iterative methodology such as Agile.

The conclusion

When it comes to Waterfall Development, it is critical that the software developers involved are able to guide and advise clients effectively in order to circumvent problems later. This is often the most criticised aspect of waterfall development – that the customer doesn’t really know what they want.

In many cases, the genuine two-way interaction between developers and clients doesn’t start to happen until the client can actually see the model in action. (Agile development, as a comparison, lets the client see chunks of working code developed and demonstrated throughout the entire process.)

Based on these pros and cons, Waterfall development is generally recommended for projects that are not expected to change or to need new developments during the project lifecycle.