Die Software-Produktivität wird heute noch immer in "Lines of code" angegeben. Dabei sind sich die meisten Fachleute der Ungenauigkeit dieses Verfahrens bewußt. Andererseits sind Anhaltswerte immer noch besser als gar keine Zahlen. In dem Beitrag von Georg Erwin Thaller* sollen daher die Schwächen und Widersprüche dieser Vorgehensweise diskutiert werden.
Daß Informationen über die Produktivität in einem modernen Unternehmen unverzichtbar sind, steht wohl außer Frage. In der Regel bieten entsprechende Messungen auch keine unüberwindlichen Schwierigkeiten. Ein Büromaschinen-Hersteller produziert zum Beispiel alle fünf Minuten eine Schreibmaschine.
Ein Automobilkonzern hat eine Tagesproduktion von 500 Wagen pro Werk. Die Software-Erstellung dagegen muß eher als eine intellektuelle Tätigkeit gesehen werden. Kaum jemand würde auf den Gedanken kommen, die Leistung eines Malers oder Schriftstellers in Meßgrößen wie Seiten pro Tag oder Bilder pro Monat zu erfassen.
Ein nicht zu unterschätzender Faktor ist auch die Qualität der Software. Die gelieferte Software muß den Erwartungen der Kunden gerecht werden. Während in den Anfangsjahren der industriellen Herstellung von Software diese Fragen weitgehend vernachlässigt wurden, zwingen uns nun eine Reihe von Faktoren zu einer genaueren Betrachtung:
1. Computer und Software sind ein zentraler Bestandteil der Organisation aller Unternehmen, von Regierungsbehörden bis zu den Streitkräften geworden.
2. Immer mehr Produkte werden durch Mikroprozessoren gesteuert und kontrolliert vom Toaster bis zum Patriot-Waffensystem.
3. Die Entwicklung der Software ist bei vielen Projekten der Faktor, der über Erfolg und Mißerfolg entscheidet.
4. Die von Unternehmen vermarktete Software trägt in überragendem Maße zur Durchsetzung am Markt bei.
5. Manager aus dem Industrie- und Behördenbereich sind übereinstimmend der Meinung, daß die Software-Erstellung die am wenigsten professionelle Disziplin im High-Tech-Bereich ist.
In Würdigung dieser Argumente wollen wir uns das Maß "Lines of code" etwas genauer ansehen. Dabei fallen zwei Widersprüche auf: Wird die Produktivität höherer Programmiersprachen und ihr Nutzen für ein Unternehmen in Lines of code kommt man zu völlig falschen Aussagen über die Produktivität. Der zweite Widerspruch entsteht, wenn man das Fehleraufkommen an den Quellcodezeilen mißt: Die Anzahl der Fehler pro 1000 Zeilen könnte ein völlig falsches Bild über die Produktivität der Sprachen entstehen lassen.
Mit diesen Widersprüchen verbunden sind eine Reihe von Fragen, die zur Verwirrung beitragen:
- Es gibt keine gemeinsame Norm, nach der Lines of code ermittelt werden;
- für den Vorgang der Software-Erstellung existiert keine abgrenzende Definition;
- Erfüllung des Zeitplans und die Ablieferung eines qualitativ hochwertigen Produkts stehen oft im Widerspruch zueinander;
- Faktoren, die zur Produktivität beitragen könnten zum Beispiel Tools oder eine verbesserte Arbeitsumgebung der Programmierer - werden vom Management häufig vernachlässigt;
- Software-Erstellung und Wartung werden nicht auseinander gehalten.
Doch wenden wir uns zunächst den beiden genannten Widersprüchen zu. In unserem Beispiel (Abbildung 1) soll ein Programm mit identischem Funktionsumfang in Assembler sowie in den höheren Programmiersprachen PL/1 und APL realisiert werden. Nimmt man die Lines of code als einen Indikator für die Produktivität bei der Software-Erstellung, so ergibt sich das dargestellte Bild.
Wer also von Assembler auf eine höhere Programmiersprache umstellt, könnte nach der abgebildeten Tabelle auf die Idee kommen, daß der ganze Aufwand völlig umsonst war. Die Produktivität ist von 500 LOC/MM beim Einsatz von Assembler auf 125 LOC/MM bei APL gesunken. Das ist natürlich verständlich, wenn man weiß, daß höhere Programmiersprachen sehr viel mächtiger sind, und sich ein gegebenes Problem mit weniger Codezeilen formulieren läßt. Das richtige Bild entsteht erst, wenn die Gesamtkosten betrachtet werden. Hier ergibt sich in der Tat eine Senkung der Kosten von über 50 Prozent.
Eine höhere Programmiersprache wie etwa APL beeinflußt zwar die Produktivität positiv, doch in der Meßgröße Produktivität in LOC/MM schlägt sich dies überhaupt nicht nieder. Über die Mächtigkeit höherer Programmiersprachen im Vergleich zu Assembler gibt auch Abbildung 2 Aufschluß.
Wer nun fragt, warum die Gesamtkosten nicht ebenso wie die Anzahl der Zeilen auf ein Zehntel der Assembler-Werte zurückgegangen sind, übersieht eine wichtige Tatsache: Die Lines of code beziehen sich auf nur eine einzige Phase des Software-Entwicklungsprozesses, nämlich das Kodieren oder die Implementierungsphase. Die übrigen Phasen hingegen unterscheiden sich in ihrer Produktivität kaum voneinander, weshalb die Gesamtkosten weniger stark abfallen.
Trotzdem lohnt sich der Einsatz höherer Programmiersprachen schon allein wegen der Kostensenkung - von den positiven Auswirkungen auf die Qualität des Codes gar nicht zu reden.
Trotzdem ergibt sich auch bei der Messung der Fehlerzahl in Verbindung mit Lines of code eine paradoxe Situation (Siehe Abbildung 3). Auch hier ergibt sich das widersinnige Bild, daß sich die Anzahl der Fehler in bezug auf den Quellcode verfünffacht hat, wenn wir Assembler und APL miteinander vergleichen.
Erst der Vergleich der Fehler-Gesamtzahl führt zu einer korrekten Aussage - und hier fällt auf, daß die Fehleranzahl um insgesamt 50 Prozent gesunken ist. Auch bei dieser Betrachtung verzerrt also die Mächtigkeit der Programmiersprachen das Bild. De facto geht die Fehleranzahl mit der zunehemenden Komplexität der Programmiersprache deutlich zurück: Der Einsalz höherer Programmiersprachen kann auch aus Gründen der Qualitätssicherung nur empfohlen werden.
Verschiedentlich wurde vorgeschlagen, die Fehlerzahl nicht auf den Quellcode, sondern auf den Binärcode in Bytes zu beziehen, um das oben geschilderte Problem zu umgehen. Dieses Vorgehen erweist sich aber bald als Irrweg. Wenn nämlich zur Erzeugung des binären Images ein optimierender Compiler eingesetzt wird, steigt auch hier der Indikator für die Qualität an. Wir stoßen also wieder auf einen Widerspruch. Der Einsatz optimierender Compiler ist allerdings erwünscht, da der Binärcode so klein wie möglich sein sollte.
Fest steht also, daß verschiedene Indikatoren ein falsches Bild zeichnen, wenn man sich auf Lines of code bezieht. Doch es gibt noch weitere Schwachpunkte: Zur Zählung der Lines
of code werden in der Praxis sehr unterschiedliche und nur bedingt vergleichbare Methoden verwendet. Das beginnt beim Zählen der physikalischen Programmzeilen beim Assembler und endet beim Zählen aller Programmanweisungen, Datendeklarationen und Kommentare. Nun lassen sich sicherlich Argumente für jede angewandte Methode finden.
Gegeben sei folgende Programmzeile in der Sprache C: tag = 29; monat = 2; jahr = 1992;/* Test des Schaltjahrs */.
Je nach der eingesetzten Art und Weise der Definition und Zählung von Lines of code können hier eine oder vier Zeilen gezählt werden. Aus rein praktischen Erwägungen wird wohl
meistens ein bestimmtes Zeichen registriert, denn wer will schon Tausende von Programmzeilen von Hand durchzählen.
Bei C dürfte das Semikolon das Zeichen sein, das letztlich die Lines of code bestimmt. Kommentarzeilen würden hier nicht eingehen, obwohl sie in bezug auf die Wartung eines Moduls eigentlich unverzichtbar sind. Ich neige dazu, Kommentarzeilen als einen prozentualen Aufschlag zu berücksichtigen, da mir gerade der Modulheader zur Kontrolle der Software als unverzichtbar erscheint. Doch das mag in anderen Organisationen anders gehandhabt werden.
Ein weiteres Problem besteht darin, die Software-Erstellung zu definieren und abzugrenzen. Ausgehend von einem herkömmlichen Vorgehensmodell ist die Analyse der Anforderungen sicherlich die erste Tätigkeit, die eindeutig der Software-Entwicklung zuzuordnen ist. Davor muß allerdings bereits eine Systemanalyse durchgeführt worden sein. Soll sich die Software harmonisch in den Rahmen des Gesamtsystems einordnen, ist für diese Tätigkeit eine Mitarbeit der Fachleute aus der Software-Entwicklung sicherlich notwendig - diese muß gepreist und verrechnet werden.
Stärker noch treten die Zuordnungsprobleme am Ende des Phasenmodells hervor: Die Softwarewartung und -pflege stellt natürlich einen bedeutenden Kostenfaktor bei den Gesamtausgaben für Software dar. Allerdings ist diese Phase nicht mehr eindeutig der Software-Entwicklung zuzurechnen. Bei Kostenberechnungen ist also immer zu klären, welche Phasen der Software-Entwicklung eigentlich abgedeckt werden sollen.
Ein weiterer, zuweilen nur wenig berücksichtigter Punkt, sind Aktivitäten, die zwar nicht zur Software-Entwicklung im engeren Sinne gehören, die für die Erstellung hochwertiger Produkte jedoch unbedingt durchgeführt werden müssen, und die nicht immer in die Planung eingehen.
Dazu zählen zum Beispiel die Dokumentation, Kosten für Fehlerbeseitigung, für Reisen und Kommunikation oder auch für Investitionen in moderne Ausrüstung.
Der Aufwand für die Dokumentation wird meist unterschätzt. Ein Waffensystem wie das Kampfflugzeug F-18 ist mit einer Benutzerdokumentation von 30 000 000 Seiten verbunden - eine solche Dokumentation will erst einmal erstellt werden. Auch die Fehlerkorrekturen sind aufwendig: Fehler müssen durch Testverfahren nicht nur gefunden werden, ihre Beseitigung nimmt die kostbare Zeit der Programmierer in Anspruch. Ein erneuter Test schlägt dann ebenfalls zu Buche, und für die Qualitätssicherung und das Konfigurationsmanagement fallen bei jeder Änderung Kosten an. Gerade bei Projekten im internationalen Rahmen sind zur Abstimmung unter den Partnern bei Reviers und Tests Reisen notwendig.
Die Ausrüstung der Programmierer mit leistungsfähigen Rechnern, Werkzeugen und einer angenehmen und leistungssteigernden Umgebung erfordert in der Regel hohe Investitionen, die angesichts des schnellen technischen Fortschritts meistens nach kurzer Zeit abgeschrieben werden müssen. Das Finanzamt gibt in der Regel seine Zustimmung, wenn ein Arbeitnehmer den privaten PC für das Arbeitszimmer innerhalb von drei Jahren abschreibt. Das ist schließlich realistisch. Manche Unternehmen gehen hier noch von falschen Voraussetzungen aus.
Nur wer Software ausliefert, die den Erwartungen des Auftraggebers entspricht, wird sich am Markt behaupten können. Die Erfüllung des Zeitplans muß sicherlich angestrebt werden, doch darf die Qualität des Produkts nicht der Erfüllung des Zeitplans zum Opfer fallen.
Angesichts der offensichtlichen Schwächen, die die "Maßeinheit" Lines of code zeitigt, erhebt sich die Frage nach den Alternativen. Einige Vorschläge sind gemacht worden, doch keiner konnte auf Anhieb überzeugen. So regte Albrecht die Verwendung sogenannter "function points" an. Der Name führt leicht zu Mißverständnissen. Die Messung beruht auf einer gerichteten Zahl von Eingaben, Ausgaben, Abfragen, Dateizugriffen und Schnittstellen eines Programms.
Die Festlegung der Eingaben zur Ermittlung der function points bedarf sicherlich ebenfalls einer klaren Definition. Die Methode beginnt sich jedoch im kommerziellen Bereich und bei Informationssystemen zunehmend durchzusetzen. Für Echtzeitsysteme und im militärischen Bereich, wo komplexe Algorithmen zum Einsatz kommen und harte Forderungen an das Zeitverhalten des Systems zu berücksichtigen sind, ist die Technik wohl weniger geeignet.
Andere Methoden, wie Thomas McCabes Komplexitätsmaß, sind wohl eher im Bereich der Metriken einzuordnen und sollen daher an dieser Stelle nicht weiter behandelt werden. Zwar ist klar, daß erhöhte Komplexität eines Programms auch die Kosten in die Höhe treibt. Allerdings kann dies alleine keine Grundlage für eine Methode zur Erfassung der Produktivität bilden.