GFG Microsystems Limited

IT Department

Information Technology Department

IT Project Quality Assurance Plan

Quality Assurance Plan for Client_name

GFG Microsystems Limited

GFG IT Development

GFG IT

Quality Assurance Plan for Client_name

project name

XXXX

0.02

GFG IT-UK-99-SO 104/0.02

4 February 1998

Client_name

DOCUMENT DISTRIBUTION

Document Identification

Document Ref:

GFG IT-UK-99-SO 104/0.02

Authors Ref:

S104O002.DOT

Author:

Date:

4 February 1998

Dept/Section:

GFG IT Development

Version:

0.02

Reason for Distribution

For Review

Status:

Draft

Distribution of Approved Version:

Reviewers	Department	Responsibilities	Comments Received

Issued By:

...........................................

...........................................

Copy No:

Issued To:

CONTENTS

1	Introduction	4

1.1	Purpose	4

1.2	Scope	4

1.3	Audience	4

1.4	Related Documents	4

1.5	References	5

1.6	Revision History	5

2	Management	6

2.1	Personnel	6

2.2	Tasks	6

3	Documentation	8

4	STANDARDS, PRACTICES AND CONVENTIONS	9

5	REVIEWS AND AUDITS	10

5.1	Reviews	10

5.2	Audits	14

6	TESTING	16

7	CONFIGURATION MANAGEMENT	16

8	PROBLEM REPORTING AND Version CONTROL	17

9	TOOLS, TECHNIQUES AND METRODOLOCIES	17

10	RECORDS COLLECTION, MAINTENANCE AND RETENTION	17

Introduction

This document is a skeleton Project Quality Assurance Plan that is intended to be used as a basis for actual PQAPS. Please take a copy of this file and modify it as appropriate. This skeleton has been produced in accordance with the Project Quality Assurance Planning Standard (GFG IT UK-99-SO-4). This skeleton is not included as part of GFG IT UK-99-SO-4 for two for two reasons. Firstly, it may be subject to more frequent revision than the body of the standard. Secondly, it has to be available in machine readable form to provide significant benefits in terms of time saved.

This paragraph and the previous paragraph should be deleted before this skeleton is used. Use of this skeleton does not avoid the need to think about the contents of a PQAP and all parts of this skeleton may need to be subject to amendment.

WARNING - This document is not guaranteed in any way and any faults or flaws in this it are the responsibility of the person editing it to correct. In other words, if you get picked up for any faults in this document then it's your own fault. However, if you do find a fault then please inform the Standards Librarian or any member of the Standards committee so it can be corrected for future use.

Purpose

This document is the Project Quality Assurance Plan for project XXXX.

This document describes how Quality Assurance (QA) is to be planned and implemented on the project.

Scope

This document is concerned with planning the Quality Assurance of the project. it does not deal with planning other aspects of the project or with Quality Assurance of other projects.

Audience

This document is intended for the staff of GFG IT Development concerned with project XXXX as part of the project team or in a Quality Assurance capacity and for the staff of XXXX client concerned with the project.

A knowledge of Quality Assurance techniques and the relevant standards is assumed throughout.

Related Documents

It is assumed that the reader is familiar with the following documents.

[1]	GFG IT UK	SO	1	The Object and Documentation Numbering System
[2]	GFG IT UK	SO	3	Document Writing Standard
[3]	GFG IT UK	SO	17	Commenting and Layout Checklist
[4]	GFG IT UK	SO	18	Coding Checklist
[5]	GFG IT UK	SO	4	Project Quality Assurance Planning Standard
[6]	GFG IT UK	SO	2	Configuration Management Standard
[7]	GFG IT UK	SO	5	Project Management Standard
[8]	GFG IT UK	SO	14	Reviewing Standard
[9]	GFG IT UK	SO	15	Auditing Standard
[10]	GFG IT UK	SO	16	Software Test Planning Standard

Any other standards

XXXX, Project Plan

XXXX, Proposal

XXXX, Contract

XXXX, Functional Specification ?

Any other project related documents, such as Requirements Specifications

References

Any referenced documents should be mentioned here.

Revision History

Version	Date	Author	Description	Sections Affected

0.02	98/02/04	GFG	Version changed	Document re-saved
0.01	97/12/04	GFG	First draft	All, diagrams and forms to be added

Management

Personnel

The Project Supervisor for this project is XXXX. The Project Manager for this project is XXXX. The Project Auditor for this project is XXXX. The Team Leaders for this project are XXXX and XXXX. The client contact for this project is XXXX.

XXXX is responsible for signing off documents after reviews. This will normally be the Project Supervisor but may be a client as well.

This data could be presented in a table format as follows:

The project management roles are assigned as follows:

Project Supervisor:	xxxx

Project Manager:	xxxx

Project Auditor:	xxxx

Team Leaders:	xxxx

xxxx

Sign-Off Authority:	XXXX for GFG IT

XXXX for the client

The client contact for this project is XXXX.

Tasks

The following tasks are the Quality Assurance tasks for this project:

Carrying out reviews and audits (see Section 5)

Conforming to standards in the creation of code and documents (and hardware perhaps).

Possibly the creation of specialised QA tools

Possibly training in QA techniques or standards

All members of the project team are responsible for conforming to all relevant standards when producing code and documents (and hardware perhaps).

The people responsible for carrying out reviews and audits are listed in Section 5 below along with the agendas, tasks and success criteria.

The success criteria for compliance with standards is to pass document reviews or code audits.

If any specialised QA tools are to be created then state the success criteria, such as passing reviews or tests.

If training is required then state the success criteria. Unless end of course tests are administered then there may not be any real success criteria.

Documentation

The following documents will be produced and reviewed in this project:

Delete those which do not apply, add any more that do apply and don’t forget to set up multi-part documents. Object numbers should be included where known. On small projects not all of these documents may be necessary and others may be combined.

Project Plan

Project Quality Assurance Plan (this document)

Requirements Specification

Functional Specification

Architectural Design Specification

Detailed Design Specification

User Manual

Acceptance Specification

Software Test Plan

Hardware Test Plan

Software Test Report

Hardware Test Report

STANDARDS, PRACTICES AND CONVENTIONS

All relevant GFG IT standards are to be used on this project, as listed in Section 1.4. If not all are to be used then state which ones are not to be used.

List any external standards that are to be used.

List any other practices or conventions that are to be used. Examples of these are:

Formal design tools (for example Jackson or Yourdon tools)

Spelling checkers (if not then why not?)

LINT or similar program checkers

'make' or SCCS based build tools

File or routine header prototypes (which could be included in appendices to this document)

The entire development environment may be described here. This would avoid having to partially repeat information elsewhere. If this is done then Section6 just needs to refer back to this section and Sections 7 and 8 may be similarly affected.

REVIEWS AND AUDITS

Reviews

The following reviews will take place during the project:

Not all of these reviews may be required on all projects. In addition some of them may be split, either as described in GFG ITUK-99-SO-14 or due to design specifications being multi-part documents.

Project Plan Review

Project Quality Assurance Plan Review

Requirements Specification Review

Functional Specification Review

Architectural Design Specification Review

Detailed Design Specification Review

User Manual Review

Acceptance Specification Review

Software Test Plan Review

Hardware Test Plan Review

Software Test Report Review

Hardware Test Report Review

All documents should be subjected to informal inspection by at least one person of the author's choice before being considered ready for review.

State which reviews the client is to be invited to participate in.

Possibly all code should be subject to informal inspection by at least one person of the author's choice before testing commences?

The following review details may have to be altered for specific projects. In particular, if some documents are not present then the dependencies change. The review participants may have to be altered, the lead times have to be defined and the review criteria and tasks may have to be altered. Do not use this section blindly but try to think about the reviews.

Project Plan Review

The Project Plan Review should take place as early as possible in the project. A lead time of XXX days should be allowed between distribution of the Project Plan and the Project Plan Review.

The following people should participate in the Project Plan Review; the Project Manager, the Project Auditor and the Project Supervisor. The criteria and tasks for the Project Plan Review are listed in the Reviewing Standard (GFG IT UK-99-SO-14). The success criterion for the Project Plan Review is for a review report to be produced.

Project Quality Assurance Plan Review

The Project Quality Assurance Review should take place as early as possible in the project. A lead time of XXX days should be allowed between distribution of the Project Quality Assurance Plan and the Project Quality Assurance Plan Review.

The following people should participate in the Project Quality Assurance Plan Review; the Project Manager, the Project Auditor and the Project Supervisor. The criteria and tasks for the Project Quality Assurance Plan Review are listed in the Reviewing Standard (GFG IT 14). The success criterion for the Project Quality Assurance Plan Review is for a review report to be produced.

As the Project Quality Assurance Plan is expected to change substantially during the life of the project a single review is unlikely to be sufficient. The first review should take place as early as possible and subsequent reviews should take place whenever the Project Quality Assurance Plan is significantly amended. This does not mean that a full-blown review is necessary whenever a trivial change is made. In the case of localised changes it is sufficient to review the altered section or sections. The personnel and criteria remain the same for all reviews of the Project Quality Assurance Plan.

Requirements Specification Review

The Requirements Specification Review should take place before a significant amount of work is done on the Functional Specification. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the Requirements Specification and agenda and the Requirements Specification Review.

The following people should participate in the Requirements Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Requirements Specification Review are as listed in the Reviewing Standard (GFG IT 14). The success criterion for the Requirements Specification Review is for a review report to be produced.

Functional Specification Review

The Functional Specification Review should take place before a significant amount of work is done on the Architectural Design. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the Functional Specification and agenda and the Functional Specification Review.

The following people should participate in the Functional Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Functional Specification Review are as listed in the Reviewing Standard (GFG IT 14). The success criterion for the Functional Specification Review is for a review report to be produced.

Architectural Design Specification Review

The Architectural Design Specification Review should take place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Architectural Design Specification and agenda and the Architectural Design Specification Review.

The following people should participate in the Architectural Design Specification Review; the author, the Project Auditor, the Project Manager, XXXX the client manager and the team leaders. The criteria and tasks for the Architectural Design Specification Review are as listed in the Reviewing Standard (GFG IT UK-99-SO-14). The success criterion for the Architectural Design Specification Review is for a review report to be produced.

Detailed Design Specification Review

The Detailed Design Specification Review should take place before a

significant amount of work is done on implementation. A lead time of XXX days should be allowed between distribution of the Detailed Design Specification and agenda and the Detailed Design Specification Review.

The following people should participate in the Detailed Design Specification Review; the author, the Project Auditor, the Project Manager, and the team leaders. The criteria and tasks for the Detailed Design Specification Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Detailed Design Specification Review is for a review report to be produced.

User Manual Review

The User Manual Review must take place before the first release. A lead time of XXX days (Allow time for internal circulation within client staff) should be allowed between distribution of the User Manual and agenda and the User Manual Review.

The following people should participate in the User Manual Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the User Manual Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the User Manual Review is for a review report to be produced.

Acceptance Specification Review

The Acceptance Specification Review should take place at least XXX weeks before testing of the complete system starts. A lead time of XXX days should be allowed between distribution of the Acceptance Specification and agenda and the Acceptance Specification Review.

The following people should participate in the Acceptance Specification Review; the author, the Project Auditor, the Project Manager and XXXX the client manager. The criteria and tasks for the Acceptance Specification Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Acceptance Specification Review is for a review report to be produced.

Software Test Plan Review

The Software Test Plan Review should take Place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Software Test Plan and agenda and the Software Test Plan Review.

The following people should participate in the Software Test Plan Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Software Test Plan

Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Software Test Plan Review is for a review report to be produced.

Hardware Test Plan Review

The Hardware Test Plan Review should take place before a significant amount of work is done on the Detailed Design Specification. A lead time of XXX days should be allowed between distribution of the Hardware Test Plan and agenda and the Hardware Test Plan Review.

The following people should participate in the Hardware Test Plan Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Hardware Test Plan Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Hardware Test Plan Review is for a review report to be produced.

Software Test Report Review

The Software Test Report Review should take place before the system is released. A lead time of XXX days should be allowed between distribution of the Software Test Report and agenda and the Software Test Report Review.

The following people should participate in the Software Test Report Review; the author, the Project Auditor the Project Manager and the team leaders. The criteria and tasks for the Software Test Report Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Software Test Report Review is for a review report to be produced.

Hardware Test Report Review

The Hardware Test Report Review should take place before the system is released. A lead time of XXX days should be allowed between distribution of the Hardware Test Report and agenda and the Hardware Test Report Review.

The following people should participate in the Hardware Test Report Review; the author, the Project Auditor, the Project Manager and the team leaders. The criteria and tasks for the Hardware Test Report Review are as listed in the Reviewing Standard (GFG IT -14). The success criterion for the Hardware Test Report Review is for a review report to be produced.

Further reviews may be required. These may include reviews for QA tools and design walkthroughs.

Audits

The following audits will take place during the project:

Physical Audit

In-Process Audit

Code Audits

Not all of these audits may be required on all projects. On some projects other audits may be required. The tasks for the audits may need to be changed.

Physical Audit

A Physical Audit must be held before each release and the release may not go ahead until an audit report has been produced stating that the release has been satisfactorily audited and no problems have been found.

Make sure that the time required for the Physical Audit is included in the Project Plan. This should include lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan.

The tasks for a Physical Audit are as listed in the Auditing Standard (GFG IT -15).

The success criteria for the Physical Audit is for an audit report to be produced.

If a report is produced from a Physical Audit that specifies any problems then the Project Manager is responsible for ensuring that the problems are dealt with before a repeat Physical Audit is scheduled.

In-Process Audit

At least one In-Process Audit should be held during the project and at the discretion of the Project Auditor further In-Process Audits may be held. If any serious faults are found during an In-Process Audit then the Project Auditor should conduct a repeat audit after the faults are supposed to have been addressed in order to check on them. Such a review may be a subset of a normal In-Process Review.

The tasks for an In-Process Audit are as listed in the Auditing Standard (GFG IT -15).

Make sure that the time required for the In-Process Audit is included in the Project Plan. This should include lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan.

The success criteria of the In-Process Audit is to produce an audit report.

The Project Supervisor is responsible for planning corrections to any faults found in an In-Process Audit within XXX days of the audit report being produced. The planned corrections should have been implemented within XXX days of their being planned.

Code Audits

A Code Audit should be held on an example of the code produced by each member of the project team at some point early on in the implementation phase. Depending on the result of the first Code Audit of a person's code further Code Audits may or may not be required at the discretion of the Project Auditor.

The Code Audits should be conducted either by the Project Auditor or by a Team Leader (as nominated by the Project Auditor).

Make sure that the time required for all Code Audits is included in the Project Plan. This should include planning time, lead time and time required of the Project Auditor and any other staff. Possibly include a reference to the task code in the Project Plan.

The success criteria of a Code Audit is to produce an audit report.

If a Code Audit discovers problems in the code produced by a team member then the relevant Team Leader is responsible for ensuring that the problems are fixed, both in the sample of code audited and in all other code produced by the team member, within XXX days of the audit report being produced.

TESTING

The software will be tested by three levels of test. All modules will be tested in semi-isolation (module testing) and then integrated into subsystems that will be tested in isolation (integration testing) and the final system will be tested (system testing).

Modules will be tested in semi-isolation in that the modules which interact directly with the operating system (list them here) will be tested in isolation and then the modules which depend on other modules for some functions (list them here) will be tested in conjunction with the other modules in order to avoid having to create unnecessary stubs during module testing. This implies that certain modules cannot be tested before other modules have been tested. List the dependencies here.

Sub-systems will be tested in isolation and stubs will be created to allow this. Any stubs that are required for sub-system testing will also be required during module testing and these are the only stubs that will be used during module testing. These stubs will be maintained under normal configuration control for the project as they may be used for regression testing in the future.

All tests will produce output in the form of a results file and each test result will be identified by the object number of the corresponding test plan and the group number and test number of the test.

No module or sub-system tests will be controlled by user input. Instead all tests will be driven by files of test data. Final system testing will be driven by user input.

CONFIGURATION MANAGEMENT

This project will follow the Configuration Management Standard (GFG IT UK-99-SO-2) for configuration management.

Consider these options seriously and do not just accept the versions given here.

Standard file naming conventions based on the GFG IT numbering system are to be followed.

All derived objects are to be controlled manually by means of an integration workbook. Or specify an alternative means that satisfies the configuration management standard.

Revision histories are to be kept with all code and documents. Revision histories for code objects are to be kept at the head of the file (see the header included as Appendix X). Revision histories for documents are to be kept as part of the introduction. Revision histories must include the date of revisions and the initials of the persons making the revisions.

Nested releases are not to be used and the whole system will be released when a release is performed. Each release will include all design documentation (both architectural and detailed), all user documentation, all source code and all executable programs.

Incremental backups should be performed daily and full backups should be performed once a week. All backup tapes should be stored in a fire safe.

PROBLEM REPORTING AND Version CONTROL

This project will follow the Configuration Management Standard (GFG IT UK-99-SO-2) for handling problem reporting and change control.

Change control procedures are mandatory once design documents have passed a review and once software has passed module tests.

The clients are allowed to raise any type of change requests but all change requests must be submitted to a change review board consisting of the Project Manager and XXX for the client.

TOOLS, TECHNIQUES AND METRODOLOCIES

This optional section states whether any unusual QA tools or techniques are being used. If only reviews, audits and testing are being used then there is no need for this section.

RECORDS COLLECTION, MAINTENANCE AND RETENTION

This optional section states how QA data is to be collected and stored. This is not necessary if the only data stored is review, audit and test reports stored in the project file. If other QA data is to be collected and stored then this section should state how this is to be done.

GFG IT-UK-99-SO 104/0.02	3 of 17	4 February 1998

Quality Assurance Plan for Client_name	GFG Microsystems Limited

Project Name project name	Number: XXXX

PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXX

PROJECT QUALITY ASSURANCE PLAN FOR CLIENT COMPANY PROJECT XXXX

Gerald McMullon

1999-02-02