Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

29.10.1982 - 

Tests: Automatisierter SW-Meßwertausdruck noch Utopie (Folge 3):

Im Brennpunkt zwischen Kosten und Ertrag

Qualitätssicherung von Software wird einmal ein ganz normaler Bestandteil der SW-Erstellung sein, wie sie das heute schon auf allen anderen Ingenieurgebieten ist. Man kann diesen Trend deutlich beobachten, wenn man die einschlägige, neuere Literatur beobachtet. War im Jahre 1980 noch kaum die Rede von SW-Qualitätssicherung als eigenem Gebiet, erscheint dieser Begriff seit eineinhalb Jahren immer deutlicher, befaßt man sich immer bewußter mit den Verfahren hierzu.

Der Rahmen für die Verfahren ist durch das Phasenkonzept vorgegeben. Die einzelnen Aktivitäten der Überprüfungen lassen sich daraus ableiten und planen. Wie man die Prüfung durchführen soll, ist ad hoc natürlich durch das Phasenkonzept nicht festgelegt. Diese Methoden hängen eng mit den Engineering-Methoden zusammen.

Auch die Zwitterrolle des Tests kommt hier zur Sprache. Der bisherige (Miß-)Stand der Technik behandelt häufig die "Testerei" als unverbindliche Hilfsmittel der Entwickler zur Kontrolle über eigene Produkte. Tests waren zur Zufriedenheit abgeschlossen, wenn der Entwickler von sich aus sagen konnte, sein Programm liefe jetzt fehlerfrei(!). Dann verschwanden die Tests in der Versenkung oder in Datengräbern. Höchster Grad von Mißwirtschaft, denn die Tests mußten praktisch alle für Wartungszwecke noch einmal erstellt werden.

Wenn man für die Qualitätsüberprüfungen eigene Tests erstellen mußte, wäre das mit Sicherheit nicht wirtschaftlich. Schließlich darf man nicht vergessen, daß der Testaufwand den eigentlichen Programmieraufwand häufig übersteigt. Also muß der Test sinnvollerweise zwei Aufgaben erfüllen: Er ist

- Hilfsmittel für die Entwicklung (Modultest und SW-Integration) und

- Überprüfungsmittel für die Qualitätssicherung.

Durch die angedeuteten Maßnahmen, der Kooperation von Engineering und Qualitätssicherung, wird die Zuverlässigkeit von SW mit Sicherheit spürbar verbessert werden.

Was heißt "spürbar bessere" oder "hohe Zuverlässigkeit"? Ohne eine exakte Messung ist dieser Begriff leider ziemlich wertlos. In den Zeiten, in denen die reine HW überwiegend die Funktion bestimmt hat, ließ sich die Authentizität mit Hilfe von Zeichenmodellen ziemlich genau bestimmen. Diesen Modellen lag die Systemstruktur und die bekannte, statistische Ausfallrate von Bauteilen zugrunde. Um zum Beispiel ganz definiert und quantifizierbar eine bestimmte Zuverlässigkeit zu erreichen, stehen als freie Parameter einmal die Auswahl und Verwendung von Bauteilen zur Verfügung, zum anderen die Auslegung des Systems bis hin zu redundanten, also mehrfachen Ausführungen.

Ausfälle durch nicht entdeckte Fehler

Da die Gesamtzuverlässigkeit eine Funktion aus der HW- und der SW-Zuverlässigkeit ist, stellt sich mit zunehmendem und heute schon häufig überwiegendem SW-Anteil natürlich automatisch die Frage nach entsprechenden Modellen für die SW. Hier zeigt sich der fundamentale Unterschied zwischen HW und SW. Es gibt keine Ausfälle durch Alterung oder Fabrikationsfehler. Ausfälle treten ausschließlich durch nicht entdeckte Fehler auf.

Es sind dies nicht nur unentdeckte Codierfehler, wie logische Fehler im Programm oder Rechen- und Rundungsfehler, sondern auch Fehler, die bereits im Entwurf beispielsweise aus falsch interpretierten Schnittstellen entstanden sind.

Gerade solche Fehler sind besonders unangenehm, weil sie mit den bisherigen Testmethoden, die sich auf den Code beziehen, gar nicht entdeckt werden können. Die eigentliche Problematik entsteht dadurch, daß SW-Programme ab einer gewissen Größe prinzipiell nicht mehr vollständig getestet werden können. Diese Komplexität ist auch der wesentliche Unterschied zur HW, die solche Komplexitätsgrade nicht annähernd erreichen kann. Denn ihre Schwierigkeiten liegen mehr auf dem Gebiet von Toleranzen und den erwähnten Ausfällen, beides Gebiete, die man rechnerisch, statistisch und experimentiell beherrschen kann.

Bis zum heutigen Zeitpunkt behilft man sich vor allem bei hohen Zuverlässigkeitsanforderungen damit, daß man möglichst viele Maßnahmen ergreift, insbesondere ausgiebig testet. Solche Methoden sind zum Beispiel das sogenannte "independent testing", bei dem zwei Teams unabhängig voneinander das SW-Produkt testen oder die Verwendung von "dissimilarer SW", also die unabhängige Codierung der gleichen Aufgabenstellung mit der Hoffnung, daß der gleiche Fehler nicht gleichzeitig auftritt.

Das magere Ergebnis all dieser Aufwendungen ist die Aussage: "Wir haben alles Menschenmögliche getan, die SW müßte jetzt einigermaßen fehlerfrei sein."

Das Problem ist also die Suche nach dem Maß, der quantifizierten Überprüfung der SW-Qualität. Wie steht es heute damit?

Die Antwort ist schnell gegeben: sehr schlecht. Man kann noch nicht einmal sagen, ob es überhaupt möglich sein wird, SW wirklich physikalisch zu messen. Wir müssen uns, um die Problematik vollständig zu erkennen, noch einmal in Erinnerung rufen, daß die Zuverlässigkeit keineswegs das einzige Merkmal der Qualität ist. Die folgenden Merkmale scheinen nach heutigem Wissensstand ein einigermaßen vollständiger Satz zu sein:

- Funktionserfüllung

- Benutzbarkeit (Handhabbarkeit, Erlernbarkeit, Verständlichkeit, Robustheit gegen Fehlbedienung)

- Sicherheit (gegen absichtliche Fehlbedienung, auch Datenschutz)

- Zuverlässigkeit

- Effizienz (sowohl Speicher- als auch Laufzeiteffizienz)

- Änderbarkeit (Wartbarkeit und Flexibilität gegen Modifikationen)

- Prüfbarkeit (Fehlerlokalisierung!)

- Portabilität (Übertragbarkeit auf andere Rechner oder Systeme)

- Weiterverwendbarkeit (vor allem von Teilen der SW, also Allgemeinheit).

Kriterien zur Qualitätsmessung

Ein brauchbarer Satz solcher Merkmale muß folgende Kriterien erfüllen, damit er für eine Qualitätsmessung nutzbar ist:

1.) Er muß vollständig sein. Dies leuchtet unmittelbar ein.

2.) Die Merkmale müssen voneinander unabhängig sein. Ansonsten wird überflüssiger Aufwand getrieben, die Aussagen könnten verwirrend und mehrdeutig werden.

3.) Er muß allgemein sein. Wenn der Merkmalsatz nur jeweils für bestimmte Anwendungsgebiete gültig ist, läßt sich eine allgemeine Meßbarkeitsmethodik nicht rationell entwickeln. Die Unabhängigkeit von bestimmten Gebieten ist auch erforderlich, um wirklich relevante Aussagen über die Qualität und nicht über spezifische Leistungen des Anwendungsfalls zu erhalten. Dies soll nicht heißen, daß für jede Aufgabenstellung, alle Merkmale gleich wichtig sind. Es muß vielmehr eine Forderung sein, daß zusammen mit den Anforderungen an die Software eine Gewichtung der Merkmale erfolgt. Diese Gewichtung kann aber nur dann durchgeführt werden, wenn das nächste Kriterium erfüllt ist:

4.) Die Merkmale müssen quantifizierbar sein. Es muß also irgendeine Art physikalischer Definition von Merkmalen geben. Und schließlich muß man dann Meßmethoden für diese Größe angeben können.

Welche Ansätze gibt es? Einige haben versucht, vernünftige Definitionen zu finden. Hier sei ein Beispiel zitiert. Der Autor ist James A. McCall, et al. im "Software Quality Measurement Manual, Vol. II" vom Rome Air Development Center, beauftragt vom U. S. Department of Commerce. McCalls Formel lautet:

Eins, minus Zahl der Fehler durch Zahl der ausführbaren Befehle (also ohne Kommentare). Zwei Fehler auf 100 Befehle wären dann eine Zuverlässigkeit von 0,98.

Eine ordentliche Definition, wenn man die Zahl der Fehler feststellen könnte, was, wie wir vorher gesehen haben, durch Tests ab einer gewissen Größe ausgeschlossen ist. Welche Antwort hat McCall auf diese Frage? Es ist eine Mischung aus Fragebogentechnik und statistischer Analyse. Um eine möglichst gute Abdeckung zu erzielen, werden die Fragen auf die einzelnen Projektphasen, wie wir sie beschrieben haben, aufgeteilt und die Zahlen für jede Phase getrennt ermittelt, um dann zu einem Gesamtergebnis zu gelangen. An den entdeckten Fehlern und an gewissen statistischen Abweichungsfaktoren (unter Nutzung der Gauß-Verteilung) werden dann Zahlen für die Qualität der quantitativen Aussage errechnet.

Natürlich hängt diese Methode sehr von der Allgemeinheit und Vollständigkeit und schließlich Güte der einzelnen Fragen ab. Zudem ist sie sehr aufwendig.

Nur eine globale Vorgehensweise sichert die Brauchbarkeit der Qualitätsaussage. Es gibt eine Reihe von Ansätzen, die sich auf bestimmte Aspekte beziehen, diese Ergebnisse sind in ihrem engen Bereich durchaus anwendbar, für eine Beurteilung eines SW-Produktes nicht ausreichend.

Gleichzeitig zeigt das Beispiel von McCall aber auch die große Schwierigkeit des Problems. Nur mit Hilfe der Krücke "Fragebogen" gelangt er zu verwertbaren Zahlen. Der Unzulänglichkeit durch subjektive Bewertung ist hier schon bei der originären Meßdatengewinnung Tür und Tor geöffnet.

Das Computerprogramm, das wie ein Meßgerät an die SW anzulegen ist, voreingestellt durch deren spezielle Daten, das nach Ablauf die Meßwerte für die einzelnen Merkmale ausdruckt, dürfte wohl noch lange Utopie bleiben, auch wenn das Thema noch so sehr brennt.

*Friedrich Haugg ist als Diplom-Mathematiker bei MBB in Ottobrunn in der SW-Qualitätssicherung tätig.