1.3 Ergebnisse

Es gibt eine Riesenmenge an Berichten darüber, was man mit Messen (angeblich) alles hinbekommen kann oder irgendwann einmal nicht hinbekommen hat. Wir greifen hier nur drei Beispiele heraus.

1.3.1 PSP

Als positives Beispiel für den Einsatz von Maßen eignet sich die Methode des ,,persönlichen Software-Prozesses`` (PSP), in der zahlreiche recht simple Maße sehr erfolgreich eingesetzt werden, um die Planbarkeit der Softwareerstellung und die Qualität der erzeugten Produkte auf der Ebene eines einzelnen Softwareingenieurs zu verbessern. So wird die Größe von Softwareprodukten in Lines of Code gemessen, was ausreichend ist, wenn man Daten nur auf eine Person und eine Programmiersprache bezieht. Fehler werden nach einem einfachen Schema in 10 Klassen eingeteilt und der Herstellungsprozeß in 6 Phasen, deren Beginn und Ende zeitlich festgehalten wird -- und schon ergibt sich eine Vielzahl von Kennzahlen, die beschreiben, wie hoch Fehlerdichten und Fehlerentfernungsquoten in einzelnen Phasen sind, wie effektiv man Inspektionen einsetzt, wie hoch die Produktivität ist etc. Diese Maße sind nicht nur wohldefiniert und aussagekräftig, sie sind auch tatsächlich Grundlage von Verbesserungen. Der PSP wird später (Abschnitt 6) noch ausführlicher besprochen.

1.3.2 o-o

Als ein Beispiel dafür, was alles schiefgehen kann und wie vorsichtig man bei der Interpretation von Meßergebnissen sein muß, vor allem, wenn man versucht, sie von einem Bereich auf einen anderen zu übertragen, soll folgender Ausschnitt aus einer Nachricht dienen, die Steve Walters (swalters@infinet.com) in die Usenet-Newsgruppe comp.software-eng gesendet hat:

,,We just finished a software development project and discovered some curious metrics. This was a project in which we had good domain experience and about six years of metrics, both team productivity and other analogous software of similar scope and functionality. The difference with this project was that we switched from a functional design methodology to o-o.
First the good news: the overall team productivity (SLOC/person-month) was almost three times our previous rate.
Now for the bad news: the delivered SLOC was almost three times greater than estimated, based on the metrics from our previous projects.
We completed the project on time and on budget, but the radical departure from what we have been used to is unnerving.``

1.3.3 GQM

Bei den Arbeiten, die zu der oben bereits besprochenen Goal-question-metric Methode geführt haben, machten Basili und Weiss einige Erfahrungen mit Meßvorhaben, die sie ebenfalls in ihrem Artikel [BW84] beschrieben haben. Diese lassen sich folgendermaßen zusammenfassen:

1.

Verstehe Deinen Anwendungsbereich (Arbeitsumfeld und Projektgegenstand). Ohne ein solches Verständnis kann man die Gründe für die Phänomene, die man mißt, nicht verstehen und aus den Messungen wenig Nutzen ziehen.

2.

Validiere die Daten rechtzeitig. Bei allen Messungen treten Widersprüche und Inkonsistenzen auf, insbesondere dann, wenn Daten ,,von Hand`` erfaßt werden müssen. Solche Widersprüche können oft noch bereinigt werden, wenn man das kurz nach der Messung versucht, weil sich die betreffende Person dann noch gut an den Sachverhalt erinnern kann. Eine Bereinigung mit großen zeitlichen Abstand ist jedoch meist zum Scheitern verurteilt.

3.

Minimiere den Arbeitsaufwand für die Datenerfassung. Dies spart nicht nur unmittelbar Kosten, es verringert auch die Zahl der Fehler und Auslassungen in den Daten. Am günstigsten ist es, die Datenerfassung mit anderen Prozeßschritten zu integrieren. Eine gute Gelegenheit für das automatische Vermessen von Dokumenten ist beispielsweise das Einchecken der Dokumente in das Konfigurationsverwaltungssystem.

4.

Berücksichtige bei der Analyse der Daten die Umgebung, in der sie entstanden sind. In der Regel müssen die Umgebungsfaktoren bei der Interpretation der Daten berücksichtigt werden, um nicht zu falschen Schlüssen zu gelangen.

5.

Unterschätze nicht den Aufwand zur Datensammlung, -validation und -analyse. Wenn die Daten eine hohe Qualität haben sollen, ist ein erheblicher Arbeitsaufwand nötig.

6.

Überzeuge die Softwareingenieure davon, daß die Daten nicht gegen sie verwendet werden. Andernfalls wird die Datensammlung unterlaufen und ist ziemlich sicher völlig wertlos.

7.

Berücksichtige, daß eventuell der Hawthorne-Effekt am Werk ist. Dies ist ein psychologischer Effekt, der darin besteht, daß Menschen sich anders verhalten, wenn sie wissen, daß sie beobachtet werden. Im Falle der Softwareherstellung werden sie in der Regel eine bessere Leistung zeigen als normalerweise -- wenn der Effekt überhaupt auftritt, was nicht sicher ist. Falls der Hawthorne-Effekt ausgeprägt vorhanden ist, können die anfänglichen Meßergebnisse irreführend sein, denn es ist unwahrscheinlich, daß er jahrelang bestehen bleibt.