Es wird viel von einer Krise innerhalb der Software gesprochen. Dem wird weitläufig zugestimmt und zum Alltag übergegangen. Der Autor möchte hier bewusst überspitzt formulieren: Wir haben keine Softwarekrise, sondern eine Softwaremanagementkrise. Damit soll ausgedrückt werden, dass ein Softwareunternehmen anders geführt werden muss als z.B. ein Autokonzern. In den letzten Jahren haben sich Verfahrensweisen herauskristallisiert, die erfolgreicher sind als andere. Es wird nicht mehr viel vom „scrach“ entwickelt, auch hat die Entwicklungsmethodik zugenommen. Allein, dies haben die Vorstandsetagen bisher im allgemeinen noch wenig realisiert und in folge dessen sprechen Management und Entwicklung verschiedene Sprachen und arbeiten oft asynchron. Mit diesem Handbuch wird auch der Versuch unternommen, diese Welten enger zusammenzuführen.

Jedes Unternehmen, insbesondere ein Softwareproduzent stellt ein hoch komplexes und sensibles Gebilde da. Veränderungen wirken sich unternehmensweit aus und dies ist sinnvoll und bewusst zu steuern. Statistiken sind ein unentbehrliches Hilfsmittel, allein die Erhebungsgrundlagen müssen klar, verständlich und kompatibel sein, damit ihre Aussagen dass leisten können, was sie zu leisten versprechen.

Dieses Handbuch behandelt grundlegende Mess- und Bewertungsverfahren für eine zeitgemäße Softwareentwicklung. Alle vorgestellten Methoden entstammen der Praxis und haben sich dort bewert, d.h. sie haben zu konkreten Ergebnissen und Verbesserungen geführt.

Alle Verfahren sind bewusst einfach gestaltet, so dass ihre Einführung weder individuelle Infrastruktur noch schwer abschätzbaren Aufwand scheitern kann. Selbstverständlich bilden sie lediglich das persönliche Credo des Autors und sind nach örtlicher und inhaltlicher Gegebenheiten anzupassen oder zu erweitern.

Jede Maßnahme, jede Prozessveränderung bedarf eindeutiger Ziele. Das oberste Ziel jedes Unternehmens ist die Mehrung des Gewinns, zumindest die Konsolidierung eines gesunden finanziellen Zustandes. Somit ist letztlich jeder Aufwand mit dem Ertrag in Beziehung zu setzen.

Der Ertrag wird nicht im direkten Gegenzug erwirtschaftet, er wird über einen zu definierenden Zeitraum erzielt. Des weiteren muss zwischen Projektziele, Projektfamilienziele und unternehmensweiten Zielen unterschieden werden.[1] Diese differenzierten Ziele gilt es für jede Mess- und Bewertungsvorschrift genau vorzugeben. Gegen diese Ziele werden dann die Ergebnisse bewertet.

Die vorgelegten Metriken haben den Anspruch, einfach zu verstehen und einfach umsetzbar zu sein. Es wird bewusst auf jegliche spezielle Toolunterstützung verzichtet. Allerdings sollte die Anwendung der Officeprogramme, sowie das Schreiben einfacher SQL – Befehle und Batchdatein kein Hinderungsgrund darstellen.

Alle metrischen Untersuchungen zielen letztlich auf Kostenreduzierung[2]. Signifikant schlechte Werte signalisieren den Bedarf an Prozessänderungen. Eine Prozessänderung bedeutet Aufwand und Einarbeitungszeit für alle Betroffenen. Prozesse werden nicht von jetzt auf gleich umgestellt, sondern gemäß iterativer[3] Planung, die auch eine Kosten – Nutzen Kalkulation beinhaltet.

Eine Ursache für die Softwarekrise ist schlechtgeplante Unternehmenssteuerung. Heute sind flache Hierarchien das Maß aller Dinge, morgen wohl definierte Strukturen, die den Entscheidungsprozess durch Aufteilung in mehrere Entscheidungsebenen vereinfachen möchten. Ungeplante und unkalkulierte Prozessänderungen können sind mit hohen Risiken verbunden. Eine Prozessänderung, die sich nicht in 3 Monaten amortisiert, gilt oft schon als Fehlinvestition und wird zurückgenommen oder durch einen anderen Prozess ersetzt. Dass diese hektischen Aktivitäten letztlich nichts bringen außer Kosten und genervten Mitarbeitern ist evident. Dem vorzubeugen, ist eine sorgfältige Planung und Abstimmung im Vorfeld unabdingbar.

Prozessänderungen entstehen nicht losgelöst in den Rechnern der Prozessmanager, sondern zusammen mit denjenigen, die diese Prozesse leben werden. Nur die Prozesse, die auf eine breite Akzeptanz treffen, liefern gute Performancewerte. Wird diese Voraussetzung nicht geschaffen, wird ein Teil der täglichen Arbeitszeit daraufhin verwandt, genau diese ungeliebten Prozesse zu umgehen.

Prozessänderungen werden – wie gesagt – iterativ vollzogen. Dabei wird von Iteration zu Iteration eine Bewertung des geänderten Prozesses vorgenommen, der Aufschluss über die nächsten Schritte gibt.

Die meisten Prozesse sollen letztlich unternehmensweit gelten. Startpunkt ist jedoch ein einzelnes Projekt, das sozusagen zu einem Testprojekt des oder der Prozesse wird. Für dieses Verfahren sprechen schwerwiegende Gründe:

1. Auftretende Seiteneffekte werden minimiert.

2. Die Teammitglieder werden zu Multiplikatoren, die die Übertragung auf weitere Projekte erleichtern.

3. Konkrete Ergebnisse und Erfahrungen fließen in die Übertragung auf weitere Projekte ein.

4. Risiken werden verteilt. So ist es durchaus sinnvoll, in einem Projekt das Konfigurationsmanagement umzustellen und in einem anderen Projekt ein neues Modellierungswerkzeug einzuführen.

Das Vorliegende Handbuch gliedert sich in 3 Teile
1. Essentielle Softwaremetriken
In diesem ersten Teil werden die wesentlichen Metriken beschrieben die eine qualitativ hochwertige Software garantieren. Dabei tritt automatisch ein mittel- und unmittelbare Reduzierung des Aufwandes (zeit- und Kostenreduktion).
Alle beschriebenen Metriken sind einfach zu verstehen und einfach zu implementieren. Der Erfolg wird sich binnen 9 Monate einstellen, nach einem Jahr wird die Kosten – Nutzungsrechnung positiv ausfallen.
2. Komplexe Softwaremetriken
Der zweite Teil beschäftigt sich mit Metriken, die nur bereichübergreifend implementiert werden können. Bevor Sie sich dieser Aufgabe widmen, sollten Sie schon erste Erfolge mit den essentiellen Softwaremetriken vorzeigen können. Naturgemäß sehen Bereiche wie Controlling die Softwareproduktion mit anderen Augen als Sie und es ist Teil Ihrer Arbeit, die unterschiedlichsten Kriterien der Softwarebetrachtung einfließen zu lassen, so dass nicht eine nackte Statistik entsteht, die anscheinend eindeutige Schlüsse zulässt, in wirklich aber an den Kernproblemen vorbeigeht.
3. Grundbegriffe
Hier werden einige Themen besprochen, die zum Verständnis der vorgestellten Metriken und zugrundeliegenden Prozesse beitragen.

Dieser Fragenkatalog soll lediglich als Vorlage dienen, er ist den individuellen Bedürfnissen anzupassen und zu erweitern.

Jedes Softwareprojekt kann unter zwei maßgeblichen Hauptkriterien untersucht werden:
· Projektführung (Management)
· Entwicklungsprozess
In diesem Kapitel werden die grundlegenden Metriken für die Projektführung erläutert.

Der Fragenkatalog versucht folgende fünf Schlüsselantworten zu finden:
· Gibt es definierte Ziele?
· Sind diese Ziele geplant?
· Wird die Planung dieser Ziele überprüft bzw. werden die Ziele verifiziert??
· Gibt es in der Planung ein Risikomanagement?
· Sind die erforderlichen Ressourcen mit den entsprechenden Skills vorhanden?

Der Fragenkatalog ist in 5 Rubriken eingeteilt. Jede Rubrik besteht aus 6 Fragen. Die jeweilige Höchstpunktzahl beträgt 3 Punkte. Einige Fragen sind unterteilt. Pro Rubrik sind also maximal (3*6=) 18 Punkte möglich.
Die Punkte werden nach folgenden Kriterien vergeben:

0: Nicht vorhanden
1: Nicht wirklich vorhanden. Die Leistung ist zwar irgendwie aufgenommen, aber genügt nicht den Anforderungen.
2: Die Leistung wird vollbracht, könnte aber besser sein.
3: In Ordnung

Die maximal erreichbare Punktzahl für den gesamten Fragenkatalog beträgt demnach (5*18=) 90 Punkte.

Die Rubrik Risikomanagement hat drei Bedingungsfragen. Die Höchstpunktzahl ist hier variable und sollte auf 18 hochgerechnet werden. (Wenn z.B. nur 4 Fragen beantwortet werden und deren Punktzahl 8 ergäben sollte die Weiterberechnung mit (8/12*18=) 12 erfolgen.

Für die Auswertung werden einerseits die einzelnen Rubrikergebnisse verwendet, als das Gesamtergebnis. Sinkt z.B. das Projektergebnis unter 41 Punkten (46%), so weist das Projekt schon gravierende Mängel auf, bei einem Ergebnis von unter 30 Punkten (33 %) sollte Daueralarm gegeben werden, d.h. das Projekt selbst sollte neu überdacht werden.
Die meisten Projekte bewegen sich zwischen 41 (60%), nicht desto weniger sollten auch hier genausten nachgefragt werden, wenn 9 Punkte (46 %) in einer Rubrik unterschritten werden.

Mit den Ergebnissen lassen sich folgende 4 Indikatoren bilden:
KPI Projektführung (Mittelwert)
Die Summe aller Projektgesamtergebnisse wird aufaddiert und durch die Anzahl der Projekte geteilt.
Teil – KPI Projektrubrik (Mittelwert)
Die Summe aller Projektteilergebnisse wird aufaddiert und durch die Anzahl der Projekte geteilt.
PI Projektführung
Die einzelnen Projektergebnisse werden betrachtet.
Teil – PI Projektrubrik
Die einzelnen Projektteilergebnisse werden betrachtet.

In dem Beispiel wird eine Steigerung von 60 auf 74 Punkten über den Zeitraum von 2 Jahren vorgesehen. Die Datenerhebung findet regelmäßig alle 3 Monate statt.

Die Abbildung zeigt den typischen Verlauf einer Prozessverbesserung: Die Besserung tritt sichtbar erst nach geraumer Zeit auf und sie bewegt sich in Wellenlinien nach oben.

Im Einzelnen: Projekt A, indem ein hoher Qualitätsstandard gefordert war und das dafür viel Unterstützung erhielt, startet gut und wird Referenzmodell für den Geschäftsbereich. Der Einbruch nach einem Jahr (Intervall 4) wird durch personelle Umstrukturierung verursacht. Die Projekte B und D sind Kurzprojekte (je ½ Jahr). D übernimmt weitgehend Struktur und Team von B. Das Projekt C1 kämpft mit multiside Entwicklung und konsequentem Baselining. Das Zwischenprojekt C2 wird als gescheitert eingestellt. C 3 richtet sich nun nach der allgemeinen Norm aus und profitiert von den Erfahrungen aus den anderen Projekten.

Hier ist keine Kennlinie vorgegeben. Sinn dieser Daten ist die Erkennung kritischer Bereiche.
Als Beispiel sei hier die Rubrik „Projektplanung“ gegeben.
Legende: siehe 2.3.1

Ähnlich bedeutend, wie die Projektführung, stellt sich der Softwareentwicklungsprozess da. Es ist eine wohlbekannte Tatsache, dass sich Versäumnisse und Fehler von einer Phase  zu nächsten in signifikanten Verteuerungen niederschlagen (siehe Grafik).

Legende: x-Achse: Projektphase y-Achse: Zeit Beispiel: Eine kleine nicht beachtete Anforderung, die im Produktdefinitionsprozess oder in der Grobspezifizierung lediglich 1 Stunde (0,13 MT) kostet, bedeutet für die Analysephase schon 2,7 Stunden (0,34 MT), dort nicht gefunden für die Designphase schon 7,4 Stunden (0,9 MT), dort nicht gefunden für die Entwicklungsphase 20 Stunden (2,5 MT) und erst in der Testphase entdeckt 54 Stunden (6,7 MT) Mehrarbeit.

Aus diesem Grunde muss der Erfolg der einzelnen Phasen gemessen werden, um gegebenenfalls direkte Maßnahmen ergreifen zu können.
Versäumnisse und Fehler in den Anforderungen sind naturgemäß schwer zu messen. Anforderungen sind nicht stabil.

Die folgenden KPI’s behandeln demgemäss die Phasen Analyse, Design und Implementierung.

Vorbedingung für die Erhebung von qualifizierten Daten bezüglich Fehlern, Versäumnissen und Problemen ist eine hinreichende aber nicht zu komplexe Klassifizierung. Auf die Vorschlagsliste werden hier folgende Klassen gesetzt:

• Anforderung
• Analyse
• Design
• Implementierung
• Datenbank
• Konfiguration
• Schnittstelle
• Testumgebung
• Verständnis (Spezifikation)
• Dokumentation
• Verschiedenes

Wünschenswert aber irrealistisch wären Implementierungsfehler à 100%. Die Klasse „Verschiedenes“ sollte kein Auffangbecken für unzureichendes Testen sein, sondern Problemen vorbehalten sein, die in keine dieser Rubriken passen oder nicht hinreichend durch diese abgedeckt werden.

Die Datenauswertung erfolgt in regelmäßigen Abständen gemäß den ausgesuchten Fehlerklassen.
Mit den Ergebnissen lassen sich folgende 2 Indikatoren bilden:
KPI Entwicklungsprozess
Die Fehler werden pro Fehlerklasse unternehmensweit aufaddiert und prozentual zu den Gesamtfehlern ausgewiesen. Dabei werden die ausgewiesenen Fehlerklassen getrennt aufgeführt.
PI Entwicklungsprozess
Die Fehler werden pro Fehlerklasse projektbezogen aufaddiert und prozentual zu den projektbezogenen Gesamtfehlern ausgewiesen. Dabei werden die ausgewiesenen Fehlerklassen getrennt aufgeführt.

In dem Beispiel wird eine Reduktion der Analysefehler auf 2%, der Designfehler auf 7% und eine Steigerung(!) der Implementierungsfehler auf 60%  über den Zeitraum von 2 Jahren vorgesehen. Die Datenerhebung findet regelmäßig alle 3 Monate statt.

Die Datenerhebungen liefern folgende Resultate:

Legende: Vorgabe: blau
x-Achse: Auswertungszeitpunkt: alle 3 Monate
y-Achse: Defekts in Prozent

Die Abbildung zeigt deutlich anfängliche Schwäche im Bereich des Designs. Innerhalb eines halben Jahres wurde der geforderte KPI sogar übertroffen (7,7%). Dass in diesem Zeitraum die Analysefehler leicht ansteigen, liegt an der Maßnahme, Kapazitäten aus der Analyse in das Design zu verlagern. Diese Maßnahme erwies sich als richtig, was auch die gleichzeitig ansteigende Verteilung der Implementierungsfehler zeigt.

Wer arbeitet, macht Fehler. Fehler müssen systematisch und nachvollziehbar beseitigt werden. Dafür gibt es den Fehlerbehebungsprozess
Fehler werden in 2 Kategorien eingeteilt: Schwere (Severity) und Priorität (Priority). In diesem Zusammenhang interessiert die Kategorie Priorität, da diese für die Fehlerbehebungszeit zuständig ist.

Vorbedingung für die Erhebung qualifizierter Daten ist ein funktionstüchtiger Defekttrackingprozess. Die Daten werden regelmäßig der Fehlerdatenbank durch einmal geschriebene SQL Befehle entnommen.

Die Datenauswertung erfolgt in regelmäßigen Abständen gemäß dem ausgesuchten Zeitraum, der Prioritäten und den Stati.
Mit den Ergebnissen lassen sich folgende 2 Indikatoren bilden:
KPI Fehlerreaktions- und Behebungszeit
Die Gesamtbehebungsdauer aller Fehler wird durch die Gesamtsumme aller Fehler geteilt. Dabei wird nach Priorität unterschieden.
PI Fehlerreaktions- und Behebungszeit
Die Gesamtbehebungsdauer aller projektspezifischen Fehler wird durch die Gesamtsumme aller projektspezifischen Fehler geteilt. Dabei wird nach Priorität unterschieden.

In dem Beispiel wird von einer Reduktion der Bearbeitungsgeschwindigkeit von submitted auf repaired über den Zeitraum von 2 Jahren auf 6 Stunden vorgeschrieben, von submitted auf tested auf 10 Stunden. Die Datenerhebung findet regelmäßig alle 3 Monate statt.

          Fehlerbehebungszeit bis repaired

          Fehlerbehebungszeit bis tested

Es dauerte fast ein Jahr, bis der Fehlerkreislauf die gewünschte Performance zeigte. Nach und nach waren verschiedene Probleme zu beheben:
Die Implementierer wurden angehalten, Defekte hoher Priorität verstärkt neben ihrer täglichen Arbeit zu bereinigen (x-Achse: 2).
Daraufhin zeigte sich, das die Priorität mit unter fälschlich genutzt wurde, um einem Fehler Nachdruck zu verleihen, dem diese Priorität nicht zustand. Die Verantwortlichen (Projektleiter bzw. Leiter Implementierung wurden angehalten, die Prioritätenvergabe allgemeinverantwortlicher zu handhaben. Daraufhin verbesserte sich die Fehlerbehebungszeit signifikant (x-Achse: 3 à 4).
Als letztes zeigte sich, das Fehler zwar behoben, aber nicht direkt nachgetestet wurden. Nachdem die Verantwortlichkeiten in diesem Prozessabschnitt  verändert waren, zeigte der gesamte Fehlerbehebungszyklus signifikante Fortschritte (x-Achse: 4 à 5).

aus Teil2: Hilfsmetriken

Die folgenden Metriken beleuchten Teilaspekte der Softwareentwicklung. Sie haben unterstützende Funktion, sind aber nicht ohne weiteres geeignet, Key Perfomance Indikatoren zu bilden.
Die Hilfsmetriken sollen viel mehr „Rote Ampeln“ darstellen, die auf Gefahren aufmerksam machen und Handlungsbedarf signalisieren.

Eine Metrik hinsichtlich der Fehlerverteilung  sollte für jedes Projekt selbstverständlich sein, interessant wird die Auswertung für Projektfamilien. Unternehmensweit sind diese Metriken nicht relevant, es sei denn unter Maßgabe einer groben Granularität wie GUI, Business-Logik, usw.
In diesem Kapitel wird die Fehlerverteilung über einzelne Komponenten gemessen. Eine Produktfamilie besteht aus ähnlichen und verwandten Projekten, die teils nacheinander, teils parallel entwickelt werden. Dabei werden gemeinsame Komponenten genutzt, bzw. von gleichen Komponente aus weiterentwickelt. Dabei entstehen naturgemäß ähnliche Probleme, die mit gemeinsamer Anstrengung in eine vernünftige Kosten-Nutzen Relation gebracht werden können. Werden diese Aufwände lediglich einem Projekt zugeschlagen, wird einerseits das Projektbild verfälscht, andererseits bleiben sinnvolle Arbeiten als nicht projektspezifisch liegen. Diese Metrik soll einerseits die Argumentationsbasis für solche gemeinsame Projektziele liefern, andererseits aber auch echte Defizite in Teilbereichen aufzeigen.

Die Datenauswertung erfolgt in regelmäßigen Abständen.
Mit den Ergebnissen wird der folgende Indikator gebildet:
PI Fehlerverteilung: Methode 1 (absolut)
Die Fehler der einzelnen Module werden aufaddiert und prozentual zu den Gesamtfehlern ausgegeben. Das Ergebnis wird in Relation zum Index (= 100/Anzahl der Module) ausgegeben. Somit ist jedes Ergebnis unter 1 gut, jedes über 1 fordert weitere Analyse.
Diese Betrachtungsweise geht von einem gleichverteilten Schwierigkeitsgrad aus und vernachlässigt das Codevolumen.
Fehlerquote pro Module = (Gesamtfehler pro Modul / Gesamtfehler) / Index
PI Fehlerverteilung: Methode 2 (gewichtet)
Die Fehler der einzelnen Module werden aufaddiert und prozentual zu dem Gesamtcodevolumen ausgegeben.
Fehlerquote pro Module =
(Gesamtfehler pro Modul / Gesamtcodevolumen) / Index
PI Fehlerverteilung: Methode 3
Die Fehler der einzelnen Module werden über einen längeren Zeitraum z.B. monatlich aufaddiert und in Promille  zu den Gesamtfehlern ausgegeben.

In dem Beispiel wird ein Projekt betrachtet, das aus 45 Modulen besteht. Die folgende Grafik zeigt alle Module die Kenngröße 1 überschreiten. Diese Methode berücksichtigt nicht das Modulvolumen.

Fehlerverteilung auf Modulebene (absolut)
x-Achse: Anzahl der Fehler (1 = Durchschnitt)
y-Achse: Module, die den Durchschnitt (1) überschreiten

Dieses Beispiel zeigt die dazugehörige Projektfamilie, nun aber nach Codevolumen gewichtet. Die Durchschnittserwartung liegt bei 1 (Gesamtfehler/Gesamtvolumen). Die Grafik zeigt die Module, die den Faktor >= 2 aufweisen.

Fehlerverteilung auf Modulebene / LOC
x-Achse: Fehlerzahl (Modulfehler/LOC) bezogen auf 1
y-Achse: Module

Zwei Module (n 27 und n 44) überschreiten signifikant die Fehlererwartung.
N 27 litt an Performanceproblemen und wurde ständig überarbeitet. N 44 wurde von einer entfernteren Lokation gefertigt,  mit der Verständnisprobleme auftraten.

Beide Grafiken haben ihre Berechtigung. Die zweite volumenabhängige indiziert direkten Handlungsbedarf. Die erste Grafik ist einerseits interessant hinsichtlich der Resourcenverteilung andererseits - über einen längeren Zeitraum gemessen - indiziert sie die Module, die gänzlich neu geschrieben werden sollten. Letzteres zeigt auch die Methode 3.

Hier wird die Fehlerverteilung über einen Zeitraum von 30 Monaten wiedergegeben. Aufgeführt sind nur die Module, die signifikant (öfters) über ≥1‰ der Gesamtfehler) liegen.

Fehlerverteilung der signifikanten Module (10).
x-Achse: Fehlerzahl (in Promille der Gesamtfehler)
y-Achse: Monate (1-29

Im folgenden Ausschnitt sind zur Verdeutlichung die 3 kontinuierlichen Ausreißer vergrößert dargestellt.

Vergrößerung für 3 Module aus vorheriger Abbildung
x-Achse: Monate (1-29)
y-Achse: Fehlerzahl (in Promille der Gesamtfehler)

Das zu oberst widergegebene Modul A ist eindeutiger Aspirant für eine künftige Neuprogrammierung. Im Falle der Anforderung neuer Funktionalitäten wird die Fehlerrate ansonsten mit Sicherheit wieder die Spitzengruppe anführen.

Die Wichtigkeit von Planungstreue, die Einhaltung von Milestones und Budget bedarf keiner ausführlichen Begründung. Alle Planungsdaten, unternehmensweit als auch projektbezogen, sind nur in dem Maße wert, indem sie realisiert werden. Erst durch die Erfassung von Planungsdaten und ihrer Umsetzung kann von wirklicher Planung die Rede sein.
Zwei Hauptkriterien gilt es zu unterscheiden:

• Zeit (Milesstones)
• Budget

Zeit
Milestones sind Bestandteil des Auftrags. Diese werden auf Iterationen heruntergebrochen. Die Granularität ist feiner, da jede Iteration funktionale Einzelziele definiert.
Budget
Das Budget wird zu Beginn eines Projektes geplant. Jede Iteration lässt eine weitere und genauere Abschätzung zu.

Die Auswertung erfolgt einerseits Iterationsweise um eine stete Korrekturmöglichkeit innerhalb der Projekte zu gewährleisten. Des weiteren wird nach Abschluss eines Projektes der ursprünglich veranschlagte Aufwand mit dem tatsächlichen verglichen. Letztere Zahlen bilden den KPI.
Für jedes Projekt ist zu Beginn zu klären, in wie weit Hilfsaufgaben (Konfiguration, Administration usw.) Teil des Projektbudgets sind. Im Zweifelsfall gilt die Regel: Der Aufwand, der ohne dieses Projekt nicht verbraucht würde, wird dem Projekt zugeschlagen. Dass diese Regel unternehmensstrategisch falsch ist, braucht nicht groß ausgeführt werden (Qualität, Wiederverwendbarkeit, Kompatibilität usw.) Eine elegante Lösung stellen Hilfsprojekte da, die diese Aufgaben im Sinne zumindest einer Projektfamilie erledigen, aber nicht das Budget eines einzelnen belasten.

KPI Planungstreue
Diese unternehmensweite Kenngröße wird über einen längeren Zeitraum gemessen. Hier fließen nur die Daten abgeschlossener oder teilabgeschlossener Projekte ein.
Zeittreue: Die gesamtveranschlagte Zeit wird gleich 100% gesetzt. Die tatsächlich verbrauchte Zeit wird in Prozent angegeben.
Budgettreue: Das gesamtveranschlagte Budget wird gleich 100% gesetzt. Das tatsächlich verbrauchte Budget wird in Prozent angegeben.

PI Entwicklungsprozess
Die Daten werden bei jedem Iterationsende erhoben in Relation zu den geplanten Daten in Prozent angegeben.

Betrachtet wird ein durch Abnahme abgeschlossener Projektteil mittlerer Größe (9 Monate, mit insgesamt über 40 Beteiligten), das sich in 5 Milestones gliedert.
Das Projekt war auf 8 Monate terminiert, die Abnahmeerklärung erfolgte 4 Wochen später.

Die ersten beiden Iterationen wurden gründlich geplant, die erste erzielte sogar einen guten Puffer. Neue Anforderungen, für die 3. Iteration geplant, konnten nicht rechtzeitig eingearbeitet werden, da in der Eile nicht alle Implikationen gesehen wurde. Die 4. Iteration fing die Verzögerung durch Reduzierungen einiger interner Anforderungen wieder auf. Dieses Konzept erwies sich als Fehleinschätzung in der 5. Iteration, die alle Nacharbeiten zu leisten hatte.

Die Aufwandsabschätzung zeigt eine typische Projektschätzung, wie sie tagtäglich gehandhabt wird, nicht aber wie sie sein sollte.
Das Projekt ist 1 ½ mal so teuer wie geplant. In diesem Fall ist es immer noch ein finanzieller Erfolg, da in der ursprünglichen Planung einer Kundenanforderungen noch nicht berücksichtigt sind, die aber realisiert und bezahlt wurden.
Gravierender ist die von Iteration zu Iteration steigende Fehleinschätzung. Um den Termin zu halten, wurden stetig mehr Ressourcen unplanmäßig eingesetzt, was selten ein wirkungsvolles Mittel ist.

Die Behandlung von Anforderungen und die Messung ihrer Stabilität bzw. Konsistenz ist eine komplexe Materie. Anforderungen sind Anlass jeder Softwareentwicklung, den Grad ihrer Erfüllungen bestimmt die Abnahme.
Anforderungen lassen sich grob in folgende Kategorien einteilen:

Anforderungen werden priorisiert. Gemäß dieser Priorisierung wird eine Änderbarkeit abgeleitet. Anforderungen werden miteinander verknüpft, so dass jeder Zeit der gegenseitige Einfluss ersichtlich ist. Demzufolge kann eine niedrig priorisierte Anforderung, die bereits implementiert ist, sich als schwer änderbar zeigen, während eine Anforderung mittlere Priorität durchaus änderbar sein kann.
In der iterativen Entwicklung (siehe 9 Iteration) werden Anforderungsänderungen von Iteration zu Iteration geplant. Während einer laufenden Iteration darf keine Änderung angenommen werden. Jeder Iterationsstart hingegen darf mit neuen oder geänderten Anforderungen versehen werden.
Jede Anforderungsänderung wirkt sich unmittelbar auf Zeit und Budget aus, mittelbar auf Qualität (, wenn z.B. der Zeitrahmen gehalten werden muss.) Insofern ist die Ermittlung der Anforderungsstabilität trotz des oben gesagten sinnvoll.

Die Datenauswertung erfolgt regelmäßig bei Iterationswechseln als ca. alle 6 Wochen für jedes Projekt.
Mit den Ergebnissen lassen sich folgende 2 Indikatoren bilden
KPI Anforderungsstabilität
Siehe unten(PI). Die dort ermittelten Daten werden quartalsweise aufaddiert und prozentual zu den Gesamtmanntagen ausgegeben. Eine weiter Aufsplitterung nach Priorität wäre wünschenswert.
PI Anforderungsstabilität
Grundlage ist die Gesamtsumme an Manntagen in der entsprechenden Iteration. Der Aufwand bedingt durch Anforderungsänderungen und neue Anforderungen wird prozentual zu den Gesamtmanntagen angegeben. Dabei wird zwischen bezahlten und unbezahlten Aufwand unterschieden. Wünschenswert ist eine weitere Aufsplitterung nach Priorität.

In dem vorliegenden Beispiel lag keine Priorisierung vor. Die Bewertung erfolgte am Ende jeder Iteration in Prozent.

Legende:
Kundenspezifisch: grün
Intern: rot.

Die Abbildung zeigt (für 2) eine deutliche Anzahl an neuen Kundenforderungen. Diese entstanden einerseits weitgehend aufgrund des gelieferten Prototyps – der Kunde sah zum ersten Mal konkret was möglich ist. Des weiteren wünschte der Kunde in 2 und 3 die Einbindung weitere Schnittstellen. In 4 wurden neue Ausgabeformate implementiert. Die internen Anforderungsänderungen stellen ein typisches Grundrauschen da: je weiter die Entwicklung schreitet, um so mehr kann verbessert werden, insbesondere dann, wenn der Kunde schon mit einem Folgeauftrag winkt, der hier zwar noch nicht abgerechnet werden kann, für den aber Änderungen zum gegenwärtigen Zeitpunkt weitaus billiger sind, als nach endgültiger Fertigstellungen.

Voraussetzung für eine Überprüfung hinsichtlich einer Kohärenz innerhalb der generellen Planung über die 3 Ebenen ist naturgemäß das Vorhandensein einer solchen. Die Projektebene wurde in 0 besprochen. Ein Fragenkatalog für Unternehmensleitung bzw. CTO-Bereich wird hier nicht gegeben, er würde den Rahmen des Buches sprengen, da hier viel individueller, der Infrastruktur und der Kultur Rechnung getragen werden muss. Die 5 Schlüsselfelder jeder sind identisch.

Tabelle 14: KPI: Koordinierte Planung

Von den 5 definierten Schlüsselfelder werden folgende Kohärenzfragen abgeleitet:

• Decken sich die definierten Ziele innerhalb der drei Ebenen?
• Decken sich die Planungen innerhalb der drei Ebenen?
• Decken sich die Überprüfungsmechanismen innerhalb der drei Ebenen, d.h. wird sichergestellt, dass die In- und Outputs zeitgerecht miteinander kommunizieren?
• Deckt sich das Risikomanagement, d.h. treten keine Lücken oder Widersprüchlichkeiten auf? Werden vorgesehene Risikomaßnahmen auf unterer Ebene von der darüber liegenden getragen?
• Sind die Ressourcen und Verantwortlichkeiten so verteilt, dass sie sinnvoll harmonieren. Oder finden sich Doppeltbelegungen (hinsichtlich Aufgaben und Entscheidungsbefugnissen) oder treten Lücken hierin auf?

Das folgende Bild zeigt die Auswertung hinsichtlich der Kohärenz der 3 Bereiche über den gleichen Zeitraum. Es soll nicht verschwiegen werden, dass die Ermittlung dieser Daten mit wesentlich mehr Aufwand und Fingerspitzengefühl erfordert als die Metriken für die Projektführung.
Im vorliegenden Beispiel wurde die Steigerung um einen Punkt pro Quartal vorgesehen (schwarze Linie). Eine unternehmensweite Umstrukturierung schlägt sich deutlich nieder (4. Quartal). Danach arbeitet der CTO - Bereich (grün) mit den Projekten (gelb) gut zusammen.

Die meisten Softwareunternehmen verwenden einen iterativen Entwicklungsprozess – so sagen sie. Hinter den Kulissen plätschert der Wasserfall …
Es gibt nicht den iterativen Prozess, aber ist gibt die iterativen Prinzipien.
Die Technik der Iteration wird angewandt, um folgende Problemkreise in den Griff zu bekommen:

• Wechselnde Anforderungen
• Komplexe Software
• Risikomanagement
• Erfolgskontrolle
• Zeit – Geld

Eine Iterationspanne beträgt 6 Wochen ± 2 Wochen.

Stabile Requirements sind Illusion, sowohl in der Produktentwicklung als auch innerhalb von Kundenprojekten. Ein Produkt von scratch auf Markttauglichkeit zu entwickeln bedarf 3 Jahre Entwicklungszeit. Jeder Kenner der IT-Branche weiß, dass innerhalb von 3 Jahren maßgebliche Standardverschiebung stattfinden, die eine Umorientierung innerhalb laufender Projekte erfordern. Dies trifft naturgemäß auch auf Kundenprojekte zu, und es zeugt von einfacher Denkungsart, Anforderungsmängel allein auf dem Rücken des Kunden austragen zu können.
Die Iterative Entwicklung trägt dem oben gesagtem insofern Rechnung, dass sie die Entwicklung in Entwicklungsabschnitte (= Iterationen) teilt. Diese Iterationen sind nun nicht lediglich Phasen eines großen Wasserfalls, sondern implementieren alle diese Wasserfälle in jede Iteration (mit anderer Gewichtung selbstverständlich).
Zu Beginn jeder Iteration werden die für diese Iteration geplanten Anforderungen hinterfragt. Kommen neue hinzu, wird einerseits ihre Machbarkeit überprüft und andererseits ihre Verträglichkeit mit den schon implementierten bzw. geplanten Anforderungen untersucht.
Diese Vorgehensweise erlaubt der Projektleitung, Änderungen in den Projektzielen kontrolliert herbeizuführen.

Eine Software läuft nicht alleine. Sie kommuniziert mit unterschiedlichsten Systemen und sie besteht oft auch aus unterschiedlichen Systemen, Neuentwicklungen und Komponenten, die recht und öfters schlecht zum Zusammenspiel hingebogen wurden.
Jede Iteration beginnt mit einer Baseline. Eine Baseline besteht aus einer wohldefinierten Menge intern abgenommener Artefakte. Zu diesen zählen:
· Source code (inklusive Makefiles, Scripts, Bibliotheken)
· Dokumentation
· Planung
Jede Iteration beginnt also auf einem bekannten Terrain. (Lässt sich diese Baseline zu Projektbeginn nicht finden, ist es vordringlichste Aufgabe dieser Iteration, diese Baseline herzustellen.)
Jede Iteration hat wohl definierte Ziele. Diese Ziele können gänzlich unterschiedlicher Natur sein. Z.B. Iteration A:
1. Anpassung zweier Subsysteme (wiederverwendet),
2. Grundlegende Architektur des Basissystems (mit Ausnahme der Kundenverwaltung, deren Anforderungen noch ungeklärt sind),
3. Demoversion der GUI (mit Umriss der Kundenverwaltung),
4. Testen einer Servermigration Version x.n auf x.(n+1),
5. Schnittstellenvereinbarung mit Drittanbietern, ...
Am Ende dieser Iteration findet eine Bewertung statt (1 und 3 liefert Testreports, 2 liefert ein Review, 4 liefert eine Machbarkeitsstudie, 5 liefert ein Protokoll).
Die Resultate bilden die Baseline für die nächste Iteration, auf deren Grundlage wiederum diese Iteration geplant wird.

Innerhalb eines Projektrahmens sind folgende Risiken offensichtlich: technische Realisation, Skills und Ressourcen. Das iterative Prinzip fordert: „The biggest risk first“. Das größte Risiko kann sehr unterschiedlicher Natur sein: Hohe Performance bei größtmöglicher Flexibilität, Einführung neuer Technologie, enger Zeitrahmen (à z.B. einfache architektonische Lösung), zu wenig oder zu wenig erfahrene Ressourcen ...
Den größten Risiken hat die Projektführung zuerst zu begegnen. Bei der Evaluierung der ersten spätestens der zweiten Iteration gibt es immer noch die Möglichkeit, die Projektziele umzudefinieren, schlimmstenfalls kann das betreffende Projekt in dieser Form rechtzeitig aufgegeben werden.
Jede Iteration wird neue Risiken zeigen, durch ihre Einteilung und durch ein priotisiertes Entgegentreten werden Risiken wägbar. 

Aus dem oben gesagten wird klar, dass zu mindest am Ende jede Iteration eine objektive Bewertung des bisher ereichten stattfindet. Planungsziele und Realisierung werden einfach gegenübergestellt. Das betrifft sowohl die Projektzeit (in MT), als auch die technischen Funktionen (realisierte Funktionen in den einzelnen Modulen). Dabei sollten nur diese Funktionen als realisiert gewertet werden können, die 100% realisiert sind. Gegebenenfalls sind auf Unterfunktionen herunterzubrechen: die Aussage zu 98% fertig heißt nichts. (Die fehlenden 2 Prozent können noch Monate verschlingen!)

Das Change Management und die Fehlerbehebung wird in die iterative Entwicklung einbezogen, d.h. ein Change Request ist de facto eine neue Anforderung. Sie wird gleich jedem anderen Problem in das entsprechende Tracking Tool eingepflegt, über ihre Implementierung entscheidet der folgende Iterationsplan.
Implementierungsfehler werden direkt gefixt, Analysefehler werden in der folgenden Iteration behoben. Bei Designfehlern kommt es auf ihre Tragweite an. Ein umfassendes Redesign wird in der folgenden Iteration gemacht, eine kleine Designkorrektur wird analog eines Implementierungsfehlers behandelt.

Das folgende Beispiel zeigt die Aufgabenverteilung in einem iterativen Projekt. Der Wasserfallsgedanke ist immer noch sichtbar, einige wesentliche Aspekte iterativen Vorgehens sind jedoch schon implementiert. Nicht dargestellt ist die Angebots- und Abgabephase. Das Projekt dauerte inklusive Abnahme 9 Monate, jede Iteration im Schnitt 6 Wochen.
Das vorliegende Projekt lieferte in 1 das SAD und die Schnittstellenbeschreibungen, in 2 einen Prototypen und eine Implementierung der beiden als größtes Risiko eingestuften Funktionalitäten, in 3 alle Hauptfunktionalitäten, in 4 die Bereitstellung zur Abnahme.
Dieses Projekt lieferte die Basis für weitere Projekte, insofern war es architekturzentriert.

Was hat die Organisation des Unternehmens mit softwaremetriken zu tun. Auf den ersten Blick nicht viel. Zwei gängige Entwicklungsmodelle sind z.Z. aktuell: Funktionsorientierte Entwicklung bzw. prozessorientierte Entwicklung.

Funktionsorientierte Entwicklung bedeutet Spezialisten in funktionsorientierten Abteilungen (z.B. Analyse) zu führen. Dieses Modell findet sich häufig bei Unternehmen, die „multiside“ an verschiedenen Projekten gleichzeitig arbeiten. Die Gewinnversprechung dabei ist bessere Resourcenauslastung und größere Einzelkompetenz. Das hierbei zu meisternde Risiko liegt in der korrekten und vollständigen Übergabe der einzelnen Artefakte.
Auch wenn sich kein zeitgemäßes Softwareunternehmen mehr die Zeit und Struktur des V-/ Wasserfallmodells mehr leisten kann, passt diese Struktur generell mehr in diese Kultur. In der Praxis wird beispielsweise der Analyst auch nach Beendigung seiner speziellen Projekttätigkeit noch von Nöten sein, dieser Zeit und Wiedereinarbeitung steht aber im Widerstreit mit seinen derzeitigen Aufgaben.
Der Vorteil einer funktionalen Gliederung liegt in der dadurch entstehenden Unabhängigkeit einzelner Funktionseinheiten. Funktionen wie Querschnitt, Qualitäts- oder Performancemanagement greifen hier mehr durch die erweiterte Möglichkeit von Datenerhebung und vergleichenden Untersuchungen.

Bei der prozessorientierten Entwicklung liegt der Schwerpunkt auf „Alle für einen, einer für alle“. Es gibt ein Projektteam, das für alle Aufgaben zuständig ist. Dies ist insbesondere für iterative Entwicklung sinnvoll, da hier jede Tätigkeit – wenn auch mit verändertem Gewicht – immer wieder gebraucht wird. Der sich anbietende Rollentausch fördert die Qualifizierung des Einzelnen und den Teamgeist.
Andererseits kann hier ein Mangel an Austausch mit Fachkollegen (Spezialisten) auftreten, so dass eventuell an optimalen Lösungen vorbeigearbeitet wird. Die Datenerhebung und vergleichende Untersuchungen sind hierbei ungleich schwieriger, gerade weil die funktionale Beschränkung aufgehoben wird.

Die flussorientierte Entwicklung versucht die beiden obigen Strukturen zu verbinden. Einerseits gehört jeder Mitarbeiter einer funktionalen Einheit an, andererseits gehört er während eines Projektes dem Projektteam. Selbstverständlich ist die Anzahl der Projektmitglieder dynamisch, doch bleiben alle Schlüsselfunktionen während der Laufzeit besetzt. Ein eventuell entstehende Mangel an Wissenstransfer ist hierbei durch die Hinzuziehung von Fachkollegen gewährleistet.
So ideal diese Konstellation für einen erfolgreichen Projektverlauf ist, so problematisch sind die zu bildenden KPIs.

Wesentlicher Bestandteil der Analyse beruht auf Messungen hinsichtlich der Planungstreue. Planung ist Voraussetzung jeglicher Aktivität vom Vorstand bis zu Projektaktivitäten. Dazu gehört ein etabliertes Riskmanagement, das bei Risikofaktoren entsprechende Alternativen aufzeigt.
Es gilt dabei 3 Ebenen der Planung zu unterscheiden. Dabei sollten die Planungen miteinander harmonieren, d.h. die Firmen- und Projektausrichtung laufen im Einklang. Ein Projekt beispielsweise, das zwar zufriedenstellend voranschreitet, nicht aber innerhalb des eigentlichen Firmenscopes liegt, bindet eventuell Ressourcen, die im Kerngeschäft nötiger gebraucht werden. Die Bewertungsgrundlage für alle nachgeordneten Pläne ist der Road management Plan.
Der „Road management“ Plan ist das Werkzeug zur Firmensteuerung. Er bildet die Vision des Unternehmens auf einer Zeitachse ab. Es werden Milestones definiert, Aktivitäten mit Verantwortlichen gesetzt sowie benötigten Input als auch erwarteten Output festgelegt. Selbstverständlich ist diese grobkörnige Planung auch mit entsprechendem Budget versehen. Die Entwicklungsplanung fließt in diesen Roadplan ein bzw. wird von diesem abgeleitet.
Der Entwicklungsplan (oft CTO –Bereich genannt) gilt für den gesamten Entwicklungsbereich. Je noch Firmenstruktur sind hier auch Produktmanagement, –marketing oder auch External services angesiedelt. Grundsätzlich beinhaltet dieser Plan die Milestones und Hauptaktivitäten der Softwareherstellung. Dies sind einerseits die Projektspezifica, andererseits alle Hauptaktivitäten, die diese Aktivitäten beeinflussen (z.B. Toolumstellen, Technologietransfer, Frameworkerstellung ...). Der Entwicklungsplan gibt die grobkörnige Steuerung des Entwicklungsbereiches vor. Er gleicht die Unternehmensvorgaben mit dem Entwicklungsstand ab, gibt Impulse zurück und steuert die Projektvorgaben.
Der Projektplan spiegelt einerseits firmeninterne andererseits die Kundenspezifischen Vorgaben und Gegebenheiten wider.

Die folgende Abbildung soll das Zusammenwirken der drei Ebenen verdeutlichen. Dabei ist die Zeiteinteilung durchaus grob und nicht als strickte monatliche Vorgabe zu versehen. Eine Projektbewertung fällt bei jeder neuen Iteration an. Die Dauer von 6 Wochen ± 2 Wochen hat sich bewert.

Aus dem oben angeführten wird klar, das es nicht reicht, nur Projektspezifische Planungstreue zu messen. Ein ernstes Kriterium stellt das Vorhandensein von koordinierter Planung da.