NASA-GB-8719.13B (W/ CHANGE 1), NASA TECHNICAL STANDARD: NASA SOFTWARE SAFETY GUIDEBOOK (08 JUL 2004)

NASA-GB-8719.13B (W/ CHANGE 1), NASA TECHNICAL STANDARD: NASA SOFTWARE SAFETY GUIDEBOOK (08 JUL 2004)., This Standard specifies the software safety activities, data, and documentation necessary for the acquisition or development of software in a safety-critical system. Safety-critical systems that include software must be evaluated for software’s contribution to the safety of the system during the concept phase, and prior to the start, or in the early phases, of the acquisition or planning for the given software. Unless the evaluation proves that the software is not involved in the system safety, this Standard is to be followed. See section 1.2 for guidance, and section 4.1 for requirements (and definition), on the determination of safety-critical software. The purpose of this Standard is to provide requirements to implement a systematic approach to software safety as an integral part of the project’s overall system safety program, software development, and software assurance processes. It describes the activities necessary to ensure that safety is designed into software that is acquired or developed by NASA and that safety is maintained throughout the software and system life cycle. How these requirements are met will vary with the program, project, facility, Mission, and Center. The NASA-GB-8719.13, Software Safety Guidebook, provides additional information on how to implement software safety and software safety related activities in a manner consistent with the software’s role in system safety. The risk posed by safety-critical software will vary with the system safety criticality (e.g., type of hazard) and the level of control or influence the software has on system safety factors. While the requirements of this Standard cannot be tailored, the specific activities and depth of analyses needed to meet the requirements can, and should, be tailored to the software safety risk. That is, while the requirements must be met, the implementation and approach to meeting these requirements may and should vary to reflect the system to which they are applied. Substantial differences may exist when the same software safety requirements are applied to dissimilar projects. Appendix A shows how an example medium-sized project might meet the requirements of this Standard. A compliance matrix listing all of the requirements in this Standard along with the personnel roles and responsibilities required for each requirement, is available in Appendix B. This matrix can be used by the program, project, or facility as a checklist to ensure coverage of all requirements in the Standard.