< Prev Next >
70
NATO SOFTWARE ENGINEERING CONFERENCE 1968
7. Special Topics

7. SPECIAL TOPICS
7.1. SOFTWARE: THE STATE OF THE ART
7.1.1. INTRODUCTION
Quite early in the conference statements of concern were made by several members about the tendency for there to be a gap, sometimes a rather large gap, between what was hoped for from a complex software system, and what was typically achieved. This topic was therefore discussed both at a special session and during the final plenary session of the conference. The essence of these discussions is given below, for the large part, as usual, in the form of more-or-less verbatim quotations.
One statement made by Buxton, given in reply to the worries of several members that the debate was unbalanced because too much attention was being paid to past and possible future software failures, is worth bringing out of context as an introduction for the reader.
Buxton: In a conference of this kind, when those present are technically competent, one has a tendency to speed up the communication by failing to state the obvious. Of course 99 percent of computers work tolerably satisfactorily; that is the obvious. There are thousands of respectable Fortran-oriented installations using many different machines and lots of good data processing applications running quite steadily; we all know that! The matter that concerns us is the sensitive edge, which is socially desperately significant.

7.1.2. PROBLEM AREAS
There was a considerable amount of debate on what some members chose to call the ‘software crisis’ or the ‘software gap’. As will be seen from the quotations below, the conference members had widely differing views on the seriousness, or otherwise, of the situation, and on the extent of the problem areas.
David and Fraser: (from their Position paper)
»There is a widening gap between ambitions and achievements in software engineering. This gap appears in several dimensions: between promises to users and performance achieved by software, between what seems to be ultimately possible and what is achievable now and between estimates of software costs and expenditures. The gap is arising at a time when the consequences of software failure in all its aspects are becoming increasingly serious. Particularly alarming is the seemingly unavoidable fallibility of large software, since a malfunction in an advanced hardware-software system can be a matter of life and death, not only for individuals, but also for vehicles carrying hundreds of people and ultimately for nations as well.«
Hastings: I am very disturbed that an aura of gloom has fallen over this assembly. I work in an environment of many large installations using OS/360. These are complex systems, being used for many very sophisticated applications. People are doing what they need to do, at a much lower cost than ever before; and they seem to be reasonably satisfied. Perhaps their systems do not meet everybody’s need, they don’t meet the time sharing people’s demands for example, but I don’t think software engineering should be confused with time sharing system engineering. Areas like traffic control, hospital patient monitoring, etc., are very explosive, but are very distinct from general purpose computing.
Gillette: We are in many ways in an analogous position to the aircraft industry, which also has problems producing systems on schedule and to specification. We perhaps have more examples of bad large systems than good, but we are a young industry and are learning how to do better.
Randell: There are of course many good systems, but are any of these good enough to have human life tied on-line to them, in the sense that if they fail for more than a few seconds, there is a fair chance of one or more people being killed?