1. Introduction

The Software Assurance (SA) Plan product documents the expected work for the Software Assurance and Software Safety (if applicable) personnel for the project. It is the document that establishes what project SA activities will be performed and how they will be managed. The plan includes topics such as project roles and staffing, schedules of activities to be performed, processes and methodologies to be used, relationships with other groups/organizations, and how safety critical software will be assured.

The SA Plan is comprised of many pieces that provide specific information to the projects. (See Tab 2. SA Plan Content.) While all of these pieces may be included in one document, they may be broken into separate documents and referenced in the SA Plan. The sub-products listed below are considered part of the SA Plan:

• Software Safety Plan – This is only required if the project has safety critical components. The minimum contents for the software safety plan are contained in Tab 3 Software Safety Plan Content.
• Security Plan – The security plan is the responsibility of the project’s security team or the Center Security personnel, thus it is not covered in this section. For reference, the National Institute of Standards and Technology (NIST) publication 800-171 provides a template prescribing the recommended Security Plan content.
• Software Classification Determination – The agreed upon classification of each of the software modules must be recorded and kept in some location accessible by the whole project. This location can be in the SA Plan, the Software Safety Plan or some other location specified in the project’s data management plan. The classifications should be reviewed periodically if there are requirements changes or other changes (e.g. intended use of the software) that might cause a change in classification. See Topic 2 - Classification and Safety-Criticality for more details.
• Software Assurance Requirements Mapping Matrix – This matrix is required to show which software assurance and software safety requirements in NASA-STD-8739.8 are being tailored. This is typically a part of the software assurance plan or is contained in a record referenced by the software assurance plan. This requirement may be fulfilled by using the SA Tasking Checklist Tool (See Topic 8.15).
  • Note: SA should build their mapping matrix using the approved tailored SWE requirements mapping matrix for the project. If SWE tailors out a requirement, SA is not expected to perform the associated SA task(s).
• Software Assurance Schedule – Provide a schedule with SA activities aligned with the project schedule and life cycle products or indicate the location of a project schedule that contains the SA activities. If the project has safety critical components, the schedule for safety activities may be: a.) included in the overall project schedule, b.) combined with the software assurance schedule, or c.) included in the Software Safety Plan.
• Safety Schedule: See Software Assurance Schedule.

The information in this topic is divided into several tabs as follows:

• Tab 1 – Introduction
• Tab 2 – SA Plan Content – provides the current minimum content for SA Plan 
• Tab 3 – Software Safety Plan Content – provides the current minimum content for Software Safety Plan
• Tab 4 – Resources for this topic

The following is a list of the applicable SWE requirements that relate to the generation of the SA Plan:

2. SA Plan Content

2.1 Minimum Recommended Content

The following section defines the minimum recommended content for a Software Assurance Plan (SAP). (Note: This contents was previously located in Topic 7.18.) The SA Plan provides insight into the methods, approaches, responsibilities, and processes for the assurance activities of all life-cycle and mission phases.  If a content section does not apply, state “Not Applicable.” The SA Plan’s content, collectively, addresses:

1. Introduction – The introduction to the plan states its purpose and scope. It also provides an overview of the document's organization and a brief description of each section of the plan.
   • Purpose – Briefly state the purpose of the document.
   • Scope – Briefly state the scope of the project.
2. Software Assurance Activities – Describe all planned assurance activities. Identify and define the software assurance planning and oversight activities throughout the life cycle. Examples are:
   • Planned audits and assessments
   • Status Reporting
   • Analysis activities
3. Software Assurance Methods – Specify the SA methods used to confirm, monitor, assess, analyze, and perform software activities. Examples are:
   • Standing meetings w/ Project Manager and software engineering
   • Standing meetings w/ SA Team
   • Reviewing products and processes
   • Test Witnessing and reviewing test results
   • Reporting inconsistencies, defects, non-conformances, risks, etc.
   • Analysis Methods (PHAs, HAs, FMEAs, FTAs, Static Code Analysis, etc.)
4. Stakeholder Management Plan – Identify the stakeholders and their involvement in the project.

5. Project Resources

   • Personnel Allocation – Identify the total SA personnel needed to perform the SA activities and their organization. Obtain Center SMA approval for personnel from SMA, if necessary.
   • Technical Resources – Identify resources needed to perform the SA activities (e.g., necessary tools, access to information)
   • Project Roles & Responsibilities – Identify the project’s SA roles and responsibilities. Indicate the division of responsibilities for implementing the requirements of the SA standard, clearly indicating Center SMA organization versus Project SA roles and responsibilities.
   • Organization and Management – Illustrate/Describe the software assurance organization's structure and relationships to project management and to the provider's organization.
6. Data Management Plan – Identify the SA products (i.e., from the SA Products List) that will be generated by SA during the project and specify the location where they will be stored, level of control needed (e.g., configuration management), and the retention schedule. The Data Management Plan includes products used to document and report on SA analysis and reviews of SW development activities, products, and results.
7. Acceptance criteria for all identified software assurance and software safety products.
8. Software Safety-Critical Assessment (if needed) – Include the results of the initial safety criticality assessment. Update at milestones, as necessary, including any concerns or push-back on the safety criticality determination.
9. Risk Management – Identify the process used for risk management of any SA identified software risks. 
10. Project-Specific Training – Identify any Project-specific training that is necessary for SA personnel to implement their Software Assurance activities properly.
11. Communication Plan – Describe how SA personnel will communicate processes, schedules, methods, and deliverables among the SA teams.
12. Software Assurance Requirements Mapping Matrix showing the implementation of the requirements in the SA Standard.
13. Metrics – Identify the SA metrics to be collected with their analysis procedures, storage procedures, and reporting plans. At a minimum, collect and report on the list of SA metrics specified in the SA Standard.
14. Issue tracking – Describe the problem reporting and corrective action system used during the software life cycle. Identify the practices and procedures that are to be used for reporting, tracking, and resolving problems or issues.
15. Acronyms – In alphabetic order, define all abbreviations and acronyms used in the plan.
16. Glossary – Define all terms that are unique to the SA document.
17. 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.
18. Project Schedule – Provide a schedule with SA activities aligned with the project schedule and life cycle products or an aligned schedule location

3. Safety Plan 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. 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.

4. Resources

4.1 References

4.2 Tools