1.5 Die Klassiker: Lines of Code, Fehleranzahl, Personentage

1.5.1 Beschreibung und Zweck

• Lines of Code: Dient zur Beschreibung der Größe von Programmen und wird in der Regel auf Quellcode angewendet. Meßwert ist die Anzahl von Programmzeilen, die eventuell durch das Weglassen von leeren Zeilen und Kommentarzeilen, eventuell auch Deklarationszeilen modifiziert werden kann. Die Programmgröße ist eine wesentliche Grundlage für viele Vorhersagen, weil sie einerseits Ausgabe von Schätzungen ist und andererseits als Eingabe anderer Schätzungen benötigt wird (Zeit, Personal, Kosten, Speicherplatz etc). Sie dient auch zur Berechnung zahlreicher indirekter Maße wie Fehlerdichten, Strukturiertheitsgrad etc.
• Fehleranzahl: Dient zur Beschreibung der Korrektheit von Programmen und wird entweder auf den Quellcode oder die Programmausführung bezogen. Meßwert ist entweder die Zahl dynamisch auftretender Programmversagen oder die Zahl statisch im Programmtext vorhandener Defekte. Ebenso wie die Größe ist die Fehleranzahl die Basisgröße für sehr viele Maße, die die Qualität von Software beschreiben (Fehlerdichte, Zuverlässigkeit, Debuggingproduktivität etc.).
• Personentage: Dient zur Beschreibung des Aufwands an Arbeitszeit für eine Softwareaufgabe. Meßwert ist z.B. die Anzahl von Projektmitarbeitern für jeden Projekttag, summiert über alle Projekttage; oft werden für die Erfassung Wochen oder Monate anstatt Tage zugrundegelegt. Ebenfalls eine wichtige Basisgröße für zahlreiche indirekte Maße, die sich mit Kosten, Zeitbedarf oder Produktivität befassen.

Eine exakte Definition wird hier für keine dieser Größen angegeben, weil es Dutzende unterschiedliche Arten gibt, diese Größen sinnvoll zu definieren.

Es gibt noch ein viertes klassisches Basismaß, nämlich die Echtzeit (gemessen meist in Kalendertagen). Dies ist jedoch so elementar, daß wir im folgenden nicht näher darauf eingehen.

1.5.2 Probleme und Grenzen

Die Definitionen aller drei Maße sind im praktischen Einsatz meist ungenau. Das liegt daran, daß die Maße so verführerisch einfach und intuitiv einleuchtend aussehen. Bei Lines of Code hat sich die Notwendigkeit einer genauen Definition inzwischen herumgesprochen, aber schon bei der Fehleranzahl hapert es erheblich: Was genau ist eigentlich ein Fehler (im Gegensatz z.B. zu einer ,,freiwilligen`` Verbesserung)? Von einer Einteilung der Fehler in disjunkte Klassen, die die Grundlage für viele weitere nützliche Analysen des Fehlerverhaltens ist, ganz zu schweigen. Bei den Personenmonaten stellt sich die Frage, ob die Basis ihrer Berechnung ein Pauschalverfahren ist, wie oben angegeben, oder eine Zeiterfassung im Einzelfall (d.h. für jede Person) auf Basis von Wochen oder Tagen oder Stunden oder gar Minuten.

Selbst mit genauen Definitionen ist es für alle drei Maße schwer, übertragbare Messungen zu machen, weil die Meßwerte von vielen Umgebungsfaktoren abhängen, die nur selten gleich (oder auch nur überhaupt alle bekannt) sind.

• Lines of Code: Größen sind nur für den gleichen Programmierer im gleichen Problembereich und mit der gleichen Programmiersprache direkt vergleichbar. In allen anderen Fällen ist die Größe nur ein grobes Maß für die ,,Menge`` an Software, unter der man intuitiv zumeist die Menge an realisierter Funktionalität versteht. Beim Vergleich sehr verschiedener Anwendungsgebiete oder sehr verschiedener Programmiersprachen kann das Maß sogar äußerst irreführend werden. Siehe auch die Diskussion in Abschnitt 6.5.2.
• Fehleranzahl: Die Reproduzierbarkeit (und damit Objektivität) ist für das Maß Fehleranzahl nicht gewährleistet, weil zur Abgrenzung zwischen Fehler/Nichtfehler oder zwischen ein Fehler/mehrere Fehler oft komplexe menschliche Entscheidungen nötig sind, die sich nicht formalisieren lassen. Es ist sehr schwierig, Fehlerklassifizierungen aufzustellen, die eine zumindest meistens eindeutige Zuordnung erlauben und dennoch viel nützliche Information liefern.
• Personentage: Die Übertragung zwischen unterschiedlich strukturierten Softwareorganisationen ist schwierig, spätenstens sobald die Tätigkeit von unterstützendem Personal wie Sekretärinnen oder Systembetreuern mit eingerechnet werden soll. Selbst die Vergleichbarkeit über Projekte derselben Organisation hinweg ist gering, sobald einzelne Projektbeteiligte an mehreren verwandten Projekten zugleich arbeiten oder sobald Wiederverwendung der erzeugten Softwarekomponenten angestrebt wird oder bei ihrer Erstellung frühere Software wiederverwendet wird. Zwar kann man den Aufwand für die gesamte Organisation recht gut berechnen, eine sinnvolle Zuweisung an die einzelnen Projekte ist aber sehr schwierig.

1.5.3 Wichtigkeit

Die beschriebenen Maße sind die Basis für fast alle höheren Maße und sind oft nicht durch bessere Maße zu ersetzen: sie sind faktisch unverzichtbar.

• Lines of Code: Da der Ausstoß an Programmzeilen pro Tag im Mittel für einen Programmierer recht konstant ist, sind LOC eine wichtige Grundlage für viele Maße, die mit Arbeitsgeschwindigkeit oder Arbeitsmenge zusammenhängen. Es ist beispielsweise zwar ein Fehler, LOC/Tag mit der Produktivität zu verwechseln, jedoch liefert das Maß sehr wohl Hinweise darauf, ob z.B. ein Programmierer plötzlich zu viel von der Arbeit abgehalten wird (Wert sinkt) oder vielleicht zwischendurch schlampig arbeitet (Wert steigt).
• Fehleranzahl: Fehler nehmen eine sehr zentrale Rolle im Softwareprozeß ein, weil sie zum einen die Produktivität beherrschen und zum anderen zentrale Qualitätsmerkmale von Software direkt beeinflussen. Große Teile der Zeit im Softwareprozeß werden auf die Fehlervermeidung, -findung und -behebung verwendet und die Zahl von Fehlern, die schließlich im Produkt ausgeliefert wird, wirkt sich stark auf die Zuverlässigkeit, Benutzbarkeit und Nützlichkeit der Software aus. Deshalb ist die Fehleranzahl Grundlage für sehr wichtige Maße wie Fehlerdichten pro Modul (um kritische Module zu entdecken), Fehlerdichten pro Arbeitsphase (um den Prozeß zu verbessern), Fehlerartenhäufigkeiten (ebenfalls um den Prozeß zu verbessern).
• Personentage: Da sich die meisten Anstrengungen der Softwaretechnik letztlich darum ranken, die Kosten zu senken, die fast vollständig von den Personalkosten beherrscht werden, sind Personentage ein grundlegendes Maß zur Bestimmung fast aller Arten von Kostenfaktoren im Softwareprozeß. Es gibt noch einen zweiten zentralen Aspekt bei der Softwareproduktion: die Zeit bis zum Markteintritt. Diese ist heute oft sogar noch wichtiger als die Kosten, weil der Markt fast völlig vom ersten Anbieter einer neuen Funktionalität beherrscht wird (siehe z.B. Netscape). Da sich Softwareproduktion nicht beliebig auf Arbeitskräfte aufteilen läßt, sind auch für dieses Maß und damit zusammenhängende Hilfsmaße die Personentage eine wichtige Basis.

1.5.4 Fazit

Die klassischen Maße verlangen zu ihrer sinnvollen Anwendung nach einer genauen Definition und disziplinierten Meßverfahren. Dann jedoch kann mit ihnen trotz ihrer Schwächen einiges geleistet werden:

• LOC: Ist bei konstanten Umgebungsbedingungen ein konsistenter Normierungsfaktor für viele Prozeß-, Produkt- und Ressourcenmaße. Nützlich, weil automatisierbar und im voraus schätzbar.
• Fehleranzahl: Hat begrenzte Genauigkeit, aber extrem hohen Nutzwert zur Steuerung des Prozesses und seiner Verbesserung, wenn die Daten in Form einer Fehlerklassifizierung vorliegen. Die Fehleranzahl ist vielleicht die wichtigste direkte Messung überhaupt, weil Fehler so stark sowohl auf Qualität als auch Produktivität einwirken.
• Personentage: Haben begrenzte Genauigkeit, sind aber unersetzlich zur Beschreibung der Kosten. Sind auf Umweg über andere Maße schätzbar, und bilden deshalb eine wichtige Grundlage für die Planung.

1.5.5 Beispiel: Definition von LOC

Hier zur Veranschaulichung eine halbwegs genaue realistische Definition von Lines of Code:

• Richtlinien:
  • Jede Anweisung wird auf mindestens eine Zeile für sich geschrieben.
  • Anweisungen, die dafür zu lang sind, werden unter Beachtung der korrekten Einrückung und einer sinnvollen Zerlegung in möglichst wenige Stücke zerlegt.
  • Jede Deklaration einer Variablen erfolgt auf einer getrennten Zeile. Das gilt auch für Elemente von Verbunden und Parameter von Prozeduren.
  • Jede Deklaration eines Verbundtyps mit n Elementen oder einer Prozedur mit n Parametern umfaßt also n+1 Zeilen.
  • Eine For-, While-, Repeat- etc. Anweisung ist um zwei Zeilen länger als ihr Rumpf (Kopfzeile und END-Zeile).
  • Eine If-Then-Else-Anweisung ist um vier Zeilen länger als ihr Rumpf, bei fehlendem Else-Teil um drei Zeilen.
• Zählweise: Bei Einhaltung dieser Richtlinien werden Lines of Code dann folgendermaßen gezählt: Jede physische Zeile jeder zum Programm gehörigen Datei zählt, ausgenommen
  • Leere Zeilen.
  • Zeilen, die ausschließlich Kommentar oder...
  • ...Blocktrenner enthalten (BEGIN, END).

Je nach Programmiersprache müßte man noch Richtlinien zum Layout von Case-Anweisungen und von Elseif-Ketten geben, sowie für diverse Spezialkonstruktionen, die die Sprache zuläßt (beispielsweise Import- und Exportlisten, Schabloneninstanziierungen etc.).