Checklist for QA Plan

1.1 Purpose of the document
What is the QA plan used for? - Formulation proposal:
The purpose of this document is to document all planned quality assurance and environment protecting measures for project <xyz>. It therefore serves as a reference document for all members of the project team in implementing and verifying all QA-related activities (reviews, tests, corrective and preventive measures, quality reports, etc.).

1.2 Validity of the document
This section must specify the areas of the project to which the QA plan applies. The following points must be covered:

• Does the plan apply to the entire project or only for specific parts/areas of the project?
• Are subcontractors included or not?
• Does the plan apply to the entire course of the project or only to specific phases?
• Do any links exist to the client’s QA system; if so, how are these regulated?

1.3 Definitions of terms and abbreviations
This section must define all important terms and abbreviations occurring in this document. Two terms which are frequently misunderstood are shown below by way of example:

Quality requirement:
Requirement on the quality of a product (e.g. with regard to reliability or portability; originating from the software requirements specification).

Quality assurance requirement:
Requirement on quality assurance during product development (e.g. with regard to the conducting of tests or inspections: QA requirements can originate from the software requirements specification or from specifications of the development method or within the project from the analysis of problem areas).

This section must show the links to the project organization (project plan) and further quality-relevant plans (test plan, CM plan, poss. review plan, etc.) and to other QA requirements (e.g. QA requirements for a superordinate project or the business unit; QA process manual, QA manual).

This section must provide a concise overview of the project; redundancies relating to the project plan and software requirements specification must be avoided as far as possible.

2.1 Project designation
The project designation selected in the Initiation phase is specified in this section. This designation is used in all documents and data (including PROWEB) to uniquely identify the project.

2.2 Project organization
This section sets out the selected areas of responsibility within the project, all project instances and the relevant persons responsible. It can also refer to another plan - generally the project plan - but the following must be specified expressly:

• Project manager (person responsible for the overall project) and the responsible organizational unit
• QA manager - must not be the same as the project manager
• Quality manager for the organizational unit
• Client and contact persons at the client’s
• Customer and contact persons at the customer's

2.3 Brief description of the project
This section must either describe in brief the required project result (product) and the selected type of project execution (e.g. releases, version development, etc.) or make appropriate references to the description in the software requirements specification or the project plan.

This information must show the type of project involved (e.g. large-scale online system, real-time system, small PC software, services, etc.), but must primarily identify the quality requirements to the product (from the software requirements specification). This ensures that the QA requirements and QA measures are easier to evaluate and understand.

Derived from the QA requirements and the general project goals also project-specific quality goals and the related metrics have to be defined, if necessary.

Quality assurance requirements are requirements which are made on quality assurance during the course of the project (not the requirements on the quality of the product!). Environmental management requirements are requirements reflecting the implementation of the regulation ISO 14001 onto the course of the project.

3.1 QA requirements, environmental management requirements on the part of the client
This section must specify all the client’s QA requirements which are known to date. If these are already specified in full in the user requirements specification or software requirements specification, a reference to this document will be sufficient. If the client also has requirements from the environmental management, these also have to be considered here. If no environmental requirements are required a corresponding reference is recommended.

Typical quality assurance requirements include:

• Requirements relating to code reviews in the form of intensive inspections for specific SW components
• Test certificates for execution of stand-alone tests
• Attainment of a specific test coverage or obtaining of an official safety certificate for safety-relevant software (with all the certificate obligations associated with this)
• Inclusion of the client into reviews of certain documents

HINT FOR OBJECT-ORIENTED SOFTWARE DEVELOPMENT:

When developing object-oriented software, OOA and OOD model reviews may be required.

These requirements also include requirements relating to the quality assurance documentation for the client (quality reports, inspection of review reports and other internal documents).

3.2 General QA requirements, environmental requirements
The quality management or business-unit-specific regulations will generally set out additional quality assurance requirements which must be listed in this section and lead to specific measures (section 5), e.g.:

• Quality reporting
• Corrective and preventive measures
• Checking customer-/client-supplied products
• Checking subcontractors
• All QA measures required by the development method

Resulting from environmental requirements additional general requirements may be:

• Reduction of paper consumption in the project
• Saving energy

3.3 QA requirements, environmental requirements resulting from problem areas
This section is used to identify problem areas so that these can be used to derive possible requirements and measures. Possible sources for problem areas include:

• Quality requirements of the customer/client (product quality requirements defined in the software requirements specification, e.g. requirements relating to reliability against failure or user-friendliness).
• Problematic technical requirements (from the software requirements specification).
• Problematic project constraints (from the provisional project planning, e.g. know-how of staff, "impossible" deadlines, requirements relating to "cheap solutions involving no quality assurance").

The analysis of these problem areas generally gives rise to quality assurance requirements which should be listed in this section and should lead to specific measures (section 5), e.g.:

• Intensive inspections for "critical" code parts
• Usability tests using prototypes
• Test planning as early as possible
• Performance tests as early as possible
• Additional HW tests for production
• Planning of multi-stage pilot application
• Use of redundant systems
• Taking account of technical specifications in the product’s operations environment
• Etc.

3.4 Guidelines, conventions, methods and tools
If special guidelines (e.g. programming guidelines), conventions, methods or tools are to be used in the project, these must be described in this section or reference made to the relevant documents (these requirements can originate from various sources, e.g. client, business unit, internal considerations in the CM plan, etc.).

Examples include:

• National and international standards (e.g. ISO, EN,  )
• Definition of the programming language(s) used
• Programming conventions for a programming language (e.g. name conventions)
• RR conventions
• Document templates
• Definitions relating to distribution lists (how are distribution lists generated?)
• IS guidelines
• Etc.

  HINT FOR OBJECT-ORIENTED SOFTWARE DEVELOPMENT:

In this section also the definition of OOA and OOD method used should be used.

Please refer also to our collection of guidelines and style guides.

3.5 Specifications for metrics
Insofar as relevant, this section must set out specifications for metrics (e.g. metrics for tracking the project goals, information on the expected and actual size of documents and code, error rates, residual error rates, etc.).

This section must specify the development method for the project, its derived method (e.g. stdSEM in the case of SEM) and all specifications selected in this model (e.g. subphase definitions, selected life cycle approach, etc.). A method other than SEM can naturally also be specified (usually if this method does not support an own QA plan, since the QA plan must then be drawn up on the basis of SEM).

If deviations from the regulations and specifications of the selected derived method are planned during the project-specific tailoring, these must be specified in this section and the reasons for such specified (e.g. reasons for non-compliance with required provisions, definition of project-specific milestones, etc.).

This section must describe the specific QA measures and, if applicable environmental measures for the project (key component of QA plan).

5.1 Project-internal measures
A key aspect of QA planning is the definition of the quality assurance measures which derive from the development model and the quality and quality assurance requirements and which need to be planned and executed.

Associated with this is the evaluation of the QA data which are generated and possible reactions for influencing the quality of the result.

This gives rise to general, phase-specific and milestone-specific QA measures which must be planned, executed and documented.

The results of the planning work are best summarized in list form and, depending on the scope of the results, are recorded in the QA plan itself or in one or more further reaching documents (e.g. test plan, possibly also review plan). Execution of QA measures can be identified in these lists; however, other methods can also be used (e.g. documentation within the framework of the CM system).

For planning environmental measures the analog regulation in the project applies.

The planning must cover the following points:

• Category of QA measure (inspection, test, discussion, etc. - including all specific instances, such as inspection techniques, types of tests, e.g. integration test)
• Name of the item which the QA measure is applied to (e.g. detailed design, code module, test case)
• Phase/milestone

Depending on requirements, further information may also be relevant for each object:

• Scope of the item (e.g. pages, LOCs, function points)
• Persons affected
• Dates/duration/effort for preparation work (in the case of inspections)
• Dates/duration/effort for execution
• Tools required (meeting rooms, projectors, video conference equipment, test tools)
• Etc.

The following subdivision is therefore recommended for this section:

5.1.1 General QA measures
Examples for planning general QA measures:

• Description of the execution of reviews in principle (appointment for the use of a review tool, criteria for the choice of review methods, acceptance or rejection of review objects)
  Concrete tips for planning and conducting reviews can be found in the Review Web).)
• Responsibilities for updating (distribution lists, telephone lists, etc.)
• Checking compliance with standards, specifications and prescribed methods
• Planned project meetings, discussions, phase termination and kick-off meetings
• Etc.

5.1.2 Phase-specific QA measures
This section must set out in detail all measures. A subdivision based on phases and/or milestones is advisable. Examples of phase-specific measures include:

• Review of document <xyz> (software requirements specification, specifications, plans, etc.)
• Usability inspections and usability tests
• Tests for modules <xyz>, integration tests, system test
• Prerequisites for starting the follow-up phase (phase termination, permissible overlaps, etc.)
• Etc.

Examples for environmental measures:

• Documentation not in printed format
• Video conferences instead of business trips
• Etc.

5.2 Product qualification and testing
If a specific product qualification, product certification, safety certifications, official testing mark, etc. is required for the project, the qualifications and associated tests must be set out in this section.

Such a requirement itself must be set out in the software requirements specification.

5.3 Customer-/client-supplied products
Where a product is to be supplied by the customer, this must be specified completely in this section (list). This product can cover both HW and SW. All measures which we must take to check and protect this product must be listed (requirement of DIN ISO 9001), e.g.:

• Special administration, labeling, storage of supplied HW
• Check of incoming goods for completeness (ID checks), functionality, performance
• Procedure if supplied goods are lost or damaged

Reference can also be made to QA measures which have already been defined (e.g. checking of a compiler or test tool using solely the product tests in various integration stages).

The definition of supplied goods must be set out in the software requirements specification (under the requirements which the Customer/client must satisfy).

5.4 Monitoring of subcontractors
If the project includes supplies made by subcontractors, the following points at least must be set out in this section:

• Goods/services to be provided by the subcontractors (in the form of procurement documents)
• Measures for checking supplies (reviews, tests, certificates)
• Requirements made on the subcontractor’s QM system
• Measures for checking the supplier’s QM system (supplier audits, certificates)

6.1 Quality reporting system
This section must specify the quality reporting system which is envisaged and the procedure to be adopted in the event of problems occurring in project organization which cannot be resolved (quality reports, quality problem reports).

Areas of responsibility, procedures and decision-making instances in this regard are generally defined within the scope of the business-unit-specific QA reporting system; references can be made to the QA process manual.

6.2 Quality records
Quality records must be generated and kept in order to demonstrate the QA measures which have been performed and for the purpose of monitoring product quality.

To ensure compliance with the applicable QM processes (see QA process manual), this section must stipulate which documents are kept in the form of quality records and how these are handled:

• Plans (QA plan, test plan, etc.)
• Reports (quality reports, test reports, acceptance reports, etc.)
• Records (review records, test records, etc.)
• Etc.

The place where the quality records are kept, the period for which they are to be kept, and the persons responsible must be specified.

This section must document the project-specific procedure regarding corrective and preventive measures (analysis of causes and measures to prevent future errors). Examples of corrective and preventive measures include:

• Mandatory entry of the cause of the error in an error database (when reported errors are remedied)
• Improvement of documents which were earlier found to be problematical
• Training of staff in difficult subject areas
• Coaching of specialist teams (e.g. at subcontractors)

Areas of responsibility, procedures and decision-making instances are to be defined. When describing the procedure for handling defined corrective measures, reference can be made to the business unit definition or the definition set out in the QA process manual.

List of quoted literature.

This section must contain all additional documents (or information about such documents) which affect QA planning (e.g. information on product qualification, certificates from subcontractors, specified programming guidelines, etc.).