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. Initial identification of the 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-critical personnel needed to perform the software safety-critical activities and their organization. Obtain Center SMA approval for personnel from SMA, if necessary.
    2. Technical Resources – Identify resources needed to perform the software safety-critical activities (e.g., necessary tools, access to information, training).
    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 the Software Assurance and Software Safety standard, 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 to the provider's organization.
    5. Pointers to the organizational processes to be used during the assessment activities and 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 – Identify the software safety-critical products that will be generated by software safety-critical activities during the project and specify the location where they will be stored, level of control needed (e.g., configuration management), and retention schedule. 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.
  4. Schedule for software safety activities. The schedule should include:
    1. Schedule for the preliminary Hazard analysis evaluation activities.
    2. Schedule for 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. Schedule for all software safety deliverables.
      1. Note: Dates should also be coordinated with the project/program safety panel/group.

    4. Schedule for deliveries of safety analyses to meet engineering deadlines and keep project and SMA management advised of risks.
    5. Schedule of periodic evaluation and reporting of adherence to the software safety plan (both for the acquirer and the supplier).
    6. Schedule for the SMA evaluation process for supplier adherence to the supplier software safety plan (e.g., traceability review, process audits, etc.).
    7. Schedule for the process audits and
    8. Schedule for participation responsibilities in system and facility safety reviews and any specific software safety reviews. 
    9. Schedule for any unique training required.
    10. Schedule for software safety unique software tool procurement, installation, and training if needed.
  5. Acronyms – In alphabetic order, define all abbreviations and acronyms used in the plan.
  6. Glossary – Define all terms that are unique to the SA document.
  7. 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.
  8. References – List any documents and reference material used to develop the software safety-critical activities.
  • No labels