The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
An Assessment of Space Shuttle Flight Software Development Processes
THE SPACE SHUTTLE FLIGHT SOFTWARE VERIFICATION AND VALIDATION PROCESS
The primary task of the Committee was to attempt to understand and evaluate the processes by which NASA and its contractors write and assure the quality of the Shuttle flight software. As shown and discussed in Chapter 3, the Committee addressed: (1) the process for requirements definition and specification; (2) the processes used by the development and IV&V contractors; (3) the configuration management process; (4) test case development and evaluation; (5) system software testing and integration; (6) preparation of mission-specific software and data; and (7) the loading and verification of the final flight software package.
As was mentioned in the opening chapter of this report, NASA has claimed for some time that its embedded V&V process (see Appendix E) is adequate without the current IV&V function. The Committee's Interim Report (see Appendix C) was primarily a discussion of why this committee felt that the current implementation of IV&V is necessary to ensure the quality and safety of the software. As promised in the Interim Report, though, there were other areas within the embedded process that the Committee believes are worthy of greater attention, and the Committee has additional comments regarding IV&V.
IBM's software quality measures show that its internal V&V discovers approximately 80 percent of errors before each new OI is built and 98 percent of errors before each OI is first released. Since 1981, 16 severity 1 1 DRs have been written against released OI versions. However, only eight errors remained in code that was used in flights and none of those eight errors was ever encountered in-flight. An additional 12 errors of severity 2, 3, or 4 have occurred in the PASS during flight. None of these threatened the crew; three threatened the mission, but the other nine were worked around. There were 50 waivers 2 written against the
Shuttle flight software errors are categorized by the severity of their potential consequences without regard to the likelihood of their occurrence. Severity 1 errors are defined as errors that could produce a loss of the Space Shuttle or its crew. Severity 2 errors can affect the Shuttle's ability to complete its mission objectives, while severity 3 errors affect procedures for which alternatives, or workarounds, exist. Severity 4 and 5 errors consist of very minor coding or documentation errors. In addition, there is a class of severity 1 errors, called severity 1N, which, while potentially life-threatening, involve operations that are precluded by established procedures, are deemed to be beyond the physical limitations of Shuttle systems, or are outside system failure protection levels.
A waiver represents a decision on the part of the Shuttle program to recognize a condition, such as a known software error, as an acceptable risk. Thus, a condition that receives a waiver is set aside, sometimes fixed at a later date when time and resources permit, but is not considered sufficient cause to hold up a flight.