< Prev Next >
96
NATO SOFTWARE ENGINEERING CONFERENCE 1968
9. Working Papers

Is there a formal procedure for planning basic software simultaneously with hardware, with an effective systems control for allocating tradeoffs?
Is there a formal review procedure for software specifications for
a) Marketing to ensure adequacy and efficacy of market coverage
b) Product Planning to ensure conformity to planning goals
c) Hardware Engineering to ensure accuracy and consistency
d) Internal computer operations to ensure user suitability and proper human engineering?
Is there a formal procedure to amend specifications as a result of such feedback, with provision for alternate methods when review schedules are not met?
Is there a mechanism for interchange (or at least crediting) of budgeted monies to facilitate maximum benefit from hardware–software tradeoffs?
Is the tradeoff principle extended to field maintainability, with a mechanism for interchange of budgeted monies?
Does Product Planning provide intelligence from competition and advanced development areas in the form of surveys and comparative evaluation materials, for due influence upon software design?
Is a substantial portion of the design staff familiar with current field operating methods, so as not to be insulated from changing requirements?
Is each software unit identified and numbered for direct correspondence to
a) Its corresponding quality assurance program?
b) Its actual source program instructions, listed?
c) Its actual source program instructions in entry form.
d) Its corresponding elements of user documentation.
e) Its corresponding elements of technical documentation.
f) The minimum hardware configuration required to run it.
Is each software unit equipped with a document detailing the following:
a) Its purpose.
b) Its inputs and their forms.
c) Its outputs and their forms.
d) The processes applied to the inputs to yield the outputs.
e) The inventory of tools (other units, utility routines, usable store, executive controls) available to it.
f) The constraints of time and interaction with other software units.
g) Its operational design goals and characteristics.
h) The characteristics of its interfaces with other software units.
i) Its precision and accuracy, where relevant.

Are these questions complete before any flowcharting, programming or coding commences?
Are they matched against the other similar specifications to detect conflict, duplication or system imbalance?
Is there a periodically updated software design checklist available to all software designers?