Schmitt-Rousselle
            
  Start Publikationen Artikel Autor Verlag

Ardo Schmitt-Rousselle

Grundlegende Metriken und KPI's
für zeitgemäße (iterative) Softwareentwicklung
 
Die hier im Auszug aufgezeigten Metriken stellen nur eine generelle Basis für ein plan- und ergebnisorientiertes Arbeiten. Dabei ist es nicht so bedeutend, welche Technik oder welches Prozessmodell Anwendung findet. Wichtig ist Planung und stetige Überprüfung der Ergebnisse, ohne die Anforderung und Ergebnis kaum zur Deckung gelangen.

Die Beispiele sind alle aus dem "echten" Leben gegriffen. Dabei wurden möglichst überschaubare Bereichsgrößen gewählt.

Text und Bilder sind dem ersten Entwurfsmanuskript entnommem.

 Inhalt  Einführung
1 Einleitung
1.1 Ziel
1.2 Mittel
1.3 Modell der Prozessänderung
1.4 Gliederung
 
aus Teil 1: Essentielle Softwaremetriken
2 Projektführung
2.1 Fragenkatalog Projektführung
2.2 Auswertung
2.3 Beispiel
 
3 Entwicklungsprozess
3.1 Datenerhebung
3.2 Auswertung
3.3 Beispiel KPI und PI Entwicklungsprozess
 
4 Fehlerreaktions- und Behebungszeit
4.1 Datenerhebung
4.2 Auswertung
4.3 Beispiel KPI und PI Fehlerreaktions- und Behebungszeit
 
aus Teil 2: Hilfsmetriken
5 Fehlerverteilung
 
aus Teil 3: Komplexe Softwaremetriken
6 Planungstreue draft
6.1 Datenerhebung Planungstreue
6.2 Auswertung
6.3 Beispiel PI Planungstreue
 
7 Anforderungen (Requirements)
7.1 Datenerhebung Anforderungen
7.2 Auswertung
7.3 Beispiel PI Anforderungsstabilität
 
8 Koordinierte Planung
8.1 Beispiel
 
aus Teil 4: Grundbegriffe
9 Iteration
9.1 Anforderungen
9.2 Komplexität
9.3 Risikomanagement
9.4 Erfolgskontrolle
9.5 Besonderheiten
9.6 Beispiel
 
10 Firmenorganisation - Ressourcencontrolling - Ressourcenauslastung
10.1 Die funktionsorientierte Entwicklung
10.2 Die prozessorientierte Entwicklung
10.3 Die flussorientierte Entwicklung
 
11 Planung
 
 
 
   
Einführung
 
 
 
1. Einleitung  

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.


 
 
1.1 Ziel  

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.

 

 
 
1.2 Mittel  

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.

 

 
 
1.3 Modell der Prozessänderung  

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.

 

 
 
1.4 Gliederung
 

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.

 
 
2. Projektführung  


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.

 

Projektführung

Schlüssel

Zielsetzung

Verbesserung der Qualität und der Prozessreife innerhalb der einzelnen Projekte à kontinuierliche Steigerung des Standards

PI /KPI

Methode

Messung anhand eines Fragenkatalogs

 

Geltungsbereich

Projekt

PI

 

 

 

Globale Ausrichtung
(Beispiel)

Eine kontinuierliche Steigerung um … Punkte innerhalb der nächsten 2 Jahre ist vorgesehen.

KPI

Einzelausrichtung

Kein Projekt darf unter … Punkte fallen.

PI

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?

An dieser Stelle sei auf Steve McConnell's Software project survival guide verwiesen, mit Hilfe dessen der Autor seine ersten Projektbewertungen vornahm. Fragen und Auswertungssystematik haben sich verändert, die Punkteregelung wird nach wie vor angewandt.
 
 
 
2.1 Fragenkatalog Projektführung  

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.


 
 
Projektdefinition (Anforderungen)  

Projektdefinition (Anforderungen)

Punkte

Sind alle funktionalen Anforderungen eindeutig definiert und von dem Auftraggeber (Kunde / Produktmanagement) abgezeichnet?
à Grobspezifikation, Requirementspezifikation

0 - 3

Sind alle nichtfunktionalen Anforderungen eindeutig definiert und von dem Auftraggeber (Kunde / Produktmanagement) abgezeichnet?
à Grobspezifikation, Requirementspezifikation, Qualitätsmanagementplan

0 - 3

Sind alle Anforderungen an Schnittstellen zu Fremdsystem definiert und von dem Auftraggeber (Kunde / Produktmanagement) abgezeichnet?
à Grobspezifikation, Schnittstellenbeschreibungen

0 - 3

Gibt es eine verbindliche Vereinbarung, wie mit Anforderungsänderungen umgegangen wird?
à Change Management Plan, Change Management Board

0 - 3

Ist das Projekt inklusive aller Nebenleistungen sowohl ausreichend budgetiert und als auch terminiert und von allen Beteiligten als realistisch abgenommen?
à Sales, Produktmanagement, Entwicklungsleitung

0 - 3

Sind alle Projektleistungen inklusive Spezifikationen, Dokumentationen, Plänen, Training, Supportleistungen, ... festgelegt?
à Projektmanagement Plan, Qualitätsmanagementplan, Vertrag

0 – 3

Summe

0 - 18

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.

 

 
 
Prohektplanung  

Projektplanung

Punkte

Wird der Projektplan regelmäßig (je Iteration / Projektphase) aktualisiert?
à Projektplan
Wird diese Aktualisierung von den beteiligten Verantwortlichen mitgetragen?
à Entwicklungsleitung, Analyse, Implementierung, Test, Qualität

0 – 2

0 - 1

Beinhaltet der Projektplan alle essentiellen funktionalen Projektdokumente mit realistischer Projektzeit?
à Analyse, Design, Konfiguration, Test, Qualität, Auslieferung

0 - 3

Beinhaltet der Projektplan die Erstellung eines Prototypus oder kann ein vorhandenes System als Prototyp dienen?

0 - 3

Wird auf eine bekannte Baseline aufgesetzt oder eine solche als Startpunkt etabliert?
Wird die iterative Entwicklung oder Phasenentwicklung von Baseline zu Baseline vollzogen?

0 – 1

0 - 2

Ist der Projektprozess inklusive Verantwortlichkeiten festgelegt?
à Projektmanagementplan, Qualitätsmanagementplan.

0 - 3

Projektumgebung, Eskalation

0 – 3

Summe

0 - 18

 

 
 
Projektkontrolle  

Projektüberprüfung, -kontrolle

Punkte

Finden regelmäßig Projektmeetings statt, auf denen die entsprechenden Beteiligten über den laufenden Projektstand informiert werden?
à Statusmeeting (Entwicklungsbereich)
Sind die Informationen klar und nachprüfbar?

0 – 2



0 - 1

Finden regelmäßig Projektmeetings statt, auf denen die entsprechenden Beteiligten über den laufenden Projektstand informiert werden?
Ist Erfüllung von Iterationsschritten oder Projektphasen von dieser Interessengruppe einfach nachzuvollziehen?
à Statusmeeting (Kunde, Produktmanagement, Sales), aktualisierte Dokumentation

0 – 2


0 - 1

Befinden sich alle relevanten Projektartefakte unter Versionskontrolle?
Ist diese Aufgabe als Spezialaufgabe delegiert?

0 – 2

0 - 1

Ist es ein Change Management etabliert?
Gibt es ein Change Management Board?
à Projektleiter, Konfiguration, Analyse, Test, Qualität

0 – 2
0 - 1

Hat der Projektleiter die alleinige Projektverantwortung d.h. ist er der Ansprechpartner sowohl für Kunde (Produktmanagement, Sales) als auch für die Projektmitglieder?

0 - 3

Wird die Überprüfung aller relevanten Projektartefakte (gemäß der Projektdefinition) von einem zum Projektteam gehörenden qualifizierten Qualitätssicherer geleitet?
Berichtet dieser regelmäßig auch an das unabhängige Qualitätsmanagement?

0 – 2


0 - 1

Summe

0 - 18

 

 
 
Risikomanagement  

Risikomanagement

Punkte

Wurde zu Projektbeginn ein Risikomanagement etabliert?
Wurde ein Risikoplan anhand der definierten Ziele und der Infrastruktur erstellt?
à Riskmanagement Plan

0 – 1
0 – 2

Wird dieser Risikoplan regelmäßig aktualisiert?
Wird bei jeder Aktualisierung eine Neubewertung der Prioritäten vorgenommen?

0 – 1
0 – 2

Ist der Risikoplan für alle Beteiligten zugänglich?
Gibt es die Rolle des Risikomanagers (¹ Projektleiter)?

0 – 2
0 – 1

Wenn auf vorausgegangenen Projekten aufgesetzt wird:
Ist der Code für die definierte Baseline stabil?
Sind die dazugehörigen Test- und Defektreports vorhanden?

 

0 – 2
0 – 1

Wenn auf vorausgegangenen Projekten aufgesetzt wird:
Ist die Dokumentation und Spezifikationen für die verwendeten Subsysteme ausreichend verständlich?

 

0 – 3

Wenn Drittanbieter involviert sind:
Ist deren Leistung und Planung im Risikomanagement ausreichend vertreten?

 

0 – 3

Summe

0 – 18

 

 
 
1. Einleitung  

Ressourcen

Punkte

Entsprechen die technischen Kenntnisse des Projektteams den Anforderungen? Wenn nicht, sind ausreichend Qualifizierungsmaßnahmen geplant?
à Projektmanagement Plan (à Trainingsplan), Projektplan, Risikoplan

0 – 3

Ist das Projektteam homogen, d.h. werden tragende Funktionen von erfahrenen Fachkräften besetzt?

0 – 3

Wird das Projekt von einem erfahrenen Projektleiter geführt?

0 – 3

Wird das Projektziel von allen Projektteilnehmern als realistisch zu verwirklichen in der vorgesehenen Zeit angesehen?

0 – 3

Arbeitet das Projektteam gut zusammen?

0 – 3

Wird an einer Lokation entwickelt? D.h. Können und finden persönliche Gespräche, Rückfragen etc. ohne weiteres zwischen Analyse, Codierung und Test statt?

 

0 – 3

Summe

0 – 18

 

 
 
2.2 Auswertung  

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.

Gesamt

Rubrik

Wertung

Prozent

76 - 90

16 – 18

Hervorragend

84 % - 100 %

61 - 75

13 – 15

Gut

67 % - 83 %

41 - 60

9 – 12

Mäßig (normal)

46 % - 66 %

16 – 40

6 -   8

Mit relevanten Risiken

17 % - 45 %

0 - 15

0 -   5

Zum Scheitern verurteilt

  0 % - 16 %

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.

 

 
 
2.3 Beispiel
2.3.1 KPI und PI Projektführung
 

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.
legende

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.

 
 
2.3.2 Projektrubriken  

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


 
 
3. Entwicklungsprozess  

Ä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.

 

Entwicklungsprozess

Schlüssel

Zielsetzung

Firmenweite Verbesserung des Entwicklungsprozesses

KPI

Methode

Messung anhand der Defektdatenbank

 

Geltungsbereich

Firmenweit

KPI

 

Einzelprojekt

PI

Globale Ausrichtung
(Beispiel)

Innerhalb der nächsten ... Monate sollen:

  • Analysefehler < 2%,
  • Designfehler < 7% und
  • Implementierungsfehler > 60% betragen

KPI

Einzelausrichtung

Diese Vorgaben gelten auch für die einzelnen Projekte

PI

 

 
 
3.1 Datenerhebung Entwicklungsprozess  

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.

 
 
3.2 Auswertung  

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.

 

  3.3 Beispiel KPI und PI Entwicklungsprozess 


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:

Analyse
Design
Implementierung

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.


 
 
4 Fehlerreaktions- und Behebungszeit  

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.

 

Fehlerreaktion und -behebung

Schlüssel

Zielsetzung

Firmenweite Verbesserung der Geschwindigkeit hinsichtlich Fehlerbehebung

KPI

Methode

Messung der Stati submitted bis tested anhand der Fehlerdatenbank

 

Geltungsbereich

Firmenweit

KPI

 

Einzelprojekt

PI

Globale Ausrichtung
(Beispiel)

Innerhalb der nächsten ... Monate sollen:


Priorität

Bis fixed

Bis tested

1 (rien ne va plus)

6 h

10 h

2 (major)

10 h

16 h

KPI

Einzelausrichtung

Diese Vorgaben gelten für jedes Kundenprojekt, wenn vertraglich nicht noch schärfer vereinbart.

PI

 

 
 
4.1 Datenerhebung  

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.

 

 
 
4.2 Auswertung  

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.

 

 
 
4.3 Beispiel KPI und PI Fehlerreaktions- und Behebungszeit  

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
Repaired

          Fehlerbehebungszeit bis tested
tested

legende

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.

 
 
5. Fehlerverteilung  

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.

 

Entwicklungsprozess

Schlüssel

Zielsetzung

Projektfamilienweite Verbesserung der einzelnen Module

PI

Methode

Messung anhand der Defektdatenbank

 

Geltungsbereich

Projektfamilie

PI

 

Einzelprojekt

PI

Globale Ausrichtung
(Beispiel)

Innerhalb der nächsten ... Monate soll die Maximale Kenngröße für ein Modul / Lokation auf ... sinken.

KPI

Einzelausrichtung

Keine Modul darf die Kenngröße ... überschreiten.

PI

Denkbar ist auch eine Einteilung nach Lokationen. Dies schließt auch Entwicklungspartner ein.

 

 
 
5.1 Datenerhebung   Vorbedingung ist ein funktionierendes Defekttracking, indem die betroffenen Module aufgeführt sind.
 
 
5.2 Auswertung  

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.


Rechenbeispiel: Ein Projekt besteht aus 45 Modulen. Damit liegt der Index bei (100/45=) 2,22.
Bei Modul A treten 3,78% aller Fehler auf. Somit ergibt sich für dessen Kennzahl 1,7 (=3,8/2,22).
Bei Modul B treten 1,1% aller Fehler auf. Somit ergibt sich für dessen Kennzahl 0,5 (=1,1/2,22).

Rechenbeispiel: Bei einem Codevolumen von 1 000 000 LOC treten 2 500 Fehler auf. Damit beträgt der Fehlerdurchschnitt 1 Fehler pro 400 Zeilen. Diese Relation 1:400 wird = 1 gesetzt.
 Ein Module mit 50 000 Zeilen hat demnach eine mittlere Fehlererwartung von 125 Fehlern. Diese 125 Fehler entsprechen der Maßzahl 1, (250 Fehler = Maßzahl 2, 100 Fehler = Maßzahl 0,8).

 

 
 
5.3 Beispiel Fehlerverteilung (Methode 1: absolut)  

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.

fehlerverteiling

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

 

 
 
Beispiel Fehlerverteilung (Methode 2: gewichtet)  

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.


 
 
5.5 Beispiel Fehlerverteilung (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.

 

 

 

     aus Teil 3: Komplexe Softwaremetriken
 
 
6 Planungstreue  

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

 

Planungstreue

Schlüssel

Zielsetzung

Firmenweite Planungssicherheit

KPI

Methode

  • Messung der definierten Zeitabschnitte (Milestones, Iterationen)
  • Messung der benötigten Manntage

 

Geltungsbereich

Firmenweit

KPI

 

Einzelprojekt

PI

Globale Ausrichtung
(Beispiel)

Eine kontinuierliche Verbesserung der Einhaltung der Milestones um ... Prozent und des Budgets um ... Prozent ist innerhalb der nächsten 2 Jahre vorgesehen.

KPI

Einzelausrichtung

Kein Projekt darf die Milestones um mehr als ... Prozent überschreiten, kein Projekt darf sein Budget um ... Prozent überschreiten.

 

 

 
 
6.1 Datenerhebung  

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.

 

 
 
6.2 Auswertung  

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.

 

 
 
6.3 Beispiel PI Planungstreue  

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.

 

 
 
7 Anforderungen (Requirements)  

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:

Anforderung

Urheber

Funktional

Kunde, Produktmanagement

Nicht funktional

Kunde, Produktmanagement (z.B. Performance)

Technisch

Entwicklung

Nicht funktional

Entwicklung, QM (z.B. Wiederverwertbarkeit)

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.

 

Anforderungsstabilität

Schlüssel

Zielsetzung

Erkennung von Fehlplanung

KPI

Methode

Messung anhand der Iterationspläne und deren Bewertung

 

Geltungsbereich

Firmenweit

KPI

 

Einzelprojekt

PI

Globale Ausrichtung
(Beispiel)

Die auf nicht äußere Einflüsse zurückzuführenden Anforderungsänderungen sollen in den nächsten ... Monaten zurückgehen:
Priorität 1 < 1%
Priorität 2 < 2%

KPI

Einzelausrichtung

Diese Vorgaben gelten auch für die einzelnen Projekte

PI

 

 
 
7.1 Datenerhebung   Um signifikante und aussagekräftige Bewertungen erzielen zu können, müssen folgende Vorarbeiten implementiert sein:
Die Projektführung wird bewertet (insbesondere 2.1.1 und 2.1.2)
Der Entwicklungsprozess wird bewertet (Kapitel 3) insbesondere die Analyse (Abgrenzung).
Alle Anforderungen und Change Requests werden systematisch aufgenommen und priorisiert (Datenbankanwendung z.B. Requisite Pro) und sind nach verschiedenen Kriterien (z.B. Urheber, Kosten, Abhängigkeit, usw. sortierbar).
 
 
7.2 Auswertung  

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.

 
 
7.3 Beispiel PI Anforderungsstabilitä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.


 
 
8 Koordinierte Planung  

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.

 

Koordinierte Planung

Schlüssel

Zielsetzung

Firmenweite Planungssicherheit und -kohärenz

KPI

Methode

Messung anhand eines Fragenkatalogs

 

Geltungsbereich

Firmenweit

KPI

 

 

 

Globale Ausrichtung
(Beispiel)

Eine kontinuierliche Steigerung um … Punkte innerhalb der nächsten 2 Jahre ist vorgesehen.

KPI

Einzelausrichtung

Die Bereiche Vorstand (Ebene 1) und IT (Ebene 2 dürfen nicht unter “gut” fallen.

 

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?

 

 
 
8.1 Beispiel  

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.

 

 
 
    aus Teil 4: Grundbegriffe
 
 
9. Iteration  

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.

 
 
9.1 Anforderungen  

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.

 
 
9.2 Komplexität  

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.

 

 
 
9.3 Risikomanagement  

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. 

 
 
9.4 Erfolgskontrolle  

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!)

 
 
9.5 Besonderheiten  

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.

 
 
9.6 Beispiel  

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.

Aufgabenverteilung über 4 Iterationen

Legende:  

i

Anforderungen

 

Analysis & Design

 

Implementierung

 

Test

 

Dokumentation

 

 

 

 

Projektmanagement

P

C

Qualitätsmanagement

P

C

Konfiguration

P

C

        1                   2                 3                  4

P = Planung, C = Controlling

 

 
 
10 Firmenorganisation - Ressourcencontrolling - Ressourcenauslastung  

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.

 

 
 
10.1 Die funktionsorientierte 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.

 
 
10.2 Die prozessorientierte Entwicklung  

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.

 
 
10.3 Die flussorientierte Entwicklung  

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.

 

 
 
11 Planung  

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.


Planung

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.

© 2005, 2013 Dr. Ardo A. Schmitt-Rousselle Impressum       Sitemap