From: Gil Regev (gil.regev@epfl.ch)
Date: Wed Apr 09 2003 - 17:48:35 EST
Ian, Scotto, Grant, Dasmeet,
The use of WM in software projects is only a special case in the understanding of what constitutes human rationality.
The same problem was discovered in strategic management, which fell into the strategic planning trap in the 60's and 70's. It seperated the planning phase from the doing phase assuming that very detailed planning was not only possible but that it would very much simplify the doing phase.
There's a very good paper on the subject of "wicked problems" by Jeff Conklin (http://cognexus.org/wpf/wickedproblems.pdf) that shows that the use of a waterfall model is a very general case in human affairs. It also shows the falacies that such a model brings. Describing a study of specialist designers trying to design an elevator system, Conkling states the following:
"Traditional thinking, cognitive studies, and the prevailing design methods all predicted that the best way to work on a problem like this was to follow an orderly and linear "top down" process, working from the problem to the solution. This logic is familiar to all of us. You begin by understanding the problem. This often includes gathering and analyzing "requirements" from customers or users. Once you have the problem specified and the requirements analyzed, you are ready to formulate a solution, and eventually to implement that solution. This is illustrated by the "waterfall" line in Figure 1.
This is the pattern of thinking that everyone attempts to follow when they are faced with a problem, and it is widely understood that the more complex the problem is, the more important it is to follow this orderly flow. If you work in a large organization, you will recognize this linear pattern as being enshrined in policy manuals, textbooks, internal standards for project management, and even the most advanced tools and methods being used and taught in the organization. In the software industry it is known as the "Waterfall model," because it suggests the image of a waterfall as the project "flows" down the steps towards completion.
However, the subjects in the elevator experiment did not follow a waterfall. They would start by trying to understand the problem, but they would immediately jump into formulating potential solutions. Then they would jump back up to refining their understanding of the problem. Rather than being orderly and linear, the line plotting the course of their thinking looks more like a seismograph for a major earthquake, as illustrated in Figure 2. We will refer to this jagged-line pattern as opportunity-driven2, because in each moment the designers are seeking the best opportunity for progress toward a solution."
So it seems that the WM model may be right about the phases that it specifies but wrong in prescribing the order and flow in which they occur. It therefore assumes too much about human rationality in the face of uncertainty. It may be OK for very simple problems where certainty can be assumed but who knows which problems are simple and which are not? Conklin has this quote of Laurence J. Peter: "Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them."
Gil
-----Original Message-----
From: owner-re-online@it.uts.edu.au
[mailto:owner-re-online@it.uts.edu.au] On Behalf Of Ian F Alexander
Sent: mardi, 8. avril 2003 16:35
To: re-online@it.uts.edu.au
Subject: Re: [re-online] waterfall model
Scotto,
"You cannot be serious" as they say in Tennis.
I guess we agree about the 'significantly tailored' bit - the WM is as I said the basis for everything else, but projects always need to iterate in some way or other (not least as their requirements change ;-) ahem) and hence they repeat several WMs, they overlap them, they share early phases, etc etc.
But the 'we finish the requirements before we start the design' is nonsense at any scale. It's based, I suspect, on a dreadful confusion between phase/activity and project/programme stage.
Ian
> Ian,
>
> It's interesting that you say that the waterfall is "...
not really practical on projects of any size.", since it was originally
elucidated by Royce precisely for large projects, and it remains the
model (although significantly tailored) for most large projects to date,
at least in the US.
>
> I would take the opposite view (perhaps partly for
argument's sake), that the waterfall isn't really practical
for small projects because of the documentation burden and "perceived"
inflexibility that it imposes on the development process.
>
> scotto...
re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail. -------------------------------------------------------------------------------To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Apr 14 2003 - 09:00:09 EST