![]() |
![]() |
![]() |
|
![]() |
|||
| QS 4: Produktprüfung |
Inhalt
|
|
|
|---|
Produktfluß
| von | Produkt | nach | Methoden | Werkzeug Anf. | Ext. Normen | |||
|---|---|---|---|---|---|---|---|---|
| Aktivität | Zustand | Kapitel | Titel | Aktivität | Zustand | |||
| SE, QS, KM, PM |
akzeptiert | Alle | Zur Konsistenzprüfung erforderliche Vorgängerprodukte | - | - |
/ISO IEC 12207/
Supply Proc.: Devlp. Proc.: Operation. Proc.: Maintenance. Proc.: Doc. Proc.: Audit Proc.: |
||
| SE, QS, KM, PM |
vorgelegt | Alle | Prüfgegenstand | SE, QS, KM, PM |
in Bearb./ akzeptiert |
REV SIMU (1)/ (2) STAT (3) T (4)/ (5) |
||
| QS1 | akzeptiert | Alle | Prüfplan | - | - | |||
| QS2 | akzeptiert | Alle | Prüfspezifikation | - | - | |||
| QS2 | akzeptiert | Alle | Prüfprozedur | - | - | |||
| - | - | Alle | Prüfprotokoll | QS5 | - | |||
+ "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250
Abwicklung
Abbildung 5.6: QS4 - Produktprüfung
Führt die Aktivität QS4.1 - Prüfbarkeit feststellen für einen Prüfgegenstand zu einer negativen Entscheidung (Prüfbarkeit ist nicht gegeben), so geht der Prüfgegenstand nach SE, QS, KM bzw. PM zurück und muß überarbeitet werden.
Ergebnis der inhaltlichen Produktprüfung ist das Prüfprotokoll, aus dem unter anderem zu ersehen ist, ob das Produkt den Zustand "akzeptiert" oder "in Bearb." erhält.
Das Projektmanagement ist über das Prüfergebnis zu informieren.
Es ist darauf zu achten, daß der Prüfgegenstand nicht vom Prüfenden selbst erstellt wurde.
Rollen
| Rolle | Beteilungsarten | ||
|---|---|---|---|
| Prüfer | verantwortlich (QS4.1,
QS4.2)
| QS-Verantwortlicher |
mitwirkend (QS4.1)
| |
Teilaktivitäten
Werkzeuganforderungen
Externe Normen
| Norm | Prozeß | Kapitel | Bemerkung |
|---|---|---|---|
| /ISO IEC 12207/ | Supply Prozeß | Review and Evaluation | (s. Part 3 - ISO 3.2.1) |
| Development Prozeß | System Requirement Analysis | (s. Part 3 - ISO 3.2.1) | |
| System Architectural Design | |||
| Software Requirement Analysis | |||
| Software Architectural Design | |||
| Software Detailed Design | |||
| Software Coding and Testing | |||
| Software Integration | |||
| Software Qualification Testing | |||
| System Integration | |||
| System Qualification Testing | |||
| Operation Prozeß | Operational Testing | (s. Part 3 - ISO 3.2.1) | |
| Maintenance Prozeß | Maintenance Review/ Acceptance | (s. Part 3 - ISO 3.2.1) | |
| Documentation Prozeß | Design and Development | (s. Part 3 - ISO 3.2.2) | |
| Audit Prozeß | Audit | (s. Part 3 - ISO 3.2.2) |
Verknüpfungen mit der V-Modell Mailingliste
(2) Die Methode SIMU ist anzuwenden, wenn der Test den Leistungs- und Fehlernachweis nicht alleine vollständig erbringen kann, da u.a. spezifische Einschränkungen, Annahmen und Umweltbedingungen berücksichtit werden müssen.
(3) Die Methode STAT ist anzuwenden, wenn Inhalte des Prüfgegenstandes nach einem vorgegebenen Formalismus aufgebaut sind.
(4) Die Methode T ist anzuwenden, wenn Inhalte des Prüfgegenstandes nach einem vorgegebenen Formalismus aufgebaut sind, der eine dinamische Ausführung erlaubt.
(5) Die Methode T ist anzuwenden, wenn automatisierte Prüfprozeduren eingesetzt werden sollen.


This page online
GDPA Online
Last Updated 07.Feb.2003 by
C. Freericks