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 kommer-zieller Anwendungen. Er begleitet und gestaltet Softwareentwick-lungsprojekte in den unterschiedlichsten Rollen, früher als Soft-wareentwickler, 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 Software-herstellers. 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 Benchmark-analysen und bewertet als Gutachter IT-Projekte und IT-Projekt-angebote.

Hans-Jürgen Plewan · Benjamin Poensgen

Produktive Softwareentwicklung

Bewertung und Verbesserung von Produktivität und Qualität in der Praxis

Hans-Jürgen Plewan hans-juergen.plewan@f-i-solutions-plus.de

Benjamin Poensgen benjamin.poensgen@quantimetrics.de

Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Birgit Bäuerlein Umschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek Die 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-4 PDF 978-3-86491-058-6ePub 978-3-86491-059-3

1. Auflage 2011 Copyright © 2011 dpunkt.verlag GmbH Ringstraße 19 B 69115 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

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · heidi.heilmann@augustinum.net

v

Vorwort

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

Carl Zuckmayer

Kaum eine andere Technologie hat die industriellen und gesellschaftlichen Pro-duktionsprozesse 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 kre-ative 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 Erfah-rung, wenn auch mit ganz unterschiedlichen Schwerpunkten. Der eine, Benjamin Poensgen, ausgebildeter Physiker, hat zunächst als Quereinsteiger vor allem sys-temnahe Programme entwickelt. Seit mehr als fünfzehn Jahren beschäftigt er sich insbesondere damit, wie das Ergebnis und die Produktivität von Softwareprojek-ten sinnvoll gemessen und bewertet werden kann. Der andere, Hans-Jürgen Ple-wan, 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

Vorwortvi

von Messungen, wenn wir nicht wissen, was wir unter Produktivität und Quali-tä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 Softwareent-wicklungsorganisationen 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 Auftragge-bern, 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 und Benjamin Poensgen, Wiesbaden

Juli 2011

vii

Inhaltsverzeichnis

1 Einleitung 1

Teil I Softwareentwicklung und Produktivität 5

2 Professionalisierung als Herausforderung 7

2.1 Wie wird heute Software entwickelt? . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Aktivitäten der Softwareentwicklung . . . . . . . . . . . . . . . . . . . 82.1.2 Ergebnisse der Softwareentwicklung . . . . . . . . . . . . . . . . . . . 102.1.3 Methoden der Softwareentwicklung . . . . . . . . . . . . . . . . . . . 122.1.4 Die Bedeutung von CMMI und Reifegradmodellen . . . . . . . . 14

2.2 Professionalität auf dem Prüfstand . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Was ist Professionalität? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2 Verbreitung methodischer Softwareentwicklung . . . . . . . . . . 182.2.3 Bescheidene Erfolgsquoten . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.4 Große Unterschiede – Top und Low Performer . . . . . . . . . . . 232.2.5 Ursachen der geringen Professionalität . . . . . . . . . . . . . . . . . 25

2.3 Übliche Wege der Professionalisierung . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 Proklamation von Wertesystemen . . . . . . . . . . . . . . . . . . . . . 262.3.2 Professionalisierung durch Methoden und Prozesse . . . . . . . . 272.3.3 Professionalisierung als Industrialisierung . . . . . . . . . . . . . . . 272.3.4 Vision des Software Engineering . . . . . . . . . . . . . . . . . . . . . . 28

3 Die Bedeutung der Produktivität für die Softwareentwicklung 31

3.1 Was verstehen wir unter Produktivität? . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Produktivität über alles? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Produktivität und Projekterfolg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Produktivität und Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.5 Produktivität und Aufwandsschätzung . . . . . . . . . . . . . . . . . . . . . . . 43

3.6 Ohne Produktivität keine Professionalisierung . . . . . . . . . . . . . . . . . 46

Inhaltsverzeichnisviii

Teil II Produktivität messen und bewerten 49

4 Function Points und andere Maße für Projektergebnisse 51

4.1 Functional Size Measurement nach ISO 14143 . . . . . . . . . . . . . . . . . 51

4.2 Function Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Die Functional Size typischer Projekte . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4 Use Case Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.5 Story Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.6 Weitere Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.7 Bei aller Kritik: Function Points sind eine gute Wahl . . . . . . . . . . . . . 61

5 Kennzahlen für Produktivität und Qualität 63

5.1 Kennzahlen für die Produktivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Kennzahlen für die Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Weitere Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Praxis der Messungen 79

6.1 Bewertung der Functional Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2 Messung von Aufwand, Kosten und Zeit . . . . . . . . . . . . . . . . . . . . . . 88

6.3 Softwarefehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.4 Erfahrungsdatenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.5 Statistische Auswertung von Kennzahlen . . . . . . . . . . . . . . . . . . . . . . 93

7 Produktivitätsunterschiede 97

7.1 Streuung von Produktivität und Qualität . . . . . . . . . . . . . . . . . . . . . . 97

7.2 Herausforderung Messgenauigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.3 Vergleichbar – aber nicht gleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.4 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Teil III Produktivitätsfaktoren 115

8 Bad Practices – Was bremst uns? 117

8.1 Unscharfe Ziele und Ziellosigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 117

8.2 Unrealistische Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

8.3 Echte Zeitverschwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.4 Ungeeignetes oder unklares Vorgehen . . . . . . . . . . . . . . . . . . . . . . . 122

8.5 Unklare und instabile Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 123

ixInhaltsverzeichnis

8.6 Schlechte Qualität und viele Nacharbeiten . . . . . . . . . . . . . . . . . . . 124

8.7 Unerfahrene oder ungeeignete Projektleiter . . . . . . . . . . . . . . . . . . 124

8.8 Fehlende Skills im Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.9 Wenig Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.10 Chinesenprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.11 Viele 50 %-Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.12 Zu viel Politik, zu wenig Realismus . . . . . . . . . . . . . . . . . . . . . . . . 127

9 Produktivitätsfaktoren der Softwareentwicklung 129

9.1 Produktivitätsfaktoren im Überblick . . . . . . . . . . . . . . . . . . . . . . . 129

9.2 Produktivitätsfaktoren und Produktivitätshebel . . . . . . . . . . . . . . . 135

9.3 Welche Produktivitätsfaktoren sind relevant? . . . . . . . . . . . . . . . . . 137

10 Die acht elementaren Produktivitätsfaktoren 139

10.1 Ein einfaches Modell produktiver Prozesse . . . . . . . . . . . . . . . . . . . 139

10.2 Berücksichtigung von Qualität und Rework . . . . . . . . . . . . . . . . . . 142

10.3 Berücksichtigung von Verschwendungen . . . . . . . . . . . . . . . . . . . . 143

10.4 Die acht Gebote der Produktivität . . . . . . . . . . . . . . . . . . . . . . . . . 145

Teil IV Produktiver werden 147

11 Die Macht der Ziele nutzen 149

11.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . 149

11.2 Klares Projektziel voranstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

11.3 Explizite Projektdurchführungsziele setzen . . . . . . . . . . . . . . . . . . . 152

11.4 Ziel-Commitments vereinbaren . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

11.5 Erreichbare Zwischenziele setzen . . . . . . . . . . . . . . . . . . . . . . . . . . 154

11.6 Zug zum Ziel durch festen Steuerrhythmus . . . . . . . . . . . . . . . . . . 155

11.7 Zielorientierung auch im Kleinen einfordern . . . . . . . . . . . . . . . . . 157

12 Produktive Hochleistungsteams aufbauen 159

12.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . 159

12.2 Die richtige Teamgröße bestimmen . . . . . . . . . . . . . . . . . . . . . . . . 160

12.3 Teams effektiv organisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

12.4 Den passenden Skillmix finden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

12.5 Gute Projektleiter als Taktgeber finden . . . . . . . . . . . . . . . . . . . . . 168

Inhaltsverzeichnisx

12.6 Individuelle Leistungsfähigkeit erkennen . . . . . . . . . . . . . . . . . . . . . 170

12.7 Motivation erzeugen und erhalten . . . . . . . . . . . . . . . . . . . . . . . . . . 171

12.8 Ein professionelles Wertesystem aufbauen . . . . . . . . . . . . . . . . . . . . 173

13 Den Kern der richtigen Anforderungen treffen 175

13.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . . 175

13.2 Anforderungen iterativ analysieren . . . . . . . . . . . . . . . . . . . . . . . . . 177

13.3 Aktive Benutzerbeteiligung einfordern . . . . . . . . . . . . . . . . . . . . . . . 178

13.4 Prototyping statt Papiertiger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

13.5 Überproduktion vermeiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

14 Vorgehen ohne effektive Methodik abstellen 187

14.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . . 187

14.2 Methodisch vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

14.3 Best Practices sammeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

14.4 Wasserfall vermeiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

14.5 Methodendisziplin erreichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

14.6 Automatisierungen selektiv einsetzen . . . . . . . . . . . . . . . . . . . . . . . . 196

14.7 Wiederverwendung auf verschiedenen Ebenen nutzen . . . . . . . . . . . 198

15 Qualität steigern und Rework radikal reduzieren 201

15.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . . 201

15.2 Qualitätsbewusstsein durch Qualitätsbegriff schaffen . . . . . . . . . . . 202

15.3 Anzahl ausgelieferter Fehler reduzieren . . . . . . . . . . . . . . . . . . . . . . 203

15.4 Rework-Anteil gering halten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

15.5 Qualitätssicherung einfach organisieren . . . . . . . . . . . . . . . . . . . . . . 205

15.6 Mit Projektaudits Sackgassen erkennen . . . . . . . . . . . . . . . . . . . . . . 206

15.7 Codereviews sind effektiver als Tests . . . . . . . . . . . . . . . . . . . . . . . . 208

15.8 Frühes iteratives Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

16 Verschwendungen erkennen und eliminieren 211

16.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . . 211

16.2 Angemessenheit zum Prinzip erklären . . . . . . . . . . . . . . . . . . . . . . . 212

16.3 Pragmatisch dokumentieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

16.4 Effektive Meetings durchführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

16.5 Organisatorische Verschwendungen vermeiden . . . . . . . . . . . . . . . . 216

16.6 Rechtzeitig Hilfe holen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

xiInhaltsverzeichnis

17 Projekte richtig in die Umgebung integrieren 219

17.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . 219

17.2 Projekt schützen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

17.3 Stakeholder aktiv managen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

17.4 Projekte durch Marketing stärken . . . . . . . . . . . . . . . . . . . . . . . . . 222

17.5 Topmanagementfokus nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

18 Fortschritt, Qualität und Produktivität steuern 225

18.1 Die Richtungen der Beschleunigung . . . . . . . . . . . . . . . . . . . . . . . . 225

18.2 Richtige Rahmenbedingungen schaffen . . . . . . . . . . . . . . . . . . . . . 226

18.3 Projektfortschritt kontrollieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

18.4 Qualität messen und bewerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

18.5 Produktivität messen und bewerten . . . . . . . . . . . . . . . . . . . . . . . . 232

19 Zusammenfassung und Ausblick 233

Anhang 237

Literaturverzeichnis 239

Index 245

Inhaltsverzeichnisxii

1

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 Projektma-nagements. 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 Produk-tivitä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 sinn-voll zu definieren, sodass die daraus bestimmte Produktivität auch eine prakti-sche 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ätsorien-tierten oder »produktiven« Softwareentwicklung dar. Mithilfe von Praxisbeispie-len, empirischen Daten und konkreten Empfehlungen werden wir unsere Aussa-gen verdeutlichen und den Leser bei der konkreten Umsetzung unterstützen. Die Erkenntnisse und Empfehlungen beruhen auf unseren eigenen beruflichen Erfah-rungen. Wir haben diese immer wieder kritisch geprüft und verglichen mit dem, was im »klassischen« Projektmanagement bereits etabliert ist. Da wir keine wis-senschaftliche 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 »People-ware«. Unser Buch richtet sich deshalb an alle Menschen in der Softwareentwick-lung – Entwickler, Designer, Architekten, Projektleiter, Teamleiter, Methoden-experten, Controller, Manager. Linienmanager lernen, wie sie optimale Rahmen-bedingungen 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.

1 Einleitung2

Drei Anmerkungen zum »Scope« dieses Buches:

Es ist ein Allgemeinplatz, dass zu einer praxisgerechten Betrachtung der Produk-tivitä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 Hauptper-spektive bleibt dabei aber die Produktivität.

Weiterhin beschränken wir uns auf die Entwicklung von Software bezie-hungsweise 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 Erfahrungs-hintergrund primär in der Entwicklung betrieblicher Informationssysteme. Ob unsere Aussagen auch für die Entwicklung technischer Informationssysteme inte-ressant und anwendbar sind, können Praktiker aus diesen Bereichen sicher sinn-voller 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 Professionali-sierung zusammen. Hier geht es uns vor allem darum, ein gemeinsames Ver-stä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 Softwareentwick-lung hat und wie Professionalisierung und Produktivität zusammenhängen.

31 Einleitung

■ In Teil II: Produktivität messen und bewerten behandeln wir die praktische, konkrete Einführung und Durchführung von Messungen für wichtige Kenn-zahlen zur Produktivität und Qualität in Softwareprojekten. Welche Kenn-zahlen sind wirklich sinnvoll? Wie werden sie gemessen? Und welche Voraus-setzungen 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 Software-projekten ist legendär und erschlagend. Wir stellen deshalb ein einfaches Modell für Produktivitätsfaktoren vor und beschreiben damit die in der Pra-xis entscheidenden acht Produktivitätsfaktoren. Daraus resultieren die acht Gebote produktiver Softwareentwicklung.

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

1 Einleitung4

5

Teil I Softwareentwicklung und Produktivität

6

7

2 Professionalisierung als Herausforderung

»Programmierung ist immer noch Flickwerk. Es wird nur angeflanscht, erweitert, modifiziert

und 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.ama-zon.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 Ent-scheidungen 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 gewor-den? Haben die zahlreichen neuen Paradigmen und Methoden zu »besseren« Projekten, besseren Ergebnissen und besserer Software geführt? Können wir

1. Ex-Entwicklungschef von Microsoft auf einem Vortrag am MIT in Boston im September 2007.

2 Professionalisierung als Herausforderung8

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 beant-worten. Wir wollen damit eine erste Orientierung über den Status quo der Soft-wareentwicklung 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 profes-sionelle Softwareentwicklung ist immer auch eine produktive Softwareentwick-lung.

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 »Softwareentwicklungs-projekt« 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 Basis-aktivitäten durchzuführen:

■ Anforderungsanalyse■ Design■ Implementierung■ Test■ Auslieferung

92.1 Wie wird heute Software entwickelt?

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 Tei-len (Inkrementen) ausgeliefert wird und in Produktion geht oder in einer einzigen Auslieferung.

Der konkrete Softwareentwicklungsprozess ergibt sich dann aus der sequen-ziellen oder parallelen Ausführung dieser Aktivitäten. Daher lässt sich der Kern jedes Entwicklungsprozesses wie folgt beschreiben [IEEE 90]: »Ein Softwareent-wicklungsprozess ist ein Prozess, der Nutzeranforderungen in ein Softwarepro-dukt umsetzt. Der Prozess beinhaltet dabei die Übersetzung von Nutzeranforde-rungen 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.«

1-nIteration

Produktionsstart

Projektstart

Projektmanagement

Qualitätsmanagement

2 Professionalisierung als Herausforderung10

Daneben sind für die Softwareentwicklung drei zentrale Querschnittsaktivi-tä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 standardisier-ten Vorgehensmodelle (zum Beispiel V-Modell XT [Höhn & Höppner 09], Rati-onal 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 Ent-wicklungsmethoden. Insbesondere unterscheiden sich die konkreten Ausgestal-tungen 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« wer-den und die für den täglichen Betrieb und den Nutzen der entwickelten Anwendung notwendig sind,

■ Zwischenergebnisse, die im Projektverlauf entstanden sind, aber nicht ausge-liefert werden und für den Betrieb und Nutzen der Anwendung nicht unbe-dingt notwendig sind.

112.1 Wie wird heute Software entwickelt?

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 zwi-schen 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.

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

2 Professionalisierung als Herausforderung12

2.1.3 Methoden der Softwareentwicklung

Begriffe wie »Vorgehensmodell«, »Entwicklungsmethode« oder »Vorgehens-weise« werden für die Softwareentwicklung oft in einer ähnlichen Bedeutung ver-wendet. Dabei meint der Begriff des Vorgehensmodells ein umfassendes Ablauf-modell 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 hel-fen, 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.

Methoden

Aktivitäten

Vorgehensmodell

Rollen

unterstützen bearbeiten

gibt vor legt fest

regelt

132.1 Wie wird heute Software entwickelt?

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 Itera-tionen, 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 Wasser-fallmodell 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 Iterati-onen und der Agilität das Fundament für das Vorgehen bilden. Meist spricht man dann von »klassischen« oder »traditionellen« Vorgehensweisen gegenüber »ite-rativen« oder »agilen« Vorgehensweisen. Dabei waren die beiden Lager der Ver-treter 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 Entwick-lungsphilosophien 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än-derten Anforderungen zu rechnen ist. Inwieweit das ohnehin eines der latenten Risiken in jedem Entwicklungsprojekt ist, sei hier dahingestellt. Agile Vorgehens-weisen setzen Flexibilität in Bezug auf Änderungen (Anforderungen, Leistungs-umfang, Projektziel) und damit das sogenannte Moving Target in das Zentrum ihrer Entwicklungsrhythmen.

Agilität ist dabei aber nicht nur eine Methode, Software zu entwickeln, son-dern 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.

2. Agiles Manifest siehe http://agilemanifesto.org.

2 Professionalisierung als Herausforderung14

Tab. 2–2 Klassifikation verschiedener Vorgehensweisen

Traditionelle Vorgehensweisen nach dem Wasserfallmodell und auch inkremen-telle Ansätze setzen eine gewisse Stabilität bei der Planbarkeit und bei den Anfor-derungen 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 Anwen-dung, die bereits erfolgreich in Betrieb ist.

2.1.4 Die Bedeutung von CMMI und Reifegradmodellen

Zusätzlich zu konkreten Entwicklungsmethoden und umfassenden Vorgehens-modellen 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 eige-nen (Softwareentwicklungs-)Prozesse orientieren können. Das Rahmenwerk gibt dann im Wesentlichen Anforderungen an die Prozesse vor. Die konkrete Umset-zung mit konkreten Methoden wird vom Reifegradmodell nicht vorgegeben. Das ist der Unterschied zu den oben beschriebenen Vorgehensmodellen und Entwick-lungsmethoden.

Reifegradmodelle haben dabei primär die Qualität von Prozessen und deren Verbesserung im Fokus. Damit unterscheiden diese Modelle »reife« von »unrei-fen« 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 Zer-tifizierung verknüpft. Wichtige Reifegradmodelle sind u. a.:

■ CMMI■ ISO 9000/9001■ ITIL■ SPICE

Vorgehens-modell

Anzahl Iterationen

Typische Länge einer Iteration

Anzahl Anforderungs-analysen

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