You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Copy of 8.20 - Safety Specific Activities in Each Phase

1. Safety Specific Activities in Each Phase 

This topic provides a summary of the safety-specific activities that should be performed for any safety-critical software. The activities are grouped into the approximate life cycle phases where they will be performed. 

All Phases: 

  • Ensure that software safety is considered throughout the system life-cycle, including mission concept, generation of requirements, design, coding, test, maintenance, and operation of the software.
  • Develop and maintain a software safety analysis throughout the life cycle.
  • Participate in software reviews affecting safety-critical software products.
  • Confirm that the identified safety-critical software components and data have implemented the safety-critical software assurance requirements listed in the standard, NASA-STD-8739.8. 
  • Review all safety-related technical issues, risks, and/or assurance findings and ensure that the project is aware of any items needing attention and is addressing them.
  • All safety-critical items (e.g. requirements, design, code, test plans, test procedures, hazard reports, data uploads, documentation, etc.) should be kept under configuration management.  Safety personnel need to verify that their safety products are in the configuration management system and they should ensure that they are using the correct versions of the products.

2. Resources

2.1 References

No references have been currently identified for this Topic. If you wish to suggest a reference, please leave a comment below.

2.2 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.

  • No labels