The Waterfall Methodology
Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like:
- Gather and document requirements
- Design
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
In a true Waterfall development project, each of these represents a distinct phase of software development, and each phase generally finishes before the next one can begin. There is also typically a stage-gate between each; for example, requirements must be reviewed and approved by the customer before design can begin. There are good things and bad about the Waterfall approach. On the positive side:
- Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing more straightforward.
- Progress is more easily measured, as the full scope of the work is known in advance.
- Through out the development effort, it is possible for various members of the team to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway.
- Except for reviews, approvals, status meetings, etc., a customer presence is not strictly required after the requirements phase.
- Because design is completed early in the development life span, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.
- Finally, the software can be designed completely and more carefully, based upon a more complete understanding of all software deliverables. This provides a better software design with less likelihood of the "piecemeal effect," a development phenomenon that can occur as pieces of code are defined and subsequently added to an application where they may or may not fit well.
Here are some issues that our author has encountered using a pure Waterfall approach:
- One area that almost always falls short is the effectiveness of requirements. In my opinion, gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development. Specific details, provided early in the project, are required with this approach, but customers are sometimes intimidated by such details. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there's no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.
- Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it's almost finished. By that time, changes can be difficult (and costly) to implement.
|
Introduction
