Software Engineering for Students A Programming Approach

Stage Input Output
21.3 Feedback between stages 293
requirements engineering none requirements specification
architectural design requirements specification architectural design
detailed design architectural design module specifications
coding module specifications coding
unit testing coding tested modules
system testing tested modules tested system
acceptance tested system satisfied client
SELF-TEST QUESTION
21.2 Someone enhances the waterfall model by including a user interface
design stage immediately after the requirements engineering stage.
What are its inputs and outputs?
21.3 ● Feedback between stages
One of the drawbacks of a strict waterfall model is that the water cannot flow upwards –
if a problem is found at a particular stage in development, there is no way of redoing an
earlier stage in order to rectify the problem. For example, testing usually finds errors in
the (preceding) coding stage, but in the strict waterfall approach, the coding cannot be
corrected. When preparing a meal, if you find that some ingredient is missing when you
get to the stage of cooking the vegetables, you need to go back to the shopping stage.
To overcome this obvious drawback, a variation of the waterfall model provides for
feedback between adjoining stages, so that a problem uncovered at one stage can cause
remedial action to be taken at the previous stage. Thus the waterfall model with feedback
between stages is as shown in Figure 21.2.
You will see, however, that this approach only provides for feedback to the immediately
preceding step. But, in reality, any step may necessitate changes in any of the preceding
stages. For example:
■ during system testing, an architectural design fault is revealed
■ during user acceptance, a problem with the specification becomes evident.
So the reality of using the waterfall model is that development does not proceed in
one direction, step by step. Instead, there is commonly frequent feedback to earlier
stages, requiring rework (which can seriously disrupt the timescale of a project). To be
more realistic, Figure 21.2 should show arrows leading backwards from every activity
to every preceding activity. This, of course, undermines the model and any planning.