QA Plan Template - DOC

Document Sample
QA Plan Template - DOC Powered By Docstoc
					                                                              QA Plan Template
                                                             TM -PPQA-01 v1.0
                                                                       7/11/06




        QUALITY ASSURANCE PLAN

                     TEMPLATE

(FOR A SYSTEMS/SOFTWARE ENGINEERING

                       PROJECT)




                 TM-PPQA-01 V1.0
                    JULY 11, 2006




     Systems Engineering Process Office, Code 20203
   Space and Naval Warfare Systems Center San Diego
                     53560 Hull Street
                San Diego, CA 92152-5001



    Approved for public release; distribution is unlimited
QA Plan Template
TM -PPQA-01 v1.0
7/11/06



                                                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 specifically tailored for a
medium to large size project that conducts systems and/or software engineering and/or technical services.
A separate Blank QA Plan Template, TM-PPQA-03, provides a template for small scale projects or
projects that do not focus on traditional systems/software or technical service activities. 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.
This template is prepared to represent a nominal systems / software engineering project, and therefore
reflects QA of processes consistent with the Systems Engineering – System Life Cycle Processes,
International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) -
15288. Tailoring of this template is required to ensure that the scope of QA for 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
                                                                                               QA Plan Template
                                                                                              TM -PPQA-01 v1.0
                                                                                                        7/11/06



                            DOCUMENT CHANGE REQUEST (DCR)
Document Title: Quality Assurance Plan Template                                Tracking Number:


Name of Submitting Organization:


Organization Contact:                                                          Phone:


Mailing Address:


DCR Description:                                                               Date:


Change Location:
(use section #, figure #, table #, etc.)
Proposed change:




Rationale for 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
QA Plan Template
TM -PPQA-01 v1.0
7/11/06



                                   RECORD OF CHANGES
                                                               *A - ADDED M - MODIFIED D - DELETED
                      NUMBER OF FIGURE, A*                                                     CHANGE
VERSION
            DATE      TABLE OR          M          TITLE OR BRIEF DESCRIPTION                  REQUEST
NUMBER
                      PARAGRAPH         D                                                      NUMBER
1.0         7/11/06   Entire Document       A      Although a new document, this template is   PPQA-0003
                                                   derived from the SQA Plan Template, TM-
                                                   SQA-01 and provides a generic document
                                                   for systems, hardware and software
                                                   engineering projects
1.0         7/11/06   Section 3             A      Describe how sponsor QA personnel           PPQA-0002
                                                   interact with project QA personnel




                                        Introduction - iv
                                                                                             QA Plan Template
                                                                                            TM -PPQA-01 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, the 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 cover sheet on the page after the next. Delete all pages prior to
the Project QA 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
QA Plan Template
TM -PPQA-01 v1.0
7/11/06




                   This page intentionally left blank.




                          Introduction - vi
                                                                                   [[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]]

                           QUALITY ASSURANCE PLAN



             [[DOCUMENT CONFIGURATION IDENTIFIER]]

                                 [[DOCUMENT DATE]]




                               [[Add your organization name here]]
                      Space and Naval Warfare Systems Center San Diego
                                      53560 Hull Street
                                    San Diego, CA 92152-5001


Guidance
Tailor this distribution notice in accordance with project requirements. If possible, refrain fro m
using terminology in this plan that would require security classification.
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


                            Approved for public release; distribution is unlimited




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

                         QUALITY ASSURANCE PLAN



            [[DOCUMENT CONFIGURATION IDENTIFIER]]

                                [[DOCUMENT DATE]]




QA Plan Approvals:


______________________                      ____________
QA Manager                                  Date


______________________                      ____________
Project Manager                             Date


______________________                      ____________
Program Manager                             Date


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




                                                  iv
                                                                         [[Project Title]] QA Plan
                                                              [[Document Configuration Identifier]]
                                                                               [[Document Date]]



                           RECORD OF CHANGES
                                                      *A - ADDED M - MODIFIED D - DELETED
                 NUMBER OF FIGURE, A*                                                CHANGE
VERSION
          DATE   TABLE OR          M        TITLE OR BRIEF DESCRIPTION               REQUEST
NUMBER
                 PARAGRAPH         D                                                 NUMBER




                                        v
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



                                                     TABLE OF CONTENTS
Section                                                                                                                                      Page

SECTION 1. INTRODUCTION..................................................................................................... 1-1
   1.1       Purpose............................................................................................................................ 1-1
   1.2       Scope............................................................................................................................... 1-1
   1.3       Identification..................................................................................................................... 1-1
   1.4       System Overview ............................................................................................................. 1-1
   1.5       Document Overview ......................................................................................................... 1-1
   1.6       Relationship to Other Plans................................................................................................ 1-2
   1.7       Reference Documents ...................................................................................................... 1-2
SECTION 2. MANAGEMENT ...................................................................................................... 2-1
   2.1     Organization ..................................................................................................................... 2-1
   2.2     Resources ........................................................................................................................ 2-4
      2.2.1    Facilities and Equipment ............................................................................................. 2-4
      2.2.2    Personnel .................................................................................................................. 2-4
      2.2.3    QA Tools, Techniques and Methodologies ................................................................... 2-5
   2.3     Risk Management ............................................................................................................. 2-5
SECTION 3. QA TASKS ............................................................................................................... 3-1
   3.1     Process Quality Assurance................................................................................................ 3-1
      3.1.1    Task: Evaluate Acquisition Process ............................................................................. 3-1
      3.1.2    Task: Evaluate Supply Process ................................................................................... 3-1
      3.1.3    Task: Evaluate Project Planning Process ..................................................................... 3-2
      3.1.4    Task: Evaluate Project Assessment Process ................................................................ 3-2
      3.1.5    Task: Evaluate Project Reviews.................................................................................. 3-2
      3.1.6    Task: Evaluate Project Control Process ....................................................................... 3-2
      3.1.7    Task: Evaluate Decision-Making Process .................................................................... 3-2
      3.1.8    Task: Evaluate Risk Management Process .................................................................. 3-2
      3.1.9    Task: Evaluate Configuration Management Process ..................................................... 3-3
      3.1.10 Task: Conduct Configuration Audits ............................................................................ 3-3
      3.1.11 Task: Evaluate Product Development Library Control Process...................................... 3-3
      3.1.12 Task: Evaluate Media Certification and Control Process ............................................... 3-4
      3.1.13 Task: Evaluate Information Management Process ........................................................ 3-4
      3.1.14 Task: Evaluate Quality Assurance Process .................................................................. 3-4
      3.1.15 Task: Evaluate Requirements Definition and Analysis Process ...................................... 3-5
      3.1.16 Task: Evaluate Architectural Design Process............................................................... 3-5
      3.1.17 Task: Evaluate Implementation Process....................................................................... 3-6
      3.1.18 Task: Evaluate Product Integration and Verification Process ........................................ 3-6
      3.1.19 Task: Evaluate Transition Process............................................................................... 3-6
      3.1.20 Task: Evaluate Validation Process .............................................................................. 3-7
      3.1.21 Task: Evaluate Maintenance Process .......................................................................... 3-7
      3.1.22 Task: Evaluate Operation Process............................................................................... 3-7
      3.1.23 Task: Evaluate Corrective Action Process ................................................................... 3-8


                                                                     vi
                                                                                                                    [[Project Title]] QA Plan
                                                                                                         [[Document Configuration Identifier]]
                                                                                                                          [[Document Date]]


      3.1.24 Task: Evaluate Disposal Process................................................................................. 3-8
      3.1.25 Task: Evaluate Subcontractor Control Process ............................................................. 3-8
   3.2     Product Quality Assurance ................................................................................................ 3-8
      3.2.1    Deliverable Document/Product Verification ................................................................. 3-8
      3.2.2    Tool Evaluation .......................................................................................................... 3-9
      3.2.3    Facilities Evaluation.................................................................................................. 3-10
   3.3     Responsibilites ................................................................................................................ 3-13
SECTION 4. QA SCHEDULE ....................................................................................................... 4-1

SECTION 5. STANDARDS, PRACTICES, CONVENTIONS AND METRICS .............................. 5-1
   5.1       Standards, Practices and Conventions ................................................................................ 5-1
   5.2       Metrics ............................................................................................................................ 5-1
SECTION 6. QA PROBLEM REPORTING AND RESOLUTION ................................................. 6-1
   6.1     QA Audit Report .............................................................................................................. 6-1
      6.1.1    Submittal and Disposition of QA audit report................................................................ 6-1
      6.1.2    Escalation Procedure for Resolution of Non-Concurrence on QA audit report................ 6-3
   6.2     Recording Problems in Hardware, Software Code or Documentation ................................... 6-3
SECTION 7. RECORDS COLLECTION, MAINTENANCE AND RETENTION ........................... 7-1

SECTION 8. TRAINING ............................................................................................................... 8-1

SECTION 9. REVIEW OF QA ACTIVITIES WITH HIGHER LEVEL MANAGEMENT............... 9-1

SECTION 10. COLLECTING IMPROVEMENT INFORMATION .............................................. 10-1

APPENDIX A. LIST OF ACRONYMS ........................................................................................ A-1

APPENDIX B. PROCESS/PRODUCT AUDIT TASK DESCRIPTIONS AND SUPPORTING
CHECKLISTS ............................................................................................................................... B-1



                                                         LIST OF FIGURES
Figure                                                                                                                                       Page
Figure 2-1.     [[Project Title]] Organization .......................................................................................... 2-1
Figure 3-1.     Tool Evaluation ............................................................................................................ 3-11
Figure 3-2.     Project Facilities Evaluation .......................................................................................... 3-12
Figure 6-1.     Quality Assurance Audit Report ..................................................................................... 6-3
Figure B-1.      Project Acquisition Process Audit Checklist ................................................................... B-3
Figure B-2.      Project Supply Process Audit Checklist ......................................................................... B-5
Figure B-3.      Project Planning Process Audit Checklist....................................................................... B-8
Figure B-4.      Project Assessment Process Audit Checklist ................................................................. B-9
Figure B-5.      Project Control Process Audit Checklist ...................................................................... B-14
Figure B-6.      Decision-Making Process Audit Checklist.................................................................... B-15



                                                                     vii
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


Figure B-7. Risk Management Process Audit Checklist .................................................................. B-16
Figure B-8. Configuration Management Process Audit Checklist..................................................... B-18
Figure B-9. Product Development Library Control Process Audit Checklist ..................................... B-24
Figure B-10. Media Certification Process Audit Checklist............................................................... B-27
Figure B-11. Information Management Process Audit Checklist...................................................... B-30
Figure B-12. System Requirements Definition and Analysis Process Audit Checklist ........................ B-32
Figure B-13. Software Requirements Definition and Analysis Process Audit Checklist ..................... B-35
Figure B-14. System Architectural Design Process Audit Checklist................................................. B-36
Figure B-15. Software Architectural Design Process Audit Checklist .............................................. B-37
Figure B-16. Hardware Implementation Process Audit Checklist .................................................... B-40
Figure B-17. Software Implementation Process Audit Checklist ...................................................... B-43
Figure B-18. Unit Integration and Testing Process Audit Checklist .................................................. B-45
Figure B-19. CI Integration Testing and System Qualification Process Audit Checklist ..................... B-47
Figure B-20. Transition Process Audit Checklist ............................................................................ B-53
Figure B-21. Validation Process Audit Checklist ............................................................................ B-56
Figure B-22. Maintenance Process Audit Checklist ........................................................................ B-57
Figure B-23. Operation Action Process Audit Checklist.................................................................. B-58
Figure B-24. Corrective Action Process Audit Checklist................................................................. B-61
Figure B-25. Disposal Process Audit Checklist .............................................................................. B-66
Figure B-26. Subcontractor Control Process Audit Checklist........................................................... B-68



                                                       LIST OF TABLES
Table                                                                                                                              Page
Table 3-1. Deliverable Products ....................................................................................................... 3-9
Table 3-2. Non-deliverable Documents............................................................................................. 3-9
Table 3-3. Responsibility Matrix ................................................................................................. 3-13
Table 8-1. QA Training Matrix ........................................................................................................ 8-1
Table B-1. Reviews and Audits .................................................................................................... B-11




                                                                viii
                                                 [[Project Title]] QA Plan
                                      [[Document Configuration Identifier]]
                                                       [[Document Date]]




This page intentionally left blank.




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

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.

1.4   SYSTEM OVERVIEW
Guidance
Insert an overview figure depicting the system receiving QA, if appropriate.

The [[System Name]] complete the sentence by providing a description of the system and the
intended use of the system. The system includes [[enter the number of subsystems, e.g., 4]]
subsystem(s) within the system.

1.5   DOCUMENT OVERVIEW
This document identifies the organizations and procedures to be used to perform activities related to the
[[Project Title]] QA program as specified in Quality Systems – Model for quality assurance in design,



                                                    1-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


development, production, installation and servicing, International Organization for Standardization (ISO)
9001, reference (c).
Section 1 identifies the system to which this QA Plan applies; provides an overview of the system and its
functions; summarizes the purpose and contents of the QA Plan; and describes the relationship of the QA
Plan to other management plans and lists all documents referenced in this QA Plan.
Section 2 describes each major element of the organization that influences the quality of the product.
Section 3 describes the various QA tasks
Section 4 describes the schedule of QA activities.
Section 5 identifies the standards, practices, conventions, and metrics.
Section 6 describes problem reporting and corrective action.
Section 7 describes QA procedures for record collection, maintenance, and retention.
Section 8 describes QA training requirements.
Section 9 describes QA review of QA activities with higher-level management.
Section 10 describes the collection of improvement information to optimize the performance of QA.
Appendix A provides a list of acronyms.
Appendix B provides checklists to be used or tailored for verifying compliance with general engineering,
management and technical service best practices.

1.6     RELATIONSHIP TO OTHER PLANS
QA evaluation of the project processes throughout the life cycle is based on the processes defined in the
[[Project Title]] Project Management Plan (PMP), reference (d). Reference (d) and its implementation
procedures establish the QA evaluation criteria.

1.7     REFERENCE DOCUMENTS
This section lists the documents referenced in this QA Plan.
Guidance
For the following, add or delete documents that are referenced in the QA Plan.
      a. Systems/Software Engineering Management Policy , SSC San Diego Instruction 5234.2, SSC San
         Diego.
      b. [[Project Title]] Configuration Management Plan, Document Configuration Identifier,
         Document Date.
      c. Quality Systems – Model for quality assurance in design, development, production, installation and
         servicing, ISO 9001, Jul 1994.
      d. [[Project Title]] Project Management Plan, Document Configuration Identifier, Document
         Date.
      e. Project Management Policy, SSC San Diego Instruction 5234.1A, Nov 2004.



                                                     1-2
                                                                                 [[Project Title]] QA Plan
                                                                      [[Document Configuration Identifier]]
                                                                                       [[Document Date]]


f.   Quality Assurance Process, PR-PPQA-01, SSC San Diego.
g. Quality Assurance Plan Template, TM-PPQA-01, SSC San Diego.
h. Space and Naval Warfare System Center San Diego Standard Process Definition (Draft), PR-
   OPD-35, SSC San Diego.
i.   Risk Management Process, PR-SPP-04, SSC San Diego.
j.   Systems Engineering – System Life Cycle Processes, International Organization for
     Standardization (ISO)/International Electrotechnical Commission (IEC) 15288, ISO/IEC
     15288:2002(E), Nov 2002.
k. Military Handbook, Configuration Management Guidance, MIL-HDBK-61A, Feb 2001.
l.   Peer Review Process, PR-PR-02, SSC San Diego.
m. Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Productivity
   Metrics, IEEE Std 1045-1992, Sep 1992.
n. IEEE Standard for a Software Quality Metrics Methodology, IEEE Std 1061-1992, Dec 1992.
o. IEEE Standard Dictionary of Measures to Produce Reliable Software, IEEE Std 982.1-1988, Jun
   1988.
p. IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software,
   Std 982.2-1988, Sep 1988.
q. Technical Reviews and Audits for Systems, Equipments, and Computer Software, MIL-STD-
   1521, Jun 1995.
r.   Software Development and Documentation, Data Item Descriptions (DIDs), Military Standard
     (MIL-STD)-498, Dec 1994. NOTE: Although ISO/IEC Std 15288 and IEEE 12207 have
     superceded MIL-STD-498, the DIDs for MIL-STD-498 are still considered applicable for the
     support of developing software engineering procedures and supporting documentation.




                                             1-3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     1-4
                                                                                         [[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 products
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.
                                              Senior Management


                                          IV&V               SEPO



                                                   Project
                                                 Management


                                           CM                 QA



               Systems          Product            Product          System            Logistics
              Engineering     Design/Devlpt         Test             Test

                                 Figure 2-1. [[Project Title]] Organization
Guidance
Replace Figure 2-1 with the project’s organizational structure or reference the organizational
chart’s location. The project may wish to keep a single chart in a central location and reference
all of its plans and procedures to that chart to facilitate maintaining the organization chart.
Provide a description of the functional responsibilities for each functional grou p in the
organizational structure.
In describing the functional responsibilities, answer the questions listed below:
      a. Who interacts with QA?
      b. Who has authority and delegates responsibilities of interacting functions?
      c. What are the reporting relationships among the interacting elements identifying
         independence /dependence?
      d. Who has product release authority?
      e. Who approves the QA Plan?


                                                   2-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


    f. What are the reporting lines for escalating conflicts and the method by which conflicts are
       resolved among the elements?
In each case, add or delete the functional responsibilities that apply.
QA is responsible for ensuring compliance with QA requirements as delineated in this QA Plan. The QA
organization assures the quality of deliverables and supporting documentation, non-deliverable items, and
the engineering processes used to produce them.
The following describes the functional groups that influence and control product and process quality.
    a. Senior Management is responsible for the items listed below:
         1. Establishing a quality program by committing the project to implement reference (a) and the
            Project Management Policy, reference (e).
         2. Resolving and following-up on any quality issues raised by QA.
         3. Identifying an individual or group independent from the project to audit and report on the
            project’s QA function.
         4. Fill-in additional functional responsibilities.
    b. Project Management is responsible for the items listed below:
         1. Implementing the quality program in accordance with references (a) and (e).
         2. Identifying the QA activities to be performed by QA.
         3. Reviewing and approving the [[Project Title]] QA Plan.
         4. Identifying and funding an individual or group independent from the project to perform the QA
            functions.
         5. Resolving and following-up on any quality issues raised by QA.
         6. Identifying the quality factors to be implemented in the system and software.
         7. Identifying, establishing and maintaining planning documents such as references (d).
         8. Fill-in additional functional responsibilities.
    Guidance
    Tailor these next subparagraphs to represent the actual scope of your project.
    c. System Engineering is responsible for the items listed below:
         1. Reviewing and commenting on the [[Project Title]] QA Plan.
         2. Implementing the quality program in accordance with this QA Plan.
         3. Resolving and following-up on any quality issues raised by QA related to system engineering
            activities.
         4. Identifying, implementing, and evaluating the quality factors to be implemented in the system
            (hardware and software).
         5. Implementing the engineering practices, processes, and procedures as defined in reference (d)
            and other program/project planning documents.


                                                   2-2
                                                                                   [[Project Title]] QA Plan
                                                                        [[Document Configuration Identifier]]
                                                                                         [[Document Date]]


     6. Fill-in additional functional responsibilities.
d. Product Design and Development is responsible for the items listed below:
     1. Reviewing and commenting on the [[Project Title]] QA Plan.
     2. Implementing the quality program in accordance with this QA Plan.
     3. Resolving and following-up on any quality issues raised by QA related to product design and
        development.
     4. Identifying, implementing, and evaluating the quality factors to be implemented in the product.
     5. Implementing the product design/development practices, processes, and procedures as defined
        in reference (d) and other program/project planning documents.
     6. Fill-in additional functional responsibilities.
e. Product Test is responsible for the items listed below:
     1. Reviewing and commenting on the [[Project Title]] QA Plan.
     2. Implementing the quality program in accordance with this QA Plan.
     3. Resolving and following-up on any quality issues raised by QA related to product testing.
     4. Verifying the quality factors are implemented in the product.
     5. Implementing the product test practices, processes, and procedures as defined in reference
        (d) and other program/project planning documents.
     6. Fill-in additional functional responsibilities.
f.   System Test is responsible for the items listed below:
     1. Reviewing and commenting on the [[Project Title]] QA Plan.
     2. Implementing the quality program in accordance with this QA Plan.
     3. Resolving and following-up on any quality issues raised by QA as related to system test.
     4. Verifying the quality factors are implemented in the system.
     5. Implementing the system test practices, processes, and procedures as defined in reference (d)
        and other program/project planning documents.
     6. Fill-in additional functional responsibilities.
g. Logistics is responsible for the items listed below:
     1. Reviewing and commenting on the [[Project Title]] QA Plan.
     2. Implementing the quality program in accordance with this QA Plan.
     3. Fill-in additional functional responsibilities.
h. Configuration Management (CM) is responsible for the items listed below:
     1. Reviewing and commenting on the [[Project Title]] QA Plan.
     2. Implementing the quality program in accordance with this QA Plan.



                                               2-3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


            3. Resolving and following-up on any quality issues raised by QA related to CM.
            4. Ensuring the quality factors related to CM are implemented in the system.
            5. Implementing the CM practices, processes, and procedures as defined in reference (d) and
               other program/project planning documents.
            6. Fill-in additional functional responsibilities.
      i.    Independent Verification and Validation (IV&V) is responsible for the items listed below:
            1. Reviewing and commenting on the [[Project Title]] QA Plan.
            2. Implementing the quality program in accordance with the [[Project Title]] QA Plan.
            3. Resolving and following-up on any quality issues raised by QA.
            4. Verifying the quality factors are implemented in the system.
            5. Implementing the practices, processes, and procedures as defined for IV&V in reference (d)
               and other program/project planning documents.
            6. Fill-in additional functional responsibilities.
      j.    Systems Engineering Process Office (SEPO) is responsible for the items listed below:
            1. Keeping references (a) and (e) current.
            2. Maintaining the QA Process, reference (f) and the QA Plan Template, reference (g).
            3. Ensuring QA training availability, either by vendor or SEPO.
            4. Providing assistance in process engineering and process improvement.
            5. Maintaining the Space and Naval Warfare System Center San Diego Standard Process
               Definition, reference (h), that describes many artifacts used to support QA verification
               activities.

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
The QA effort for this project is person-year effort or indicate the amount of effort if it is less than
100% - ensure the effort agrees with the project Work Breakdown Structure.
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 persons may be designated for a moderate to large -scale
project, or several part-time persons, or someone external to the project organization may be


                                                     2-4
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]


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.
The QA Manager will be familiar with and will be able to apply the standards and guidelines listed in
Section 1.7. Additionally, the QA Manager will be familiar with product quality, product development-
related activities, and structured analysis, design, fabrication, manufacturing, coding, and testing
[tailor this list as appropriate].
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 preprocess ors, 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 ac tivity and provide a
description of the process to be used.
The QA Group will utilize the following tools to perform audit/inspection events:
Guidance
List the tools, techniques and methodologies used; use Section 4, QA Schedule, to specify when
special tools are required

2.3     RISK MANAGEMENT
Guidance
Identify the risk management strategy for QA. If the project has identified an overall risk
management strategy in its PMP, or as a separate Risk Management Plan, reference this document.
If the QA Plan is written as a stand-alone document, describe the Risk Management activities for
the project:
      a. The identified QA risks, with estimates of severity and impact.
      b. The person(s) responsible for managing QA risks.



                                                  2-5
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


    c. The criteria (e.g. risk thresholds, conditions, etc.) necessary to commence risk management
       activities.
    d. The risk mitigation strategies for each risk.
    e. Etc.
Use the Risk Management Process, reference (i), as a guide for documenting the project QA risk
management process.
The QA Group identifies risks associated with accomplishing its planned activities. These risks are
managed in accordance with reference the appropriate document (PMP, Risk Management Plan,
etc.).
Guidance
Also discuss QA’s role in auditing and verifying project Risk Management activities and artifacts.
The QA Group audits project Risk Management activities for compliance to plans and procedures. This is
described in Section 3.1.8.




                                                2-6
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]



                                   SECTION 3. QA TASKS
Guidance
Development of this section requires the cooperation of the proj ect manager and QA manager to
identify the system life cycle processes, and the work products that are applicable to the project.
The processes listed here are drawn from Systems Engineering – System Life Cycle Processes,
ISO/IEC Standard 15288, reference (j), that describes system life cycle processes. 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 developme nt, test
and evaluation, logistic support, etc.) should dictate which of these 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.
The scheduling of QA tasks is driven by the project development schedule. Therefore, a QA task is
performed in relationship to what development activities are taking place. One or more QA tasks can be
performed concurrently until a task is completed. A task is considered completed when the required
report e.g., QA Reports, QA Audits Reports, etc. are satisfactorily completed or action items have been
closed. The following tasks, requiring coordination and cooperation with the project team, shall be
performed by QA.
For each evaluation conducted by QA, the results shall be documented using the QA Audit Report form
described in Section 6. QA recommendation for corrective action requires project management’s
disposition and will be processed in accordance with the guidance in Section 6.

3.1 PROCESS QUALITY ASSURANCE
Guidance
Describe the project processes that will undergo QA verification. Where appropriate, cite the
governing technical or administrative standard that describes the requirements for performing the
process being verified. For each documented process, include a checklist of activities that are
verified. The completed checklist provides an artifact of QA activity for the project’s processes.
3.1.1   Task: Evaluate Acquisition Process
QA shall conduct evaluation of the project Acquisition Process (e.g., the project’s Supplier Agreement
Management Process, if appropriate), verifying that project processes are defined and implemented to
obtain a product or service in accordance with acquirer requirements.
QA will use Appendix B, Section B.1 as a guide for conducting the evaluation.
3.1.2   Task: Evaluate Supply Process
QA shall conduct evaluation of the project Supply Process, verifying that project processes are defined
and implemented to provide a product or service that meets agreed requirements.


                                                  3-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


QA will use Appendix B, Section B.2 as a guide for conducting the evaluation.
3.1.3    Task: Evaluate Project Planning Process
QA shall evaluate the Project Planning Process, verifying that project processes are defined and
implemented that facilitate project management action to develop and document plans for Product
Development, CI and System Test, Installation, and Transition. Section 1.7 lists the program/project plans.
For project documents to be developed, QA will assist in identifying the appropriate guidelines, standards,
or Data Item Description (DIDs), and will assist with the tailoring of those guidelines, standards, or DIDs
to meet the project’s needs.
QA will use Appendix B, Section B.3 as a guide for conducting the evaluation.
3.1.4    Task: Evaluate Project Assessment Process
QA shall evaluate the Project Assessment Process, verifying that project processes are defined and
implemented to provide tracking and oversight of scheduled project activities prepared in accordance with
project management plans for Product Development, CI and System Test, Installation, and Transition.
Section 1.7 lists the program/project plans.
QA will use Appendix B, Section B.4 as a guide for conducting the evaluation.
3.1.5    Task: Evaluate Project Reviews
QA shall evaluate that the project has, where identified in project plans (e.g. Project Management Plan),
established and conducted formal Project Reviews of performance of project activities.
QA will use Appendix B, Section B.5 as a guide for conducting the evaluation.
3.1.6    Task: Evaluate Project Control Process
QA shall evaluate the Project Control Process, verifying that project processes are defined and
implemented to direct project plan execution and ensure that the project performs according to the project
plans and schedules, within estimated budgets, and satisfying technical objectives. Project control includes
redirecting project activities, as appropriate, to correct identified departures and variations from other
project management or technical processes. Redirection may include re-planning as appropriate.
QA will use Appendix B, Section B.6 as a guide for conducting the evaluation.
3.1.7    Task: Evaluate Decision-Making Process
QA shall evaluate the project Decision-Making Process, verifying that project processes are defined and
implemented to facilitate selecting the most beneficial course of project action where alternatives exist.
The Decision-Making Process responds to a request for a decision encountered during the system life
cycle, whatever its nature or source, to reach specified, desirable or optimized outcomes. Alternative
actions are analyzed and a course of action is selected and directed. Decisions and their rationale are
recorded to support future decision-making.
QA will use Appendix B, Section B.7 as a guide for conducting this evaluation.
3.1.8    Task: Evaluate Risk Management Process
QA shall evaluate the project Risk Management Process, verifying that project processes are defined and
implemented to reduce the effects of uncertain events that may result in changes to quality, cost, schedule
or technical characteristics. The project Risk Management Process identifies, assesses, treats and



                                                  3-2
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]


monitors risks during the entire life cycle, responding to each risk in terms of appropriate treatment and
acceptance.
QA will use Appendix B, Section B.8 as a guide for conducting this evaluation.
3.1.9   Task: Evaluate Configuration Management Process
QA shall evaluate the project Configuration Management Process, verifying that project processes are
defined and implemented to establish and maintain the integrity of all identified outputs of a project or
process and make them available to all project stakeholders.
QA will use Appendix B, Section B.9 as a guide for conducting this evaluation.
3.1.10 Task: Conduct Configuration Audits
Guidance
The following subparagraphs describe QA conduct of Functional and Physical Configuration
Audits (FCA/PCA). These two audits comprise core project product quality assurance activities.
These audits are typically directed by the project sponsor and, whether directed or not, should be
included in project planning for major product development/deployment milestones. Conducting
FCA/PCA provides for project Product as well as Process Quality Assurance.
3.1.10.1 Functional Configuration Audit. The Functional Configuration Audit (FCA) is held prior to
software delivery to compare the product as built (including its architectural components (hardware),
executable forms (software) and available documentation) with the requirements as stated in the baseline
System/Software Requirements Specification (SRS). The purpose is to ensure that the product as built
has addressed all, and only, the documented requirements and functional capabilities stated in the SRS.
MIL-HDBK-61A, Configuration Management Guidance, reference (k), provides the guidelines for
conducting an FCA. QA will participate as a member of the FCA team with other FCA team members to
be assigned by the project manager. QA will assist in the preparation of the FCA findings. Any follow-up
to the reported FCA findings will be monitored and tracked to closure.
QA will prepare audit documentation in accordance with the applicable Project Management Plan or
Configuration Management Plan.
3.1.10.2 Physical Configuration Audit. The Physical Configuration Audit (PCA) is held to verify that
the product and its documentation are internally consistent and are ready for delivery. The purpose is to
assure that the documentation to be delivered is consistent and correctly describes the product. Reference
(k) provides the guidelines for conducting a PCA. QA will participate as a member of the PCA team with
other PCA team members to be assigned by the project manager. QA will assist in the preparation of the
PCA findings. Any follow-up to the reported PCA findings will be monitored and tracked to closure.
QA will prepare audit documentation in accordance with the applicable Project Management Plan or
Configuration Management Plan.
3.1.11 Task: Evaluate Product Development Library Control Process
Guidance
Some projects may tailor this section and associated Appendix to describe QA verification of
Configuration Management Library Control Processes that support either or both systems and
software engineering. The evaluation may also be tailored to include verification of Engineering



                                                   3-3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


Notebooks and Software Development Folders. The evaluations should evaluate CM activities as
described in the Project CM Plan and/or PMP.
QA shall evaluate the project Product Development Library Control Process, verifying that processes,
tools, and procedures have been established to support the effective CM of development product
components, hardware, software, tailor list as appropriate and supporting elements.
QA will use Appendix B, Section B.10 as a guide for conducting this evaluation.
3.1.12 Task: Evaluate Media Certification and Control Process
QA shall evaluate the correct implementation of the Project Media Certification Process. “Media”
includes paper documentation and computer retrieval devices, including CDROMs, tapes, diskettes, etc.
that provide supporting information for the fielding of a hardware or software system and/or product.
QA will use Appendix B, Section B.11 as a guide for conducting this evaluation.
Guidance
The purpose of Media Control evaluation is to state the methods and facilities to be used, and
whose proper use is to be verified by QA, to identify the media for each computer product and the
documentation required to store the media, including the copy and restore process, and to protect
the computer program physical media from unauthorized access or inadvertent damage or
degradation during all phases of the product life cycle. This may be provided as a part of
reference (b). If so, an appropriate reference should be made.
Media control includes the items listed below:
    a. Regularly scheduled backup of the media.
    b. Labeled and inventoried media filed in a storage area in accordance with security requirements
       and in a controlled environment that prevents degradation or damage to the media.
    c. Adequate protection from unauthorized access.
The media control methods and facilities are described in reference (b). QA will conduct ongoing
evaluations of the media control process to verify that the process of controlling the media is effective and
in compliance with reference (b).
3.1.13 Task: Evaluate Information Management Process
QA shall evaluate the Information Management Process to ensure the project’s defined process provides
relevant, timely, complete, valid, and, if required, classified information to designated parties during and, as
appropriate, after the system life cycle.
QA will use Appendix B, Section B.12 as a guide for conducting this evaluation.
3.1.14 Task: Evaluate Quality Assurance Process
The Project Manager requests periodic independent assessments of project QA. These assessments will
be conducted at least annually. The auditor, who must be independent of the assessed QA group, will
review QA audits conducted on the project, including documented findings and corrective actions, and will
consult with project personnel to ensure that QA activities have been accomplished, and that corrective
actions have been implemented or resolved. The auditor will report findings of the independent
assessment to the Project and, where appropriate, Program Manager.



                                                    3-4
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]


The project sponsor organization QA may participate in the assessment of project QA to ensure its
successful implementation. When this occurs, project QA will ensure documented QA process review
findings and resulting action items are communicated to sponsor QA, and reported through to resolution of
the action items.
Independent assessments may be requested of higher-level QA personnel (where available, Department-
level QA personnel) or from SEPO
3.1.15 Task: Evaluate Requirements Definition and Analysis Process
QA shall evaluate the project Requirements Definition and Analysis Process verifying that it identifies
stakeholders or stakeholder classes involved with the system throughout its life cycle, and their needs and
desires. QA shall also verify that the processes transform the stakeholder, requirement-driven view of
desired services into a technical view of a required product that could deliver those services.
3.1.15.1 Task: Evaluate System Requirements Definition and Analysis Process . QA shall
evaluate the project System Requirements Definition and Analysis Process to verify that it establishes a
common understanding of the customer’s requirements between that customer and the project
development team. QA will verify that an agreement is established and maintained with the customer on
the requirements for the project. This agreement is known as allocating system requirements to software
and hardware.
Section 3.2.1 lists the system requirements documents.
QA will use Appendix B, Section B.13 as a guide for conducting this evaluation.
3.1.15.2 Task: Evaluate Software Requirements Definition and Analysis Process . QA shall
evaluate the project Software Requirements Definition and Analysis Process to verify that it supports the
items listed below:
    a. Formulation, documentation and management of the software requirements baseline.
    b. Responses to requests for clarification, correction or change; analysis of impacts; revisions of the
       software requirements specification.
    c. Management of the software requirements analysis and change process.
Section 3.2.1 lists the software requirements documents.
QA will use Appendix B, Section B.14 as a guide for conducting this evaluation.
3.1.16 Task: Evaluate Architectural Design Process
QA shall evaluate the project Architectural Design Process to verify that an architectural design baseline
is established; that an implementable set of system element descriptions that satisfy customer requirements
for the system are specified; that interface requirements are incorporated into the design solution; that
traceability of architectural design to system requirements is established; that a basis for verifying the
system elements is defined; and that a basis for the integration of system elements is established.
3.1.16.1 Task: Evaluate System Architectural Design Process. QA shall evaluate the project
System Architectural Design Process to verify that it supports the development of decisions about the
system’s behavioral design and other decisions affecting the selection and design of system components.
Section 3.2.1 lists the system design documents.
QA will use Appendix B, Section B.15 as a guide for conducting this evaluation.


                                                   3-5
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


3.1.16.2 Task: Evaluate Software Architectural Design Process . QA shall evaluate the project
Software Architectural Design Process to verify it supports the development of the overall structure of the
software to be built. QA shall review the detailed design of the software to ensure it will satisfy the
allocated requirements. The level of detail of this design must be such that someone other than the original
designer can accomplish the coding of the computer program.
Section 3.2.1 lists the software design documents.
QA will use Appendix B, Section B.16 as a guide for conducting this evaluation.
3.1.17 Task: Evaluate Implementation Process
QA shall evaluate the project Implementation Process for fabricating a product, and/or creating software
and supporting documentation. QA will verify that the implementation process supports transforming
specified behavior, interfaces and implementation constraints into fabrication actions that create a system
element according to the practices of the selected implementation technology. QA will verify that the
process results in a system element that satisfies architectural design requirements through verification and
stakeholder requirements through validation.
3.1.17.1 Task: Evaluate Hardware Implementation Process . QA shall evaluate the project
Hardware Implementation Process to ensure that an implementation strategy is defined and documented;
that implementation technology constraints on the design are identified; that a system element is realized,
and; that a system element is packaged and stored in accordance with an agreement for its supply.
Section 3.2.1 lists the hardware products.
QA will use Appendix B, Section B.17 as a guide for conducting this evaluation.
3.1.17.2 Task: Evaluate Software Implementation Process . QA shall evaluate the project Software
Implementation Process to ensure that software development and testing conforms to project
implementation plans and produces a product that meets defined operational requirements and conforms to
defined operational characteristics.
Section 3.2.1 lists the software products.
QA will use Appendix B, Section B.18 as a guide for conducting this evaluation.
3.1.18 Task: Evaluate Product Integration and Verification Process
QA shall evaluate the project Product Integration and Verification Process to ensure that a system
element is assembled consistent with its architectural design, and that testing confirms that the systems
specified design requirements are fulfilled.
QA will use Appendix B, Section B.19 as a guide for conducting this evaluation.
3.1.19 Task: Evaluate Transition Process
Guidance
This section is applicable to those projects whose scope includes accomplishing or ensuring a
product or service is delivered, installed (if appropriate), and operationally tested to ensure
compliance with stakeholder requirements.




                                                     3-6
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]


QA shall evaluate the project Transition Process to ensure it supports project efforts to provide a verified
system, together with relevant enabling systems, e.g. operating system, installation equipment, support
system, operator training system, and user training system, as appropriate and specified in agreements.
QA will use Appendix B, Section B.20 as a guide for conducting this evaluation.
3.1.20 Task: Evaluate Validation Process
Guidance
This section is applicable to those projects whose scope includes providing objective evidence (i.e.
evidence obtained from reviewing developer activities and products that are reported to the
acquirer) that the services provided by a system comply with stakeholder requirements.
QA shall evaluate the project Validation Process to ensure that it supports a comparative assessment and
confirms that the stakeholder requirements are satisfied, and that where variances are identified, that these
are recorded and guide corrective actions. QA shall verify that the stakeholder ratifies the system
validation.
QA will use Appendix B, Section B.21 as a guide for conducting this evaluation.
3.1.21 Task: Evaluate Maintenance Process
Guidance
This section is applicable to those projects whose scope of tasking includes providing maintenance
of a system element or system. This tasking may be part of higher-level tasking for the development
and delivery of a system element or system, or may be specific to providing maintenance services
for an operational system element or system.
Projects performing repairable/logistic support may wish to tailor this section to ensure that the
accomplishment of the project’s various technical or logistic tasks are verified.
QA shall evaluate the project Maintenance Process to ensure the project monitors the supported system’s
capability to deliver services, records problems for analysis, takes corrective, adaptive, perfective and
preventive actions and confirms restored capability.
QA will use Appendix B, Section B.22 as a guide for conducting this evaluation.
3.1.22 Task: Evaluate Operation Process
Guidance
This section is applicable to those projects whose scope includes assigning personnel to operate a
system; to monitor the services and operator-system performance; and to sustain by analyzing
operational problems in relation to agreements, stakeholder requirements and organizational
constraints.
QA shall evaluate the project Operation Process to ensure that it supports the use of a system to deliver
its required services.
QA will use Appendix B, Section B.23 as a guide for conducting this evaluation.




                                                   3-7
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


3.1.23 Task: Evaluate Corrective Action Process
QA shall evaluate the project Corrective Action Process to ensure it supports the identification, recording
and resolution of anomalies in system elements.
QA will use Appendix B, Section B.24 as a guide for conducting this evaluation.
3.1.24 Task: Evaluate Disposal Proce ss
Guidance
This section is applicable to those projects that, in the course of life cycle activities, are responsible
for conducting the disposal or destruction of system elements, equipment, computer software or
documentation in accordance with guidelines or standards for safety, security, or environmental
protection.
QA shall evaluate the project Disposal Process to ensure it supports appropriate project measures for the
timely disposition of materials, equipments, media, or documentation.
QA will use Appendix B, Section B.25 as a guide for conducting this evaluation.
3.1.25 Task: Evaluate Subcontractor Control Process
Guidance
This section is applicable to those projects that acquire subcontractors for the accomplishment of
project tasking.
QA shall evaluate the project Subcontractor Control Process.
QA will use Appendix B, Section B.26 as a guide for conducting this evaluation.

3.2 PRODUCT QUALITY ASSURANCE
Guidance
Describe the project products that will undergo QA verification. Where appropriate, cite the
governing technical or administrative standard that describes the requirements for engineering the
product, or for producing the service-related products being verified. For each product, include a
checklist of activities that are verified. The completed checklist provides an artifact of QA activity
for the project’s products.
3.2.1    Deliverable Document/Product Verification
The documentation that describes and supports the [[Project Title]] product or the product development
process shall be established and maintained periodically throughout the project life cycle.
Table 3-1 is a list of [[Project Title]] deliverables and associated supporting documents and the standard or
guidelines used to establish and maintain the products. Any tailoring guidelines are also found in Table 3-1.
Table 3-2 is a list of non-deliverable documents.
For the project’s documents to be established and not yet listed in Tables 3-1 and 3-2, QA will assist in
identifying the specifications, standards, and DIDs to be followed in the preparation of the required
documentation.
Guidance


                                                   3-8
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]


List the products (or reference the document, e.g. CM Plan , PMP, that lists the products) that will
be established/maintained and identify the associated Data Item Description (DID) or standard or
guidelines that are used to establish/maintain the product to which this QA Plan applies in Table 3 -
1. If there are any tailoring guidelines, provide that information in Table 3 -1. Identify all non-
deliverable documents in Table 3-2.

                              TABLE 3-1. DELIVERABLE PRODUCTS
                                         DELIVERABLE                GOVERNING DID, STANDARD,
        NOMENCLATURE
                                          SUPPORTING                       GUIDELINE
                                        DOCUMENTATION
 [[CI 1]]                            Document Type                 DID, Standard, Guideline
 [[CI 2]]                            Document Type                 DID, Standard, Guideline
 [[CI 3]]                            Document Type                 DID, Standard, Guideline


                          TABLE 3-2. NON-DELIVERABLE DOCUMENTS
                                           DOCUMENT TITLE
                          Document title
                          Document title
                          Document title


Guidance
State how the documents are to be checked for adequacy. The document review process should
include the criteria and the identification of the review or audit by which the adequacy of each
document shall be confirmed.
All documents will undergo a peer review in accordance with the Peer Review Process, reference (l).
Upon completion of a peer review, QA records and reports Peer Review measurements (the item
reviewed, the number of errors detected, the phase when the Peer Review was conducted, the number of
closed error reports, and the number of open error reports) to SEPO.
Upon completion of a peer review, the document will be submitted to CM and placed under CM control.
The document will then be processed in accordance with the CM document approval and release process
as described in reference (b).
3.2.2   Tool Evaluation
QA shall conduct evaluations of hardware and/or software tools, both existing and planned, used for
product development and support. The tools are evaluated for adequacy by assessing whether they
perform the functions for which the tools are intended and for applicability by assessing whether the tool
capabilities are needed for the product development or support. Planned tools are evaluated for feasibility




                                                  3-9
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


by assessing whether they can be developed with the techniques and computer resources available or by
procurement.
Figure 3-1 provides the format for evaluating software tools.
3.2.3    Facilities Evaluation
QA shall evaluate facilities, both existing and planned, for adequacy by assessing whether they provide the
equipment and space needed for product development, test and support.
Figure 3-2 provides the format for evaluating existing and planned [[Project Title]] facilities.




                                                   3-10
                                                                                 [[Project Title]] QA Plan
                                                                      [[Document Configuration Identifier]]
                                                                                       [[Document Date]]




                                         TOOL EVALUATION
QA:_________________________                             DATE OF EVALUATION:___________


Tool Evaluated:




Methods or criteria used in the evaluation:




Evaluation Results:




Recommended Corrective Actions




Corrective Action Taken




                                        Figure 3-1. Tool Evaluation




                                                 3-11
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                    PROJECT FACILITIES EVALUATION


QA:_________________________                                    DATE OF EVALUATION:__________


Facility Evaluated (Equipment, User/Test/Library Space):




Methods or criteria used in the evaluation:




Evaluation Results:




Recommended Corrective Actions




Corrective Action Taken




                                        Figure 3-2. Project Facilities Evaluation




                                                        3-12
                                                                                       [[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. If they do participate, they should be included in the project QA
responsibility matrix. The matrix could comprise the following suggested format:

                                TABLE 3-3. RESPONSIBILITY MATRIX
  Task Description        QA       Prog.      Proj.      CM    Sys      Sys       SW       Sys        Log-
                          Mgr      Mgr        Mgr              Eng      Dev       Test     Test       istics
  Task 1                  X                   X
  Task 2                  X        X          X          X     X        X         X        X          X
  Task N                  X        X          X


The ultimate responsibility for the quality of the [[Project Title]] products and associated documentation
produced by [[SSC San Diego or Agency Name]] rests with the [[Project Title]] Project Manager. The
QA Manager shall implement the QA procedures defined in this plan.
QA derives its authority from the Project Manager through the [[SSC San Diego Branch / Division /
Department or Agency Name]] Manager. QA shall monitor project staff activities and review products
for compliance to applicable standards, procedures, and reference (b). The results of QA monitoring and
analysis along with QA recommendations for corrective action shall be reported to the Project Manager,
and, as required, to the [[SSC San Diego Branch/Division/Department or Agency Name]] Manager. All
documents and products approved by the Project Manager for release to [[user activity]] shall have been
reviewed and approved by QA. Add this sentence if a responsibility matrix is included [[Table 3-3 is a
responsibility matrix for the tasks identified in this section.]]
Where appropriate, support of QA activity may include QA personnel from the project sponsor level.
When this occurs, the Project Manager and Project QA will ensure that all documentation of reviews,
audits, resulting identified issues and action items are available to sponsor QA personnel.




                                                  3-13
                                                                                      [[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.
QA schedules are closely coordinated with the product schedule in reference (d). Process and product
audits will be performed at the appropriate milestone of each project phase to verify that the appropriate
processes are correctly implemented as defined in the planning documents, and that products satisfy and
are established or maintained in accordance with defined processes. In addition, spot-checks
(unscheduled audits) will be made during each phase of development to verify that the processes, desktop
procedures, and interim products (when appropriate) are being accomplished. At the completion of a
project life cycle phase, QA will review and report whether all steps required to transition to the next
phase have been accomplished.




                                                  4-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     4-2
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



      SECTION 5. STANDARDS, PRACTICES, CONVENTIONS AND
                          METRICS

5.1   STANDARDS, PRACTICES AND CONVENTIONS
This section describes the procedures used by QA to verify that the quality assurance provisions of this
QA Plan and applicable standards, practices, conventions, and metrics are met.
Guidance
Identify the standards (mandatory requirements) to be applied. State how compliance with these
items is to be monitored and assured. Tailor this section to reflect the actual project products, e.g.
hardware, software, documentation, etc.
It should be noted that whenever a project product reflects TAILORING of a governing guideline
or standard, e.g. MILSPEC, QA should verify that the project has fully described the scope of
tailoring with supporting rationale in the PMP or similar document.
Guideline title or reference is the product development standard used by the [[Project Title]]; any
tailoring of this standard is documented in reference (d). Section 3 identifies QA evaluation of the
requirements, design, implementation, and test phase to verify compliance with Guideline title or
reference and reference (d).
Section 3.2.1 identifies the associated DID for each document to be developed and maintained. Any
tailoring of the DID is described in reference (d). QA will verify documentation format and content
complies with the DID and reference (d).
Standards for the fabrication, manufacture, and performance testing of product hardware components are
described in reference (d). QA will verify product development and testing complies with these standards.
Standards for logic structure, coding, and code comments are described in reference (d). QA will verify
source code complies with these standards as detailed in reference (d).
Standards and practices for testing are described in reference (d). QA will verify testing activities
complies with reference (d).

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




                                                   5-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


cycle phases to gain confidence in the building of reliable software. To keep metrics simple, an
example of cost and schedule metrics is offered.
The following measurements will be made and used to determine the cost and schedule status of the QA
activities:
    a. QA milestone dates (planned)
    b. QA milestone dates (completed)
    c. QA work scheduled (planned)
    d. QA work completed (actual)
    e. QA effort expended (planned)
    f.   QA effort expended (actual)
    g. QA funds expended (planned)
    h. QA funds expended (actual)
    i.   Number of noncompliance items open
    j.   Number of noncompliance items closed
    k. Total number of noncompliance items
QA is responsible for reporting these measurements to the Project Manager on a monthly basis.




                                                5-2
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



        SECTION 6. QA PROBLEM REPORTING AND RESOLUTION
Guidance
Describe the practices and procedures to be followed for reporting, tracking, and resolving
problems identified in both product configuration items and the product establishment and
maintenance processes. State the specific organizational responsibilities concerned with their
implementation.
This section describes the reporting and control system used by QA to record and analyze discrepancies
and to monitor the implementation of corrective action. The forms utilized by QA for reporting are the
QA Audit Report, Problem/Change Report (P/CR) or Software Trouble Report (STR). Each of these
forms and their uses are discussed in the following section.

6.1     QA AUDIT REPORT
QA reports the results of a product or process audit and provides recommendations, if necessary, using
the QA Audit Report. The QA Audit Report is used to record that either:
      a. The product evaluated complies with the standards, requirements or processes that govern its
         development, or
      b. The project’s processes are (1) being followed correctly and working effectively, (2) being
         followed but not working effectively, or (3) not being followed.
Figure 6-1 provides the format of a QA Audit Report. QA will attach amplifying information to the QA
Audit Report including, but not limited to: process audit checklists, notes from product verification and
validation testing performed by QA, etc.
6.1.1     Submittal and Disposition of QA audit report
The QA Audit Report is directed to the groups listed below:
      a. Senior Management - The results of QA audits are used in conjunction with other project status
         information to guide senior management attention to identify and mitigate project risks at the
         organizational level.
      b. SEPG - The SEPG utilizes the QA audits results, in conjunction with the results of audits of other
         projects, to identify process weaknesses and initiate or enhance process improvement in specific
         areas. This data becomes part of the process database so that it is available for future project
         analysis and use.
      c. Project Manager - The project manager utilizes the report in the ways listed below:
          1. To provide insight into whether there is compliance with the evaluated project process and its
             effectiveness in meeting project goals. Where necessary and appropriate, the project
             manager may initiate enforcement activities or initiate change to the established processes
             using the approved procedures.
          2. To indicate agreement, disagreement, or deferral of recommendations cited in the QA Audit
             Report. Should the Project Manager indicate disagreement with the recommendations
             recorded on the QA Audit Report, the final disposition of report recommendations is made by
             the appropriate senior manager as described in Section 6.1.2.


                                                   6-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                  QUALITY ASSURANCE AUDIT REPORT
                                                         TRACKING IDENTIFIER:____________
LEAD AUDITOR:______________________________________ DATE OF
REPORT:_____________
AUDIT
TEAM:_______________________________________________________________________
______________________________________________________________________________
______
PROJECT
NAME:____________________________________________________________________
DATE OF AUDIT:_______________________ EFFORT EXPENDED:________________(total
hours)
PRODUCT/PROCESS/PROCEDURE
AUDITED:___________________________________________
AUDIT CHECKLIST/PRODUCT VERIFICATION USED:
(Attach)_____________________________
AUDIT FINDINGS: (Check one.)
         _____ Product/Process/Procedure Acceptable
         _____ Product/Process/Procedure Conditionally Acceptable
               (Subject to satisfactory completion of action items listed below)
               Conditions noted:
         _____ Product/Process/Procedure Unacceptable
               (Subject to satisfactory completion of action items listed below)
               Conditions noted:
ACTION ITEM (AI):
AI # TITLE                              ASSIGNED TO:          DUE DATE:            COMP DATE:___
______________________________________________________________________________
______
______________________________________________________________________________
______
______________________________________________________________________________
______
CORRECTIVE ACTION:
______________________________________________________________________________
______




                                                  6-2
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]


______________________________________________________________________________
______
RECOMMENDATIONS/SUGGESTED IMPROVEMENTS:
______________________________________________________________________________
______
______________________________________________________________________________
______
DISPOSITION:        APPROVE         CANCEL             DEFER
Project Manager:                                                        DATE:
______________________________________________________________________________
______
AI CLOSURE:
QA Sign-off:                                                    DATE:
(FILE COMPLET ED FORM IN QA EVALUAT ION RECORD.)

                              Figure 6-1. Quality Assurance Audit Report
6.1.2   Escalation Procedure for Resolution of Non-Concurrence on QA audit report
In the event that affected project personnel dispute the findings and recommendations of a QA Audit
Report, QA will first communicate with the affected Project Manager to resolve the dispute. If the
affected Project Manager also disputes the findings and/or recommendations, senior management (at least
one management level higher than that affected by the QA Audit Report recommended actions) directs
final disposition of QA audit report recommendations. The affected project implements, defers, or cancels
the implementation of corrective actions recommended on the QA Audit Report as directed by senior
management. This direction is recorded and dated by senior management (or other management, as
appropriate) to be added to the QA evaluation records of the project. QA retains the original record of
findings and subsequent resolution data in its audit files.

6.2 RECORDING PROBLEMS IN HARDWARE, SOFTWARE CODE OR
DOCUMENTATION
Problems found in the hardware, software code or documentation that are under configuration
management must be recorded by means of a P/CR (or STR, as appropriate to the project) regardless of
how or by whom the problem was discovered. P/CRs generated by QA shall be prepared and processed
in accordance with reference (b). QA shall analyze P/CRs for problem trends in an effort to prevent
recurring discrepancies. QA shall report the results of P/CR trend analyses along with suggestions for
problem resolution and prevention. The format of the P/CR or STR is found in reference (b).




                                                 6-3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     6-4
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]



      SECTION 7. RECORDS COLLECTION, MAINTENANCE AND
                         RETENTION
Guidance
Identify the QA documentation to be retained, state the methods and facilities to be used to
assemble, safeguard, and maintain this documentation, and designate the retention period.
QA documents its activities through records and reports that provide a history of product quality
throughout the project life cycle. Measurement data collected will be reviewed for trends and process
improvement. All QA records will be collected and maintained under configuration control or archival
storage for the life cycle of the product or a minimum of state number of years.




                                                 7-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     7-2
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]



                                  SECTION 8. TRAINING
Guidance
Identify the training activities necessary to meet the needs of the QA Plan. Tailor the contents of
Table 8-1 below to reflect the project’s requirements.
Table 8-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 8-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
                                                            OJT             Management 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



                                                 8-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     8-2
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]



   SECTION 9. REVIEW OF QA ACTIVITIES WITH HIGHER LEVEL
                      MANAGEMENT

This section describes the requirement for periodic review of QA activities with higher-level management.
The [[Project Title]] Project Management Plan or other appropriate project management document
describes the process for conducting periodic reviews of all project activity. QA activities will be
reviewed during name of project review. Agenda for these reviews will include the items listed below:
    a. QA scheduled activities
    b. QA performance metrics
    c. Review of planned versus actual QA tasking
    d. Outstanding issues.

Guidance
This is a nominal agenda for reviewing QA activities. The project QA, collaborating with the
project manager, should establish and document in the PMP or QA Plan the appropriate agenda
items for review during these meetings; the process for these meetings should also establish
required attendees from higher level management, and any reports or action items that are
documented to facilitate managing QA activities.




                                                 9-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     9-2
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]



     SECTION 10. COLLECTING IMPROVEMENT INFORMATION

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.
The QA group, working with the project manager, defines measures of QA activity, which includes the
measures listed below:

Guidance
If appropriate, cite the project database from which these measures are derived.
   a. Effort and funds expended for each activity
   b. Number of QA reviews and audits conducted (planned vs. actual)
   c. Number of unresolved issues (elevated to PM) compared to all issues reported
   d. Proposed new or revised QA processes.
   e. Periodic objective review of QA activities (reporting identified process defects and resolution, and
      recommended process improvements).

Guidance
These are nominal proposed QA performance measures. The QA group should use this section to
identify the specific performance measures that will be collected and evaluated by the group and
the Project Manager to facilitate the management and improvement of the QA function
On a periodic basis, in accordance with cite the governing project planning document, e.g. Project
Management Plan the QA group reports these measures to the Project Manager. The Project Manager
uses these measures as the basis for reviewing QA function effectiveness, and for proposing new or
revised QA processes. These metrics are also reported in the periodic review of project activities
conducted in accordance with cite the governing project-planning document, e.g. Project
Management Plan.
The QA Group, as a result of implementing this QA Plan, may identify potential improvements to this
template, and to the defined QA Process. The QA Group will communicate these improvements to the
[Department] Systems/Software Process Improvement (SPI) Agent. The SPI Agent, working with the
QA Group, reviews and, when deemed appropriate, nominates improvements to the QA Plan Template
and/or Process to the Systems Engineering Process Office (SEPO) by submitting a prepared Document
Change Request (DCR). The DCR form is included in this QA Plan.




                                                10-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                        This page intentionally left blank.




                                                     10-2
                                                                      [[Project Title]] QA Plan
                                                           [[Document Configuration Identifier]]
                                                                            [[Document Date]]



            APPENDIX A. LIST OF ACRONYMS

AI     Action Item
CASE   Computer-Aided Software Engineering
CDR    Critical Design Review
CI     Configuration Item
CM     Configuration Management
CRR    Critical Requirements Review
DBDD   Database Design Description
DCR    Document Change Request
DID    Data Item Description
EIA    Electronic Industries Association
FCA    Functional Configuration Audit
IDD    Interface Design Description
IEC    International Electrotechnical Commission
IEEE   Institute of Electrical and Electronics Engineers
IRS    Interface Requirements Specification
ISO    International Organization for Standardization
IV&V   Independent Verification and Validation
MIL    Military
OCD    Operational Concept Document
OCR    Operational Concept Review
OJT    On-the-Job
PCA    Physical Configuration Audit
P/CR   Problem/Change Report
PDR    Preliminary Design Review
PDL    Product Development Library
PMCC   Project Management Core Course
PMG    Project Management Guide
PMP    Project Management Plan
QA     Quality Assurance
SDD    Software Design Document


                                      A-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


    SDF                 Software Development File
    SDP                 Software Development Plan
    SDR                 Software Design Review
    SEM                 Systems/Software Engineering Management
    SEPO                Systems Engineering Process Office
    SMR                 Systems Maintenance Review
    SPAWAR              Space and Naval Warfare
    SPI                 Systems/Software Process Improvement
    SPR                 Systems/Software Plan Review
    SRR                 System Requirements Review
    SRS                 Software Requirements Specification
    SSC                 SPAWAR Systems Center
    SSDD                System/Subsystem Design Description
    SSCR                Systems/Software Design Review
    SSR                 Software Specification Review
    SSRR                Systems/Software Requirements Review
    STD                 Standard
    STR                 Software Trouble Report
    STRR                Systems Test Results Review
    SUR                 System Usability Review
    TRR                 Test Readiness Review
    VDD                 Version Description Document




                                                    A-2
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



  APPENDIX B. PROCESS/PRODUCT AUDIT TASK DESCRIPTIONS
               AND SUPPORTING CHECKLISTS
This appendix provides the following audit task descriptions with supporting checklists:
    B.1 – EVALUATE ACQUISITION PROCESSES
    B.2 – EVALUATE SUPPLY PROCESS
    B.3 – EVALUATE PROJECT PLANNING PROCESS
    B.4 – EVALUATE PROJECT ASSESSMENT PROCESS
    B.5 – EVALUATE PROJECT REVIEWS
    B.6 – EVALUATE PROJECT CONTROL PROCESS
    B.7 – EVALUATE DECISION-MAKING PROCESS
    B.8 – EVALUATE RISK MANAGEMENT PROCESS
    B.9 – EVALUATE CONFIGURATION MANAGEMENT PROCESS
    B.10 – EVALUATE PRODUCT DEVELOPMENT LIBRARY CONTROL PROCESS
    B.11 – EVALUATE MEDIA CERTIFICATION PROCESS
    B.12 – EVALUATE INFORMATION MANAGEMENT PROCESS
    B.13 – EVALUATE SYSTEM REQUIREMENTS DEFINITION AND ANALYSIS PROCESS
    B.14 – EVALUATE SOFTWARE REQUIREMENTS DEFINITION AND ANALYSIS PROCESS
    B.15 – EVALUATE SYSTEM ARCHITECTURAL DESIGN PROCESS
    B.16 – EVALUATE SOFTWARE ARCHITECTURAL DESIGN PROCESS
    B.17 – EVALUATE HARDWARE IMPLEMENTATION PROCESS
    B.18 – EVALUATE SOFTWARE IMPLEMENTATION PROCESS
    B.19 – EVALUATE PRODUCT INTEGRATION AND VERIFICATION PROCESS
    B.20 – EVALUATE TRANSITION PROCESS
    B.21 – EVALUATE VALIDATION PROCESS
    B.22 – EVALUATE MAINTENANCE PROCESS
    B.23 – EVALUTATE OPERATION PROCESS
    B.24 – EVALUATE CORRECTIVE ACTION PROCESS
    B.25 – EVALUATE DISPOSAL PROCESS
    B.26 – EVALUATE SUBCONTRACTOR CONTROL PROCESS




                                                  B-1
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.1 EVALUATE ACQUISITION PROCESSES
QA activities are listed below:
    a. Verify a documented strategy for the acquisition.
    b. Verify the criteria for, and selection of, a supplier.
    c. Verify evidence of regular communication with the supplier.
    d. Verify a documented agreement to acquire a product or service according to defined acceptance
       criteria.
    e. Verify documented acceptance that the delivered product and/or service complies with the
       agreement.
Figure B-1 provides a checklist for QA to use to audit the project acquisition process.




                                                    B-2
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]




                  PROJECT ACQUISITION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The Project has documented plans for how the acquisition will be accomplished, and they include:

     ____ Reference to the appropriate life cycle model being followed

     ____ If the supplier is external to the organization, a schedule of milestones and selection criteria

____The Project has documented a request for the supply of a product or service.

____The Project has communicated the request for the supply of a product or service to identified
    suppliers.

____The Project has documented selection criteria for a supplier.

____The Project has a documented agreement with the supplier that establishes:

     ____Requirements

     ____Development and delivery milestones

     ____Verification, validation and acceptance conditions

     ____Exception handling conditions

     ____Change control procedures

____The project has documented that delivered products and/or services comply with the supplier
    agreement.

____The project has documented an assessment of the execution of the supplier agreement.

                         Figure B-1. Project Acquisition Process Audit Checklist




                                                   B-3
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.2 EVALUATE SUPPLY PROCESS
QA activities are listed below:
    a. Verify the identification of an acquirer for the product or service
    b. Verify a documented response to the acquirer’s request
    c. Verify a documented agreement to supply a product or service according to defined acceptance
       criteria
    d. Verify evidence that the project has supplied a product or service conforming to the agreement
       according to agreed delivery procedures and conditions
    e. Verify documented transfer of responsibility for the acquired product or service, as directed by the
       agreement, is accomplished
Figure B-2 provides a checklist to use to audit the project supply process.




                                                   B-4
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]




                      PROJECT SUPPLY PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The Project has a documented agreement to supply an identified acquirer with a product and/or
    service that includes:

    ____Acquirer requirements

    ____Deliver milestones and acceptance conditions

    ____Exception handling procedures

    ____Change Control procedures

____The Project has documented evidence of the execution of the acquirer agreement.

____The Project has assessed the execution of the agreement, including:

    ____Monitoring and Oversight of project cost, performance and schedule risks

    ____Analysis of actual project cost, performance and schedule adherence

____The Project has documented evidence of the delivery of the product and/or service in accordance
    with the agreement criteria.

____The Project has documented evidence of the transfer of responsibility for the product and/or service
    to the acquirer.

                          Figure B-2. Project Supply Process Audit Checklist




                                                 B-5
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.3 EVALUATE PROJECT PLANNING PROCESS
QA shall evaluate that the project plans the relevant activities stated in the Program and Project plans. To
verify that these activities are documented, QA will audit the project schedule that defines the project
activities, and will use reference (d) or other planning document as the measure of whether those activities
are being planned.
QA activities are listed below:
    a. Verify Project Plans are documented
    b. Verify project roles, responsibilities and authorities are defined
    c. Verify resources and services required to achieve the project objectives are identified
    d. Verify project performance measures are defined
    e. Verify project staff are directed in accordance with the project plans
Figure B-3 provides a checklist to use to audit the project planning process.




                                                   B-6
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]




                    PROJECT PLANNING PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____Project plans and commitments, objectives and constraints exist and are documented in the PMP or
    other appropriate documents.

____Project plans define performance measures to track the accomplishment of project objectives.

____Standards governing the scope of the project’s development process are documented and reflected in
    the PMP.

____The content of the PMP reflects consistent implementation of organization’s standard process.

____The PMP is under configuration management.

____The activities of project estimation are conducted in accordance with a defined Estimation Process
    and results are documented.

____The organizational database is used for making estimations.

____Project requirements are the basis for plans, work products, and activities.

____Plans for conducting configuration management exists and are documented in the PMP or a separate
    Configuration Management Plan (CM Plan).

____The CM Plan is under configuration management.

____Plans for conducting quality assurance exists and are documented in the PMP or a separate Quality
    Assurance Plan (QA Plan).

____Plans for conducting integration testing exist and are documented in a Project Test Plan.

____Plans for conducting system testing exist and are documented in a Project Test Plan or other
    appropriate document.

____The Project Test Plans are under configuration management.

____Plans for conducting software transition exist and are documented.

____Project schedules and plans undergo a peer review prior to establishing their baselines.



                                                  B-7
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


                               Figure B-3. Project Planning Process Audit Checklist

B.4 EVALUATE PROJECT ASSESSMENT PROCESS
QA shall evaluate that the project assessment process provides tracking and oversight of the
accomplishment of project schedules and conducts the relevant activities, including management oversight
and review, stated in the Program and Project plans. To verify that these activities are performed as
planned, QA will audit the schedule that defines the activity, and will use reference (d) or other planning
document as the measure of whether those activities are being scheduled and conducted.
QA periodic management review of project status, progress, problems, and risk will provide an
independent assessment of project activities. QA will provide the following information to management:
    a. Compliance - Identification of the level of compliance of the project with established organizational
       and project processes.
    b. Problem areas - identification of potential or actual project problem areas based on analysis of
       technical review results.
    c. Risks - identification of risks based on participation and evaluation of project progress and trouble
       areas.
Because the QA function is integral to the success of the project, QA will freely communicate its results
to senior management, project management and the project team. The method for reporting compliance,
problem areas, and risks will be communicated in a documented report or memorandum. Compliance,
problem areas, and risks will be followed-up and tracked to closure.
QA will verify that:
    a. Project performance measurements or assessment results are recorded.
    b. Adequacy of project support for defined roles, responsibilities and authorities is reviewed.
    c. Adequacy of project resources and services required to accomplish the project objectives is
       reviewed.
    d. Departures from project performance criteria are analyzed.
    e. Stakeholders are informed of project status.
Figure B-4 provides a checklist to use to audit the project assessment process.




                                                     B-8
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]




                  PROJECT ASSESSMENT PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____Project Management Plan exists and is under CM.

____Project measurements are collected in accordance with the Project Management Plan or project
    measurement plan.

____Project progress is assessed using measured achievement and milestone completion.

____Reports of departures or variations from planned progress or performance are reported, and
    recommendations for correction are made and implemented.

____Project reviews project status against plans to determine cost, schedule and quality variations.

____Measurements are used for re-planning analysis.

____The Project Manager reviews project status on a biweekly basis.

____Branch Head reviews project status on a monthly basis.

____Division Head reviews project status on a quarterly basis.

____Quarterly Reviews are conducted in accordance with the project measurement plan.

____Required management and technical reviews, audits and inspections are conducted to determine
    readiness to proceed to the next stage of a system life cycle or project milestone.

____Quality Assurance is conducted in accordance with the Project QA Plan.

                        Figure B-4. Project Assessment Process Audit Checklist




                                                  B-9
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




B.5 EVALUATE PROJECT REVIEWS
Guidance
Define project reviews to be conducted. State how the reviews are to be accomplished. State what
further actions are required and how they are to be implemented and verified. The type and scope
of reviews depends heavily on the size, scope, risk and criticality of the project. The reviews
identified here should be the same as specified in reference (d).
Tailor the table of reviews, Table B-1, to reflect formal project plans (e.g. Project Management
Plan) for conducting these activities.
Table B-1 identifies the required reviews for the system and software development phases.
A primary component of engineering quality is the conduct of project reviews of hardware and/or
software products, both deliverable and non-deliverable. Participants of a review shall include persons
with technical knowledge of the hardware and/or software products to be reviewed. The purpose of the
review will be to focus on in-progress and final products rather than the materials generated especially for
the review. QA will assure that reviews are accomplished and will selectively attend them in accordance
with approved sampling techniques. The guidelines of MIL-STD-1521B, Technical Reviews and Audits
for Systems, Equipments, and Computer Software, reference (q), may be used for conducting a technical
review. A summary of each kind of review appears below:
Guidance
The following list of project reviews are taken from Annex G of IEEE 12207, which provides
candidate joint management reviews; Annex E of EIA-632, Processes for Engineering a System,
also provides descriptions of system reviews. Tailor this project review list to reflect the project
guidelines, referred to in the Project Management Plan, that direct this project.
    a. System/Software Plan Review (SPR) - the objective is to ascertain the adequacy of the
       developer’s documented system/software development plans.
    b. Operational Concept Review (OCR) - the objective is to evaluate the correctness and
       completeness of the developer’s Operational Concept Document (OCD).
    c. System/Subsystem Requirements Review (SSRR) - the objective is to evaluate the progress,
       consistency, and technical adequacy of the selected top-level design and test approach,
       compatibility between system requirements and preliminary design, and the preliminary version of
       the operation and support documents.
    d. System/Subsystem Design Review (SSDR) - the objective is to determine acceptability of the
       detailed design, performance, and test characteristics of the design solution, and on the adequacy
       of the operation and support documents.
    e. Software Requirements Review (SRR) - the objective is to review the finalized software
       requirements. A successful SRR shows that the System/Software Requirements Specification
       (SRS), Interface Requirements Specification (IRS), and Operational Concept Document (OCD)
       form a satisfactory basis for proceeding into preliminary design.




                                                  B-10
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]


  f.   Software Design Review (SDR) – the objective is to review the finalized software-wide design
       decisions, the architectural design of a software item, and the detailed design of a software item or
       portion thereof (such as a database).

                               TABLE B-1. REVIEWS AND AUDITS
SYSTEM AND SOFTWARE                    PRODUCTS               REQUIRED AUDITS AND REVIEWS
    DEVELOPMENT
  EVENT/MILESTONE
System/Subsystem                 SRS, IRS, OCD              (1) System Requirements Review (SRR)
Requirements                                                (2) Process Audits
                                 PMP, SDP, CM Plan,
                                 QA Plan                    (3) Management Review
                                                            (4) Peer Review
System Design                    System/Subsystem           (1) System Design Review (SDR)
                                 Design Description         (2) Process Audits
                                 (SSDD), Interface          (3) Management Review
                                 Design Description         (4) Peer Review
                                 (IDD)
Software Requirements            SRS, IRS                   (1) Software Specification Review (SSR)
                                                            (2) Process Audits
                                                            (3) Management Review
                                                            (4) Peer Review
Software Design                  Software Design            (1a) Software Preliminary Design Review
                                 Document (SDD),            (PDR)
                                 Database Design            (1b) Software Critical Design Review
                                 Description (DBDD),        (CDR)
                                 IDD                        (2) Process Audits
                                                            (3) Managerial Review
                                                            (4) Peer Review
Software/Hardware                Software/Hardware          (1) Process Audits
Implementation                   products                   (2) Management Review
                                                            (3) Peer Review
Test                             Test Documentation         (1) Test Readiness Review (TRR)
                                                            (2) Process Audits
                                                            (3) Managerial Review
                                                            (4) Functional Configuration Audit
                                                            (5) Peer Review




                                                 B-11
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


 SYSTEM AND SOFTWARE                        PRODUCTS           REQUIRED AUDITS AND REVIEWS
     DEVELOPMENT
   EVENT/MILESTONE
 Product Release                        Version Description   (1) System Usability Review (SUR)
                                        Document (VDD),       (2) System Maintenance Review (SMR)
                                        User documentation    (2) Process Audits
                                                              (3) Management Review
                                                              (4) Physical Configuration Audit
                                                              (5) Peer Review




                                                     B-12
                                                                                             [[Project Title]] QA Plan
                                                                                  [[Document Configuration Identifier]]
                                                                                                   [[Document Date]]




    g. Test Readiness Review (TRR) - the objective is to determine whether the test procedures are
       complete and to assure that the developer is prepared for formal hardware/software CI testing.
    h. System Test Results Review (STRR) – the objective is to verify that the issues regarding the
       results of system/software qualification testing are resolved.
    i.   System Usability Review (SUR) – the objective is to verify the readiness of the system for
         installation at user sites; the status of training, including “training software products”, if applicable;
         the readiness of user and operator manuals; the correctness of system/software version
         descriptions; and the status of installation preparations and activities.
    j.   System Maintenance Review (SMR) – the objective is to verify the readiness of the system for
         transition to life cycle maintenance; the completeness/correctness of supporting product
         specifications, maintenance manuals and version description documents; and the status of
         transition preparations and activities, including the transition of the product engineering
         environment, if applicable.
    k. Critical Requirement Review (CRR) - the objective is to determine the status and handling of
       critical requirements, such as those for safety and security.
Project reviews will be conducted to review evolving products, demonstrate proposed technical solutions,
and provide insight and obtain feedback on the technical effort. The outcome of a project review is listed
below:
    a. Identify and resolve technical issues.
    b. Review project status, specifically surface near- and long-term risk regarding technical, costs, and
       schedule issues.
    c. Arrive at agreed-upon mitigation strategies for identified risks, within the authority of those
       present.
    d. Identify risks and issues to be raised at joint management reviews.
    e. Verify on-going communications between acquirer and developer technical personnel.
The entrance criteria for a project review will require that a review agenda be distributed to the group
prior to the review meeting. Additionally, a recorder will be assigned to record any issues requiring
resolution stating action item assignee and due date, and decisions made within the authority of the project
review participants.
Various measurements are collected as part of reviews to help determine the effectiveness of the review
process itself as well as the process steps that are used to produce the item being reviewed. These
measurements, reported to the project manager, will include the amount of time spent by each person
involved in the review, including preparation for the review.




                                                     B-13
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


B.6 EVALUATE PROJECT CONTROL PROCESS
QA shall evaluate successful implementation of Project Control Process:
    a. Corrective action is defined and directed, when project achievement is not meeting planned
       targets.
    b. The project schedules and records action to authorize progress (or not) from one scheduled
       milestone or event to the next.
    c. Project objectives, when achieved, are recorded.
    d. Project re-planning is initiated when project objectives or constraints have changed, or when
       planning assumptions are shown to be invalid.
Figure B-5 provides a checklist to use to audit the project control process.


                        PROJECT CONTROL PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____When required, project management initiates corrective actions needed to achieve the goals and
    outputs of project tasks that have deviated outside acceptable or defined limits.

____Project management initiates preventive actions, as appropriate, to ensure achievement of the goals
    and outputs of the project.

____Project management initiates problem resolution actions to correct non-conformance.

____Project management adapts the scope, definition and related breakdown of project tasking in
    response to corrective actions taken (project re-planning).

____Project management initiates change actions to update plans, procedures and schedules to reflect re-
    planning requirements.

____Project management authorizes the project to proceed toward the next milestone or event when
    justified.

                               Figure B-5. Project Control Process Audit Checklist




                                                    B-14
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



B.7 EVALUATE DECISION-MAKING PROCESS
QA activities are listed below:
    a. Verify that a decision-making strategy is defined and documented
    b. Verify alternative courses of action are defined and analyzed
    c. Verify a preferred course of action is selected
    d. Verify the resolution, decision rational and assumptions are captured and reported.
Figure B-6 provides a checklist to use to audit the project decision-making process.


               PROJECT DECISION-MAKING PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has defined and documented a decision-making strategy.

____The decision-making process involves relevant stakeholders.

____The criteria for requiring the decision-making process is identified and documented.

____A decision-making strategy is selected and declared for each decision situation, with desired
    outcomes and measurable success criteria established.

____The project evaluates the balance of consequences of alternative actions, using the defined decision-
    making strategy, to arrive at an optimization of, or an improvement in, an identified decision situation.

____The project records, tracks, evaluates and reports decision outcomes to confirm that problems have
    been effectively resolved, adverse trends have been reversed and advantage has been taken of
    opportunities.

____The project maintains records of problems and opportunities and their disposition, as stipulated in
    organizational procedures and in a manner that permits auditing and learning from experience.

                          Figure B-6. Decision-Making Process Audit Checklist




                                                  B-15
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.8 EVALUATE RISK MANAGEMENT PROCESS
QA activities are listed below:
    a. Verify project risks are identified and categorized
    b. Verify the probabilities and consequence of risks are quantified
    c. Verify a strategy to treat each risk is specified
    d. Verify risk status is available and communicated
    e. Verify risks that have become unacceptable are acted upon.
Figure B-7 provides a checklist to use to audit the project risk management process.


                        RISK MANAGEMENT PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has documented a Risk Management Process that provides a systematic approach for
    risk identification, assessment and treatment.

____The project identifies and defines risks.

____The project determines the probability associated with risk occurrence using the established risk
    criteria.

____The project evaluates the risks in terms of their possible consequences using the established criteria.

____The project prioritizes the risks in terms of their probability and consequences.

____The project determines and documents risk treatment strategies.

____The project defines a threshold of acceptability for each identified risk.

____The project identifies risk treatment actions to follow if the threshold of acceptability is reached.

____The project communicates the risk treatment actions and their status in accordance with the
    agreement, policies and procedures.

____The project maintains a register of project risks throughout the life cycle.

                              Figure B-7. Risk Management Process Audit Checklist




                                                   B-16
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]



B.9 EVALUATE CONFIGURATION MANAGEMENT PROCESS
CM is the discipline that applies technical and administrative direction and surveillance to (1) identify and
document the functional and physical characteristics of CIs, (2) control the changes to CIs and their
related documentation, (3) record and report information needed to manage CIs effectively, including the
status of proposed changes and the implementation status of approved changes, and (4) audit the CIs to
verify conformance to specifications, interface control documents, and other contract requirements.
QA activities are listed below:
    a. Verify that configuration identification of documents, code, and computer data has established
       standards for titling, naming, and describing change status.
    b. Verify that baseline management of changes to the developmental baseline (including documents,
       code and computer data) are identified, reviewed, implemented, and incorporated in accordance
       with established procedures.
    c. Verify configuration control of changes to baseline documents and software are being managed in
       accordance with CM requirements as stated in the CM Plan.
    d. Verify configuration status accounting reports are prepared at established times, are prepared in
       accordance with established procedures, and report the status of items that are significant with
       respect to the management of the configuration of the product and documentation.
    e. Verify that the personnel assigned to participate in the configuration audits comply with the CM
       Plan.
    f.   Verify for document control that only approved, up-to-date documentation is provided for use by
         project personnel, and that the document distribution process results in receipt of correct
         documentation.
    g. Verify that a designated configuration support library is the single place of storage for the baseline
       version of all products. Verify that the identification of all products includes the product name and
       a unique version identifier. The evaluation shall also determine that control of access to products
       is being properly exercised and that unauthorized changes to master files cannot occur.
Figure B-8 provides a checklist to use to audit the project configuration management process.




                                                   B-17
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




              CONFIGURATION MANAGEMENT PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. CM Plan

____Project follows the organizational policy for implementing CM.

____Group responsible for coordinating and implementing CM for the project exists.

____A documented and approved CM Plan is used as the basis for performing CM activities.

____Configuration control of changes to baseline hardware, documents and software are managed in
    accordance with the CM Plan.

____A configuration management library system is established as the repository for the software baseline,
    supporting documentation, drawings, and hardware configuration control.

____The CM library is the single place of storage for the baseline version of all products.

____Access to products in the CM library is in accordance with the Library Control procedures.

____Work products to be placed under CM are identified according to the CM Plan.

____Change Control Board (CCB) exists and implements CCB procedures.

____Change request and problem reports for all configuration items are handled in accordance with the
    Change Request (CR) procedure.

____Changes to baselines are controlled according to the CM Plan, CCB procedure, and CR procedure.

____Products from the configuration baseline library are created and their release is controlled according
    to the Library Control procedures.

____Configuration status accounting reports are prepared in accordance with the CM plan.

                        Figure B-8. Configuration Management Process Audit Checklist




                                                  B-18
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]


        CONFIGURATION MANAGEMENT PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Part 2. Configuration Identification

____Product Baselines and the Developmental Library can be identified.

     ____If yes, verify that the project describes the method used to identify the Baselines and the
         Developmental Library.

     ____Verify that the project lists the documents that comprise the Baselines and Developmental
         Library.

____The documentation and the computer storage media containing code, documentation, or both can be
    identified.

     ____If yes, verify that a documented process describes the method used to identify the
         documentation and the computer storage media and list the documents that are placed under
         configuration control.

____Each CI and its corresponding components can be identified.

     ____If yes, verify that a documented process describes the method used to identify them.

____A method is used to identify the name, version, release, change status, and any other identification
    details of each deliverable item.

     ____If yes, describe the method used.

     ____For each customer, identify the deliverable item, version, release, and change status being used.

____A method is used to identify the version of each CI to which the corresponding documentation
    applies.

     ____If yes, verify that the project process describes the method used.

     ____Verify that the project lists the SRS and SDD for each CI.

____A method is used to identify the specific version of software contained on a deliverable medium,
    including all changes incorporated since its previous release.

           ____If yes, verify that the project describes the method used.

____Verify that the project deliverable medium matches the CM masters. List any discrepancies.



                                                 B-19
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


                Figure B-8. Configuration Management Process Audit Checklist (Continued.)




                                                B-20
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]




        CONFIGURATION MANAGEMENT PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Part 3. Configuration Control

____An established plan for performing configuration control exists.

____If yes, there is a method to establish a Developmental Library for each CI.

     ____If yes, verify the project process describes the method used.

____Verify the project lists the CIs in the Developmental Library.

____Verify that a method exits to maintain current copies of the deliverable documentation and code.

     ____If yes, verify project processes describe the method used.

     ____Verify that the project lists the current copies. List all discrepancies.

____Verify that a method exits to control the preparation and dissemination of changes to the master
    copies of deliverable hardware, software and documentation.

     ____If yes, verify the project process describes the method used.

____Master copies of deliverables reflect only approved changes. List any discrepancies.

     ____List the changes in current deliverable hardware/software/documents.

Part 4. Configuration Status Accounting

____A documented plan for implementing and performing configuration status accounting exists.

____There are status reports on all products comprising the Developmental Libraries and the Functional
    Allocated and Product Baselines.

____Proposed and implemented changes to a CI and its associated configuration identification documents
    are recorded and reported.

____If yes to two out of three, answer the following. If not, then go to Part 5.

               Figure B-8. Configuration Management Process Audit Checklist (continued)




                                                  B-21
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




         CONFIGURATION MANAGEMENT PROCESS AUDIT CHECKLIST (cont)
Project:
Date:
Prepared by:
Part 4. Configuration Status Accounting (cont)

____Describe the method used to provide traceability of changes to controlled products.

____Describe the method used for communicating the status of configuration identification and associated
    hardware, software and supporting documentation.

____Describe the method for ensuring that delivered documents describe and represent the associated
    hardware and/or software.

Part 5. Engineering Change Proposals

____Engineering Change Proposals (ECPs) are prepared in accordance with the appropriate standard.

____Specification Change Notices (SCNs) are prepared in accordance with the appropriate standard.

____Describe the method used for handling requested changes to the CI.

____Describe the method used to authorize SCNs and ECPs.

                 Figure B-8. Configuration Management Process Audit Checklist (continued)




                                                 B-22
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]



B.10 EVALUATE PRODUCT DEVELOPMENT LIBRARY CONTROL PROCESS
Guidance
Tailor this evaluation and the attached checklist to reflect the actual contents of the Product
Development Library as described in the Project Management Plan or Configuration Management
Plan
The PDL functions as the main control point for CM. The [[Project Title]] PDL contains List the
primary categories of components, hardware, software, drawings, documentation or other elements
contained within the PDL (tailor as appropriate). The PDL also contains previous versions of the
operational system in the form of (describe the media used to archive previous versions of the system,
e.g. CDROM, DVD, concept models, prototypes, etc.).
QA activities are listed below:
    a. Verify the establishment of the PDL and procedures to govern its operation.
    b. Verify that documentation and computer program materials are approved and placed under library
       control.
    c. Verify the establishment of formal release procedures for CM approved documentation and
       product versions.
    d. Verify that library controls prevent unauthorized changes to the controlled products and verify the
       incorporation of all approved changes.
Figure B-9 provides a checklist to use to audit the Product Development Library Control Process.




                                                 B-23
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




   PRODUCT DEVELOPMENT LIBRARY CONTROL PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Establishment of PDL Environment and Control

____The PDL is established and procedures to govern its operation exist.

____The PDL provides a positive means for recognizing related elements (i.e., those versions that
    constitute a particular baseline and protecting the product against destruction or unauthorized
    modification).

____Documentation and computer program materials approved by the CCB are placed under library
    control.

____All hardware, software, tools, and documentation relevant to the product development are placed
    under library control.

____Published procedures/standards for the PDL exist.

____PDL procedures include identification of persons/organization responsible for receiving, storing,
    controlling, and disseminating library materials.

____Verify access to PDL is limited to authorized personnel.

      ____If yes, describe the procedures used to limit access.

____Safeguards are in place to assure that no unauthorized alterations are made to controlled material.

      ____If yes, describe those safeguards.

      ____Describe or list the materials to be controlled.

      ____Describe how the materials are approved and placed under control:

      ____Describe how changes to the product components are handled and how changes to lines of
          code or hardware or documentation elements are identified.

____The PDL contains master copies of each CI under configuration control.

                  Figure B-9. Product Development Library Control Process Audit Checklist



                                                   B-24
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




   PRODUCT DEVELOPMENT LIBRARY CONTROL PROCESS AUDIT CHECKLIST
                              (cont)

Project:
Date:

Prepared by:

Part 1. Establishment of PDL Environment and Control (cont)

____Periodic back up of the Library System software is performed to prevent loss of information due to
    any failure of the Development Library System.

     ____If yes, describe the backup procedure and frequency of backups.

Part 2. Assurance of Controlled Material Validity

____Duplications from controlled and tested master copies are verified before delivery as exact copies.

____All deliverable products that are duplicated from controlled and tested master copies are compared
    with that master copy to assure exact duplication.

____Describe how identification numbers and revision codes are assigned to controlled hardware,
    documents and software.

____Describe the way releases of controlled materials are recorded.

____List the people or organization responsible for assurance of product media validity.

____A formal release procedure exists. If so, describe it.

____The material contained in the library is promptly and correctly updated when a change to any of
    these materials is authorized.

           Figure B-9. Product Development Library Control Process Audit Checklist (continued)




                                                 B-25
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.11 EVALUATE MEDIA CERTIFICATION PROCESS
Guidance
Tailor this evaluation to represent the actual project products
For software products, QA shall verify that CM certifies that the media containing the source code, and
the media containing the object code of software products which are delivered to the procuring agency,
correspond to one another. QA shall verify also that the product version represented by this media
matches that on which product performance testing was performed, or correctly represents an authorized
update of the product, as applicable.
For hardware products, QA shall verify that CM certifies that the media containing all product technical
and user documentation corresponds to the product baseline of the hardware end-item being supported by
the media. QA shall verify also that the hardware version represented by the media matches that on
which hardware performance testing was performed, or correctly represents an authorized update of the
product, as applicable.
Figure B-10 provides a checklist to use to audit the project media certification process.




                                                  B-26
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




                 MEDIA CERTIFICATION PROCESS AUDIT CHECKLIST
Project:
Date:
Prepared by:
Procedures:

Part 1a. Media Production

(For software products)

____Media containing source code and media containing the object code that are delivered correspond to
    one another.

____A documented process that is used to implement production of media from the software library
    exists.

    ____If not, a plan is being created or a reason why one is not needed is being documented. Skip to
        Part 2.

    ____The plan was followed in production of media.

    ____CM personnel created software from correct files in the software library.

    ____CM personnel created documents from approved master copies.

Part 1b. Media Production

(For hardware products)

____Media containing hardware documentation corresponds with the version of the hardware supported.

____A documented process that is used to implement production of media from the CM library exists.

    ____If not, a plan is being created or a reason why one is not needed is being documented. Skip to
        Part 2.

    ____The plan was followed in production of media.

    ____CM personnel created documentation from correct files in the CM library.

    ____CM personnel created documents from approved master copies.

                          Figure B-10. Media Certification Process Audit Checklist




                                                  B-27
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                 MEDIA CERTIFICATION PROCESS AUDIT CHECKLIST (cont)
Project:
Date:
Prepared by:

Part 2. Media Labeling

____There is a documented standard that is followed in labeling the media.

      ____If yes, describe the standard method used to identify the product, version, and Configuration
          Identification Number.

____Media is clearly labeled.

____The label contains all required information (product, version, and Configuration Identification
    Number).

____If hardware/software is classified; the media clearly reflects the correct classification.

____Supporting documents are clearly labeled with product, CIN, and version number, if applicable.

Part 3. Media Contents

____A listing of contents on the media exits.

____If yes, describe where the listing is located.

____The media contains the contents specified in the listing.

____The contents of the media match the label information, i.e., is it the correct version for the correct
    hardware platform?

____The documents contain all change pages required for this version of the documents.

                     Figure B-10. Media Certification Process Audit Checklist (continued)




                                                     B-28
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]



B.12 EVALUATE INFORMATION MANAGEMENT PROCESS
QA activities are listed below:
    a. Verify that information to be managed is identified
    b. Verify that the forms of the information representations are defined
    c. Verify that information is transformed and disposed of as required
    d. Verify that the status of information is recorded
    e. Verify information is current, complete and valid
    f.   Verify information is made available to designated parties.
Figure B-11 provides a checklist to use to audit the project information management process.




                                                  B-29
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




               INFORMATION MANAGEMENT PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project identifies the information to be managed, and specifies the period for maintaining the
    information.

____The project designates authorities and responsibilities regarding the origination, generation, capture,
    archiving and disposal of items of information.

____The project defines the rights, obligations, and commitments regarding the retention of, transmission
    of and access to information items.

____The project defines the content, semantics, formats and medium for the representation, retention,
    transmission and retrieval of information.

____The project has obtained all of the identified items of information.

____The project maintains information items and their storage records according to integrity, security and
    privacy requirements.

____The project defines information maintenance actions.

____The project retrieves and distributes information to designated parties as required by agreed
    schedules or defined circumstances.

____The project provides classified information in accordance with the appropriate governing standards or
    guidelines for management of classified information.

____The project archives designated information, in accordance with the audit and knowledge retention
    purposes.

____The project disposes of unwanted, invalid or unverifiable information according to governing
    organization policy, security and privacy requirements.

                         Figure B-11. Information Management Process Audit Checklist




                                                  B-30
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]




B.13 EVALUATE SYSTEM REQUIREMENTS DEFINITION AND ANALYSIS PROCESS
QA activities are listed below:
    a. Verify that the required characteristics and context of use of the product are specified.
    b. Verify that the constraints on a system solution, and the means to realize these constraints, are
       defined.
    c. Verify that the required characteristics, attributes, and functional and performance requirements
       for a product solution are specified.
    d. Verify the integrity and traceability of stakeholder requirements to stakeholders and their needs.
    e. Verify that the basis for defining the system requirements is defined.
    f.   Verify that the basis for validating the conformance of the products is defined.
    g. Verify a Statement of Work or similar documented agreement to supply the product is provided.
Figure B-12 provides a checklist to use to audit the project system requirements definition and analysis
process.




                                                   B-31
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




        SYSTEM REQUIREMENTS DEFINITION AND ANALYSIS PROCESS AUDIT
                              CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The correct participants are involved in the systems requirements definition and analysis process to
    identify all user needs.

____Requirements are reviewed to determine if they are feasible to implement, clearly stated, and
    consistent.

____Changes to allocated requirements, work products, and activities are identified, reviewed, and
    tracked to closure.

____Project personnel involved in the system requirements definition and analysis process are trained in
    the necessary procedures and standards applicable to their area of responsibility to do the job
    correctly.

____The commitments resulting from allocated requirements are negotiated and agreed upon by the
    affected groups.

____The commitments are documented, reviewed, accepted, approved and communicated.

____Allocated requirements identified as having potential problems are reviewed with the group
    responsible for analyzing system requirements and documents, and necessary changes are made.

____The prescribed processes for defining, documenting, and allocating requirements are followed and
    documented.

____A CM process is in place to control and manage the baseline.

____Requirements are documented, managed, controlled, and traced (preferably via a matrix).

____If provided, documented requirements traceability is both forward and backward traceable.

____The agreed upon requirements are addressed in the PMP.

             Figure B-12. System Requirements Definition and Analysis Process Audit Checklist




                                                 B-32
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



B.14 EVALUATE SOFTWARE REQUIREMENTS DEFINITION AND ANALYSIS
PROCESS
QA activities are listed below:
    a. Verify that the software requirements definition and analysis process and associated requirements
       reviews are conducted in accordance with the standards and procedures established by the project
       and as described in the PMP.
    b. Verify that action items resulting from reviews of the software requirements analysis are resolved
       in accordance with these standards and procedures.
Figure B-13 provides a checklist to use to audit the project software requirements definition and analysis
process.




                                                  B-33
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




     SOFTWARE REQUIREMENTS DEFINITION AND ANALYSIS PROCESS AUDIT
                            CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Software Requirements
____Software requirements are documented in a Software Requirements Specification (SRS) or other
    approved format and are included in a traceability matrix.

____The SRS is maintained under configuration management.

____The SRS changes undergo a peer review before they are incorporated into the requirements
    baseline.

____Ensure that the peer review validates testability of requirements and that appropriate metrics are
    established to validate measurable performance requirements.

____Project management plans, work products, and activities are changed to be consistent with changes
    to the software requirements.

____Software requirements analysis techniques are consistent with the PMP.

____Automated tools acquired to manage software requirements trouble reports and change requests are
    correctly used.

____Software engineering group is trained to perform requirements management activities.

____Measurements are made and used to determine the status of requirements management.

Part 2. Interface Requirements

____Interface requirements are documented in an Interface Requirements Specification (IRS) or other
    approved format.

____The IRS is maintained under configuration management.

____The IRS changes undergo peer review before they are incorporated into the requirements baseline.

____Project management plans, work products, and activities are changed to be consistent with changes
    to the interface requirements.

____Automated tools are used to manage interface requirements trouble reports and change requests.



                                                 B-34
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]


____Software engineering group is trained to perform requirements management activities.

           Figure B-13. Software Requirements Definition and Analysis Process Audit Checklist

B.15 EVALUATE SYSTEM ARCHITECTURAL DESIGN PROCESS
QA activities are listed below:
    a. Verify that an architectural design baseline is established.
    b. Verify that an implementable set of system element descriptions that satisfy the requirements for
       the system are documented.
    c. Verify that interface requirements are incorporated into the architectural design solution.
    d. Verify the traceability of architectural design to system requirements is established.
    e. Verify that a basis for verifying the system elements is defined.
    f.   Verify that a basis for the integration of system elements is established.
Figure B-14 provides a checklist to use to audit the project system architectural design process.


           SYSTEM ARCHITECTURAL DESIGN PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____System design documents and the traceability matrix are prepared and kept current and consistent.

____Relevant system design documents are updated based on approved requirements changes.

____Design walkthroughs (peer reviews) evaluate compliance of the design to the requirements, identify
    defects in the design, and alternatives are evaluated and reported.

____QA attends a sample set of design walkthroughs. All walkthroughs are conducted.

____Defects are identified and resolved. Change control integrity is maintained.

____The content of system design documents is selectively reviewed and audited.

____Lack of compliance with standards is identified and corrective actions are determined.

____Requirements and accompanying design and tools conform to standards, and needed waivers are
    obtained prior to continuing software development.

____Demonstration prototypes comply with requirements and standards.



                                                   B-35
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


____The demonstration conforms to standards and procedures.

____The status of design milestones is reviewed.

                       Figure B-14. System Architectural Design Process Audit Checklist

B.16 EVALUATE SOFTWARE ARCHITECTURAL DESIGN PROCESS
QA activities are listed below:
    a. Verify that the software design process and associated design reviews are conducted in
       accordance with standards and procedures established by the project and as described in the
       PMP.
    b. Verify that action items resulting from reviews of the design are resolved in accordance with
       these standards and procedures.
    c. Evaluate the method used for tracking and documenting the development of a software unit to
       determine the method's utility as a management tool for assessing software unit development
       progress. Example criteria to be applied for the evaluation are the inclusion of schedule
       information, results of audits, and an indication of internal review and approval of its constituent
       parts.
    d. Verify that the method, such as the Software Development File (SDF) or Unit Development
       folder (UDF), used for tracking and documenting the development of a software unit is
       implemented and is kept current.
Figure B-15 provides a checklist to use to audit the project software architectural design process.




                                                   B-36
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]




           SOFTWARE ARCHITECTURAL DESIGN PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Software Design

____The following documents undergo peer review during this phase of development:
        ___Software Design Document
        ___Interface Design Document
        ___Software Test Plan (Test Ids, Test Cases)
        ___Software Programmers Manual
        ___Software Test Description
        ___Firmware Support Manual

____The following modified documents are placed under CM during this phase of development:
        ___Software Design Document
        ___Interface Design Document
        ___Software Test Plan (Test Ids, Test Cases)
        ___Software Programmers Manual
        ___Software Test Description
        ___Firmware Support Manual

____Design documents and the traceability matrix are prepared and kept current and consistent based on
    approved software requirement changes.

____Design walkthroughs evaluate compliance of the design to the requirements, identify defects in the
    design, and alternatives are evaluated and reported.

____Design walkthroughs are conducted in accordance with Peer Review Process.

____Changes to the software design are identified, reviewed, and tracked to closure.

____Software design is consistent with the design methodology approved in the PMP.


                   Figure B-15. Software Architectural Design Process Audit Checklist


                                                B-37
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




      SOFTWARE ARCHITECTURAL DESIGN PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Procedures:

Part 1. Software Design (cont)

____The method, such as the Software Development Folder or Unit Development Folder, used for
    tracking and documenting the development/maintenance of a software unit is implemented and is kept
    current.

Part 2. Interface Design

____Interface Requirements are documented in an Interface Design Document (IDD) or other approved
    format.

____The IDD is maintained under configuration management.

____The IDD changes undergo peer review.

              Figure B-15. Software Architectural Design Process Audit Checklist (continued)




                                                 B-38
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]



B.17 EVALUATE HARDWARE IMPLEMENTATION PROCESS
QA activities are listed below:
    a. Verify the project has defined a hardware implementation strategy.
    b. Verify that constraints are identified that the implementation strategy and implementation
       technology impose on the design solution.
    c. Verify the project realizes or adapts system elements using the implementation enabling systems
       and specified materials according to the defined implementation procedures for hardware
       fabrication, testing and/or operator training.
    d. Verify that recorded evidence exists that the system element meets supplier agreements, specified
       standards and applicable organization policies.
    e. Verify that the project packages the system element and stores the element as appropriate.
Figure B-16 provides a checklist to use to audit the project hardware implementation process.




                                                 B-39
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




               HARDWARE IMPLEMENTATION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has a defined implementation strategy that addresses:

      ____Implementation procedures

      ____Fabrication processes

      ____Tool and equipment requirements

      ____Implementation tolerances and verification uncertainties

      ____(For planned mass produced system elements) Fabrication processes are defined to achieve
          consistent and repeatable producibility

___The project has identified constraints to the implementation strategy that address:

      ____Current or anticipated limitations of the chose implementation technology

      ____Acquirer furnished materials

      ____System elements that require adaptation

      ____Limitations resulting from the use of required implementation enabling systems

____The project realizes or adapts system elements using the implementation enabling systems and
    specified materials in accordance with the defined implementation procedures that include:

      ____Adherence with standards that govern applicable safety, security, privacy and environmental
          guidelines, or legislation that governs the practices of the relevant implementation technology

      ____Fabricating hardware elements using the conditioning, forming and fabrication techniques
          relevant to the physical implementation technology and materials selected

      ____Hardware testing in conformance with specified product quality characteristics

                        Figure B-16. Hardware Implementation Process Audit Checklist




                                                  B-40
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]




         HARDWARE IMPLEMENTATION PROCESS AUDIT CHECKLIST (cont)

Procedures (continued):

____Where appropriate, operator training to perform tasks in accordance with required performance
    standards and operational procedures is provided.

____Where appropriate, operator training satisfies the required range and level of competence required
    for operation of the hardware element.

____Documented evidence exists that the system element meets supplier agreements, complies with
    established standards and organizational policy.

____The system element is packaged and stored as appropriate, in conformance with required
    maintainability, safety, and security requirements.

              Figure B-16. Hardware Implementation Process Audit Checklist (continued)




                                                B-41
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




B.18     EVALUATE SOFTWARE IMPLEMENTATION PROCESS
QA activities are listed below:
    a. Verify that the coding process, associated code reviews, and software unit testing are conducted
       in conformance with the standards and procedures established by the project and as described in
       the Project Management Plan (PMP) or Software Development Plan (SDP).
    b. Verify that action items resulting from reviews of the code are resolved in accordance with these
       standards and procedures.
    c. Verify that the SDF used for tracking and documenting the development of a software unit is
       implemented and is kept current.
Figure B-17 provides a checklist to use to audit the project software architectural design process.




                                                  B-42
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




             SOFTWARE IMPLEMENTATION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Software Implementation

____Code and the traceability matrix are prepared and kept current and consistent based on approved
    software requirement changes.

____Code walkthroughs (peer review) evaluate compliance of the code to the approved design, identify
    defects in the code, and alternatives are evaluated and reported.

____Code walkthroughs are conducted in accordance with Peer Review Process.

____Changes to code are identified, reviewed, and tracked to closure.

____Code is maintained under configuration management.

____Code changes undergo peer review before they are incorporated into the software baseline.

____Software coding is consistent with the coding methodology approved in the Software Development
     Plan (SDP) or PMP.

____The method, such as the Software Development Folder or Unit Development Folder, used for
    tracking and documenting the development/maintenance of a software unit is implemented and is kept
    current.

Part 2. Unit Testing

____Software unit testing is conducted in conformance with the approved standards and procedures
    described in the SDP or PMP.

____Ensure that passing criteria for unit test is documented, and that compliance has been recorded.

____Results of unit testing are documented in the Software Development Folder or Unit Development
    Folder.

                       Figure B-17. Software Implementation Process Audit Checklist




                                                 B-43
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.19 EVALUATE PRODUCT INTEGRATION AND VERIFICATION PROCESS
QA shall verify that product integration and test activities combine individually developed components
together in the development environment to verify that they work together to complete system
functionality. For joint hardware and software development, integration requires close synchronization of
hardware and software to meet designated integration and test milestones.
QA activities are listed below:
    a. Verify that product test activities are identified, test environments have been defined, and
       guidelines for testing have been designed. QA will verify the product integration process,
       integration testing activities and performance testing activities are being performed in accordance
       with the PMP, SDP, the system architectural design, the plan for testing, and established
       standards and procedures.
    b. Verify any transfer of control of the product to personnel performing integration testing or
       performance testing is being accomplished in accordance with established standards and
       procedures.
    c. Verify that as many of the integration tests as necessary and all of the performance tests are
       witnessed to verify that the approved test procedures are being followed, that accurate records of
       test results are being kept, that all discrepancies discovered during the tests are being properly
       reported, that test results are being analyzed, and the associated test reports are completed.
    d. Verify that discrepancies discovered during product integration and performance tests are
       identified, analyzed, documented, and corrected; unit tests, and product integration tests are re-
       executed as necessary to validate corrections made to the product; and the system unit’s design,
       architecture, and testing is updated based on the results of product integration testing, performance
       testing, and corrective action process.
    e. Verify that the performance tests produce results that will permit determination of performance
       parameters of the system element.
    f.   Verify that the responsibility for testing and for reporting on results has been assigned to a specific
         organizational element.
    g. Verify that procedures are established for monitoring informal testing.
    h. Review the Test Plan and Test Descriptions for compliance with requirements and standards.
    i.   Verify that the product is tested.
    j.   Monitor test activities, witness tests, and certify test results.
    k. Verify that requirements have been established for the certification or calibration of all support
       software or hardware used during tests.
Figures B-18 and B-19 provide checklists to use to audit the product integration and verification process.




                                                     B-44
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




            UNIT INTEGRATION AND TESTING PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Configuration Identification

____The CIs are integrated under change control. If not, go to Part 2; otherwise, continue.

____The CIs integrated into the system were obtained from an authorized Configuration Management
    representative in accordance with the PMP or SDP.

____The baseline versions of each CI are integrated into the system.

____All CI components of software integration are under change control in accordance with the CM
    Plan.

____If yes, describe how they are identified.

Part 2. Integration Process

____A plan for the integration of the product CIs (including, as appropriate, all hardware and software
    CIs) exists.

____The plan specifies the order and schedule in which the CIs are integrated.

____The CIs are integrated in accordance with the schedule and in the specified order.

____The integration plan specifies which version of each CI is to be integrated.

____The correct version is integrated.

____The integrated CIs have completed unit testing.

____Any required corrections have been completed.

        ____The CIs have been retested.

____Test procedures are defined for CI integration.

____The defined procedures are followed.

                   Figure B-18. Unit Integration and Testing Process Audit Checklist



                                                 B-45
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




           UNIT INTEGRATION AND TESTING PROCESS AUDIT CHECKLIST (cont)
Project:
Date:
Prepared by:
Procedures:

Part 2. Integration Process (cont)

____Test cases are defined.

____The defined test cases are followed.

____Test pass/fail criteria are defined.

____The defined test pass/fail criteria are followed.

____The test results are documented.

                Figure B-18. Unit Integration and Testing Process Audit Checklist (continued)




                                                  B-46
                                                                                         [[Project Title]] QA Plan
                                                                              [[Document Configuration Identifier]]
                                                                                               [[Document Date]]




     CI INTEGRATION TESTING, AND SYSTEM QUALIFICATION PROCESS AUDIT
                                CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Test Plan

____An approved test plan and test descriptions exist.

____The plan and descriptions used are under configuration management control.

____The latest version of the plan and description are used.

Part 2. Testing Process

____The system element tested was received from an authorized configuration management source.

____The test environment, including both hardware and software requirements, is set up as required by
    the test plan.

____The tests were performed in the correct order.

____Each test case in the test description was executed.

____The system is tested after each CI is integrated.

____Test-passing criteria is documented and compliance is recorded.

____The results of the tests are recorded in a test report.

____If yes, describe the information that is recorded and where it is recorded.

____CIs are retested after integration to assure they still satisfy their requirements without interference
    from remainder of system.

____The system that results from integration of each CI is placed under configuration management
    control.

____If yes, describe how it is identified.

           Figure B-19. CI Integration Testing and System Qualification Process Audit Checklist




                                                  B-47
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




      CI INTEGRATION TESTING, AND SYSTEM QUALIFICATION PROCESS AUDIT
                               CHECKLIST (cont)

Project:
Date:
Prepared by:
Part 3. Trouble Reporting

____The discrepancies found are entered into the Configuration Management system for change control.
    If not, describe where they are they recorded.

____The entries are completed at the time the discrepancies are found.

____The reported discrepancy reference number is kept in the test file. If not, describe where it is kept.

____Discrepancy/Trouble Reports are written when problems are found in the test environment, test plan,
    test descriptions, or test cases.

____These Discrepancy/Trouble Reports are sent through the same change control process as product
    discrepancies.

Part 4. Modifications

____Are modifications or corrections made to the test environment during testing?

____If yes, were the modifications approved through the change control process prior to implementation?

      ____What documentation of the modifications exists?

      ____What are the changes?

____Are modifications or corrections made to the test descriptions during testing?

____If yes, were the modifications approved by the change control process prior to implementation?

      ____What documentation of the modifications exists?

      ____What is the approving CCB date? _______________________

      ____What is the STD change release date? _______________________

____Were the change control procedures in the CM Plan followed?

      ____If no, what are the changes?

Part 5. Completion Criteria

____All specified CIs have been integrated into the system.

    Figure B-19. CI Integration Testing and System Qualification Process Audit Checklist. (continued)


                                                 B-48
                  [[Project Title]] QA Plan
       [[Document Configuration Identifier]]
                        [[Document Date]]




B-49
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




    CI INTEGRATION TESTING, AND SYSTEM QUALIFICATION PROCESS AUDIT
                             CHECKLIST (cont)

Project:
Date:

Prepared by:

Part 5. Completion Criteria. (cont)

____All test cases have been executed on the system.

____All Discrepancy Reports are closed out.

____If not, all outstanding Discrepancy Reports are properly documented in the VDD.

____The Test Report has been completed and approved.

____The Test Report has been placed under change control.

____The appropriate authority has determined whether the system passed or failed integration testing.

      ____List the individual or group that determined whether the system passed or failed.

      ____Describe how the pass or fail determination was made.

      ____The system element is ready to be integrated with the operational system.

Part 6. Software Development Files/Engineering Notebooks

____The Test Report includes any retests due to product failures.

      ____If yes, list the failures with their corresponding Trouble Report reference numbers.

      ____Using the Trouble Report CM system, list all the CIs changed due to these failures.

____All the software development files or engineering notebooks (as appropriate) of the listed CIs were
    updated in accordance with the PMP or SDP.

      ____If not, list all software development files or engineering notebooks that were not updated.

    Figure B-19. CI Integration Testing and System Qualification Process Audit Checklist. (continued)




                                                  B-50
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




     CI INTEGRATION TESTING, AND SYSTEM QUALIFICATION PROCESS AUDIT
                              CHECKLIST (cont)
Project:
Date:
Prepared by:

Part 7. Test Report Accuracy

____The Test Report supplies the Configuration Identification Number (CIN) for all test documents and
    hardware and/or software. If not, the Test Report is incomplete.

____The tester can run the evaluation tests with the specified CINs? If not, the Test Report is
    inaccurate.

____The results of these tests match the Test Report? If not, the Test Report is inaccurate.

   Figure B-19. CI Integration Testing and System Qualification Process Audit Checklist. (continued)




                                                 B-51
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.20 EVALUATE TRANSITION PROCESS
QA activities are listed below:
    a. Verify that a transition strategy is defined.
    b. Verify that a system is installed in its operational location, or as specified in agreements.
    c. Verify that the system, when operated, is capable of delivering the required services.
    d. Verify that the installed system configuration is recorded.
    e. Verify that corrective action reports are recorded.
    f.   Verify that the delivered service is sustainable by enabling systems (i.e. operates correctly within
         the target environment).
Figure B-20 provides a checklist to use to audit the transition process.




                                                   B-52
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]




                          TRANSITION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Audits

____A functional audit was conducted, if required.

____A physical audit was conducted, if required.

Part 2. Package Generation

____The product is generated from the CM library in accordance with the PMP or SDP.

     ____If yes, the product is the latest version in the CM library.

     ____If not, why not?

____The documentation is generated from masters controlled by the Configuration Management
    personnel as required by the CM Plan.

Part 3. Delivery Package

____The product supporting media is labeled correctly, showing at a minimum product name, release date,
    and correct version number. The checklist in Figure B-10 contains more details on media labeling.

____Product labeling, including delivery location and product acceptance personnel, is accomplished.

____The Version Description Document is with the supporting media.

     ____If yes, the Version Description Document is the correct version for the product.

____The Version Description Document has been formally inspected.

____The User's Manual is with the supporting media.

     ____If yes, the User's Manual is the correct version for the product.

____The User's Manual has been formally inspected.

                             Figure B-20. Transition Process Audit Checklist




                                                  B-53
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                          TRANSITION PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Procedures:

Part 4. Product Distribution List

____A distribution list for the deliverable exists.

      ____If yes, it is complete, all organizations listed, all addresses correct and current.

      ____If yes, are any organizations listed that do not need to receive deliverable?

____Is the deliverable classified?

      ____If yes, the personnel on the distribution list have required clearance and need-to-know.

Part 5. Packaging

____The packaging material is suitable for the contents and transmission method used.

____Does package contain a signed transmittal letter?

      ____If yes, the transmittal information is correct.

____All contents are listed on transmittal contained in package.

____Does package include receipt acknowledgment form?

Part 6. Installation/Checkout

____Pre-installation site preparation is accomplished in accordance with documented plans and
    procedures.

____Product installation is conducted in accordance with documented plans and procedures.

____Product installation checkout testing is accomplished in accordance with agreements for operational
    verification testing, including verified witnessed and documented operational demonstration results.

                           Figure B-20. Transition Process Audit Checklist (continued)




                                                      B-54
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]




                      TRANSITION PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Procedures:

Part 7. Problem Notification

____There is a specified method for the receiving organization to notify the sender of problems and
    deficiencies in the package.

     ____If yes, describe the method.

____There is a specified method for logging and handling distribution problems. Describe it.

____A specific person is identified to handle distribution problems. Identify that person.

                       Figure B-20. Transition Process Audit Checklist (continued)




                                                  B-55
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.21 EVALUATE VALIDATION PROCESS
QA activities are listed below:
    a. Verify that a validation strategy is defined
    b. Confirm the validation of services required by the stakeholder
    c. Verify that validation data is provided
    d. Verify that data capable of providing information for corrective action is provided.
Figure B-21 provides a checklist to use to audit the validation process.


                              VALIDATION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has a defined strategy for validating services in the operational environment and
    achieving stakeholder satisfaction.

____A Validation Plan exists.

____Operators, enabling systems for validation and associated facilities are ready to conduct validation.

____Validation is conducted to demonstrate conformance of services to stakeholder requirements.

____The project makes available validation data on the system according to documented agreements.

____As appropriate to agreement terms or organizational guidelines, validation is conducted to isolate that
    part of the system that comprises a non-conformance.

____Validation data is analyzed, recorded and reported according to criteria defined in the validation
    strategy.

                                  Figure B-21. Validation Process Audit Checklist




                                                     B-56
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]



B.22 EVALUATE MAINTENANCE PROCESS
QA activities are listed below:
    a. Verify the project has a documented maintenance strategy
    b. Verify that maintenance constraints are provided as inputs to system requirements
    c. Verify that replacement system elements are made available
    d. Verify that services meeting stakeholder requirements are sustained
    e. Verify that the need for corrective design changes is reported
    f.   Verify that failure and lifetime data are recorded.
Figure B-22 provides a checklist to use to audit the maintenance process.


                         MAINTENANCE PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has a documented maintenance strategy.

____The project defines constraints on system requirements that are an unavoidable consequence of the
    maintenance strategy.
____The project obtains enabling systems, system elements and services to be used during maintenance
    of the system.
____The project has implemented problem reporting and incident recording to support future corrective,
    adaptive, perfective and preventive maintenance.
____The project has implemented procedures for correction of faults and/or scheduled replacement of
    system elements.
____Corrective action is initiated to remedy previously undetected design errors.
____Confirm that logistics actions satisfy the required replenishment levels so that stored system elements
    meet repair rates and planned schedules.
____The project performs preventive maintenance by replacing or servicing system elements prior to
    failure, in accordance with agreements and planned schedules.
____The project performs failure identification actions when a non-compliance has occurred in the
    system.
                            Figure B-22. Maintenance Process Audit Checklist




                                                   B-57
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.23 EVALUATE OPERATION PROCESS
QA activities are listed below:
      a. Verify that an operation strategy is defined
      b. Confirm that services that meet stakeholder requirements are delivered
      c. Ensure approved corrective action requests are satisfactorily completed
      d. Confirm that stakeholder satisfaction is maintained.
 Figure B-23 provides a checklist to audit the operation process.


                              OPERATION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____The project has a defined strategy for the operation of the system.

____If yes, does the strategy support the items listed below:

      ____The availability of services as they are introduced, routinely operated and withdrawn from
          service.

      ____The staffing strategy and schedules for operators.

      ____Where appropriate, the release and re-acceptance criteria and schedules of the system to
          permit modifications that sustain existing or enhance services.

____The project has documented, if appropriate, methods to obtain other services related to operation of
    the system

____The project has assigned trained, qualified personnel to be operators.

____The system has been activated in its intended operational situation to deliver instances of service or
    continuous service according to its intended purpose.

____The project has documented materials consumption, as required, to sustain the services.

____The project monitors operation to ensure that the system is operated in accordance with the
    operations plans, in a safe manner and compliant with guidelines concerning occupational safety and
    environmental protection.

                              Figure B-23. Operation Action Process Audit Checklist


                                                    B-58
                                                                                     [[Project Title]] QA Plan
                                                                          [[Document Configuration Identifier]]
                                                                                           [[Document Date]]




                     OPERATION PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Procedures:

____The project monitors system operation to confirm that service performance is within acceptable
    parameters.

____The project performs failure identification when a non-compliance has occurred in the delivered
    services.

____The project determines the appropriate course of action when corrective action is required to remedy
    failings due to changed need.

____The project introduces remedial changes to operating procedures, the operator environment, human-
    machine interfaces and operator training as appropriate when human error contributed to failure.

____The project continuously or routinely communicates with users to determine the degree to which
    delivered services satisfy their needs.

                     Figure B-23. Operation Action Process Audit Checklist (cont)




                                                B-59
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]



B.24 EVALUATE CORRECTIVE ACTION PROCESS
The corrective action process describes the steps for (1) problem identification and correction occurring
during product life cycle to verify detection of actual or potential problems, (2) reporting of the problem to
the proper authority, (3) analysis of the problem to propose corrective measures, (4) timely and complete
corrective action, and (5) the recording and follow-up of each problem's status. Problems in this context
include documentation errors, hardware and/or software errors, and noncompliance with standards and
procedures.
QA activities are listed below:
    a. Periodically review the corrective action process and their results against the CM Plan to assess
       the effectiveness of the corrective action process.
    b. Perform periodic analysis of all reported problems to identify trends that may disclose generic
       problem areas. These analyses shall include the study of the causes, magnitude of impact,
       frequency of occurrence, and preventive measures.
Figure B-24 provides a checklist to use to audit the corrective action process.




                                                   B-60
                                                                                    [[Project Title]] QA Plan
                                                                         [[Document Configuration Identifier]]
                                                                                          [[Document Date]]




                   CORRECTIVE ACTION PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

Part 1. Implementation of a closed loop Corrective Action (CA) Process

____The CA Process is a closed-loop.

____If yes, does the closed-loop CA Process verify the items listed below?

     ____All detected problems are promptly reported.

     ____All detected problems are entered into CA Process.

     ____Action is initiated on problems.

     ____Resolution is achieved.

     ____Status is tracked and reported.

     ____Records are maintained.

     ____Problem/change/discrepancy reports are the input.

____If the CA was not resolved with the Project Manager, the problem was escalated to the appropriate
    management personnel for resolution, and the final disposition was recorded and filed.

Part 2. Inputs to the Corrective Action Process

____A CA Process exists.                             Location:

____The CA Process is documented.                    Location:

____The CA Process is implemented.

Notes:




                        Figure B-24. Corrective Action Process Audit Checklist



                                                  B-61
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                  CORRECTIVE ACTION PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Part 3. Classification of Problems by Category and Priority

____Problems are classified by category. Categories include the following.

      ____Software Problem. The software does not operate according to supporting documentation and
          the documentation is correct.

      ____Hardware Problem. The hardware does not operate according to supporting documentation
          and the documentation is correct.

      ____Documentation Problem. The hardware/software does not operate according to supporting
          documentation but the hardware/software operation is correct.

      ____Design Problem. The hardware/software does not operate according to supporting
          documentation but a design deficiency exists.

____Problems are classified by priority. Priorities include the following.

      ____Priority 1: A problem that does one of the following:
            -    Prevents the accomplishment of an operational or mission essential capability specified in
                 the baseline requirements.
            -    Prevents the operator's accomplishment of an operational or mission essential capability.
            -    Jeopardizes personnel safety.

      ____Priority 2: A problem that does one of the following:
            -    Adversely affects the accomplishment of an operational or mission essential capability
                 specified in the baseline requirements so as to degrade performance and for which no
                 alternative work-around solution is known.
            -    Adversely affects the operator's accomplishment of an operational or mission essential
                 capability for which no alternative work-around solution is known.

      ____Priority 3: A problem that does one of the following:
            -    Adversely affects the accomplishment of an operational or mission essential capability
                 specified in the baseline requirements so as to degrade performance and for which an
                 alternative work-around solution is known.
            -    Adversely affects the operator's accomplishment of an operational or mission essential


                                                    B-62
                                                                     [[Project Title]] QA Plan
                                                          [[Document Configuration Identifier]]
                                                                           [[Document Date]]


capability for which an alternative solution is known.

    Figure B-24. Corrective Action Process Audit Checklist (continued)




                                    B-63
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                  CORRECTIVE ACTION PROCESS AUDIT CHECKLIST (cont)

Part 3. Classification of Problems by Category and Priority (cont)

      ____Priority 4: A problem that is an operator inconvenience or annoyance and which does not
          affect a required operational or mission essential capability.
      ____Priority 5: All other errors.

Part 4. Performance of Trend Analysis

____Analysis is performed to determine problem areas.

____Underlying factors/root causes are identified, categorized, and prioritized.

____Resources are expended in finding and treating root causes.

Part 5. Evaluation of Corrective Action taken

____Corrective actions are evaluated to verify the items listed below:

      ____Problems have been resolved.

      ____Adverse trends have been reversed.

      ____Changes have been correctly implemented.

      ____ No additional problems have been introduced.

NOTES:




                      Figure B-24. Corrective Action Process Audit Checklist (continued)




                                                   B-64
                                                                                        [[Project Title]] QA Plan
                                                                             [[Document Configuration Identifier]]
                                                                                              [[Document Date]]



B.25 EVALUATE DISPOSAL PROCESS
QA activities are listed below:
    a. Verify that a system disposal strategy is documented.
    b. Verify disposal constraints are provided as inputs to system requirements.
    c. Verify system elements are destroyed, stored, reclaimed or recycled in accordance with guidelines
       or regulations for safety, security, and/or environmental protection.
    d. Verify the disposal process returns the operational environment to its original or agreed to state.
    e. Verify that records allowing knowledge retention of disposal actions and the analysis of long-term
       hazards are available.
Figure B-25 provides a checklist to use to audit the disposal process.




                                                  B-65
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]




                                DISPOSAL PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____A disposal strategy exists for the system that includes each system element and any resulting waste
    products or addresses destruction of classified materials.

____The project communicates unavoidable constraints on the system design arising from the disposal
    strategy.

____The project acquires enabling systems or services to be used during disposal of a system.

____The system is properly deactivated to prepare it for removal from operation.

____The project withdraws operating staff from the system and records relevant operating knowledge.

____Where appropriate, the system is disassembled into manageable elements to facilitate its removal for
    reuse, recycling, overhaul or destruction.

____The system is removed from the operational environment for reuse, recycling, reconditioning
    overhaul or destruction.

____The project disposal strategy specifies containment facilities, storage locations, inspection criteria and
    storage periods if the system is to be stored.

____Where appropriate, the project secures destruction of the system, as necessary, to reduce the
    amount of waste treatment or to make the waste easier to handle.

____Where appropriate, project documentation is stored to support system reuse, or is destroyed in
    accordance with guidelines for the disposition of classified material.

____Where appropriate, confirm that no detrimental health, safety, security and environment factors exist
    following system or supporting element disposal.

____The project archives information gathered through the lifetime of the system to permit audits and
    reviews in the event of long-term hazards to health, safety, security and the environment, and to
    permit future system creators and users to build a knowledge base from past experiences.

                                   Figure B-25. Disposal Process Audit Checklist




                                                     B-66
                                                                                       [[Project Title]] QA Plan
                                                                            [[Document Configuration Identifier]]
                                                                                             [[Document Date]]



B.26 EVALUATE SUBCONTRACTOR CONTROL PROCESS
QA shall be responsible for ensuring that the quality of all products from subcontractors conforms to the
contract requirements and that the subcontractor's CM plan and procedures are being followed.
Figure B-26 provides a checklist to use to audit the subcontractor control process.


               SUBCONTRACTOR CONTROL PROCESS AUDIT CHECKLIST

Project:
Date:
Prepared by:
Procedures:

____A subcontract manager is designated to be responsible for establishing and managing the
    subcontract.

____Subcontract manager is trained to perform these activities.

____The work to be subcontracted is defined and planned according to a documented procedure.

____The subcontract SOW is reviewed and approved by the project manager, branch head, and division
    head.

____The subcontract SOW is managed and controlled.

____The subcontractor is selected according to a documented procedure.

____The contractual agreement between the prime contractor and the subcontractor is used as the basis
    for managing the subcontract. The contractual agreement documents the items listed below:

     ____The terms and conditions

     ____SOW

     ____Requirements for the products to be developed

     ____List of dependencies between subcontractor and prime

     ____Subcontracted products to be delivered to the prime

     ____Conditions under which revisions to products are to be submitted

     ____Acceptance procedures and acceptance criteria to be used in evaluating the subcontractor
         products before they are accepted by the prime



                                                  B-67
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


                           Figure B-26. Subcontractor Control Process Audit Checklist




                                                    B-68
                                                                                      [[Project Title]] QA Plan
                                                                           [[Document Configuration Identifier]]
                                                                                            [[Document Date]]




           SUBCONTRACTOR CONTROL PROCESS AUDIT CHECKLIST (cont)

Project:
Date:
Prepared by:
Procedures:

     ____Procedures and evaluation criteria to be used by the prime to monitor and evaluate the
         subcontractor’s performance

____Subcontractor’s project management plan is reviewed/approved by the prime.

____Approved subcontractor's PMP is used for tracking the subcontractor activities and communicating
    status.

____Changes to the subcontractor's SOW are resolved according to a documented procedure.

____Project manager conducts periodic status/coordination reviews with the subcontractor’s
    management.

____Periodic technical reviews and interchanges are held with the subcontractor.

____Formal reviews to address the subcontractor’s accomplishments and results are conducted at
    selected milestones.

     ____Reviews are documented in the SOW

     ____Reviews address status of subcontractor activities

     ____Significant issues, action items, and decisions are identified and documented

     ____Subcontractor risks are addressed

     ____Subcontractor’s PMP is refined as appropriate

____The prime contractor's quality assurance group monitors the subcontractor’s quality assurance
    activities.

____The prime contractor conducts acceptance testing of subcontractor products.

____Subcontractor’s performance is evaluated on a periodic basis, and reviewed with the subcontractor.

____Measurements are made and used to determine the status of the subcontract.

____The activities of the subcontract are reviewed by the Division Head on a quarterly basis.



                                                 B-69
[[Project Title]] QA Plan
[[Document Configuration Identifier]]
[[Document Date]]


                    Figure B-26. Subcontractor Control Process Audit Checklist (continued)




                                                   B-70
                             DOCUMENT CHANGE REQUEST (DCR)
Document Title: [[Project Title]] Quality Assurance Plan                            Tracking Number:


Name of Submitting Organization:


Organization Contact:                                                               Phone:


Mailing Address:


DCR Description:                                                                    Date:


Change Location:
(use section #, figure #, table #, etc.)
Proposed change:




Rational for 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