Software Engineering for Students A Programming Approach

2.2 The tasks 25
An important example of a validation activity is acceptance testing. This happens at
the end of the project when the software is deemed complete, is demonstrated to its
client and accepted by them as satisfactory. The inputs to acceptance testing are the
client and the apparently complete software. The products are either a sign-off document
and an accepted system or a list of faults. The outcome is that the system complies
with the requirements of the client or it does not.
Current evidence suggests that many computer systems do not meet the needs of their
users, and that therefore successful validation is a major problem in software engineering
today. It is a common experience that users think they have articulated their needs to the
software engineer. The engineer will then spend months or even years developing the
software only to find, when it is demonstrated, that it was not what the user wanted. This
is not only demoralizing for both users and developers, but it is often massively costly in
terms of the effort needed to correct the deficiencies. As an extreme alternative the system
is abandoned.
It is too easy to blame the requirements analysis stage of development, when in
reality the basic problem is the quality of the communication between users and
developers. Users do not know (and usually do not care) about technicalities, whereas
the software engineer expects detailed instructions. Worst of all is the problem of
some common language for accurately describing what the user wants. The users are
probably happiest with natural language (e.g. English), whereas the software engineer
would probably prefer some more rigorous language that would be incomprehensible
to the users. There is a cultural gap.
Production
The system is put into use. (This is sometimes, confusingly, termed implementation.)
The users may need training.
Maintenance
When the software is in use, sooner or later it will almost certainly need fixing or
enhancing. Making these changes constitutes maintenance. Software maintenance often
goes on for years after the software is first constructed. The product of this activity is
the modified software.
Documentation
Documentation is required for two types of people – users and the developers.
Users need information about how to install the software, how to de-install the software
and how to use it. Even in the computer age, paper manuals are still welcome. For
general purpose software, such as a word processor, a help system is often provided.
User documentation concentrates on the “what” (the external view) of the software,
not the “how” (the internal workings).
Developers need documentation in order to continue development and to carry out
maintenance. This typically comprises the specification, the architectural design, the