Software Quality Assurance Plan: [Project or product name]

Complete Software Quality Assurance Plan (SQAP). The structure follows the SQA plan content described in IEEE 730-2014: purpose and scope, organisation and independence, SQA activities across the life cycle (product assurance and process assurance), standards, reviews and audits, problem reporting, tools, supplier control, records, training, risk and metrics. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Organisation and independence
3. Standards, practices and conventions
4. SQA activities by life-cycle phase
5. Product assurance
6. Process assurance
7. Reviews and audits schedule
8. Problem reporting and corrective action
9. Tools, techniques and methods
10. Supplier and subcontractor control
11. Risk management
12. Records collection, maintenance and retention
13. Training
14. Metrics
15. Glossary and references

1. Purpose and scope

1.1 Purpose

This plan defines how [organisation] will provide objective evidence that [project name] produces software, documentation and services that conform to their requirements, and that the project follows its agreed processes. It is the reference for all SQA tasks, reviews and audits.

1.2 Scope

1.3 Quality requirements and objectives

1.4 Tailoring

[State which parts of the organisation's quality management system or of this template are tailored for the project, why, and who approved it. Example: "Formal inspection replaced by pull-request review for code with risk class C, approved by head of quality YYYY-MM-DD."]

2. Organisation and independence

2.1 Organisation

The SQA lead reports to the head of quality, not to the project manager, so that findings can be escalated without depending on the delivery chain.

2.2 Responsibilities

2.3 Independence

2.4 Escalation

Unresolved findings are escalated in this order: technical lead (5 working days) -> project manager (5 working days) -> head of quality -> project sponsor. Escalations are recorded in the finding log.

3. Standards, practices and conventions

4. SQA activities by life-cycle phase

5. Product assurance

5.1 Products subject to assurance

5.2 Conformance evaluation

Each assessment produces a result of Conformant, Conformant with minor findings, or Non-conformant. Non-conformant products are not baselined until the findings are closed or a waiver is approved (section 8.4).

5.3 Acceptability of products

[Describe how SQA checks that products meet customer acceptance criteria, for example by reviewing the UAT plan and witnessing a sample of acceptance tests.]

5.4 Life-cycle support and measurement of products

Product quality measures (defect density, test coverage, static analysis violations) are collected as described in section 14 and reviewed at each phase gate.

6. Process assurance

6.1 Assessment of the project's life-cycle model

[Confirm that the project's chosen life-cycle model and its plans are consistent with the organisation's processes and the contract, and that the plans themselves are adequate. Record the result in the plan review report.]

6.2 Assessment of the environment for development

[Check that development, build and test environments are controlled: access, versions, backups, and that tools are qualified where required.]

7. Reviews and audits schedule

8. Problem reporting and corrective action

8.1 Problem types

8.2 Finding severity

8.3 Corrective action process

Every major or minor finding follows the loop below. SQA closes a finding only after checking that the action removed the cause, not just the symptom.

8.4 Waivers

A non-conformance that will not be corrected requires a waiver with the reason, the risk, the compensating measure and approval by [the head of quality and the product owner]. Waivers are listed in the release quality statement.

9. Tools, techniques and methods

10. Supplier and subcontractor control

Acceptance of supplier deliveries requires: delivery checklist complete, evidence received, and no open major findings.

11. Risk management

12. Records collection, maintenance and retention

Records are protected from unauthorised change by [access control and version history] and backed up [daily].

13. Training

14. Metrics

Review effectiveness is calculated as

$RE = \frac{F_{\text{review}}}{F_{\text{later}} + 1}$

where $F_{\text{review}}$ is major findings found in reviews and $F_{\text{later}}$ is major defects in the same product found in test or operation; adding one avoids division by zero.

15. Glossary and references

References: [Project management plan], [SCM plan], [V&V plan], [Test strategy], [Organisation QMS procedures], IEEE 730-2014, IEEE Standard for Software Quality Assurance Processes.

Standard and licence note

Structure aligned with IEEE 730-2014, IEEE Standard for Software Quality Assurance Processes, SQA plan content. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from IEEE for its normative requirements. Template licence: MIT.