The license could not be verified: License Certificate has expired! Administrators, please check your license details here.
See edit history of this section
Post feedback on this section
1. Requirements
2.2.1.2 For safety-critical software, the project shall develop a software safety plan.
1.1 Notes">1.1 Notes
The requirement for the content of the software safety plan (whether stand-alone or condensed into one or more project level or software documents) is defined in Chapter 5. The NASA Software Safety Standard, NASA-STD-8719.13, contains detailed requirements and guidance on development of software safety plans. Software engineering and the software safety disciplines jointly are responsible for providing project management with the optimal solution for software to meet the engineering, safety, quality, and reliability needs of the project.
1.2 Applicability Across Classes
Appendix D of NPR 7150.2 does not include any notes for this requirement.
Class |
A_SC |
A_NSC |
B_SC |
B_NSC |
C_SC |
C_NSC |
D_SC |
D_NSC |
E_SC |
E_NSC |
F |
G |
H |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Applicable? |
|
|
|
|
|
|
|
|
|
|
|
|
|
Key: A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable
X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures
2. Rationale
The project team creates the Software Safety Plan to define the processes, risks, resources, stakeholders, interfaces, and safety design methodologies, necessary for the development of the software. The development of this plan allows for the review and agreement of the approach prior to implementation. The NASA Software Safety Standard, NASA-STD-8719.13 defines the contents of the Software Safety Plan.
3. Guidance
The NASA Software Safety Standard, NASA-STD-8719.13 defines the contents of the Software Safety Plan , and identifies who approves/concurs on it. The format for a Software Safety Plan is not mandated by this NPR or NASA-STD-8719.13. The project team checks with the Center's Safety and Mission Assurance organization for possible format requirements.
Based on the size and complexity of a project, the Software Safety Plan can be an independent document or part of another software document such as a Software Assurance Plan, software development plan or a software management plan.
If a project transitions from non-safety-critical to safety-critical, the project team will need to create the Software Safety Plan that includes the past, the transition, and the forward plan for meeting software safety requirements.
Best practices
Because the Software Safety Plan covers the lifecycle of the project, it is periodically evaluated as the project matures, to verify accuracy and continued implementation approaches. Typically, the project and the responsible software assurance engineer performs the evaluation at major milestone reviews.
4. Small Projects
For small projects, the safety plan may be part of an overall project management plan.
5. Resources
- NASA Technical Standard, "NASA Software Safety Standard", NASA-STD-8719.13B, 2004.This document provides information relative to the content and approval for the Software Safety Plan .
- NASA Technical Standard, "NASA Software Safety Guidebook", NASA-GB-8719.13, 2004.
- NASA Software Assurance website. Safety Training Courses. http://nsc.nasa.gov/Disciplines/SoftwareAssurance/ (accessed August 26, 2011).
- STEP Level 2 Overview of Software Safety course, SMA-SA-WBT-230, SATERN (need user account to access SATERN courses).
- STEP Level 3 Software Safety for Practitioners course, SMA-SOFT-NSC-1005, SATERN (need user account to access SATERN courses).
5.1 Tools
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.