If we divide the entire development proces, from customer request, until product done, this methodology says tha the entire process must be divided into phases and most importantly – no phase should start before the previous is completed.
It’s pretty rigid and linear. The method relies heavily on all the requirements and thinking twice before you begin.
No phase should overlap other and each one fully depends on the previous one.
What we understand by phases? Tasks?
No, phases in general. For example:
Phase 1: Requirements from the Customer – this should be the only phase in which the Customer can take part and intervene. The requirements phase states:
- what the system should do;
- resources required for the project;
- what each team member will work on and at what stage;
- a timeline for the entire project, outlining how long each stage will take;
- details on each stage of the process.
Phase 2: Analysis – make sure that the Project is realistic and applicable in production, financial aspects etc…
Phase 3: Design – analyse the architecture, what technologies will be used, do we have the people for these technologies, the programming languages, the hardware and infrastructure needed…
Phase 4: Implementation – development begins…
Phase 5: Testing and Debugging…
Phase 6: Operation – the products is deployed on production…
Phase 7: Maintenance, debugging, patches, updates and additional functionality…
Waterfall methodology is suitable for cases where:
- we have fixed requirements;
- we have specifications and documentation.
Not suitable for cases where
- frequently changing requirements;
- constant new requirements from the customer;
- when updates are required ASAP.