No author in the area of software development has resisted denouncing the
waterfall model . Everyone agrees that insights obtained downstream may
change decisions made upstream and thus violate a simple sequential
development algorithm. The notion of a development process in which one
can backtrack at each point to any previous point has led to the
fountain metaphor (with, we assume, the requirements at the bottom and
the target system at the top).
Whether the development process has few feedback loops (the waterfall
model) or many (the fountain model) depends on several factors. The
clarity of the initial requirements is an obvious factor. The less we know
initially about the desired target system, the more we have to learn along
the way and the more we will change our minds, leading to backtracking.
Another factor might be the integration level of tools that support the
development process. A highly integrated development environment
encourages ``wild'' explorations, leading to more backtracking. On the
other hand without tool support, we may be forced to think more deeply
at each stage before moving on because backtracking may become too costly.
The development style of team members may be a factor as well.
It has been said that the object-oriented paradigm is changing the classic
distinctions between analysis, design and implementation. In particular,
it is suggested that the differences between these phases is decreasing,
that the phases blur into each other. People claim that the OO paradigm
turns every programmer into a designer, and every designer into an analyst.
We are willing to go only part way with this view. There is empirical
evidence from projects in which objects identified in the requirements
phase carried all the way through into the implementation (see [5
]). We
will see as well that notions and notations used in analysis and design
are similar, lending more support for this thesis.
On the other hand, intrinsic differences among phases cannot be forgotten.
Analysis aims at clarifying what the task is all about and does not go
into any problem solving activity. In contrast, design and implementation
take the task specification as a given and then work out the details of
the solution. The analyst talks to the customer and subsequently (modulo
fountain iterations) delivers the result to the designer. The designer
``talks'', via the implementor, with hardware that will ultimately
execute the design. In a similar vein we do not want to blur the difference
between design and implementation. Contemporary OO programming languages
have limitations and idiosyncrasies that do not make them optimal thinking
media for many design tasks.