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
- 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.