Waterfall Methodology

Software Development Life Cycle (SDLC)

Software Development Life Cycle is a systematic approach to develop software. This cycle creates a structure for the developer to design, create, and produce/deliver high-quality software (that depend on the client requirements or end user).

Furthermore SDLC also provides a methodology for improving the quality of the product. The main purpose for implementing SDLC is to provide a cost efficient product, which is also of high quality.

There are seven types of SDLC’s and the Waterfall model is one of them, the other six are:

• Iterative model:

Breaking down the software development of a large application into smaller chunks, the iterative model makes use of repeated cycles.

• Spiral model:

Combination of iterative model and sequential linear development (Waterfall with a high emphasis on risk analysis). This model allows incremental releases of the product or incremental refinement through each iteration around the spiral.

• V-model:

Rather than allowing the processes to move down in a linear fashion like the Waterfall model, the V model process steps are bent upwards after the coding phase (like the “V” shape).

• Big Bang model:

No specific process is followed in this model. The development is initiated with the required money and the effort is considered to be the input. The output is considered to be the software developed which may or may not be to the customer requirements.

• RAD model:

Functional modules are developed in parallel as the prototypes are integrated to make the complete product for faster product delivery. The customer can provide early feedback on the design, delivery, and other requirements, as they have early visibility.

• Prototype model:

A throwaway prototype is built to understand the requirements rather than freezing the requirements for the design and coding that are required to begin.

This prototype is developed based on the requirements that are already known.

(This paper will only focus on the Waterfall model)

What is the Waterfall methodology?

Although Herbert D. Benington had mentioned the phases similar to that of a Waterfall back in 1956 during his presentation for Semi Automatic Ground Environment (SAGE), the first formal description of the Waterfall model was cited around the 1970s in an article by Winston W. Royce, who was an American computer scientist. Winston as a matter of fact was describing the flaws of such systems. It was only until 1985 that the six phases of the Waterfall model were acknowledged by the United States Department of Defence.

The Waterfall model is considered to be the first “Process Model” to be introduced. The model is described to be a breakdown of project activities into linear sequential phases, were each phase depends on the product and deliverables of the subsequent phase.

The Waterfall model was first adopted in the construction and manufacturing industries, which in these industries meant that any changes made throughout the development process became extremely expensive. 

When the Waterfall model was used for software development, there was no recognised alternative for knowledge based work. This is why it is known to be the earliest type of Software Development Life Cycle (SDLC).

The Waterfall model is divided into separate phases, and as mentioned above the outcome of the current phase will depend on the phase that was just completed as they must be executed sequentially. These phases are:

1. Requirements Analysis
2. System Design
   • High level design phase
   • Low level design phase
3. Implementation
4. Testing
5. Deployment
6. Maintenance

Although throughout the years, the popularity of the Waterfall model has decreased, in favour of other methodologies such as agile, the logical nature of the sequential process used in the Waterfall methodology cannot be denied, and it remains to be a common design process in industry.

Stages of Waterfall methodology

As the name of the process emphasises, the Waterfall downward mechanism functions similarly to a Waterfall.

The process is divided into subsequent stages, and it is extremely important to complete each step completely and successfully to move onto the next step.

These steps consist of 6 stages which are described in detail below:

• Requirements Analysis:

In the requirements analysis phase, all the prerequisite demands of the project are analysed and documented into a specification document, furthermore, these requirements are analysed to check if they are feasible to be successfully completed within the project realms and to check if they are valid.

In this phase, it is mandatory to consider any constraints and/or limitations that the project may carry, for instance: time or budget constraints. Ultimately these are the considerations, which may affect the development process and decrease productivity.

After all these considerations and analysis, a “Requirements Understanding Document” “RUD” is produced.

• System Design:

This phase will cover the technical design requirements, which includes hardware and system requirements, for instance, data layers, network infrastructure, user interface, and programming languages etc.

System design can be divided into two further phases to break down the understanding and implementation:

• High level design phase:

The high-level design phase includes a list of functionality modules, correlation modules, architecture diagrams, and database tables. This phase will conclude with the creation of a high-level design document.

• Low level design phase:

The low-level design phase involves the designing of the actual software components, which will be used in the system.

The modules in the high-level design phase are broken down into separate modules, and pseudo-code is written to aid the programmer in coding when development is initiated.

Moreover, the low-level design phase also includes interface details, dependency issues, error-message listings, and inputs and outputs for each module.

• Implementation:

In this phase, as the name would imply, the source code is written as per the requirements that were developed and assigned. In-essence, the physical design specification is created into the working code for the system.

The software system is developed in small program fragments, which are referred to as “units”. Once these units are completed, they are integrated into the system.

Each unit will be tested after completion to make sure that they function correctly as required, this process is referred to as “unit testing”.

• Testing:

Once the code is completed, it will be given to the testing team, where individuals will check for all possible errors/defects, by running test cases either automatically or manually.

Generally testers will allow the code to go through very rigorous test cases to see the levels to which is can withstand and function without producing errors/defects.

Furthermore, in this phase the client/end-user is also involved, this is to ensure that all requirements are met to their desired needs.

All errors/defects detected during this stage are fixed to ensure quality assurance, thus making it uncommon for the implementation phase to be visited again, in order to fix the errors/bugs.

• Deployment:

When this stage is reached, the system should be ready to be deployed onto the live environment (i.e. the client server), in order to analyse and test the performance of what was created. Once the all clear is taken, and everything is fine with the system from the client server point of view, the system becomes available for the end users to make use off.

• Maintenance:

Once the deployment phase is a success and everything is running smoothly, the last step is to provide constant support and maintenance to the system software, ensuring and guaranteeing that the system runs smoothly with possible changes to the environment, moreover, the system must be abled to be maintained to provide a better user experience if possible, when new releases are available.

Therefore “patches” are released to make sure that these changes are delivered in the client environment. 

Examples of Waterfall model applications

One of the key factors to consider with the Waterfall methodology is time, back in the day, when Waterfall was implemented quite heavily, systems and software’s had a very large development time period.

Although Waterfall is less used nowadays, there are still areas where the Waterfall model is continued to be used/preferred.

• Situations where human safety comes first, and time and money is the secondary considerations.
• Development of Department of Defence, military and aircraft programs follow the Waterfall methodology.

In such industries, the requirements are known in advance and the contracts are very specific about the desired product that will be delivered.

Other industries, which utilise the Waterfall model can also, include healthcare, control system for nuclear facilities, space shuttles etc.

Despite the above, more industries tend to lean towards the Agile methodology, as it suites there development, like Space X.

When to use the Waterfall model?

• The Waterfall model is used when the desirable requirements and are very well known, clear and fixed(they don’t change).
• Technology is understood.
• Product definition is stable.
• There are no ambiguous requirements for development.
• A large amount of resources with the required expertise is freely available.

There is very little client, customer interaction during the development phase of the project when using Waterfall. It is only when the product is ready, it can be demonstrated to the client/end-user

Though one key factor to consider when implementing Waterfall is to make sure that the development is perfect, as any error or defect can be extremely costly, due to developers needing to update everything from document to logic.

Despite the above, most industries and companies nowadays are using other models such as Iterative, Agile etc.

Advantages of Waterfall methodology

Adapts to shifting teams:

Waterfall methodology allows the project to maintain a more detailed, robust scope and design stricter due to the preplanning and documentation stages.

This is particularly beneficial for large teams that may see an exchange of members in the team (individuals leaving and new individuals being added) throughout the lifecycle of the project.

Forces structured organisation:

Waterfall methodology allows the project and organisation to be disciplined in its design and structure.

Allows for early design changes:

Altering changes when a project is complete or near completion can be extremely hard and difficult. The advantage of the Waterfall methodology is that it allows changes that are necessary to be distinguished at the early stages of development, rather than later on.

Suited for milestone focused development:

Due to the inherent linear structure of the Waterfall methodology, this will suite organisations that work well with milestones and make use of date focused developments.

With a clear understanding of the what the team must achieve, it is considered to be more simple to develop a timeline for the entire process and hence assign individuals milestones for each stage in development.

Other advantages include:

• Suited for milestone-focused development.
• Simple and easy to use and understand.
• The Waterfall model is easy to manage due to its rigidity of the model, each phase has specific deliverables and a review process.
• Process and results are documented in good detail.
• The stages are well defined and clear with no ambiguity.
• Works well for small projects that have well defined requirements.
• Changes are done during the development, rather than deploying it, and then finding out that there are error/defects.

 Disadvantages of the Waterfall methodology

Non-adaptive design constraints:

Arguably the biggest disadvantage of using the Waterfall methodology is its inherent lack of adaptability across all stages of the development life cycle.

When a flaw is realised at the testing stage of a process, it requires a dramatic leap backward in stages of the process, but in some cases, this can also lead to the realisation regarding the legitimacy of the whole system. Although this case shouldn’t happen in theory, if the system was designed properly in the first stage, although sometimes not every possibility can be accounted for, especially when stages (like testing) are so often delayed until the very end of the process.

Ignores mid process feedback:

Due to strict step-by-step process that Waterfall methodology entails and no overlapping between stages, client/end-user feedback that is provided may be too late in the cycle. While the project managers can deploy a role back to the previous stage, this can be costly and time consuming for both development team and client, so it is detrimental to understand the clients objectives and desires at the very beginning.

Delayed testing period:

Although most SDLC models incorporate testing as a fundamental objective throughout the development, the Waterfall model on the other hand only introduces testing at the very end of development life cycle. This can lead to more bugs being introduced all at once, furthermore, this can showcase design issues or flaws in the system.

Other disadvantages include:

• Working software is produced late during the life cycle, which will lead to high amount of risk and uncertainty.
• Not fitting for complex object oriented projects (OOP).
• Poor methodology for long term and ongoing projects.
• Adjusting the scope during the life cycle can potentially end the project.
• Integration is completed like a “big bang” at the end of the project, this doesn’t allow to identify any business or technological bottlenecks or any challenges early in the life cycle.
• Waterfall methodology is not suitable for projects which contain requirements that have a possibility of changing.
• It is difficult to measure progress within stages.
• Reduces efficiency by not allowing process to overlap.

Summary and Facts

What is the Waterfall methodology?

Software development is a process that entails the creation and maintenance of systems, applications, frameworks, and other software elements.

The Waterfall model is considered to be the first “Process Model” to be introduced. The model is described to be a breakdown of project actives into linear sequential phases, where each phase depends on the product and deliverables of the subsequent phase.

The Waterfall model puts emphasis on logical progression steps to be taken throughout the software development life cycle (SDLC).

Stages of Waterfall methodology:

1. Requirements Analysis
2. System Design
   • High level design phase
   • Low level design phase
3. Implementation
4. Testing
5. Deployment
6. Maintenance

Advantages of Waterfall methodology:

• Adapts to shifting teams.
• Forces structured organisation.
• Allows for early design changes.
• Suited for milestone-focused development.
• Simple and easy to use and understand.
• The Waterfall model is easy to manage due to its rigidity of the model, each phase has specific deliverables and a review process.
• Process and results are documented in good detail.
• The stages are well defined and clear with no ambiguity.
• Works well for small projects that have well defined requirements.
• Changes are done during the development, rather than deploying it, and then finding out that there are error/defects.

Disadvantages of the Waterfall methodology:

• Non-adaptive design constraints
• Ignores mid process feedback
• Delayed testing period
• Working software is produced late during the life cycle, which will lead to high amount of risk and uncertainty.
• Not fitting for complex object oriented projects (OOP).
• Poor methodology for long term and ongoing projects.
• Adjusting the scope unrig the life cycle can potentially end the project.
• Integration is completed as a “big bang” at the end of the project, this doesn’t allow to identify any business or technological bottlenecks or any challenges early in the life cycle.
• Waterfall methodology is not suitable for projects, which contain requirements that have a possibility of changing.
• It is difficult to measure progress within stages.
• Reduces efficiency by not allowing process to overlap.

References:

1. https://rezaid.co.uk/sdlc-waterfall-model/
2. http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
3. http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html
4. https://www.toolsqa.com/software-testing/software-development-life-cycle/
5. http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/
6. https://searchsoftwarequality.techtarget.com/definition/waterfall-model
7. https://en.wikipedia.org/wiki/Waterfall_model#cite_note-benington-1
8. https://www.guru99.com/what-is-sdlc-or-waterfall-model.html
9. https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
10. https://airbrake.io/blog/sdlc/waterfall-model
11. https://www.toolsqa.com/software-testing/waterfall-model/#:~:text=The%20waterfall%20model%20is%20a,Production%2FImplementation%2C%20and%20Maintenance