Quality assurance procedure

Quality documents

This page presents a summary of various quality documents used within a quality assurance procedure. 

QI.1 Quality Plan

The Quality Plan defines all the measures that will be taken in order to ensure the good quality of the project.

Normally, a Reference Quality Plan should pre-exist in a software company or in an IT department. It defines in a general way how the quality should be managed for a project of the same type. It is important to run a policy improving continuously the Reference Quality Plan by taking regularly the experience into account. In this way, the average projects quality will go improving.

The Reference Quality Plan includes often a set of forms and of standard documents that will make the quality management easier during particular projects.

The Reference Quality Plan is the base for the writing of the Project Quality Plan . This one describes the way the quality will be managed during one particular project.

You could very usefully start writing the Project Quality Plan during the commercial phase; it could already be an appendix of the contract. Indeed, this document is the thinnest definition of the mutual obligations, and the way every part agrees to manage the project together.

Anyway, the Project Quality Plan must be finalized during the startup phase of the project.

The Project Quality Plan is a synthetic document covering all the project activities. Typically, it covers up all the topics discussed hereafter; it can either describe them directly, or make reference to appendices describing them.

 Key factor: it is important to have one unique reference document, that describes all the obligations of all concerned parts. The Quality Plan will thus be the common reference in case of trouble.

 Key factor: the Quality Plan is also useful to let all parts concerned by the different aspects of the project life agree together. This should reduce the later troubles.

 Set up the general project description

 Key factor: make sure that all participants have the same understanding of the project and of its critical elements

 Describe the project, its purposes, its context and history

 Main project constraints: budgetary limits, time limits

 Describe the project scope limits: what will not be performed according to the contract

 Identify the main risk and success factors

 Set up project plan

 describe the project steps (project work breakdown structure)

 At every step, associate:

 a planning and dates

 deliverables

 control points

   Fix the common responsibilities and the dependencies

 Describe the responsibilities of every concerned part

 In particular, when the project has an interface with an existing system, identify its impacted components and describe the required updates.

 Key factor: the involvement of the customer or end-user is often underestimated although it is a critical element in the success or failure of the project. It is here that you should identify and quantify what his involvement will have to be. Here follows a set of activities that may require his active intervention:

 to give all the material support to the realization and to the launch in production:

offices, office furniture

computers and equipment

 To deliver the required information

If necessary, he should document the current procedures and applications, when the are managed only by habit or oral tradition.

 To validate the detailed specifications

 To supply the test data

 To modify or adapt other applications upstream and downstream

 To participate to the tests and the acceptance procedure

 To modify, correct or adapt the internal procedures

 To organize and take part in the training sessions

to write user guides adapted to the real business cases, vade-mecum and other practical documentation

 To enter the master data and other basic data

 To set up the production environment

 Describe the limits of the available resources, particularly where you know that the situation is not ideal

You should altogether take account of these limits and measure their negative impact on the project.

  Describe the realization actions that will be performed during the project

  Deliverables Inventory

 describe in an exhaustive way, under an inventory form, all what must be produced or realized during the project: realizations (function points) and documentation.

 detailed specifications: describe the way the detailed specifications will be produced and approved.

 Change Requests

define the way specific requests will be judged as being within the project scope, or on the contrary as justifying a price supplement.

describe the way change requests will be managed.

 Describe the procedures and methods that will be applied

Show in the Project Plan; that these methods answer the quality purposes, that they are well documented and well known by the various participants.

  Describe the project management actions that will be performed during the project

set up the various organs in charge of the project management, this is charged to care that the forecasted realizations are effectively performed within the allocated time limits and budget

fix the project reports: contents and distribution list

  Describe the quality assurance actions that will be performed during the project

fix the quality purposes

fix the guide lines about the way the quality control need being performed; this is how the different tests will be performed, how the acceptance will be said, how the nonconformities will be managed. These guide lines fix the way the Acceptance File and the Nonconformities File will be set up in the future.

In particular, it is important to define:

which non conformity statuses will lead to the acceptance refuse (blocking errors)

which non conformity statuses will lead to an acceptance under reserve (non blocking errors)

   Assign the individual responsibilities and the human resources

 Each part should assign human resources in number and in quality in order to meet its responsibilities and to realize its part of the activities.

precise as much as possible, the days forecasted for the meetings and workshops and the duration, so that the commitment can be done with full knowledge of the facts

 Name the people in charge of the three actions types:

realization actions

project management actions

quality assurance actions

    Set up the bases of the documents management

 Give an inventory of the contractual documents and other reference documents

 Give the norms to produce and reference the various project documents

QI.2 Acceptance File - Acceptance Journal

 The Acceptance File is the turntable of the quality assurance.

 The Acceptance File is based upon a synoptic table called Tracing Matrix

  The Tracing Matrix starts from the previous Deliverables Inventory : at each recorded function point, you link all his components.

The components include also the documentation !

  Every element of the Tracing Matrix needs being tested. The Acceptance File is finally the synthesis of all test results.

   The Acceptance File must allow to perform a double control before setting any component in production:

   One single function point may only be set in production when all his components have been accepted.

  One single component may only be set in production when all components of all the impacted function points have been accepted.

This second remark is mainly valid in case of update of an existing operational system.

This requires thus to follow-up the components version and the constraints existing between the function points and the components versions.

Example:

The Function Point FP1 (change the date format Y2K in the billing system) has got 3 components:Change the 'Invoices' table, change the billing program, change the bills printing program.

The Function Point FP2 (change the customers dunning system) has got 3 components:Change the 'Invoices' table, change the dunning program, use a new printing form with enlarged date column and other enhancements.

The Function Point FP3 (conversion of the existing invoices) has got 2 components: change the 'Invoices' table, write a conversion program to adapt the existing invoices to the new date format.

It is evident that all 3 Function Points need being set in production together, when all their components have been accepted.

Often, you could thus group mutually dependent function points into one 'release' or 'project'.

The acceptance file allows also to a give a well defined objective framework to the evaluation and to the nonconformities management: the errors are evaluated following their importance on the right functioning of the function point. The weighting is given by agreement between the supplier and the customer, or following rules predefined in the Quality Plan

 When all its components will have been accepted, the acceptance files notes the final result of the function point tests; signatures.

  The Acceptance Journal completes the acceptance file. It includes a detailed document for every point to be accepted, belonging to the tracing matrix

 Inventory of the elements tested for this component: input screens, calculation formulas, output data, output reports, sub-functions chains, etc.

The components are often programs. Here, you should detail every procedure point, in order that everything is tested in details.

 Description of the way the tests should be or have been performed: reference to test games, or tests on real data, operation to be performed, etc.

 Name of the persons performing the test or in charge of the nonconformity correction.

 Tests history: date, result, actions to be taken, planning date for the nonconformities correction

 Final result of the component tests; signatures.

 The synthetic acceptance file includes the following information:

 Inventory of the tested function points, to be compared with the tracing matrix

 Synthesis of the function points tests: date, result, number of performed tests

 Signature for the global acceptance, with possible reserves.

QI.3 Internal validation tests file.

The internal validation tests file is similar to the Acceptance File .

It is usually not transmitted to the customer nor to the end-user. The only people in charge of these tests belong thus to the development team.

QI.4 Nonconformities file

At the end of the acceptance, the remaining nonconformities are collected in the Nonconformities file.

It goes obviously about the non blocking nonconformities, as their error status allow an acceptance under reserve.

The nonconformities file is similar to the Acceptance File . Its only purpose is to bring clearly to the fore what remains to be delivered.

QI.5 Changes follow-up file

The changes follow-up file can be used for an operational application.

It is fairly similar to the Acceptance File .

You should insist on the link between the updated components, always critical in such a case. A good versions management tool can be useful.

You can add the following data:

 change origin: name of the requesting people

 change reason

  if applicable, identify in function of the request origin and reason whether it goes over a correction under warranty, or over an upgrade, and to which budget the cost of change must be allocated.

 priority

 evaluation of the resources and costs

 time limit / date to set in operation.