Waterfall versus cyclical project management

By June 20, 2015

The six-phase model is a waterfall model. In other words, the phases take place in
succession. Just as it is impossible to swim upstream against a waterfall, the pure
waterfall method does not allow returning to a phase after it has been completed.
During the implementation phase, it is not desirable to decide to adapt the design,
thereby bringing implementation to a standstill. For a number of reasons (see e.g.
McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton, 2002), the waterfall
method is usually less suited to software-development projects.
Software development is a creative process.
It is nearly impossible to identify all of the requirements (functionalities)
beforehand.
Estimating the amount of time that will be necessary to implement a
functionality is quite difficult.
It should be possible for all intermediate results to be tested by users
throughout the entire trajectory of the project.
Software development is a creative process
To outsiders, software development appears to have more to do with engineering
than it does with inventing. It does, however, correspond to inventing in a number of
ways. In the process of invention, one never knows in advance precisely what is
going to happen.
The designers and programmers who write new software must conceive of
solutions for the problems that are set before them. Regardless of the many
methods and prescriptions for work, writing programming code remains largely new
and therefore largely uncertain. Programmers can choose their solutions out of
millions of possibilities that are written in dozens of programming languages, and
which operate according to thousands of hardware configurations and in dozens of
software platforms. Although this freedom does offer a number of advantages, it also
makes the project more difficult to manage than traditional projects (e.g.
construction or building projects).
It is nearly impossible to identify all of the requirements
(functionalities) beforehand
The waterfall method prescribes the formulation of requirements as the project
result of the definition phase. Ideally, there should be little further deviation from
these requirements throughout the rest of the project. The development of software
according to the waterfall method requires the investment of considerable time in
the beginning of the project in analysing the necessary functionalities
(requirements). This leads to a functional design (for more details on functional
designs, see [i]). Using the functional design as a guide, the software architect
makes a technical design in the design phase. The technical design includes a
description of how the desired functionalities should be implemented.
Although this may appear quite straightforward, consider the following situation
(example adapted from McConnell, 1996, p. 138). There is a project to produce a
new automobile. As an active automobile driver, you are asked to formulate the
requirements for an automobile. You consult with other drivers and create an
extensive list:
The automobile must accommodate four people.
The automobile must have a steering wheel in the front on the driver’s left-hand
side, a brake pedal, a gas pedal and a hand brake.
The automobile must have four wheels.
The automobile must have white headlamps and red tail lamps.
et cetera (the actual list would obviously be enormous)
Using your list as a guide, the designers develop a new design, which is
subsequently built several months later. One day, as you are walking down the
street, you see an automobile stopping. You realise that you neglected to include
brake lamps in your list! You immediately telephone the engineer of the automobile
manufacturer, who nearly explodes in reaction to your call. You maintain that it is
only a small change. For the automobile manufacturers, however, it is a disaster.
The automobiles that have already been made must be completely disassembled,
cables must be stretched from the brake pedals to the rear, the rear of the
automobile must be completely re-designed in order to accommodate the brake
lamps, the boot hatches that had already been produced would have to be discarded
and the list goes on.
While the example above is somewhat absurd, it reflects an almost daily reality
in software development. Programmers erroneously assume that the clients,
customers or users of the software that is to be developed know precisely what they
want Clients erroneously assume that the software builders can make (and adapt)
everything in the shortest possible time. This problem is the greatest source of
conflict between customers and software builders.
The following anecdote illustrates the fact that there are many conflicts between
customers and software suppliers. A beginning entrepreneur wanted to obtain legal
insurance for his business. He asked about the possibilities. When the broker asked
him to identify the sector in which his business was active, the entrepreneur replied,
‘IT’. ‘Too bad’, replied the broker, ‘there are so many lawsuits between IT suppliers
and customers that there are no insurance companies that will write legal-insurance
policies for IT companies’.
Estimating the amount of time that will be necessary to
implement a functionality is quite difficult
The waterfall method assumes a number of phases. In their project plans, project
leaders must include estimates of the amount of time (and therefore money) that
will be needed for each phase. We have already seen that time estimates are
generally difficult for any project, particularly if they must be made in the early
stages of a project. For software projects, it is simply impossible. Imagine that it
were feasible to compile a qualitatively adequate list of functionalities in the
definition phase. In theory, the project team should then be able to provide a
reasonable estimate of how much time will be necessary to implement each
functionality. In practice, however, there are too many uncertainties to allow a
reasonable estimate (e.g. McConnell, 1996):
Once a functionality has been made, it is often discovered that the customer
does not need it after all. The hours that were used in implementing this
functionality can therefore be regarded as useless.
Requirements change during the project.
Should the functionality be implemented expensively or inexpensively? There are
many possible methods of implementation and realisation.
How will the functionality be designed technically? The design largely determines
the amount of time that will be needed to make it How high must the quality of the functionality be? For example, should a web
application always remain completely available, or can it be offline for a few
hours each year?
The time needed to identify and repair errors in software can vary from minutes
to weeks.
How long will it take to install and integrate the new software into the
customer’s existing systems?
The lack of knowledge concerning possible solutions also complicates the
estimation of time. Further, it is difficult to estimate how long it will take to
acquire the necessary knowledge.
The list above shows that many factors can affect the amount of time that will
ultimately prove necessary to implement a new piece of software. Research
(McConnell, 1996, p. 168) has shown that the estimates of the time needed to
implement a functionality at the beginning of a project varies between four times too
little time and four times too much time. This means that the amount of time
necessary can turn out to be either four times higher or four times lower than a
faulty estimate. These estimates become more accurate as the project progresses.
After the functional design has been made, the margin is reduced to twenty-five per
cent too much or too little. Only when the functionality is implemented can an
estimate be provided with a high level of certainty