Software-Projekte transparenter zu machen, hat sich Insbesondere In mittleren und größeren Projekten als unumgänglich erwiesen. Einen wesentlichen Beitrag zur Transparenz der Software-Arbeiten bietet die Anwendung eines Software-Qualitätssicherungsplans,

Software-Projekte in der Raumfahrt, die hier als Beispiele dienen sollen, werden in den letzten Jahren nach bei Dornier festgelegten Standards der Europäischen Raumfahrtbehörde ESA durchgeführt. Dazu zählen die Software Engineering Standards, die Software Quality Assurance for ESA-Spacecraft and Associated Equipment und Software Quality Assurance Plans.

Diese Standards ergänzen und unterstützen sich im Rahmen eines SW-Projektes gegenseitig. Sie setzen gemeinsam einen Software-Lebenszyklus voraus, in den der Software-Entwicklungszyklus eingebettet ist.

Dieser Zyklus wird in verschiedene Phasen unterteilt, so die

- User Requirements Phase (UR)

- Software Requirements Phase (SR)

- Architectural Design Phase (AD)

- Detailed Design Phase (DD)

- Transfer Phase (TR)

- Operations and Maintenance Phase (OM)

Jede dieser Phasen ist als ein in sich abgeschlossenes Teilstück innerhalb des SW-Lebenszyklus zu sehen, wobei den Requirements-Phasen - der Definition von User-Requirements und der Definition von Software-Requirements - besondere Bedeutung zukommt.

QS-Plan mit vielen Zielen

Der Software-Qualitätssicherungsplan wird zu Beginn des Entwicklungszyklus, also in der Software-Requirements Phase, erstellt.

Er hat verschiedene wesentliche Ziele zum Inhalt; so die Erfüllung vertraglicher Qualitätssicherungs-Forderungen und die Konformität der Phasenergebnisse mit Entwicklungs- und QS-Standards. Auch die Transparenz des Entwicklungsablaufs von den Software-Requirements über das Software Design zur Kodierung und zurück sowie die Aufdeckung von Fehlern und Schwachstellen zu einem frühen Zeitpunkt oder die Definition vom Einsatz von SW-Werkzeugen zählen hierzu. Weitere Aufgabe ist es, Codier-Standards und -Regeln festzulegen, um Codierungsfehler zu verringern, die Testbarkeit mit geringerem Aufwand zu erreichen, und Interface-Probleme durch Vorgabe von Richtlinien zu vermeiden.

Um diese Ziele zu erreichen, sollte ein Qualitätssicherungsplan die folgenden Punkte eindeutig und in der notwendigen Tiefe behandeln:

- Ziele der Qualitätssicherungsmaßnahmen für das spezielle Projekt,

- Anzuwendende Dokumente,

- Management, Organisation, Aufgaben und Verantwortlichkeiten,

- Software-Dokumentation,

- Standards und Richtlinien,

- Reviews und Audits,

- Konfigurations-Management und -Kontrolle,

- Störmeldeverfahren, Änderungsverfahren,

- SW-Werkzeuge, Methoden,

- Programm-Bibliothek.

Zweigeteilter Aufbau

Der Qualitätssicherungsplan gliedert sich in einen formalen, projektübergreifenden Teil und in einen fachtechnischen Teil.

Zum formalen, projektübergreifenden Teil gehören zum Beispiel die Dokumentation, das Konfigurationsmanagement, das Störmelde- und Änderungsverfahren und die Organisation.

Zum fachtechnischen Teil gehört die Definition von QS-Kriterien für das Projekt, die Beurteilung und Bewertung von SW-Entwürfen, die Beurteilung der Implementierung von QS-Kriterien in die SW-Entwürfe oder Testdokumente etc.

Hier sollen die Schwerpunkte hervorgehoben werden. Dazu zählen die Dokumentation der Software, die Einhaltung von Entwicklungsstandards, die Implementierung von Qualitätskriterien in die Dokumentation oder die Prüfungen der Software in Reviews.

Die Phasenergebnisse der Software werden in der obligatorischen Dokumentation niedergelegt.

Dieses sind als Minimum:

- das SW-Requirements-Dokument (SRD)

- das SW-Architektur-DesignDokument (ADD)

- das SW-Detailed-Design Dokument (DDD)

- das SW-UserManual (SUM)

- der SW-Verifikations-Plan (SVP)

- das SW-Transfer-Dokument mit SW-Testplan und

Testprozeduren (STD)

Die Anforderungen im SRD werden anhand einer Gliederung festgelegt, wie sie in den Software-Standards vorgesehen ist. Je nach Projekt können zusätzliche Kapitel aufgenommen werden oder gegebenenfalls irrelevante Kapitel weggelassen werden.

Die folgenden aufgelisteten Kapitel sollten jedoch nicht fehlen:

a) Funktions-Anforderungen

b) Leistungs-Anforderungen

c) Interface-Anforderungen

d) Bedienungs-Anforderungen

e) Ressourcen-Anforderungen

f) Verifikations-Anforderungen

g) Abnahme-Anforderungen

h) Zuverlässigkeits-Anforderungen

i) Wartbarkeits-Anforderungen.

Sinngemäß ist für jedes oben genannte Dokument eine Gliederung vorgesehen und die Hauptaktivitäten der Phase definiert.

Im Qualitätssicherungsplan sind Qualitätskriterien beschrieben, die als allgemeine Qualitätskriterien von jedem Dokument erfüllt werden müssen. Diese Qualitätseigenschaften werden von der unabhängigen Qualitätssicherungsorganisation überprüft. Das Ergebnis wird in einem Prüfbericht niedergelegt. Mit dieser Prüfung wird sichergestellt, daß ein Dokument in sich abgeschlossen und wohldefiniert ist.

Anhand der QS-Kriterien "Verfolgbarkeit" und "Vollständigkeit" soll die Prüfung der Funktions-Anforderung und der Verifikations-Anforderungen aufgezeigt werden.

Slalom durch den Testweg

Um eine Anforderung und deren Validation in der Testprozedur verfolgbar zu machen, sollte bereits die Anforderung im Software Requirements-Dokument möglichst eindeutig identifizierbar sein. Das bedingt die Verwendung einer formalen Sprache, einer halbformalen Sprache oder/und eines eindeutigen Nummernschlüssels bei der Erstellung der Anforderungen.

Ein solcher Nummernschlüssel für Anforderungen wird in den Dokumentationsrichtlinien des Projektes festgelegt, wobei in jeder Nummer die Funktionsanforderungen, das zugehörige Gerät, in dem die Funktion erfüllt werden soll, sowie die fortlaufende Nummer der Funktionsanforderung zu finden sein sollten.

Die Anforderungsnummer ist nun die Referenz-Nummer im Architectural Design (AD), im Detailed Design (DD) und gegebenenfalls im Datenhaltungsentwurf. Parallel zur Referenz-Nummer im SRD, ADD und DDD dient diese Referenz-Nummer dazu, in der Testprozedur einen bestimmten Testschritt oder eine Gruppe von Testschritten zu bezeichnen. Diesen Testschritten sind wiederum bestimmte Testdaten zugeordnet, die sich aus dem Detailed Design und Architektural Design ergeben. Da zu den Anforderungen im Software-Requirements-Dokument bereits Abnahme-Anforderungen definiert wurden, die ebenfalls wohlunterscheidbar mit - Referenz-Nummern versehen sind, dienen die aus dem AD/DD abgeleiteten Testdaten der Verifikation der Programme, die Abnahme-Anforderungen der Validation des Software-Systems. Über die Referenz-Nummern ist somit die Verfolgbarkeit von den Anforderungen über den SW-Design zur Verifikation/Validation gewährleistet.

Matrix für runde Sachen

Die Überprüfung der Vollständigkeit eines SW-Designs und der Tests gegenüber den Anforderungen ist ebenfalls über einen eindeutigen Nummernschlüssel bei Verwendung einer halbformalen oder formalen Spezifikationssprache wie auch mit manuellen Mitteln recht einfach. Voraussetzung bei Benützung einer halbformalen Sprache ist, daß die Anforderungen möglichst eindeutig sind. Die Überprüfung erfolgt einerseits, indem zu jeder Anforderung ein ausreichend detailliertes Software-Design vorhanden sein muß, andererseits, daß jedes Designobjekt in der Testprozedur ausreichend detailliert getestet werden muß. Ein wirkungsvolles Hilfsmittel zur Prüfung der Vollständigkeit eines DV-Entwurfs ist die Erstellung einer Matrix, in der zu jeder Anforderung des Requirements-Dokuments ein Testfall definiert sein muß.

Sinngemäß wird für die übrigen QS-Kriterien des Qualitätssicherungsplanes geprüft, ob sie im SW-Design ausreichend berücksichtigt wurden.

Die Überprüfung von QS-Kriterien wie Konsistenz, Vollständigkeit wird bei der Verwendung von SW-Werkzeugen wie zum Beispiel EPOS wesentlich erleichtert. Das hier beschriebene Verfahren ist jedoch auch manuell wirkungsvoll anwendbar. Die Einführung von Referenz-Nummern und die sorgfältige Implementierung von QS-Kriterien während des SW-Designs trägt zur Transparenz und Qualitätserhöhung der Software bei.

Die Prüfungsergebnisse über den erreichten Grad der Implementierung der vorgegebenen QS-Kriterien in die Phasendokumente werden in den Prüfberichten der Qualitätssicherung niedergelegt. Diese Prüfberichte werden in der Vorbereitungsphase zu den bei Dornier obligatorischen Reviews zum Abschluß der einzelnen Entwicklungsphasen erstellt.

Reviews gut planen

Reviews sind ihrem Wesen nach Projektbesprechungen, in denen Statusüberprüfungen in technischer und ökonomischer Hinsicht durchgeführt werden. In einem Review soll primär festgestellt werden, ob der Fortschritt der Entwicklungsarbeiten in der laufenden Phase einen Stand erreicht hat, der aus verschiedensten Sichten als ausreichend detailliert, bezeichnet werden kann, um in die nächste Entwicklungsphase eintreten zu können. Um eine solche Feststellung treffen zu können, benötigt man im allgemeinen neben der Beurteilung des Sachstandes durch den SW-Entwickler eine Sachstandsfeststellung vom Management (Projektleiter), von der Qualitätssicherung, von unabhängigen externen Fachleuten und gegebenenfalls vom Auftrageber.

Ein Review am Ende einer SW-Entwicklungsphase besteht aus folgenden Einzelschritten:

- Planung, des Reviews in Übereinstimmung mit dem Projekt-Meilensteinplan

- Vorbereitung des Reviews

- Durchführung des Reviews

- gegebenenfalls Nacharbeit der Phasenergebnisse

- Freigabe der Phasenergebnisse zum Eintritt in die nächste SW-Entwicklungsphase.

Bei der Planung des Reviews wird der Termin benannt und der Teilnehmerkreis festgelegt, von dem zum Sachstand anhand der vorliegenden Phasenergebnisse eine Aussage zu treffen ist. Ziel der Review-Planung ist das Einhalten des Projektzeitplanes sowie die Verfügbarkeit der Teilnehmer zur Prüfung der Phasenergebnisse zum Review-Termin.

Die Vorbereitung des Reviews, die - abhängig von der Projektgröße - zwei bis vier Wochen nicht überschreiten sollte, dient vorwiegend der Prüfung der Phasenergebnisse durch die Teilnehmer unter formalen und inhaltlichen Gesichtspunkten, auf Erfüllung der Anforderungen aus der vorhergehenden Phase, der Beachtung vorgegebener Standards und QS-Kriterien, der Prüfung des Verhaltens in Fehlerfällen. Die von den Teilnehmern erstellten Kommentare und Bewertungen werden, spätestens bei der Review-Besprechung von der Qualitätssicherung in Form des Prüfberichtes an den Entwickler zurückgegeben.

Bei der Durchführung des Reviews zum geplanten Termin präsentiert der SW-Entwickler seine Phasenergebnisse unter Berücksichtigung der Kommentare und Prüfberichte. Die Teilnehmer der Review-Besprechung überprüfen, ob ihre technischen Probleme im Phasenergebnis ausreichend berücksichtigt sind. Ziel der Besprechung ist, mögliche Schwachstellen zu identifizieren. Fehler aufzudecken und Randbedingungen kritisch zu durchleuchten und zu klären. Mögliche Schwachstellen oder Fehler werden im Review-Protokoll festgehalten.

Protokoll als Basis

Die Freigabe der Phasenergebnisse durch die Review-Teilnehmer kann dann erfolgen, wenn nur geringe oder keine Mängel festgestellt werden können. Wird das Phasenergebnis freigegeben, dann sollten alle technischen Probleme dem Detaillierungsgrad der Entwicklungsphase entsprechend gelöst sein. Die Phasenergebnisse und das Review-Protokoll können abgezeichnet werden.

Die konsequente Durchführung von Reviews nach den beschriebenen Verfahren vermeidet das, Scheitern von SW-Projekten, führt zu Qualitätserhöhung der Software und zur Transparenz des Prozesses.

*Horst Pohl ist Ingenieur für Software-Qualitätssicherung bei der Dornier System GmbH, Friedrichshafen.