[SQA Plan Template Rev 2.

0]

<Project Name>

Software Quality Assurance (SQA) Plan

<Document Control Number>

Date: <Month Year>

CHECK THE <XXXXX> AT< WEBSITE Address>

TO VERIFY THAT THIS IS THE CORRECT VERSION PRIOR TO USE.

[SQA Plan Template Rev1.0] <Document Control Number>

General Tailoring Guidelines

This document is a template for a Software Quality Assurance Plan intended for use by <Project
name> 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.

Text in Black

• 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 < >

• 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 [ ]

• 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

• Text in this style, blue, 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 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 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 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.

Revision <#> ii <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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>
Address Line 1
Address line 2
Pin
Phone

Revision <#> iii <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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>

Revision <#> iv <Month Year>

 [SQA Plan Template Rev 2.0] <Document Control Number>

<Project Name> Project Document Title

DOCUMENT CHANGE RECORD Sheet: 1 of 1

REV/ APPROVED DATE
VER DESCRIPTION OF CHANGE BY APPRO
LEVEL VED
<REV <Initial Publication> <Approver <Month
- #> Name> Day,
Year>

Revision <#> v <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

Table of Contents

1.0 Purpose.................................................................................................................................1

1.1 Scope.................................................................................................................................1

2.0 Reference Documents...........................................................................................................2

3.0 Management..........................................................................................................................3

3.1 Management Organization.................................................................................................3

3.1.1 <Project Name> Project Office........................................................................................3

3.1.2 Assurance Management Office.......................................................................................3

3.2 Tasks..................................................................................................................................4

3.2.1 Product Assessments.....................................................................................................4

3.2.2 Process Assessments.....................................................................................................4

3.3 Roles and Responsibility....................................................................................................5

3.3.1 SAM................................................................................................................................5

3.3.2 Software Quality Personnel.............................................................................................5

3.3.3 Other OSSMA Personnel................................................................................................6

3.4 Software Assurance Estimated Resources.........................................................................7

4.0 Documentation.......................................................................................................................8

4.1 Purpose..............................................................................................................................8

4.2 Minimum Documentation Requirement..............................................................................8

5.0 Standards, Practices, Conventions, and Metrics....................................................................9

5.1 Purpose..............................................................................................................................9

5.2 Software Quality Program..................................................................................................9

5.2.1 Standard Metrics.............................................................................................................9

6.0 Software Reviews................................................................................................................11

6.1 Purpose............................................................................................................................11

6.2 Minimum Software Reviews.............................................................................................11

7.0 Test 12

Revision <#> vi <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

8.0 Problem Reporting and Corrective Action............................................................................12

9.0 Tools, Techniques and Methodologies................................................................................12

9.1 Software Quality Tools.....................................................................................................12

9.2 Project Tools....................................................................................................................13

10.0 Media Control ..................................................................................................................13

11.0 Supplier Control.................................................................................................................13

12.0 Record Collection, Maintenance, and Retention................................................................14

13.0 Training..............................................................................................................................14

14.0 Risk Management............................................................................................................14

15.0 Glossary............................................................................................................................15

16.0 SQA Plan Change Procedure and History.........................................................................15

List Of Tables
Table

Table 3-2 Software Assurance Resources.................................................................................7

Revision <#> vii <Month Year>

[SQA Plan Template Rev1.0] <Document Control Number>

1.0Purpose
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 <Project Name> policies, standards, and procedures, as well as applicable Institute
of Electrical and Electronic Engineers (IEEE) standards.

1.1 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.]

Revision <#> 1 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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

• Software Safety Standard

• Software Assurance Standard
• Software Engineering Requirements
• Quality Assurance Letter of Delegation
• Risk Management
• Integrated Independent Reviews
• Engineering Peer Reviews
• Systems Assurance Manager Reporting
• Assurance Management
• Procedure for Developing and Implementing Software Quality Programs
• Software Quality Assessment Process
• 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.]

Revision <#> 2 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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

3.1 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.]

3.1.1 <Project Name> Project Office

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

3.1.2 Assurance Management Office

The Assurance Management Office (AMO), provides mission assurance support to projects).
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).

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.

[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.]

Revision <#> 3 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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

3.2.1 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)

3.2.2 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.]

Revision <#> 4 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

3.3 Roles and Responsibility

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

3.3.1 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
• 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

3.3.2 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

Revision <#> 5 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

3.3.3 Other OSSMA Personnel

The following are the primary responsibilities for Safety and Reliability personnel in support of
software assurance.

3.3.3.1 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

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

Revision <#> 6 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

3.4 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. [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.]

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.

Revision <#> 7 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

4.0Documentation

4.1 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).]

4.2 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

Revision <#> 8 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

5.0Standards, Practices, Conventions, and Metrics

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

5.2 Software Quality Program

Software Quality Programs at <Organization Name> are governed by the <Organization Name>
Software Assurance Policies, the <Organization Name> Software Assurance Standard, and the
<Organization Name> Software Safety Standard. Together, these <Organization Name> levbel
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 <Organization Name> 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 <Organization Name>’s Software Process Improvement
Program.

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

5.2.1 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

• 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))

Revision <#> 9 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

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

Revision <#> 10 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

6.0Software Reviews

6.1 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.]

6.2 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.]

Revision <#> 11 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

7.0Test
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)]

8.0Problem 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 <web site address>. 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.]

9.0Tools, Techniques and Methodologies

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

9.1 Software Quality Tools

• Microsoft Office tools (i.e., Word, Excel, and PowerPoint)
• Access to the Software Quality Engineer Reporting Database (SQERD)
• Access to the OSSMA internal server for SQA records

Revision <#> 12 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

9.2 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

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

11.0 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).

Revision <#> 13 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

[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.]

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

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

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

Revision <#> 14 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

[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.]

15.0 Glossary
Reference Software Assurance web site, <Web site name> glossary and software quality
acronyms.

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

Revision <#> 15 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

Appendix A – Abbreviations & Acronyms

Abbreviation/
Acronym
DEFINITION

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

Revision <#> 16 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

Abbreviation/
Acronym
DEFINITION

MOR Mission Operations Review

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

Revision <#> 17 <Month Year>

[SQA Plan Template Rev 2.0] <Document Control Number>

Abbreviation/
Acronym
DEFINITION

SW Software

TRR Test Readiness Review

VDD Version Description Document

VER Version

Vs. Verses

WI Work Instruction

WV West Virginia

Revision <#> 18 <Month Year>