|5 Regulations Submodel Quality Assurance|
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.)
Some of the constructive/preventive measures are:
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.
|Assessment Activity||Generation of Product||QA Representative||Assessor||Customer/User|
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.
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|
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:
Figure 5.3: Overview of Functions in Submodel QA
Which SD products contain the relevant requirements depends on the corresponding level:
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|