Well-known Waterfall Practices

Every programmer knows that Waterfall is the most popular software development methodology. It is widely used by teams and companies all over the world since it originated in 1950s. Every methodology has a number of practices that should be applied in order to manage its projects. Waterfall is no exception. In this article we will tell you about Waterfall rules and practices. But before doing that we have to give the definition of Waterfall.

As we have already mentioned, Waterfall is the most popular software development methodology that originated in 1950s. That is why it is often called the traditional model of software development. At the time of its origin it was actually a hardware development methodology applied to software development industry.

Most software developers agree that strict structure and strong documentation are the main distinctive features of all Waterfall projects. Actually, the methodology has three principles: low customer involvement, strong documentation, and sequential structure of projects. These principles formulate the best and the worst Waterfall practices. But before describing them, we should find the proper definition for Waterfall practice.

Any action performed by software developers in the process of Waterfall project realization can be called a Waterfall practice. Most programmers agree that Waterfall practices are subdivided in good and bad. Good practices are the advantages of Waterfall methodology. They help the teams finish their projects in time. Bad practices are things that make Waterfall projects last longer. They are considered the disadvantages of this methodology.

Now let’s look at the Waterfall practices list in greater detail.

Low customer involvement is the main distinctive feature of Waterfall. It can be called one of its practices. Waterfall teams do not involve their clients in the process of project realization. Usually they conduct only two meetings with the customer during every project. The first of them takes place before the work starts. The main goal of this meeting is to define the customer’s demands and to document them. The second meeting is conducted only after the final software product is ready. The practice of low customer involvement can be considered good or bad depending on the situation. Most clients like it because it allows them not to participate in all team meetings. However, in some cases this practice leads to low customer acceptance of the final product.

The second well known Waterfall practice is its strong documentation. Waterfall developers begin to create project documentation from the first meeting with their customer. The process is continued at the stage of design. All further stages of Waterfall projects are based on documents. Most software developers consider this feature a great advantage of Waterfall methodology, because it allows them to perform the initial plan of the project strictly without changing it. However, Waterfall teams waste lots of time while handling their documents. That is a disadvantage of this practice.

All Waterfall projects are subdivided into 5 or 7 sequential stages. They should be performed one after another without changing their order. Sequential structure of projects is often called the most important Waterfall practice. It is the key feature of this methodology. In most cases this practice is useful and helps the developers perform their tasks in time. However, it has a large disadvantage. Waterfall developers cannot return to the previous stage of work if it is finished. It means that they have to run their projects from the very beginning every time when they detect a bug that cannot be fixed at the stage of testing.

The structure of Waterfall teams is often called one of the practices of this methodology. Waterfall teams are large. They usually include more than 15 people. They work in separate offices and perform the tasks in accordance with their roles. Unlike Agile teams, Waterfall teams have lots of roles, including programmers, analysts, testers, and managers. The structure of such teams is strictly hierarchical. Each Waterfall team has a leader called a project manager. He is the main person responsible for the final product.