5 Regulations Submodel Quality Assurance



		5 Regulations Submodel Quality Assurance

5 Regelungen Submodell Qualitätssicherung

Contents
5.1 Overview
5.2 The Activities of Submodel QA

Contents		5.1 Overview 5.2 The Activities of Submodel QA

5.1 Overview

The Regulations of submodel quality assurance (QA) have no impact at all on organizational definitions. The V-Model does not include regulations about how the activities of submodel QA have to be executed in a project by a person or organizational units.

Quality is defined as "all characteristics of a unit with regard to its suitability to meet defined and expected requirements" (/ISO DIS 8402-1, 91/).

During the course of the project the specified requirements for the System to be developed will be refined by more detailed requirements and documented in the products User Requirements and Technical Requirements . The measures described in submodel "quality assurance" (QA) help that those given requirements are met, that faults are prevented, and that the process quality is guaranteed.

On the one hand, it is possible to assure software quality by applying constructive quality assurance measures (cf. section 5.1.1 ).

On the other hand, constructive quality assurance measures are supplemented by analytical quality assurance measures (cf. section 5.1.2 ).

In projects where orders are given to external (industrial) contractors, suitable contracts should be set up so that the customer is allowed to participate adequately in the quality assurance measures. (This participation has to be documented in detail in the QA Plan.)

5.1.1 Constructive Quality Assurance Measures

Quality cannot be achieved by assessing an already completed product. Therefore, it is vital that maintaining quality is fostered by constructive quality assurance measures. The objective must be to prevent quality-relevant risks, to counteract quality deficiencies in the first place, and to make the objects to be assessed by analytical quality assurance measures in such a way that they can be assessed.

Some of the constructive/preventive measures are:

the structure of the development process by means of a SW development standard
the support of the development process by methods and tools

Constructive/preventive quality assurance measures are defined in submodel QA; the application of constructive measures takes place in submodel SD. Figure 5.1: Constructive and Analytical Quality Assurance Measures shows the relationship between the submodels SD and QA with regard to constructive quality assurance measures.

5.1.2 Analytical Quality Assurance Measures

The objective of analytical quality assurance measures is the assessment, evaluation and the (external) quality proof of the objects to be assessed. They are both defined and realized in submodel QA. Analytical quality assurance measures refer to products and activities of all submodels. Figure 5.1 illustrates the connection between the submodels SD and QA with regard to analytical quality assurance measures.

Figure 5.1: Constructive and Analytical Quality Assurance Measures

The analytical measures to be applied in the V-Model can be displayed in the form of a hierarchy of terms (see Figure 5.2: Terminology "Assessment").

Note:
The evaluation (e. g. IT security) is an analytical quality assurance measure, too. However, this measure is realized by an impartial, authorized and independent organization and is not regulated in the V-Model. The evaluation may either be carried out after completion of the development or as accompanying evaluation.

Figure 5.2: Terminology "Assessment"

5.1.3 Allocation of Roles during the Realization of Assessment Activities

Different roles participate in different assessment activities (see Table 5.1: Participation of Roles in the Assessment Activities):

Assessment Activity Generation of Product QA Representative Assessor Customer/User
Self-Assessment r
Process Assessment r c
Product Assessment a c r
Validation c r c

Assessment Activity	Generation of Product	QA Representative	Assessor	Customer/User
Self-Assessment	r
Process Assessment		r	c
Product Assessment	a	c	r
Validation		c	r	c

Legende:
r responsible
c cooperating
a advising

Table 5.1: Participation of Roles in the Assessment Activities

5.1.4 Classification of QA Activities

The activities of the submodel QA can be classified as follows:

planning activities,
assessment activities, and
monitoring activities.

In the planning activities (QA1 - QA Initialization, QA2 - Assessment Preparation) both general and product-specific quality assurance measures are defined. This way, proofs and monitoring activities are only made possible.

Assessment activities (QA3 - Process Assessment of Activites, QA4 - Product Assessment) are proof activities. They help to control generated products and performed activities. Only after the proof activities have been successful (the product changes into the state "accepted") these products are allowed to be used for the development of other products.

In the monitoring activities (QA5 - QA Reporting), PM is informed about possible problems. All occurring errors are collected, classified and analyzed. If the same type of problems occur often then the reason for these problems shall be investigated within the scope of QA. Possible corrective actions will be given. The results of the assessment activities yield reliable information required for the monitoring.

5.1.5 Instantiations of Assessment Activities

In order to present the possible instantiations of assessment activities, it is necessary to clearly differentiate between (formal) assessments used to externally prove assessment results, and between assessments that are used for the internal proof at the end of the processing.

The assessment at the end of a processing is called self-assessment and is realized in submodel SD.

The responsibilities of the developers resulting from the realization of self-assessments must be defined.

The following classification serves as an example:

Type of Specification for the Developer Responsibilities of the Developer
No specification (except general comprehensibility) Documentation in a free form
Statistical specifications (e. g. minimum coverage) to realize assessment Documentation must meet specifications
Full specification of preparation, realization and evaluation of assessment Assessment Report according to QA Submodel

Type of Specification for the Developer	Responsibilities of the Developer
No specification (except general comprehensibility)	Documentation in a free form
Statistical specifications (e. g. minimum coverage) to realize assessment	Documentation must meet specifications
Full specification of preparation, realization and evaluation of assessment	Assessment Report according to QA Submodel

Table 5.2: Possible Levels for Processing Self-Assessment

The handling of the self-assessment according to the exact specification differs from the (formal) assessment only in the fact that the assessment activities have to be carried out by the developer. (In this case the developer must be given all relevant assessment information by QA, i. e. Assessment Specification and Assessment Procedure.) Handling self-assessments according to the exact specification does not render the formal assessment unnecessary, however.

The (formal) assessment is realized according to the regulations of the submodel QA. This assessment is a proof activity such that it is also possible for outsiders to check that the assessed object meets all specified requirements. If the assessment activity is successful the object to be assessed is classified as "accepted". The assessment is realized according to the Assessment Plan, Assessment Specification, and Assessment Procedure.

With regard to (formal) assessments, it is necessary to differentiate between various types of (organizational) realization. It depends on the organizational project structure (e. g. on the technical competence and manpower of "QA Manager") and also on the conditions of the project (e. g. if assessment activities can be isolated), which kind of realization to choose for the current project. In the following description the term "QA Manager" always means a role (as explained in the Part 3: Concept of Roles in the V-Model).

The participation of the QA manager in a (formal) assessment may take place in either of the three types (participation types) B1 to B3:

B1 The QA manager carries out the formal assessment himself and decides about acceptance ("accepted") or rejection ("b. proc.").

B2 The QA manager supervises the assessment activities and decides about acceptance ("accepted") or rejection ("b. proc."). The assessment activities themselves are carried out by a member of the development team.

B3 The QA manager decides about acceptance ("accepted") or rejection ("b. proc.") of the assessment based on the assessment documentation alone. The assessment activities themselves are carried out by a member of the development team without the presence of the QA manager.

5.2 The Activities of Submodel QA

QA1 - QA Initialization ,
QA2 - Assessment Preparation ,
QA3 - Process Assessment of Activites ,
QA4 - Product Assessment ,
QA5 - QA Reporting

Figure 5.3: Overview of Functions in Submodel QA

Note about Figure 5.3:

Which SD products contain the relevant requirements depends on the corresponding level:

System and Segment Levels

SW/HW Unit Levels

Component Level

Module/Database Levels

GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster