1.6 Vorhersage und Validation

Wie schon erwähnt ist das Ziel des Messens meist eine Vorhersage mit dem Zweck, die Qualität oder die Kosten eines Produkts oder Prozesses zu verbessern. Wie kommt man zu einer solchen Vorhersage?

Vorhersagen werden hergestellt durch ein Vorhersagesystem. Ein solches besteht aus einem mathematischen Modell und einer Menge von Vorhersageprozeduren zur Bestimmung unbekannter Parameter des Modells und zur Interpretation der Resultate. Ein Modell ist eine abstrakte Repräsentation eines Objekts (hier: eines Produkts oder Prozesses).

  
1.6.1 Beispiel: Vorhersagesystem

Hier ein einfaches Beispiel für ein Vorhersagesystem: Gesucht sei ein Vorhersagesystem zur Vorhersage des Personenzeitaufwands zur Erstellung einer Softwarekomponente kbekannter Größe. Wir modellieren den Personenzeitaufwand T(k) durch die Beziehung T = b + G(k)/p, also einen konstanten Basiszeitaufwand b plus die Komponentengröße G(k) geteilt durch eine Programmiergeschwindigkeit p (gemessen in Größe pro Zeit).

Dieses Modell macht also erstens die Annahme, daß es eine Menge von Verwaltungs- und sonstigen Arbeiten gibt, deren Dauer pro Komponente von der Größe und der Art dieser Komponente unabhängig ist. Das könnten zum Beispiel die Zeit zum Registrieren der Komponente in der Konfigurationsverwaltung, zum Planen des Herstellungsprozesses und zum Sammeln von Daten über das fertige Produkt sein.

Zweitens macht das Modell die Annahme, daß die eigentliche Herstellung mit einer Geschwindigkeit (Größe pro Zeit) abläuft, die sowohl von der Größe der Komponente als auch von der Art der Komponente unabhängig ist -- zumindest innerhalb des separat festzulegenden Gültigkeitsbereichs des Modells.

Um aus diesem Modell ein Vorhersagesystem zu gewinnen, brauchen wir Prozeduren zur Bestimmung der Parameter b, G(k) und p. Die Bestimmung von G(k) geschieht, so könnten wir zum Beispiel festlegen, mittels eines Lines-of-Code-Maßes. Die Bestimmung von b und p könnte beispielsweise durch lineare Regression anhand historischer Daten erfolgen. Das geht so: Wir sammeln für eine Reihe von Softwarekomponenten die tatsächlichen Daten für T(k), sagen wir in Minuten, und G(k), beispielsweise

G(k)	T(k)
78	33
565	207
330	191
187	93
w 1160	524	Summe
290	131	Durchschnitt

nun berechnen wir die Regressionsgerade nach den Regressionsformeln

$$\beta_1 = \frac{\sum_{i=1}^n x_i y_i - n\bar{x}\bar{y}} {\su... ...n\bar{x}^2} \quad\quad\quad \beta_0 = \bar{y} - \beta_1\bar{x}$$

wobei $\bar{x}$ und $\bar{y}$ die jeweiligen Mittelwerte der x_i und der y_i sind. In unserem Fall setzen wir als x_i die Werte G(k)ein und als y_i die T(k), der Ergebnisparameter $\beta_1$entspricht bei uns 1/p und $\beta_0$ entspricht b. Wir erhalten

$$p = \frac{199950 - 4\cdot 290\cdot 131}{469178 - 4 \cdot 290}... ...2778} = 0.361 \quad\quad\quad b = 131 - 0.361 \cdot 290 = 26.3$$

Damit können wir Vorhersagen treffen in der Form $T(k) = 26.3 + 0.361 \cdot G(k)$.

Die vier oben angegebenen Datenpunkte und die Regressionsgerade sind zur Veranschaulichung in Abbildung 1.2 dargestellt.

Bei diesem ganzen Prozeß ist übrigens ein fundamentaler Fehler passiert, ist er Ihnen aufgefallen?
Ein Programmierer, der fast drei Zeilen pro Minute erzeugen kann ist kaum vorstellbar. In obiger Rechnung wurden von den wirklichen Daten die Zeilenanzahlen mit den Minutenanzahlen genau vertauscht. Dieses Problem kann durch Mitdenken und Plausibilitätsprüfungen mittels Überschlagsrechnung leicht entdeckt werden, führt andernfalls aber zu verwirrenden Auswirkungen. Dies verdeutlicht, daß der gesunde Menschenverstand immer der Hauptmaßstab bleiben sollte.

1.6.2 Validation

Bevor man nun ein Vorhersagesystem benutzt, sollte man sicherstellen, daß es auch wirklich für den angestrebten Zweck brauchbar ist. Diesen Vorgang bezeichnet man als Validation. Die Validation eines Vorhersagesystems bedeutet letztlich nichts anderes, als seine Genauigkeit und Zuverlässigkeit zu bestimmen und zu entscheiden, ob sie ausreichend ist. Eine solche Anforderung könnte sein, daß die Vorhersagen in höchstens 10 Prozent der Anwendungsfälle um mehr als 20 Prozent vom tatsächlichen Wert abweichen dürfen.

Dabei ist zu beachten, daß die Validation im Hinblick auf den Anwendungszweck vorgenommen wird. Es wird also gegebenenfalls nicht nur die Güte des mathematischen Modells samt seiner Parameter betrachtet, sondern auch die Interpretation der Ergebnisse aus dem Modell. Beispiel: Bei der Validation eines Vorhersagesystems für die Zuverlässigkeit beschreibe das mathematische Modell die Häufigkeit des Versagens (also des Auftretens von Fehlern). Selbst wenn diese Häufigkeit gut vorhergesagt wird, wäre noch zu klären, ob der zugrundegelegte Fehlerbegriff mit dem Zuverlässigkeitsempfinden harmoniert, oder ob vielleicht die Benutzer manche Fehler kaum als Beeinträchtigung der Zuverlässigkeit empfinden aber andere Fehler als erhebliche Beeinträchtigung.

Oft jedoch ist der Kern der Validation eines Vorhersagesystems direkt an den verwendeten Maßen aufgehängt: für ein Maß ist stets zu prüfen, ob es die angeblich von ihm charakterisierte Eigenschaft auch der Intutition entsprechend widerspiegelt. So ist beispielsweise das Maß Lines of Code nur dann ein ,,valides`` (gültiges) Maß für die Programmlänge entsprechend unserer Intuition, wenn wir das Zählen von leeren Zeilen ausschließen. Denn nach unserem Empfinden wird ein Programm nicht länger, wenn wir beispielsweise 5000 Leerzeilen anhängen. Ein Lines-of-Code-Maß, das einfach die Anzahl von Zeilenwechseln in einer Datei zugrundelegt, wäre deshalb eine unsichere Grundlage für Vorhersagesysteme und würde eine Validation als Maß für Programmlänge nicht bestehen.

  
1.6.3 Beispiel: Validation

Verfolgen wir das obige Beispiel der Vorhersage von T(k) weiter: Wir haben ein Lines-of-Code-Maß verwendet, das die Länge gut charakterisiert, von dort droht also keine Gefahr. Eine Interpretation der Ergebnisse findet in unserem Beispiel ebenfalls nicht statt, kann also auch die Validation nicht verderben. Bliebe noch sicherzustellen, daß die mit den berechneten Parametern aus dem mathematischen Modell entstehenden Vorhersagewerte genau genug sind.

Wir müssen also zunächst eine gewünschte Genauigkeit festlegen und dann prüfen, ob sie eingehalten wird. Welche Genauigkeit zu fordern ist, hängt von der Anwendung des Vorhersagesystems ab. Werden aufgrund der Vorhersagen sehr kritische Entscheidungen getroffen, wird eine recht hohe Zuverlässigkeit und eventuell auch eine hohe Genauigkeit benötigt. In vielen Fällen ist man aber auch bereit, sich mit weniger genauen und zuverlässigen Werten zufriedenzugeben, weil das immer noch besser ist, als überhaupt keine systematisch erzeugten Vorhersagen zur Verfügung zu haben. Nehmen wir an, in unserem Fall wünschen wir eine Genauigkeit von plus/minus 20 Prozent mit einer Zuverlässigkeit von 90 Prozent.

Dann benötigen wir eine ausreichend große Menge von Datenpunkten, die repräsentativ für die geplante spätere Anwendung des Vorhersagesystems sein muß, um seine Genauigkeit zu messen. Für das Beispiel ist dies in Abbildung 1.3 dargestellt: Wir verwenden 50 Paare von Größe G und Zeit T, die wir bereits gemessen haben. Aus der Ungenauigkeitsschranke von 20 Prozent ergeben sich die beiden im Bild mit `min' und `max' bezeichneten Geraden, die den erlaubten Vorhersagebereich abgrenzen. Für eine Zuverlässigkeit von 90 Prozent im Rahmen dieser Schranke dürften von 50 Datenpunkten also nur 5 außerhalb dieses Bereichs liegen. Tatsächlich finden wir aber 14 Punkte außerhalb vor. Das Vorhersagesystem genügt in diesem Beispiel unseren Ansprüchen also eindeutig nicht.

In einer solchen Validierung gewinnt man oftmals neue Einsichten in das zu vermessende System, die anschließend die Definition besserer Vorhersagesysteme erlauben. Im Beispiel etwa erkennen wir, daß das Vorhersagesystem zwar grundsätzlich brauchbare, aber systematisch etwas zu hoch liegende Vorhersagen macht. Die Parameter der Regressionsgerade sollten also mit mehr Daten noch einmal neu berechnet werden, dann wird sich die Qualität der Vorhersagen verbessern.

1.6.4 Häufige Fehler bei Validation

Drei Fehler werden bei der Validation von Maßen und Vorhersagesystemen häufig gemacht: Erstens wird häufig nicht die Übereinstimmung der Meßwerte mit dem tatsächlich zu beurteilenden Sachverhalt überprüft, sondern stattdessen nachgewiesen, daß eine Korrelation mit anderen, bereits bekannten Maßen vorliegt. Eine solche Aussage ist jedoch weitgehend nutzlos: Ist die Korrelation sehr hoch, ist das neue Maß eigentlich überflüssig, denn man kann fast ebensogut das alte verwenden. Ist die Korrelation nicht sehr hoch, so stellt sich die Frage, ob das neue Maß eine bessere oder eine schlechtere Übereinstimmung mit der zu messenden Eigenschaft hat als das alte. Diese Frage kann durch eine Korrelationsmessung jedoch prinzipiell nicht beantwortet werden. Ein solches Vorgehen ist nur dann nützlich, wenn mehrere Bedingungen erfüllt sind:

1.

Das neue Maß korreliert sehr gut mit einem alten.

2.

Das alte Maß ist anerkanntermaßen nützlich.

3.

Das neue Maß ist einfacher zu berechnen als das alte oder steht zu einer früheren Zeit zur Verfügung.

Zweitens wird oftmals keine klare und einleuchtende Hypothese an den Anfang einer Validation gestellt, sondern es wird gegen irgendetwas validiert, worüber gerade Daten zur Hand sind. Dazu müssen dann implizit Annahmen gemacht werden, die eventuell jeder Grundlage entbehren. Beispielsweise wurde ein Maß für die Modularität aufgrund seiner Vorhersagekraft für die Entwicklungskosten validiert, obwohl keine Aussagen über einen Zusammenhang zwischen Modularität und Entwicklungskosten vorliegen.
Aus ähnlichen Erwägungen wird auch manchmal gleich bei der Definition eines Maßes eine Konstruktion gemacht, die gar nichts mit dem Ziel des Maßes zu tun hat; ich zitiere als Beispiel Chidamber und Kemerer mit einer Aussage über ihr RFC-Maß [CK94]:

It should be noted that membership to the response set is defined only up to the first level of nesting of method calls due to the practical considerations involved in collection of the metric.

Drittens wird manchmal ein Vorhersagesystem aufgrund einer gewissen Menge von Datenpunkten entwickelt und optimiert und dann aufgrund guter Vorhersagen für dieselben Datenpunkte als validiert betrachtet. Das ist im Prinzip Unsinn, weil man unter dieser Randbedingung stets auf triviale Weise ein scheinbar perfektes Vorhersagesystem konstruieren kann. Das Vorgehen ist allenfalls zulässig, wenn sichergestellt werden kann, daß die einzelnen Werte der Datenpunkte die grundsätzliche Arbeitsweise des Vorhersagesystems nicht beeinflussen.

1.6.5 Wahl von Vorhersagesystemen

Was für Vorhersagesysteme sollte man angesichts dieser Schwierigkeiten denn nun anstreben? Es gibt mehrere Klassen von Vorhersagesystemen, die sowohl nützlich als auch validierbar sind:

• Messung interner Produktattribute aus frühen Phasen des Software-Lebenszyklus zur Vorhersage von internen Attributen für Produkte aus späteren Phasen. Beispiel: Verwendung von Größe und Modularität einer Spezifikation zur Vorhersage von Größe und Strukturiertheit einer Implementation.
• Messung früher Prozeßattribute zur Vorhersage von späteren Prozeßattributen. Beispiel: Anzahl von Fehlern, die in der Grobentwurfsinspektion gefunden wurden zur Vorhersage der Häufigkeit von Entwurfskorrekturen während der Implementation.
• Messung interner Produktattribute zur Vorhersage von Prozeßattributen. Beispiel: Strukturiertheit des Codes zur Vorhersage des Zeitbedarfs für bestimmte Wartungsarbeiten.
• Messung von internen Produktattributen und Prozeßattributen zur Vorhersage externer Produktattribute. Beispiel: Zahl von bei Codedurchsichten gefundener Fehler zur Vorhersage der Zuverlässigkeit.

Die Vorhersage externer Attribute aus internen Attributen wird immer problematisch bleiben, weil äußerlich sich gleich verhaltende Software intern dramatisch unterschiedlich aufgebaut sein kann. Die Vorhersage kann aber dennoch in einem nützlichen Rahmen gelingen, wenn Einschränkungen an das Universum der internen Attribute ohnehin festliegen. Ferner kann die zusätzliche Nutzung von Prozeßinformation die Vorhersage verbessern.