Die immer wieder beklagte Softwarekrise bezieht sich in der Regel nur auf das Fehlen von Applikationen. Doch bei der Qualität der vorhandenen Software stellt sich die Situation ähnlich dramatisch dar. Werner Mathes* zeigt Methoden auf, die helfen sollen, bei Softwareprodukten einen ähnlich hohen Qualitätsstandard zu erreichen, wie er in anderen Industrien längst selbstverständlich ist.
Die mangelnde Qualität bei der Entwicklung hat drastische Folgen. Immer wieder überschreiten Entwicklungsprojekte das vorgegebene Budget, Anforderungen an die Software werden nicht erfüllt und der Großteil der Entwickler ist mit Wartung und Pflege der erstellten Software beschäftigt.
Das CASE-Konzept ist mit dem Anspruch angetreten, durch Methoden des Software-Engineerings in diesem Bereich mehr Produktivität und Qualität zu schaffen. Die Versprechungen der CASE-Hersteller wurden gerne gehört, doch ist nach mehr als zehn Jahren wenig Zahlenmaterial vorhanden, das eine Erhöhung der Produktivität und der Qualität von mit CASE erstellter Software nachweist.
Vergleichen wir die Situation mit dem Beginn der Qualitätssicherung in der Manufaktur. Dort begannen die Hersteller, durch Sortieren die guten von den fehlerhaften Teilen zu trennen. Um den so ausgemusterten Ausschuß künftig zu vermeiden, erwies es sich als notwendig, den gesamten Herstellungsprozeß zu verstehen und beherrschen zu lernen. Dieses Verständnis entwickelten die jeweiligen Herstellern über die Analyse der fehlerhaften Teile. In der Folge konnte dann versucht werden, die Fehlerursachen zu vermeiden, damit sich die gewünschten Teile in einer gleichmäßigen Qualität erzeugen ließen. Dieses Verfahren nennt man statistische Prozeßkontrolle.
Aber auch die ausgefeiltesten Fertigungstechniken haben nicht dazu geführt, daß die Endkontrolle der Produkte aufgegeben werden konnte. Erst hier kann festgestellt werden, ob Änderungen im Herstellungsprozeß den gewünschten Effekt hatten. Erfahrungen haben gezeigt, daß die Qualitätsplanung nie zu einem Ende kommt. Es gibt immer Möglichkeiten, ein Werkstück zu verbessern. Wichtig dabei ist auch, daß man sich in vielen Projekten damit beschäftigt, die Qualität zu erhöhen.
Unternehmen, die in der Lage sind, ihre Produktionsprozesse rascher als die Mitbewerber in eine gewünschte Richtung zu ändern, verfügen über einen entscheidenden Wettbewerbsvorteil. Als Beispiel sei die japanische Industrie erwähnt, der es gelungen ist, ausgehend von einem sehr schlechten Qualitäts-Image, ein Niveau zu erreichen, mit dem sie heute in vielen Bereichen als führend gelten kann.
Auch bei der Software-Entwicklung gilt es, die Qualität der Ergebnisse zu messen - nach dem Motto "no Quality if no Metrics". Ausgehend vom Setzen eines konkreten Qualitätsziels, ist der derzeitige Stand festzustellen, um den Handlungsbedarf zu ermitteln.
Bei der Einführung von CASE wird häufig der Fehler gemacht, den Software-Entwicklungsprozeß zu verbessern, ohne genau zu wissen, welche Faktoren die Qualität von Software beeinflussen.
Es ist notwendig, Metriken aus der erzeugten Software zu gewinnen, diese Metriken in Beziehung zu den Fehlern zu setzen, die man beim Betrieb dieser Software feststellt.
Einführung eines Feedback-Mechanismus
Es ist also notwendig sich darüber klar zu werden, in welchem Zustand sich der Software-Entwicklungsprozeß befindet. Man hat einen Plan zu entwickeln, wie der Entwicklungsprozeß in Zukunft aussehen soll, und durch Fehler-Ursachen-Analyse festzustellen, wo der Software-Entwicklungsprozeß verändert und verbessert werden muß.
Voraussetzung für ein solches Verfahren ist die Einführung eines Feedback-Mechanismus in den Software-Entwicklungsprozeß. Das oberste Ziel der Software- Qualitätssicherung ist es, Fehler zu vermeiden, und nicht, sie später zu erkennen. Wer jedoch Mängel bereits im Vorfeld umgehen möchte, der muß sicherstellen, daß er aus erkannten Fehlern die richtigen Schlüsse zieht.
Dazu gehört eine Einstellung, bei der Fehler nicht unter den Tisch gekehrt, sondern vielmehr als Chance betrachtet werden, den Software-Entwicklungsprozeß zu verbessern.
CASE darf sich deshalb nicht nur auf konstruktive Methoden abstützen, sondern muß auch analytische beinhalten. Am weitesten fortgeschritten ist hier die Analyse von bestehenden Programmquellen.
Sie dient dazu, kritische Komponenten und Elemente zu entdecken und diese einer manuellen Beurteilung zuzuführen.
Die statistische Analyse erlaubt, bestimmte Metriken festzustellen, wobei für die Entwicklung bereits Qualitätseigenschaften vorgegeben sind. Die Kunst liegt nun darin, diesen Qualitätseigenschaften Metriken zuzuordnen. Zu diesem Zweck läßt sich eine von den Qualitätsspezialisten Bohm und McCall vorgeschlagene Baumstruktur einsetzen. Hierbei werden bestimmten Qualitätsfaktoren Qualitätskriterien zugeordnet und diesen werden nun wieder Metriken zugeordnet, von denen man annimmt, daß sie einen Einfluß auf die Qualitätskriterien haben.
Eine solche Anpassung an die Anforderungen hat projekt- und firmenabhängig zu erfolgen. Außerdem müssen für diese Metriken Bereiche definiert werden, die angeben, ob ein gemessener Wert akzeptabel oder kritisch ist. Liegt ein Wert außerhalb des gewünschten Bereiches, ist daraus noch kein Urteil abzuleiten, sondern es muß geprüft werden, ob dieser Wert notwendig ist und sich nicht durch geeignete Maßnahmen reduzieren läßt.
Die Komplexität von Software-Anwendungen
Die Komplexität von Software-Anwendungen erschließt sich aus der Architektur, das heißt der Aufrufe zwischen den einzelnen Komponenten, der internen Struktur und den Anweisungen und Bedingungen innerhalb einer Komponente.
- Die Komplexität der Architektur läßt sich geeigneterweise als Aufrufbaum darstellen. Diese grafische Darstellung ermöglicht eine Kontrolle von rekursiven Aufrufen - auch solchen, die über mehrere Ebenen gehen. Außerdem gestattet sie, Aufrufe über mehrere Hierarchie-Stufen darzustellen.
- Die Komplexität der Struktur einer Komponente läßt sich als Kontrollgraf wiedergeben. Diese Darstellungsform führt zu klaren Aussagen über den Grad der Strukturiertheit einer Komponente. Verstöße gegen die Regeln der strukturierten Programmierung werden so offenbar. Die Einhaltung der Vorgaben bezüglich einzelner Metriken läßt sich anhand eines Kiviat-Diagramms nachweisen. Die statistische Analyse insgesamt dient also der Aufdeckung kritischer Komponenten mit dem Ziel, durch geeignete konstruktive Maßnahmen die statistische Komplexität zu verbessern.
Nicht alle Abweichungen von den Vorgaben können jedoch durch statistische Maßnahmen korrigiert werden. Aus diesem Grund sollte eine statistische durch eine dynamische Analyse ergänzt werden, das heißt durch Maßnahmen zur Unterstützung und Kontrolle des Tests.
Kritische Komponenten, die sich statisch nicht mehr verbesseren lassen, müssen besonders gut getestet werden, um im Betrieb keine Fehler zu produzieren beziehungsweise um eine ausreichende Wartung zu ermöglichen.
Die dynamische Analyse unterstützt im wesentlichen den sogenannten "Whitebox-Test". Dieser ermöglicht die Definition von Testfällen aufgrund der Kenntnis der Programmstruktur und weist die Ausführlichkeit des Tests durch Feststellen von Testabdeckungs-Metriken nach. Auf Komponentenebene werden dabei in den Kontrollstrukturen noch nicht erreichte Zweige visualisiert und somit die Testfallfindung für
weitere Testläufe erleichtert. Auf Architekturebene stellt die dynamische Analyse nicht durchgeführte Aufrufe dar und weist so die Vollständigkeit des Integrationstests nach.
Für die Darstellungen werden alle bisher durchgeführten Testläufe herangezogen und somit ist auch eine Beurteilung der einzelnen Testdatensätze möglich.