This standard specifies the format and contents of a quality plan. It identifies the practices and processes to be applied during a project to ensure that the deliverables conform to the agreed requirements.
It also identifies the quality objectives of the project, which are statements about measurable aspects of project and quality management.
The quality plan includes the following:
This standard applies to the following:
This standard does not apply to the following.
The objective of this standard is to provide project and quality managers with a guide for the development of the quality plan.
The outcome of using this standard will be the following.
[1] IEEE 730 -1989
Standard for Software Quality Assurance Plans
IEEE Software Engineering Standards 1993 Ed.
The Project Manager is responsible for the following.
The Quality Manager is responsible for the following.
An approved quality plan is a prerequisite to the conduct of a project. A quality plan shall be created at the commencement of each software quality management system project. It is developed concurrently with the project agreement and the project plan.
All quality plans shall conform to Std-01, be filed in accordance with Std-03, and be change controlled in accordance with Std-18.
This procedure description section outlines the minimum content of the quality plan.
All quality plans shall have as a minimum, a contents, as described in the table of contents sections following.
|
1. Purpose |
1.1. Project description |
1.2. Quality objectives |
1.3. Life cycle model |
1.4. Precedence |
1.5. Scope |
2. Reference documents |
2.1. software quality management system standards |
2.2. Other standards |
2.3. reference documents |
2.4. Other documents |
3. Management |
3.1. Quality organisation |
3.2. Quality tasks and responsibilities |
4. Documentation |
4.1. Identification and filing of project documents |
4.2. Project document standards |
5. Standards, practices, conventions and metrics |
5.1. Standards |
5.2. Practices and conventions |
5.3. Metrics |
5.4. Project debrief |
6. Reviews and audits |
7. Test |
8. Problem reporting and corrective action |
9. Tools, techniques and methodologies |
10. Code control |
11. Media control |
12. Supplier control |
12.1. Individual contractors |
12.2. Supplier quality and control |
12.3. Suppliers quality system |
12.4. Control of purchased software products |
13. Records collection, maintenance and retention |
14. Training |
14.1. Quality assurance representative |
14.2. Project team |
15. Risk management |
15.1. Introduction |
15.2. Risk assessment |
15.3. Risk scenarios |
|
|
Figure 1 - Quality Plan Table of Contents
Where a section is not relevant, still include the section and say 'Not applicable' with a brief reason(s) for leaving it out.
Additional sections may be added as required and should follow a similar format and numbering convention as the rest of the quality plan.
Some of the material may appear in other documents. If so, then reference to these documents shall be made in the body of the quality plan.
This section of the quality plan gives a basic overview of the project, defines the quality objectives for the project, and defines in detail the scope of the Quality Plan.
Project description (section 1.1)This section shall provide a brief overview of the project to which the Quality Plan relates. It should provide a reference to the Project Plan for a more complete description of the project.
This section shall state the quality objectives of the project. Each objective must be measurable and it must be possible to determine compliance through the use of some measurable quantity. Do not restate the project objectives (those from section 1.1 of the project plan).
It is difficult to have meaningful quality objectives until projects become familiar with the use of quality systems and have metrics collection processes in place. The following are examples.
A table identifying the metric or metrics used for establishing compliance with each of the Quality Objectives, and an indication of whether the objective has been achieved shall be included. The table need only identify the metric(s) to be used, section 5.3 of the Quality Plan should be referenced for a complete definition.
The quality objectives and metric(s) shall then be monitored and reviewed during the project, and the table updated with subsequent revisions of the Quality Plan, though it is likely that compliance or otherwise will only be able to be determined at the conclusion of the project.
An example of the required table is given below.
Objective |
Metric(s) |
Reference |
1 |
Review minutes/page |
5.3.x |
2 |
Number of project change requests |
5.3.y |
Table 1. Metrics for quality objectives
This section shall provide in detail the project's life cycle, or make reference to the project plan. If the model is provided it may be given as a flowchart, a table or a written description and should reflect the information in section 2.1 of the project plan.
The life cycle of a project shows the major phases or stages of the project. It need contain only a high level project phase description and does not include the detailed tasks or activities necessary for the construction of the schedule.
Many different project structures may exist given the major differences between, say, a large development, purchase of a package, enhancement of an existing system and so on.
Indicate the order of precedence which applies should conflict occur between certain items of project documentation. For example standards will take precedence over the quality plan.
This section shall describe in detail the scope of the Quality Plan for each of the project deliverables.
For each project deliverable show the intended use of the deliverable, and the proportion of the software life cycle of that deliverable, that is covered by this Quality Plan. This information is normally given in a table such as the example below.
Table 2. Quality scope for deliverables.
Definitions of the terms used are as follows.
Table 3 - Life cycle phases for use in quality plan.