Waterfall Methodology

I have told you in my previous articole about existing SDLC methodologies that can be used in the software creation process.

This article is the first one in a series of articles that describe in detail the methodologies mentioned before.

I will start with Waterfall methodology, as it is one of the most common and oldest ones (actually, it was the first SDLC model to be used), being encountered in many of the existing companies. It is a pretty inflexible methodology which supposes that all the requirements are well defined before the development start. SDLC phases are followed rigurously at a low level, meaning that each phase starts after the previous one has finished completely. Testing phase usually starts after the development is finished, so the advantage of early testing is not used.

The waterfall SDLC methodology was first introduced by Winston Royce in 1970 and it  was the first public documented life cycle model. 

The waterfall methodology is divided into the following phases:

  • Requirements gathering – Define the characteristics of the product and record them into the requirements document
  • System Design – Based on the requirements, the company must study the existing resources and decide whether some new hardware is needed or some software upgrades are required
  • Implementation and Execution – After the requirements are designed and the system preconditions have been met, the product is created based on the previously created specifications
  • Testing – The testing phase follows the implementation step, and has the purpose of finding potential defects of the software and to increase confidence into the end product
  • Release – After the testing is complete, the product is released into production, meaning that it is made accessible for the use of the end user
  • Maintenance – The process in which we make sure the preconditions in which the software works are met. It could be a hardware upgrade, a software version increase or any other type of maintenance.

Advantages of Waterfall methodology

  • Easy to understand
  • Easy to use and manage
  • Works very well for short projects
  • It guarantees predictability, so you can trust the timelines with reduced possibility to exceed deadlines
  • You know ever since the beginning what to expect and how would the result will look like
  • The entire process is well documented, so any new person being assigned on the project can easily understand what the project to be developed is supposed to do

Downfalls of the Waterfall methodology

  • It is very inflexible, so changing the requirements in the middle of the development process is pretty hard
  • If you have a high amount of risk that is identified, then waterfall might not be appropriate. A risk might imply changing the requirements and, of course, the code, so that you can mitigate it.
  • Defects are only found in the testing phase, when the product is already fully developed. So, instead of creating tests for a single future or module, you create tests for the entire project, which increases the risk of missing something.
  • Working software is available late in the SDLC process, so feedback can only be provided from user when many defects already appeared
  • Usually a series of test cases is followed blindly, and most of the times the tester doesn’t try to find some other test cases. If he does, this would mean to change the test plan, test deadline, test report, depending of the new number of tests that are to be found, and sometimes additional development resources need to be included in the project
  • If a requirements change necessity is detected during the implementation, then most of the times it must be treated as a separate project

When to use Waterfall methodology

  • Short projects with a low level of complexity
  • Projects with a low level of risk
  • Projects where the requirements are very well known ever since the beginning and the probability of requirements changing is small
  • The team is experienced and knows very well the technology to be used

Why is it called waterfall? Because the project phases are performed in a linear way, and the output of one phase is the input for the next one, just like the waterfall passes some location coordinates to enter some others.

According to Wikipedia, the earliest use of the term waterfall may have been in a 1976 paper by Bell and Thayer.

If you want to learn more about the waterfall methodology, you could take a look at Software Engineering Methodologies: A Review of the Waterfall Model and ObjectOriented Approach, and of course you could check the official syllabus provided by the ISTQB official website.

I will come back with my next article about the Agile methodology.

2 thoughts on “Waterfall Methodology”

Leave a Reply