5.18 - Safety Plan Minimum Content

3.1 Minimum Recommended Content

Software Safety Plan (SSP) Contents 

When projects determine they have safety-critical software, they need to plan the activities to ensure that all the safety elements in the project get the appropriate attention to produce high quality, safe system. The specific activities related to safety can be in a stand-alone software safety plan or combined into a software management, software assurance, or software development plan.  The point is to address the software safety planning elements.

When developing a software safety plan, the following should be considered, at a minimum:

1. Safety Critical Components - Identify the initial software safety criticality components to determine the extent of the software safety effort needed. 
2. Project Resources
   1. Personnel Allocation – Identify the total software safety personnel needed to perform the software safety-critical activities and their organization. 
   2. Technical Resources – Identify resources needed to perform the software safety-critical activities, e.g.,
      1. Project Tools – List of the tools and versions needed to perform safety-critical activities.
      2. Access Requirements – Access to project information and repositories, websites, databases, training, etc.
   3. Project Roles & Responsibilities – Identify the project’s software, safety-critical roles, and responsibilities. Indicate the division of responsibilities for implementing the software safety-critical requirements of NASA-STD-8739.8, clearly indicating Center SMA organization versus Project roles and responsibilities.
   4. Organization and Management – Illustrate/Describe the software safety-critical organization's structure and relationships to project management and the provider's organization.
   5. Software Safety Processes – Describe the software safety processes or provide pointers to the processes to be used for the hazard analysis and safety assessment activities during the implementation of the software safety-critical requirements.
   6. Communication Plan – Describe how personnel will communicate processes, schedules, methods, and deliverables among the teams.
3. Data Management Plan – The Data Management Plan includes products used to document and report on software safety-critical analysis and reviews of software development activities, products, and results.
   1. SA Products – Identify the SA products (i.e., from the SA Products List) that will be generated by Software Safety personnel for the safety-critical activities during the project.
   2. Product Storage – Specify the location where the products will be stored, the level of control needed (e.g., configuration management), and the retention schedule. 
4. Schedule for software safety activities. The schedule should include:
   1. Preliminary Hazard Analysis (PHA) evaluation activities.
   2. Hazard Analysis re-evaluations throughout the life cycle, including any software safety-critical re-evaluations throughout the life cycle and where the results are maintained. 
   3. All software safety deliverables.

      1. Note: Dates should also be coordinated with the project/program safety panel/group.

   4. Deliveries of safety analyses to meet engineering deadlines and keep the project and SMA management advised of risks.
   5. Periodic evaluation and reporting of adherence to the software safety plan.
   6. SMA evaluation process for supplier adherence to the supplier software safety plan (e.g., traceability review, process audits, etc.).
   7. Process audits and product assessments.
   8. Participation responsibilities in system and facility safety reviews and any specific software safety reviews. 
   9. Software safety unique software tool procurement, installation, and training if needed.
5. Safety-Specific Training – Identify any safety-specific training that is necessary for software safety personnel to perform their Software Safety activities properly
6. Acronyms – In alphabetic order, define all abbreviations and acronyms used in the plan.
7. Glossary – Define all terms that are unique to the SA document.
8. Document Change Procedure and History – Define the procedures that are to be used to modify the plan and maintain the history of all changes and modifications that are defined by the SA section of the plan.
9. References – List any documents and reference material used to develop the software safety-critical activities.