Agile Methoden in der Softwareentwicklung

Bibliografische Beschreibung

G¨ otzenauer, J¨ urgen:

Agile Methoden in der Softwareentwicklung - Vergleich und Evaluierung. - 2005 - 103 S. Graz, Hochschule Mittweida (FH), Fachbereich Informationstechnik & Elektrotechnik, Diplomarbeit, 2005

Referat

Die Software-Industrie steht heute mehr denn je vor der Tatsache, dass ein Großteil der beauftragten Projekte die geforderte Qualit¨ at nicht erreicht, Zeit- und Budgetvorgaben uberschritten werden, oder im schlimmsten Fall das Projekt noch w¨ ahrend der Entwicklung ¨ abgebrochen wird.

Die Anforderungen der Kunden an die beauftragte Software sind unklar, der Zeitraum zwischen Vertragsunterzeichnung und Auslieferung des Endprodukts wird zunehmend enger und die Entwicklung in verteilten Teams steht in Zeiten der Globalisierung an der Tagesordung.

Der ¨

Ubergang von den traditionellen Softwareentwicklungsmethoden hin zu leichtgewichtigen und agilen Vorgehensmodellen ist eine der M¨ oglichkeiten sich diesen Herausforderungen erfolgreich zu stellen.

Das Ziel der vorliegenden Arbeit ist es, die Eigenschaften und Schwerpunkte der verschiedenen Vertreter der Agilen Methoden zu erarbeiten und zu vergleichen. Zus¨ atzlich soll aus diesen Vertretern der Agilen Methoden ein geeignetes Vorgehensmodell f¨ ur die Entwicklungsabteilung eines weltweit agierenden Unternehmens im Bereich der Telekommunikation und Systemintegration ermittelt werden. Hierf¨ ur werden die unternehmensinternen Anforderungen erarbeitet und daraus ein Kriterienkatalog abgeleitet, wobei besonderes Augenmerk auf die Umsetzungsm¨ oglichkeiten in global verteilten Softwareentwicklungsprojekten gelegt wird.

1

Danksagung

Ich m¨ ochte mich bei Herrn Prof. Dr.-Ing. Uwe Schneider von der Hochschule Mittweida herzlich f¨ ur seine Unterst¨ utzung bei der Umsetzung der vorliegenden Arbeit bedanken. Mein Dank gilt auch Herrn Dipl.-Ing. Mario Walder von der BearingPoint INFONOVA GmbH, der mir die M¨ oglichkeit gab, die vorliegende Arbeit innerhalb meines beruflichen Umfelds umzusetzen und mir immer mit Rat und Tat zur Verf¨ ugung stand. Weiters m¨ ochte ich mich bei Herrn Dr. Peter Hruschka von der Atlantic Systems Guild f¨ ur seine wertvollen Anregungen hinsichtlich der Anwendbarkeit Agiler Methoden in global verteilten Softwareentwicklungsprojekten bedanken.

Mein ganz besonderer Dank gilt jedoch meiner Frau Martina und meiner Familie, die mir auch in den entbehrungsreichen Zeiten des berufsbegleitenden Studiums zur Seite standen und immer f¨ ur mich da waren.

Inhaltsverzeichnis

1  Einleitung  8

1.1  Motivation  8

1.2  Zielsetzung  10

1.3  Gliederung  11

2  Klassische Softwareentwicklung  13

2.1  Die Softwarekrise  13

2.2  Software Engineering Methodik als L osungsansatz  15

2.3  Traditionelle Vorgehensmodelle  16

2.3.1  Das Phasen- oder Wasserfallmodell  16

2.3.2  Das V-Modell  19

2.3.3  Das Spiralmodell  20

2.4  Erfolgskriterien in Softwareprojekten  21

3  Agile Softwareentwicklung  25

3.1  Eine neue Bewegung entsteht  25

3.2  Das Agile Manifest  26

3.3  Die vier Agilen Werte  28

3.3.1  Individuen und Interaktionen  28

3.3.2  Funktionierende Software  28

3.3.3  Zusammenarbeit mit dem Kunden  28

3.3.4  Vorbereitung auf unbekannte  

  Anderungen  29

3.4  Die zw olf Agilen Prinzipien  29

4  Anforderungen an einen Entwicklungsprozess  31

4.1  Einordnung der Agilen Vorgehensmodelle  31

4.2  Unternehmensspezifische Anforderungen  32

4.2.1  Unternehmensdarstellung  32

4.2.2  Projekteigenschaften und Arbeitsumfeld  32

4.3  Der Kriterienkatalog  35

4.3.1  Einordnung der Agilen Methodik  36

4.3.2  Projektgr oße  36

4.3.3  Projektphasen  37

4.3.4  Gewichtung  37

4.3.5  Projektumwelt  38

3

5  Vergleich und Evaluierung  39

5.1  Adaptive Software Development (ASD)  39

5.1.1  Rollen und Verantwortlichkeiten  40

5.1.2  Prozessbeschreibung  40

5.1.3  Praktiken und Charakteristika  42

5.1.4  Zusammenfassung und Evaluierung  43

5.2  Crystal Methods  45

5.2.1  Rollendefinitionen  47

5.2.2  Prozessbeschreibung  48

5.2.3  Praktiken und Charakteristika  50

5.2.4  Zusammenfassung und Evaluierung  51

5.3  Scrum  53

5.3.1  Rollen und Verantwortlichkeiten  53

5.3.2  Prozessbeschreibung  54

5.3.3  Praktiken und Charakteristika  56

5.3.4  Zusammenfassung und Evaluierung  58

5.4  Dynamic Systems Development Method (DSDM)  60

5.4.1  Rollen und Verantwortlichkeiten  61

5.4.2  Prozessbeschreibung  61

5.4.3  Praktiken und Charakteristika  63

5.4.4  Zusammenfassung und Evaluierung  64

5.5  Extreme Programming (XP)  66

5.5.1  Rollen und Verantwortlichkeiten  67

5.5.2  Prozessbeschreibung  67

5.5.3  Praktiken und Charakteristika  69

5.5.4  Zusammenfassung und Evaluierung  71

5.6  Feature Driven Development (FDD)  73

5.6.1  Rollen und Verantwortlichkeiten  73

5.6.2  Prozessbeschreibung  75

5.6.3  Praktiken und Charakteristika  77

5.6.4  Zusammenfassung und Evaluierung  78

5.7  Zusammenfassung der Evaluierung  80

6  Agile Methoden und global verteilte Entwicklung  81

6.1  Eigenschaften gobal verteilter Entwicklung  81

6.2  Organisatorische Komplexit at in global verteilter Entwicklung  82

6.3  Agile Praktiken in global verteilter Entwicklung  83

6.4  Umsetzung in der BearingPoint INFONOVA GmbH  86

7  Zusammenfassung  88

7.1  Res umee  88

7.2  Ergebnisse  89

7.3  Schlussbemerkung und Ausblick  93

  Literaturverzeichnis  95

4

Abbildungsverzeichnis

2.1  Das Phasen- oder Wasserfallmodell  17

2.2  Das erweiterte Phasen- oder Wasserfallmodell  18

2.3  Das NATO-Phasenmodell (Quelle: NR68 S 13 )  19

2.4  Das V-Modell  20

2.5  Das Spiralmodell (Quelle: wikipedia.org)  21

2.6  IT-Projekte von 1994 bis 2004 (Quelle: Standish Group Int )  23

2.7  Rezept f ur Projekterfolg (Quelle: Standish Group Int )  24

4.1  Projekt-Entwicklung vs. Produktentwicklung  33

4.2  Struktur von Projektmitarbeitern  34

4.3  Struktur von verteilten Projektteams  35

5.1  ASD Prozessmodell  41

5.2  ASD Projektphasen (Quelle: DK05 S 142  42

5.3   

  Ubersicht der verschiedenen Crystal Methodiken  46

5.4  Crystal Projektphasen (Quelle: DK05 S 149 )  50

5.5  Das Scrum-Prozessmodell in der Grob ubersicht  54

5.6  Der Scrum-Prozess im  

  Uberblick  56

5.7  Beispielhafte Burndown-Chart  57

5.8  DSDM Prozessmodell  62

5.9  XP Prozess ubersicht  68

5.10  Test Driven Development (TDD)  69

5.11  FDD Prozess ubersicht  75

5.12  FDD Prozess-Schritte (Quelle: Kevin Morrison)  76

6.1  Abnahme der Kommunikationsh aufigkeit (Quelle: Kot01 S 56 )  83

5

Tabellenverzeichnis

2.1  Kriterien f ur den Projekterfolg im Jahr 1994  22

5.1  Evaluierungsmatrix f ur Adaptive Software Development (ASD)  44

5.2  Evaluierungsmatrix f ur Crystal Methods  52

5.3  Evaluierungsmatrix f ur Scrum  59

5.4  Die MoSCoW-Regel  63

5.5  Evaluierungsmatrix f ur Dynamic Systems Development Method (DSDM)  65

5.6  Evaluierungsmatrix f ur Extreme Programming (XP)  72

5.7  FDD Zertifizierungsstufen  73

5.8  Evaluierungsmatrix f ur Feature Driven Development (FDD)  79

5.9  Evaluierungsmatrix Gesamt ubersicht  80

6

Abk ¨ urzungsverzeichnis

ACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Association for Computing Machinery ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agile Database Techniques AM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agile Modelling ASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adaptive Software Development DIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deutsches Institut fuer Normung DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Systems Development Method FDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature Driven Development HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Markup Language ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Organization for Standardization IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Technology JAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joint Application Development LSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lean Software Development NATO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . North Atlantic Treaty Organisation PP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pragmatic Programming SW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Driven Development TSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Team Software Process UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Interface XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXtreme Programming

Kapitel 1

Einleitung

In diesem Kapitel wird die grundlegende Motivation und Ausgangssituation der vorliegenden Arbeit beschrieben, die Aufgabenstellungen und Zielsetzungen pr¨ azisiert und die Gliederung des Dokuments n¨ aher erl¨ autert.

1.1 Motivation

Software findet sich mittlerweile in allen Bereichen des Lebens und ist schon lange aus unserem Alltag nicht mehr wegzudenken. Der Wandel hin zur nahezu vollst¨ andig automatisierten Informationsgesellschaft hat sich in den letzten Jahren bereits vollzogen. Neben den herk¨ ommlichen Computersystemen, die sich schon in fast jedem Haushalt und jedem B¨ uro finden, steigt auch die Verbreitung von sogenannten Embedded-Systems ¹ rasant an. Man m¨ ochte meinen, dass durch diese ubiquit¨ are Nutzung von Software-Komponenten deren Entwicklung ein qualitativ zumindest gleichwertiges Niveau wie die Entwicklung von Produkten in vergleichbaren traditionellen Ingenieursdisziplinen (z.B. Maschinenbau, Elektrotechnik oder Architektur) erreicht hat. Doch schon in der ersten H¨ alfte der 60er Jahre des 20. Jahrhunderts zeichnete sich in der Industrie eine Situation ab, die im Bereich der Software-Entwicklung zu dem Begriff Softwarekrise ² f¨ uhrte:

• Programme taten nicht das, was sie sollten, oder aber sie taten das, was sie tun sollten, nur fehlerhaft.

• Software kostete, wenn sie ¨ uberhaupt je fertig wurde, ein Vielfaches dessen, was zu Beginn geplant war.

• Termine wurden selten eingehalten und die nachtr¨ agliche ¨ Anderung von exisitierender Software war nahezu unm¨ oglich.

¹ Embedded System: ” A computer system that is part of a larger system and performs some of the requirements of that system; for example, a computer system used in an aircraft or mobile phone.“ [IEE90, S.30] ² Softwarekrise: ” Bezeichnet ein Mitte der sechziger Jahre des zwanzigsten Jahrhunderts auftretendes Ph¨ anomen: Erstmalig ¨ uberstiegen die Kosten f¨ ur die Software die Kosten f¨ ur die Hardware. In der Folge

8

KAPITEL 1. EINLEITUNG 9

Die Software-Industrie war zu dieser Zeit nicht mehr in der Lage, mit den damals bekannten Techniken und Werkzeugen die Entwicklung großer Programme zu beherrschen. [PS94, S.19ff] In einer ersten Reaktion auf die Softwarekrise erkannte man, dass ein v¨ ollig neues und systematisches Vorgehen notwendig war, um von der damals vorherrschenden ” Kunst des Programmierens“ den Schritt zu ingenieurm¨ aßiger Softwareentwicklung zu gehen. Vor diesem Hintergrund wurde 1968 auf einer NATO-Konferenz in Garmisch der Begriff Software Engineering ³ gepr¨ agt. [NR68, S.19ff] Man sah Parallelen zur Herstellung von Produkten im Bereich der Ingenieurwissenschaften und wollte deren methodisches Vorgehen adaptieren. Der Entwicklungsprozess von Software sollte dadurch plan- und kalkulierbar werden. Die oben genannten Umst¨ ande und die steigende Komplexit¨ at der Programme bei kommerziellen Softwareprojekten f¨ uhrten zur Definition von sogenannten Vorgehensmodellen ⁴ , mit denen die Arbeitsabl¨ aufe in Softwareprojekten standardisiert werden sollten. Es etablierte sich ein erstes systematisches Modell, das sich gr¨ oßtenteils am Vorbild von industriellen Fertigungsprozessen orientierte und den Softwareentwicklungsprozess in die vier großen Phasen Analyse, Entwurf, Implementierung und Test gliederte, das sogenannte Phasen- oder Wasserfallmodell ⁵ . Inzwischen gibt es eine große Anzahl an wissenschaftlichen Untersuchungen zu der Fragestellung, wie man Software qualitativ hochwertig und zugleich fristgerecht und wirtschaftlich ¨ okonomisch entwickeln k¨ onnte. Es wurden weitere Methoden und Vorgehensmodelle entwickelt, welche die Bereiche der Softwareentwicklung Schritt f¨ ur Schritt in ihre Teilprozesse zerlegen und umfangreiche Regelwerke zur effizienten Softwareentwicklung zur Verf¨ ugung stellen. Dennoch ist es auch heute noch h¨ aufig so, dass viele Softwareprojekte die Anforderungen, welche vom Kunden gefordert werden, nicht oder nur unzureichend erf¨ ullen, Termin- und Budgetvorgaben ¨ uberschreiten und somit letztendlich die Projektziele verfehlen. [Int95, S.3ff] Es stellt sich zunehmend heraus, dass bei der Entwicklung von Software andere Gesetzm¨ aßigkeiten gelten, als in den traditionellen Ingenieursdisziplinen und Softwareprojekte beim Projektstart oftmals mit vielen Konstanten begonnen werden, die sich aber im weiteren Projektverlauf sehr schnell zu Variablen ¨ andern.

So sollen zum Beispiel Preis, Liefertermin, Qualit¨ at und Umfang der geforderten Software schon zu Vertragsbeginn feststehen und das Projekt mit Hilfe eines definierten Projektplans abgewickelt werden. Doch sind diese Anforderungen an ein Softwareprodukt l¨ angst nicht so stabil und weisen h¨ aufig Konflikte und Zielkonkurrenzen auf. Niedrigstpreise widersprechen umfangreicher Funktionalit¨ at und ” sportlich“ definierte Zeitrahmen konkurrieren naturgem¨ aß mit den hohen Qualit¨ atsanspr¨ uchen der meisten Kunden. Dynamische Projekte an der Spitze von Markt und Technologie entwickeln ihre konkreten Anforderungen oft sogar erst w¨ ahrend des eigentlichen Projektverlaufs.

³ Software Engineering: ” The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.“ [IEE90, S.67] ⁴ Vorgehensmodell: ” Gliedert einen Prozess in verschiedene, strukturierte Phasen, denen wiederum entsprechende Methoden und Techniken zugeordnet sind. Aufgabe eines Vorgehensmodells ist es, die allgemein in einem Prozess auftretenden Aufgabenstellungen und Aktivit¨ aten in ihrer logischen Ordnung darzustel-

len.“ (Vgl. http://de.wikipedia.org/wiki/Vorgehensmodell) ⁵ Wird in Kapitel 2 - Unterabschnitt 2.3.1, Seite 16 dieser Arbeit n¨ aher erl¨ autert.

KAPITEL 1. EINLEITUNG 10

Die traditionellen Vorgehensmodelle mit ihren restriktiven und schwergewichtigen Regelwerken stoßen hier sehr schnell an ihre Grenzen, da auf st¨ andige ¨ Anderung gar nicht, oder nur sehr eingeschr¨ ankt, reagiert werden kann. Die Diskussionen dar¨ uber, wie am besten auf diese Umst¨ ande in der Softwareentwicklung reagiert werden kann und welches Vorgehensmodell daf¨ ur am geeignetsten ist, sind noch lange nicht abgeschlossen, wurde aber in den letzten Jahren durch einen radikalen Richtungswechsel belebt. Neue Vorgehensmodelle wurden entwickelt, die sich in ihren Paradigmen radikal von den traditionellen Entwicklungsmethodiken unterscheiden. Eines der hervorstechendsten Merkmale dieser neuen und revolution¨ aren Vorgehensmodelle ist die vergleichsweise geringe Anzahl und der schlichte Charakter ihrer Regeln, daher werden sie als leichtgewichtige oder agile ⁶ Prozesse bezeichnet.

Die Erfinder und Initiatoren der Agilen Methoden haben erkannt, dass in großen kommerziellen Softwareprojekten permanente ¨ Anderungen (seien es nun die Anforderungen der Kunden an das Produkt, der zeitliche Ablauf des Projekts, etc.) nicht durch starre und schwergewichtige Vorgehensmodelle im Vorhinein ” wegzuplanen“ sind, sondern durch flexible und leichtgewichtige Prozesse schnell und effektiv darauf reagiert werden muss. ⁷ Frei nach dem Motto ” Man kann sich nicht aussuchen, was auf einen zukommt. Man kann sich aber aussuchen, wie man darauf reagiert!“.

1.2 Zielsetzung

Zu den bereits im vorangegangenen Abschnitt erw¨ ahnten kritischen Punkten in der Softwareentwicklung gesellt sich in Zeiten der Globalisierung und des Outsourcings der Umstand, dass große kommerzielle Softwareprojekte l¨ angst nicht mehr nur von Teams an einem Standort entwickelt werden, sondern die Projektmitglieder h¨ aufig geografisch verteilt und durch Zeitzonen getrennt an ein und demselben Softwareprojekt arbeiten m¨ ussen. Der Autor der vorliegenden Arbeit ist seit Jahren beruflich in den Bereichen Software Quality Management und Software Engineering in der Entwicklungsabteilung eines weltweit agierenden Unternehmens im Bereich der Telekommunikation und Systemintegration t¨ atig und tagt¨ aglich mit den Herausforderungen globaler Softwareentwicklung in verteilten Teams konfrontiert.

Das Ziel der vorliegenden Arbeit ist es, die verschiedenen Ans¨ atze und Vertreter der Agilen Methoden in der Softwareentwicklung allgemein zu vergleichen und in Hinblick auf die unternehmensinternen Anforderungen zu evaluieren.

Hierf¨ ur werden die unternehmensinternen Anforderungen mittels Interviews, Frageb¨ ogen und Projektreviews erarbeitet und daraus ein Kriterienkatalog abgeleitet. Besonderes Augenmerk wird dabei auf die Umsetzungsm¨ oglichkeiten in global verteilten Entwicklungsteams gelegt. Anhand der gewonnenen Ergebnisse soll ein f¨ ur das Unternehmen geeignetes Vorgehensmodell vorgeschlagen werden. Wenn die unternehmensinternen Anforderungen nicht von einer einzelnen Agilen Methode abgedeckt werden, soll untersucht werden, ob

⁶ agil gleichbed. fr. agile, dies aus lat. agilis, eigtl. ” leicht zu f¨ uhren, beweglich“> : beh¨ ande, flink, gewandt; regsam, gesch¨ aftig. [Dud03] ⁷ Nicht umsonst benannte Kent Beck, der Erfinder von Extreme Programming sein erstes Buch zu diesem Thema mit dem Untertitel ” Embrace change“ (Auf Deutsch: ”

KAPITEL 1. EINLEITUNG 11

eine M¨ oglichkeit der Adaptierung, bzw. Kombination mit anderen Methoden besteht.

Somit sollen als Ergebnis der vorliegenden Arbeit die folgenden Fragestellungen beant-wortet werden:

• Welche Anforderungen werden aktuell von einem global agierenden Unternehmen im Bereich der Telekommunikation und Systemintegration an einen Softwareentwicklungsprozess gestellt? 8

• Wie unterscheiden sich die aktuellen Vertreter der sogenannten Agilen Methoden hinsichtlich ihrer Praktiken und ihrer Umsetzung?

• Erf¨ ullt eine der Agilen Methoden die Anforderungen, oder k¨ onnen Teilbereiche aus verschiedenen Agilen Vorgehensmodellen hierf¨ ur kombiniert oder erweitert werden?

1.3 Gliederung

Im Folgenden wird auf die Gliederung und den inhaltlichen Aufbau der vorliegenden Arbeit eingegangen. Es wird erl¨ autert, wie zur Beantwortung der Fragestellungen aus dem vorigen Abschnitt vorgegangen wurde und wie die Ergebnisse der Untersuchungen dargestellt werden.

Da sich Agile Methoden von den traditionellen und schwergewichtigen Methoden in vielerlei Hinsicht gravierend unterscheiden, besch¨ aftigt sich der erste Teil der Arbeit mit der Klassifizierung von Entwicklungsprozessen im Allgemeinen. In Kapitel 2 - ” wicklung von Softwareprojekten anhand der Softwarekrise und des daraus resultierenden Begriffs des Software Engineerings beschrieben, sowie die daraus abgeleiteten traditionellen Vorgehensmodelle erl¨ autert. Als wichtigste Vertreter werden hierbei das Phasen- oder Wasserfallmodell, das V-Modell und das Spiralmodell angef¨ uhrt. ⁹ In Kapitel 3 - ” Bewegung beschrieben und erl¨ autert, welche Ursachen und Probleme in der traditionellen Softwareentwicklung ¨ uberhaupt zur Entstehung der Agilen Bewegung gef¨ uhrt haben und welche L¨ osungsans¨ atze die Agile Bewegung hinsichtlich dieser Probleme empfiehlt. Da heute eine große Anzahl an unterschiedlichen Entwicklungsprozessen zur Verf¨ ugung steht, stellt sich die Frage, welche Faktoren einen Einfluss auf die Abwicklung von Softwareprojekten haben und welche Kriterien bei der Auswahl eines Vorgehensmodells relevant sind.

Das Kapitel 4 - ” sich daher mit den Anforderungen an einen Agilen Softwareentwicklungsprozess im Allgemeinen und den firmeninternen Auswahlkriterien anhand eines im Unternehmen erarbeiteten Kriterienkatalogs im Speziellen.

⁸ Mit Gewichtung auf Projekte mit einer Gr¨ oße von 20 bis 50 Projektmitarbeitern und einer durchschnittlichen Durchlaufzeit von 500 Personentagen.

⁹ Es wurden bewusst nur die drei bedeutendsten Vertreter der traditionellen Vorgehensmodelle erw¨ ahnt, da eine detaillierte Beschreibung s¨ amtlicher dokumentierter traditioneller Vorgehensmodelle den Rahmen dieser Arbeit sprengen w¨ urde.

KAPITEL 1. EINLEITUNG 12

Die Charakteristika der sechs aktuell angewandten und dokumentierten Agilen Methoden werden in Kapitel 5 - ” Um einen Vergleich zu erleichtern werden die verschiedenen Agilen Methoden immer nach dem selben Schema beschrieben: Einleitung, Rollen und Verantwortlichkeiten, Prozessbeschreibung, Praktiken und Charakteristika sowie Zusammenfassung und Evaluierung. In Kapitel 6 - ” erl¨ autert, welche Anpassungen und Erweiterungen an den bestehenden Agilen Methoden vorzunehmen sind, um sie erfolgreich in global verteilten Softwareprojekten anwenden zu k¨ onnen, und welche Praktiken davon bereits in der BearingPoint INFONOVA GmbH zur Anwendung kommen.

Das Kapitel 7 - ” menfassende Darstellung der Ergebnisse und Hinweise auf eventuelle Erweiterungs- und Umsetzungsm¨ oglichkeiten ab.

Kapitel 2

Klassische Softwareentwicklung

In diesem Kapitel wird dargelegt, welche Probleme und Herausforderungen in den ersten Jahrzehnten der kommerziellen Software-Entwicklung auftraten und welche Umst¨ ande dann schließlich zur Entwicklung der ersten fundierten Vorgehensmodelle gef¨ uhrt haben. Im ersten Abschnitt wird kurz das Wesen und der Hintergrund der sogenannten Softwarekrise erl¨ autert und im zweiten Abschnitt auf den Ursprung des Begriffs Software-Engineering und dessen Rolle als Antwort auf die Softwarekrise eingegangen. Die wichtigsten Vertreter der traditionellen Vorgehensmodelle und deren wesentlichen Merkmale werden im dritten Abschnitt angef¨ uhrt. Dass Software-Projekte trotz dieses wesentlichen Umdenkens nach wie vor nicht wie Produktentwicklungen in anderen Ingenieursdisziplinen abgewickelt werden k¨ onnen und selbst im Jahr 1994 noch 31% aller Software-Projekte vor der Fertigstellung abgebrochen wurden ¹ , wird im letzten Abschnitt dieses Kapitels behandelt.

2.1 Die Softwarekrise

In den 50er Jahren des 20. Jahrhunderts gestaltete sich die Entwicklung von Software noch als relativ einfach, obwohl zu dieser Zeit sich nur Spezialisten und Universit¨ aten damit besch¨ aftigten:

• Die entwickelte Software war verh¨ altnism¨ aßig klein und ¨ uberschaubar.

• Die implementierten Algorithmen hatten im Vergleich zu sp¨ ateren Entwicklungen eine sehr geringe Komplexit¨ at.

• Die Entwickler der Software waren in den meisten F¨ allen auch gleichzeitig die Anwender, dadurch kam es in der Regel nicht zu Verst¨ andigungsschwierigkeiten zwischen Auftraggebern und Auftragnehmern.

Dar¨ uber hinaus war die Hardware zu dieser Zeit noch nicht sehr leistungsf¨ ahig, was dazu f¨ uhrte, dass das Scheitern eines Projektes zu dieser Zeit meistens auf eine fehlerhafte Hardware zur¨ uckzuf¨ uhren war. Denn entweder war die Hardware durch Rechenfehler der Ingenieure flasch definiert, oder einfach zu fehleranf¨ allig, bzw. zu langsam. Dass aus der

13

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 14

Software gr¨ oßere Probleme entstehen k¨ onnten, glaubte man zu dieser Zeit nicht. [DK05, S.16] Nur zehn Jahre sp¨ ater begannen jedoch Computer die Industrie im großen Stil zu erobern. Das Resultat war, dass die verwendete Hardware in ihrer Bedeutung durch verschiedene Fortschritte in der Technik immer mehr in den Hintergrund trat. ² Stattdessen wurde es immer schwieriger, ¨ adequate Software zu entwickeln.

W¨ ahrend zuvor bei der Entwicklung von Programmen die Korrektheit und Effizienz der Software im Vordergrund standen, kamen nun durch die enorme Zunahme von Komplexit¨ at und Umfang v¨ ollig neue Problemstellungen hinzu:

• Große Aufgaben mussten sinnvoll in kleinere Programmteile (Module) zerlegt werden.

• Schnittstellen zu anderen Programmen mussten definiert werden.

• Die Software musste sicherer, zuverl¨ assiger und vor allem wartbar sein.

• Der enorme Fortschritt stellte die Industrie dar¨ uber hinaus vor v¨ ollig neue Probleme im Bereich der Organisation.

Die bisherigen Arbeitsabl¨ aufe der im IT-Umfeld besch¨ aftigten Mitarbeiter passten Auf-grund dieser Konflikte mit der Zeit immer weniger zu den neuen Anforderungen. Der Produktionsprozess wandelte sich von einer ” Nebent¨ atigkeit“ zu einem eigenst¨ andigen und ungemein komplexen Ablauf und wurde dadurch mit den damaligen Mitteln immer weniger plan- und beherrschbar. Der Verlust der Kontrolle brachte wiederum erhebliche Risiken mit sich, so dass Kosten-, Zeit- und Qualit¨ atsziele aufgrund der gestiegenen Komplexit¨ at immer weniger oft eingehalten werden konnten. 1965 war es schließlich so weit, dass man von der sogenannten Softwarekrise zu sprechen begann. [DK05, S.16f] Eine der ersten gesicherten Erw¨ ahnungen dieser Bezeichnung findet sich in Edsger W. Dijkstras Dankesrede zum Turing-Preis ³ , die er 1972 hielt und welche im ” tions of the ACM“ Magazin ver¨ offentlicht wurde. Er beschreibt darin die Ursache der Softwarekrise wie folgt:

[The major cause of the software crisis is] that the machines have become several

”

orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.“ [Dij72, S.4]

² Die Erfindung des Transistors im Jahre 1947 durch William B. Shockley, John Bardeen und Walter Brattain gewann zu dieser Zeit den Wettlauf gegen die bis dato eingesetzte R¨ ohrentechnik und f¨ uhrte in ihrer Anwendung in integrierten Schaltkreisen dazu, dass die Hardware immer stabiler und leistungsf¨ ahiger wurde.

³ Der nach Alan Turing benannte und mit 100.000 US-Dollar dotierte Turing-Preis (offizielle Bezeichnung: A. M. Turing Award) wird j¨ ahrlich von der Association for Computing Machinery (ACM) an Personen verliehen, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Er gilt als h¨ ochste Auszeichnung in der Informatik, vergleichbar mit dem Nobelpreis oder der Fields-Medaille. (Vgl. http://de.wikipedia.org/wiki/Turing-Preis)

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 15

In der deutschen ¨

Ubersetzung:

[Die Hauptursache f¨ ur die Softwarekrise liegt darin begr¨ undet,] dass die Maschinen

”

um einige Gr¨ oßenordnungen m¨ achtiger geworden sind! Um es umgangssprachlich auszudr¨ ucken: Solange es keine Maschinen gab, stellte die Programmierung kein Problem dar; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem kleineren Problem und nun da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.“ 4

2.2 Software Engineering - Methodik als L¨ osungsansatz

Als Reaktion auf die Softwarekrise versuchte man, sich verst¨ arkt an den Arbeitsweisen und Abl¨ aufen der Ingenieursdisziplinen zu orientieren,um dadurch eine strukturierte, weit vorausplanende, geradlininge und theoretisch fundierte Arbeitsweise zu etablieren, welche die vorliegenden Probleme l¨ osen sollte. [DK05, S.17] Vor diesem Hintergrund wurde der Begriff Software Engineering im Jahr 1968 in Garmisch Partenkirchen auf einer vom Wissenschaftskomitee der NATO einberufenen Konferenz zun¨ achst als Schlagwort eingef¨ uhrt. 5

Der Softwareentwicklungsprozess sollte plan- und kalkulierbarer werden. Pr¨ azise Vorgaben, die in Abstimmung mit dem Auftraggeber getroffen werden, sowie eine bessere Qualit¨ atskontrolle sollten hochwertige Produkte garantieren und somit den Auftraggeber zufrieden stellen. Es setzte sich auch die ¨

Uberzeugung durch, dass neue Managementmethoden zur Organisation großer Projekte eingef¨ uhrt werden mussten, um eine rigorose Kontrolle der Kosten und Termine zu gew¨ ahrleisten und die Organisation großer Entwicklungsteams in den Griff zu bekommen. [PS94, S.36]

Um dies zu erreichen, diskutierten auf der Konferenz mehr als f¨ unfzig Wissenschaftler von Universit¨ aten aus elf verschiedenen L¨ andern ¨ uber den Zusammenhang von Software und Hardware, das Design von Software, die Produktion, bzw. Implementierung von Software, die Verteilung von Software und die Wartung von Software. [NR68, S3ff.] Die Konferenz sollte ein neues Licht auf viele der damals gegenw¨ artigen Probleme im Bereich der kommerziellen Software-Entwicklung werfen. Es sollten auch m¨ ogliche Techniken, Methoden und Entwicklungen, die zur L¨ osung der Probleme f¨ uhren k¨ onnten, besprochen werden. Man erwartete, dass die Konferenz Erfordernisse, M¨ angel und Trends aufzeigen w¨ urde und dass diese als konkrete Wegweiser f¨ ur die Hersteller und die Benutzer von Computern dienen k¨ onnten. [BPK00, S.9]

Jedoch waren sich die Teilnehmer der Konferenz in vielerlei Hinsicht nicht einig und wussten auch nicht, wie sie die Probleme gemeinsam l¨ osen sollten. Daher wurden von den verschiedenen teilnehmenden Personen Arbeitspapiere ausgearbeitet und kommentiert.

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 16

Vor allem Edsger W. Dijkstra kritisierte die von ihm behauptete Einstellung vieler Konferenzteilnehmer:

• Wir d¨ urfen unsere Vorgehensweise nicht ¨ andern.

• Wir d¨ urfen unsere Programmierhilfsmittel nicht ¨ andern.

• Wir d¨ urfen unsere Hardware nicht ¨ andern.

• Wir d¨ urfen unsere Aufgaben nicht ¨ andern.

• Wir d¨ urfen die organisatorischen Abl¨ aufe nicht ¨ andern, in denen die Arbeiten erledigt werden m¨ ussen.

Wir sollen unter diesen f¨ unf unab¨ anderlichen Grenzbedingungen versuchen, Verbes-

”

serungen zu erreichen? Dies ist ¨ außerst l¨ acherlich!“ 6

Dijkstra glaubte, dass eine gr¨ undliche ¨

Anderung der Entwicklungsmethoden auf allen Ebenen die notwendige L¨ osung aller Probleme der Software-Krise sei. Er hob hervor, dass man die existierende Arbeitsweise grundlegend ¨ andern m¨ usse. Die Hardware und die Hilfsmittel h¨ atten sich ge¨ andert, die Aufgaben seien komplexer geworden, aber die Entwicklungsmethoden und die Organisationsstrukturen und Methoden eines Softwareprojekts h¨ atten sich nicht der Entwicklung der letzten Jahre angepasst. [BPK00, S.12f] In Folge wurden viele wichtige Begriffe der Softwareindustrie neu definiert und man versuchte, generelle Richtlinien f¨ ur die Entwicklung leistungsf¨ ahiger Software zu entwickeln. Nur ein Jahr sp¨ ater wurde eine Folgekonferenz in Rom abgehalten, auf der die in Garmisch angesprochenen Inhalte nochmals ¨ uberarbeitet wurden und speziell auf die Themen Software-Spezifikation, -Qualit¨ at und -Flexibilit¨ at eingegangen wurde. Auch die Korrektheit und Portabilit¨ at von Software wurde er¨ ortert. [BR69, S.5ff]

2.3 Traditionelle Vorgehensmodelle

Als Ergebnis der NATO-Konferenzen stieß die Idee einer ingenieurm¨ aßigen Vorgehensweise bei der Entwicklung von Software besonders auf Managementebene der großen Unternehmen auf breite Zustimmung. Es etablierten sich die ersten systematischen Modelle, deren wichtigste Vertreter in den folgenden Abschnitten stellvertretend f¨ ur die klassischen Vorgehensmodelle erl¨ autert werden.

2.3.1 Das Phasen- oder Wasserfallmodell

Das bekannteste lineare Vorgehensmodell ist das Phasen- oder Wasserfallmodell und wurde 1970 von Walker Royce entwickelt. [Roy70] Es stellt lediglich eine Erweiterung des bereits im Jahre 1956 von Herbert D. Benington publizierten Stagewise Models dar. Beningtons Vorgehensmodell orientierte sich am Vorbild industrieller Fertigungsprozesse und behandelte die Probleme, die bei unorganisierter Software-Entwicklung auftraten, in dem es den Prozess der Software-Entwicklung in die

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 17

Phasen Analyse, Entwurf, Implementierung und Test aufteilte, die streng nacheinander zu durchlaufen sind. [Ben56] Die Bezeichnung Wasserfallmodell geht auf eine Publikation von Barry W. Boehm aus dem Jahr 1981 zur¨ uck und weist auf den sequentiellen, nicht-zyklischen Charakter des Modells hin. [Boe81, S.35ff] In der einfachsten Form des Wasserfallmodells hat jede Phase wohldefinierte Start-und Endpunkte mit eindeutigen Ergebnissen und lediglich einem Durchlauf. H¨ aufig wird noch eine f¨ unfte Phase angef¨ uhrt, die nicht mehr zum eigentlichen Entwicklungsprozess geh¨ ort, aber im Sinne einer Abbildung des realen Lebenszyklus der Software auch das Vorhandensein einer Einsatz- und Wartungsphase betont. (Vgl. Abbildung 2.1, Seite 17)

In der Phase Analyse und Definition wird eine Machbarkeitsstudie erstellt, eine Kosten/Nutzen Analyse erarbeitet und die spezifischen Produktanforderungen ermittelt. Diese Produktdefinition ist das Ergebnis dieser Phase und bildet eine Vertragsbasis zwischen Auftraggeber und Auftragnehmer. Der Leistungsumfang des Produkts wird hierin exakt festgehalten und auch die Endabnahme des Produkts erfolgt nach diesen Kriterien. Diese Phase besch¨ aftigt sich nahezu ausschließlich mit dem Außenverhalten der Software. Dem L¨ osen von etwaigen Kommunikationsproblemen zwischen Auftraggeber und Auftragnehmer kommt dabei eine besondere Bedeutung zu.

Auf Grundlage der Produktdefinition wird in der Phase Entwurf die innere Struktur der Software festgelegt. Es wird in mehreren Schritten eine Aufteilung in Einzelkomponenten vorgenommen, bis schließlich die Architektur der Software feststeht. Der Schwerpunkt dieser Phase liegt in der Spezifikation der Aufgaben der einzelnen Teilkomponenten und deren Zusammenwirken. Das Ergebnis dieser Phase ist die Softwarespezifikation, welche die Architektur pr¨ azisiert und beschreibt. Dieser Entwurf bestimmt sehr wesentlich die gesamte Qualit¨ at der Software.

Die Implementierung des Entwurfs in einer konkreten Programmiersprache steht im Mittelpunkt der dritten Phase, deren Ergebnis die Quelltexte der verschiedenen Komponenten ist. Diese sind zwar bereits einzeln getestet, ergeben zusammen aber noch kein funktionsf¨ ahiges Programm.

Nach den Einzeltests der Komponenten beginnt jetzt die Phase Test, deren Ergebnis nach einem positiv verlaufenen Integrationstest ein von beiden Parteien unterschriebenes Abnahmezertifikat ist. Das Ergebnis der letzten Phase Einsatz- und Wartung ist schließ-

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 18

lich das beim Auftraggeber installierte und voll lauff¨ ahige System. [PS94, S.36ff]

Die Vorteile einer solchen Vorgehensweise sind:

• Die Zerlegung des Entwicklungsprozesses in zeitlich aufeinander folgende Phasen mit strenger Aufgabentrennung.

• Die entstandenen Teile k¨ onnen unabh¨ angig behandelt und weiter aufgeteilt werden, somit ist ein erster Schritt der Komplexit¨ atsbew¨ altigung getan.

• Die Einf¨ uhrung der Phasen Test und Wartung stellt die Qualit¨ atskriterien Korrektheit und Wartbarkeit erstmals nach außen dar.

Im praktischen Einsatz erweist sich jedoch der streng sequentielle Charakter des Wasserfallmodells h¨ aufig als zu restriktiv. Die aus Managementsicht ideale Eigenschaft, dass alle Phasen einen definierten Anfang und ein definiertes Ende besitzen und sich zeitlich nicht ¨ uberlappen ist in großen Software-Projekten unrealistisch. [PS94, S.63ff]

Die Nachteile einer solchen Vorgehensweise sind:

• Software-Entwicklung ist kein wasserfallartiger Prozess. Jede Phase f¨ uhrt zu R¨ uckwirkungen auf fr¨ uhere Phasen.

• Das klassische Wasserfallmodell ber¨ ucksichtigt den Tatbestand der unpr¨ azisen oder fehlerhaften Produktdefinition nicht und geht realit¨ atsfremd von einer abgeschlossenen und korrekten Produktdefinition aus.

• Eine lauff¨ ahige Version der Software liegt erst am Ende der Entwicklung vor, somit werden Fehler aus fr¨ uhen Phasen erst sehr sp¨ at entdeckt, was deren Beseitigung aufwendig und teuer macht.

Daher wurde das klassische Wasserfallmodell als Reaktion auf die dargestellte Kritik auf verschiedene Weise modifiziert, aber auch grunds¨ atzlich andere Vorgehensmodelle entwickelt.

KAPITEL 2. KLASSISCHE SOFTWAREENTWICKLUNG 19

Die am weitesten verbreitete Modifikation des klassischen Wasserfallmodels ist das iterative Wasserfallmodell. (Vgl. Abbildung 2.2, Seite 18) Hier erm¨ oglichen R¨ uckkoppelungspfeile die R¨ uckkehr in vorangegangene Phasen. Eine R¨ uckkehr wird dann n¨ otig, wenn in einer sp¨ ateren Phase, d.h. bei einem h¨ oherem Detailierungsgrad, Fehler aus fr¨ uheren Phasen erkannt werden und somit zur Korrektur derselben zwingen.

Eine dem klassischen Wasserfallmodell sehr ¨ ahnliche Form findet sich schon im Report der ersten NATO-Konferenz aus dem Jahr 1968. Im Gegensatz zu den in sich geschlossenen Phasen des herk¨ ommlichen Wasserfallmodells ¨ uberlappen sich hier jedoch die Phasen Analyse, Design und Implementierung, sowie die Phasen Installation und Wartung. (Vgl. Abbildung 2.3, Seite 19)

2.3.2 Das V-Modell

Ein weiteres lineares Vorgehensmodell ist das sogenannte V-Modell. Es wurde 1981 von Barry W. Boehm vorgestellt und wie schon das Wasserfallmodell exisitiert auch das V-Modell in verschiedenen Auspr¨ agungen. Es erweitert das Wasserfallmodell um Qualit¨ atssicherungsmaßnahmen, die jeder Phase gegen¨ ubergestellt sind und die Ergebnisse der einzelnen Phasen ¨ uberpr¨ ufen. (Vgl. Abbildung 2.4, Seite 20)

Zus¨ atzlich wird zwischen den beiden großen Bereich Validierung und Verifikation unterschieden. Bei der Validierung eines Produkts wird sein Nutzen f¨ ur den Anwender gepr¨ uft (Wird das richtige Produkt entwickelt?), w¨ ahrend bei der Verifikation die Einhaltung der Spezifikation (Wird ein korrektes Produkt entwickelt?) ¨ uberpr¨ uft wird und die Validierung in der Analyse-Phase stattfindet und die Verifikation in den sp¨ ateren Phasen. [Boe81]