Produktive Softwareentwicklung - Hans-Jürgen Plewan - E-Book

Produktive Softwareentwicklung E-Book

Hans-Jürgen Plewan

0,0

Beschreibung

Dieses Buch stellt Standards und den 'State of the Art' in der produktivitätsorientierten Steuerung und Durchführung von Softwareentwicklung dar. Praxiserprobte Verfahren zur Bewertung und Verbesserung der Produktivität in Softwareprojekten werden beschrieben und die Rahmenbedingungen und Erfolgsfaktoren aufgezeigt, unter denen Projekte und Teams produktiv sein können. Der Leser erfährt, wo in der Praxis die typischen 'Produktivitätsbremsen' zu finden sind und wie man sie vermeiden kann. Zahlreiche Praxisbeispiele, Tipps und Checklisten helfen bei der konkreten Umsetzung in der Praxis.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 344

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0



Produktive Softwareentwicklung

Dr. Hans-Jürgen Plewan ist Geschäftsführer der Finanz Informatik Solutions Plus GmbH in Frankfurt. Seit mehr als zwanzig Jahren kennt er den Projektalltag in der Softwareentwicklung kommerzieller Anwendungen. Er begleitet und gestaltet Softwareentwicklungsprojekte in den unterschiedlichsten Rollen, früher als Softwareentwickler, Architekt und Projektmanager, heute als Geschäftsführer eines Softwarehauses. Sein besonderer Fokus gilt der Frage, wie sich Softwareprojekte besser und zuverlässiger durchführen lassen und wie sie durch praxiserprobte Methoden eine noch höhere Qualität und einen noch größeren Nutzen liefern können.

Dr. Benjamin Poensgen ist Geschäftsführer der QuantiMetrics GmbH in Wiesbaden. Nach dem Physikstudium begann er seine berufliche Laufbahn in der Softwareentwicklung und wechselte später in das Marketing und Produktmanagement eines Softwareherstellers. Seit 1996 ist er als Unternehmensberater auf dem Gebiet der Bewertung und Verbesserung von Organisation und Prozessen der betrieblichen IT-Anwendungsentwicklung tätig. Er begleitet und unterstützt Unternehmen bei der Einführung von Kennzahlensystemen und der Durchführung von Benchmarkanalysen und bewertet als Gutachter IT-Projekte und IT-Projektangebote.

Hans-Jürgen Plewan · Benjamin Poensgen

ProduktiveSoftwareentwicklung

Bewertung und Verbesserung vonProduktivität und Qualität in der Praxis

Hans-Juergen [email protected]

Benjamin [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Birgit BäuerleinUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik:Prof. Dr. Heidi Heilmann · [email protected]

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:Buch 978-3-89864-686-4PDF 978-3-86491-058-6ePub 978-3-86491-059-3

1. Auflage 2011Copyright © 2011 dpunkt.verlag GmbHRingstraße 19 B69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

»Die einzig dauerhafte Form irdischer Glückseligkeitliegt im Bewusstsein der Produktivität.«

Carl Zuckmayer

Kaum eine andere Technologie hat die industriellen und gesellschaftlichen Produktionsprozesse so stark verändert wie die Informationstechnologie. Sie ist der Hebel für atemberaubende Steigerungen der Produktivität, und viele Produkte und Dienstleistungen, die uns heute alltäglich geworden sind, wären ohne sie gar nicht mehr vorstellbar.

Aber auch hinter der Informationstechnologie stehen Menschen, die eine kreative Leistung erbringen: die Entwickler der Software. Die Softwareentwicklung ist selbst ein produktiver Prozess, sowohl im klassisch volkswirtschaftlichen Sinne als auch in einem übertragenen Sinne: indem der Entwickler etwas Neues hervorbringt, das mehr ist als die Summe seiner Teile.

Wir, die Autoren, kennen beide die Softwareentwicklung aus eigener Erfahrung, wenn auch mit ganz unterschiedlichen Schwerpunkten. Der eine, Benjamin Poensgen, ausgebildeter Physiker, hat zunächst als Quereinsteiger vor allem systemnahe Programme entwickelt. Seit mehr als fünfzehn Jahren beschäftigt er sich insbesondere damit, wie das Ergebnis und die Produktivität von Softwareprojekten sinnvoll gemessen und bewertet werden kann. Der andere, Hans-Jürgen Plewan, ausgebildeter Informatiker, kennt den Projektalltag in der Entwicklung kommerzieller Anwendungen seit mehr als zwanzig Jahren. Er begleitet und gestaltet Softwareentwicklungsprojekte in den unterschiedlichsten Rollen, früher als Softwareentwickler, Architekt und Projektmanager, heute als Geschäftsführer eines Softwarehauses. Sein »roter Faden« ist die Frage, wie sich Softwareprojekte besser und zuverlässiger durchführen lassen und wie sie höhere Qualität und einen noch größeren Nutzen liefern können.

Als wir uns vor einigen Jahren kennenlernten, gab es zunächst die wohl in unserer Branche nicht ganz unüblichen Missverständnisse. Dem Argument »Was ist der Sinn von Verbesserungen der Produktivität und Qualität, wenn wir die Verbesserungen nicht messen können?« wurde entgegengehalten »Was ist der Sinn von Messungen, wenn wir nicht wissen, was wir unter Produktivität und Qualität verstehen, welche Verbesserungen wir erreichen wollen und wie wir diese erreichen können?«. Die Folge war eine, wie man sich leicht vorstellen kann, oft recht lebhafte Diskussion. In deren Verlauf wir zu dem Schluss kamen: Beide Argumente sind richtig! Die Messung und Bewertung von Produktivität und Qualität und ihre Verbesserung gehören zusammen wie die Henne und das Ei. Ohne Henne kein Ei, ohne Ei keine Henne.

Aber was ist ein »gutes« Projekt? Was bedeutet Produktivität und Qualität für Softwareprojekte? Das ist auch heute für die Softwareentwicklung immer noch wenig greifbar. Insbesondere gibt es darüber keinen allgemeinen Konsens. Bis heute gilt für viele Softwareprojekte: Überhaupt ins Ziel zu kommen, ist schon ein Erfolg. Aber wenn schließlich der Zielerreichungsgrad in die Nähe von 100% kommt, was bedeutet dann: »noch besser werden«? Was bringt dann zum Beispiel der Wechsel zu einem agilen Vorgehensmodell und wie kann man die damit verbundenen Verbesserungen beschreiben, greifbar und messbar machen? Oder allgemeiner: Was ist eine »produktive« Softwareentwicklung?

Wir haben aus unseren unterschiedlichen Erfahrungshintergründen heraus in den vergangenen Jahren zahlreiche Unternehmen und Projekte auf ihrem Weg zu einer produktiven Softwareentwicklung begleitet. Dabei haben sich für uns drei Merkmale herauskristallisiert, die charakteristisch für produktive Softwareentwicklungsorganisationen und Projekte sind:

Sie streben nach einer hundertprozentigen Zielerreichung ihrer Projekte in Bezug auf Kundenzufriedenheit, Leistungsumfang, Qualität, Zeit und Kosten.

Sie haben den Ehrgeiz, dabei immer besser zu werden, und den Anspruch, sich mit den Besten zu vergleichen.

Sie kennen die Produktivität und Qualität ihrer Projekte und wissen um deren Einfluss auf die hundertprozentige Zielerreichung.

Das vorliegende Buch fasst unsere Erfahrungen zusammen und soll Auftraggebern, Managern, Projektleitern, Architekten, Softwareentwicklern, letztlich allen an der Entwicklung von Software Beteiligten, Hinweise und Werkzeuge für den Weg zu einer produktiven Softwareentwicklung an die Hand geben.

Hans-Jürgen Plewan, Frankfurt undBenjamin Poensgen, Wiesbaden

Juli 2011

Inhaltsverzeichnis

1

Einleitung

Teil I

Softwareentwicklung und Produktivität

 

2

Professionalisierung als Herausforderung

2.1

Wie wird heute Software entwickelt?

 

2.1.1   Aktivitäten der Softwareentwicklung

 

2.1.2   Ergebnisse der Softwareentwicklung

 

2.1.3   Methoden der Softwareentwicklung

 

2.1.4   Die Bedeutung von CMMI und Reifegradmodellen

2.2

Professionalität auf dem Prüfstand

 

2.2.1   Was ist Professionalität?

 

2.2.2   Verbreitung methodischer Softwareentwicklung

 

2.2.3   Bescheidene Erfolgsquoten

 

2.2.4   Große Unterschiede – Top und Low Performer

 

2.2.5   Ursachen der geringen Professionalität

2.3

Übliche Wege der Professionalisierung

 

2.3.1   Proklamation von Wertesystemen

 

2.3.2   Professionalisierung durch Methoden und Prozesse

 

2.3.3   Professionalisierung als Industrialisierung

 

2.3.4   Vision des Software Engineering

3

Die Bedeutung der Produktivität für die Softwareentwicklung

3.1

Was verstehen wir unter Produktivität?

3.2

Produktivität über alles?

3.3

Produktivität und Projekterfolg

3.4

Produktivität und Qualität

3.5

Produktivität und Aufwandsschätzung

3.6

Ohne Produktivität keine Professionalisierung

Teil II

Produktivität messen und bewerten

 

4

Function Points und andere Maße für Projektergebnisse

4.1

Functional Size Measurement nach ISO 14143

4.2

Function Points

4.3

Die Functional Size typischer Projekte

4.4

Use Case Points

4.5

Story Points

4.6

Weitere Alternativen

4.7

Bei aller Kritik: Function Points sind eine gute Wahl

5

Kennzahlen für Produktivität und Qualität

5.1

Kennzahlen für die Produktivität

5.2

Kennzahlen für die Qualität

5.3

Weitere Kennzahlen

6

Praxis der Messungen

6.1

Bewertung der Functional Size

6.2

Messung von Aufwand, Kosten und Zeit

6.3

Softwarefehler

6.4

Erfahrungsdatenbanken

6.5

Statistische Auswertung von Kennzahlen

7

Produktivitätsunterschiede

7.1

Streuung von Produktivität und Qualität

7.2

Herausforderung Messgenauigkeit

7.3

Vergleichbar – aber nicht gleich

7.4

Benchmarking

Teil III

Produktivitätsfaktoren

 

8

Bad Practices – Was bremst uns?

8.1

Unscharfe Ziele und Ziellosigkeit

8.2

Unrealistische Projekte

8.3

Echte Zeitverschwendungen

8.4

Ungeeignetes oder unklares Vorgehen

8.5

Unklare und instabile Anforderungen

8.6

Schlechte Qualität und viele Nacharbeiten

8.7

Unerfahrene oder ungeeignete Projektleiter

8.8

Fehlende Skills im Team

8.9

Wenig Motivation

8.10

Chinesenprinzip

8.11

Viele 50%-Ressourcen

8.12

Zu viel Politik, zu wenig Realismus

9

Produktivitätsfaktoren der Softwareentwicklung

9.1

Produktivitätsfaktoren im Überblick

9.2

Produktivitätsfaktoren und Produktivitätshebel

9.3

Welche Produktivitätsfaktoren sind relevant?

10

Die acht elementaren Produktivitätsfaktoren

10.1

Ein einfaches Modell produktiver Prozesse

10.2

Berücksichtigung von Qualität und Rework

10.3

Berücksichtigung von Verschwendungen

10.4

Die acht Gebote der Produktivität

Teil IV

Produktiver werden

 

11

Die Macht der Ziele nutzen

11.1

Die Richtungen der Beschleunigung

11.2

Klares Projektziel voranstellen

11.3

Explizite Projektdurchführungsziele setzen

11.4

Ziel-Commitments vereinbaren

11.5

Erreichbare Zwischenziele setzen

11.6

Zug zum Ziel durch festen Steuerrhythmus

11.7

Zielorientierung auch im Kleinen einfordern

12

Produktive Hochleistungsteams aufbauen

12.1

Die Richtungen der Beschleunigung

12.2

Die richtige Teamgröße bestimmen

12.3

Teams effektiv organisieren

12.4

Den passenden Skillmix finden

12.5

Gute Projektleiter als Taktgeber finden

12.6

Individuelle Leistungsfähigkeit erkennen

12.7

Motivation erzeugen und erhalten

12.8

Ein professionelles Wertesystem aufbauen

13

Den Kern der richtigen Anforderungen treffen

13.1

Die Richtungen der Beschleunigung

13.2

Anforderungen iterativ analysieren

13.3

Aktive Benutzerbeteiligung einfordern

13.4

Prototyping statt Papiertiger

13.5

Überproduktion vermeiden

14

Vorgehen ohne effektive Methodik abstellen

14.1

Die Richtungen der Beschleunigung

14.2

Methodisch vorgehen

14.3

Best Practices sammeln

14.4

Wasserfall vermeiden

14.5

Methodendisziplin erreichen

14.6

Automatisierungen selektiv einsetzen

14.7

Wiederverwendung auf verschiedenen Ebenen nutzen

15

Qualität steigern und Rework radikal reduzieren

15.1

Die Richtungen der Beschleunigung

15.2

Qualitätsbewusstsein durch Qualitätsbegriff schaffen

15.3

Anzahl ausgelieferter Fehler reduzieren

15.4

Rework-Anteil gering halten

15.5

Qualitätssicherung einfach organisieren

15.6

Mit Projektaudits Sackgassen erkennen

15.7

Codereviews sind effektiver als Tests

15.8

Frühes iteratives Testen

16

Verschwendungen erkennen und eliminieren

16.1

Die Richtungen der Beschleunigung

16.2

Angemessenheit zum Prinzip erklären

16.3

Pragmatisch dokumentieren

16.4

Effektive Meetings durchführen

16.5

Organisatorische Verschwendungen vermeiden

16.6

Rechtzeitig Hilfe holen

17

Projekte richtig in die Umgebung integrieren

17.1

Die Richtungen der Beschleunigung

17.2

Projekt schützen

17.3

Stakeholder aktiv managen

17.4

Projekte durch Marketing stärken

17.5

Topmanagementfokus nutzen

18

Fortschritt, Qualität und Produktivität steuern

18.1

Die Richtungen der Beschleunigung

18.2

Richtige Rahmenbedingungen schaffen

18.3

Projektfortschritt kontrollieren

18.4

Qualität messen und bewerten

18.5

Produktivität messen und bewerten

19

Zusammenfassung und Ausblick

Anhang

 

 

 

Literaturverzeichnis

 

Index

1 Einleitung

Ein einheitliches Verständnis für die »Produktivität in der Softwareentwicklung« ist in der Softwareindustrie heute nicht sichtbar. Die Produktivität steht noch nicht im Zentrum der Betrachtung des Software Engineering und des Projektmanagements. Das betrifft einerseits die akademische Forschung, aber noch viel mehr die Projekt- und Entwicklungspraxis in den Unternehmen.

Aus einem allgemeinen wirtschaftlichen Verständnis abgeleitet, steht Produktivität für das Verhältnis von Ertrag zu Aufwand. Aber wie sind Aufwand und vor allem der Ertrag in der Softwareentwicklung und für Softwareprojekte sinnvoll zu definieren, sodass die daraus bestimmte Produktivität auch eine praktische Aussagekraft erhält? Ein noch größerer »weißer Fleck« tut sich auf, wenn es um die Frage geht, wie Produktivität in der Praxis der Softwareentwicklung gemessen, bewertet und verbessert werden kann.

Wir stellen Standards und den »State-of-the-Art« in der produktivitätsorientierten oder »produktiven« Softwareentwicklung dar. Mithilfe von Praxisbeispielen, empirischen Daten und konkreten Empfehlungen werden wir unsere Aussagen verdeutlichen und den Leser bei der konkreten Umsetzung unterstützen. Die Erkenntnisse und Empfehlungen beruhen auf unseren eigenen beruflichen Erfahrungen. Wir haben diese immer wieder kritisch geprüft und verglichen mit dem, was im »klassischen« Projektmanagement bereits etabliert ist. Da wir keine wissenschaftliche Arbeit, sondern ein Praxishandbuch schreiben wollten, verweisen wir dabei auf Literatur vor allem an den Stellen, die für den Leser auch zum »Weiterlesen« und für seine eigene Praxis interessant sein könnten.

Produktivität und Qualität sind im besten Sinne Ausdruck von »Peopleware«. Unser Buch richtet sich deshalb an alle Menschen in der Softwareentwicklung – Entwickler, Designer, Architekten, Projektleiter, Teamleiter, Methodenexperten, Controller, Manager. Linienmanager lernen, wie sie optimale Rahmenbedingungen schaffen können. Projektleiter erfahren, wie sie Projekte produktiv führen können. Und Projektmitarbeiter erhalten Hinweise, wie sie zu einer hohen Produktivität beitragen und von ihr profitieren können.

Drei Anmerkungen zum »Scope« dieses Buches:

Es ist ein Allgemeinplatz, dass zu einer praxisgerechten Betrachtung der Produktivität mehr als »Output« und »Input« gehört. Will man Produktivität im Umfeld des komplexen Entstehungsprozesses von Software verstehen, muss man auch Zielerreichung und Zeit sowie möglicherweise weitere Aspekte betrachten. Auch wenn wir vordringlich den Begriff »Produktivität« verwenden, werden wir diese Aspekte nicht ausblenden. Zur Produktivität kommen für uns Qualität und Geschwindigkeit als gleichberechtigte Erfolgsmerkmale hinzu. Unsere Hauptperspektive bleibt dabei aber die Produktivität.

Weiterhin beschränken wir uns auf die Entwicklung von Software beziehungsweise auf Softwareprojekte. Wir sind uns bewusst, dass für die Beurteilung der Wirtschaftlichkeit eines Softwareprodukts letztlich auch dessen Pflege und Wartung betrachtet werden muss. Vieles, was wir zur Messung der Produktivität sagen werden, lässt sich auch darauf übertragen. Andererseits: Wenn es darum geht, wie eine hohe Produktivität erreicht werden kann, sind die erheblichen Unterschiede zwischen Softwareentwicklung und Softwarewartung – einerseits in Projektform, andererseits häufig als Organisationseinheit – zu berücksichtigen. Wir sind der Meinung, dass das Thema Produktivität in der Softwarewartung durchaus eine eigene umfassende Arbeit rechtfertigt, und haben diesen Aspekt deshalb in unserem Buch ausgeklammert.

Zum Dritten schließlich: Beide Autoren haben ihren beruflichen Erfahrungshintergrund primär in der Entwicklung betrieblicher Informationssysteme. Ob unsere Aussagen auch für die Entwicklung technischer Informationssysteme interessant und anwendbar sind, können Praktiker aus diesen Bereichen sicher sinnvoller beurteilen. Wir, die Autoren, hoffen es und freuen uns über Rückmeldungen.

Zur Gliederung

Wir haben unser Buch in vier Hauptteile gegliedert:

In Teil I: Softwareentwicklung und Produktivität fassen wir zunächst den aktuellen Stand der Softwareentwicklung unter dem Aspekt der Professionalisierung zusammen. Hier geht es uns vor allem darum, ein gemeinsames Verständnis dafür zu schaffen, wie heute Software (im Umfeld betrieblicher Informationssysteme) entwickelt wird und welche Herausforderungen es für eine weitere Professionalisierung der Softwareentwicklung gibt. Dazu gehört auch die Frage, welche Bedeutung die Produktivität für die Softwareentwicklung hat und wie Professionalisierung und Produktivität zusammenhängen.

In Teil II: Produktivität messen und bewerten behandeln wir die praktische, konkrete Einführung und Durchführung von Messungen für wichtige Kennzahlen zur Produktivität und Qualität in Softwareprojekten. Welche Kennzahlen sind wirklich sinnvoll? Wie werden sie gemessen? Und welche Voraussetzungen sind dafür zu schaffen? Und schließlich: Wie sind die Ergebnisse auszuwerten und zu interpretieren?

In Teil III: Produktivitätsfaktoren gehen wir der Frage nach, welche Faktoren eigentlich Produktivität im negativen und im positiven Sinne beeinflussen. Die Vielfalt möglicher Einflussfaktoren auf die Produktivität von Softwareprojekten ist legendär und erschlagend. Wir stellen deshalb ein einfaches Modell für Produktivitätsfaktoren vor und beschreiben damit die in der Praxis entscheidenden acht Produktivitätsfaktoren. Daraus resultieren die acht Gebote produktiver Softwareentwicklung.

In Teil IV: Produktiver werden beschreiben wir für die acht Produktivitätsfaktoren, welche Maßnahmen konkret in der Organisation und in den Projekten zu entscheidenden Verbesserungen führen. Jedem der acht Gebote produktiver Softwareentwicklung ist dabei ein eigenes Kapitel gewidmet. Wir zeigen die Richtungen der Beschleunigung auf und verdeutlichen, durch welche konkreten produktiven Praktiken diese erreicht werden können.

Teil I

Softwareentwicklung und Produktivität

2 Professionalisierung als Herausforderung

»Programmierung ist immer noch Flickwerk.Es wird nur angeflanscht, erweitert, modifiziertund am Ende werden Bugs quick-and-dirty beseitigt.«

Charles Symoni1

Die Disziplin der Softwareentwicklung ist mittlerweile über 40 Jahre alt. Dabei ist die Softwareindustrie gerade in den letzten 20 Jahren noch einmal stark gewachsen. Software spielt eine zentrale Rolle im täglichen Leben. Die Anzahl, die Größe und auch die Komplexität von Softwareanwendungen und ganzen Anwendungslandschaften sind dabei dramatisch gestiegen. Billionen von Dollars und Euro werden weltweit jährlich in die Softwareentwicklung investiert.

Das geht einher mit gewaltigen Kraftanstrengungen, Software »einfacher«, »besser« und »professioneller« zu entwickeln. Um das zu erreichen, gibt es gerade in den letzten 20 Jahren im Vergleich zu den Dekaden davor eine Flut neuer Methoden, Vorgehensweisen und Konzepten. Die Webseite www.amazon.de listet auf das Schlagwort »Softwareentwicklung« über 4.800 Bücher auf (Stand 01/2011). Dem Außenstehenden, aber auch dem Interessierten fällt es immer schwerer, sich in diesem Dschungel zu orientieren und die richtigen Entscheidungen für die eigenen Projekte zu treffen. Schließlich hat jeder den Anspruch, seine Software »gut« und »professionell« zu entwickeln.

Auf der anderen Seite stellt sich die Frage, wie heute in der Praxis wirklich Software entwickelt wird. Haben sich bestimmte Methoden durchgesetzt? Gibt es allgemeingültige Trends? Wo steht die Softwareentwicklung heute eigentlich? Trotz aller iterativen Konzepte, prototypischen Ansätze oder agilen Maximen geht es im Kern immer noch um die gleichen Aktivitäten und Aufgaben wie schon vor 20 Jahren.

Und: Ist die Softwareentwicklung wirklich professioneller und besser geworden? Haben die zahlreichen neuen Paradigmen und Methoden zu »besseren« Projekten, besseren Ergebnissen und besserer Software geführt? Können wir heute von der Softwareentwicklung in der Breite als professionelle »Industrie« sprechen? Wenn nicht, woran liegt das? Was sind dann die Voraussetzungen für eine Professionalisierung der Softwareentwicklung?

In den folgenden Abschnitten versuchen wir, diese wichtigen Fragen zu beantworten. Wir wollen damit eine erste Orientierung über den Status quo der Softwareentwicklung geben. Wir wollen damit aber auch eine Grundlage für unser Kernthema der Produktivität schaffen. Für uns ist die Achse »Professionalität« und »Produktivität« eine zentrale Motivation des gesamten Buches. Eine professionelle Softwareentwicklung ist immer auch eine produktive Softwareentwicklung.

2.1 Wie wird heute Software entwickelt?

Zu den Grundlagen, Techniken und Methoden der Softwareentwicklung gibt es zahlreiche umfassende Arbeiten. Für einen umfänglichen Überblick über alle Bereiche der Softwareentwicklung verweisen wir den Leser auf den Klassiker von Ian Sommerville über Software Engineering [Sommerville 07] und das Buch von Jochen Ludewig und Horst Lichter [Ludewig & Lichter 10].

Die häufigste Organisationsform für Softwareentwicklung ist dabei heute das Projekt. Das ist unabhängig davon, ob ein Dienstleister für einen Kunden oder ob eine Entwicklungseinheit innerhalb eines Unternehmens Software entwickelt. Meist gilt das sogar für die Produktentwicklung, indem jede neue Version eines Softwareprodukts in Form eines Projekts durchgeführt wird. In diesem Sinne benutzen wir die Begriffe »Softwareentwicklung« und »Softwareentwicklungsprojekt« in der Regel als Synonyme.

Als Grundlage für das Thema unseres Buches wollen wir hier die folgenden Aspekte der Softwareentwicklung herausstellen und in ihrem Kern beschreiben:

Aktivitäten

Ergebnisse

Methoden

Reifegradmodelle

2.1.1 Aktivitäten der Softwareentwicklung

Abbildung 2–1 zeigt ein allgemeines Ablaufmodell für die Durchführung von Softwareentwicklungsprojekten. In jedem Entwicklungsprojekt sind fünf Basisaktivitäten durchzuführen:

Anforderungsanalyse

Design

Implementierung

Test

Auslieferung

Die Basisaktivitäten werden in der Regel sequenziell durchlaufen. Aber auch eine teilweise Überlappung oder Parallelität ist möglich (zum Beispiel paralleles Implementieren und Testen). In einem Softwareentwicklungsprojekt können die Basisaktivitäten einmal oder mehrmals iterativ durchgeführt werden.

Abb. 2–1 Die wichtigsten Aktivitäten der Softwareentwicklung

Jede Basisaktivität produziert ein oder mehrere Ergebnisse. Wir sprechen von den »Ergebnistypen« einer Aktivität. Die Aktivität »Auslieferung« hat dabei die Besonderheit, unabhängig von der Anzahl der Iterationen der vorangehenden Aktivitäten entweder genau einmal oder ebenso mehrmals ausgeführt zu werden. Das hängt davon ab, ob die entwickelte Anwendung in mehreren sukzessiven Teilen (Inkrementen) ausgeliefert wird und in Produktion geht oder in einer einzigen Auslieferung.

Der konkrete Softwareentwicklungsprozess ergibt sich dann aus der sequenziellen oder parallelen Ausführung dieser Aktivitäten. Daher lässt sich der Kern jedes Entwicklungsprozesses wie folgt beschreiben [IEEE 90]: »Ein Softwareentwicklungsprozess ist ein Prozess, der Nutzeranforderungen in ein Softwareprodukt umsetzt. Der Prozess beinhaltet dabei die Übersetzung von Nutzeranforderungen in Softwareanforderungen, die Überführung der Softwareanforderungen in ein Design, die Implementierung des Designs in Code, das Testen des Codes und die Installation der Software für den praktischen operativen Einsatz.«

Daneben sind für die Softwareentwicklung drei zentrale Querschnittsaktivitäten herauszuheben, die primär steuernden Charakter haben:

Projektmanagement

Qualitätsmanagement

Änderungs- und Konfigurationsmanagement

Auf der Grundlage dieser fünf Basisaktivitäten und drei Querschnittsaktivitäten kann man fast jedes individuelle Vorgehen, aber auch die meisten standardisierten Vorgehensmodelle (zum Beispiel V-Modell XT [Höhn & Höppner 09], Rational Unified Process (RUP) [Essigkrug & Mey 07], Scrum [Schwaber 04], Extreme Programming (XP) [Beck 00]) beschreiben. Die Terminologien für die verschiedenen Aktivitäten variieren natürlich in den Vorgehensmodellen und Entwicklungsmethoden. Insbesondere unterscheiden sich die konkreten Ausgestaltungen dieser Aktivitäten und ihre Ausführungsreihenfolge.

2.1.2 Ergebnisse der Softwareentwicklung

Softwareentwicklung ist ein produktiver Prozess, an dessen Ende ein nutzbares »Produkt« steht. Das Produkt und zentrale Ergebnis jeder Softwareentwicklung ist eine ausführbare Anwendung, die den Nutzer dieser Anwendung einen bestimmten Mehrwert liefert (Komfort, Zeit, Kosten). Im Laufe eines Projekts werden zusätzlich Dokumente und Zwischenergebnisse produziert, die für den Entstehungsprozess hilfreich waren, die aber kein Teil des Endergebnisses sind (siehe Tab. 2–1). Bei den Ergebnissen der Softwareentwicklung unterscheiden wir daher zwei Arten:

Endergebnisse oder Liefereinheiten, die mit der Auslieferung »geliefert« werden und die für den täglichen Betrieb und den Nutzen der entwickelten Anwendung notwendig sind,

Zwischenergebnisse, die im Projektverlauf entstanden sind, aber nicht ausgeliefert werden und für den Betrieb und Nutzen der Anwendung nicht unbedingt notwendig sind.

Basisaktivität

Typische Ergebnistypen

Anforderungsanalyse

Anforderungsliste Anforderungsspezifikation User Stories Use Cases UML-Modell GUI-Prototyp Fachkonzept

Design

Architekturdokument Verfeinertes UML-Modell DV-Konzept Technischer Prototyp

Implementierung

Code Systemdokumentation Benutzerhandbuch

Test

Testkonzept Testplan Testfälle Testprotokolle Fehlerberichte Abnahmeprotokoll

Auslieferung

Installierte Anwendung

Tab. 2–1 Typische Ergebnisse der verschiedenen Basisaktivitäten

Typische Endergebnisse und Liefereinheiten eines Entwicklungsprojekts sind:

Ausführbare Anwendung (Code)

Benutzerhandbuch

Systemdokumentation

Release Notes

Kann ein mit der Unified Modeling Language (UML) formuliertes Modell auch Liefereinheit und damit Ergebnis eines Projekts sein? Natürlich, wenn das zwischen dem Entwicklungsprojekt und dem Auftraggeber des Projekts so vereinbart ist, dann kann auch das UML-Design eine Liefereinheit und damit ein definiertes Endergebnis der Softwareentwicklung sein. Will ein Kunde etwa die Software, die ein Dienstleister für ihn entwickelt hat, selbst weiterentwickeln und warten, dann können solche Ergebnisse auch für den Kunden relevant sein. Entscheidend ist in diesem Sinne, welche Liefereinheiten mit dem Projektauftrag vereinbart sind. Diese Vereinbarung bestimmt, welche Endergebnisse ein Entwicklungsprojekt neben dem eigentlichen Code produziert und liefert.

2.1.3 Methoden der Softwareentwicklung

Begriffe wie »Vorgehensmodell«, »Entwicklungsmethode« oder »Vorgehensweise« werden für die Softwareentwicklung oft in einer ähnlichen Bedeutung verwendet. Dabei meint der Begriff des Vorgehensmodells ein umfassendes Ablaufmodell für den gesamten Entwicklungsprozess und dessen Aktivitäten (zum Beispiel Rational Unified Process, RUP). Allen Vorgehensmodellen ist gemeinsam, dass sie den Ablauf des Entwicklungsprozesses systematisch regeln und damit helfen, die Komplexität von Softwareentwicklungsprojekten zu beherrschen. Dabei werden vor allem die folgenden Vorgaben gemacht (siehe Abb. 2–2):

Durchzuführende Aktivitäten und deren Reihenfolge

Zu erstellende Ergebnisse und Teilergebnisse

Verwendete Methoden und Werkzeuge

Verantwortlichkeiten und Kompetenzen (Projektrollen)

Abb. 2–2 Zusammenhang Vorgehensmodell, Methode und Entwicklungsaktivität

Der Begriff der Entwicklungsmethode betont dagegen mehr das Spezifische eines kleineren Schrittes oder einer einzelnen konkreten »Vorgehensweise« innerhalb einer Entwicklungsaktivität (zum Beispiel Use Cases zur Anforderungsanalyse, Aufwandsschätzung auf der Basis von Function Points). Dabei ist der Übergang von einzelnen Methoden und Sammlungen von Methoden zu Vorgehensmodellen fließend. So sind Vorgehensweisen wie Extreme Programming [Beck 00] oder Scrum [Schwaber 04] eher Methoden oder besser Sammlungen von Methoden als umfassende Vorgehensmodelle.

Bezüglich ihrer Philosophie unterscheidet man heute grob vier Kategorien von Vorgehensmodellen bzw. Entwicklungsmethoden (siehe auch [Fritzsche & Keil 07]):

Wasserfallmodell

Inkrementelle Entwicklung

Iterative Entwicklung

Agile Entwicklung

Im Kern unterscheiden sich die Entwicklungsphilosophien im Konzept der Iterationen, deren Anzahl, deren Längen und deren Ablauf (siehe Tab. 2–2). Dabei gibt es in der Praxis immer häufiger auch Mischformen. Das klassische Wasserfallmodell zum Beispiel tritt in Reinform kaum mehr auf.

Etwas vereinfacht kann man feststellen, dass heute vor allem zwei Typen von Vorgehensweisen dominieren, je nachdem, ob eher ein sequenzieller »langer« Wasserfall mit oder ohne Inkrementen oder eher das Konzept der kurzen Iterationen und der Agilität das Fundament für das Vorgehen bilden. Meist spricht man dann von »klassischen« oder »traditionellen« Vorgehensweisen gegenüber »iterativen« oder »agilen« Vorgehensweisen. Dabei waren die beiden Lager der Vertreter von agilen und von traditionellen Methoden vor ein paar Jahren noch im starken Wettstreit. Wie alles Neue brauchten auch die agilen Methoden ihre Zeit, um zum Mainstream zu werden und von (fast) allen akzeptiert zu werden. Heute haben sich die Schulen von agilen und traditionellen Methoden zum Teil bereits stark angenähert, sodass der Übergang zwischen den verschiedenen Entwicklungsphilosophien zunehmend fließend wird.

Agile und iterative Vorgehensweisen sind vor allem in dynamischen Projekten und Projektumfeldern gefragt. Das sind Projekte, in denen die Anforderungen nicht sehr stabil sind und während der Entwicklung mit vielen neuen und geänderten Anforderungen zu rechnen ist. Inwieweit das ohnehin eines der latenten Risiken in jedem Entwicklungsprojekt ist, sei hier dahingestellt. Agile Vorgehensweisen setzen Flexibilität in Bezug auf Änderungen (Anforderungen, Leistungsumfang, Projektziel) und damit das sogenannte Moving Target in das Zentrum ihrer Entwicklungsrhythmen.

Agilität ist dabei aber nicht nur eine Methode, Software zu entwickeln, sondern auch eine »Haltung«, verbunden mit einer bestimmten Projektkultur, die sich am agilen Manifest2 orientiert. Werte wie Kundennutzen, Qualität und Teamgeist werden explizit in den Vordergrund gerückt. In eine ähnliche Richtung gehen Methoden, die sich dem sogenannten »Lean Management« [Poppendieck et al. 10] verschreiben.

Vorgehensmodell

Anzahl Iterationen

Typische Länge einer Iteration

AnzahlAnforderungsanalysen

Anzahl Auslieferungen

Wasserfall

1

1–3 Jahre

1

1

Inkrementell

n

3–6 Monate

n

n

Iterativ

nn

Mehrere Wochen

nn

1 bis nn

Agil

nnn

1–4 Wochen

nnn

1 bis nnn

Tab. 2–2 Klassifikation verschiedener Vorgehensweisen

Traditionelle Vorgehensweisen nach dem Wasserfallmodell und auch inkrementelle Ansätze setzen eine gewisse Stabilität bei der Planbarkeit und bei den Anforderungen voraus. Aus dieser Perspektive sind traditionelle Methoden eher gefragt für Entwicklungsprojekte in stabilen, wohlverstandenen Umfeldern (technisch und fachlich), wo man aus Erfahrung weiß, dass sich die Anforderungen nur geringfügig ändern und Architektur und Technik bereits mehrfach erfolgreich eingesetzt wurden. Beispiel ist die Weiterentwicklung einer bestehenden Anwendung, die bereits erfolgreich in Betrieb ist.

2.1.4 Die Bedeutung von CMMI und Reifegradmodellen

Zusätzlich zu konkreten Entwicklungsmethoden und umfassenden Vorgehensmodellen haben sich für die Softwareentwicklung sogenannte Reifegradmodelle etabliert. Die Grundidee von Reifegradmodellen ist es dabei, ein Rahmenwerk zur Verfügung zu stellen, an dem sich Unternehmen bei der Gestaltung der eigenen (Softwareentwicklungs-)Prozesse orientieren können. Das Rahmenwerk gibt dann im Wesentlichen Anforderungen an die Prozesse vor. Die konkrete Umsetzung mit konkreten Methoden wird vom Reifegradmodell nicht vorgegeben. Das ist der Unterschied zu den oben beschriebenen Vorgehensmodellen und Entwicklungsmethoden.

Reifegradmodelle haben dabei primär die Qualität von Prozessen und deren Verbesserung im Fokus. Damit unterscheiden diese Modelle »reife« von »unreifen« Organisationen. Der Reifegrad ist dann ein Indikator für die Zuverlässigkeit einer Organisation, ihre Entwicklungsprojekte immer wieder, also wiederholbar, erfolgreich durchführen zu können. Reifegradmodelle sind häufig mit einer Zertifizierung verknüpft. Wichtige Reifegradmodelle sind u.a.:

CMMI

ISO 9000/9001

ITIL

SPICE

Dabei ist das international bekannteste Reifegradmodell das Capability Maturity Model Integration (CMMI) des Software Engineering Institute (SEI) der Carnegie Mellon University [Chrissis, Konrad & Shrum 07]. CMMI ist nach unserer Einschätzung auch das im Umfeld betrieblicher Informationssysteme mit Abstand am weitesten verbreitete Reifegradmodell. Im CMMI sind dabei verschiedene Vorgängermodelle (CMM) integriert. CMMI kennt fünf Reifegrade einer Organisation, Softwareentwicklungsprojekte durchzuführen (siehe Tab. 2–3). Die Reifegrade unterscheiden sich im Grad der Kontrolle und Zuverlässigkeit der Entwicklungsprozesse und -projekte.

Tab. 2–3 Die fünf Stufen des CMMI-Reifegradmodells

Stufe 1 beschreibt eine »Ad hoc«-Softwareorganisation, die keine oder sehr wenige Prozesse definiert hat. Es gibt keine Vorgaben zur Planung und Steuerung von Projekten. Organisationen, die Stufe 2 erreichen, haben zumindest grundlegende Prozesse und Methoden für ein kontrolliertes Projektmanagement. Tabelle 2–4 zeigt die sieben Prozesse, die für CMMI-Stufe 2 gefordert sind.

Requirements Management

REQM

Anforderungsmanagement

Project Planning

PP

Projektplanung

Project Monitoring and Controlling

PMC

Projektsteuerung

Supplier Agreement Management

SAM

Management von Zulieferungen

Measurement and Analysis

MA

Messung und Analyse

Process and Product QA

PPQA

Qualitätssicherung

Configuration Management

CM

Konfigurationsmanagement

Tab. 2–4 Exemplarische Übersicht aller Prozesse der CMMI-Stufe 2

Auf Stufe 3 ist ein organisationsweit gültiger Softwareentwicklungsprozess definiert und eingeführt, inklusive Projektmanagement und Qualitätssicherung. Dieser Prozess ist auch etabliert und funktioniert in allen Projekten.

Auf CMMI-Stufe 4 werden die Qualität der (Zwischen-)Ergebnisse und die Produktivität der Prozesse quantitativ gemessen. Metriken und Kennzahlen unterstützen die Projektsteuerung. Organisationen auf Stufe 5 haben darüber hinaus Methoden und Wege zur ständigen Prozessverbesserung etabliert.

Ein weitverbreiteter Irrtum liegt in der Ansicht, die Anwendung von CMMI führe notwendigerweise zu schwergewichtigen und teureren Prozessen, CMMI sei zu komplex und propagiere einen Wasserfallprozess. Es gibt inzwischen viele Beispiele, in denen konkrete agile Verfahren wie Scrum oder XP mit Erfolg auf eine bestimmte CMMI-Stufe abgebildet wurden [Glazer et al. 08]. CMMI ist eben nur ein Framework, das auch für agile Vorgehensweisen funktionieren kann.

Während CMMI vor allem in Nordamerika, Asien und auch Europa verbreitet ist, wird das Reifegradmodell ISO 9000/9001 vor allem in Europa eingesetzt. Es hat seinen Ursprung in der Fertigungsindustrie und ist im Vergleich zu CMMI viel allgemeiner formuliert. Im Kern ist es ein Regelwerk zur Qualitätssicherung innerhalb einer Organisation. ISO 9001 kennt nur zwei Stufen, d.h., ein Unternehmen erfüllt die Anforderungen oder es erfüllt sie nicht.

Während CMMI ein Rahmenwerk für die Entwicklung von Softwaresystemen ist, ist ITIL (Information Technology Infrastructure Library) ein Rahmenwerk für die Wartung und den Betrieb von Softwaresystemen. ITIL ist im Wesentlichen eine Sammlung von bewährten Verfahren aus dem IT-Servicemanagement.

Betrachtet man die verschiedenen Reifegradmodelle, angeführt von CMMI, stellt sich die Frage, inwieweit diese Modelle in der Praxis auch Nutzen stiften. Nutzen stiften in dem Sinne, dass Projekte von »reifen« Organisationen mit besserer Qualität, geringeren Kosten und höherer Produktivität durchgeführt werden. Dafür gibt es tatsächlich empirische Indizien, die wir in Teil IV aufgreifen werden.

2.2 Professionalität auf dem Prüfstand

»Wir alle arbeiten geschäftig an der nächsten Softwareversion. Doch wirklich professionell im obigen Sinne tun es die wenigsten.«

Ralf Westphal3

Dass die Softwareentwicklung eine professionelle Disziplin ist in dem Sinne, dass damit viel Geld verdient wird, steht außer Frage. Aber ist sie auch eine professionelle Disziplin im Sinne einer »fachmännischen«, »kompetenten« und »qualifizierten« Branche? Seit ihren Anfängen vor über 40 Jahren steht die Professionalität der Softwareentwicklung stetig auf dem Prüfstand. Leider wird es in der kommerziellen Praxis immer wieder bestätigt, dass Projekte »chaotisch«, »unprofessionell, »mit schlechter Qualität« oder einem unbefriedigenden Ergebnis durchgeführt werden. Jeder Projektleiter, Softwareentwickler oder IT-Manager kennt heute aus seinem Umfeld Projekte, die »nicht gut« laufen oder sogar abgebrochen werden. Sind das Einzelfälle oder gibt das die Realität in der Breite wieder?

Wir wollen dazu zunächst klären, was unter »Professionalität« zu verstehen ist. Dann wollen wir prüfen, wie verbreitet eine »methodische« Softwareentwicklung in der Praxis ist und wie es um die Erfolgsquoten von Softwareprojekten steht. Schließlich stellen wir uns die Frage, wo die noch geringe Professionalität der Softwareentwicklung eigentlich herrührt.

2.2.1 Was ist Professionalität?

Professionalität ist einer der allgemeinen Begriffe, für die man von zehn verschiedenen Personen elf verschiedene Beschreibungen erhält. Eine Klärung des Begriffs ist wichtig, gerade auch um den Standort der Softwareindustrie zu bestimmen. Dabei gibt es neben dem klaren Kriterium des »Geldverdienens« zahlreiche Merkmale einer professionellen Disziplin, die gerade auch für die Softwareentwicklung intensiv diskutiert werden (beispielsweise in [Westphal 09]).

Aus unserer Sicht gibt es vier wesentliche Merkmale für eine professionelle Disziplin:

1. Eindeutiger Konsens von Methoden und Praktiken, mit denen gearbeitet wird (body of knowledge).

2. Hohe Zuverlässigkeit und Qualität in den erreichten Ergebnissen.

3. Anerkanntes Wertesystem von Prinzipien und Regeln, die das tägliche Handeln leiten (code of ethics).

4. Festgelegter Ausbildungsweg für die Vertreter einer professionellen Disziplin. Existenz klarer und anerkannter Anforderungen, was ein Profi »können« muss und »gelernt« hat.

Blickt man auf klassische professionelle Disziplinen wie Medizin oder Architektur, liegt die Bedeutung dieser vier Kriterien auf der Hand. Es ist eine anerkannte Praxis eines Zahnmediziners mit einem elektrischen Bohrer zu arbeiten. Das führt zu einer Zuverlässigkeit, die nahe 100% liegt. Und: Kein Zahnmediziner würde mit einem stumpfen Bohrer arbeiten und damit den Erfolg seiner Operation riskieren (Wertesystem). Professioneller Zahnmediziner kann in unserer Gesellschaft nur werden, wer eine festgelegte und anerkannte Ausbildung durchläuft. Versucht er ohne diese Ausbildung als Mediziner zu arbeiten, gilt er als Hochstapler oder Scharlatan.

Aber wie ist das in der Softwareentwicklung? In den folgenden beiden Abschnitten wollen wir das für die ersten beiden Kriterien, den Konsens von Methoden und die Zuverlässigkeit der Ergebnisse, beantworten. Auf die Themen Wertesystem und Ausbildungsweg werden wir in Abschnitt 2.3 eingehen.

2.2.2 Verbreitung methodischer Softwareentwicklung

Spannend ist die Frage, wie verbreitet die verschiedenen Entwicklungsmethoden und Vorgehensmodelle in der kommerziellen Praxis sind. Wer entwickelt nach einer etablierten Methode? Wer hat seine Methoden und Prozesse selbst definiert? Wer entwickelt seine Software noch »unmethodisch«, also ohne Vorgaben und festgelegte Methoden? Gibt es für die Softwareentwicklung einen Konsens von Methoden und Praktiken?

Die Beantwortung dieser Fragen ist zugegebenermaßen schwierig. Vielleicht ist das sogar eines der Rätsel der heutigen Softwareindustrie und der kommerziellen Entwicklungspraxis überhaupt, wer wirklich nach einer praxiserprobten Methode vorgeht. Die Schwierigkeit ist, wie man eine entsprechende Statistik aufstellen kann, ohne dem Marketing und der Selbstdarstellung einzelner Unternehmen und Softwareentwicklungseinheiten auf den Leim zu gehen.

Die Statistiken, die es zu dieser Frage gibt, sind allesamt Umfragen an IT-Fach- und Führungskräfte. Oft mit der Möglichkeit von Mehrfachantworten, also der Angabe von mehreren Entwicklungsmethoden. Man stelle sich einen Entwicklungsleiter oder Projektleiter vor, dem in einer Umfrage die Frage gestellt wird, mit welcher Methodik in seinem Verantwortungsbereich Software entwickelt wird. Im Zweifel kreuzt er irgendeine bekannte Methode an, die seinem Vorgehen am nächsten kommt. Wer gibt schon gerne zu, dass die Vorgehensweise im Unternehmen oder Projekt nicht oder nur unzureichend etabliert ist.

Daher sind die Ergebnisse solcher Umfragen immer mit Vorsicht zu genießen. Zum Teil sind die Ergebnisse verschiedener Umfragen deutlich voneinander abweichend, sodass eine Tendenz nur schwer erkennbar ist. Beispielhaft seien hier zwei Studien genannt. Nach einer Umfrage des Software Quality Labs in 2008 [Hochrainer 08] mit der Möglichkeit von Mehrfachantworten haben 50% der befragten Unternehmen nach dem V-Modell4 (Wasserfallmodell mit inkrementellen Elementen) gearbeitet. 25% nutzten eine eigene agile Methode, 25% ein prototypisches Vorgehen, 13% ein reines Wasserfallmodell, 13% die agile Methode Scrum, 13% das iterative V-Modell XT, 13% ein selbst entwickeltes Vorgehensmodell, 6% den RUP, 6% XP, 6% Feature Driven Development (FDD), 6% eine andere agile Methode und 6% keine Methode.

In einer Forrester-Studie aus dem Jahr 2010 [Forrester 10] mit einer Umfrage unter 1.300 IT-Professionals sieht das etwas anders aus. Danach nutzen 35% eine agile Methode wie Scrum, XP oder FDD. 21% verwenden eine iterative Vorgehensweise wie RUP oder das Spiralmodell, während 13% nach einem Wasserfallprozess vorgehen. Nach dieser Studie haben 31% der Unternehmen keine definierte Vorgehensweise.

Vergleicht man die beiden Studien, ergibt sich kein einheitliches Bild. 6% versus 31% als Anteil der Unternehmen, die keine Methodik nutzen, und über 50% versus 13% bei der Nutzung eines Wasserfallmodells (wenn man das V-Modell im Kern als Wasserfallmodell versteht). Beide Studien zeigen bei den agilen Methoden eine ähnliche Tendenz. Agile Methoden sind in der Praxis auf dem Vormarsch und unter den agilen Methoden hat Scrum heute sicherlich die größte Verbreitung. Allerdings bezweifeln wir, dass das erhobene Ergebnis mit einem Anteil von ca. 35% agiler Methoden in der Softwarebranche heute wirklich repräsentativ ist. Die Frage ist auch, welcher »Methodenmix« schon als agil oder noch als klassisch angesehen wird.

Interessant ist dabei auch eine ältere Studie des Bundesministeriums für Bildung und Forschung aus dem Jahr 2000, die vom Fraunhofer-Institut zusammen mit der Technischen Universität München durchgeführt wurde. Danach entwickeln bis zu 50% aller Unternehmen ihre Software ohne vorgegebene Methodik [BMBF 00]. Zu einem ähnlichen Ergebnis kommt die Studie SUCCESS aus dem Jahre 2006 [Buschermöhle, Eekhoff & Josko 06]. Von den 378 teilnehmenden Unternehmen gingen in ihren Projekten knapp 40% ohne Methodik vor. Von denen, die methodisch entwickeln, verwenden danach knapp die Hälfte ein eigenes Vorgehensmodell.

Wie schätzen wir, die Autoren, die praktische Verbreitung der verschiedenen Vorgehensweisen in den Unternehmen und den Entwicklungseinheiten ein? Nach über 20 Jahren Erfahrung in Hunderten von Kundenprojekten wagen wir die in Tabelle 2–5 zusammengefasste grobe Einschätzung für die Praxis in der deutschen Softwareindustrie.

Methode

Verbreitung

Beschreibung

Ohne

30%–50%

Unternehmen ohne festgelegte Vorgehensweise oder mit einer rein formalen Methode, die in den Projekten nicht eingesetzt wird.

Rudimentär

20%–30%

Unternehmen mit einer lediglich sehr rudimentären Vorgehensweise, die nur wenige Aktivitäten abdeckt.

Wasserfallorientiert (klassisch)

10%–20%

Unternehmen mit funktionierender, umfassender Methodik, basierend auf dem Wasserfallmodell, das ggf. durch inkrementelle und iterative Elemente angereichert ist.

Agil/iterativ

5%–10%

Unternehmen mit einer funktionierenden, umfassenden Methodik, basierend auf einem stark iterativen oder auf einem agilen Vorgehensmodell.

Tab. 2–5 Geschätzte Verbreitung der Entwicklungsmethoden in der Praxis

Dabei unterscheiden wir in der ersten Gruppe nicht, ob ein Unternehmen gar keine Methodik für die Softwareentwicklung festgelegt hat oder die Vorgehensweise zwar formal definiert ist, in der Projektpraxis aber nicht genutzt wird. Wir sprechen dann gerne von »Schrankware«, die als mächtige Beschreibung auf einem Laufwerk liegt, die aber keiner nutzt oder kennt. In diesem Sinne ist es nicht nur wichtig, was auf dem Vorgehen einer Entwicklungseinheit »drauf steht«, sondern auch ob es in der Projektpraxis tatsächlich eingesetzt wird und funktioniert.

Häufig begegnet uns in der Praxis auch die Situation, dass die Entwicklungseinheit lediglich eine sehr rudimentäre Vorgehensweise festgelegt hat und nutzt, die aber zentrale Basisaktivitäten ausspart. Typisch ist der Fall bei einem Kunden, der signalisierte, dass er jetzt agil vorgehe. Auf die Frage nach der konkreten Vorgehensweise, war die Antwort: »Wir setzen jetzt Scrum ein, das heißt, wir machen jetzt jeden Morgen ein Standup-Meeting.« Mehr nicht. Wenn ein solches Vorgehen dann unter der Überschrift »agil« läuft und in Statistiken als agile Vorgehensweise auftaucht, ist das natürlich irreführend und falsch.

Wir haben auch die Erfahrung gemacht, dass viele Unternehmen mit einem eher rudimentären Vorgehensmodell relativ gute Vorgaben und Methoden im Bereich Test haben, aber die Aktivitäten für Anforderungsanalyse oder Design offenlassen. Oft findet man in Unternehmen auch die Situation, dass Methoden und Vorgaben für die reine Implementierung etabliert sind, Methoden für das Projektmanagement wie zum Beispiel Schätzmethoden aber überhaupt nicht vorgegeben sind. Wir gehen heute davon aus, dass maximal 20%–25% der Unternehmen eine einigermaßen funktionierende und in der eigenen Projektpraxis genutzte Vorgehensweise festgelegt haben, die alle wichtigen Aktivitäten der Softwareentwicklung abdeckt.

Schwierig ist auch die Frage zu beantworten, wie verbreitet CMMI und andere Reifegradmodelle in der kommerziellen Praxis sind. Dazu fehlt wie schon bei den Entwicklungsmethoden ausführliches Zahlenmaterial. Allerdings gibt es einige wenige Studien, die zumindest aufzeigen, in welche Richtung es geht. Die bereits zitierte Forrester-Studie aus dem Jahr 2010 [Forrester 10] mit einer Umfrage unter 1.300 IT-Professionals ergab einen Anteil von ca. 5% der Softwareunternehmen, die nach CMMI oder ISO 9000/9001 zertifiziert sind. Die Softwarestudie 2000 unter 600 österreichischen Softwareunternehmen [Janko, Bernroider & Ebner 00] ergab einen Anteil von 2,0%, die nach ISO 9001 zertifiziert waren und 0,7% nach CMMI (CMM). Diese Tendenz können wir auch aus unserer Praxiserfahrung bestätigen. Wir gehen heute davon aus, dass im deutschsprachigen Raum weniger als 5% der Softwareunternehmen nach CMMI oder ISO 9000/9001 zertifiziert sind. Was nicht heißt, das ein etwas größerer Anteil zwar keine Zertifizierung anstrebt, sich aber trotzdem an einem Reifegradmodell wie CMMI orientiert.

Die Erkenntnis bleibt trotzdem: Es wird heute mehr Wirbel um »moderne« Entwicklungsmethoden und Reifegradmodelle gemacht, als sie in der kommerziellen Softwareentwicklung wirklich systematisch eingesetzt werden. Die Softwareindustrie ist heute in der Breite noch weit entfernt von allgemein anerkannten und etablierten Methoden und Praktiken. Ein Konsens im Sinne eines body of knowledge fehlt.

2.2.3 Bescheidene Erfolgsquoten

Regelmäßig kommen empirische Studien zu dem Ergebnis, dass Softwareentwicklungsprojekte wenig zuverlässig, wenig termintreu und wenig qualitativ sind. Bekannt ist vor allem der CHAOS-Report der Standish Group [Standish 09], der auf der Basis von einigen Tausend Projekten zeigt, dass sich die Erfolgsquoten von Entwicklungsprojekten seit Jahrzehnten immer noch auf einem bescheidenen Niveau bewegen. Danach werden immer noch 44% aller Projekte mit Terminverzug, Budgetüberziehung oder nachhaltigen Qualitätsproblemen durchgeführt. 24% aller Projekte werden gar ohne Ergebnis abgebrochen, lediglich 32% der Entwicklungsprojekte gehen wie geplant und vereinbart ins Ziel. Bei größeren oder großen Projekten mit einer Teamgröße von 20 Personen oder mehr sind diese Werte sogar noch katastrophaler. Gerade mal 10,8% dieser größeren Projekte werden nach dem CHAOS-Report 2009 erfolgreich durchgeführt.

Betrachtet man den CHAOS-Report der letzten 20 Jahre, hat sich an den Werten kaum etwas verändert (siehe Abb. 2–3). Aber nicht nur der CHAOS-Report bestätigt die bescheidenen Erfolgsquoten von Softwareprojekten. Die bereits zitierte SUCCESS-Studie aus dem Jahr 2006 ermittelt eine durchschnittliche Erfolgsquote von 50,6% [Buschermöhle, Eekhoff & Josko 06]. Wobei diese Studie im Gegensatz zur Standish Group vor allem kleinere und mittelgroße Projekte untersucht hat. Für Projekte mit einer Teamgröße von zehn Mitarbeitern oder mehr lag die Erfolgsquote nach SUCCESS nur noch bei 34,3%. Der CHAOS-Report lässt grüßen. Seit Jahren kommen diese und andere Studien zu dem Ergebnis, dass im Mittel lediglich ein Drittel bis maximal die Hälfte aller Softwareentwicklungsprojekte wirklich erfolgreich ist. Der Rest kommt mit Verzügen und großen Mängeln ins Ziel oder wird abgebrochen. Und das trotz der Inflation neuer Methoden und Technologien, die zum Teil als Allheilmittel hochgejubelt werden, zum Teil als bloßer Hype entlarvt werden. Die mittelmäßigen Erfolgsquoten der Softwareindustrie zeigen sich nahezu resistent gegen jede Neuerung.

Abb. 2–3 Anteil erfolgreicher Projekte 1994–2009 (Quelle: Standish Group)

Fragt man nach den Gründen fehlgeschlagener oder weniger erfolgreicher Projekte werden in Untersuchungen und Studien immer wieder ähnliche Mängel genannt [Standish 09]:

Unvollständige und veränderte Anforderungen

Unzureichendes Projektmanagement

Fehlende Ressourcen

Unrealistische Ziele und Erwartungen

Unzureichender Managementsupport

Neue Methoden der Softwareentwicklung nehmen dann meist Bezug auf diese typischen Ursachen und versuchen diese zu eliminieren. Ein Beispiel sind agile Methoden, die gerade auch das Thema der unklaren und sich verändernden Anforderungen in den Griff bekommen wollen. An den Erfolgsquoten von Projekten ändert sich trotzdem wenig. Auch wenn Scott W. Ambler, ein Vertreter agiler Vorgehensweisen, in einer Statistik aus dem Jahr 2010 zeigt, dass die Erfolgsraten von agilen Projekten im Mittel ca. 10% höher sind als in traditionellen Projekten [Ambler 10]. Das Gesamtniveau bleibt dürftig.

Man kann alleine schon aus den schlechten bis mittelmäßigen Erfolgsquoten schließen, dass die Disziplin der Softwareentwicklung noch nicht wirklich im Stadium der Professionalität angelangt ist. Von einer professionellen Disziplin würde man Erfolgsquoten nahe 100% erwarten. Schaut man allerdings eine Ebene tiefer, stellt man fest, dass es durchaus Softwareunternehmen gibt, die dem Anspruch der Professionalität zumindest nahekommen und mittlere Erfolgsquoten von 90% und mehr erreichen.

2.2.4 Große Unterschiede – Top und Low Performer

»Amateure hoffen. Profis handeln.«

Garson Kanin