Are there finite points in time during development and system updating when the system is reassembled to a clean form with updated listings?
Are hand coding sheets destroyed and each reassembly listing used as the legal representation?
Is periodic recoding recommended when a routine has lost a clean structural form?
Is the system oriented to reassemble with at least the ease of patching?
Are all system tools utilized as provided?
Is there periodic exchange of fabrication information and progress among the various programmer groups constructing an integrated system?
Are original programs and changes controlled so that they cannot be introduced without meeting certain minimum criteria (e.g., a minimum length of comments associating with the statement, or preventing entry or modification of a software unit unless the appropriate links and interfaces in both directions are given)?
Is adequate attention given to modularity in construction, but without overemphasis which could destroy operating efficiency?
Since it is cheaper to be prepared for a malfunction than not, are program units created in three forms for testing:
a) As a self-contained unit, complete with synthetic input and output, created perhaps by a generator
b) In a form suitable for usage within its own major program
c) In a form suitable for use within the overall system?
Can the extra instructions required for (a) and (b) above be removed mechanically for the final stage?
Are statistics kept on the type of malfunction incurred, which may be:

a) a hardware malfunction
b) a malfunction in the programming system used
c) an operating mistake
d) data errors, such as unexpected type, outside of expected range, physical errors in preparation or reading, etc.
e) programmer’s mistake, such as a misunderstanding or disregard for the rules of syntax, grammar, construction, file layout, system configuration, flow process for solution, etc.?
Is considerable desk checking performed to
a) Check conformity to rules, such as those for justification
b) See that enough restart points exist for long programs
c) Compare actual program logic for match with intended logic as given by a flowchart or equation
d) Examine live input for peculiar characteristics which could cause erroneous branching, such as bad data, blank records, etc.
e) Inspect the list of identifiers produced and assigned by the processor, looking for conflicts, insufficient definition, completeness and spelling
f) Check permissible spellings of reserved words, allowable usage of spacing, hyphens and commas, and juxtaposition of illegal word or operation pairs?
Do the programmers plan for maximum machine utility per run in checkout by:
a) Submitting multiple related runs