Die Software-Industrie steht heute mehr denn je vor der Tatsache, dass ein Großteil der beauftragten Projekte die geforderte Qualität nicht erreicht, Zeit- und Budgetvorgaben überschritten werden, oder im schlimmsten Fall das Projekt noch während 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 auf der Tagesordnung.
Der Übergang von den traditionellen Softwareentwicklungsmethoden hin zu leichtgewichtigen und agilen Vorgehensmodellen ist eine der Möglichkeiten 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ätzlich soll aus diesen Vertretern der Agilen Methoden ein geeignetes Vorgehensmodell für die Entwicklungsabteilung eines weltweit agierenden Unternehmens im Bereich der Telekommunikation und Systemintegration ermittelt werden. Hierfür werden die unternehmensinternen Anforderungen erarbeitet und daraus ein Kriterienkatalog abgeleitet, wobei besonderes Augenmerk auf die Umsetzungsmöglichkeiten in global verteilten Softwareentwicklungsprojekten gelegt wird.
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Gliederung
2 Klassische Softwareentwicklung
2.1 Die Softwarekrise
2.2 Software Engineering - Methodik als LOsungsansatz
2.3 Traditionelle Vorgehensmodelle
2.3.1 Das Phasen- oder Wasserfallmodell
2.3.2 Das V-Modell
2.3.3 Das Spiralmodell
2.4 Erfolgskriterien in Softwareprojekten
3 Agile Softwareentwicklung
3.1 Eine neue Bewegung entsteht
3.2 Das Agile Manifest
3.3 Die vier Agilen Werte
3.3.1 Individuen und Interaktionen
3.3.2 Funktionierende Software
3.3.3 Zusammenarbeit mit dem Kunden
3.3.4 Vorbereitung auf unbekannte Anderungen
3.4 Die zwolf Agilen Prinzipien
4 Anforderungen an einen Entwicklungsprozess
4.1 Einordnung der Agilen Vorgehensmodelle
4.2 Unternehmensspezifische Anforderungen
4.2.1 Unternehmensdarstellung
4.2.2 Projekteigenschaften und Arbeitsumfeld
4.3 Der Kriterienkatalog
4.3.1 Einordnung der Agilen Methodik
4.3.2 ProjektgroBe
4.3.3 Projektphasen
4.3.4 Gewichtung
4.3.5 Projektumwelt
5 Vergleich und Evaluierung
5.1 Adaptive Software Development (ASD)
5.1.1 Rollen und Verantwortlichkeiten
5.1.2 Prozessbeschreibung
5.1.3 Praktiken und Charakteristika
5.1.4 Zusammenfassung und Evaluierung
5.2 Crystal Methods
5.2.1 Rollendefinitionen
5.2.2 Prozessbeschreibung
5.2.3 Praktiken und Charakteristika
5.2.4 Zusammenfassung und Evaluierung
5.3 Scrum
5.3.1 Rollen und Verantwortlichkeiten
5.3.2 Prozessbeschreibung
5.3.3 Praktiken und Charakteristika
5.3.4 Zusammenfassung und Evaluierung
5.4 Dynamic Systems Development Method (DSDM)
5.4.1 Rollen und Verantwortlichkeiten
5.4.2 Prozessbeschreibung
5.4.3 Praktiken und Charakteristika
5.4.4 Zusammenfassung und Evaluierung
5.5 Extreme Programming (XP)
5.5.1 Rollen und Verantwortlichkeiten
5.5.2 Prozessbeschreibung
5.5.3 Praktiken und Charakteristika
5.5.4 Zusammenfassung und Evaluierung
5.6 Feature Driven Development (FDD)
5.6.1 Rollen und Verantwortlichkeiten
5.6.2 Prozessbeschreibung
5.6.3 Praktiken und Charakteristika
5.6.4 Zusammenfassung und Evaluierung
5.7 Zusammenfassung der Evaluierung
6 Agile Methoden und global verteilte Entwicklung
6.1 Eigenschaften gobal verteilter Entwicklung
6.2 Organisatorische Komplexitat in global verteilter Entwicklung
6.3 Agile Praktiken in global verteilter Entwicklung
6.4 Umsetzung in der BearingPoint INFONOVA GmbH
7 Zusammenfassung
7.1 Resiimee
7.2 Ergebnisse
7.3 Schlussbemerkung und Ausblick
Literaturverzeichnis
Bibliografische Beschreibung
Gotzenauer, Jurgen:
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 GroBteil der beauftragten Projekte die geforderte Qualitat nicht erreicht, Zeit- und Budgetvorgaben uberschritten werden, oder im schlimmsten Fall das Projekt noch wahrend der Entwicklung abgebrochen wird.
Die Anforderungen der Kunden an die beauftragte Software sind unklar, der Zeitraum zwischen Vertragsunterzeichnung und Auslieferung des Endprodukts wird zunehmend en- ger und die Entwicklung in verteilten Teams steht in Zeiten der Globalisierung an der Tagesordung.
Der Ubergang von den traditionellen Softwareentwicklungsmethoden hin zu leichtge- wichtigen und agilen Vorgehensmodellen ist eine der Moglichkeiten sich diesen Herausfor- derungen erfolgreich zu stellen.
Das Ziel der vorliegenden Arbeit ist es, die Eigenschaften und Schwerpunkte der ver- schiedenen Vertreter der Agilen Methoden zu erarbeiten und zu vergleichen. Zusaotzlich soll aus diesen Vertretern der Agilen Methoden ein geeignetes Vorgehensmodell fur die Ent- wicklungsabteilung eines weltweit agierenden Unternehmens im Bereich der Telekommuni- kation und Systemintegration ermittelt werden. Hierfur werden die unternehmensinternen Anforderungen erarbeitet und daraus ein Kriterienkatalog abgeleitet, wobei besonderes Augenmerk auf die Umsetzungsmoglichkeiten in global verteilten Softwareentwicklungs- projekten gelegt wird.
Danksagung
Ich mochte mich bei Herrn Prof. Dr.-Ing. Uwe Schneider von der Hochschule Mittweida herzlich fur seine Unterstutzung bei der Umsetzung der vorliegenden Arbeit bedanken.
Mein Dank gilt auch Herrn Dipl.-Ing. Mario Walder von der BearingPoint INFONOVA GmbH, der mir die Moglichkeit gab, die vorliegende Arbeit innerhalb meines beruflichen Umfelds umzusetzen und mir immer mit Rat und Tat zur Verfugung stand.
Weiters mochte ich mich bei Herrn Dr. Peter Hruschka von der Atlantic Systems Guild fur 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 fur mich da waren.
Jurgen Gdtzenauer Graz, am 20. Dezember 2005
Abbildungsverzeichnis
2.1 Das Phasen- oder Wasserfallmodell
2.2 Das erweiterte Phasen- oder Wasserfallmodell
2.3 Das NATO-Phasenmodell (Quelle: [NR68, S.13])
2.4 Das V-Modell
2.5 Das Spiralmodell (Quelle: wikipedia.org)
2.6 IT-Projekte von 1994 bis 2004 (Quelle: Standish Group Int.)
2.7 Rezept fur Projekterfolg (Quelle: Standish Group Int.)
4.1 Projekt-Entwicklung vs. Produktentwicklung
4.2 Struktur von Projektmitarbeitern
4.3 Struktur von verteilten Projektteams
5.1 ASD Prozessmodell
5.2 ASD Projektphasen (Quelle: [DK05, S.142]
5.3 Ubersicht der verschiedenen Crystal Methodiken
5.4 Crystal Projektphasen (Quelle: [DK05, S.149])
5.5 Das Scrum-Prozessmodell in der Grobubersicht
5.6 Der Scrum-Prozess im Uberblick
5.7 Beispielhafte Burndown-Chart
5.8 DSDM Prozessmodell
5.9 XP Prozessubersicht
5.10 Test Driven Development (TDD)
5.11 FDD Prozessubersicht
5.12 FDD Prozess-Schritte (Quelle: Kevin Morrison)
6.1 Abnahme der Kommunikationshaufigkeit (Quelle: [Kot01, S.56])
2.1 Kriterien fur den Projekterfolg im Jahr 1994
5.1 Evaluierungsmatrix fur Adaptive Software Development (ASD)
5.2 Evaluierungsmatrix fur Crystal Methods
5.3 Evaluierungsmatrix fur Scrum
5.4 Die MoSCoW-Regel
5.5 Evaluierungsmatrix fur Dynamic Systems Development Method (DSDM) .
5.6 Evaluierungsmatrix fur Extreme Programming (XP)
5.7 FDD Zertifizierungsstufen
5.8 Evaluierungsmatrix fur Feature Driven Development (FDD)
5.9 Evaluierungsmatrix - Gesamtubersicht
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Kapitel 1 Einleitung
In diesem Kapitel wird die grundlegende Motivation und Ausgangssituation der vorlie- genden Arbeit beschrieben, die Aufgabenstellungen und Zielsetzungen prazisiert und die Gliederung des Dokuments naher erlautert.
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 vollstandig automa- tisierten Informationsgesellschaft hat sich in den letzten Jahren bereits vollzogen. Neben den herkommlichen Computersystemen, die sich schon in fast jedem Haushalt und jedem Buro finden, steigt auch die Verbreitung von sogenannten Embedded-Systems1 rasant an. Man mochte meinen, dass durch diese ubiquitare 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 Halfte der 60er Jahre des 20. Jahrhunderts zeichnete sich in der Industrie eine Situation ab, die im Bereich der Software-Entwicklung zu dem Begriff Softwarekrise 2 fuhrte:
- Programme taten nicht das, was sie sollten, oder aber sie taten das, was sie tun sollten, nur fehlerhaft.
- Software kostete, wenn sie dberhaupt je fertig wurde, ein Vielfaches dessen, was zu Beginn geplant war.
- Termine wurden selten eingehalten und die nachtragliche Anderung von exisitieren- der Software war nahezu unmaoglich.
Die Software-Industrie war zu dieser Zeit nicht mehr in der Lage, mit den damals bekannten Techniken und Werkzeugen die Entwicklung groBer Programme zu beherrschen. [PS94, S.19ff]
In einer ersten Reaktion auf die Softwarekrise erkannte man, dass ein vollig neues und systematisches Vorgehen notwendig war, um von der damals vorherrschenden „Kunst des Programmierens“ den Schritt zu ingenieurmaBiger Softwareentwicklung zu gehen. Vor die- sem Hintergrund wurde 1968 auf einer NATO-Konferenz in Garmisch der Begriff Software Engineering3 gepragt. [NR68, S.19ff]
Man sah Parallelen zur Herstellung von Produkten im Bereich der Ingenieurwissen- schaften und wollte deren methodisches Vorgehen adaptieren. Der Entwicklungsprozess von Software sollte dadurch plan- und kalkulierbar werden. Die oben genannten Umstande und die steigende Komplexitat der Programme bei kommerziellen Softwareprojekten fuhr- ten zur Definition von sogenannten Vorgehensmodellen4 mit denen die Arbeitsablaufe in Softwareprojekten standardisiert werden sollten. Es etablierte sich ein erstes systemati- sches Modell, das sich groBtenteils am Vorbild von industriellen Fertigungsprozessen ori- entierte und den Softwareentwicklungsprozess in die vier groBen Phasen Analyse, Entwurf, Implementierung und Test gliederte, das sogenannte Phasen- oder Wasserfallmodell5
Inzwischen gibt es eine groBe Anzahl an wissenschaftlichen Untersuchungen zu der Fragestellung, wie man Software qualitativ hochwertig und zugleich fristgerecht und wirt- schaftlich okonomisch entwickeln konnte. Es wurden weitere Methoden und Vorgehens- modelle entwickelt, welche die Bereiche der Softwareentwicklung Schritt fur Schritt in ihre Teilprozesse zerlegen und umfangreiche Regelwerke zur effizienten Softwareentwicklung zur Verfugung stellen. Dennoch ist es auch heute noch haufig so, dass viele Softwareprojekte die Anforderungen, welche vom Kunden gefordert werden, nicht oder nur unzureichend erfullen, Termin- und Budgetvorgaben fiberschreiten und somit letztendlich die Projekt- ziele verfehlen. [Int95, S.3ff]
Es stellt sich zunehmend heraus, dass bei der Entwicklung von Software andere Ge- setzmaBigkeiten gelten, als in den traditionellen Ingenieursdisziplinen und Softwarepro- jekte 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, Qualitat und Umfang der geforderten Software schon zu Vertragsbeginn feststehen und das Projekt mit Hilfe eines definierten Pro- jektplans abgewickelt werden. Doch sind diese Anforderungen an ein Softwareprodukt langst nicht so stabil und weisen haufig Konflikte und Zielkonkurrenzen auf. Niedrigst- preise widersprechen umfangreicher Funktionalitaat und sportlich“ definierte Zeitrahmen konkurrieren naturgemaaB mit den hohen Qualitaatsanspruachen der meisten Kunden.
Dynamische Projekte an der Spitze von Markt und Technologie entwickeln ihre kon- kreten Anforderungen oft sogar erst waahrend des eigentlichen Projektverlaufs.
Die traditionellen Vorgehensmodelle mit ihren restriktiven und schwergewichtigen Re- gelwerken stofien hier sehr schnell an ihre Grenzen, da auf standige Anderung gar nicht, oder nur sehr eingeschrankt, reagiert werden kann. Die Diskussionen daruber, wie am besten auf diese Umstande in der Softwareentwicklung reagiert werden kann und welches Vorgehensmodell dafur 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 revolutionaren Vorgehensmodelle ist die vergleichsweise ge- ringe Anzahl und der schlichte Charakter ihrer Regeln, daher werden sie als leichtgewich- tige oder agile6 Prozesse bezeichnet.
Die Erfinder und Initiatoren der Agilen Methoden haben erkannt, dass in grofien kom- merziellen 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.7 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 erwahnten kritischen Punkten in der Softwareentwicklung gesellt sich in Zeiten der Globalisierung und des Outsourcings der Umstand, dass grofie kommerzielle Softwareprojekte langst nicht mehr nur von Teams an einem Standort entwickelt werden, sondern die Projektmitglieder haufig geografisch verteilt und durch Zeitzonen getrennt an ein und demselben Softwareprojekt arbeiten mussen.
Der Autor der vorliegenden Arbeit ist seit Jahren beruflich in den Bereichen Software Quality Management und Software Engineering in der Entwicklungsabteilung eines welt- weit agierenden Unternehmens im Bereich der Telekommunikation und Systemintegration tatig und tagtaglich mit den Herausforderungen globaler Softwareentwicklung in verteilten Teams konfrontiert.
Das Ziel der vorliegenden Arbeit ist es, die verschiedenen Ansatze und Vertreter der Agilen Methoden in der Softwareentwicklung allgemein zu vergleichen und in Hinblick auf die unternehmensinternen Anforderungen zu evaluieren.
Hierfuar werden die unternehmensinternen Anforderungen mittels Interviews, Frageboagen und Projektreviews erarbeitet und daraus ein Kriterienkatalog abgeleitet. Besonderes Au- genmerk wird dabei auf die Umsetzungsmaoglichkeiten in global verteilten Entwicklungs- teams gelegt. Anhand der gewonnenen Ergebnisse soll ein far das Unternehmen geeignetes Vorgehensmodell vorgeschlagen werden. Wenn die unternehmensinternen Anforderungen nicht von einer einzelnen Agilen Methode abgedeckt werden, soll untersucht werden, obeine Moglichkeit 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 Softwareent- wicklungsprozess gestellt?8
- Wie unterscheiden sich die aktuellen Vertreter der sogenannten Agilen Methoden hinsichtlich ihrer Praktiken und ihrer Umsetzung?
- Erfullt eine der Agilen Methoden die Anforderungen, oder konnen Teilbereiche aus verschiedenen Agilen Vorgehensmodellen hierfur kombiniert oder erweitert werden?
1.3 Gliederung
Im Folgenden wird auf die Gliederung und den inhaltlichen Aufbau der vorliegenden Arbeit eingegangen. Es wird erlautert, wie zur Beantwortung der Fragestellungen aus dem vori- gen 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, beschaftigt sich der erste Teil der Arbeit mit der Klassifizierung von Entwicklungsprozessen im Allgemeinen.
In Kapitel 2 - „Klassische Softwareentwicklung“, Seite 13, wird die historische Ent- wicklung von Softwareprojekten anhand der Softwarekrise und des daraus resultierenden Begriffs des Software Engineerings beschrieben, sowie die daraus abgeleiteten traditionellen Vorgehensmodelle erlautert. Als wichtigste Vertreter werden hierbei das Phasen- oder Wasserfallmodell, das V-Modell und das Spiralmodell angefuhrt9
In Kapitel 3 - „Agile Softwareentwicklung“, Seite 25, wird die Geschichte der Agilen Bewegung beschrieben und erlautert, welche Ursachen und Probleme in der traditionellen Softwareentwicklung uberhaupt zur Entstehung der Agilen Bewegung gefuhrt haben und welche Losungsansatze die Agile Bewegung hinsichtlich dieser Probleme empfiehlt.
Da heute eine grofie Anzahl an unterschiedlichen Entwicklungsprozessen zur Verfugung steht, stellt sich die Frage, welche Faktoren einen Einfluss auf die Abwicklung von Softwa- reprojekten haben und welche Kriterien bei der Auswahl eines Vorgehensmodells relevant sind.
Das Kapitel 4 - „Anforderungen an einen Entwicklungsprozess“, Seite 31, beschaftigt sich daher mit den Anforderungen an einen Agilen Softwareentwicklungsprozess im Allge- meinen und den firmeninternen Auswahlkriterien anhand eines im Unternehmen erarbei- teten Kriterienkatalogs im Speziellen.
Die Charakteristika der sechs aktuell angewandten und dokumentierten Agilen Metho- den werden in Kapitel 5 - „Vergleich und Evaluierung“, Seite 39, dargestellt.
Um einen Vergleich zu erleichtern werden die verschiedenen Agilen Methoden immer nach dem selben Schema beschrieben: Einleitung, Rollen und Verantwortlichkeiten, Pro- zessbeschreibung, Praktiken und Charakteristika sowie Zusammenfassung und Evaluierung.
In Kapitel 6 - „Agile Methoden und global verteilte Softwareprojekte“, Seite 81, wird erlautert, welche Anpassungen und Erweiterungen an den bestehenden Agilen Methoden vorzunehmen sind, um sie erfolgreich in global verteilten Softwareprojekten anwenden zu konnen, und welche Praktiken davon bereits in der BearingPoint INFONOVA GmbH zur Anwendung kommen.
Das Kapitel 7 - „Zusammenfassung“, Seite 88, schlieBt die Arbeit durch eine zusam- menfassende Darstellung der Ergebnisse und Hinweise auf eventuelle Erweiterungs- und Umsetzungsmoaglichkeiten ab.
Kapitel 2 2.Klassische Softwareentwicklung
In diesem Kapitel wird dargelegt, welche Probleme und Herausforderungen in den er- sten Jahrzehnten der kommerziellen Software-Entwicklung auftraten und welche Umstande dann schlieBlich zur Entwicklung der ersten fundierten Vorgehensmodelle gefuhrt haben.
Im ersten Abschnitt wird kurz das Wesen und der Hintergrund der sogenannten Soft- warekrise erlautert und im zweiten Abschnitt auf den Ursprung des Begriffs SoftwareEngineering und dessen Rolle als Antwort auf die Softwarekrise eingegangen. Die wich- tigsten Vertreter der traditionellen Vorgehensmodelle und deren wesentlichen Merkmale werden im dritten Abschnitt angefuhrt. Dass Software-Projekte trotz dieses wesentlichen Umdenkens nach wie vor nicht wie Produktentwicklungen in anderen Ingenieursdiszipli- nen abgewickelt werden konnen und selbst im Jahr 1994 noch 31% aller Software-Projekte vor der Fertigstellung abgebrochen wurden10, 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 Universitaten damit beschaftigten:
- Die entwickelte Software war verhaltnismaBig klein und uberschaubar.
- Die implementierten Algorithmen hatten im Vergleich zu spaateren Entwicklungen eine sehr geringe Komplexitat.
- Die Entwickler der Software waren in den meisten Fallen auch gleichzeitig die Anwen- der, dadurch kam es in der Regel nicht zu Verstandigungsschwierigkeiten zwischen Auftraggebern und Auftragnehmern.
Dariiber hinaus war die Hardware zu dieser Zeit noch nicht sehr leistungsfahig, was dazu fuhrte, dass das Scheitern eines Projektes zu dieser Zeit meistens auf eine fehlerhafte Hardware zurackzufiihren war. Denn entweder war die Hardware durch Rechenfehler der Ingenieure flasch definiert, oder einfach zu fehleranfallig, bzw. zu langsam. Dass aus der[10]
Software groBere Probleme entstehen konnten, glaubte man zu dieser Zeit nicht. [DK05, S.16]
Nur zehn Jahre spater begannen jedoch Computer die Industrie im groBen 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.11 Stattdessen wurde es immer schwieriger, adequate Software zu entwickeln.
Wahrend zuvor bei der Entwicklung von Programmen die Korrektheit und Effizienz der Software im Vordergrund standen, kamen nun durch die enorme Zunahme von Komplexitat und Umfang vollig neue Problemstellungen hinzu:
- GroBe Aufgaben mussten sinnvoll in kleinere Programmteile (Module) zerlegt wer- den.
- Schnittstellen zu anderen Programmen mussten definiert werden.
- Die Software musste sicherer, zuverlassiger und vor allem wartbar sein.
- Der enorme Fortschritt stellte die Industrie daruber hinaus vor vollig neue Probleme im Bereich der Organisation.
Die bisherigen Arbeitsablaufe der im IT-Umfeld beschaftigten Mitarbeiter passten Auf- grund dieser Konflikte mit der Zeit immer weniger zu den neuen Anforderungen. Der Pro- duktionsprozess wandelte sich von einer „Nebentatigkeit“ zu einem eigenstandigen und ungemein komplexen Ablauf und wurde dadurch mit den damaligen Mitteln immer we- niger plan- und beherrschbar. Der Verlust der Kontrolle brachte wiederum erhebliche Risiken mit sich, so dass Kosten-, Zeit- und Qualitatsziele aufgrund der gestiegenen Komplexitat immer weniger oft eingehalten werden konnten. 1965 war es schlieBlich so weit, dass man von der sogenannten Softwarekrise zu sprechen begann. [DK05, S.16f]
Eine der ersten gesicherten Erwaahnungen dieser Bezeichnung findet sich in Edsger W. Dijkstras Dankesrede zum Turing-Preis13 die er 1972 hielt und welche im Communications of the ACM“ Magazin verbffentlicht 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]
In der deutschen Ubersetzung:
„[Die Hauptursache fur die Softwarekrise liegt darin begrundet,] dass die Maschinen um einige Grofienordnungen machtiger geworden sind! Um es umgangssprachlich aus- zudrucken: Solange es keine Maschinen gab, stellte die Programmierung kein Problem dar; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem klei- neren Problem und nun da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem. “[14]
2.2 Software Engineering - Methodik als Losungsansatz
Als Reaktion auf die Softwarekrise versuchte man, sich verstarkt an den Arbeitsweisen und Ablaufen der Ingenieursdisziplinen zu orientieren,um dadurch eine strukturierte, weit vorausplanende, geradlininge und theoretisch fundierte Arbeitsweise zu etablieren, welche die vorliegenden Probleme losen sollte. [DK05, S.17]
Vor diesem Hintergrund wurde der Begriff Software Engineering im Jahr 1968 in Gar- misch Partenkirchen auf einer vom Wissenschaftskomitee der NATO einberufenen Konfe- renz zunachst als Schlagwort eingefuhrt.15
Der Softwareentwicklungsprozess sollte plan- und kalkulierbarer werden. Prazise Vor- gaben, die in Abstimmung mit dem Auftraggeber getroffen werden, sowie eine bessere Qualitatskontrolle sollten hochwertige Produkte garantieren und somit den Auftraggeber zufrieden stellen. Es setzte sich auch die Uberzeugung durch, dass neue Management- methoden zur Organisation grofier Projekte eingefuhrt werden mussten, um eine rigorose Kontrolle der Kosten und Termine zu gewahrleisten und die Organisation grofier Entwick- lungsteams in den Griff zu bekommen. [PS94, S.36]
Um dies zu erreichen, diskutierten auf der Konferenz mehr als funfzig Wissenschaftler von Universitaten aus elf verschiedenen Landern 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 gegenwaartigen Probleme im Bereich der kommerziellen Software-Entwicklung werfen. Es sollten auch moagliche Techniken, Methoden und Entwicklungen, die zur Losung der Probleme ftihren kdnnten, besprochen werden. Man erwartete, dass die Konferenz Erfordernisse, Mangel und Trends aufzeigen wtirde und dass diese als konkrete Wegweiser ftir die Hersteller und die Benutzer von Computern dienen konnten. [BPK00, S.9]
Jedoch waren sich die Teilnehmer der Konferenz in vielerlei Hinsicht nicht einig und wussten auch nicht, wie sie die Probleme gemeinsam ldsen sollten. Daher wurden von den verschiedenen teilnehmenden Personen Arbeitspapiere ausgearbeitet und kommentiert.
Vor allem Edsger W. Dijkstra kritisierte die von ihm behauptete Einstellung vieler Konferenzteilnehmer:
- Wir diirfen unsere Vorgehensweise nicht andern.
- Wir diirfen unsere Programmierhilfsmittel nicht andern.
- Wir diirfen unsere Hardware nicht andern.
- Wir diirfen unsere Aufgaben nicht andern.
- Wir diirfen die organisatorischen Ablaufe nicht andern, in denen die Arbeiten erledigt werden mussen.
„ Wir sollen unter diesen funf unabanderlichen Grenzbedingungen versuchen, Verbes- serungen zu erreichen? Dies ist aufierst lacherlich!“16
Dijkstra glaubte, dass eine grtindliche Anderung der Entwicklungsmethoden auf allen Ebenen die notwendige Losung aller Probleme der Software-Krise sei. Er hob hervor, dass man die existierende Arbeitsweise grundlegend &ndern mtisse. Die Hardware und die Hilfsmittel hatten sich ge&ndert, die Aufgaben seien komplexer geworden, aber die Entwicklungsmethoden und die Organisationsstrukturen und Methoden eines Software- projekts h&tten sich nicht der Entwicklung der letzten Jahre angepasst. [BPK00, S.12f]
In Folge wurden viele wichtige Begriffe der Softwareindustrie neu definiert und man ver- suchte, generelle Richtlinien fiir die Entwicklung leistungsfahiger Software zu entwickeln. Nur ein Jahr spater wurde eine Folgekonferenz in Rom abgehalten, auf der die in Gar- misch angesprochenen Inhalte nochmals tiberarbeitet wurden und speziell auf die Themen Software-Spezifikation, -Qualit&t und -Flexibilit&t eingegangen wurde. Auch die Korrekt- heit und Portabilitat von Software wurde erdrtert. [BR69, S.5ff]
2.3 Traditionelle Vorgehensmodelle
Als Ergebnis der NATO-Konferenzen stiefi die Idee einer ingenieurm&Bigen Vorgehensweise bei der Entwicklung von Software besonders auf Managementebene der grofien Unterneh- men auf breite Zustimmung. Es etablierten sich die ersten systematischen Modelle, deren wichtigste Vertreter in den folgenden Abschnitten stellvertretend fiir die klassischen Vorgehensmodelle erlautert 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 Vor- bild industrieller Fertigungsprozesse und behandelte die Probleme, die bei unorganisierter Software-Entwicklung auftraten, in dem es den Prozess der Software-Entwicklung in die
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 zuriick 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. Haufig wird noch eine fiinfte Phase angefuhrt, die nicht mehr zum eigentlichen Entwicklungsprozess gehort, aber im Sinne einer Abbildung des realen Lebenszyklus der Software auch das Vorhandensein einer Einsatz- und Wartungsphase betont. (Vgl. Abbildung 2.1, Seite 17)
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.1: Das Phasen- oder Wasserfallmodell
In der Phase Analyse und Definition wird eine Machbarkeitsstudie erstellt, eine Ko- sten/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 beschaftigt sich nahezu ausschlieBlich mit dem AuBenverhalten der Software. Dem Losen von etwaigen Kommunikationsproblemen zwischen Auftraggeber und Auftragneh- mer 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 Einzelkomponen- ten vorgenommen, bis schlieBlich 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 prazisiert und beschreibt. Dieser Entwurf bestimmt sehr wesentlich die gesamte Qualitat der Software.
Die Implementierung des Entwurfs in einer konkreten Programmiersprache steht im Mittelpunkt der dritten Phase, deren Ergebnis die Quelltexte der verschiedenen Kompo- nenten ist. Diese sind zwar bereits einzeln getestet, ergeben zusammen aber noch kein funktionsfaahiges 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 schlieB- lich das beim Auftraggeber installierte und voll lauffahige 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 kannen unabhangig behandelt und weiter aufgeteilt werden, somit ist ein erster Schritt der Komplexitatsbewaltigung getan.
- Die EinfUhrung der Phasen Test und Wartung stellt die Qualitatskriterien Korrekt- heit und Wartbarkeit erstmals nach auBen dar.
Im praktischen Einsatz erweist sich jedoch der streng sequentielle Charakter des Was- serfallmodells haufig 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 groBen Software-Projekten unrealistisch. [PS94, S.63ff]
Die Nachteile einer solchen Vorgehensweise sind:
- Software-Entwicklung ist kein wasserfallartiger Prozess. Jede Phase fUhrt zu RUck- wirkungen auf fruahere Phasen.
- Das klassische Wasserfallmodell berUcksichtigt den Tatbestand der unprUzisen oder fehlerhaften Produktdefinition nicht und geht realitutsfremd von einer abgeschlosse- nen und korrekten Produktdefinition aus.
- Eine lauffahige Version der Software liegt erst am Ende der Entwicklung vor, somit werden Fehler aus frUhen Phasen erst sehr spat entdeckt, was deren Beseitigung aufwendig und teuer macht.
Daher wurde das klassische Wasserfallmodell als Reaktion auf die dargestellte Kri- tik auf verschiedene Weise modifiziert, aber auch grundsatzlich andere Vorgehensmodelle entwickelt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.2: Das erweiterte Phasen- oder Wasserfallmodell
Die am weitesten verbreitete Modifikation des klassischen Wasserfallmodels ist das iterative Wasserfallmodell. (Vgl. Abbildung 2.2, Seite 18) Hier ermoglichen Ruckkoppe- lungspfeile die Ruckkehr in vorangegangene Phasen. Eine Ruckkehr wird dann notig, wenn in einer spateren Phase, d.h. bei einem hoherem Detailierungsgrad, Fehler aus fruheren 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 geschlosse- nen Phasen des herkommlichen Wasserfallmodells uberlappen sich hier jedoch die Phasen Analyse, Design und Implementierung, sowie die Phasen Installation und Wartung. (Vgl. Abbildung 2.3, Seite 19)
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.3: Das NATO-Phasenmodell (Quelle: [NR68, S.13])
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&gungen. Es erweitert das Wasserfallmodell um Qualit&ts- sicherungsmaBnahmen, die jeder Phase gegenubergestellt sind und die Ergebnisse der ein- zelnen Phasen uberprufen. (Vgl. Abbildung 2.4, Seite 20)
Zus&tzlich wird zwischen den beiden groBen Bereich Validierung und Verifikation un- terschieden. Bei der Validierung eines Produkts wird sein Nutzen fur den Anwender gepruft (Wird das richtige Produkt entwickelt?), w&hrend bei der Verifikation die Einhal- tung der Spezifikation (Wird ein korrektes Produkt entwickelt?) uberpruft wird und die Validierung in der Analyse-Phase stattfindet und die Verifikation in den sp&teren Phasen. [Boe81]
Das V-Modell wurde von der Deutschen Bundeswehr ubernommen, speziell fur deutsche Behorden ausgearbeitet und 1992 als Vorgehensmodell im Bundesanzeiger verOffent- licht. Neue Softwareentwicklungsansatze machten jedoch eine tjberarbeitung des V-Modells notwendig. Als Ergebnis wurde im Juni 1997 das V-Modell ’97 vorgestellt, welches fur jegliche Software-Entwicklung in der Bundesverwaltung als Standard empfohlen wurde.16
Das V-Modell ’97 wiederum wurde im Zuge neuer Erkenntnisse im Februar 2005 durch die aktuell gultige Version 1.0 des V-Modell XT ersetzt. Die gravierendste Anderung liegt hierbei in der starkeren Orientierung in Richtung agiler und inkrementeller Ansatze. Das V-Modell XT gibt keinerlei Vorschriften uber die zeitliche Abfolge der einzelnen Phasen vor, sondern stellt die erzeugten Produkte in den Mittelpunkt.17
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.4: Das V-Modell
2.3.3 Das Spiralmodell
Das Spiralmodell wurde 1986 von Barry W. Boehm vorgestellt und erlaubt die freie problembezogene Kombination aller bereits existierender Ansatze unter st&ndiger Kon- trolle des Managements. Das Spiralmodell fasst den Entwicklungsprozess im SoftwareEngineering im Gegensatz zu den bisher vorgestellten Vorgehensmodellen als iterativen[18] Prozess auf und beschreibt als eines der ersten Vorgehensmodelle den sogenannten iterativ- inkrementellen Entwicklungsprozess von Software.
Das Modell wird durch eine Spirale visualisiert, die, ausgehend vom Ursprung eines rechtwinkligen Koordinatensystems, im Uhrzeigersinn eine immer grofier werdende Fl&che umschlieBt. Jeder Umlauf entspricht dem Durchlaufen eines Entwicklungszyklus in den Phasen des Wasserfallmodels.
Ublicherweise werden den vier Quadranten des Koordinatensystems folgende Phasen zugeordnet:
- Festlegen von Zielen, Beurteilen eventueller Alternativen und Rahmenbedingungen
- Evaluieren der Alternativen, Erkennen und Reduzieren von Risiken
- Realisieren und Uberprufen des Zwischenprodukts
- Planen des nachsten Zyklus
Am Ende jedes Zyklus steht ein Review, in dem der Projektfortschritt bewertet und verabschiedet wird. [Boe86] (Vgl. Abbildung 2.5, Seite 21)
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.5: Das Spiralmodell (Quelle: wikipedia.org)
Typisch fur das Spiralmodell ist die starke Betonung der Risikoanalyse, die einem Scheitern des Projekts fruhzeitig vorbeugen, bzw. ein aussichtsloses Projekt moglichst schnell beenden soll. Die von der Spirale eingeschlossene, grofier werdene Flache soll den erreichten Fertigstellungsgrad symbolisieren. Problematisch ist allerdings, dass sie nicht den fur jede Iteration benotigten Zeitaufwand visualisiert. Die geplante Projektdauer kann bei Anwendung des Spiralmodells nur eingehalten werden, wenn fur jede Iteration verbindlich terminierte Meilensteine gesetzt sind. [Boe94]
2.4 Erfolgskriterien in Softwareprojekten
Ein erfolgreiches Softwareprojekt zeichnet sich dadurch aus, dass es im geplanten Zeit- rahmen, innerhalb der definierten Kosten und in der gewunschten Qualitat fertig gestellt wird.
Doch wie schon im Abschnitt 2.1, Seite 13 dieses Kapitels erlautert, war das zuneh- mende Scheitern von Software-Projekten bereits in den 60er und 70er Jahren des 20. Jahrhunderts erkannt worden. Als Antwort auf diese sogenannte Softwarekrise etablierten sich die ersten Vorgehensmodelle um damit den Softwareentwicklungsprozess plan- und kalkulierbarer zu machen und somit das Scheitern von Software-Projekten zu verhindern.
Im Jahr 1995 veroffentlichte die international anerkannte Standish Group[19] eine um- fassende Untersuchung, die im Jahr zuvor durchgefuhrt wurde. [Int95]
Die Analyse von 8.380 Projekten aus 365 Firmen im IT-Bereich ergab, dass 1994
- 31% der untersuchten Projekte gescheitert sind,
- 53% der untersuchten Projekte Zeit- und/oder Budgetvorgaben nicht eingehalten haben, und nur
- 16% der untersuchten Projekte innerhalb der vorgegebenen Zeit- und Budgetvorga- ben abgeschlossen wurden.
Als Folge der Untersuchung wurde anhand von Fallstudien analysiert, welche Kriterien die Erfolgswahrscheinlichkeit von Software-Projekten signifikant erhohen und eine „Top- Ten“ Liste dieser Kriterien veroffentlicht. (Vgl. Tabelle 2.1, Seite 22)
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.1: Kriterien fur den Projekterfolg im Jahr 1994
Seit 1994 fuhrt die Standish Group diese Analysen permanent durch und veroffentlicht die Untersuchungsergebnisse[20] in Form des zweijahrlich erscheinenden Chaos Report.
Der Chaos Report ordnet IT-Projekte in drei Kategorien ein:
1. Succeeded - Das Projekt wurde innerhalb der vorgegebenen Zeit und innerhalb des geplanten Budgets abeschlossen. Das Projektergebnis ist im Einsatz und erfullt alle Anforderungen.
2. Challenged - Das Projekt ist abgeschlossen und das Projektergebnis im Einsatz. Jedoch wurden Zeit, Budget oder Anforderungen nicht im vorgegebenen Umfang erreicht.
3. Failed - Das Projekt wurde vorzeitig abgebrochen oder das Projektergebnis nie ein- gesetzt.
Vergleicht man nun die Untersuchungsergebnisse der letzten zehn Jahre, so stellt man fest, dass sich die Anzahl der erfolgreichen Projekte von 16% im Jahr 1994 auf 29% im Jahr 2004 fast verdoppelt hat, und sich im selben Zeitraum die Anzahl der fehlgeschlagenen Projekte von 31% auf 18% fast halbiert hat. (Vgl. Abbildung 2.6, Seite 23)
Die Anzahl der Projekte, bei denen Zeit, Budget oder Anforderungen nicht im vorgegebenen Umfang erreicht wurden, stellt jedoch mit einem arithmetischen Mittel von 47,5% im Untersuchungszeitraum nahe zu die Halfte der Gesamtanzahl an untersuchten Projekten dar.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.6: IT-Projekte von 1994 bis 2004 (Quelle: Standish Group Int.)
Da sich die in den Projekten angewandten Vorgehensmodelle gravierend auf deren Erfolg auswirken, lasst dieses Ergebnis den Schluss zu, dass die in den Projekten des Unteruchungszeitraums angewandten, meist traditionellen Vorgehensmodelle nicht dazu in der Lage waren, den Erfolg der Projekte entscheidend zu beeinflussen.
In dieser Hinsicht interessant ist die Tatsache, dass die Standish Group in der ak- tuellen Version des Chaos Report von 2004 die Anwendung einer agilen und iterativen Vorgehensweise in ihren Top-Ten Erfolgsfaktoren explizit an sechster Stelle gelistet hat.[21]
Schon 2001 hat die Standish Group die Anwendung eines iterativen Entwicklungspro- zesses als Teil des „Rezepts fur Projekterfolg“ erwahnt: [Int01, S.12]
„[...]This calls for reducing requirements to the bare minimum, providing constant communication systems and coupling those with a standard infrastructure. Mix these indgre- dients with good stakeholders, an iterative development process, project management tools and adherence to key roles, and success is pracitcally in the oven.[...]“
In der deutschen Ubersetzung:
,,[...]Dies schreit nach bis auf das absolute Minimum reduzierten Anforderungen, dem zur Verfugungstellen von konstanten Kommunikationssystemen und der Kopplung dieser mit einer Standard-Infrastruktur. Mixe diese Zutaten mit guten Projektbeteiligten, einem iterativen Entwicklungsprozess, Projektmanagement-Werkzeugen und dem Einhalten von Schlusselrollen und der Erfolg ist praktisch schon im Ofen.[...]“
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2.7: Rezept fur Projekterfolg (Quelle: Standish Group Int.)
Abbildung in dieser Leseprobe nicht enthalten
Kapitel 3 Agile Softwareentwicklung
In diesem Kapitel wird kurz auf die Vorgeschichte der Agilen Bewegung eingegangen, danach erklart, wie es zum Agilen Manifest kam und schlieBlich die einzelnen Teibereiche des Agilen Manifests naher erlautert.
3.1 Eine neue Bewegung entsteht
Wie die Untersuchungen der Standish Group eindrucksvoll belegen, blieb der erhoffte Er- folg die Software Krise in den Griff zu bekommen, mit AuBnahme der Etablierung des Begriffes Software Engineering, bis heute aus. Die letzten Jahre haben aber gezeigt, dass der Ansatz, Software nach den Regeln der traditionellen Ingenieursdisziplinen zu ent- wickeln dazu fuhrte, dass zwar zahlreiche theoretisch sehr ausgefeilte Verfahren entwickelt wurden, diese aber praktisch nur sehr bedingt einsetzbar sind. Dies liegt vor allem an ihrer Schwergewichtigkeit [22] und der hieraus resultierenden Inflexibilitat. [DK05, S.17]
Eine entscheidende Rolle fur das Ausbleiben des Erfolges spielt der nur selten ver- standene Aspekt, dass die Vorgehensweisen der traditionellen Ingenieursdisziplinen nicht ohne weiteres auf die Entwicklung von Software ubertragen werden kann. Hierzu sind die Ausgangspositionen beider Disziplinen zu unterschiedlich. Waahrend bei den traditionellen Ingenieursdisziplinen im Normalfall alle Informationen bereits zu Projektbeginn vorhan- den sind und somit die weitere Vorgehensweise sehr gut geplant werden kann, kommt bei Software-Projekten eine groBe Menge wichtiger Informationen erst waahrend des lau- fenden Projekts zum Vorschein. Daher ist es bei Software-Projekten nahezu unmoglich genau vorauszuplanen und nachtragliche Anderungen an zuvor festgelegten Planen werden unvermeidbar. [DK05, S.18]
Die Vorgehensweise der traditionellen Ingenieursdisziplinen muss zwar auch in Software Projekten gewuardigt werden, aber auch die speziellen Randbedingungen der Software- Entwicklung mussen in hinreichendem MaBe berucksichtigt werden.
Einige Kritikpunkte an den traditionellen Vorgehensweisen sind: [DK05, S.19f]
- Selbst mit sehr ausgereifter Planung kann nur selten qualitativ hochwertige Software entwickelt werden, da sich permanent neue Anforderungen ergeben.
- Ein GroBteil der Aktivitaten geht am eigentlichen Ziel - namlich qualitativ gute Software zu entwickeln - vorbei, statt dessen wird Dokumentation zu bestimmten Software-Versionen geschrieben, die spater nie zum Einsatz kommt.
- Bei einer hohen Anzahl von vorgeschrieben Prozessen wird nicht auf den Faktor Mensch geachtet.
- Software wird erst viel zu spaat im Entwicklungs-Prozess getestet.
- Zahlreiche Vorgaange sind nicht transparent genug, um zu erkennen, was wirklich schlecht lauft.
Zu Beginn der 90er Jahre des 20. Jahrhunderts entstanden unabhangig voneinander verschiedene Vorgehensmodelle, die als sogenannte leichtgewichtige Methoden bezeichnet wurden, da sie einen Gegensatz zu den bisher ublichen schwergewichtigen Vorgehens- modellen, in denen z.B. vieles muhselig in zahlreichen Dokumenten ofter als notwendig dokumentiert wird, darstellen. [DK05, S.20f]
3.2 Das Agile Manifest
Von 11. bis 13. Februar 2001 trafen sich 17 Vertreter[23] der leichtgewichtigen Methoden in einem Hotel in Utah/USA um uber die verschiedenen leichtgewichtigen Vorgehensmodelle zu diskutieren und anschlieBend eine Aussage daruber treffen zu konnen, ob sich eine weitere Zusammenarbeit lohnt oder nicht.
Die meisten Anwesenden haten keine all zu hohen, aber teilweise sehr unterschiedliche Erwartungen und gingen davon aus, dass bei diesem Treffen nicht viel mehr geschehen wurde, als Kontakte zu knupfen.
Jedoch bemerkte man recht schnell, dass die leichtgewichtigen Vorgehensmodelle starke Gemeinsamkeiten haben und auch aus sehr ahnlichen Grunden entstanden waren. Allen voran der Grund, dass durch permanente Anpassung an neue Situationen die bisherigen Vorgehensmodelle nur bedingt angewendet werden kbnnen. [DK05, S.21]
Auf Grund der Gemeinsamkeiten entstand schlieBlich der Wunsch, dem Unmut ge- genuber den vorherrschenden Methodiken Ausdruck zu verleihen und gleichzeitig neue Wege aufzuzeigen, wie Software effizienter entwickelt werden kann. Man beschloss schlieBlich, ein Manifest zu verabschieden, dass als „Aufschrei“ gegen die Software-Industrie gedacht war und gleichzeitig als Mahnmal gegen „schlechte“ Software gelten sollte.
Gleichzeitig wollte man den Begriff leichtgewichtig durch eine Bezeichnung ersetzen, die den Hintergrund der neuen Methoden besser verdeutlichen sollte. Nach mehreren Vorschl&gen einigte man sich schlieBlich auf den Begriff agil, da dieser recht gut die An- passungsfahigkeit und Reaktion auf unvermeidbare Anderung ausdruckt. [DK05, S.22]
„Agilitat ist die Fahigkeit einer Organisation prompt und angemessen auf Anderungen in der Umgebung sowie auf die BedUrfnisse, die durch diese Anderungen entstehen einzu- gehen. Ein agiler Prozess ist einer, der diese Anpassungsfahigkeit bereitwillig begrufit und unterstutzt. “ [Kru01]
Aus leichtgewichtig wurde agil und die Teilnehmer begannen iiber den genauen Inhalt des Manifests zu diskutieren. Es stellte sich heraus, dass die Teilnehmer zwar einigen grundlegenden Aspekten zustimmten, aber die Meinungen auseinander gingen, sobald es um konkrete Wege ging, bestimmte Probleme zu lOsen.
Daher einigte man sich darauf, in dem geplanten Manifest lediglich vier Werte zu nennen, die zusatzlich durch zwOlf Prinzipien unterstutzt werden sollten. Auf konkrete Praktiken, die helfen sollen diese Prinzipien umzusetzen, verzichtete man ganz bewusst und uberlieB dies den einzelnen Methodiken. Das Agile Manifest[24] war geboren.
Das Agile Manifest in seiner deutschen Ubersetzung: [Coc03, S.281]
„ Wir entdecken bessere Wege, Software zu entwickeln, in dem wir es selbst tun und anderen dabei helfen es zu tun. Durch diese Arbeit haben wir folgendes zu schatzen gelernt:
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
- Sich auf unbekannte Anderungen einzustellen, ist wichtiger als einem Plan zu folgen.
Wir schatzen auf Grund unserer Erfahrungen die Punkte auf der rechten Seite, aber wir bewerten die Punkte auf der linken Seite hoher. “
Im Einleitungsteil bringen die Verfasser zum Ausdruck, dass sie bisher ausreichend Erfahrung in der Software-Entwicklung gesammelt haben, und somit auch wirklich be- urteilen konnen, worauf es bei der Entwicklung von Software ankommt. Sie distanzieren sich damit klar von Menschen die ohne ausreichende Erfahrung lediglich Regeln fur andere vorschreiben. Sie sehen sich als Menschen der Praxis, im Gegensatz zu Theoretikern, die ihre Theorien in der Praxis nie bewiesen haben. Es geht den Verfassern darum, anderen zu helfen, nicht aber sich uber andere Personen zu stellen und denjenigen zu erklaren, wie sie ihre Arbeit zu tun haben.
Der Schlussteil zeigt, dass es im Agilen Manifest nicht darum geht, die traditionellen Vorgehensmodelle ad absurdum zu fuhren und die auf der rechten Seite des Manifests angefuhrten Punkte aus der Software-Entwicklung zu streichen, denn sie werden nach wie vor als wichtig erachtet. Es geht darum, sich verstuarkt auf vermeintlich wichtigere Aspekte in der Software-Entwicklung zu konzentrieren. [DK05, S.33ff]
Die Verfasser des Agilen Manifests einigten sich auf vier Ebenen: [Coc03, S.283]
1. Es war notig, auf Anderungen einzugehen und der Begriff agil sollte diese Absicht vermitteln sowie die Diskussion von schwereren Agilen Methodiken in groBeren und hochkritischen Projekten zulassen.
2. Die vier Agilen Werte wurden beschlossen. (Vgl. Abschnitt 3.3, Seite 28)
3. Zwolf weitere detaillierte Prinzipien entsprechend der vier Werte wurden beschlossen. (Vgl. Abschnitt 3.3, Seite 28)
4. Auf konkrete Praktiken verzichtete man ganz bewusst und uberlieB sie den einzelnen Agilen Methoden. (Vgl. Kapitel 5, Seite 39)
3.3 Die vier Agilen Werte
Die vier Agilen Werte sollen dabei helfen, dem Problem der permanenten Anpassungs- bedurfnisse besser begegnen zu konnen und nicht gegen die Anderungen zu kampfen, sondern sich mit den Anderungen zu arrangieren. Es handelt sich um auf Erfahrung basierende Ansichten, die beschreiben sollen, was in der Software-Entwicklung wirklich wichtig ist und daher auf keinen Fall auBer Acht gelassen werden darf. [DK05, S.34]
3.3.1 Individuen und Interaktionen
„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. “ [Coc03, S.281]
Der erste Punkt stellt die Teammitglieder den Verfahren gegenuber. Die eigentliche Aussage in diesem ersten Punkt lautet, dass ein undokumentiertes Verfahren mit guter Interaktion einem dokumentiertem Verfahren mit schlechter Interaktion vorzuziehen ware. [Coc03, S.284]
3.3.2 Funktionierende Software
„Funktionierende Software ist wichtiger als umfassende Dokumentation. “ [Coc03, S.281]
Dieser Punkt beschreibt, dass Dokumentation fur die Entwicklung von Software zwar einen hohen Stellenwert hat und wichtig genommen werden soll, aber in ihrem MaBe auf „gerade ausreichend“, bzw. „gerade genug“ reduziert werden sollte. [Coc03, S.285]
3.3.3 Zusammenarbeit mit dem Kunden
„Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. “ [Coc03, S.281]
Der dritte Punkt beschreibt die Beziehung zwischen den Menschen, in deren Auf- trag die Software erstellt werden soll, und denen, die die Software entwickeln. In der ordentlich ausgefuohrten Agilen Entwicklung gibt es kein wir“ und ihr“ , sondern ledig- lich ein „wir“. Obwohl Vertrage naturlich rechtlich bindend sind, wird die Entwicklung von Software durch Zusammenarbeit gestarkt, egal ob ein Vertrag existiert, oder nicht. Gute Zusammenarbeit kann eine kritische Projektsituation unabhangig vom vertraglichen Status retten. [Coc03, S.285]
3.3.4 Vorbereitung auf unbekannte Anderungen
„Sich auf unbekannte Anderungen einzustellen ist wichtiger als einem Plan zu folgen. “ [Coc03, S.281]
Im letzten Punkt geht es darum, sich an plotzlich auftretende Anderungen im Projekt anzupassen. Es ist sehr sinnvoll, einen Plan auszuarbeiten, jedoch ist es nur sinnvoll, sich so lange an diesem Plan zu orientieren, so lange die tatsachliche Projektsituation sich nicht zu weit davon entfernt hat. Sich an einem Plan zu orientieren, der nicht der Realitat entspricht, ist nutzlos. [Coc03, S.286]
3.4 Die zwolf Agilen Prinzipien
Die Aufgabe der zwolf Agilen Prinzipien liegt darin, die schon beschriebenen vier Agilen Werte zu unterstutzen und bei der Umsetzung derselben nahere Strategien zur Verfugung zu stellen. Die zwolf Prinzipien gehoren zwar auch zum Agilen Manifest, sind aber nicht Bestandteil des Wortlauts und werden gelegentlich von den Autoren des Manifests uber- arbeitet. [DK05, S.41]
Die zwolf Agilen Prinzipien lauten:[25]
1. „Unsere hochste Prioritat liegt darin, den Kunden durch fruhzeitige und kontinuier- liche Auslieferung wertvoller Software zufrieden zu stellen.
2. Begriifie sich verandernde Anforderungen, selbst wenn sie erst spat bei der Entwick- lung auftreten. Agile Prozesse nutzen Anderungen zugunsten des Wettbewerbsvorteils des Kunden.
3. Liefere haufig funktionierende Software aus, innerhalb weniger Wochen oder Monate, wobei der kiirzeren Zeitspanne eindeutig der Vozug zu geben ist.
4. Geschaftsleute und Entwickler miissen wahrend des gesamten Projekts taglich zu- sammenarbeiten.
5. Baue deine Projekte mit motivierten Mitarbeitern auf. Gib ihnen die Umgebung und die Unterstutzung, die sie benotigen und vertraue ihnen, dass sie ihre Arbeit erfolgreich beenden.
6. Die effektivste und effizienteste Methode, Informationen einem Entwicklungsteam zukommen zu lassen, bzw. innerhalb eines Entwicklungsteams auszutauschen, ist die direkte Kommunikation von Angesicht zu Angesicht.
7. Funktionierende Software ist der primare Maflstab fur Fortschritt.
[...]
[1] 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]
[2] Softwarekri.se: ,,Bezeichnet ein Mitte der sechziger Jahre des zwanzigsten Jahrhunderts auftretendes Phanomen: Erstmalig iiberstiegen die Kosten fur die Software die Kosten fur die Hardware. In der Folge kam es zu den ersten grofien gescheiterten Software-Projekten.“ (Vgl. http://de.wikipedia.org/wiki/ Softwarekrise) - Wird in Kapitel 2 - Abschnitt 2.1, Seite 13 naher erlautert.
[3] Software Engineering: ,,The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.11 [IEE90, S.67]
[4] Vorgehensmodell: ,,Gliedert einen Prozess in verschiedene, strukturierte Phasen, denen wiederum ent- sprechende Methoden und Techniken zugeordnet sind. Aufgabe eines Vorgehensmodells ist es, die allgemein in einem Prozess auftretenden Aufgabenstellungen und Aktivitaten in ihrer logischen Ordnung darzustel- len.“ (Vgl. http://de.wikipedia.org/wiki/Vorgehensmodell)
[5] Wird in Kapitel 2 - Unterabschnitt 2.3.1, Seite 16 dieser Arbeit naher erlautert.
[6] agil <aus gleichbed. fr. agile, dies aus lat. agilis, eigtl. ,,leicht zu fuhren, beweglich“> : behande, flink, gewandt; regsam, geschaftig. [Dud03]
[7] Nicht umsonst benannte Kent Beck, der Erfinder von Extreme Programming sein erstes Buch zu diesem Thema mit dem Untertitel ,,Embrace change“ (Auf Deutsch: „Begriifie die Veranderung“).
[8] Mit Gewichtung auf Projekte mit einer Grofie von 20 bis 50 Projektmitarbeitern und einer durch- schnittlichen Durchlaufzeit von 500 Personentagen.
[9] Es wurden bewusst nur die drei bedeutendsten Vertreter der traditionellen Vorgehensmodelle erwahnt, da eine detaillierte Beschreibung samtlicher dokumentierter traditioneller Vorgehensmodelle den Rahmen dieser Arbeit sprengen wurde.
[10] Vgl. http://www.standishgroup.com/sample_research/chaos_1994_1.php
[11] 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 Rohrentechnik und fuhrte in ihrer Anwendung in integrierten Schaltkreisen dazu, dass die Hardware immer stabiler und leistungsfahiger wurde.
[12] Der nach Alan Turing benannte und mit 100.000 US-Dollar dotierte Turing-Preis (offizielle Bezeich- nung: A. M. Turing Award) wird jahrlich von der Association for Computing Machinery (ACM) an Personen verliehen, die sich besonders um die Entwicklung der Informatik verdient gemacht haben. Er gilt als hochste Auszeichnung in der Informatik, vergleichbar mit dem Nobelpreis oder der Fields-Medaille. (Vgl. http://de.wikipedia.org/wiki/Turing-Preis)
[13] Vgl. http://de.wikipedia.org/wiki/Softwarekrise
[14] Die originalen Mitschriften und Fotografien der Konferenz finden sich unter http://homepages.cs. ncl.ac.uk/brian.randell/NATO
[15] Vgl. http://www.cpsc.ucalgary.ca/~kremer
[16] Vgl. http://www.v-modell.iabg.de
[17] Vgl. http://h90761.serverkompetenz.net/v-modell-xt/Release- 1.1/Dokumentation/html
[18] iterativ <Adj.> [lat. iterativus]: wiederholend [Dud03]
[19] Vgl. http://www.standishgroup.com
[20] Veroffentlicht werden die aktuellen Projektzahlen sowie eine aktulle ,,Top-Ten“ Liste der Erfolgswahr- scheinlichkeitsfaktoren.
[21] Schwergewichtig im Sinne von hohem Aufwand zur Einhaltung des Vorgehensmodells.
[22] Es waren dies: Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries, James Grenning und Robert C. Martin (XP); Ken Schwaber, Jeff Sutherland und Mike Breedle (Scrum); Andrew Hunt und Dave Thomas (PP); Arie van Bennekum (DSDM); Alistair Cockburn (Crystal Methods); Jim Highsmith (ASD); Jon Kern (FDD); Stephen J. Mellor (Model Driven Development); Brian Marick (Software Test
[23] Vgl. http://www.agilemanifesto.org
[24] Vgl. http: //www. agilemanifesto. org/principles. html
- Quote paper
- Dipl.-Ing. (FH) Jürgen Götzenauer (Author), 2006, Agile Methoden in der Softwareentwicklung, Munich, GRIN Verlag, https://www.grin.com/document/127411
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.