Softwaremetriken dienen dazu, die in den Prejekten geleistete Arbeit zu messen, um Informationen für eine Projektplanung zu liefern. Warum gängige Maßgrößen wie Mannmonate und Lines of Code als Maßzahlen für die Aufwandschätzung nur bedingt geeignet sind, erläutert Robert Hürten*.
Stellen Sie sich folgende Situation vor: Ein Fuhrunternehmer mißt die Leistung seiner Fahrer an dem verbrauchten Benzin und den Fahrzeiten; der Quotient aus beiden Größen bildet somit die Maßzahl für die Fahrer. Jeder Betriebswirt würde hier sofort einwenden, daß die Bezugsgrößen falsch gewählt sind. Der Verbrauch sagt nämlich nichts Sinnvolles über eine erbrachte Leistung aus. In unserem Beispiel müssen selbstverständlich die gefahrenen Kilometer die Basis für die erbrachte Arbeit sein. Die Leistung ergibt sich also aus dem Quotienten von Wegstrecke durch Zeiteinheit.
Leistungsbetrachtungen in der Datenverarbeitung werden heute vorwiegend nur für das Rechenzentrum erstellt. Hier sind Leistungsgrößen wie Zeilen pro Stunde und Zugriffe in der Sekunde anerkannte Werte.
Im Bereich der Software-Entwicklung dagegen bilden Leistungsbetrachtungen die Ausnahmen. In vielen Unternehmen entsteht der Eindruck, als ob die Software-Ingenieure Leistungsbetrachtungen meiden wie der Teufel das Weihwasser. Für die Anwendungsentwickler gilt anscheinend dasselbe, was den Schreinern, Schustern und Schneidern nachgesagt wird: Sie organisieren die Aufgaben anderer Leute, vergessen aber sich selbst dabei.
Ziel jeder Organisationsmaßnahme ist es, durch neue Arbeitsabläufe oder Arbeitsmethoden die Produktivität beziehungsweise die erbrachte Leistung zu steigern Der Nachweis über eine Leistungsveränderung läßt sich aber nur führen wenn die geleistete Arbeit gemessen werden kann Es sind also Maßeinheiten notwendig.
Die Leistungsermittlung in der Software-Entwicklung verlangt folglich Maßgrößen für die Arbeit der Analytiker und der Programmierer. Diese Probleme sollen die Software Metrics lösen; sie definieren Standards für die Messung von Eigenschaften im Rahmen der Software-Entwicklung.
Solche Eigenschaften können beispielsweise die Größe beziehungsweise die Komplexität eines Projektes, der dafür nötige Aufwand, die Qualität der erstellten Software oder die Produktivität eines Entwicklungsumfeldes sein.
Die Suche nach dem richtigen Maß
Die Problematik der Leistungsermittlung bei der Software-Entwicklung liegt in der Ermittlung der Größe eines Projektes oder genauer gesagt: der Größe der Aufgabe. Es gilt folglich, ein Maß für die Arbeit in der Software-Entwicklung zu finden. Dieses Maß muß originär sein, es darf sich also nicht durch die Art der Realisierung und die daraus abgeleiteten Größen bestimmen.
In dem oben genannten Beispiel wird beispielsweise die geleistete Arbeit des Fahrers in Kilometern und nicht in Kraftstoff-Verbrauch oder in Autostunden gemessen. Letztere vermitteln zwar eine Information über die zurückgelegte Entfernung, werden jedoch de facto vom Fahrstil, den Wetterverhältnissen etc. beeinflußt.
Wer heute in der Software-Entwicklung mit Maßen für die Projektgröße arbeitet, verwendet fast ausschließlich Sekundärmaße. Die gebräuchlichsten Maße dieser Art sind Mannmonate und Lines of Code (LoC).
Die Maßeinheit Mannmonate ist ein Sekundärmaß, das durch sehr viele Faktoren beeinflußt wird: Die fachlichen und DV-technischen Kenntnisse der Projektmitarbeiter gehen darin ebenso ein wie die Art der Programmiersprache, der Hardware und der Tool-Umgebung. Mannmonate sind eine Maßeinheit, die durch die Produktivität der Entwicklungsumgebung sehr stark beeinflußt wird.
Mit Hilfe der Mannmonate lassen sich Aussagen über die Dauer und die Kosten eines Projektes gewinnen. Sie beschreiben aber nicht die absolute Größe des Projektes. Projekte mit gleicher absoluter Größe führen mit Sicherheit zu einer unterschiedlichen Anzahl von Mannmonaten, wenn sie in unterschiedlichen Entwicklungsumgebungen realisiert werden.
Die Lines of Code werden von erheblich weniger Faktoren
beeinflußt als die Mannmonate. Die bestimmenden Faktoren sind im wesentlichen die Art der Programmiersprache und der Arbeitsstil des Programmierers. Sicherlich besteht eine Korrelation zwischen der Größe eines Projektes und der Anzahl der Lines of Code.
Wer jedoch die Anzahl der Befehle vergleichen und daraus
eine Aussage über die Größe zweier Projekte ableiten will,
muß die Mächtigkeit dieser Befehle beachten. Beispielsweise
steht die notwendige Anzahl der Assembler-Befehle zur entsprechenden Anzahl der Cobol-Statements im Verhältnis 300: 105.
Betriebswirtschaftlicher Umfang einer Aufgabe
Die bisher besprochenen Maßgrößen sind zwar nicht vollkommen sinnlos, aber sie stellen kein primäres Maß für die Größe eines DV-Projektes dar. Die ideale Maßgröße wäre eine Zahl, die den funktionalen, betriebswirtschaftlichen Umfang eines Projektes bewertet.
Eine solche Maßzahl würde die Größe einer betriebswirtschaftlichen Aufgabenstellung messen, ohne dabei vorauszusetzen, daß das Problem mit einer bestimmten Organisationstechnik gelöst wird. Außerdem würde sich diese Maßzahl gleichermaßen auf eine manuelle, eine auf PCs basierende oder eine Mainframe-Lösung anwenden lassen.
Zu messen ist die fachliche Aufgabe aus der Sicht des Anwenders. Dabei sollte sich aber auch der Nutzen der Aufgabenstellung für den Anwender in dieser Maßzahl widerspiegeln.
Die Maßeinheit, die die oben gestellten Anforderungen erfüllt, sind die Function Points. Sie gewinnen im englischsprachigen Raum zunehmend an Bedeutung. Dort haben sich bereits Function Point User Groups gebildet, die für eine internationale Standardisierung dieser Methode eintreten.
Das Prinzip der Function-Point-Methode
Das Prinzip der Function-Point-Methode beruht darauf, daß die Benutzer Oberflächen und vorgehaltene Datenbestände ermitteln und nach einheitlichen Regeln bewerten. Der Benutzer definiert also, welche Informationen er benötigt und aus welchen Quellen, Eingaben oder Datenbeständen er sie sich erstellen lassen will. Dazu ist kein DV-Wissen notwendig, sondern vielmehr das Wissen um den betriebswirtschaftliche Inhalt.
In der Praxis ergibt sich hier das Problem, daß der Software-Entwickler primär die technische Lösung im Auge hat und die Fachabteilung nicht über ausreichendes Organisations-Know-how verfügt. Dies wirkt sich vor allem dann negativ aus, wenn der Funktionsumfang dazu genutzt werden soll, eine Aufwandsschätzung in einem frühen Stadium der Software-Entwicklung abzugeben.
Sollten die internationalen Function Point User Groups
eine einheitliche Definition dieser Methode durchsetzen, so würden wir eine objektive Maßeinheit erhalten. Sie wäre auch dazu geeignet, Größenvergleiche zwischen Software-Entwicklungen unterschiedlicher DV-Anwender zu anzustellen.
Um eine Leistungen zu messen, reicht es nicht aus, nur die inhaltliche Größe eines Projektes zu kennen. Die Anforderungen an die Qualität beeinflussen den Aufwand nämlich ebenfalls merklich.
Bei der Beurteilung der erbrachten Leistung muß also auch die Qualität des Produktes bekannt sein. Hierbei ist wieder primär an die Qualität der betriebswirtschaftlichen Lösung gedacht und weniger an die Qualität der späteren technischen Umsetzung, beispielsweise die Anzahl der Fehler auf 1000 Codezeilen.
Im Rahmen der Software Metrics sind deswegen Qualitätsmerkmale zu definieren und zu bewerten. Das Problem dabei besteht darin, daß Qualität stark subjektiv beurteilt wird. Dient beispielsweise das Antwortzeitverhalten als ein Qualitätsmerkmal, so können drei Sekunden für den einen Anwender ausreichend, für den anderen hingegen völlig ungenügend sein.
Für eine innerbetriebliche Produktivitätsermittlung sollte sich deswegen jeder Anwender einen eigenen Qualitätsrahmen festlegen, an dem sich seine Projekte messen lassen. Zwischenbetriebliche Vergleiche sind aufgrund des Mangels an einheitlichen Qualitätskriterien zunächst noch kritisch zu betrachten - zumindest solange es nicht gelungen ist, allgemein verbindliche Qualitätsmerkmale und deren Bewertung festzulegen.
In der Praxis hat sich gezeigt, daß weniger als zehn Qualitätsmerkmale ausreichen. Diese lassen sich nutzen, um prozentuale Zu- oder Abschläge auf die originäre Projektgröße vorzunehmen.
Eine wichtige Management-Zahl für die Software-Entwicklung läßt sich aus den Function Points für ein Produkt ableiten. Es handelt sich um das Verhältnis von Function Point (FP) zu Entwicklungszeit (t). FP/t lautet die Formel für den Produktivitätsfaktor der Software-Erstellung, kurz PFS genannt.
Wird der PFS über einen längeren Zeitraum ermittelt, so läßt
sich daraus eine durchschnittliche Produktivität ableiten. Diese dient beispielsweise dazu, den Aufwand anstehender Projekte zu schätzen.
Wie sich empirisch nachweisen läßt, nimmt der PFS mit der Größe des Projekts ab: Große Projekte werden also mit einer geringeren Produktivität erstellt als kleine. Diese Erkenntnis sollte in die Aufwandsschätzung einfließen, um ein zuverlässigeres Ergebnis zu erzielen.
Der PFS ist die Kenngröße, mit der sich die Wirkung von Änderungen im Entwicklungsumfeld nachweisen läßt. In der Praxis zeigt sich beispielsweise, daß die Software-Erstellung mit Sprachen der vierten Generation einen höheren PFS aufweist als die Entwicklung mit Cobol. Und die Qualität des Personal-Managements wird sich ebenso auf den PFS auswirken wie eine Umstellung von einem Betriebssystem auf ein anderes.
Die Mächtigkeit von Programmiersprachen läßt sich aus dem Verhältnis von Lines of Code zu Function Points nachweisen. Eine Maßzahl für die Qualität der Software ist der Quotient von Anzahl der aufgetretenen Fehler durch Function Points.
Die Statistik über den Aufwand pro Function Point und Jahr, bezogen auf die einzelnen Projekte, liefert eine wichtige Kennzahl für die Planung des Wartungsaufwands.
Auf der Grundlage dieser Statistik läßt sich dann der jährliche Wartungsaufwand für die Zukunft schätzen. Dabei zeigt sich vor allem, daß der Wartungsaufwand für ein Projekt keineswegs über seine gesamte Lebensdauer konstant ist. Diese Tatsache wird heute von den wenigsten Software-Managern beachtet.
Voraussetzung für die Nutzung von Management-Zahlen ist in jedem Fall ein detailliertes Berichtswesen. Das beschränkt sich jedoch bei den meisten Software-Entwicklern auf eine einfache projektbezogene Zeiterfassung.
Ein Berichtswesen über die Wartungsaktivitäten existiert nur in wenigen Fällen. Insofern ist das Bewußtsein dafür zu schaffen, daß ein Berichtswesen nicht nur als Grundlage für die Nachkalkulation oder eine Leistungskontrolle not tut, sondern auch eine Art Erfahrungs-Datenbank bereitstellt, die Informationen für die Planung der Unternehmensführung liefert.