b) Getting multiple service per run by modifying his program to read in correct conditions periodically to nullify any mistakes so the next section of program can also be checked
c) Avoiding extensive store dumps
d) Programming flow indicators which print to show the paths of decision in actual execution
e) Providing a full range of controlled data input
f) Designing testing on a ‘design of experiment basis’ to achieve maximum progress for each run?
7. USER DOCUMENTATION
Is the user documentation given top priority and consideration for the sale and successful operation of the system?
Does the documentation conform to standard models?
Is the documentation uniform across product lines so that the user may expect to find similar information in corresponding places and form for every system?
Is user documentation consistent with itself and with national and international standards?
Do all flowcharting symbols and methods conform to international standards?
Does all terminology conform to the IFIP/ICC vocabulary?
Do software processors (Fortran, Cobol, Algol, etc.) conform to standard language specifications?
Are single manuals produced which are valid across machine lines (Fortran, File Structure, Labeling, etc.)?
Are variable software system characteristics excluded, but enclosed separately in machine line manuals with cross indexing?
Is there a formal, consistent document numbering system?
In consideration of the various audiences addressed (for the customers — purchasers, utilizers, programmers, operators; for the manufacturer salesmen, customer technical assistants, basic software programmers, field engineers and maintenance programmers), are user documents looseleaf rather than bound?
Can pages have multiple set membership (i.e. present in several different manuals)?
Does the education staff provide other documents which are in effect ‘road maps’ through these manuals to accelerate the learning process:
Is there a computerized system for writing, editing and boiler-plating this user documentation?
Are programmers forced to prepare documentation very early in the production cycle?
Are tentative manuals, with missing decisions identified, published in preference to having no manuals at all?
Is there a formal review procedure for manuals 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 adequacy and consistency?
Is there a formal procedure to amend manuals as a result of such feedback, with provision for alternate methods when review schedules are not met?
Does hardware engineering provide complete operational specifications early in the software production cycle?