WaterFall Methdologies

Waterfall Methodology

There are 7 stages to the waterfall methodology, see diagram below

Stage 1 – Requirement gathering and documentation

Gathering all possible requirements for a project on what needs to be done, and have a product requirement documents for what each set task needs to be completed before moving onto the next stage.

Stage 2 – System Design

The system will have a design built based on the analysis design of the software architecture, this defines all the schemes, models and rules.

Stage 3 – Implementation

Is the development of the software using small units with functional testing.

Stage 4- Testing

This stage integrates all the work done up until now and would test the entire system for any faults, any issues found make it very difficult to go back and fix any changes.

Step 6 – Delivery /Deployment

Making the product live after all functional and non-functional testing is completed.

Step 7- Maintenance

Fixing issues and releasing new versions via a patch

Pros

1. Using Clear Structure

When compared with other methodologies waterfall focuses on a very clear and set goal. It uses a set of step (Explained above), team members must complete each step before moving onto the next step. If any issues occur during the testing phase projects are not going to be pushed aside as half-finished projects but leave the team with more completed and polished project.

      2.  Determines the end goals early

One of the defining steps of the waterfall is committing to an end product goal. The team should avoid deviating away from that, for small projects where’s the goals are clear this makes your team aware and less likely for getting lost in the details as the project moves forward.

            3. Transfers information well

Waterfall approach is highly methodical, when applied in a software setting, every new step involves a new group of people and though that might not be the case in other companies, they should still aim to document the information throughout whether passing projects off or passing it onto another team member. It’s easier to pick up than other methodologies.

Cons

1.     
                1. Makes changes difficult

Waterfall is based entirely on following a set of steps that keep teams always moving forward. It leaves no room for unexpected changes or revision. if you need to pivot round to fix something you’ll have to put a considerable amount of time and work to find out where to issue occurred which can throw off the entire timeline.

2.   
                2. Excludes the client and/or end user

One of the defining steps of the waterfall is committing to an end product goal. The team should avoid deviating away from that, for small projects where’s the goals are clear this makes your team aware and less likely for getting lost in the details as the project moves forward.

3.     
          3. Transfers information well

Waterfall approach is highly methodical, when applied in a software setting, every new step involves a new group of people and though that might not be the case in other companies, they should still aim to document the information throughout whether passing projects off or passing it onto another team member. It’s easier to pick up than other methodologies.