bannerc
SAP - Software Assurance Plan

Return to 7.18 - Documentation Guidance

1. Minimum Recommended Content

Software Assurance Plan Content

The following section defines the content for a Software Assurance Plan. 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 Compliance 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. Resources

2.1 References

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.

3. Lessons Learned

3.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

3.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

  • No labels