bannerc

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

Compare with Current View Page History

« Previous Version 6 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 278
  • 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.

Concept Phase:

  • The first safety analysis is performed during system concept and beginning requirements phase. A common assessment tool used during this beginning activity is the Preliminary Hazard Analysis (PHA). The results of the PHA are a list of hazard causes and a set of candidate hazard controls, that are taken forward as inputs to the system and software safety requirements flow-down process.
  • Review the lists of known software-based hazards, hazard contributions and hazard controls to determine whether any of these might be applicable for this project.
  • Review the project’s Concept Development and any available Operational Concept information to become aware of any potential security threats and risks that may affect safety. Assure that mitigations are being planned for these.
  • Software Safety personnel should develop a good working relationship with any IV&V team on the project to provide more focus any safety-related issues on the project. 

Planning: 

  • Ensure that software safety is addressed in project acquisition, planning, management, and control activities.
  • Ensure that the acquisition of software, whether off-the-shelf or contracted, includes evaluation, assessment, and planning for addressing and mitigating risks due to the software’s contribution to safety and any limitations of the software.
  • The Engineering Technical Authority and S&MA Technical Authority will jointly determine if the software is designated as “safety-critical”. See criteria in NASA-STD-8739.8A,  278 Appendix A.
  • Software Safety personnel need to develop a Safety Plan, including safety activities, requirements, effort estimates and schedule. The Safety Plan may be part of the Software Assurance Plan.
    • Additional planning activities may need to be done whenever heritage, reused or COTS software are planned for use, for example:
      • Hazard analysis may need to be done for this software.
      • Additional analysis, testing, and verification may need to be done, depending on the documentation and other information available with the COTS, reused, heritage code.
      • Additional functionality may need to be added; Unused functions may need to be removed.

See Topic  8.8 - COTS Software Safety Considerations in this Handbook for more information on using COTS.

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