bannerd


8.51 - Software Assurance Plan

Return to 8.16 - SA Products

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 379  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 7.02 - 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 278are 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 8.15 - SA Tasking Checklist Tool).
    • 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.
  • 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 379  provides a template prescribing the recommended Security Plan content.


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:

SWE #

NPR 7150.2 Requirement

NASA-STD-8739.8 Software Assurance and Software Safety Tasks per SA Standard

013

3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.

2. Develop and maintain a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety.

121

3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.

2. Develop a tailoring matrix of software assurance and software safety requirements.

125

3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 

2. Maintain the requirements mapping matrix (matrices) for requirements in NASA-STD-8739.8.

151

3.2.2 The project manager’s software cost estimate(s) shall satisfy the following conditions: 

a. Covers the entire software life cycle.
b. Is based on selected project attributes (e.g., programmatic assumptions/constraints, assessment of the size, functionality, complexity, criticality, reuse code, modified code, and risk of the software processes and products).
c. Is based on the cost implications of the technology to be used and the required maturation of that technology.
d. Incorporates risk and uncertainty, including end state risk and threat assessments for cybersecurity.
e. Includes the cost of the required software assurance support.
f. Includes other direct costs.

 

1. Assess the project's software cost estimate(s) to determine if the stated criteria listed in "a" through "f" are satisfied.

016

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

    1. Coordinates with the overall project schedule.
    2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
    3. Reflects the critical dependencies for software development activities.
    4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

2. Develop a software assurance schedule, including software assurance products, audits, reporting, and reviews.

046

3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

1. Confirm the project's schedules, including the software assurance’s/software safety’s schedules, are updated.

020

3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D. 

1. Perform a software classification or concur with the engineering software classification of software per the descriptions in NPR 7150.2.

1.1 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

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 - Documentation Guidance.) 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. 

2.2 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

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.

3.2 Additional Guidance

Links to Additional Guidance materials for this subject have been compiled in the Relevant Links table. Click here to see the Additional Guidance in the Resources tab.

4. Resources

4.1 References


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

4.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

4.4 Center Process Asset Libraries

SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki  197

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 



  • No labels