< Prev Next >
NATO SOFTWARE ENGINEERING CONFERENCE 1968
11
3. Software Engineering

3. SOFTWARE ENGINEERING
3.1. THE NATURE OF SOFTWARE ENGINEERING
The content of software engineering was explained in several ways during the conference. Nash and Selig provided figures 1 and 2 indicating the various activities of a software project. These diagrams also indicate some of the terminology used in the field.
The need for feedback was stressed many times.
Perlis: Selig’s picture requires a feedback loop, for monitoring of the system. One must collect data on system performance, for use in future improvements.
The project activity was described in more detail by Fraser.
Fraser: (from The nature of progress in software production)
»Design and implementation proceeded in a number of stages. Each stage was typified by a period of intellectual activity followed by a period of program reconstruction. Each stage produced a useable product and the period between the end of one stage and the start of the next provided the operational experience upon which the next design was based. In general the products of successive stages approached the final design requirement; each stage included more facilities than the last. On three occasions major design changes were made but for the most part the changes were localised and could be described as ‘tuning’.
The first stage did not terminate with a useable object program but the process of implementation yielded the information that a major design change would result in a superior and less expensive final product. During the second stage the entire system was reconstructed; an act that was fully justified by subsequent experience. The second major design change had its origin in the more usual combination of an inelegant system and a demanding environment. Over a period of time we discovered  the failure characteristics of the hardware that was being used and assembled a list of techniques designed to overcome these. The final major design change arose out of observing the slow but steady escalation of complexity in one area of the system. As is often the case, this escalation had its origins in the conceptual inadequacy of the basic design. By replacing the appropriate section of the system kernel we simultaneously removed an apparent need for a growing number of specialized additions to the superstructure and considerably enhanced the quality of the final product«
The disadvantages of not allowing feedback were commented on by Galler.
Galler: Let me mention some bad experiences with IBM. One example concerns a request to allow user extensions of the PL/1 language. After a week of internal discussion at IBM it was decided that this could not be done because the language designers were not to tell the implementers how to implement the desired extensions. Another example: the OS/360 job control language was developed without any users having the chance to see the options beforehand, at the design stage. Why do these things happen?
External and internal design and their mutual feedback were described by Selig.
Selig: External specifications at any level describe the software product in terms of the items controlled by and available to the user. The internal design describes the software product in terms of the program structures which realize the external specifications. It has to be understood that feedback between the design of the external and internal specifications is an essential part of a realistic and effective implementation process. Furthermore, this interaction must begin at the earliest stage of establishing the objectives, and continue until completion of the product.