![](media/image1.png){width="2.1in" height="1.4333333333333333in"}

**\<Project Name\>**

**Software Quality Assurance (SQA) Plan**

**\<Document Control Number\>**

**Date: \<Month Year\>**

**General Tailoring Guidelines**

This document is a template for a Software Quality Assurance Plan
intended for use by Code 303, Assurance Management Office (AMO)
personnel as the basis for a mission-specific Software Quality Assurance
Plan.

There are three general types of text format: Text in Black, Text in
Blue with \< \>,\
Text in Blue with \[ \] and Text underlined in [blue]{.underline}.

[Text in Black]{.underline}

-   Text in this style, black, is used for text that is equally
    applicable to all Software Quality Assurance Plans and will be
    included in the Software Quality Assurance Plan without
    modification. All document section headings are in the same
    category.

[Text in Blue with \< \>]{.underline}

-   Text in this style, \<blue\>, is used to indicate that the text
    needs to be updated with project specific information such as the
    project name, persons name, persons title, date, revision #,
    Document Control Number, exc...

[Text in Blue with \[ \]]{.underline}

-   Text in this style, \[blue\], is used to indicate that there is
    additional instruction for tailoring text in any specific section.
    Delete this style, \[blue\], text before the document is finalized.

[Text underlined in Blue]{.underline}

-   Text in this style, [blue]{.underline}, is used to indicate active
    links. These links are usually to project or software assurance
    websites. The text color may very depending on each persons personal
    computer settings/configuration.

All components of the *[table of contents]{.underline}* will be
addressed, but the level of detail is left up to the software quality
personnel. The length and level of detail of the Software Quality
Assurance Plan should be commensurate with the scope and complexity of
the project.

*[Section headings]{.underline}* may be added where necessary, but
**existing headings should not be modified or deleted**. If a particular
section is not applicable to the specific Software Quality Assurance
Plan under production, that fact should be noted under the section
heading, together with a brief explanation.

The following *[disclaimer]{.underline}* appears on all pages: "Printed
copies of this document are for REFERENCE PURPOSES ONLY! The only
controlled copy of this document is located on-line at
\<[http://xxxxxxxx\>](). This disclaimer should be modified to contain
the appropriate URL, but should not be removed.

Finally, in the Software Assurance Plan Template, this entire section
("**General Tailoring Guidelines**") will be deleted.

**Foreword**

This document is a \<Project Name\> Project controlled document and
adheres to IEEE 730-2002, the IEEE Standard for Software Quality
Assurance Plans. Changes to this document require prior approval of the
\<Project Name\> Project Configuration Control Board (CCB). Proposed
changes shall be submitted to the \<Project Name\> Systems Assurance
Manager (SAM), along with supportive material justifying the proposed
change.

Questions or comments concerning this document should be addressed to
the Assurance Management Office:

\<Project Name\>, \<SAM Name\>/Code 303

Building \<XX\> Room \<XXX\>

Mail Stop \<XXX\>

Goddard Space Flight Center

Greenbelt, Maryland 20771

\(301\) \<XXX-XXXX\>

**Signature Page**

+----------------------------------+-----------------------------------+
| ***Prepared by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_                   |                                   |
|                                  |                                   |
| \<Preparer Name\> \<Date\>       |                                   |
|                                  |                                   |
| \<Preparer Title\>               |                                   |
+----------------------------------+-----------------------------------+
| ***Reviewed by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_                   | \_\_\_\_\_\_\_\_\_ \<Reviewer     |
|                                  | Name\> \<Date\>                   |
| \<Reviewer Name\> \<Date\>       |                                   |
|                                  | \<Reviewer Title\>                |
| \<Reviewer Title\>               |                                   |
+----------------------------------+-----------------------------------+
|                                  |                                   |
+----------------------------------+-----------------------------------+
| ***Approved by:***               |                                   |
+----------------------------------+-----------------------------------+
| \_\_\_\_\_\_\_                   |                                   |
|                                  |                                   |
| \<Approver Name\> \<Date\>       |                                   |
|                                  |                                   |
| \<Approver Title\>               |                                   |
+----------------------------------+-----------------------------------+

**\<Project Name\> Project Document Title**

**DOCUMENT CHANGE RECORD** Sheet: 1 of 1

+-----+--------------------------------------------+-----------+------+
| R   | DESCRIPTION OF CHANGE                      | APPROVED  | DATE |
| EV/ |                                            |           |      |
| VER |                                            | BY        | APPR |
|     |                                            |           | OVED |
| LE  |                                            |           |      |
| VEL |                                            |           |      |
+-----+--------------------------------------------+-----------+------+
| \   | \<Initial Publication\>                    | \         | \<M  |
| <RE |                                            | <Approver | onth |
| V - |                                            | Name\>    | Day, |
| #\> |                                            |           | Ye   |
|     |                                            |           | ar\> |
+-----+--------------------------------------------+-----------+------+

Table of Contents

[1.0 Purpose 1](#purpose)

[1.1 Scope 1](#scope)

[2.0 Reference Documents 2](#reference-documents)

[3.0 Management 3](#management)

[3.1 Management Organization 3](#management-organization)

[3.1.1 \<Project Name\> Project Office 3](#project-name-project-office)

[3.1.2 Assurance Management Office 3](#assurance-management-office)

[3.2 Tasks 5](#tasks)

[3.2.1 Product Assessments 5](#product-assessments)

[3.2.2 Process Assessments 5](#process-assessments)

[3.3 Roles and Responsibility 7](#roles-and-responsibility)

[3.3.1 SAM 7](#sam)

[3.3.2 Software Quality Personnel 7](#software-quality-personnel)

[3.3.3 Other OSSMA Personnel 8](#other-ossma-personnel)

[3.4 Software Assurance Estimated Resources
9](#software-assurance-estimated-resources)

[4.0 Documentation 10](#documentation)

[4.1 Purpose 10](#purpose-1)

[4.2 Minimum Documentation Requirement
10](#minimum-documentation-requirement)

[5.0 Standards, Practices, Conventions, and Metrics
11](#standards-practices-conventions-and-metrics)

[5.1 Purpose 11](#purpose-2)

[5.2 Software Quality Program 11](#software-quality-program)

[5.2.1 Standard Metrics 11](#standard-metrics)

[6.0 Software Reviews 13](#software-reviews)

[6.1 Purpose 13](#purpose-3)

[6.2 Minimum Software Reviews 13](#minimum-software-reviews)

[7.0 Test 14](#test)

[8.0 Problem Reporting and Corrective Action
14](#problem-reporting-and-corrective-action)

[9.0 Tools, Techniques and Methodologies
14](#tools-techniques-and-methodologies)

[9.1 NASA GSFC Tools 14](#nasa-gsfc-tools)

[9.2 Software Quality Tools 14](#software-quality-tools)

[9.3 Project Tools 15](#project-tools)

[10.0 Media Control 15](#media-control)

[11.0 Supplier Control 15](#__RefHeading___Toc68068014)

[12.0 Record Collection, Maintenance, and Retention
16](#__RefHeading___Toc68068015)

13.0 Training 17

[14.0 Risk Management 1](#risk-management)8

[15.0 Glossary 1](#glossary)9

16.0 SQA Plan Change Procedure and History 20

**List Of Tables**

Table

[Table 3-2 Software Assurance Resources 9](#__RefHeading___Toc68068662)

# Purpose

The purpose of this Software Quality Assurance (SQA) Plan is to
establish the goals, processes, and responsibilities required to
implement effective quality assurance functions for the \<Project Name\>
project.

The \<Project Name\> Software Quality Assurance Plan provides the
framework necessary to ensure a consistent approach to software quality
assurance throughout the project life cycle. It defines the approach
that will be used by the SAM and Software Quality (SQ) personnel to
monitor and assess software development processes and products to
provide objective insight into the maturity and quality of the software.
The systematic monitoring of \<Project Name\> products, processes, and
services will be evaluated to ensure they meet requirements and comply
with National Aeronautics and Space Administration (NASA), Goddard Space
Flight Center (GSFC), and \<Project Name\> policies, standards, and
procedures, as well as applicable Institute of Electrical and Electronic
Engineers (IEEE) standards.

## Scope

This plan covers SQA activities throughout the \<identify phases, e.g.,
formulation and implementation\> phases of the \<Project Name\> mission.
\[Indicate whether or not SQA activities will continue through
operations and maintenance of the system.\]

\[Enter a brief description of the project, the suppliers of the
software, the software items covered by the plan, and their intended
use.\]

# Reference Documents

The following documents were used or referenced in the development of
this plan:

-   NASA-STD-8719.13, NASA Software Safety Standard

-   NASA-STD-8739.8, NASA Software Assurance Standard

-   NPR 7150.2, NASA Software Engineering Requirements

-   GPG 5100.3, Quality Assurance Letter of Delegation

-   GPG 7120.4, Risk Management

-   GPG 8700.4, Integrated Independent Reviews

-   GPG 8700.6, Engineering Peer Reviews

-   303-PG-1060.1.1, Systems Assurance Manager Reporting

-   303-PG-1060.1.2, Assurance Management

-   303-PG-7120.2.1, Procedure for Developing and Implementing Software
    Quality Programs

-   300-PG-7120.2.2, Mission Assurance Guidelines (MAG) For Tailoring to
    the needs of GSFC Projects

-   303-WI-7120.2.2, Software Quality Assessment Process

-   303-WI-7120.2.1, Software Quality Reporting Process

-   IEEE STD 730-2002, IEEE Standard for Software Quality Assurance
    Plans

-   \<Project Name\> Project Surveillance Plan

-   \<Project Name\> Project Plan

-   \<Project Name\> System Implementation Plan (SIP)

-   \<Project\> Software Management Plan (or Product Plan)

-   \<Project\> Statement of Work (SOW)

-   \<Project\> Configuration Management Plan (CMP)

\[Update the reference document list to include a list of project
documents used or referenced in the development of this plan. This
includes policies, standards, procedures, guidelines, and other similar
documents. Note: the last 6 documents listed are examples of project
plans that you might include. Cite them only if they apply and/or add
others specific to your project.\]

# Management

This section describes the management organizational structure, its
roles and responsibilities, and the software quality tasks to be
performed.

## Management Organization

\<Project Name\> efforts are supported by numerous entities,
organizations and personnel (see \<Project Name\> internal website for a
detailed organizational chart). Relevant entities/roles that are of
interest and applicable to this SQA Plan and the software assurance
effort are described at a high level below.

\[Enter a copy of the project's management organizational chart or the
project's website where this information can be found. This chart should
reflect the project's interface with Code 303.\]

### \<Project Name\> Project Office

The \<Project Name\> Project Office at NASA GSFC is responsible for
management of project objectives within the guidelines and controls
prescribed by NASA Headquarters, GSFC Management, and the \<Project
Name\> Project Plan. The Project Manager (PM) from GSFC Code \<enter
Code\> is specifically responsible for the success of the \<Project
Name\> Project, including but not limited to cost, schedule, and
quality.

### Assurance Management Office

The Assurance Management Office (AMO), Code 303, provides mission
assurance support to NASA GSFC programs and projects (Reference
303-PG-1060.1.2). The AMO is comprised of civil service Systems
Assurance Managers (SAMs), Quality Assurance Specialists (QASs), and
Product Assurance Engineers (PAEs). The SAM assigned to a project is an
AMO civil service representative responsible for supporting the Project
Manager in the coordination of the definition and implementation of a
Project Mission Assurance Program.

The SAM provides Project Management with visibility into the processes
being used by the software development teams and the quality of the
products being built. The SAM is matrixed to the \<Project\> project and
maintains a level of independence from the project and the software
developers. Risk escalation begins at the project level, and extends to
the AMO and the Office of Systems Safety and Mission Assurance (OSSMA),
Code 300.

In support of software quality assurance activities, the SAM has
assigned and secured Software Quality personnel from the Mission
Assurance Services Contract (MASC) to coordinate and conduct the SQ
activities for the project and identify and document noncompliance
issues. In the future and on an as needed basis, SQ personnel support
from the Supplier Assurance Contract (SAC) and/or Defense Contract
Management Agency (DCMA) may be utilized to support the SQ activities at
remote (non-GSFC) locations.

Additional support personnel may also include OSSMA Safety and
Reliability and NASA Independent Verification and Validation (IV&V)
personnel from the NASA IV&V Facility in Fairmont, WV. For additional
details on IV&V activities, reference the IV&V Memorandum of Agreement
(MOA) and/or the IV&V Project Plan (IVVP). \[Identify which IV&V
agreements/plans are applicable to your project.\]

\[Enter any additional management organization and/or suppliers
providing support to this project. Some examples of other management
organizations include the Observatory provider, instrument provider,
and/or ground data system providers.\]

## Tasks

This section summarizes the tasks (product and process assessments) to
be performed during the development, operations, and maintenance of
software. These tasks are selected based on the developer's Project
Schedule, Software Management Plan (SMP) (and/or Software Maintenance
Plan) and planned deliverables, contractual deliverables, and identified
reviews. Reference 303-PG-7120.2.1, Procedure for Developing and
Implementing Software Quality Programs, for additional information on
the various process and product assessments. Reference 303-WI-7120.2.2,
Software Quality Assessment Process, for specific instructions on
conducting process and product assessments.

Reference the NASA GSFC Software Assurance web site,
[[http://sw-assurance.gsfc.nasa.gov](http://sw-assurancegsfc.nasa.gov/)]{.underline}
to retrieve software quality checklists and forms. This site is owned
and maintained by the NASA GSFC Software Assurance Lead, located in the
OSSMA.

### Product Assessments

The following are typical product assessments that may be conducted by
SQ personnel. See the SQ Activity Schedule for the planned assessments:

-   Peer Review packages

-   Document Reviews (see Section 4, Documentation)

-   Software Development Folders

-   Software Configuration Management (e.g., configuration baselines,
    configuration change requests, and change control records)

-   Test results (e.g., requirements traceability matrix, test reports)

### Process Assessments

The following are typical process assessments that may be conducted by
SQ personnel. See the SQ Activity Schedule for the planned assessments:

-   Project Planning

-   Project Monitoring and Control

-   Measurement and Analysis

-   System/Subsystem Reviews

-   Peer Reviews

-   Requirements Management

-   Software Configuration Management and Configuration Audits (FCA/PCA)

-   Test Management (Verification & Validation)

-   Software Problem Reporting and Corrective Action

-   Risk Management

-   Supplier Agreement Management

\[Add or delete assessments from Sections 3.2.1 and 3.2.2 to establish a
comprehensive list of processes and products you intend to monitor
and/or assess.\]

## Roles and Responsibility

This section describes the roles and responsibilities for each assurance
person assigned to the \<Project Name\> Project.

### SAM

Responsibilities include, but are not limited to:

-   Secure and manage SQ personnel resource levels

-   Ensure that SQ personnel have office space and the appropriate tools
    to conduct SQ activities

-   Provide general guidance and direction to the SQ personnel
    responsible for conducting software quality activities and
    assessments

-   Issue Letters of Delegation, MASC Service Orders, and SAC task
    orders to initiate software support services (as required)

-   Provide AMO with weekly and quarterly software status (per
    303-PG-1060.1.1, Systems Assurance Manager Reporting)

-   Assist SQ personnel in the resolution of any noncompliances, issues
    and/or risks identified as a result of software quality activities

-   Escalate any noncompliances to project management

### Software Quality Personnel

Responsibilities include, but are not limited to:

-   Develop and maintain the project software quality assurance plan

-   Generate and maintain a schedule of software quality assurance
    activities

-   Conduct process and product assessments, as described within this
    plan, using objective criteria

-   Interface with Safety, Reliability, and IV&V personnel on software
    assurance activities

-   Identify and document noncompliances, observations, and risks from
    all software assurance related activities to the SAM

-   Communicate results from assessments with relevant stakeholders

-   Ensure resolution of noncompliances and escalate any issues that
    cannot be resolved within the project

-   Identify lessons learned that could improve processes for future
    products

-   Develop and maintain metrics

### Other OSSMA Personnel

The Systems Safety and Reliability Office, Code 302, provides NASA GSFC
projects with Safety and Reliability support. The following are the
primary responsibilities for Safety and Reliability personnel in support
of software assurance.

#### Safety Personnel

Responsibilities include, but are not limited to:

-   Provide system software safety expertise to the SQ personnel and/or
    project personnel, as required

-   Assist in the assessment of the various software development efforts
    in terms of meeting applicable software safety standards and
    requirements

-   Assist in the resolution of any software safety related issues,
    concerns, and/or risks identified throughout the project life cycle

-   Assist in the review of various life cycle related artifacts as they
    pertain to system software safety

For additional support information, reference the project's System
Safety Plan.

\[Note: make sure this information is covered in the System Safety
Plan.\]

#### 3.3.3.2 Reliability Personnel {#reliability-personnel .unnumbered}

Responsibilities include, but are not limited to:

-   Provide software reliability expertise to the SQ personnel and/or
    project personnel, as required. Assist in the assessment of the
    various software development efforts in terms of meeting applicable
    software reliability standards and requirements

-   Assist in the resolution of any software reliability related issues,
    concerns, and/or risks identified throughout the life cycle

-   Assist in the review of various life cycle related artifacts as they
    pertain to software reliability

## Software Assurance Estimated Resources

Staffing to support software assurance (i.e., quality, safety, and
reliability) activities must be balanced against various project
characteristics and constraints, including cost, schedule, maturity
level of the providers, criticality of the software being developed,
return on investment, perceived risk, etc.

The staffing resource levels provided in the table below represent what
has currently been agreed upon between Project Management and the SAM.
For applicable IV &V resources, see the \<Project Name\> IV&V MOA or
IVVP. As the project's efforts progress, these staffing resource levels
may be revisited and updated as necessary to complete the
activities/tasks described within this plan. \[NOTE: Table 3-2 can be
omitted from the SQAP so long as a reference to the information is
provided and the resource information is maintained.\]

[]{#__RefHeading___Toc68068662 .anchor}Table 3-2 Software Assurance
Resources

  ------------------------------------ -------------- -------------- --------------
  **Support Personnel**                **FY\<YY\>**   **FY\<YY\>**   **FY\<YY\>**

  SQ Personnel                         \<x.x\> FTE    \<x.x\> FTE    \<x.x\> FTE

  Safety Personnel                     \<x.x\> FTE    \<x.x\> FTE    \<x.x\> FTE

  Reliability Personnel                \<x.x\> FTE    \<x.x\> FTE    \<x.x\> FTE

  DCMA                                 \<x.x\> FTE    \<x.x\> FTE    \<x.x\> FTE

  SAC                                  \<x.x\> FTE    \<x.x\> FTE    \<x.x\> FTE
  ------------------------------------ -------------- -------------- --------------

x.x = FTE number (1.0, 0.5, 2.5, etc...)

YY = Year (04, 05, 06, 07, etc...)

\[Enter the Resource Level by Full Time Equivalent (FTE) and Fiscal Year
for the duration of the project life cycle. Example resource data is
provided. Update the table to highlight all software assurance resources
supporting the project.\]

See Section 9 for a list of additional resources for performing process
and product quality assurance activities.

# Documentation

## Purpose

This section identifies the minimum documentation governing the
requirements, development, verification, validation, and maintenance of
software that falls within the scope of this software quality plan. Each
document below shall be assessed (reviewed) by SQ personnel.

\[Include only those documents that exist for your program/project and
that you have resources to actually review. Include in section 4.2 known
documents from the Software Management Plan (SMP), Statement of Work
(SOW), and Contract Deliverable Requirements List (CDRL).\]

## Minimum Documentation Requirement

-   Quality Manual

-   Software Assurance Plan

-   Software Management Plan

-   Configuration Management Plan

-   Software Requirements Specification

-   Risk Management Plan

-   Software Safety Plan

-   Test Plans (Verification and Validation)

-   Software User's Guide

-   Software Maintenance Plan

-   Interface Control Document(s)

-   Test Reports and Artifacts

-   Software Version Description Document (VDD)

-   Software Requirements Traceability Matrix

-   Software Development Records

-   Peer Review data packages

# Standards, Practices, Conventions, and Metrics

## Purpose

This section highlights the standards, practices, quality requirements,
and metrics to be applied to ensure a successful software quality
program.

## Software Quality Program

Software Quality Programs at GSFC are governed by the NASA Software
Assurance Policies, the NASA Software Assurance Standard, and the NASA
Software Safety Standard. Together, these NASA documents establish a
common framework for software processes and products throughout the life
of the software. In addition, SQ personnel are governed by software
quality procedures, work instructions, checklists, and forms developed
and approved by the AMO. These practices and conventions are tools used
to ensure a consistent and objective approach to software quality for
all GSFC programs/projects. SQ personnel are also experienced in the
Software Engineering Institute Capability Maturity Model Integration
(SEI-CMMI) methodology and are applying generic and specific practices
for Process and Product Quality Assurance (PPQA) in support of GSFC's
Software Process Improvement Program.

For details on the specific procedures, work instructions, checklists,
and forms used by SQ personnel, reference
[http://sw-assurance.gsfc.nasa.gov](http://sw-assurance.gsfc.nasa.gov/).

For details on the development standards for documentation, design,
code, and test, reference \<the developer's site\>.

### Standard Metrics

The following standard metrics are the minimum planned metrics that will
be collected, reported, and maintained in the area of software quality
assurance:

-   SQ effort and funds expended (Planned vs. Actual)

-   Number of SQ Assessments (Planned vs. Actual)

-   Number of SQ Assessment Findings or noncompliances (Open vs. Closed)

-   Number of SQ Assessment Observations

-   Number of Risks identified as a result of an SQ Assessment

Additional Project metrics may also be collected, reported, and
maintained, as required by the SAM. Sample metrics include:

-   Number of Peer Reviews (Planned vs. Actual)

-   Number of Open vs. Closed Action Items from peer reviews

```{=html}
<!-- -->
```
-   Number of Open vs. Closed Software Problem Reports, with aging and
    trending over a specified time frame

-   Number of Open vs. Closed IV&V issues (via the Facility's Project
    Issue Tracking System (PITS))

-   Number of Open vs. Closed software Requests for Action (RFAs) or
    Action Items from project-level reviews (e.g., mission PDR or CDR)

# Software Reviews

## Purpose

This section identifies the number and type of system/subsystem reviews
and engineering peer reviews that will be supported by the SQ Personnel.
The Software Management Plan (SMP), the project milestone chart, the
project's Engineering Peer Review Plan, and the SQ Personnel resource
levels determine the reviews that are supported. \[Reference only those
project plans or schedules that form the basis of the review schedule.\]

\[Identify the location of the software review schedule.\]

## Minimum Software Reviews

For each review, SQ will assess the review products to assure that
review packages are being developed according to the specified criteria,
the review content is complete, accurate, and of sufficient detail, and
Requests for Action are captured, reviewed, and tracked to closure. In
addition, SQ will assess the processes used to conduct the reviews to
determine if appropriate personnel are in attendance, correct
information is presented, entry and exit criteria are met, and
appropriate documents are identified for update.

The following software reviews may be assessed by SQ:

-   System Concept Review (SCR)

-   Software Specification Review (SSR)

-   Preliminary Design Review (PDR)

-   Critical Design Review (CDR)

-   Test Readiness Review (TRR)

-   Acceptance Review (AR)

-   Operational Readiness Review (ORR)

-   Mission Operations Review (MOR)

-   Flight Operations Review (FOR)

-   Peer Reviews (EPR) \[Be specific. \-- for example, code
    walkthroughs, design reviews, etc.\]

See the SQ Activity Schedule for the planned reviews to be supported.

\[List only those reviews you plan to attend and assess. Add/delete
reviews and modify review titles, as appropriate.\]

# Test

SQ personnel will assure that the test management processes and products
are being implemented per the Software Management Plan and /or Test
Plan(s). This includes all types of testing of software system
components as described in the test plan, specifically during
integration testing (verification) and acceptance testing (validation).

SQ personnel will monitor testing efforts to assure that test schedules
are adhered to and maintained to reflect an accurate progression of the
testing activities. SQ will assure that tests are conducted using
approved test procedures and appropriate test tools, and that test
anomalies are identified, documented, addressed, and tracked to closure.
In addition, SQ will assure that assumptions, constraints, and test
results are accurately recorded to substantiate the requirements
verification/validation status.

SQ personnel will review post-test execution related artifacts including
test reports, test results, problem reports, updated requirements
verification matrices, etc... \[Add any additional SQ test activities
(e.g., test witnessing)\]

# Problem Reporting and Corrective Action

SQ personnel generate, track, and trend assessment
findings/nonconformances and observations in the centralized Software
Quality Engineering Repository Database (SQERD), available via
<http://sqerd/gsfc.nasa.gov>/. Reference the SQ Assessment Process WI
for details on tracking and trending of assessment findings and
observations and the reporting escalation process.

\[Specify how you communicate your assessment results and corrective
action status to the SAM and the project. This is ***critical*** for
PPQA.\]

# Tools, Techniques and Methodologies

SQ personnel will require access to the following: \[Add/delete tools,
as appropriate\]

## NASA GSFC Tools

-   Automated Requirements Measurement (ARM) Tool

-   NASA Lessons Learned Information System (LLIS)

-   Goddard Directives Management System (GDMS)

## Software Quality Tools

-   Microsoft Office tools (i.e., Word, Excel, and PowerPoint)

-   Access to the GSFC Software Assurance web site
    [[http://sw-assurance.gsfc.nasa.gov]{.underline}](http://sw-assurance.gsfc.nasa.gov/)

-   Access to the Software Quality Engineer Reporting Database (SQERD)

-   Access to the OSSMA internal server for SQA records

## Project Tools

-   \<Project Name\> Server

-   \<Project Name\> Risk Management System

-   Supplier Web sites and/or Software Development Life cycle
    Asset/Artifact(s) Repositories (as applicable)

-   Supplier Software Problem Reporting Systems (remote access
    preferred)

-   On-orbit Anomaly Reporting Systems for similar/heritage
    systems/missions

# Media Control 

SQ deliverables will be documented in one of the following Microsoft
software applications: Word, Excel, or PowerPoint. Deliverables will be
in soft copy, unless specified otherwise. See Section 12 for additional
details on the collection and retention of key records.

Software Quality deliverables, work products, and data items shall be
maintained in accordance with the OSSMA Software Quality Assurance Data
Management Plan. This plan provides information on the data item, data
category, owner, location, collection frequency, and data retention
period.[]{#__RefHeading___Toc68068014 .anchor}

# Supplier Control

SQ personnel will conduct off-site surveillance activities at supplier
sites \<enter suppliers\> on software development activities. \[Specify
the various suppliers and how SQ will monitor their software processes
and products. Specify whether you intend to utilize insight, oversight,
or a combination of both. Use the definitions for "insight" and
"oversight", if needed.\]

SQ personnel will conduct a baseline assessment of the supplier(s)
Quality Management Systems (QMS) to ensure that the supplier(s) have
quality processes in place. This initial assessment will help to scope
the level of effort and follow-on activities in the area of software
quality assurance. \[Note: this baseline assessment is recommended, but
not a requirement.\]

Process and product assessments \<identify key assessments\> will be
conducted and any findings will be reported and tracked to resolution.

**Insight**: Surveillance mode requiring the monitoring of
acquirer-identified metrics and contracted milestones. Insight is a
continuum that can range from low intensity, such as reviewing quarterly
reports, to high intensity, such as performing surveys and reviews.

**Oversight:** Surveillance mode that is in line with the supplier\'s
processes. The acquirer retains and exercises the right to concur or
nonconcur with the supplier\'s decisions.  Nonconcurrence must be
resolved before the supplier can proceed.  Oversight is a continuum that
can range from low intensity, such as acquirer concurrence in reviews
(e.g., PDR, CDR), to high intensity oversight, in which the customer has
day-to-day involvement in the supplier\'s decision-making process (e.g.,
software inspections).

\[For previously developed software, this section shall state the
methods to be used to ensure the suitability of the product for use with
the software items covered by the SQAP.

For software that is to be developed, the supplier shall be required to
prepare and implement an SQAP in accordance with this standard. Discuss
the receipt and review of that plan and how SQ will use the deliverable.

Also state the methods to be employed to assure that the suppliers
comply with the requirements of this standard. If software is to be
developed under contract, then the procedures for contract review and
update shall be described.\][]{#__RefHeading___Toc68068015 .anchor}

# Record Collection, Maintenance, and Retention

SQ personnel will maintain records that document assessments performed
on the project. Maintaining these records will provide objective
evidence and traceability of assessments performed throughout the
project's life cycle. Example records include the process and product
assessments reports, completed checklists, the SQ Activity Schedule,
metrics, weekly status reports, etc. For more details on SQ records,
their location, and data retention, reference the OSSMA Software Quality
Assurance Data Management Plan.

# Training

SQ personnel shall have fundamental knowledge in the following
areas/disciplines through prior experience, training, or certification
in methodologies, processes, and standards:

-   Software Quality Assurance:

-   Audits and Reviews

-   Risk Management

-   Configuration Management

-   Software Safety

-   Contracts/Contractor Surveillance

-   CMMI

-   ISO 9001

-   Project-specific Training

-   ISD Software Engineering Discussions

It is the responsibility of the SQ personnel to acquire the necessary
skills or knowledge in each of the above disciplines. An SQ Training log
has been prepared that specifies the type of training and/or on-the-job
experience that has been completed, along with the source of the
training, and the date of completion.

#  Risk Management

SQ personnel will assess the project's risk management process against
the \<Project Name\> Risk Management Plan and GPG 7120.4. SQ
participates in \<weekly/monthly\> risk management meetings and reports
any software risks to the SAM and the project's Risk Manager.

\[Provide any additional detail regarding review of risks and the SQ
relationship with the risk review team. Provide link to project's risk
management system, if applicable.\]

# Glossary

Reference 303-PG-7120.2.1, Procedure for Developing and Implementing
Software Quality Programs or the GSFC Software Assurance web site,
[http://sw-assurance.gsfc.nasa.gov](http://sw-assurance.gsfc.nasa.gov/)
for the Glossary and software quality acronyms.

# SQA Plan Change Procedure and History

SQ personnel are responsible for the maintenance of this plan. It is
expected that this plan will be updated throughout the life cycle to
reflect any changes in support levels and SQ activities. Proposed
changes shall be submitted to the \<Project Name\> Systems Assurance
Manager (SAM), along with supportive material justifying the proposed
change. Changes to this document require prior approval of the \<Project
Name\> Project CCB Chairperson.

**Appendix A -- Abbreviations & Acronyms**

  -------------------------------------------------------------------------
  **Abbreviation/   **DEFINITION**
  Acronym**         
  ----------------- -------------------------------------------------------
  AMO               Assurance Management Office

  AR                Acceptance Review

  ARM               Automated Requirements Management

  CCB               Configuration Control Board

  CDR               Critical Design Review

  CDRL              Contract Deliverable Requirements List

  CMMI              Capability Maturity Model Integration

  CMP               Configuration Management Plan

  DCMA              Defense Contract Management Agency

  EPR               Engineering Peer Review

  FCA               Functional Configuration Audit

  FOR               Flight Operations Review

  FTE               Full Time Equivalent

  GDMS              Goddard Directives Management Systems

  GDS               Ground Data System

  GOV               Government

  GPG               Goddard Procedures and Guidelines

  GSFC              Goddard Space Flight Center

  IEEE              Institute of Electrical and Electronic Engineers

  IV&V              Independent Verification and Validation

  LLIS              Lessons Learned Information System

  MAG               Mission Assurance Guidelines

  MASC              Mission Assurance Services Contract

  MOA               Memorandum of Agreement

  MOR               Mission Operations Review

  NASA              National Aeronautics and Space Administration

  NPD               NASA Policy Directive

  NPG               NASA Program Guideline, NASA Policies and Guidelines

  NRRS              NASA Record Retention Schedule

  ORR               Operational Readiness Review

  OSSMA             Office of Systems Safety and Mission Assurance

  PAE               Product Assurance Engineer

  PCA               Physical Configuration Audit

  PDR               Preliminary Design Review

  PG                Procedures and Guidelines

  PM                Project Manager

  PPQA              Process and Product Quality Assurance

  QAS               Quality Assurance Specialist

  QMS               Quality Management System

  REV               Revision

  SAC               Supplier Assurance Contract

  SAM               Systems Assurance Manager

  SCR               System Concept Review

  SEI               Software Engineering Institute

  SIP               System Implementation Plan

  SMP               Software Management Plan

  SOW               Statement Of Work

  SQ                Software Quality

  SQA               Software Quality Assurance

  SQAP              Software Quality Assurance Plan

  SSR               Software Specifications Review

  STD               Standard

  SW                Software

  TRR               Test Readiness Review

  VDD               Version Description Document

  VER               Version

  Vs.               Verses

  WI                Work Instruction

  WV                West Virginia
  -------------------------------------------------------------------------