Software Engineering For Students: A Programming Approach Part 32 pot

288 Chapter 20 ■ Groups
20.1 Assess the effectiveness of structured walkthroughs.
20.2 Evaluate pair programming.
20.3 Compare and contrast the structured walkthrough technique with pair programming.
20.4 Argue a case for either walkthroughs or pair programming and suggest how it might
be introduced into an organization.
20.5 Try to introduce ego-less programming into your college, university or organization
in the following way. When you have written your next program and have a clean-
compiled listing, ask one of your colleagues to look through it for you. Explain that
you would appreciate comments of any kind on the program’s clarity, correctness,
etc. Explain that you are trying to identify problems sooner rather than later. Offer to
do the same in return.
20.6 Suggest features for software tools that could assist in using each of the following
techniques:
■ walkthroughs
■ inspections.
Exercises
•
Further reading
•
The classic book which introduced the idea of ego-less programming, the precursor to
walkthroughs and inspections. It deals at length and in a most interesting way with
the informal, social aspects of working in a team. It is most enjoyable to read. G.
Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, l971.
The original reference describing the technique of inspections: M.E. Fagan, Design
and code inspections to reduce errors in program development, IBM Systems
Journal, 15 (3) (July 1976), pp. 182–211.
Full of practical advice and case studies, jointly authored by one of the industry gurus,
all you ever wanted to know about inspections is explained in: Tom Gilb and
Dorothy Graham, Software Inspection, Addison-Wesley, 1993.
A collection of useful papers on how to do inspections and what the benefits are: David

A. Wheeler, Bill Brykczynski and Reginald N. Meeson, Software Inspection: An
Industry Best Practice, IEEE Computer Society Press, 1996.
There is a website simply for pair programming, with links to sites that report on eval-
uations, at: />This is a useful book on pair programming: Laurie Williams and Robert Kessler, Pair
Programming Illuminated, Addison-Wesley, 2002.
BELL_C20.QXD 1/30/05 4:25 PM Page 288
PART
E
PROCESS MODELS
BELL_CPARTE.QXD 1/30/05 4:31 PM Page 289
BELL_CPARTE.QXD 1/30/05 4:31 PM Page 290
The waterfall model is an established approach that dominated software development
for a number of years and is widely used. It has the virtue of simplicity.
In the waterfall model, software development is split up into a number of independent
steps (Figure 21.1). These steps are carried out in sequence one after the other. Each
stage produces a product which is the input into the next stage. It is important to real-
ize that each stage is pursued until its conclusion before the next stage is begun. Thus,
for example, all the coding is completed before testing starts.
Like all process models, the waterfall model says nothing about what methods are
used at any of its stages, nor does it stipulate what notations are used for the products
at each stage. (This whole book is about the different methods and notations that are
available.) It merely provides a framework for a development.
Different people and authors have slightly different ideas about what exactly the
steps should be. For example, some people include a feasibility study as the first step.
However, the essentials of the approach are the same.
21.2
●
Principles of the model
21.1
●

Introduction
CHAPTER
21
The waterfall model
This chapter explains:
■ how to use the waterfall model for software development
■ the principles behind the waterfall model.
BELL_C21.QXD 1/30/05 4:25 PM Page 291
292 Chapter 21 ■ The waterfall model
The principles of the waterfall model are:
■ it is a series of steps (like a factory production line)
■ each step is well defined
■ each step creates a definite product (in some cases a piece of paper)
■ each product forms the basis for the next step
■ the correctness of each step can be checked (verification or validation).
The waterfall model gets its name because each stage produces a product, like a
stream of water which passes on to the next stage. So the complete development
process is like a series of small waterfalls – see Figure 21.1. Just as water cannot flow up
a waterfall, information does not flow backwards in the waterfall model. Once a step is
complete, there is no going back.
Requirements
Engineering
Architectural
design
Detailed
design
Coding
Acceptance
Unit
testing

System
testing
Figure 21.1 The waterfall model
SELF-TEST QUESTION
21.1 Draw up a process model for preparing a meal, including buying the
ingredients and washing up afterwards. Don’t forget to identify the
product at each stage.
The inputs and outputs for each step of the waterfall model are shown in this
table.
BELL_C21.QXD 1/30/05 4:25 PM Page 292
21.3 Feedback between stages 293
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 feed-
back between stages is as shown in Figure 21.2.
You will see, however, that this approach only provides for feedback to the immedi-
ately preceding step. But, in reality, any step may necessitate changes in any of the pre-
ceding 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.
21.3
●
Feedback between stages
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
Stage Input Output
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?
BELL_C21.QXD 1/30/05 4:25 PM Page 293
294 Chapter 21 ■ The waterfall model
The instigators of the waterfall model clearly and wrongly perceived software devel-
opment to be simple and straightforward, with development proceeding smoothly
onwards from stage to stage without disruption. But, as we have seen, there are funda-
mental problems with using the waterfall model as a basis for a project plan.
Nonetheless, it is common to use this process model.
The strengths of the waterfall model are:
■ it divides a complex task into smaller, more manageable tasks
■ each task produces a well-defined deliverable.
Thus the process is well-defined. Anyone can see exactly what has been completed and
what remains to be done.
Perhaps the most serious problem with the waterfall model is that the client only gets
to see the product at the very end of the development – and if it is not what they

want, it is too late! The problem is the huge gap between requirements analysis at an
early stage in a project and acceptance testing near the end. There is no opportunity
to validate the user requirements at an early stage in development. This is a major prob-
lem with the waterfall model.
But there are also less obvious, but equally important drawbacks. If a problem is dis-
covered at any stage which reveals a mistake at an earlier stage, nothing can be done
about it.
21.4
●
Discussion
Requirements
Engineering
Architectural
design
Detailed
design
Coding
Acceptance
Unit
testing
System
testing
Figure 21.2 Modified waterfall model with feedback
BELL_C21.QXD 1/30/05 4:25 PM Page 294
Exercises 295
21.1 Draw up a waterfall process model for a large civil engineering project, such as
building a road bridge across the channel between England and France. Identify
similarities and differences between this project and a large software development
project.
21.2 Validation and verification are clearly important. Identify where validation is carried out

and where verification is carried out in the waterfall model.
21.3 Create an outline plan for developing each of the systems in Appendix A using the
waterfall model.
21.4 Evaluate the waterfall model using the following criteria:
■ capability to accommodate risk
■ capability to meet user requirements
■ capability to respond to changed requirements
■ visibility of the progress of the project.
21.5 Identify the main goals and the main techniques of each of the following process
models:
■ waterfall
■ spiral
■ prototyping
■ incremental
■ open source
■ XP
■ UP
21.6 “The waterfall model is useless.” Discuss.
Exercises
Summary
The essence and the strengths of the waterfall model are that:
■ it divides a complex task into smaller, more manageable tasks
■ each task produces a well-defined deliverable.
■ each stage is carried out in sequence – there is no going back.
The goal of this approach is to maintain control during development.
•
BELL_C21.QXD 1/30/05 4:25 PM Page 295
296 Chapter 21 ■ The waterfall model
Answers to self-test questions
21.1 1. buy ingredients (product is ingredients)

2. prepare vegetables (prepared vegetables)
3. cook meat (cooked meat)
4. cook vegetables (cooked vegetables)
5. serve meal (meal on table)
6. wash up (clean utensils).
21.2 The input is the requirements specification.
The output is the specification of the user interface.
BELL_C21.QXD 1/30/05 4:25 PM Page 296
The main feature of the spiral model is the recognition that there is often enormous
uncertainty at many stages during a software development project. It therefore incor-
porates periodic risk assessment. These assessments are followed by identifying alterna-
tive actions, selection of the best action and re-planning.
This model is shown in Figure 22.1. Progress is shown as a line that spirals out from near
the centre of the diagram. Each cycle of the project passes through four steps, shown as
the four quarters of the diagram. The project spirals outwards from the center of the dia-
gram to convey the increasing expenditure of time, effort – and progress.
As the diagram shows, each cycle consists of four steps:
1. analyze risks and plan
2. analyze requirements
3. construct
4. evaluate.
22.2
●
The spiral model
22.1
●
Introduction
CHAPTER
22
The spiral model

This chapter:
■ explains the principles behind the spiral model
■ explains some of the practical aspects of using this model.
BELL_C22.QXD 1/30/05 4:26 PM Page 297