
 |
 |
1 Introduction
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). |
 |
 |
2 Project overview
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. |
 |
 |
3 QA requirements,
environmental management requirements
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.). |
 |
 |
4 Development method and
tailoring
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.). |
 |
 |
5 QA measures, environmental
measures
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 Quality reporting system and
quality records
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. |