The QA Plan contains the general definitions with regard to prevention and proof activities (methods, tools, sequences of operation) valid for the entire project. Planned are constructive measures to reach the desired quality, preventive measures to avoid quality risks, and analytical measures to prove that quality requirements have been fulfilled.
1. General Information
2. Desired Quality and Risks in the Project
2.1. Quality Goals for Products and Processes
2.2. Quality Risks
2.3. Measures Based on Quality Goals and Risks
3. QA Measures according to Criticality and IT Security
3.1. Applied Rules or Standards
3.2. QA Measures based on Classifications
4. Quality Assurance during Development
4.1. Products to be Assessed
4.2. Activities to be Assessed
5. Special Control Measures
5.1. Entry Control of Off-the-Shelf Products
5.2. Controlling Subcontractors
5.3. Software Item Exit Control
5.4. Change Control
5.5. Controlling Working Responsibilities
5.6. Controlling the Configuration Management
See schema 1. General Information.
The project goals fixed in the project order must be considered from a quality assurance point of view; they must be weighted according to the project criteria and marginal conditions, so measurable quality goals can be defined for the project and its products.
Quality risks that exist when the project goals and criteria have to be met under the given marginal project conditions, must be documented, weighted and analyzed.
This includes measures required for reaching and controlling the quality goals as well as for the prevention and elimination of quality risks.
All rules and standards relevant in the project that refer to the criticality and to IT security must be listed:
This chapter lists all measures to be realized on the basis of classifications of criticality levels and IT security.
- Definition of criticality and its levels
The definition contained in the V-Model that might be adapted with regard to the actual project must be used as basis. In accordance with the customer, it is possible to select a definition of appropriate existing standards (e. g. /RTCA-178B/); in this connection, any specifications possibly set down in the Project Manual already have to be taken into consideration.
The criticality of the System, the defined fields, and the structure elements they are based on are specified in the User Requirements. The criticality classification of the function units Segment and SW Unit or HW Unit is realized in the Technical Requirements. The classifications of the criticality level for the functional units SW Component and SW Module are defined in the Software Architecture.
- Definition of IT security-relevant levels as well as setting up evaluation levels and the required strength of IT security mechanisms
In this connection, reference is normally made to a published criteria catalogue, and the project-specific interpretation of the corresponding regulations is realized.
With regard to criticality, this is defined with the help of a criticality/methods matrix consisting of two submatrices: one matrix for constructive (specifications with respect to generation) QA methods and one matrix for analytical (specifications with respect to assessment) QA methods. Examples for both of these matrices can be found in Part 3 Collection of Manuals of the V-Model (Safety and Criticality manual).
For every criticality level, the constructive QA methods agreed will be set up in the matrix for constructive QA methods. According to the definition in this matrix, the activities of the submodel SD (in special cases also the other submodels) have to be carried out.
For every criticality level, the analytical QA methods agreed will be set up in the matrix for analytical QA methods. According to the definition in this matrix, the products generated by the submodels system development, quality assurance, configuration management, and project management will have to be assessed.
Depending on the IT security-relevant levels, requirements must be covered by QA; they can be found in the corresponding criteria catalogue and have already been listed in the Project Manual. These requirements and the resulting QA measures are specified with regard to the actual project.
All generic products to be assessed by QA must be listed.
All generic activities the conformity of which has to be proved by process assessment with specified rules (standards, guidelines, methods) must be listed here.
Off-the-shelf-products are software packages which already exist. This may refer to:
According to the planned purpose, it is necessary to differentiate with regard to:
- purchased software, e. g. library programs, test monitor, operating systems,
- usable software that has been developed in the same company, but not within the current project.
The individual checks have to be stated in a list of measures which depend on the use of the software (e. g. criticality). In any case, it is important:
- off-the-shelf products integrated into the functionality of the System, and
- off-the-shelf products used for the development process.
If necessary, an off-hand sample-like test has to be defined (in the case of high criticality, however, a complete QA cycle).
It must be defined which implementation guidelines the subcontractor must adhere to. By means of implementation guidelines like this
- to guarantee the identification of manufacturer and product,
- to check if the documentation is available according to the project guidelines,
- to check if sufficient quality assurance measures have been carried out and if (and in which cases) this has yet to be done.
have to be stipulated.
- the size of the documentation and
- the development standards
The control measures for the subcontractors must also be defined:
The tasks with regard to documentation, assessments, and acceptance control (in addition to the activities accompanying the project) will be specified for the various delivery types.
The QA specifications with regard to the change control procedures and the QA assessments in these procedures will be stated. The change management itself will be specified in the product CM Plan.
This describes the procedure to control the working responsibilities. This particularly refers to the access to the product library. The access rights themselves will be determined in the product CM Plan, however.
The methods used in the configuration management must be controlled. This includes the supervision of backup of results and archivation.
- accompanying assessment of the development
- acceptance control for developed products
- specifications for the internal subcontractor assessments
Note: The CM Plan describes the respective procedures, e. g. backup of results and archivation; the QA Plan, however, describes the corresponding control measures, e. g. for the proper backup of results.
Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
Mail 0632 - Produktstatus Projekthandbuch (632)
Mail 0585 - QS-Plan - 5.1 Eingangskontrolle von Fertigprodukten (585)
Mail 0406 - Re: Kritikalitaeten/Funktionen-Matrix (406)
Mail 0286 - Re: Organisationseinheiten im QS-Plan / Pruefplan (286)
Mail 0273 - Organisationseinheiten im QS-Plan / Pruefplan (273)
Mail 0173 - Re: QS-Plan nach V-Modell 97 (173)