bannera

Book A.
Introduction

Book B.
7150 Requirements Guidance

Book C.
Topics

Tools,
References, & Terms

SPAN
(NASA Only)

Versions Compared

Old Version 10

changes.mady.by.user Offik, Karin E. (MSFC-EE11)[COLSA]

Saved on

compared with

New Version 49

changes.mady.by.user Haigh, Fred Douglas. (HQ-KA000)[PEROT]

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Wiki Markup
{alias:SWE-130} {tabsetup:1. The Requirement|2. Rationale|3. Guidance|4. Small Projects|5. Resources|6. Lessons Learned} {div3:id=tabs-1} h1. 1. Requirements
Div
idtabs-1

1. Requirements

2.2.1.2

For

safety-critical

software,

the

project

shall

develop

a

software

safety

plan.

h2. {color:#003366}{*}

1.1

Notes{*}{color} 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 \[section 5.3.1 of NPR 7150.2, NASA Software Engineering Requirements\].

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 [section 5.1.9 of NPR 7150.2, NASA Software Engineering Requirements]. NASA-STD-8719.13

\

[NASA

Software

Safety

Standard

\

]

contains

detailed

requirements

{sweref:271}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. Typically, Class F through H software is not considered safety critical; however, a piece of non-engineering software (Class F through H) could have a safety critical nature to it. One example is an emergency notification system for natural disasters. In this example, if the software did not work it could result in loss of life or injury or significant impact to assets. For this reason, this requirement includes applicability for safety critical Class F through H. h2. 1.2 Applicability Across Classes This requirement applies to all classes and safety criticalities _including_ _safety critical_ _Class F thru H,_ with exceptions noted in the following table: {applicable:asc=1|ansc=1|bsc=1|bnsc=1|csc=1|cnsc=0|dsc=1|dnsc=0|esc=1|ensc=0|f=1|g=1|h=1} {div3} {div3:id=tabs-2} h1. 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. NASA-STD-8719.13 {sweref:271} defines the contents of the Software Safety Plan. Effective planning assures that adequate safety features are included within the system and software. Developing a plan early in the project ensures that software safety will be an integral part of the software development or acquisition process. {div3} {div3:id=tabs-3} h1. 3. Guidance NASA-STD-8719.13 {sweref:271} 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 (S&MA) 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 life cycle 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. See Topic 7.4 to determine the state of maturity of the Software Safety Plan at the various Milestone Reviews. {div3} {div3:id=tabs-4} h1. 4. Small Projects For small projects, the safety plan may be part of an overall project management plan. {div3} {div3:id=tabs-5} h1. 5. Resources # [NASA Technical Standard, "NASA Software Safety Standard"|http://www.hq.nasa.gov/office/codeq/software/docs.htm], 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"|http://www.hq.nasa.gov/office/codeq/software/docs.htm], NASA-GB-8719.13, 2004. # NASA Software Assurance website. Safety Training Courses.  [http://nsc.nasa.gov/Disciplines/SoftwareAssurance/|http://nsc.nasa.gov/Disciplines/SoftwareAssurance/] (accessed August 26, 2011). # STEP Level 2 Overview of Software Safety course, SMA-SA-WBT-230, [SATERN|https://saterninfo.nasa.gov/] (need user account to access SATERN courses). # STEP Level 3 Software Safety for Practitioners course, SMA-SOFT-NSC-1005, [SATERN|https://saterninfo.nasa.gov/] (need user account to access SATERN courses). {refstable} {toolstable} {div3} {div3:id=tabs-6} h2. 6. Lessons Learned No lessons learned have currently been identified for this requirement. {div3} {tabclose}

sweref
271
271
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.

Typically, Class F through H software is not considered safety critical; however, a piece of non-engineering software (Class F through H) could have a safety critical nature to it. One example is an emergency notification system for natural disasters. In this example, if the software did not work it could result in loss of life or injury or significant impact to assets. For this reason, this requirement includes applicability for safety critical Class F through H.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities including safety critical Class F thru H, with exceptions noted in the following table:


applicable
f1
g1
h1
ansc1
asc1
bnsc1
csc1
bsc1
esc1
cnsc0
dnsc0
dsc1
ensc0
 Div
idtabs-2
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. NASA-STD-8719.13 
sweref
271
271
 defines the contents of the Software Safety Plan.
Effective planning assures that adequate safety features are included within the system and software. Developing a plan early in the project ensures that software safety will be an integral part of the software development or acquisition process.
 Div
idtabs-3
3. Guidance
NASA-STD-8719.13 
sweref
271
271
 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 (S&MA) 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 life cycle 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 perform the evaluation at major milestone reviews. See Topic 7.08 - Maturity of Life Cycle Products at Milestone Reviews to determine the state of maturity of the Software Safety Plan at the various Milestone Reviews.
 Div
idtabs-4
4. Small Projects
For small projects, the safety plan may be part of an overall project management plan.
 Div
idtabs-5
5. Resources

refstable
toolstable
 Div
idtabs-6
6. Lessons Learned
No lessons learned have currently been identified for this requirement.



    
    






    
	

    
    
    



    




    
    

    
    
    






        



        

    

    



										
								
		        

		    



		
						
 











Page Editor: Tim Crumbley 

NASA Official: Tim Crumbley






NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer

 NASA Privacy Statement

______________________________________________________________________________