Skip to content

Latest commit

 

History

History
48 lines (38 loc) · 3.13 KB

File metadata and controls

48 lines (38 loc) · 3.13 KB

Waterfall Methodology

Table of Contents:

Introduction

Waterfall methodology, also known as the Waterfall model, is a linear sequential development process. This traditional project management approach occurs where each phase flows like a waterfall. Each phase must be completed before the next begins.

Despite having critics and supporters since its inception, the Waterfall model is still relevant today and has a place among other methodologies that have since emerged. For example, if your team is small and the project is consistent and predictable, the Waterfall framework can provide the structure to have an organized, on-track team.

Common Phases in the Waterfall Model

  1. Requirement Gathering and Documentation
  2. System Design
  3. Implementation
  4. Testing
  5. Delivery/Deployment
  6. Maintenance

In-depth description and what deliverables are expected at each phase: link

When to use the Waterfall Model

The Waterfall model is a traditional form of project management, allowing for thorough planning and detailed documentation.

The Waterfall model is most suited for projects where the requirements are constant and won't change regularly, meaning the project has a well-defined end goal. The tools and technology are consistent and stay the same. The project isn't restrained by a budget or deadline, allowing the team to spend quality time on the initial phases, requirements and system design to finalize a well-defined project plan.

Advantages of Waterfall Project Management

  • Tracking is easy as each phase has specific deliverables to measure progress.
  • Team members can manage time effectively as the requirement and design phases detail the timeline well.
  • The end goal is determined early.
  • Transfers information well between phases to new groups of people.

Disadvantages of Waterfall Project Management

  • Roadblocks can majorly setback the project's timeline due to the linear process.
  • Backtracking to a previous phase can be challenging.
  • Low amount of flexibility and adaptability after finalizing requirements and design.
  • QA is late in the process, which can lead to a problematic rework if mistakes are made earlier in the process.
  • Excludes the client and/or end user as this is a more internal process
  • Poor model for object orientated programming and for long, on-going projects

Resources