Say the words “waterfall development” to most
people and chances are they’re going to be thinking of a bunch of condos under
Niagara Falls. Imagine their surprise, then, when you tell them that waterfall
development is actually a software development model which involves a phased
progression of activities leading to the release of a software product. This
article provides a quick and dirty introduction to the model, explaining what
it is, how it’s supposed to work, and why it can fail.
Waterfall development isn’t new — it’s been around since
1970 — but most developers still only have a vague idea of what it means.
Essentially, it’s a framework for software development in which development
proceeds sequentially through a series of phases, starting with system
requirements analysis and leading up to product release and maintenance.
Feedback loops exist between each phase, so that as new information is
uncovered or problems are discovered, it is possible to “go back” a
phase and make appropriate modification. Progress “flows” from one
stage to the next, much like the waterfall that gives the model its name.
A number of variants of this model exist, with each one
quoting slightly different labels for the various stages. In general, however,
the model may be considered as having six distinct phases, described below:
first step is also the most important, because it involves gathering
information about what the customer needs and defining, in the clearest
possible terms, the problem that the product is expected to solve.
Analysis includes understanding the customer’s business context and
constraints, the functions the product must perform, the performance
levels it must adhere to, and the external systems it must be compatible
with. Techniques used to obtain this understanding include customer
interviews, use cases, and “shopping lists” of software
features. The results of the analysis are typically captured in a formal
requirements specification, which serves as input to the next step.
- Design: This
step consists of “defining the hardware and software architecture,
components, modules, interfaces, and data…to satisfy specified
requirements” (Wikipedia). It involves
defining the hardware and software architecture, specifying performance
and security parameters, designing data storage containers and
constraints, choosing the IDE and programming language, and indicating
strategies to deal with issues such as exception handling, resource
management and interface connectivity. This is also the stage at which
user interface design is addressed, including issues relating to
navigation and accessibility. The output of this stage is one or more
design specifications, which are used in the next stage of implementation.
- Implementation: This
step consists of actually constructing the product as per the design
specification(s) developed in the previous step. Typically, this step is
performed by a development team consisting of programmers, interface
designers and other specialists, using tools such as compilers, debuggers,
interpreters and media editors. The output of this step is one or more
product components, built according to a pre-defined coding standard and
debugged, tested and integrated to satisfy the system architecture
requirements. For projects involving a large team, version control is
recommended to track changes to the code tree and revert to previous
snapshots in case of problems.
- Testing: In this
stage, both individual components and the integrated whole are
methodically verified to ensure that they are error-free and fully meet
the requirements outlined in the first step. An independent quality
assurance team defines “test cases” to evaluate whether the
product fully or partially satisfies the requirements outlined in the
first step. Three types of testing typically take place: unit testing of
individual code modules; system testing of the integrated product; and
acceptance testing, formally conducted by or on behalf of the customer.
Defects, if found, are logged and feedback provided to the implementation
team to enable correction. This is also the stage at which product
documentation, such as a user manual, is prepared, reviewed and published.
- Installation: This
step occurs once the product has been tested and certified as fit for use,
and involves preparing the system or product for installation and use at
the customer site. Delivery may take place via the Internet or physical media,
and the deliverable is typically tagged with a formal revision number to
facilitate updates at a later date.
- Maintenance: This
step occurs after installation, and involves making modifications to the
system or an individual component to alter attributes or improve
performance. These modifications arise either due to change requests
initiated by the customer, or defects uncovered during live use of the
system. Typically, every change made to the product during the maintenance
cycle is recorded and a new product release (called a “maintenance
release” and exhibiting an updated revision number) is performed to
enable the customer to gain the benefit of the update.
The waterfall model, as described above, offers numerous
advantages for software developers. First, the staged development cycle
enforces discipline: every phase has a defined start and end point, and
progress can be conclusively identified (through the use of milestones) by both
vendor and client. The emphasis on requirements and design before writing a
single line of code ensures minimal wastage of time and effort and reduces the
risk of schedule slippage, or of customer expectations not being met.
Getting the requirements and design out of the way first
also improves quality; it’s much easier to catch and correct possible flaws at
the design stage than at the testing stage, after all the components have been
integrated and tracking down specific errors is more complex. Finally, because
the first two phases end in the production of a formal specification, the
waterfall model can aid efficient knowledge transfer when team members are
dispersed in different locations.
Despite the seemingly obvious advantages, the waterfall
model has come in for a fair share of criticism in recent times. The most
prominent criticism revolves around the fact that very often, customers don’t
really know what they want up-front; rather, what they want emerges out of
repeated two-way interactions over the course of the project. In this
situation, the waterfall model, with its emphasis on up-front requirements
capture and design, is seen as somewhat unrealistic and unsuitable for the
vagaries of the real world. Further, given the uncertain nature of customer
needs, estimating time and costs with any degree of accuracy (as the model
suggests) is often extremely difficult. In general, therefore, the model is
recommended for use only in projects which are relatively stable and where
customer needs can be clearly identified at an early stage.
Another criticism revolves around the model’s implicit
assumption that designs can be feasibly translated into real products; this
sometimes runs into roadblocks when developers actually begin implementation.
Often, designs that look feasible on paper turn out to be expensive or
difficult in practice, requiring a re-design and hence destroying the clear
distinctions between phases of the traditional waterfall model. Some criticisms
also center on the fact that the waterfall model implies a clear division of labor
between, say, “designers”, “programmers” and
“testers”; in reality, such a division of labor in most software
firms is neither realistic nor efficient.
While the model does have critics, it still remains useful
for certain types of projects and can, when properly implemented, produce
significant cost and time savings. Whether you should use it or not depends
largely on how well you believe you understand your customer’s needs, and how
much volatility you expect in those needs as the project progresses. It’s worth
noting that for more volatile projects, other frameworks exists for thinking
about project management, notably the so-called spiral model…but that’s a
story for another day!