Mail 0138

1996-1997-1998-1999-2000-2001-2002

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

> From:          "STAPELBERG.MAX" 

Lieber Herr Stapelberg, 
hier kommt die Anwort auf Ihre Anfrage. Etwas spät, aber ich hoffe 
nicht zu spät.

> Dokumentenvolage Pruefspezifikation
> 
> Kapitel 4. Pruefkriterien
> Kapitel 4.1. Abdeckungsgrad
> Wie kann ich den Abdeckungsgrad für die Pruefung des Gesamtsystems festlegen ?
> Eine Angabe ueber SW-Pfadabdeckung halte ich auf System-Level fuer unsinnig, 
> da auf System-Ebene hauptsaechlich operationelle Forderungen getestet werden. 
> Einzeilne Pfade der SW, die dann durch diese operationelle Forderung ausgefuehrt 
> werden, sind im Gesamt-System nur schwer - eher gar nicht - nachvollziehbar.
> Ist es ausreichend in Kapitel 4.1 zu schreiben:
> 
> 100 % der Funktionen des Systems (alle geforderten) werden bezogen 
> auf den Normalfall getestet.
> 
> 100 % der Funktionen des Systems (alle geforderten) werden bezogen 
> auf mindestens einen Fehlerfall getestet.

Sie haben sicherlich Recht mit Ihrer Feststellung.
Auf Systemebene sind nur funktionale (Blackbox-Tests) möglich. Der 
Test auf dieser Ebene erfolgt durch die Prüfung aller Anforderungen. 
Hier wäre es wichtig, eine Zuordnung Anforderungen <-> Testfälle 
anzugeben.
Diese Requirement-bezogene Art des Testes gilt noch für die 
Segment-Ebene (falls existent) und die Ebene der SW-Einheiten.
Unterhalb dieser Ebene werden Software-Komponenten und Module 
getestet. Diese werden aber mit Whitebox-Tests überprüft. Hier 
sollte dann die Pfadabdeckung angegeben werden.

> Kapitel 4.2 Checkliste
> Braucht man auf Systempruefungs-Ebene Checklisten fuer die Pruefung 
> oder reicht ein Verweis auf die Anwenderforderungen aus. 
> Wie sieht beispielhaft eine Checkliste für die Systempruefung aus?

Eine Eigenheit der Prüfspezifikation des V-Modells ist es, daß hier 
funktionale Prüfungen für das System, die Segmente, SW-Einheiten, 
SW-Module und Komponenten enthalten sind, aber auch die Prüfung für 
die Dokumentation des Systems. Im Teil "Checklisten" werden die 
Prüfkriterien für Dokumente, wie die Anwenderforderungen, die 
Systemarchitektur, die Technischen Anforderungen etc. aufgeführt.
Eine Auswahl an Prüfkriterien für diese Dokumente finden Sie auf den 
Seiten 8-38, 8-39.

> Dokumentenvorlage Pruefplan
> 
> Kapitel 2 Pruefgegenstaende und Qualifikationserfordernisse

Prüfgegenstände ist klar.

> Was genau sind Qulifikationserfordernisse ?

Qualifikationserfordernisse meint "besondere Anforderungen" an 
Prüfungen.

> Woher stammen diese ? (Vom Kunden oder aus Standards oder 
> aus Entwicklungsdokumenten?

I.d.R. vom Kunden.
Haben einige Ihrer Systemteile eine höhere Kritikalität, so sollten 
diese Systemteile intensiver geprüft werden als die nicht-kritischen 
Systemteile.

> Koennen Sie ein paar Beispiele nennen fuer Qualifikationserfordernisse.

M. E. ist hier im Wesentlichen die Kritikalität gemeint. Es könnten 
aber auch nicht-funktionale Q-Merkmale wie Robustheit, Effizienz, 
Portabilität, Benutzerfreundlichkeit etc. gemeint sein.

> Es sind doch nicht die Qulifikationserfordernisse des Pruefers
>  gemeint? (breites Systemwissen, C++ Kenntnisse etc.)

Nein, auf keinen Fall. 

> Kapitel 3 Aufgaben und Verantwortlichkeiten
> Ist hier mehr gefordert als die Tabelle 5.1  in Kapitel 5.1.3 
> im Regelungsteil des Submodell QS ?

Ja, hier soll angegeben werden, wer prüft das System, wer prüft 
welche Segmente oder SW-Einheiten? Wer prüft die Softwareteile?

> Kapitel 4 Zeitplan
> Ist hier gemeint generelle Aussagen fuer die Zeitplanung von
>  Pruefungen zu treffen ? (z.B. alle Dokumente werden innerhalb 
> 2 Wochen nach Erstellung geprueft.)

Wenn Sie Sie komplexe Prüfungen haben, die u. U. nur in Verbindung 
mit anderen z. B. bereits existierenden Teilen geprüft werden 
können, dann ist eine Prüfplanung wichtig. 

Für normale SW-Systeme ist ein Prüfplan nicht erforderlich und 
sinnvoll. Bitte beachten Sie die Tailoring-Vorgaben in der 
Handbuchsammlung. Hier wird selbst für große Projekte kein Prüfplan 
gefordert. Die Prüfungen können auch im Rahmen der normalen 
Projektplanung mitgeplant werden.

Ich würde einen Prüfplan nur für große Projekte mit Hardwaresystemen 
und hohem Abstimmungsbedarf verwenden.

> Wenn konkrete Termine notwendig sind ( Review Systemarchitektur
>  20.10.97 9.00 bis 15.00), sollten diese in den Terminplan des
>  Projektplans integriert werden ?

Ich meine, daß dies voll ausreichend ist (Feinplanung PM 4).

Viel Erfolg in Ihrem Projekt.

MfG

Klaus Plögert
(V-Modell-Support)
-- 
Dr. Klaus P. Ploegert
IABG (Industrieanlagen-Betriebsgesellschaft mbH)
Information Systems, IS23                                
D-85521 Ottobrunn, Einsteinstr. 20 
E-Mail: ploegert@iabg.de
Tel: +49-89-6088-3420
Fax: +49-89-6088-3418
CompuServe 100655,3717

Links to V-Model

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