b. Parameter compiler.
c. Translation data assembler.
d. Simulators for:
(i). Studying traffic and real-time capabilities
(ii). Testing hardware design
e. Summary of general purpose computer support programs.
5. Program test and evaluation support programs.
a. By simulation on a general purpose machine.
b. On the system itself:
(i) First by program blocks
(ii) Second by program functions
(iii) Finally under many load tests as a complete hardware software system.«
Inspired by a proposal by Fraser in ‘Classification of software production methods,’ a working party was formed to work on the classification of the subject matter of software production methods. This working party, with the members Bemer, Fraser, Glennie, Opler, and Wiehle, submitted the report titled ‘Classification of subject matter,’ reproduced in section 9.
3.3. DESIGN AND PRODUCTION IN SOFTWARE ENGINEERING
The difficulties associated with the distinction between design and production (or implementation) in software engineering was brought out many times during the conference. To clarify this matter it must first be stressed that the difficulty is partly one of terminology. Indeed, what is meant here by production in software engineering is not just the making of more copies of the same software package (replication), but the initial production of coded and checked programs. However, as evidenced by quotations below, the appropriateness of the distinction between design and production was contested by several participants.
Added to these basic difficulties is that the conference was organized around the three concepts, design, production, and service. In organizing the report this distinction was retained, mostly for expediency.
First we quote an attempt to clarify the distinction.
Naur: (from The profiles of software designers and producers)
»Software production takes us from the result of the design to the program to be executed in the computer. The distinction between design and production is essentially a practical one, imposed by the need for a division of the labor. In fact, there is no essential difference between design and production, since even the production will include decisions which will influence the performance of the software system, and thus properly belong in the design phase. For the distinction to be useful, the design work is charged with the specific responsibility that it is pursued to a level of detail where the decisions remaining to be made during production are known to be insignificant to the performance of the system.«
The practical dangers of the distinction are stressed in the two following remarks.
Dijkstra: Honestly, I cannot see how these activities allow a rigid separation if we are going to do a decent job. If you have your production group, it must produce something, but the thing to be produced has to be correct, has to be good. However, I am convinced that the quality of the product can never be established afterwards. Whether the correctness of a piece of software can be guaranteed or not depends greatly on the structure of the thing made. This means that the ability to convince users, or yourself, that the product is good, is closely intertwined with the design process itself.