< Prev Next >
NATO SOFTWARE ENGINEERING CONFERENCE 1968
61
6. Service

6. Service
6.1. INTRODUCTION
6.1.1. THE VIRTUE OF REALISTIC GOALS
Much discussion centered on the conditions necessary for acceptable service to be obtained from a software system. The first point covered was the virtue of realistic design and production goals,
Opler: I am concerned about the current growth of systems, and what I expect is probably an exponential growth of errors. Should we have systems of this size and complexity? Is it the manufacturer’s fault for producing them or the user’s for demanding them? One shouldn’t ask for large systems and then complain about their largeness.
Dijkstra: It is not clear that the people who manufacture software are to blame. I shirk manufacturers deserve better, more understanding users.
Llewelyn: Lots of time and money are lost in planning on what turns out to be false data provided by manufacturers. We need more realistic delivery estimates from manufacturers.
Randell: The users should demand contractual safeguards.
6.1.2. INITIAL SYSTEM RELEASE
The second point was concerned with the quality of initial releases of software systems.
Babcock: The initial release of a software system should work well (albeit with limited facilities) and must contain the basic system philosophies that ensure orderly growth.
Genuys: We need pre-release versions of systems, whether they work well or not, for training our staff.

Galler: Manufacturers should not deliver a system unless it is working well, although it need not be entirely free of bugs.
David: Define a subset of the system which is small enough to be manageable, then build on that system. This strategy requires that the system be designed-in modules which can be realised, tested and modified independently, apart from conventions for intermodule communication. It also implies that the system can be a tool vital in its own development.
Kolence: Large systems must evolve, and cannot be produced all at one time. You must have an initial small core system that works really well.
Randell: The users are as much to blame for premature acceptance of systems as the manufacturers for premature release.
Samelson: The real problem is the user, since he needs software and takes it whether or not it is correct.
Glennie: Software manufacturers should desist from using customers as their means of testing systems.
6.1.3. FREQUENCY OF RELEASES
The subject of frequency of system releases, and its effect on the level of service that could be expected from a system gave rise to the following comments.
Babcock: Fewer releases, containing major functional improvements (other than corrections) that work well are more desirable than frequent releases of versions containing only minor improvements.
Gillette: CDC recently undertook an extensive update of one of its software systems in order to increase its performance. Users were given the chance to wait for development to be complete or to receive incremental updates that would not have been fully integrated and tested. All users elected to receive monthly system updates. Our field analysts explained that they could cope more easily with small incremental changes.