 |
 |
 |
|
 |
|
|
8.3.3 Prüfspezifikation (PrSpez) |
|
Assessment Specification
Die Prüfspezifikation enthält die Beschreibung von Prüfanforderungen und -zielen, Prüfmethoden, von den Anforderungen abgeleitete Prüfkriterien und die Prüffälle. Die Abdeckung der Anforderungen durch die Prüffälle wird durch eine Abdeckungsmatrix dokumentiert. Mit Hilfe der Prüfspezifikation muß entschieden werden können, ob die Prüfung erfolgreich war oder nicht.
Eine Prüfspezifikation wird für jeden Prüfgegenstand erstellt - vgl. Festlegung der Prüfplan.Prüfgegenstände und Qualifikationserfordernisse.
Es ist möglich, mehrere Prüfspezifikationen zu einem Dokument zusammenzufassen.
1. Allgemeines
2. Anforderungen
2.1. Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit
2.2. Prüfanforderungen
3. Methoden der Prüfung
4. Prüfkriterien
4.1. Abdeckungsgrad
4.2. Checklisten
4.3. Endekriterien
5. Prüffälle
5.1. Prüffallbeschreibung
5.2. Abdeckungsmatrix
5.2.1. Architektur-Elemente und Schnittstellen
5.2.2. Fachliche und technische Anforderungen
Siehe Gliederungspunkt 1. Anforderungens.
Die Einstufung der Funktionseinheit (System, Segment, SW-Einheit/HW-Einheit, SW-Komponente, SW-Modul, Datenbank) hinsichtlich Kritikalität und IT-Sicherheit ist in den Entwicklungsdokumenten definiert. Sie wird von dort übernommen.
Dieses Kapitel nimmt Anforderungen allgemeiner Art an eine Prüfung auf. Beispiele hierfür sind:
- Prüfungen sind mit Normal-, Grenz- und fehlerhaften Werten durchzuführen.
- Prüfungen sind unter Normal- und Ausnahmebedingungen (Höchstleistungen, Komponentenausfall, usw.) durchzuführen.
- Prüfungen sind mit Echtdaten durchzuführen.
- Möglichst alle Ausführungsoptionen und fehlerhafte Nutzereingaben sind abzuprüfen.
Eine Prüfung unterteilt sich in die Abschnitte Vorbereitung, Durchführung und Auswertung. Werden die Vorbereitung und die Auswertung in der Prüfprozedur ausreichend beschrieben, so können sie hier entfallen.
Die Vorbereitung einer Prüfung umfaßt z. B. die Generierung von Testdaten. Die Methoden und Vorgehensweisen hierfür werden festgelegt und, sofern nicht als bekannt voraussetzbar, beschrieben.
Methoden zur Durchführung der Prüfung sind z. B. statische Analyse, Test, Simulation, Korrektheitsbeweis, symbolische Programmausführung, Review, Inspektion. Die Methoden der Prüfungsdurchführung werden anhand der kritikalitäts- und IT-sicherheitsbezogenen Einstufung des Prüflings, der den jeweiligen Stufen zugeordneten Maßnahmen und weiteren an ihn gestellten Qualitätsforderungen ermittelt.
Festzuschreiben sind die Art und Weise der Ergebnissicherung und -auswertung, insbesondere im Hinblick auf Wiederholung von Prüfungen. Es wird geklärt, welche Daten während und nach der Prüfung wie festzuhalten sind.
Die Methoden und Vorgehensweisen werden hier festgelegt und beschrieben, z. B. die Nutzung von automatisierten Vergleichsroutinen, die persönliche Begutachtung, das Führen eines chronologischen Logbuchs.
Unter diesem Gliederungspunkt werden die Kriterien jeder Prüfung genannt. Sie sind derart festzulegen, daß die Prüfung hinsichtlich ihrer erfolgreichen Durchführung bewertbar ist.
Es wird festgelegt, wie tief zu prüfen ist (z. B. Angabe über Pfadabdeckung), um die Tauglichkeit des Prüfgegenstands sicherzustellen. Der Abdeckungsgrad ist im allgemeinen von der Kritikalität des Prüfgegenstands abhängig.
Hier wird ein Fragenkatalog aufgeführt, der bei den Prüfungen von Produkten und Aktivitäten abgearbeitet wird. Die nachfolgenden Prüfchecklisten sind im Minimum je - generischem - Prüfobjekt, in kritischen Fällen jedoch für einzelne Prüfobjekte zu überarbeiten, d. h. zu ergänzen. Sie sind so zu formulieren, daß mögliche Fehler mit größtmöglicher Wahrscheinlichkeit aufgedeckt werden. In den Checklisten sind die verschiedenen Fehlerquellen ausreichend abzudecken:
- Allgemeine Kriterien wie Vollständigkeit, Produktlayout, Rechtschreibung, Konsistenz innerhalb des Prüfgegenstands, Eindeutigkeit, usw.
- Entwicklungstechnische Kriterien wie Konsistenz zu Vorgänger- und Nachbarprodukten, Nachvollziehbarkeit, Methodenkonformität, usw.
- Produktspezifische Kriterien wie Praktikabilität einer Anforderung, Anforderungserfüllung eines Entwurfs, Kommentierung von Code, Detaillierungsgrad einer Spezifikation, usw.
- System- oder anwendungsspezifische Kriterien wie Erfüllung spezieller Anwenderforderungen, Einhaltung strenger Projektplandaten, Integrierbarkeit in Org-Umgebung, harmonisches Zusammenwirken mit vorhandenem (Teil-) System, usw.
Nachfolgend sind beispielhaft einige grundlegende Fragestellungen für die Checklisten der verschiedenen Prüfgegenstände formuliert. Wie bereits oben erwähnt, bedürfen diese einer Ergänzung und projektspezifischen Interpretation. Für Prüfprodukte sind die allgemein gehaltene "Basis"-Checkliste und die entsprechende "Produkt"-Checkliste als Ausgangspunkt heranzuziehen.
"Basis"-Checkliste für jedes zu prüfende Produkt:
(Die folgenden Fragestellungen zeichnen sich dadurch aus, daß sie alleinig anhand des vorliegenden Prüfgegenstandes beanwortet werden können.)
- Ist das Produkt nach dem Produktschema aufgebaut?
- Enthält das Produkt keine Syntaxfehler (z. B. Schreibfehler)?
- Sind in dem Produkt keine widersprüchlichen Aussagen?
- Sind alle Aussagen in dem Produkt eindeutig formuliert?
- Ist das Produkt vollständig?
- Sind in dem Produkt alle nach dem Produktschema relevanten Inhalte in adäquater Ausführlichkeit vorhanden?
(Die folgenden Fragestellungen zielen auf den Entwicklungshergang eines Produktes, d. h. andere in Beziehung stehende Produkte müssen bei der Prüfung als Input herangezogen werden.)
- Ist das Produkt konsistent mit allen Vorgänger-Produkten, aus denen das zu prüfende Produkt hervorging?
- Ist das Produkt frei von Inkonsistenzen und Widersprüchen zu "Nachbar-"Produkten, die mit ihm in Beziehung stehen?
"Produkt"-Checklisten für die einzelnen Vertreter der jeweiligen Produktklassen:
(Diese Fragestellungen behandeln produkttypische Fehlerquellen, d. h. sie zielen auf den Inhalt und Besonderheiten der jeweiligen Produkte.)
- Anwenderforderungen
- Sind die Anforderungen erfüllbar, und ist die Erfüllung der Anforderungen prüfbar?
- Enthalten die Anwenderforderungen allein die vom AG gewünschten Anforderungen frei von überflüssigem Ballast?
- Sind die Anwenderforderungen frei von versteckten Entwurfsentscheidungen?
- Entsprechen die fachlichen Anforderungen den Angaben der Ist-Analyse?
- Sind die Vorgaben aus der Bedrohungs- und Risikoanalyse über die Anforderungen an die IT-Sicherheit ausreichend gewährleistet?
- Sind die Qualitätsforderungen in ihrer Gesamtheit erfüllbar, d. h. kann die gegenseitige (negative) Beeinflussung einzelner Qualitätskriterien, wie z. B. Zuverlässigkeit gegen Effizienz, kompensiert werden?
- Systemarchitektur
- Ist die Systemarchitektur mit den Anwenderforderungen und den Technischen Anforderungen verträglich?
- Deckt die Systemarchitektur alle Anwenderforderungen plausibel ab?
- Erfüllen IT-Sicherheitskonzept und IT-Sicherheitsmodell die Anforderungen an die IT-Sicherheit und die Anforderungen aus der Bedrohungs- und Risikoanalyse?
- Ist die Anforderungszuordnung von Anwenderforderungen auf die Elemente der Systemarchitektur eindeutig und vollständig?
- Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?
- Sind die Realisierbarkeitsuntersuchungen aussagekräftig?
- Technische Anforderungen
- Sind die Anforderungen erfüllbar, und ist die Erfüllung der Anforderungen prüfbar?
- Entsprechen die Technischen Anforderungen den Absichten der Ersteller der Systemarchitektur?
- Sind die Technischen Anforderungen frei von versteckten Entwurfsentscheidungen?
- Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?
- Sind die Anforderungen an die Software und Hardware ausreichend detailliert spezifiziert?
- Sind die Entwicklungs- und SWPÄ-Umgebung vollständig und eindeutig beschrieben?
- Schnittstellenübersicht
- Sind alle Schnittstellen aufgeführt?
- Besteht Konsistenz zu den Architekturdokumenten?
- Schnittstellenbeschreibung
- Sind alle in der Schnittstellenübersicht identifizierten Schnittstellen beschrieben?
- Sind die Schnittstellen ausreichend detailliert beschrieben?
- Integrationsplan
- Passen die im Integrationsplan aufgeführten Architekturelemente zu denjenigen, die im zugehörigen Architekturdokument aufgeführt sind?
- Ist die Integrations-/Prüfumgebung verträglich mit der Entwicklungsumgebung?
- Sind die organisatorischen und terminlichen Vorgaben mit dem Projektplan vereinbar?
- SW-Architektur
- Ist der Prozeßentwurf frei von Verklemmungen?
- Ist der Zugriff auf gemeinsame Betriebsmittel ausreichend geregelt?
- Ist der Prozeßentwurf mit dem verwendeten Betriebssystem verträglich?
- Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?
- Wurden konstruktive Maßnahmen entsprechend der Kritikalitätsstufe eingehalten?
- Erfüllt die SW-Architektur die Anwenderforderungen und die Technischen Anforderungen?
- SW-Entwurf: Modul,Datenbank
- Wurden die Realisierbarkeitsuntersuchungen überprüft?
- Wurden konstruktive Maßnahmen entsprechend der Kritikalitätsstufe eingehalten?
- Ist der SW-Entwurf im Sinne einer Programmiervorgabe gehalten?
- Datenkatalog
- Sind die Angaben im Datenkatalog konsistent zur Datenbank-Beschreibung?
- Besteht Konsistenz zum zentralen Datenkatalog?
- Implementierungsdokumente: SW Komponente, Datenbank, SW Modules, SW Einheit
- Wird ein einheitlicher Modulrahmen verwendet?
- Wurden die Programmier-/Codierstandards eingehalten?
- Wurde der Code ausreichend und verständlich dokumentiert?
- Ist der Prüfplan konsistent zu den Vorgaben im QS-Plan?
- Ist die Auswahl der Prüfgegenstände konform mit den Tailoring-Entscheidungen?
- Sind die organisatorischen und zeitlichen Zuordnungen konsistent zum Projektplan?
- Prüfspezifikation
- Deckt die Prüfspezifikation die im Prüfplan dafür festgelegten Vorgaben und Anforderungen ab?
- Wird gegebenenfalls die Prüfung der Schnittstellen in der Prüfspezifikation behandelt?
- Entsprechen die Prüfmethoden der dem Prüfgegenstand zugeordneten Kritikalitätsstufe bzw. seiner IT-Sicherheitseinstufung?
- Sind die vorgegebenen Prüfkriterien objektiv entscheidbar?
- Prüfprozedur
- Ist die Prüfprozedur für kritische Komponenten ausreichend detailliert und genau verfaßt?
- Projekthandbuch
- Sind die Tailoring-Entscheidungen eindeutig und sind diese nachvollziehbar dokumentiert?
- Projektplan
- Ist die Terminplanung frei von Verklemmungssituationen?
- Ist der Auslastungsgrad der Einsatzmittel (Personal und Ressourcen) kleiner als 100 Prozent?
- Sind die Inhalte des Projektplans verträglich mit den Vorgaben und Verfahren im Projekthandbuch, KM-Plan und QS-Plan?
- KM-Plan
- Berücksichtigt der KM-Plan die besonderen Konfigurationserfordernisse des Projekts?
- Werden sowohl Vorgaben bzgl. der Identifikation von Software als auch von Hardware getroffen?
- Konfigurations-Identifikationsdokument (KID)
- Ist das KID übersichtlich gestaltet, so daß Konfigurationsbeziehungen schnell ersichtlich sind?
- Ist eindeutig festgelegt, welche Konfigurationseinheiten definiert sind?
- Wird über das System-KID deutlich, welche weiteren KID existieren?
- Sind alle Bausteine und Dokumente der Konfiguration vollständig mit ihren Versionskennungen verzeichnet?
"Aktivitäten"-Checkliste für jede zu prüfende Aktivität:
- Wird die Aktivität entsprechend den relevanten Verfahrensvorschriften ausgeführt?
- Werden die geltenden Projektstandards eingehalten?
- Werden bei der Durchführung der Aktivität die Rollen angemessen verteilt?
Endekriterien benennen Bedingungen, unter denen die Prüfung als erfolgreich abgeschlossen betrachtet werden kann. In diesem Gliederungspunkt werden sowohl Endekriterien einer erfolgreichen Prüfung (z. B. die geforderte Genauigkeit ist mit einer maximalen Abweichung von +/-0.0005 erfüllt) als auch einer nicht bestandenen Prüfung (z. B. Meldung "Überlauf", "Division durch Null", "Speichermedium voll") genannt.
Es wird beschrieben,
- was (Funktion, Genauigkeit, usw.) zu prüfen ist,
- welche Ausgangssituation hierfür erforderlich ist,
- welche Eingaben (Daten und Signale mit allen für die Prüfung ausschlaggebenden Eigenschaften wie Zeitbedingungen) notwendig sind und
- welche Ergebnisse (Ausgabedaten und Reaktionen/Effekte) zu erwarten sind.
Mit den hier aufgeführten Prüffällen müssen die o. g. Endekriterien ausreichend erfüllbar und entscheidbar sein.
Diese Matrix dokumentiert die Abdeckung der Anforderungen an den Prüfgegenstand durch die einzelnen Prüffälle.
Dieses Kapitel enthält eine Dokumentation der Abdeckung von architektonischen Elementen des Prüflings (z. B. Überdeckung von integrierten Bausteinen durch SW-Module, externe und interne Schnittstellen usw.) und von Code-Elementen (z. B. Zweig-, Bedingungs-, Pfadüberdeckung) durch die Prüffälle.
Wichtig ist, daß die Prüfungen der Schnittstellen durch entsprechende Prüffälle bei den einzelnen Prüfgegenständen ausreichend mit abgedeckt werden.
Dieses Kapitel enthält eine Dokumentation der Abdeckung von fachlichen und technischen Anforderungen (z. B. durch Abdeckung von Äquivalenzklassen und Grenzwerten oder von Zeit- und Mengenanforderungen) durch die Prüffälle.
Mail 0723 - Abdeckungsmatrix (723)
Mail 0373 - Pruefkriterien V-Modell'97 (573)
Inhalt