Académique Documents
Professionnel Documents
Culture Documents
TM-PPQA-03 v1.0
7/11/06
BLANK
TEMPLATE
TM-PPQA-03 V1.0
JULY 11, 2006
PREFACE
This document is a template of a Quality Assurance (QA) Plan using the guidelines provided in the Quality
systems – Model for quality assurance in design, development, production, installation and servicing,
International Organization for Standardization ISO 9001. This template is designed for small scale
projects or projects that do not follow tradition systems/software/technical service activities. Large scale
projects or projects that do apply systems/software/technical service activities may also wish to review the
QA Plan Template, TM-PPQA-01 that exemplifies an expanded implementation of QA.
This template should be supplemented with project-specific information to produce a QA Plan that
accurately describes the project’s QA organization, tasks, roles, and responsibilities. The planning and
documenting of QA activities must agree and be consistent with the project’s Project Management Plan
(PMP) or other project-planning document. Additionally, the QA Plan must comply with Space and Naval
Warfare (SPAWAR) Systems Center (SSC) San Diego Systems/Software Engineering Management (SEM)
Policy, which provides management with appropriate visibility into the process being used by the project
and of the products being built.
This document supplements the QA Process, PR-PPQA-01. Refer to Section 2.4.3, of the QA Process for
a description on the use of this template.
Tailoring of this template is required to ensure that the scope of the project, the standards governing the
project’s operation, and the goals and objectives specific to the project, are represented.
The SSC San Diego Systems Engineering Process Office (SEPO) assumes responsibility for this document
and updates it as required to meet the needs of users within SSC San Diego CA. SEPO welcomes and
solicits feedback from users of this document so that future versions will reflect improvements, based on
organizational experience and lessons learned.
Users of this document may report deficiencies or corrections using the Document Change Request (DCR)
found on the next page or online through the SSC San Diego Process Asset Library (PAL) at
http://sepo.spawar.navy.mil/. Updates are performed in accordance with the SEPO Configuration
Management Procedure.
Introduction - ii
Blank QA Plan Template
TM-PPQA-03 v1.0
7/11/06
Mailing Address:
Change Location:
(use section #, figure #, table #, etc.)
Proposed change:
Note: For the Systems Engineering Process Office (SEPO) to take appropriate action on a change request,
please provide a clear description of the recommended change along with supporting rationale.
Send to: Commanding Officer, Space and Naval Warfare Systems Center, Code 20203, 53560 Hull Street, San
Diego, CA 92152-5001
Fax to: (619) 553-6249
Email to: sepo@spawar.navy.mil
Submit online: http://sepo.spawar.navy.mil/ DCR Form 3/2006
Introduction - iii
Blank QA Plan Template
TM-PPQA-03 v1.0
7/11/06
RECORD OF CHANGES
*A - ADDED M - MODIFIED D - DELETED
NUMBER OF A* CHANGE
VERSION
DATE FIGURE, TABLE OR M TITLE OR BRIEF DESCRIPTION REQUEST
NUMBER PARAGRAPH D NUMBER
Introduction - iv
Blank QA Plan Template
TM-PPQA-03 v1.0
7/11/06
DOCUMENT CONVENTIONS
This document is a Quality Assurance (QA) Plan template. As such, wording in this document should be
supplemented with project-specific information to produce a QA Plan that accurately describes the project
QA organization and tasks. Therefore, appropriately tailor (add, delete, change, or expand) the information
provided in this document
Standard conventions are used within this document to direct the reader to specific sections of the text.
These sections provide instructions and explanations, and require users to substitute their own project-
specific information for the generic information provided or to "fill in a blank."
[[Text]] Global changes. Items that appear in regular text and are surrounded by double brackets
represent changes that can be made globally throughout the document. For example, if the
sentence reads, "The purpose of this document is to define QA responsibilities, resources,
and procedures to be used during the development and maintenance of the [[project title]]
system," the user can use a global command to change all occurrences of [[project title]] to a
new system-specific title.
Bold Italics Items that appear in bold italics font represent variables that require changes on an
individual basis. For example, if the sentence reads, "Document Title of plan/manual
number 1," the user enters a specific document title.
Items that appear in a box titled “Guidance” represent instructions to the user and are not to
Italics appear in the completed version of the document. For example, if the statement reads,
Guidance
If the list of organizations is long, it may be appropriate to create numbered paragraph
headings for each organization
the writer may simply follow the directions. The user is not required to create separate,
numbered paragraphs, but the option is suggested.
Watermark. To further assist in drafting the required information, some sections contain a sample of a
hypothetical project. A watermark has been placed diagonally across the page to indicate
that the text is an example of the type of information that should appear in each section.
The samples have been constructed such that if extracted from the template with their
associated paragraph number they would create a good first draft of a QA Plan.
In cases where information may be found in another project document, like the Project Management Plan
(PMP), refer to that document rather than duplicate the information in the project QA Plan.
The template begins with the Project QA Plan cover sheet on the next page. Delete all pages prior to the
Project QA Plan cover sheet in the final format of the project QA Plan. Update the header to reflect the
document configuration identifier for the project QA Plan.
Introduction - v
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
Guidance
The Cover Page for the project QA Plan may be tailored in accordance with the project’s defined
documentation standard.
[[PROJECT TITLE]]
[[DOCUMENT DATE]]
Guidance
Tailor this distribution notice in accordance with project requirements. If possible, refrain from using
terminology in this plan that would require security classification.
Guidance
The Cover Page for the project QA Plan may be tailored in accordance with the project’s defined
documentation standard
[[PROJECT TITLE]]
[[DOCUMENT DATE]]
QA Plan Approvals:
______________________ ____________
QA Manager Date
______________________ ____________
Project Manager Date
______________________ ____________
Program Manager Date
ii
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
PREFACE
This document contains the Quality Assurance (QA) Plan for the [[Project Title]]. The QA activities
described in this plan are consistent with the [[Project Title]] Project Management Plan and other project
planning documents. This document has been tailored from the QA Plan Template, TM-PPQA-01.
The [[Code/Project/Office]] assumes responsibility for this document and updates it, as required, to meet
the needs of [[Project Title]]. Users of this document may report deficiencies or corrections using the
Document Change Request found at the end of the document. Updates to this document will be performed,
at least annually, in accordance with the [[Project Title]] Configuration Management Process.
iii
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
RECORD OF CHANGES
*A - ADDED M - MODIFIED D - DELETED
NUMBER OF A* CHANGE
VERSION
DATE FIGURE, TABLE OR M TITLE OR BRIEF DESCRIPTION REQUEST
NUMBER PARAGRAPH D NUMBER
iv
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
TABLE OF CONTENTS
Section Page
LIST OF FIGURES
v
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
Figure Page
LIST OF TABLES
Table Page
vi
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
SECTION 1. INTRODUCTION
1.1 PURPOSE
The purpose of this plan is to define the [[Project Title]] Quality Assurance (QA) organization, tasks and
responsibilities; provide reference documents and guidelines to perform the QA activities; provide the
standards, practices and conventions used in carrying out QA activities; and provide the tools, techniques,
and methodologies to support QA activities, and reporting.
1.2 SCOPE
This plan establishes the QA activities performed throughout the life cycle of the [[Project Title]].
This plan is written to follow the Space and Naval Warfare (SPAWAR) Systems Center (SSC) San Diego
Systems/Software Engineering Management (SEM) Policy, reference (a), for [[Project Title]]. Specifically,
this QA Plan will show that the QA function is in place for this project. It will show that the QA group has
a reporting channel to senior management that is independent of the project manager, the project’s systems
and software engineering groups, and related groups that include Configuration Management (CM),
Systems and Software Test, Logistics, and Technical Services.
The goal of the QA program is to verify that all products and documentation to be delivered meet all
technical requirements. The QA procedures defined herein shall be used to examine all deliverable products
and documentation to determine compliance with technical and performance requirements.
Guidance
List the life cycle processes for the system or software or technical service(s) being performed, which
are being audited by QA.
The following project-level life cycle processes are applicable to this project and considered subject to QA:
List the appropriate life cycle processes (and cite the relevant standard of guideline from which they
are derived).
1.3 IDENTIFICATION
Guidance
Reference the list of project items (e.g., Configuration Items (CIs), project processes, products, tools,
facilities, etc.) from the appropriate document (Project Management Plan, CM Plan, etc.) to which this
QA Plan will apply or provide a list in this section.
The [[Project Title]] Configuration Management Plan, reference (b), lists the Configuration Items
(CI) that are subject to this QA Plan.
The [[System Name]] complete the sentence by providing a description of the system or technical
service and the intended use of the system or technical service. The system includes [[enter the number
of subsystems, e.g., 4]] subsystem(s) within the system.
1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
2
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
SECTION 2. MANAGEMENT
This section describes each major element of the organization that influences the quality of the product and
processes.
2.1 ORGANIZATION
Good project management practice requires a measure of independence for the QA group. This
independence provides a key strength to QA; that is, QA has the freedom, if the quality of the product is
being jeopardized, to report this possibility directly above the level of the project. While in practice this
rarely occurs, for almost all problems are correctly addressed at the project level, the fact that the QA
group can go above the project level gives it the ability to keep many of these problems at the project level.
Figure 2-1 shows the QA organization with relation to the project organization.
L in e M a n a g e m e n t
IV & V SEPO
P r o je c t
M anagem ent
C M Q A
S y s te m s P ro d u c t P ro d u c t S y s te m L o g is t ic s
E n g in e e r in g D e s ig n / D e v lp t Test Test
4
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
2.2 RESOURCES
2.2.1 Facilities and Equipment
QA will have access to the facilities and equipment as described in reference (d). QA will have access to
computer resources to perform QA functions such as process and product evaluations and audits.
2.2.2 Personnel
Guidance
Identify the qualification requirements of the QA
Manager. The “product” or products for which
related technical discipline familiarity is required
should be explicitly stated, e.g.
hardware/software/systems engineering, technical
documentation standards, etc. The project should
exercise flexibility in its approach to designating
personnel to perform QA. For example, where
appropriate, one or two full time people may be
designated for a moderate to large-scale project, or
several part-time people, or someone external to the
project organization may be assigned. Objective
verification may be performed by project personnel
under the supervision of the QA Manager ONLY when
they inspect processes or products OUTSIDE of their
project role and responsibilities.
2.2.3 QA Tools, Techniques and Methodologies
Guidance
Identify the special tools, techniques, and methodologies that support QA, state their purposes, and
describe their use.
Hardware Tools – QA hardware tools include, but are not limited to, simulators, monitors, stress or
environmental measurement equipment, etc.
Software Tools - QA software tools include, but are not limited to, operating system utilities, debugging
aids, documentation aids, checklists, structuring preprocessors, file comparators, structure analyzers,
code analyzers, standards auditors, simulators, execution analyzers, performance monitors, statistical
analysis packages, software development folder/files, software traceability matrices, test drivers, test
case generators, static or dynamic test tools, and information engineering Computer Aided Software
Engineering (CASE) tools.
Techniques - techniques include review of the use of standards, software inspections, requirements
tracing, requirements and design verification, reliability measurements and assessments, and rigorous
or formal logic analysis.
Methodologies - methodologies are an integrated set of the above tools and techniques. The
methodologies should be well documented for accomplishing the task or activity and provide a
description of the process to be used.
The QA Group will utilize the following tools to perform audit/inspection events:
5
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
Guidance
List the tools, techniques and methodologies used; use Section 4, QA Schedule, to specify when special
tools are required
6
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
SECTION 3. QA ACTIVITES
Guidance
Development of this section requires the cooperation of the project manager and QA manager to
identify the system, software or technical support life cycle processes, and the work products that are
applicable to the project. Whether the project is a full service development effort, or is focused on a
subset of engineering activities, or provides a specific technical support service (e.g. concept
development, proposal development, test and evaluation, logistic support, etc.) should dictate which
activities this QA Plan should address. This QA Plan should reflect verification of those activities, and
as well the products derived from the activities. Describe the portion of the project life cycle covered
by this QA Plan, the tasks to be performed with special emphasis on QA activities, and relationship
between these tasks and the planned major checkpoints. The sequence of the tasks should be indicated.
Tailor this section to reflect those tasks and project products being verified that relate to the project’s
current/projected activities. The QA Group should work with the PM to ensure that QA activities are
coordinated with those of the project being evaluated.
7
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
3.3 RESPONSIBILITES
Guidance
This paragraph should identify the specific organizational elements responsible for each task. It is
recommended that the Project Manager, together with the QA Manager, develop a matrix that provides
an overview of the responsibilities for conducting each of the aforementioned QA tasks. It is
recommended that the project’s higher-level sponsor QA personnel, if available, participate in project
QA activities.
8
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
SECTION 4. QA SCHEDULE
Guidance
Ensure that the QA schedule is coordinated with the project schedule. Schedule the performance of QA
audits and inspections in accordance with project schedule and milestones. Ensure the appropriate
checklists are developed and provided to coincide with the scheduled QA audit events. Establish a
process for conducting the schedule, e.g., announce the upcoming QA event(s), request stakeholder
artifact availability for audit/inspection, prepare audit findings/recommendation, resolve outstanding
issues, etc. Ensure that provisions are included for resolving issues that cannot be resolved within the
project as described in Section 6.
The QA schedule should also specify the tools, techniques, and methodologies described in Section
2.2.3 that are required to prepare for and conduct each QA event.
9
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
5.2 METRICS
Guidance
Identify or reference the standards, practices, and conventions to be used in the definition, collection
and utilization of measurement data. Cite any internal (e.g., project, corporate) and external (e.g.,
user, customer) requirements or standards with which metrics practices must comply. IEEE Std 1045-
1992, IEEE Standard for Software Productivity Metrics, reference (m) describes conventions for
counting the results of the development processes. IEEE Std 1061-1992, IEEE Standard for a Software
Quality Metrics Methodology, reference (n), provides a methodology for selecting and implementing
process and product metrics. IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to
Produce Reliable Software, reference (o) and IEEE Std 982.2-1988, IEEE Guide for using reference
(o), reference (p) provide various measures for use in different life cycle phases to gain confidence in
the building of reliable software. To keep metrics simple, an example of cost and schedule metrics is
offered.
10
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
11
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
12
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
SECTION 7. QA TRAINING
Guidance
Identify the training activities necessary to meet the needs of the QA Plan. Tailor the contents of Table
7-1 below to reflect the project’s requirements.
Table 7-1 provides a matrix that identifies the required skills to perform QA tasks to implement this
[[Project Title]] QA Plan. The training schedule will be compatible with the project schedule. In some
cases, training will be conducted as On-the-Job Training (OJT).
TABLE 7-1. QA TRAINING MATRIX
TASK SKILL REQUIREMENTS TYPE SOURCE
Code Reviews Source Language, Peer Classroom/ SEPO, Peer Review
Reviews OJT Process and Workshop
Hardware Reviews Hardware orientation training, Classroom/ Hardware Vendor or
technical knowledge OJT organization hardware
expert
Documentation System Development and Classroom/ SEPO, Peer Review
Reviews Documentation standards and OJT Process and Workshop
guidelines, Peer Reviews
Process Audits System Development Life Classroom/ ISO/IEC-15288, IEEE/EIA
Cycle Processes, Audit OJT 12207
techniques
Testing Testing Methodologies OJT
QA Management Project Management Classroom/ SEPO, Project Management
OJT Core Course (PMCC)
Metrics Data Collection and Analysis Classroom/ SEPO, PMCC
OJT
Problem reporting and Configuration Management Classroom/ SEPO, CM Practitioner's
correction action OJT Training
Tools Vendor supplied training Classroom/ Vendor
OJT
Code, Media, and Configuration Management Classroom/ SEPO, CM Practitioner's
Supplier Control OJT Training
Risk Management and Classroom/ SEPO, PMCC, Risk
Analysis OJT Management Process
Project Management Classroom/ SEPO, Introduction to Best
OJT Practices, PMCC, PMG
13
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
14
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
Guidance
This section describes the requirements for collecting, assessing, reporting, and acting upon measures
of activities and work products derived from planning and performing the QA process to support the
future use and improvement of the project and the organization’s defined QA process and process
assets.
15
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]
A-1
DOCUMENT CHANGE REQUEST (DCR)
Document Title: [[Project Title]] Quality Assurance Plan Tracking Number:
Mailing Address:
Change Location:
(use section #, figure #, table #, etc.)
Proposed change:
Note: For the [[Project Title]] to take appropriate action on a change request, please provide a clear
description of the recommended change along with supporting rationale.
Send to: Commanding Officer, Space and Naval Warfare Systems Center, Code 2XX, 53560 Hull Street,
San Diego, CA 92152-5001
Fax: add appropriate fax number
Email: add appropriate email
Submit online: add appropriate URL
DCR Form 7/2003