SQA Plan Template – Software quality plan – SQA Plan Template TM-SQA-01 v2. 12/16/ SOFTWARE QUALITY – Studocu

SQA Plan Template
TM-SQA-01 v2.
12/16/

SOFTWARE QUALITY ASSURANCE PLAN

TEMPLATE

TM-SQA-01 V2.

DECEMBER 16, 2003

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

Approved for public release; distribution is unlimited

SQA Plan Template
TM-SQA-01 v2.
12/16/

PREFACE

This document is a template of a Software Quality Assurance (SQA) Plan using the guidelines provided
in the Institute of Electrical and Electronics Engineers (IEEE) 730-1998, IEEE Standard for Software
Quality Assurance Plans, and IEEE Std 730-1995, IEEE Guide for Software Quality Assurance
Planning. This template should be supplemented with project-specific information to produce a SQA
Plan that accurately describes the project’s SQA organization, tasks, role, and responsibilities. The
planning and documenting of SQA activities must agree and be consistent with the project’s Software
Development Plan (SDP) and any other project-planning document. Additionally, the SQA Plan must
comply with Space and Naval Warfare (SPAWAR) Systems Center (SSC) San Diego SQA Policy, which
provides management with appropriate visibility into the process being used by the software project and
of the products being built.

This document supplements the SQA Process. Refer to Section 4, Create/Maintain SQA Plan, of the
SQA Process for a description on the use of this template.

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 revisions 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
sepo.spawar.navy/. Updates are performed in accordance with the SEPO Configuration
Management Procedure available on the SSC San Diego PAL.

ii

SQA Plan Template
TM-SQA-01 v2.
12/16/

RECORD OF CHANGES
* A – ADDED M – MODIFIED D – DELETED

VERSION
NUMBER
DATE

NUMBER OF
FIGURE, TABLE OR
PARAGRAPH

A
M
D*

TITLE OR BRIEF DESCRIPTION

CHANGE
REQUEST
NUMBER

1 1/25/00 Entire Document Updated Template to include checklists
for general Software Engineering Process
Verification (Appendix B) and focused
CMM Key Process Area Verification
(Appendix C)

2 12/16/03 Entire Document Revised Task definitions and reorganized
them into a separate section; incorporated
changes from DCR #SQAPT-003;
removed SW-CMM Key Process Area
validation process and checklists (to be
documented as a separate document –
addressing CMMI verification); added an
“escalation procedure” to Section 7 for
resolution of non-concurrence of SQA
recommendations

SQAPT-
003
SQA-

iv

SQA Plan Template
TM-SQA-01 v2.
12/16/

DOCUMENT CONVENTIONS

This document is a Software Quality Assurance (SQA) Plan template. As such, wording in this
document should be supplemented with project-specific information to produce an SQA Plan that
accurately describes the project SQA organization. Therefore, 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
department-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.

Italics Instructions and explanations. Items that appear in italics represent instructions to the user
and are not to appear in the completed version of the document.

In some cases where information may already be found in another project document, like the Software
Development Plan (SDP), refer to that document rather than duplicate the information in the project SQA
Plan.

The template begins with the Project SQA cover sheet on the page after the next. Delete all pages prior
to the Project SQA cover sheet in the final format of the project SQA Plan. Update the header page to
reflect the document configuration identifier for the project SQA Plan.

v

[[Configuration Control #]]
[[Document Date]]

[[PROJECT NAME]]

SOFTWARE QUALITY ASSURANCE PLAN

[[CONFIGURATION CONTROL #]]

[[DOCUMENT DATE]]

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

Approved for public release; distribution is unlimited

[[Configuration Control #]]
[[Document Date]]

This page intentionally left blank.

ii

[[Configuration Control #]]
[[Document Date]]

PREFACE

This document contains the Software Quality Assurance (SQA) Plan for the [[Project Name]]. The SQA
activities described in this plan are consistent with the [[Project Name]] Software Development Plan (or
Project Management Plan) and other project planning documents. This document has been tailored from
the SQA Plan Template, TM-SQA-01, v2.

The [[Code/Project/Office]] assumes responsibility for this document and updates it, as required, to meet
the needs of [[Project Name]]. 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 Name Configuration Management
Process]].

iv

[[Configuration Control #]]
[[Document Date]]

RECORD OF CHANGES
* A – ADDED M – MODIFIED D – DELETED

VERSION
NUMBER
DATE

NUMBER OF
FIGURE, TABLE OR
PARAGRAPH

A
M
D*

TITLE OR BRIEF DESCRIPTION

CHANGE
REQUEST
NUMBER

v

[[Configuration Control #]]

LIST OF FIGURES

• SECTION 5. STANDARDS, PRACTICES, CONVENTIONS AND METRICS…………………………….- [[Document Date]]
  • 5 Metrics…………………………………………………………………………………………………………………….-
• SECTION 6. TEST………………………………………………………………………………………………………………..-
• SECTION 7. SQA PROBLEM REPORTING AND RESOLUTION……………………………………………..-
  • 7 Process Audit Report…………………………………………………………………………………………………-
    • 7.1 Submittal and Disposition of Process Audit Report…………………………………………………-
    • 7.1 Escalation Procedure for Resolution of Non-Concurrence on Process Audit Report…….-
  • 7 Recording Problems in Software Code or Documentation………………………………………………-
  • 7 Software Tool Evaluation Report…………………………………………………………………………………-
  • 7 Facilities Evaluation Report……………………………………………………………………………………….-
• SECTION 8. TOOLS, TECHNIQUES, AND METHODOLOGIES………………………………………………-
• SECTION 9. CODE CONTROL……………………………………………………………………………………………..-
• SECTION 10. MEDIA CONTROL…………………………………………………………………………………………-
• SECTION 11. SUPPLIER CONTROL……………………………………………………………………………………-
• SECTION 12. RECORDS COLLECTION, MAINTENANCE AND RETENTION………………………-
• SECTION 13. TRAINING…………………………………………………………………………………………………….-
• SECTION 14. RISK MANAGEMENT…………………………………………………………………………………..-
• APPENDIX A. LIST OF ACRONYMS……………………………………………………………………………………-
• APPENDIX B. GENERAL SOFTWARE ENGINEERING PROCESS AUDIT CHECKLISTS……….-
• Figure 1-1. [[System Title]] Software………………………………………………………………………………………..- Figure Page
• Figure 2-1. [[Project Name]] Organization…………………………………………………………………………………-
• Figure 7-1. Process Audit Report……………………………………………………………………………………………..-
• Figure 7-2. Software Tool Evaluation………………………………………………………………………………………..-
• Figure 7-3. Project Facilities Evaluation……………………………………………………………………………………-
• Figure B-1. Project Planning Process Audit Checklist………………………………………………………………..-
• Figure B-2. Project Tracking and Oversight Process Audit Checklist……………………………………………-
• Figure B-3. System Requirements Analysis Process Audit Checklist…………………………………………….-
• Figure B-4. System Design Process Audit Checklist…………………………………………………………………..-
• Figure B-5. Software Requirements Analysis Process Audit Checklist………………………………………….-
• Figure B-6. Software Design Process Audit Checklist………………………………………………………………..-
• Figure B-7. Software Implementation and Unit Testing Process Audit Checklist……………………………-
• Figure B-8. Unit Integration and Testing Process Audit Checklist………………………………………………..-
• Figure B-9. CI Integration Testing and System Qualification Process Audit Checklist…………………….-
• Figure B-10. End-Item Delivery Process Audit Checklist……………………………………………………………-
• Figure B-11. Software Corrective Action Process Audit Checklist………………………………………………..-
• Figure B-12. Media Certification Process Audit Checklist…………………………………………………………..-

[[Configuration Control #]]
[[Document Date]]

Figure B-13. Non-Deliverable Software Certification Process Audit Checklist………………………………-
Figure B-14. Storage and Handling Process Audit Checklist……………………………………………………….-
Figure B-15. Subcontractor Control Process Audit Checklist……………………………………………………….-
Figure B-16. Deviations and Waivers Process Audit Checklist…………………………………………………….-
Figure B-17. Software Configuration Management Process Audit Checklist………………………………….-
Figure B-18. Software Development Library Control Process Audit Checklist………………………………-
Figure B-19. Non-Developmental Software Process Audit Checklist……………………………………………-

LIST OF TABLES

Table Page

TABLE 1-1. SOFTWARE LIFECYCLE ACTIVITIES……………………………………………………………………….-
Table 1-2. CI Nomenclature/Identification…………………………………………………………………………………-
Table 3-1. Reviews and Audits…………………………………………………………………………………………………-
Table 3-2. Responsibility Matrix………………………………………………………………………………………………-
Table 4-1. Deliverable Software Products………………………………………………………………………………….-
Table 4-2. Non-deliverable Software Products…………………………………………………………………………….-
Table 13-1. SQA Training Matrix…………………………………………………………………………………………….-

viii

[[Configuration Control #]]
[[Document Date]]

Project Planning and Oversight

Software Development Environment

System Requirements Analysis

System Design

Software Requirements Analysis

Software Design

Software Implementation and Unit Testing

Unit Integration and Testing

CI Qualification Testing

CI/Hardware Configuration Item (HWCI)
Integration and Testing

System Qualification Testing

Software Use Preparation

Software Transition Preparation

Life Cycle Maintenance

TABLE 1-2. CI NOMENCLATURE/IDENTIFICATION

NOMENCLATURE ACRONYM CI NUMBER

[[CI Name]] [[Acronym]] [[CI ID number]]

[[CI Name]] [[Acronym]] [[CI ID number]]

[[CI Name]] [[Acronym]] [[CI ID number]]

1 DOCUMENT OVERVIEW

This document identifies the organizations and procedures to be used to perform activities related to the
[[Project Name]] SQA program as specified in IEEE Std 730-1998, IEEE Standard for Software Quality
Assurance Plans, reference (c) and IEEE Std 730-1995, IEEE Guide for SQA Planning, reference (d).

Section 1 identifies the system to which this SQA Plan applies; provides an overview of the system and
its software functions; summarizes the purpose and contents of the SQA Plan; and describes the
relationship of the SQA Plan to other management plans and lists all documents referenced in this SQA
Plan.

Section 2 describes each major element of the organization that influences the quality of the software.

1-

[[Configuration Control #]]
[[Document Date]]

Figure 1-1. [[System Title]] Software

Section 3 describes the various SQA tasks

Section 4 lists the baseline documents produced and maintained by the project.

Section 5 identifies the standards, practices and conventions.

Section 6 describes SQA involvement in testing.

Section 7 describes problem reporting and corrective action.

Section 8 describes SQA tools, techniques, and methodologies.

Section 9 describes the configuration management tool used for code control.

Section 10 describes SQA evaluation of media control.

Section 11 describes control of supplier software.

Section 12 describes SQA procedures for record collection, maintenance, and retention.

Section 13 describes SQA training requirements.

Section 14 describes SQA review of the Risk Management process.

Appendix A provides a list of acronyms.

Appendix B provides checklists to be used or tailored for verifying compliance with general software
engineering best practices.

1 RELATIONSHIP TO OTHER PLANS

SQA evaluation of the software development processes throughout the life cycle is based on the processes
defined in the [[Project Name]] Software Development Plan (SDP), reference (e). Reference (e) and its
implementation procedures establish the SQA evaluation criteria. The SQA Plan is implemented in
conjunction with the [[Project Name]] Software Configuration Management Plan, reference (f).

1-

[[Configuration Control #]]
[[Document Date]]

SECTION 2. MANAGEMENT

This section describes each major element of the organization that influences the quality of the software.

2 ORGANIZATION

Good software practice requires a measure of independence for the SQA group. This independence
provides a key strength to SQA; that is, SQA 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 SQA 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 SQA organization with relation to the project organization.

I V & V S E P O

S Q A

S C M

S y s t e m s
E n g i n e e r i n g

S o f t w a r e
D e v e l o p m e n t

S o f t w a r e
T e s t

S y s t e m
T e s t

L o g i s t i c s

P r o j e c t
M a n a g e m e n t

P r o g r a m
M a n a g e m e n t /
L i n e M a n a g e m e n t
( S p o n s o r )

Figure 2-1. [[Project Name]] Organization

Replace Figure 2-1 with your 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 char. Provide a description of the
functional responsibilities for each functional group in the organizational structure.

In describing the functional responsibilities, answer the questions listed below:

a. Who interacts with SQA?
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?

2-

[[Configuration Control #]]
[[Document Date]]

e. Who approves the SQA Plan?

f. What are the reporting lines for escalating conflicts and the method by which conflicts are to be
resolved among the elements?

In each case, add or delete the functional responsibilities that apply.

SQA is responsible for ensuring compliance with SQA requirements as delineated in this SQA Plan. The
SQA organization assures the quality of deliverable software and its documentation, non-deliverable
software, and the engineering processes used to produce software.

The following describes the functional groups that influence and control software quality.

a. Program Management/Line Management (Sponsor) is responsible for the following items:
1. Establishing a quality program by committing the project to implement the Software
Engineering Process Policy, reference (g), and reference (a).
2. Reviewing and approving the [[Project Name]] SQA Plan.
3. Resolving and following-up on any quality issues raised by SQA.
4. Identifying an individual or group independent from the project to audit and report on the
project’s SQA function.
5. Identifying the quality factors to be implemented in the system and software.
6. fill-in additional functional responsibilities.
b. Project Management is responsible for:

1. Implementing the quality program in accordance with references (g) and (a).

2. Identifying the SQA activities to be performed by SQA.

3. Reviewing and approving the [[Project Name]] SQA Plan.

4. Identifying and funding an individual or group independent from the project to perform the
   SQA functions.

5. Resolving and following-up on any quality issues raised by SQA.

6. Identifying and ensuring the quality factors to be implemented in the system and software.

7. Identifying, developing and maintaining planning documents such as the Program
   Management Plan, reference (h), references (e) and (f), Test Plans, and this SQA Plan.
   8. fill-in additional functional responsibilities.
   c. System Engineering is responsible for:

8. Reviewing and commenting on the [[Project Name]] SQA Plan.

9. Implementing the quality program in accordance with this SQA Plan.

10. Resolving and following-up on any quality issues raised by SQA related to software
    engineering activities.

11. Identifying, implementing, and evaluating the quality factors to be implemented in the
    system (software and hardware).

12. Implementing the engineering practices, processes, and procedures as defined in reference (e)
    and other program/project planning documents.

6. fill-in additional functional responsibilities.

2-