Das Gebiet der Software-Entwicklung hat seit den 60er Jahren bedeutende Fortschritte gemacht. Vom bloßen "Programme/-Schreiben" sind wir mittlerweile zu einem geregelten Software-Entwicklungsprozeß gelangt. Trotzdem kann das Erreichte nicht befriedigen. Allzu oft basieren unsere Entscheidungen auf unzulänglichen sowie ungenauen Formationen, weshalb sie später unter hohen Kosten korrigiert werden müssen.

Software-Erstellung und deren Management stützen sich auf qualitative Aussagen, weniger auf quantitative Feststellungen. Hier versprechen Softwaremetriken oder Qualitätsindikatoren Abhilfe.

Softwaremetriken überspannen das gesamte Feld der Software-Erstellung, von einleitenden Realisierbarkeitsstudien und System Requirements bis hin zu Untersuchungen nach dem Abschluß eines Projekts. Sie sind so vielfältig wie das gesamte Gebiet unserer Software-Industrie.

1. Die Fehlerdichte: Bei dieser Metrik werden die Fehler erfaßt und durch die Programmlänge in Lines of Code (LOC) dividiert. Die Gleichung in ihrer allgemeinen Form läßt sich so darstellen:

FD = Fkum / KLOC.

Dabei ist

FD: Fehlerdichte in Fehler pro 1000 Programmzeilen,

Fkum : kumulierte Fehlerzahl,

KLOC: 1000 Programmzeilen des Quellcodes.

Bei dieser Statistik ist eine Reihe von Varianten denkbar. Man kann die Fehlerdichte für jede Phase der Software-Entwicklung - also Analyse der Anforderungen, Entwurf, Implementierung und Integration - gesondert erfassen. Die Fehlerdichte kann auch getrennt für katastrophale und weniger schwerwiegende Fehler berechnet werden.

Unerkannte Probleme treten bei der Implementierung auf

Hat man zum Beispiel Erfahrungen aus früheren Projekten und ist die Fehlerdichte in der Entwurfsphase außergewöhnlich gering, so kann dies zum einen auf sehr gut dokumentierte und schlüssige Anforderungen an die Software hindeuten. In vielen Fällen wird allerdings der Indikator anzeigen, daß die Probleme noch nicht erkannt wurden, und in der Implementierungsphase tritt dies deutlich zutage.

2. Die Fehlertage: Dieser Indikator ähnelt einer in der Luftfahrtindustrie weit verbreiteten Statistik. Die Fluggesellschaften sind ja vor allem daran interessiert, zahlende Passagiere zu befördern. Deshalb werden die geflogenen Meilen mit der Zahl der Passagiere multipliziert.

In der Software nun werden für jeden erkannten Fehler die Anzahl der Tage erfaßt, während der sich der Fehler unerkannt in der Software befand. Diese Zahlen werden dann pro System addiert. Da man oft nicht genau weiß, wann sich ein Fehler in die Software eingeschlichen hat, wird in einem solchen Fall als Entstehungsdatum einfach die Mitte der entsprechenden Phase angenommen. Bei einem Fehler im Lastenheft wäre dies konsequenterweise in der Mitte der Phase Lastenhefterstellung.

Wie wir wissen, kommen erkannte Fehler in ihrer Beseitigung um so teurer, je später im Lebenszyklus sie gefunden werden. Demzufolge kann diese Statistik ein wertvolles Mittel zur Beurteilung des Entwicklungsprozesses sein.

3. Ein Fehlerprofil: Diese Methode benutzt die kumulierten Fehler eines Projekts und trägt sie über den Projektzeitraum auf. Sie ist also grafisch orientiert. Eine solche Metrik ist relativ einfach zu erstellen. Sie kann auch ohne große maschinelle Hilfsmittel angefertigt werden. Wenn man weiß, wie der Durchschnitt der Industrie bei den zu erwartenden Fehlerzahlen liegt, erlaubt die Statistik auch ein Urteil über die Güte des Tests der Software.

4. Testabdeckung durch Funktionstest: Bei dieser Statistik werden die mittels Test geprüften Funktionen der Software durch die Zahl der gesamten Funktionen der Software dividiert. Also:

IF = Ft/Fg

Dabei ist

IF: Index für Testabdeckung,

Ft: getestete Funktionen,

Fg: Gesamtzahl der Funktionen.

Schwierigkeiten vor allem bei deutschen Lastenheften

In der Praxis stellt die Ermittlung der Softwarefunktionen ein Problem dar. Verschiedentlich wird vorgeschlagen, einfach die Zahl der "Shall" in der Spezifikation zu zählen. Das ist zwar mit Hilfe eines Werkzeugs relativ leicht möglich, befriedigt allerdings kaum. Zwar muß jede verbindliche Forderung in englischsprachigen Spezifikationen mit "shall" formuliert werden die Worte "should" oder "may" sind nicht ausreichend, wenn man etwas verbindlich vorschreiben will -, aber Papier ist geduldig: Ob jemand eine Funktion durch einmalige oder fünfmalige Benutzung des Wortes "shall" spezifiziert, bleibt dem Autor überlassen.

Schwierigkeiten sehe ich erst recht bei Lastenheften in deutscher Sprache. Hier sind die Regeln für das Schreiben der Dokumente lange nicht so streng. Was eine Funktion der Software darstellt, kann im Einzelfall zu langen Diskussionen führen.

Ohne Frage kann man für den Indikator die Anzahl der getesteten Module im Verhältnis zur Zahl der gesamten Module eines Softwarepakets heranziehen, wie das IEEE auch vorschlägt. Nun sollte man aber immer alle Module testen. Daher ist der Indikator in der vorgeschlagenen Form wenig hilf reich.

Besser ist, wenn die Qualitätssicherung eines Unternehmens ein Maß der Testabdeckung für den Modultest vorgibt und die Einhaltung dieser Vorgabe überwacht. Als eine Mindestforderung sollte hier gelten, daß jeder Pfad in einem Modul des Programmcodes beim Test mindestens einmal durchlaufen werden muß.

5. Ursache-Wirkungs-Grafen: Bei dieser Methode, die Glenford J. Myers bereits vorfahren beschrieben hat, werden Ursache und Wirkung einer geforderten Softwarefunktion durch einen gerichteten Grafen verbunden. Bedingungen wie "und" beziehungsweise "oder" lassen sich zusätzlich aufnehmen.

Diese Methode ist durchaus geeignet, verborgene Abhängigkeiten des Programmcodes aufzuspüren. Ihr Nachteil liegt im enormen Aufwand für die Erstellung der Grafiken. Sinnvoll wäre das nur, wenn der Arbeitsaufwand durch ein Werkzeug in Grenzen gehalten werden könnte. Mir ist derzeit kein derartiges Hilfsmittel bekannt. Das Erkennen von Ursache und Wirkung erfordert auch das Auge eines geschulten Fachmanns.

6. Verfolgen der funktionellen Anforderungen: Bei diesem Indikator werden die in der Software-Architektur erkannten Funktionen mit den ursprünglichen Anforderungen verglichen. Da es schwierig sein dürfte, die Anforderungen numerisch genau festzuschreiben, kann dieser Indikator in der Praxis wohl keine große Bedeutung erlangen.

7. Der gewichtete Fehlerindex: Diese Metrik verwendet die Zahl der gefundenen Fehler über den Software-Lebenszyklus. Dabei werden die Fehler nach ihrem Schadenspotential gewichtet. In einer Formel kann man das so darstellen:

Ifw = W1 (S/Fg) + W2 X (M/Fg) + W3 X (L/Fg).

Dabei ist

lfw: gewichteter Fehlerindex,

Fg: kumulierte Zahl der Gesamtfehler,

S: katastrophale Fehler,

M: mittelschwere Fehler,

L: leichte Fehler,

W1 bis W3: Wichtungsfaktor.

Um den unterschiedlichen Fehlern Rechnung zu tragen, könnte man zum Beispiel W1 auf 0,7, W2 auf 0,2 und W3 auf 0,1 setzen.

Voraussetzung: Ein System für die Fehlererfassung

Diese Metrik ist sehr gut geeignet, um den Prozeß der Software-Entwicklung über die gesamte Projektlaufzeit hinweg zu verfolgen; der Indikator liefert zudem ein objektives Bild. Allerdings setzt diese Statistik voraus, daß innerhalb einer Organisation ein System zur Fehlererfassung existiert und daß diese Vorschriften auch angewandt werden. Da die Fehler bei der Entwicklung der Software peu a peu anfallen, wird die Kalkulation des Indikators nur in rechnergestützter Form sinnvoll sein. Also erfordert diese Metrik einen gewissen Aufwand.

8. Fehlerverteilung und Ursachenforschung: Bei dieser Art von Softwarestatistik sind der Phantasie keine Grenzen gesetzt. Man kann die Fehlerberichte einer Organisation in vielerlei Form auswerten, etwa um Trends identifizieren zu können. Dabei ist immer darauf zu achten, daß die Fehlerberichte auch ausreichende Informationen in genügender Tiefe enthalten. Ist dies nicht der Fall, macht eine Auswertung wenig Sinn. Ferner kann man einzelne Phasen des Software-Entwicklungsprozesses anhand der Fehlerberichte näher untersuchen. Es läßt sich zum Beispiel eruieren, welche Fehler bei Lastenheften häufiger als andere gemacht werden.

9. Der Reife- oder Stabilitätsindex: Bei diesem Indikator geht es darum, die Reife oder Stabilität eines Softwarepakets beurteilen zu können.

In mathematischer Notation läßt sich diese Metrik wie folgt darstellen:

Mi = (NMod-(Nnm + Ng + No))/ Nmod

Dabei ist

Mi: Reifeindex,

NMod: Gesamtzahl der Module oder Funktionen im gegenwärtigen (neuen) Software-Release,

Nnm: Anzahl der neuen (zusätzlichen) Module oder Funktionen gegenüber dem letzten Release,

Ng: Anzahl der geänderten Module oder Funktionen gegenüber dem vorhergehenden Release,

No: Anzahl der gelöschten und nicht mehr vorhandenen Module oder Funktionen.

Diese Metrik, obwohl mit einiger Rechenarbeit verbunden, erlaubt es uns, relativ schnell ein Urteil über die Stabilität eines Softwareprodukts zu fällen. Es wäre interessant zu wissen, welchen Index einige am Markt verfügbaren Textverarbeitungs- oder Datenbanksysteme wohl aufzuweisen hätten.

Nehmen wir einmal an, die fiktive Firma Minisoft entschließt sich, für ihr Softwarepaket zur Textverarbeitung namens Text-perfect einen solchen Index zu veröffentlichen. Sie als Verbraucher verfolgen diese Entwicklung und schreiben sich diese Zahlen auf Ihre Tabelle könnte nach einiger Zeit so aussehen:

Version Reifeindex

Release 3.0 0,4

Release 4.0 0,6

Release 4.2 0,9

Release 4.3 0,92

Release 5.0 0,52

Tabelle 1: Stabilitätsindex je Version eines fiktiven Produkts

Wenn Sie nun noch in Betracht ziehen, daß Release 5.0 als großangelegte Überarbeitung des Programms angekündigt war, sollten Ihnen die Zahlen zu denken geben. Der ideale Index wäre natürlich 1,0. Ob er erreichbar ist, mag dahingestellt bleiben. Immerhin war aber bis zu Release 4.3 eine stetige Verbesserung des Produkts festzustellen.

Die vielen neuen Features von Release 5.0 haben offenbar dazu geführt, daß das Programm radikal geändert wurde. Nun muß der Index aber nicht unbedingt bedeuten, daß Release 5.0 eine schlechte Qualität hat. Ist das Programm vor der Freigabe gründlich getestet worden, kann es ebenso gut sein wie Release 4.3. Aber wir als Verbraucher sollten vorsichtig sein. Brauchen wir die neuen Funktionen von Release 5.0 nicht sofort, können wir durchaus abwarten, bis uns zur Qualität des Produkts näheres bekannt wird.

10. Halstead's Software Science Measures: Diese aus der Literatur bereits seit längerer Zeit bekannte Metrik beruht auf der Zahl, die für Operatoren und Operanden eines Programms steht. Die Zahl kann ermittelt werden, nachdem das entsprechende Programm erstellt wurde. Sie ist letztlich ein Maß für die Komplexität eines Computerprogramms. So nützlich dieses Maß sein mag - es wird immer erst ermittelt, wenn das Programm bereits vorliegt. Insofern wird es oft zu spät sein, um noch korrigierend einzugreifen.

Die Ermittlung der Kennzahl erfordert einen gewissen Aufwand für die Zählung der Parameter und die Kalkulation des Ergebnisses. Auswüchse bei der Programmierung können in der Praxis aber auch durch vorbeugende Maßnahmen, also Engineering-Standards, verhindert werden.

11. McCabe's Komplexitätsmaß: Diese Metrik beruht auf den Verzweigungen im Ablauf eines Programms oder Moduls. McCabe's Argument ist, daß sehr komplexe und schwer durchschaubare Programme nur unter Schwierigkeiten testbar sind; daher nimmt die Fehlerhäufigkeit überproportional zu. Diese Argumentation ist ernst zu nehmen. Die Ermittlung dieser Kennzahl erfordert allerdings immer ein Werkzeug, wenn man sie für ein Projekt erfolgreich anwenden will.

12. Fehlerbilanz der Softwarephasen: Es ist seit längerem bekannt, daß die Beseitigung von Fehlern in der Software um so teurer kommt, je später ein Fehler erkannt wird. Man kann etwa mit den folgenden Werten rechnen:

Entwicklungsphase rel. Kosten

Lastenhefterstellung 0,3

Entwurf 1,0 - 1,5

Kodierung 1,5 - 2,5

Integration u. Test 2,0 - 5,0

Inbetriebnahme

und Einsatz 5,0 - 20,0

Tabelle 2: Relative Kosten bei der Beseitigung von Fehlern

Angesichts solcher Zahlen ergibt sich natürlich auch ein bedeutendes Potential zur Einsparung von Kosten. Dazu muß man wissen, wann ein Fehler in den Software-Entwicklungsprozeß eingeführt und wann der Fehler beseitigt wurde. Zu diesem Zweck wird man für jede Phase der Entwicklung eine Bilanz aufstellen. Darin müssen auftauchen:

- die in dieser Phase neu eingeführten Fehler,

- die eventuell aus einer früheren Phase übernommenen Fehler,

- die in der Phase entdeckten und beseitigten Fehler,

- die noch nicht entdeckten und weiter in dem Produkt vorhandenen (schlummernden) Fehler.

Wer sich einmal die Mühe macht, solch eine Bilanz zu erstellen und konsequent durchzurechnen, wird über das Potential zur Kosteneinsparung überrascht sein.

13. Turn-around-Time: Eine sehr aussagekräftige Metrik ist die durchschnittliche Zeit zur Beseitigung eines Fehlers. Man stellt dazu fest, wann der Fehler entdeckt und gemeldet wurde. Als zweite Eingangsgröße benötigt man das Datum des Tages, an dem der Fehler in der Software bereinigt war. Aus einer Reihe solcher Datenpaare bildet man den Durchschnitt in Kalendertagen.

Braucht eine gegebene Organisation nun 90 Tage, um einen bekannten Fehler zu beseitigen, so sollte man sich als Kunde überlegen, ob man die Produkte dieser Firma kauft. Natürlich gibt es bei Fehlern in der Software unterschiedliche Fehlerklassen, aber ein Vierteljahr für die Fehlerbeseitigung ist eine lange Zeit. Bei einem schwerwiegenden Fehler ist dieser Zeitraum einfach nicht tragbar. Ich habe diese Statistik immer als sehr nützlich empfunden.

14. Fehlerrate: Diese Metrik führt man dann durch, wenn das Projekt bereits abgeschlossen ist. Man teilt dazu einfach die kumulierte Anzahl der Fehler durch die benötigten Lines of Code für das Programm. Die Fehlerrate - mag es sich nun um 2,5 oder fünf Prozent handeln - ist langfristig ein sehr guter Indikator, um Softwareprojekte einordnen zu können. Da die Zahl zudem relativ leicht zu ermitteln ist, sollte man auf diese Statistik keinesfalls verzichten.

15. Fehlerrate bei Dokumenten: Nun haben wir bereits viele Metriken gesehen, doch keine geht speziell auf Softwaredokumente ein. Dabei entstehen im Laufe der Entwicklung mehr Dokumente, als vielen lieb ist. Eine subjektive Beurteilung des Dokuments sollten wir zu vermeiden suchen. Ähnlich wie bei deutschen Aufsätzen schwanken dabei nämlich die Meinungen. Was der eine für eine großartige Arbeit hält, mag bei einem zweiten Leser unter "Thema verfehlt" laufen.

Daher sollte ein Standard existieren. Die Einhaltung dieser Richtlinie muß dann allerdings auch durch einen Fragebogen und ein gründliches Review des Dokuments überprüft werden.

Eine ganz einfache und relativ billige Metrik erhält man, wenn man nach dem Durcharbeiten des Dokuments die Anzahl der Kommentare zu dem Softwaredokument durch die Anzahl der Seiten teilt. Eine solche Statistik kann so aussehen, wie in Tabelle 3 (Seite 18) dargestellt.

Die absolute Zahl ist bei dieser Statistik nicht so wichtig. Vielmehr sollte uns der Trend interessieren. Bei unserem Beispiel hat sich die Qualität des Dokuments von Entwurf zu Entwurf stetig verbessert.

Diese Statistik erlaubt es uns auch, verschiedene Dokumente der Software miteinander zu vergleichen, sowohl innerhalb eines Projekts als auch über Projekte hinweg. Gewiß läßt sich die Methode noch verbessern, wenn man statt der Seitenzahl die Zeilen oder Worte eines Dokuments zur Verfügung hat. Dazu benötigt man allerdings wiederum ein Werkzeug. Wir haben eine ganze Reihe von Metriken zur Beurteilung der Qualität eines Softwareprodukts und des Entwicklungsprozesses kennengelernt. Der Aufwand zur Erstellung ist von Fall zu Fall unterschiedlich, und die Aussagekraft und Nützlichkeit kann durchaus kontrovers diskutiert werden.

Meist ist der Einsatz eines Werkzeugs notwendig

Keine der Metriken ist umsonst zu haben. Für jede solche Statistik ist ein gewisser Auf wand notwendig. Viele der Kennzahlen erfordern geradezu den Einsatz eines Werkzeugs, wenn Sie Programme mit mehr als ein paar Hundert Lines of Code haben. Und wer hätte das nicht?

Ein geregelter Software-Entstehungsprozeß mit einer klaren Trennung der Phasen und Reviews muß vorausgesetzt werden, wenn man sinnvolle Statistiken erstellen will. Auch sind vor der Erfassung der Meßwerte immer ganz klare Definitionen zu treffen. Hier müssen die Bedingungen des Unternehmens berücksichtigt werden.

Über den anfallenden Kosten sollte der Nutzen für das Management nicht vergessen werden: Nur wer klare und eindeutige Kennzahlen über den Software-Entwicklungsprozeß besitzt, kann auf der Basis gesicherter Zahlen entscheiden. Daher bieten Metriken die Chance, das Management von Softwareprojekten entscheidend zu verbessern.

Zu fragen ist abschließend jedoch, wer die Metriken erstellen sollte. Hier bietet sich die Qualitätssicherung an, denn es handelt sich um eine unabhängige Gruppe. Die Entwicklungsabteilung verfügt zwar über die meisten der notwendigen Daten; sie ist aber in den meisten Fällen zu sehr Partei, als daß man sie mit dieser Aufgabe betrauen sollte.