Über die leichtgewichtigen bzw. agilen Softwareentwicklungsmodelle wurde in den letzten Jahren verstärkt diskutiert. Das zeigt sich durch die vermehrte Anzahl an den in Buchform erschienen Modellen bzw. an vielen veröffentlichten Fachartikeln.
Diese Modelle bilden den Rahmen, um Software effizient und rasch entwickeln zu können. Im Unterschied zu den Schwergewichtigen versuchen sie, Software mit weniger Vorgaben und Richtlinien zu erstellen und rasch auf Kundenwünsche zu reagieren. Sie sind weniger formal beschrieben als die Schwergewichtigen und lassen den Softwareentwicklern einen größeren Freiraum, u. a. beim Entwurf. Doch nicht alle agilen Modelle sind für jede Art von Projekt gleich gut geeignet. Einige Modelle eignen sich auf Grund ihrer reglementierten Richtlinien nur für kleine bis mittelgroße Projekte, die anderen sind weniger formal beschrieben und auch in größeren Projekten anwendbar.
Die in dieser Diplomarbeit beschriebenen Modelle erschienen alle in Buchform, doch auf verschiedene Kriterien wie Stärken und vor allem Schwächen gingen die Modellentwickler nicht detailliert ein. In dieser Arbeit werden acht agile Modelle beschrieben und anhand verschiedener Kriterien verglichen, deren Einsatzbereiche eruiert und Stärken und Schwächen aufgezeigt. Darüber hinaus wird ein Fragebogen erstellt, der Hinweise darüber geben soll, ob bzw. welche agilen Modelle in der Praxis eingesetzt werden und welche Stärken und Schwächen bei agiler Entwicklung auftreten können. Die Durchführung der Befragung ist nicht mehr Teil dieser Diplomarbeit, sie kann jedoch im Rahmen einer darauf aufbauenden Arbeit erfolgen.
Stärken und Schwächen agiler Softwareentwicklungsmodelle
Kurzfassung
Über die leichtgewichtigen bzw. agilen Softwareentwicklungsmodelle wurde in den letzten Jahren verstärkt diskutiert. Das zeigt sich durch die vermehrte Anzahl an den in Buchform erschienen Modellen bzw. an vielen veröffentlichten Fachartikeln. Diese Modelle bilden den Rahmen, um Software effizient und rasch entwickeln zu können. Im Unterschied zu den Schwergewichtigen versuchen sie, Software mit weniger Vorgaben und Richtlinien zu erstellen und rasch auf Kundenwünsche zu reagieren. Sie sind weniger formal beschrieben als die Schwergewichtigen und lassen den Softwareentwicklern einen größeren Freiraum, u. a. beim Entwurf. Doch nicht alle agilen Modelle sind für jede Art von Projekt gleich gut geeignet. Einige Modelle eignen sich auf Grund ihrer reglementierten Richtlinien nur für kleine bis mittelgroße Projekte, die anderen sind weniger formal beschrieben und auch in größeren Projekten anwendbar.
Die in dieser Diplomarbeit beschriebenen Modelle erschienen alle in Buchform, doch auf verschiedene Kriterien wie Stärken und vor allem Schwächen gingen die Modellentwickler nicht detailliert ein. In dieser Arbeit werden acht agile Modelle beschrieben und anhand verschiedener Kriterien verglichen, deren Einsatzbereiche eruiert und Stärken und Schwächen aufgezeigt. Darüber hinaus wird ein Fragebogen erstellt, der Hinweise darüber geben soll, ob bzw. welche agilen Modelle in der Praxis eingesetzt werden und welche Stärken und Schwächen bei agiler Entwicklung auftreten können. Die Durchführung der Befragung ist nicht mehr Teil dieser Diplomarbeit, sie kann jedoch im Rahmen einer darauf aufbauenden Arbeit erfolgen.
Abstract
Agile software development approaches have become more popular during the last few years, shown by the increased number of methods appeared in book form or discussed in many subject articles.
They form the framework to be able to develop software efficiently and quickly. In addition to this, they try to ensure that the software meets customer’s changing needs. In comparison to traditional development methods, agile development is less document-centric and more code-oriented. Further, it is adaptive rather than predictive and people-oriented rather than process-oriented. But all agile methods aren't equally well suitable for every kind of project. Due to more exact guidelines, some methods are only suitable for small till medium-sized projects, others are described less formally and therefore also applicable to greater projects. All the methods described in this paper appeared in book form but the method developers didn't go into different criteria like strengths and primarily weaknesses. The description and the comparisons of the agile methods, the fields of application as well as the strengths and weaknesses derived from it are the main part of the work. Further, we prepare a questionnaire which examines the hypotheses put forward in this work. This questionnaire gives information about which agile models are used in the practice and declares which strengths and weaknesses appear at an agile development. The evaluation is no more part of the work. It can, however, be evaluated in the context of a master thesis building on it.
Danksagung
Wir möchten unserem Betreuer, Herrn Dr. Joachim H. Fröhlich, für diese interessante Aufgabenstellung und seine engagierte Betreuung danken. Unser Dank geht an dieser Stelle auch an unsere Eltern, die uns das Studium der Wirtschaftsinformatik ermöglicht und uns in jeder Hinsicht dabei unterstützt haben. Ebenso bedanken wir uns bei unseren Freunden und Kollegen, die durch kritische Anmerkungen und fachliche Diskussionen uns immer wieder neue Anregungen und Motivation gegeben haben.
Kapitelaufteilung
Michael Wesinger erklärt sich verantwortlich für die folgenden Kapitel:
• Kapitel 1
• Kapitel 2
• Kapitel 4.1, 4.2, 4.3
• Kapitel 6.6, 6.7, 6.8, 6.9, 6.10
• Kapitel 7 Thomas Ecker erklärt sich verantwortlich für die folgenden Kapitel:
• Kapitel 3
• Kapitel 4.4, 4.5
• Kapitel 5
• Kapitel 6.1, 6.2, 6.3, 6.4, 6.5
• Kapitel 8
1 Einleitung
Die leichtgewichtigen Softwareentwicklungsmodelle werden von ihren Entwicklern und zahlreichen Befürwortern als Lösungen für Softwareentwicklungsprobleme gesehen, weil sie im Gegensatz zu den schwergewichtigen Modellen durch mehr Flexibilität und mehr Kundennähe gekennzeichnet sind. Ihnen eilt der Ruf voraus, dort zu helfen, wo schwergewichtige Modelle scheitern. Mitunter werden sie als Allheilmittel gesehen. Sie gewähren den Projektbeteiligten ein hohes Maß an Gestaltungsfreiheit, fordern bzw. fördern ein regelmäßiges Überprüfen und Anpassen des Vorgehens und bauen auf ähnliche Grundsätze auf. Der bekannteste Vertreter ist „eXtreme Programming“. Dieses Modell war wichtig für die Weiterentwicklung anderer agiler Modelle. Das Ziel ist, mit geringem finanziellen Einsatz so schnell als möglich auf Änderungen zu reagieren, Erfolge früh sichtbar zu machen und die Lebensdauer der Software zu verlängern. Diese Modelle kommen ursprünglich aus den USA, haben jedoch auch bei den IT - Verantwortlichen in Europa ihre Anhänger. Im Dezember 2001 hat das Cutter IT Consortium, das ist ein Zusammenschluss von amerikanischen IT-Beratern, 200 Softwareunternehmen mit mindestens 25 Mitarbeitern nach dem Einsatz von leichtgewichtigen Modellen befragt. Dem Umfrageergebnis zufolge hatten mehr als 48 % der Firmen die Absicht, bis zum Jahre 2003 leichtgewichtige Modelle in mindestens einem Projekt einzusetzen. Das zeigt, wie groß die Euphorie bezüglich des Einsatzes von leichtgewichtigen Modellen im Jahre 2001 war. Weiters zeigte sich die höhere Kundenzufriedenheit. Wurde ein Projekt leichtgewichtig abgewickelt, so waren 77 % der Kunden mit dem Ergebnis eher zufrieden. Bei Teams, die schwergewichtig vorgingen, waren es nur 63 %. Dies bedeutet aber auch, dass noch 23 % der Kunden mit dem leichtgewichtigen Modell unzufrieden waren [Coldewey 2002a S. 237]. Der Grund der Unzufriedenheit geht aus der Studie nicht hervor. Man darf trotz aller Euphorie um die neuen Modelle nicht vergessen, dass auch sie Problemen und Risiken ausgesetzt sind.
1.1 Motivation
Das wissenschaftliche Computermagazin ACM veröffentlichte eine Studie 1 , welche die unterschiedlichen Prämissen theoretischer und praxisorientierter Forschung
1.2 Aufgabenstellung und Zielsetzung
Wir möchten der zunehmenden Bedeutung der leichtgewichtigen Modelle Rechnung tragen und sie aus neutraler Sicht beschreiben. Diese Modelle sollen anhand typischer Merkmale charakterisiert und untereinander - bzw. auch mit typisch schwergewichtigen Modellen - verglichen werden, um daraus Stärken und Schwächen ableiten zu können. Weiters möchten wir herausfinden, ob es „das“ leichtgewichtige Modell gibt, das in allen Projekten, unabhängig der Größe eingesetzt werden kann, das alle Phasen der Softwareentwicklung abdeckt und mit denen allen Schwächen und Risiken entgegengetreten werden kann. Dies wäre ein Modell, das man Softwareentwicklungsunternehmen empfehlen könnte. Durch eine neutrale Sicht sollen die Stärken und Schwächen besser erkennbar und die Modelle vergleichbar werden.
Um die Aussagekraft der Literaturarbeit zu erhöhen, schaffen wir mit einem Fragebogen die Voraussetzungen, die in unserer Arbeit aufgestellten Hypothesen untersuchen zu können. Der Fragebogen soll so konzipiert sein, dass die
Aufbau der Arbeit 15 Untersuchung in allen Softwareentwicklungsfirmen, unabhängig der Unternehmensgröße und Branche, durchgeführt werden kann. Der Grund einer unternehmens- und branchenunabhängigen Untersuchung liegt darin, dass Erkenntnisse über den Vorgang der Softwareentwicklung gewonnen werden sollen. Umfassende Erkenntnisse über den praktischen Einsatz von Softwareentwicklungsmodellen erhält man, wenn keine unternehmensspezifische Festlegung hinsichtlich Größe und Branche vorgenommen wird. Die Auswertung des Fragebogens wird von uns nicht durchgeführt, dies könnte jedoch im Rahmen einer weiterführenden Arbeit erfolgen.
1.3 Aufbau der Arbeit
In Kapitel 2 „Grundlagen“ nehmen wir einige Begriffsdefinitionen vor, erörtern die Unterschiede zwischen leicht- und schwergewichtigen Modellen und beschreiben die für die Softwareentwicklung notwendigen Phasen und Prozesse, da wir einerseits die Modelle anhand von Phasen vergleichen und andererseits einen einheitlichen Sprachgebrauch diesbezüglich liefern wollen. In Kapitel 3 „Agile Softwareentwicklungsmodelle“ gehen wir auf die leichtgewichtigen Modelle ein. Wir analysieren das „Manifest der agilen Softwareentwicklung“, erläutern die Eigenschaften und gehen auf die Einsatzbereiche ein. Kapitel 4 „Ausgewählte Vertreter agiler Modelle“ beschreibt die typischen Vertreter der leichtgewichtigen Modelle. Kapitel 5 „Vergleich der Vertreter agiler Modelle“ stellt die Modelle zum Vergleich gegenüber und behandelt die Unterschiede anhand verschiedener Kriterien. Weiters analysieren wir, inwieweit die leichtgewichtigen Softwareentwicklungsmodelle die im zweiten Kapitel beschriebenen Phasen abdecken. Kapitel 6 geht auf die Stärken sowie auf die Schwächen der leichtgewichtigen Softwareentwicklungsmodelle ein. In Kapitel 7 „Fragebogen“ beschreiben wir die Zielsetzung und die Strukturierung des Fragebogens. Im letzten Kapitel „Zusammenfassung und Ausblick“ fassen wir die gewonnenen Erkenntnisse der Diplomarbeit zusammen und liefern einen kurzen Ausblick.
2 Grundlagen
Ziel dieses Kapitels ist die Einführung in den komplexen Bereich der Softwareentwicklungsmodelle und der Erwerb von grundlegendem Wissen, das für das Verständnis der weiteren Kapitel notwendig ist. Wir nehmen eine Begriffsdefinition vor, führen weiters in den Bereich der Softwareentwicklungsmodelle ein und eruieren die Unterschiede zwischen leicht- und schwergewichtigen Modellen. Darüber hinaus beschreiben wir die Phasen der Softwareentwicklung inklusive Tätigkeiten und Ergebnissen. Die von uns beschriebenen leichtgewichtigen Modelle werden im Rahmen dieser Arbeit anhand der Phasen gegenübergestellt und analysiert, inwieweit sie diese berücksichtigen. Abschließend beschreiben wir noch Prozesse, die bei der Softwareentwicklung unterstützend eingesetzt werden.
2.1 Begriffsdefinitionen
Wir definieren hier jene Begriffe, die für das Verständnis der folgenden Kapitel notwendig sind. In der Literatur werden hierfür oft keine einheitlichen Ausdrücke verwendet. Damit wir in dieser Arbeit ein Begriffschaos vermeiden, erläutern wir an dieser Stelle die wesentlichen Ausdrücke und Bedeutungen. Eine umfassende Begriffsdefinition führen wir im „Glossar“ an.
Aktivität: Eine in sich abgeschlossene Folge von Tätigkeiten, deren Unterbrechung kein sinnvolles Ergebnis liefert [Heinrich et al. 2004 S. 49]. Arbeitsergebnis: Ein Produkt, dass bei einer Aktivität entstanden ist. Basislinie (engl. Baseline): Eine überprüfte und genehmigte Spezifikation [OOSE 2003]. Im Kontext des Konfigurationsmanagements stellt sie die Ausgangskonfiguration eines Produkts dar.
Entwurf: Die Phase eines Projekts, mit dem Zweck der Überführung der Grundkonzeption in ein logisches Modell des Sollzustands [Heinrich 2001a S. 72]. Feature: Ein funktionales Merkmal bzw. eine unbedingte notwendige Eigenschaft eines Softwareprodukts.
Inkrement: Darunter versteht man die Erweiterung eines Produktes. Ein Inkrement ist gewöhnlich gekennzeichnet durch die Differenz zwischen zwei Versionen eines in Entwicklung befindlichen Systems. Auch das Teilergebnis, das innerhalb einer Iteration entstanden ist, wird Inkrement genannt [OOSE 2003].
Modell: Synonym für Verfahren bzw. Ansatz im Kontext der Softwareentwicklung. Wir unterscheiden in unserer Arbeit zwischen leichgewichtigen (agilen) und schwergewichtigen Softwareentwicklungsmodellen.
Phase: Eine nach zeitlichen und logischen Gesichtspunkten gebildete Teilmenge eines Projekts [Heinrich 2001a S. 72].
Praktik: Tätigkeit, die von den Beteiligten beim Softwareentwicklungsvorgang durchgeführt wird.
Prozess: Menge von Operationen, die durch eine Eingabe in ein System, interne Funktionen im System und einem Ergebnis aus dem System beschrieben wird [Heinrich et al. 2004 S. 534].
Refactoring: Restrukturierung des Programms durch den Softwareentwickler, ohne Funktionen zu ändern.
Release: Eine aus Anwendersicht lauffähige Version des Systems mit vorher genau definierter Funktionalität.
Rolle: Ein System von Verhaltensregeln, das an den Inhaber einer Position gerichtet ist [Heinrich 2001b S. 290].
Softwareentwicklungskultur: Die in einer Organisation üblichen Softwareentwicklungsrichlinien.
Softwareentwicklungslebenszyklus (engl. Software Development Life Cycle): Zusammenfassender Begriff für die Phasen der Softwareentwicklung.
Begriffsdefinition 19 System: Der ganzheitliche Zusammenhang von Teilen, Einzelheiten, Dingen oder Vorgängen, die voneinander abhängig sind, ineinander greifen oder zusammenwirken [Heinrich 2001a S. 11].
Testen: Der Vorgang des Überprüfens der Korrektheit von Entwurfs- und Entwicklungsergebnissen [Heinrich et al. 2004 S. 661]. Wir unterscheiden in unserer Arbeit mehrere Begriffe, die mit dem Testen in Verbindung stehen. Diese werden wie folgt definiert:
• Abnahmetest (Akzeptanztest): Ist eine besondere Ausprägung des
Systemtests, bei dem das gesamte Programm unter Beobachtung oder Mitwirkung des Kunden getestet wird. Dieser Test dient als vertrauensbildende Maßnahme für den Kunden [Richter 2004 S. 12-14], [Sauer 2002 S. 18].
• Automatischer Test: Soll vermeiden, dass mangels Zeit nicht getestet wird
und dass Tests in schlechter Qualität durchgeführt werden [Eckstein 2004 S. 34].
• Integrationstest: Die Module werden zu Teilsystemen zusammengefasst und
das fehlerfreie Zusammenwirken der Systemkomponenten wird überprüft [Richter 2004 S. 3], [Sauer 2002 S. 15].
• Modultest: Das ist der Test auf der untersten Ebene, der vom
Modulentwickler selbst durchgeführt wird. Man betrachtet ein individuelles Unterprogramm bzw. eine Prozedur in einem Programm und testet es. Man testet also nicht das gesamte Programm, sondern kleinere Einheiten [Richter 2004 S. 1-3], [Sauer 2002 S. 11]. Diese Tests bilden das Hauptsicherheitsnetz für Refactoring und den Einbau neuer Features [Eckstein 2004 S. 33].
• Funktionstest: Ein Test, bei dem das Programm oder einzelne ausführbare
Teile des Programms überprüft werden. Kann sowohl vom Entwickler als auch vom Kunden durchgeführt werden.
• Kundentest: Im Gegensatz zum Abnahmetest erfolgt das Testen durch den
Kunden nicht nur am Ende der Entwicklungsphase. Das Hauptziel ist die Abdeckung der Anforderungen. Kundentests sind gewöhnlich Funktionstests.
• Regressionstest: Ein Test, der anhand der vorliegenden Testdaten beliebig oft
wiederholbar ist und dem Nachweis dient, dass die Funktionalität der Nachfolgeversion eines Systems mit der Funktionalität der Vorgängerversion identisch ist [Heinrich et al. 2004 S. 561].
• Systemtest: Beim Systemtest wird das gesamte Programm mit den in den
Anforderungsdokumenten festgelegten Funktions-, Leistungs- und Qualitätsanforderungen verglichen. Die Überprüfung des Außenverhaltens ist
• Test-First: Entwicklung des Tests vor der Codierung. Ziel ist es,
Schnittstellen, Funktionalität und Codebeschränkungen im Vorfeld zu verstehen. Test-First ist mehr Entwurf als Entwicklungstechnik [Eckstein 2004 S. 33].
Zeitbox (engl. Time-Box): Kleine Planungsintervalle mit festen Terminen, festgelegten Ressourcen und priorisierten Featurelisten [OOSE 2003]. Zeitbox-Verfahren (engl. Time-Boxing): Für eine oder mehrere Aktivitäten wird ein fester Zeitrahmen festgelegt. Der Endtermin ist dabei wichtiger als die Vollständigkeit des Ergebnisses [OOSE 2003].
Zeremonie: Anteil nachvollziehbarer Interaktionen und Entscheidungen.
Um die verwendeten Begriffe verständlicher zu machen, haben wir für die deutschen Ausdrücke jeweils die englische Originalbezeichnung in Klammer angeführt, da die Literatur speziell zu den Modellbeschreibungen fast ausschließlich in englischer Sprache vorliegt. Englische Begriffe sind dem Leser, der sich mit der Materie beschäftigt hat, oftmals besser bekannt, weil sie in den verschiedenen Quellen einheitlich zu finden sind. Die Diplomarbeit ist aber in deutscher Sprache geschrieben, daher werden vordergründig deutsche Begriffe verwendet.
2.2 Softwareentwicklungsmodelle
In den 60er und 70er Jahren entstand der Begriff „Software-Krise“. Grund war die schlechte Qualität der erzeugten Software-Systeme. Deshalb hat man erstmals in der Praxis erprobte Vorgehensmodelle veröffentlicht, die im Laufe der Jahre erweitert und den Anforderungen angepasst wurden [Zuser et al. 2001 S. 16]. Diese Modelle erweckten immer mehr das Interesse der IT-Verantwortlichen der Softwarebranche. Ein Softwareentwicklungsmodell bildet den Rahmen für das Entwickeln einer Anwendung. Die Projektverantwortlichen erwarten sich durch dessen Einsatz u. a. eine Reduzierung der Kosten über den Lebenszyklus eines Produkts, eine Qualitätsverbesserung und eine bessere Kommunikation der Projektbeteiligten. Darüber hinaus soll ein Vorgehensmodell eine korrekte Abfolge der Entwicklungsschritte zur Folge haben [Bergsmann 2003 S. 1-2]. Man unterscheidet zwei unterschiedliche Arten von Entwicklungsmodellen. Zum einen die schwergewichtigen Modelle, die den Schwerpunkt auf die Planung und die Dokumentation legen. Diese Modelle werden auch als „Ingenieur-Modelle“
Softwareentwicklungsmodelle 21 bezeichnet, weil sie von anderen Ingenieurdisziplinen geprägt wurden, u. a. von Bauingenieuren. Der durchschlagende Erfolg blieb ihnen jedoch verwehrt 2 . Ein Grund dafür war die bürokratische Vorgehensweise und die große Menge an Dokumentation, welche die Entwicklung verlangsamte [Fowler 2003]. Zum anderen gibt es seit Mitte der 90-er Jahre die leichtgewichtigen Modelle, die seit Festlegung des „Manifests der agilen Softwareentwicklung“ im Jahre 2001 auch als agile Modelle bezeichnet werden. Software soll mit weniger Bürokratie, d. h. mit weniger Vorgaben und Richtlinien erstellt werden. Im Gegensatz zu den schwergewichtigen Modellen soll nur mehr das Notwendigste standardisiert und den Entwicklern u. a. beim Entwurf und der Dokumentation Freiheiten geboten werden. Wir verwenden den Begriff „leichtgewichtig“ und „agil“ synonym. Konträr dazu sprechen wir von „schwergewichtigen“ Modellen, obwohl in der Literatur häufig auch der Begriff „klassisch“ oder „traditionell“ verwendet wird. Wir führen nun eine kurze Beschreibung der schwer- und leichtgewichtigen Modelle an:
2.2.1 Schwergewichtige Modelle
Die schwergewichtigen Modelle sind dadurch gekennzeichnet, dass die Anforderungen an ein System vorab genau spezifiziert sind. Sie versuchen, möglichst vollständige Prozessbeschreibungen zur Verfügung zu stellen und den Prozess der Softwareentwicklung anderen Ingenieurdisziplinen so ähnlich als nur möglich zu gestalten [Coldewey 2002a S. 238-241].
Die schwergewichtigen Modelle sind planungsorientiert, d. h. man plant detailliert einen großen Teil des Softwareentwicklungsprozesses für einen langen Zeitraum im Voraus [Hruschka 2003 S. 3]. Ein Ziel der schwergewichtigen Modelle ist es, Menschen wie Ressourcen behandeln zu können. Das bedeutet, dass die an der Softwareentwicklung beteiligten Menschen austauschbar sein sollen. Dazu legt man sich auf Rollen wie Analysten, Entwickler, Tester und Manager fest. Die Einzelpersonen hinter den Rollen sind weniger wichtig [Fowler 2003]. Typische Vertreter der schwergewichtigen Modelle sind das V-Modell oder das Spiralmodell. Sie sind im Gegensatz zu den leichtgewichtigen Modellen durch einen
2.2.2 Leichtgewichtige Modelle
Die leichtgewichtigen Modelle kommen aus der Praxis und wurden dort vielfach erprobt. Es gab für diese Verfahren immer wieder Rückschläge, u. a. durch die mangelnde Erfahrung der Umsetzung in einer Organisation. In [Coldewey 2004 S.
73] sind einige Referenzprojekte agiler Modelle im Bereich von Buchungssystemen für Banken oder Versicherer angeführt, die den Marktanteil dank einer Marktstrategie innerhalb eines Jahres um etwa 12% steigern konnten. Diese Marktstrategie war nur durch agile Entwicklung möglich. Die Modelle weisen mittlerweile eine Reihe von weiteren Referenzen auf. Durch eine neue Herangehensweise an die Abwicklung von Softwareprojekten versuchen sie, auf neue Herausforderungen in der Softwareentwicklung zu reagieren. Ein Beispiel wäre die Minimierung der Zeitspanne von der Entwicklung bis zum tatsächlichen Einsatz der Software [Coldewey 2002a S. 237]. Die leichtgewichtigen Modelle stellen die Softwareentwickler in das Zentrum der Überlegungen [Eckstein 2004 S. 11]. Sie umfassen nur wenige Regeln und lassen dem Entwicklerteam große Freiheiten, etwa beim Entwurf, bei der Dokumentation oder bei der Qualitätssicherung. Die Leichtgewichtigkeit beruht auf der Verknüpfung von ausgewählten Modellen, die einander unterstützen. Kennzeichnend für leichtgewichtige Modelle sind ihre Gemeinsamkeiten. Teamorientierung, adaptive Zeitplanung, Orientierung am Kundennutzen und kurze Iterationszyklen beeinflussen ihren Erfolg [Abrahamsson et al. 2002 S. 14].
Sie sind für kleine Teams und kleine bis mittelgroße Projekte am Besten geeignet. Sie können auch in größeren Projekten eingesetzt werden, in diesem Fall müssen sie aber angepasst werden. Das bedeutet, dass ein großes Team in mehrere kleine aufgeteilt wird, wobei aber zwischen diesen kleinen Teams immer kommuniziert werden muss. In Kapitel 3 wird auf die Thematik „Einsatzbereich der leichtgewichtigen Modelle“ (S. 36) eingegangen.
Das bekannteste leichtgewichtige Modell ist „eXtreme Programming“. Dieser und andere typische Vertreter werden in Kapitel 4 „Ausgewählte Vertreter agiler Modelle“ (S. 39) anhand Phasen, Praktiken und Rollen beschrieben und anschließend kritisch bewertet.
Softwareentwicklungsmodelle 23
2.2.3 Unterschiede zwischen leicht- und schwergewichtigen Modellen
Die schwergewichtigen Softwareentwicklungsmodelle versuchen, möglichst vollständige Prozessbeschreibungen zur Verfügung zu stellen. Gegensätzlich zu den schwergewichtigen Vorgehensweisen, die oft mehrere hundert bis tausend Seiten Beschreibung umfassen 3 , fallen die Beschreibungen der leichtgewichtigen Softwareentwicklungsmodelle vergleichsweise kurz aus. Sie liefern nur einen Rahmen, der dem Projektteam ermöglichen soll, einen eigenen Prozess zu finden. Das Ziel schwergewichtiger Modelle ist es, den Prozess der Softwareentwicklung anderen Ingenieurdisziplinen so ähnlich wie möglich zu gestalten. Die leichtgewichtigen Modelle nehmen Abstand von der Vorstellung eines einheitlich organisationsweiten wiederholbaren Vorgangs. Stattdessen wird die konkrete Vorgehensweise von den Teams und deren Erfahrungen im individuellen Projekt gestaltet [Coldewey 2002a S. 238-241].
Die Befürworter der leichtgewichtigen Entwicklungsmodelle sind der Ansicht, dass die schwergewichtigen Entwicklungsmodelle eher planungsorientiert als ergebnisorientiert sind. Die leichtgewichtigen Vorgehensmodelle konzentrieren sich mehr auf das Erreichen der Ergebnisse als dem Weg dorthin. Dabei fehlen aber Möglichkeiten zur Kontrolle. Dies hat zur Folge, dass im Gegensatz zu den schwergewichtigen Vorgehensmodellen größeres Vertrauen in die Mitarbeiter erforderlich ist [Hruschka 2003 S. 3].
Bei den schwergewichtigen Modellen plant man detailliert einen großen Teil des Softwareentwicklungsvorgangs für einen langen Zeitraum im Voraus. Diese Vorgangsweise lehnen die Autoren der leichtgewichtigen Modelle ab, da detaillierte Vorausplanung zu Problemen führen kann, sobald Änderungen eintreten. Bei leichtgewichtiger Vorgangsweise sollten Änderungen wohlwollend aufgenommen werden. Leichtgewichtige Modelle sind adaptiv. Das heißt, sie enthalten sich anpassende Prozesse. Weiters sind sie nicht vorhersagend. Im Gegensatz zu den schwergewichtigen Modellen sind leichtgewichtige Modelle nicht auf Prozesse ausgerichtet. Ihr primärer Fokus liegt stattdessen auf den Menschen. Sie betonen, dass Softwareentwicklung Spaß machen sollte [Fowler 2003]. Leichtgewichtige Modelle gehen davon aus, dass man Menschen nicht wie vorhersagbare Komponenten behandeln kann. Menschen sind höchst variabel, d. h. sie können einzigartige Erfolge erbringen, aber auch versagen. Das sind Faktoren,
Geht man schwergewichtig vor, so beginnt die Programmierung relativ spät im Projekt. Bei größeren Projekten entstehen selbst bei iterativen Vorgehensmodellen wie dem V-Modell 97 oder dem RUP Vorlaufzeiten von sechs Monaten oder mehr, da in dieser Zeit sämtliche Fehler gefunden werden sollten. Bei leichtgewichtiger Entwicklung startet die Codierung sehr früh im Projektverlauf. Weiters liegt es laut [Coldewey 2002a S. 240] in der Natur der schwergewichtigen Modelle, dass zwischen Entscheidungen und deren Auswirkungen lange zeitliche Verzögerungen liegen.
Fehler sollten bei schwergewichtiger Vorgehensweise vermieden oder zumindest möglichst früh gefunden werden. Der Grund dafür liegt in der Annahme, dass die Fehlerkosten exponentiell mit der Zeitspanne bis zu ihrer Entdeckung steigen. Um dies zu vermeiden, wird vor allem Dokumentation eingesetzt. Dokumentation hat das Ziel, die einzelnen Aspekte des geplanten Systems aufzubereiten, sodass sie begutachtet und auf Vollständigkeit überprüft werden kann. Weiters kann sie auch zur Wartung herangezogen werden, sofern es gelingt, sie konsistent zu halten. Ein anderes Mittel der schwergewichtigen Modelle, um Fehler zu vermeiden, lautet Redundanz. Dies erleichtert die Fehlersuche nicht nur bei der menschlichen Begutachtung, sondern ermöglicht auch eine maschinelle Überprüfung. Bei leichtgewichtiger Vorgehensweise wird nicht versucht, Änderungen zu vermeiden, sondern Änderungen so einfach wie möglich zu halten. Dies erfordert eine grundsätzlich andere Ausrichtung des Projekts im Anforderungs-, Risiko- und Kundenmanagement. Änderungen sind nicht nur wegen Fehlerkorrekturen, sondern auch aufgrund eines betriebswirtschaftlichen und technischen Lernprozesses notwendig. Diese Art von Änderungen wird bei schwergewichtigen Vorgehensmodellen in die Wartungsphase verlagert. Bei leichtgewichtigen Modellen sind Änderungen in diesem Zusammenhang Bestandteil der Marktstrategie. Die Einarbeitung neuer Projektmitglieder erfolgt bei schwergewichtigen Modellen in erster Linie durch das Studium von Dokumenten. Bei den leichtgewichtigen Modellen erfolgt sie durch Zusammenarbeit mit den bestehenden Teammitgliedern [Coldewey 2002a S. 239-241].
Phasen und Prozesse der Softwareentwicklung 25
2.3 Phasen und Prozesse der Softwareentwicklung
Um ein Verständnis für die Vorgehensweise der Softwareentwicklung zu bekommen, folgt eine Übersicht samt Erklärung der dabei nötigen Phasen. Zusätzlich zu den Phasen der Softwareentwicklung wird auf die Prozesse eingegangen, da die Entwicklung nicht nur aus der Systemerstellung, sondern auch aus unterstützenden Prozessen wie Projekt- und Konfigurationsmanagement besteht.
2.3.1 Phasen
Für jede Phase ist zu definieren, welche Ergebnisse erzielt werden müssen. Dabei ist zu beachten, dass eine Phase erst dann in Angriff genommen werden darf, wenn die vorhergehende vollständig abgeschlossen ist, d. h. die Ergebnisse erbracht wurden. Dadurch sollen Softwareprojekte besser planbar, organisierbar und kontrollierbar werden [Pomberger und Pree 2004 S. 11].
Problemdefinition: In dieser Phase wird festgelegt, was das Softwaresystem leisten soll. Dies geschieht in einer einfachen sprachlichen Form. Der Kunde äußert seine Wünsche und nennt dem Entwickler die Voraussetzungen des Systems. Neben dem Einsatzfeld der Software sollte der Kunde auch ein Benutzerprofil erstellen und klären, in welcher Systemumgebung die Software eingesetzt wird [Dorloff 2001 S. 5]. Es wird der Ist-Zustand erhoben, die Problemstellung erörtert und der Problembereich abgegrenzt. Die Ergebnisse werden in Form eines Projektplanes, eines Lastenheftes, einer Problemstellung und eines Projektauftrages grob beschrieben [Pomberger und Pree 2004 S. 12].
Systemspezifikation (Anforderungsdefinition): Das Ziel dieser Phase ist es, einen Vertrag zwischen Kunde und Entwickler zu gestalten, der genau festlegt, was das geplante Softwaresystem leisten soll. Wie die Umsetzung erfolgt, ist nicht Gegenstand der Systemspezifikation. Die wesentlichen Bestandteile einer Spezifikation sind die funktionalen und nichtfunktionalen Anforderungen (etwa Robustheit, Portabilität). Eine wesentliche Tätigkeit dieser Phase ist die Erstellung einer Spezifikation bzw. eines genauen Projektplanes sowie die Prüfung der Vollständigkeit der Anforderungen, die Prüfung der Konsistenz der Anforderungen und die Prüfung der technischen Durchführbarkeit. Bevor die Phase abgeschlossen wird, muss der Kunde bestätigen, dass die Spezifikation alle gewünschten Funktionen enthält. Als Ergebnis liegen ein Pflichtenheft und ein Projektplan vor. [Pomberger und Pree 2004 S. 13].
Test: Hier wird festgestellt, ob die Anforderungen durch das Softwareprodukt erfüllt werden. Die Wechselwirkungen der Systemkomponenten sollen unter echten Bedingungen geprüft und möglichst viele Fehler aufgedeckt werden. Weiters muss sichergestellt sein, dass die Implementierung die Spezifikation erfüllt. Als Ergebnis entsteht hier das einsatzfähige System [Pomberger und Pree 2004 S. 14]. Um einen übersichtlichen Vergleich der agilen Modelle hinsichtlich ihrer Berücksichtigung der in diesem Kapitel beschriebenen Phasen vornehmen zu können, untergliedern wir den Vorgang des Testens zusätzlich in vier Testphasen, die im Grundlagenkapital erläutert wurden:
• Modultest
• Integrationstest
• Systemtest
• Abnahmetest
Systemeinführung: Das Ziel ist, das System unter realen Bedingungen zu prüfen und Fehler aufzudecken. Es muss sichergestellt sein, dass die Systemimplementierung der Spezifikation entspricht. Ist dies sichergestellt, wird das Softwareprodukt zur Benutzung freigegeben [Pomberger und Pree 2004 S. 14].
Phasen und Prozesse der Softwareentwicklung 27 Wartung: Zu dieser zeitlich betrachtet längsten Phase zählen alle Tätigkeiten, die die Anwendung des Systems über einen längeren Zeitpunkt gewährleisten. Alle Mängel, die während der Betriebsphase auftreten, müssen beseitigt werden [Pomberger und Pree 2004 S. 14], [Dorloff 2001 S. 11].
Die im Laufe der Diplomarbeit beschriebenen Vertreter der leichtgewichtigen Modelle werden diesen Phasen der Softwareentwicklung gegenübergestellt und analysiert, inwieweit ein Modell die Phasen berücksichtigt.
2.3.2 Prozesse
Um die Softwareentwicklung zu gestalten, werden Prozesse wie Projekt-, Änderungs-, oder Versions- und Konfigurationsmanagement verwendet. Ziel ist, die in den jeweiligen Phasen beschriebenen Ergebnisse zu erreichen. Wir erläutern an dieser Stelle die Prozesse, da wir in Kapitel 5 vergleichen, inwieweit ein agiles Modell diese berücksichtigt.
Projektmanagement: Das Projektmanagement umfasst alle Aktivitäten, welche die Planung, Durchführung und Kontrolle von Entwicklungsprojekten betreffen. Ziel ist das Festlegen von Rahmenbedingungen, mit denen die Planungsziele erreicht werden können [Heinrich et al. 2004 S. 23]. Die Einführung eines Projektmanagements ist vor allem dann sinnvoll, wenn das Ziel des Projekts im Vorhinein definiert, die Frist für die Zielerreichung bestimmt und die Zielerreichung mit Unsicherheit und Risiko verbunden ist [Meffert 1998 S. 1000]. Dies ist bei (agilen) Softwareprojekten der Fall.
Änderungsmanagement: Unter Änderungsmanagement versteht man einen Steuerungsprozess, der die Veränderungen in einem Unternehmen initiiert und steuert [Kraus 2003]. Wesentliches Merkmal ist die Flexibilität, auf nicht geplante Ereignisse zu reagieren und einzugehen. Sehr wichtig ist dabei die Kommunikation mit den Mitarbeitern, um die Gefahren einer schlechten oder fehlerhaften Informationsvermittlung zu vermeiden [Kraus 2003].
Neben der Klarheit über die Zielsetzung sollen jene Prozesse und Strukturen erörtert werden, mit denen die Ziele zu erreichen sind. Durch eine offene Informationspolitik soll ein Problembewusstsein aufgebaut, dem Kunden und dem Markt erste Priorität eingeräumt und negative Einflüsse entfernt werden [Kraus 2003]. Ein Änderungsmanagement ist sehr wichtig, da sich die Anforderungen der Kunden rasch ändern können und die Flexibilität einen Wettbewerbsvorteil gegenüber Konkurrenten zur Folge hat.
2.4 Zusammenfassung
Ein Softwareentwicklungsmodell legt den Rahmen fest, mit dem eine Anwendung entwickelt werden soll. Man unterscheidet zwischen schwergewichtigen und leichtgewichtigen Softwareentwicklungsmodellen. Die leichtgewichtigen Modelle haben das Ziel, Software mit weniger Bürokratie, sprich mit weniger Vorgaben und Richtlinien zu erstellen und rasch auf Änderungen reagieren zu können. Es soll nur das Notwendigste standardisiert und den Entwicklern Freiheiten, etwa beim Entwurf oder der Dokumentation geboten werden. Teamorientierung, adaptive Zeitplanung, Orientierung am Kundennutzen und kurze Iterationszyklen sind markante Aspekte von leichtgewichtigen Entwicklungsmodellen. Im Gegensatz dazu sind die schwergewichtigen Modelle dadurch gekennzeichnet, dass die Anforderungen an ein System vorab genau spezifiziert sind. Das Ziel dieser ist es, vollständige Prozessbeschreibungen zur Verfügung zu stellen und den Prozess der Softwareentwicklung anderen Ingenieurdisziplinen so ähnlich als nur möglich zu gestalten. Ein wesentliches Merkmal ist ihre Planungsorientiertheit, das bedeutet, dass ein großer Teil des Softwareentwicklungsprozesses für einen langen Zeitraum im Voraus geplant wird. Anders als bei den leichtgewichtigen Modellen, wo der Kurs jederzeit geändert werden kann, steht hier der Kurs schon zu Beginn fest. Die Softwareentwicklung berücksichtigt Phasen und Prozesse. Die Phasen bauen einander auf. Zu diesen Phasen gehören die Problemdefinition (Analysephase), die Systemspezifikation, der Entwurf, die Implementierung, der Test, die Systemeinführung und die Wartung. Eine neue Phase wird erst dann in Angriff
Zusammenfassung 29 genommen, wenn die vorhergehende vollständig abgeschlossen wurde. Die Softwareentwicklung berücksichtigt nicht nur Phasen, sondern auch Prozesse. Zu diesen Prozessen zählen etwa das Projektmanagement, das Änderungsmanagement und das Versions- und Konfigurationsmanagement.
Die im Laufe der Diplomarbeit beschriebenen Vertreter der leichtgewichtigen Modelle werden den Phasen der Softwareentwicklung gegenübergestellt und analysiert, inwieweit ein Modell diese Phasen berücksichtigt. Ebenso erörtern wir, inwieweit ein von uns beschriebenes agiles Modell diese Prozesse berücksichtigt.
3 Agile Softwareentwicklungsmodelle
Dieses Kapitel behandelt die Gemeinsamkeiten der agilen Softwareentwicklungs- Zuerst wird der Inhalt des Manifests der agilen Softwareentwicklung (auch agiles Manifest genannt) erläutert. Ausgehend vom agilen Manifest werden typische Eigenschaften der agilen Modelle abgeleitet. Am Ende des Kapitels wird noch auf die Einsatzbedingungen für agile Vorgehensweisen eingegangen.
3.1 Das Manifest der agilen Softwareentwicklung
Die verschiedenen agilen Softwareentwicklungsmodelle weisen trotz unterschied- Schwerpunkte Gemeinsamkeiten auf. Diese Gemeinsamkeiten sind im Manifest der agilen Softwareentwicklung festgehalten [Hruschka 2003 S. 1]. Das Manifest enthält die Richtlinien, die allen agilen Modellen zugrunde liegen und besagt folgendes:
• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen.
• Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen. Es ist anzumerken, dass die in diesem Manifest als weniger wichtig bezeichnete Werte nicht gänzlich in Frage gestellt werden. Diesen Werten ist nur im Zweifelsfall weniger Gewicht beizumessen als den Werten, die in dem Manifest als wichtiger angesehen werden [Eckstein 2004 S. 15].
Es folgt eine detaillierte Betrachtung der einzelnen Aussagen dieses Manifests. Dabei geben wir die vorherrschende Meinung wieder, die von den Autoren und Befürwortern agiler Softwareentwicklungsmodelle geprägt wird: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Die einzelnen am Prozess beteiligten Menschen stehen im Mittelpunkt. Die
Es ist denkbar, Software weitgehend ohne definierten Prozess und ohne Werkzeuge zu entwickeln, es ist aber völlig unmöglich, sie ohne ein qualifiziertes Team zu schreiben. Wenn die Mitglieder des Teams unprofessionell arbeiten, können weder gute Werkzeuge noch wohl definierte Prozesse für eine hohe Qualität der Software sorgen. Weiters haben alle agilen Modelle gemeinsam, dass sie mit einem möglichst geringen Satz an Prinzipien auszukommen versuchen. Diese sind besser umsetzbar, als seitenlange Dokumentationen von Prozessen. Dafür müssen einige traditionelle Ideen wie die Vorstellung vom einheitlichen, wiederholbaren Entwicklungsprozess aufgeben werden. Weiters gehen die Befürworter der agilen Modelle davon aus, dass man Projekte nicht detailliert durchplanen kann. Folglich kann man Projekte auch nicht durch Kontrolle und die Ausgabe klarer Anweisungen steuern [Coldewey 2002 S. 70].
Funktionierende Software ist wichtiger als umfassende Dokumentation. Agile Modelle versuchen, umfangreiche Dokumentation durch direkte Kommunikation im Team zu ersetzen. Dokumentationen haben den Nachteil, dass sie Fehlinformationen liefern können, da sie selten auf dem neuesten Stand sind. Oftmals ist es notwendig, Dokumentation zu erstellen, um den sicheren Betrieb zu gewährleisten. Laut Coldewey geschieht dies häufig erst dann, „wenn sich das System bereits stabilisiert hat“. In diesem Fall dienen die Dokumente nur dem Selbstzweck. Unnötige Dokumentation sollte vermieden und, wenn möglich, durch Kommunikation ersetzt werden [Coldewey 2002 S. 70]. Nur durch das funktionierende System, also den funktionierenden Code, ist feststellbar, was das Team geleistet hat [Cockburn 2003 S. 285].
Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen. Hier geht es um die Beziehungen zwischen den Personen, in deren Auftrag Software entwickelt wird, und jenen Personen, die Software entwickeln. Verträge können zwar nützlich sein, aber für die Entwicklung ist die tatsächliche Zusammenarbeit von
Das Manifest der agilen Softwareentwicklung 33 Kunden und Entwicklern entscheidend. Laut Cockburn kann gute Zusammenarbeit eine unklare Vertragssituation retten oder einen Vertrag sogar unnötig machen [Cockburn 2003 S. 285]. Bei vielen der heute üblichen Verträge zwischen Kunden und Auftraggeber wird sehr viel Wert auf die Absicherung im Falle des Scheiterns des Projekts gelegt. Das gemeinsame Ziel wird vernachlässigt [Martin 2002 S. 10]. Laut Coldewey würden diese Vertragsansätze nur funktionieren, „wenn eine eindeutige Spezifikation vorläge, wie die Software aussehen soll“ [Coldewey 2002 S. 70]. Eine vollständige Systemspezifikation ist nicht nur sehr schwierig zu erstellen, sondern auch extrem teuer.
Die Zufriedenheit des Kunden ist das wichtigste Maß bezüglich der Frage, inwiefern seine Bedürfnisse durch die Software gedeckt werden. Intensive Kundenorientierung ist daher die Voraussetzung, um den Kunden so gut wie möglich zufrieden stellen zu können [Eckstein 2004 S. 14]. Bei allen agilen Modellen erfolgt die Einbeziehung des Kunden in der Planung, bei manchen auch direkt in das Projekt. Voraussetzung ist aber, dass ein fachlicher Entscheidungsträger für Fragen jederzeit zur Verfügung steht [Coldewey 2002 S. 70].
Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen. Da zu Beginn des Projektes das Wissen über das System gewöhnlich am geringsten ist, ist es nahezu unmöglich, das Projekt ganz genau durchzuplanen. Während des Projektes können unvorhersehbare Ereignisse eintreten, das die ursprünglichen Schwerpunkte verändern kann [Martin 2002 S. 10].
Das Aufstellen eines Plans ist gemäß Cockburn sehr nützlich. Man hat aber nur so lange einen Nutzen von dem Plan, solange die aktuelle Situation noch diesem Plan entspricht. Es ist nutzlos, sich auf diesen zu berufen, wenn er nicht mehr aktuell ist [Cockburn 2003 S. 286]. Der Erfolg eines Projekts wird oftmals daran gemessen, ob der gegenwärtige Projektzustand mit dem Projektplan übereinstimmt. Wenn man einen Plan strikt befolgt, führt man das durch, was bei der Erstellung des Plans für notwendig gehalten wurde. Dies deckt sich laut Coldewey meistens nicht mit dem, was zum gegenwärtigen Zeitpunkt notwendig wäre. Man erhält möglicherweise das geplante Ergebnis, aber nicht das Ergebnis, dass man am Ende des Projekts braucht. Auch in agilen Projekten wird mit Plänen gearbeitet. An diesen Plänen orientiert man sich, bis sie aufgrund neuerer Erkenntnisse überholt sind. Spätestens am Ende eines Inkrements wird ein neuer Plan für das nächste Inkrement erstellt [Coldewey 2002 S. 71].
3.2 Eigenschaften der agilen Modelle
Aus dem agilen Manifest wurden von den Autoren und Befürworten der agilen Softwareentwicklungsmodelle zwölf Prinzipien für die Softwareentwicklung abgeleitet [Agile Manifesto Principles]:
• Frühe und kontinuierliche Lieferung von Software
• Prozessbegleitende Berücksichtigung von neuen oder geänderten
Anforderungen
• Regelmäßige Lieferung von Software innerhalb kurzer Releasezyklen
• Tägliche Zusammenarbeit von Anwendungsexperten und Entwicklern
• Motivation und Unterstützung der Mitarbeiter sowie Vertrauen in deren
Fähigkeiten
• Direkte Kommunikation zwischen Entwickler und Kunden sowie innerhalb
des Entwicklerteams
• Messung des Fortschritts primär durch lauffähige Software
• Effektivität durch gleich bleibende kontinuierliche Entwicklungsarbeit
• Ständige Aufmerksamkeit gegenüber technischer Qualität und guten Entwurf
• Schlichtheit: die Kunst, die Menge der nicht geleisteten Arbeit zu maximieren
• Selbstorganisation der Teams
• Regelmäßige Beratungen der Teams zur Steigerung ihrer Effektivität Eine in [Hruschka et al. 2003] aufgestellte Maxime zu den agilen Modellen beschreibt die Grundeinstellung in allen Bereichen der agilen Softwareentwicklung: „Eher Angemessenheit als Extremismus!“ Diese Maxime relativiert einige Aussagen von Kent Beck, dem Schöpfer des agilen Softwareentwicklungsmodells ‚Extreme Programming’ (XP), wobei diese von Beck mittlerweile moderater formuliert werden. Alles, was zur Erreichung der Projektziele getan wird, soll in keine Richtung
Eigenschaften der agilen Modelle 35 extrem werden und unter Einhaltung der Randbedingungen angemessen sein [Hruschka 2003 S. 2-3].
Eine weitere Eigenschaft agiler Vorgehensmodelle ist die Betonung der Ergebnisorientierung. Die Autoren der agilen Modelle haben in der Praxis die Erfahrung gemacht, dass oftmals anderen Werten mehr Bedeutung beigemessen wird. Daher streichen die agilen Modelle heraus, dass das Ziel der Softwareentwicklung beispielsweise nicht die Erstellung zahlloser Dokumente, sondern lauffähige Software sein soll.
Im Sinne der von Hruschka, Rupp und Stark aufgestellten Maxime schränkt Alistair Cockburn in [Cockburn 2003] diese Aussage ein: Das Hauptziel muss das lauffähige System sein. Für die Zeit nach der Auslieferung müssen jedoch Anpassungen sowie Wartung und Weiterentwicklung vorgenommen werden. Wie viel Zusatzaufwand und Zusatzdokumentation für dieses Aktivitäten notwendig ist, muss man für jedes Projekt selbst entscheiden. Um diese Leitlinie umsetzen zu können, bedarf es einer sorgfältigen Risikoabwägung. Risikomanagement ist daher eine Kerndisziplin aller agilen Modelle [Hruschka 2003 S. 3].
Die Spezialisierung auf bestimmte Modellierungstechniken wird bei agiler Vorgehensweise zurückgedrängt. Man arbeitet an allen Entwurfsmodellen gleichzeitig und entwirft nicht zuerst ein Anwenderfallmodell und dann das Datenmodell. Da es viel Zeit und Geld kostet, die Dokumentation ständig dem gegenwärtigen Stand des Quellcodes anzupassen, werden die Dokumente nur aktualisiert, wenn es unbedingt notwendig erscheint [Biffl 2004 S. 4]. Grundsätzlich sollen agile Modelle zur Erreichung der Ergebnisse gerade ausreichend sein. Der Faktor Kommunikation ist daher von größter Wichtigkeit. Die Autoren und Befürworter der agilen Modelle vertreten folgende Ansicht: Je besser die Kommunikation zwischen den am Projekt Beteiligten funktioniert, desto mehr kann man auf Zwischenergebnisse wie Anforderungsdokumente, Spezifikationen usw. verzichten [Hruschka 2003 S. 3].
Die Autoren der agilen Modelle betonen, den Entwicklungsprozess so einfach wie möglich zu gestalten. Das Ziel dabei ist die bessere Überschaubarkeit des Prozesses. Das bedeutet konkret, dass alles Unnötige weggelassen wird. Auch Entwurfsmodelle wie etwa UML-Diagramme können wegfallen, sobald alle Entwickler die Anforderungen verstanden haben [Biffl 2004 S. 4]. Die Zusammenarbeit mit dem Kunden, beginnend mit der Anforderungsanalyse, spielt bei allen Vertretern der agilen Modelle eine zentrale Rolle. Es ist wichtig, die
Bei agiler Vorgehensweise wird der Entwurf ohne bewusste Steuerung durchgeführt. Es gibt keine abgegrenzte Entwurfsphase und es findet keine bewusste Gestaltung statt [Stephens 2003].
3.3 Einsatzbedingungen der agilen Modelle
Bislang wurde behauptet, dass der agile Ansatz nur für kleine Teams und kleine bis mittelgroße Projekte geeignet ist. Dies trifft auf manche Modelle (wie z.B. XP) zu, die sehr konkrete Richtlinien anführen und den Entwicklern weniger Freiheiten bei der Umsetzung lassen. Andere Modelle sind jedoch hinsichtlich ihrer Praktiken weniger reglementiert, sodass sie auch in größeren Projekten eingesetzt werden können. Bis zum jetzigen Zeitpunkt gibt es jedoch wenig detaillierte Informationen, ob agile Modelle in größeren Projekten erfolgreich eingesetzt werden [Eckstein 2004 S. 17]. Jene Modelle, die konkrete Richtlinien vorgeben, sind zwar für kleine Projekte am besten geeignet, doch in [Eckstein 2004 S. 16] wird behauptet, dass einige Verfahren auch bei größere Projekte anwendbar sind. Indikatoren für ein kleines bzw. großes Projekt: Neben der Mitarbeiteranzahl bestimmen Indikatoren wie Projektumfang, Projektdauer und Kosten die Größe eines Projekts. Diese verschiedenen Faktoren sind abhängig voneinander. Wenn viele Personen in einem Projekt arbeiten, so werden auch Projektumfang, Projektdauer und Kosten eine entsprechende Größe haben [Eckstein 2004 S. 3-4].
Zusammenfassung 37 Damit agile Modelle wie XP, die grundsätzlich für kleinere Projekte ausgerichtet sind, in großen Projekten angewendet werden können, muss man sie anpassen. Das bedeutet, dass diese Modelle adaptiert werden müssen, um die Grundsätze des agilen Manifests nicht zu verletzen. Als Beispiel sollen an dieser Stelle die Projektmitglieder angeführt werden, die trotz der verschiedenen Teilteams miteinander kommunizieren müssen. Ist dies nicht der Fall, besteht das Risiko, dass die Mitglieder nicht auf das gleiche Ziel hin arbeiten. In der Literatur wird angemerkt, dass dies in der Praxis häufig so ist. Projektmitglieder identifizieren sich oft nicht mit den Zielen und deshalb kann auch nicht auf ein gemeinsames Ziel hingearbeitet werden. Kommunikation und Feedback sind wesentliche Merkmale der Agilität, unabhängig von der Projekt- und Teamgröße [Eckstein 2004 S. 75-78]. Daran ist zu erkennen, dass nicht die Größe eines Projektes ausschlaggebend für den Einsatz eines schwergewichtigen oder leichtgewichtigen Modells ist, sondern die interne Organisation des Teams und die Umsetzung der Prinzipien. Hat man eine große Anzahl an Mitarbeitern, so muss die interne Kommunikation der Teams anders gestaltet werden als bei wenigen Teilnehmern.
Die agilen Modelle werden in Projekten mit einem dynamischen Umfeld und in Projekten, bei denen zu Beginn die Kundenanforderungen unvollständig und unklar sind, eingesetzt. Da sich die Wünsche der Kunden ständig ändern können, ändern sich auch die Rahmenbedingungen und die Anforderungen während des gesamten Projekts. Kennzeichnend für die agilen Modelle sind der hohe Zeitdruck und die Projektrisiken, auf die in Kapitel 6 detailliert eingegangen wird. Diese Risiken werden bewusst in Kauf genommen, da auf eine Risikominimierung durch Vorausplanung, Dokumentation und Regeln - wie bei schwergewichtigen Verfahren
- großteils verzichtet wird. Deshalb setzt die Agilität hohe Professionalität und Qualifikation aller Beteiligten voraus. Jeder Einzelne muss Verantwortung übernehmen und darf sie nicht an andere Mitarbeiter übertragen.
3.4 Zusammenfassung
Das Manifest der agilen Softwareentwicklung enthält die Richtlinien, auf denen alle agilen Softwareentwicklungsmodelle aufbauen. Diese Richtlinien betonen die Wichtigkeit von Individuen, funktionierender Software, Change Management und die Zusammenarbeit mit Kunden für die agile Softwareentwicklung. Daraus lassen sich Prinzipien ableiten, die bei allen agilen Modellen beachtet werden. Hierbei sind vor allem die frühe und kontinuierliche Lieferung von lauffähiger Software sowie die Selbstorganisation der Entwicklerteams zu nennen.
4 Ausgewählte Vertreter agiler Modelle
Wir beschreiben in diesem Kapitel agile Softwareentwicklungsmodelle, denen in der Literatur große Aufmerksamkeit geschenkt wird, weil sie einen hohen Bekanntheitsgrad aufweisen. Hierfür haben wir zwei Kriterien festgelegt. Zum einen muss das Modell in Buchform erschienen sein. Weiters müssen bei Eingabe entsprechender Suchbegriffe in der Internetsuchmaschine „Google“ mehr als 500 Ergebnisse zu dem gesuchten Modell gefunden werden. Wir unterscheiden in dieser Arbeit zwischen Entwicklungsmodellen und Managementmodellen. Entwicklungsmodelle präsentieren relativ konkrete Prozesse, wie man Software agil entwickeln kann, und stellen dokumentierte Praktiken zur Verfügung. Bei diesen Modellen handelt es sich um Extreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM) und Agile Modeling (AM). Die Managementmodelle stellen den Managementansatz in den Vordergrund und überlassen den Teams die Entscheidung, wie sie einen konkreten Prozess festlegen. Zu diesen Modellen zählen Adaptive Software Development (ASD), Lean Development (LD), Scrum und die Crystal-Modellfamilie. Diese acht Modelle werden hinsichtlich ihrer Phasen, Praktiken und Rollen untersucht und abschließend bewertet.
Nicht berücksichtigt werden in dieser Arbeit die Modelle Internet-Speed Development und XBreed, da es bis zum Jahr 2004 noch keine Bücher zu diesen Modellen gibt und die Anzahl an Suchergebnisse bei „Google“ am 26.06.2004 deutlich weniger als 500 betrug. Open Source Software Development wurde nicht mit aufgenommen, da es keine Sammlung von definierten und veröffentlichten Softwarepraktiken ist, und kein beschriebenes eloquentes Modell bildet. Auch Pragmatic Programming stellt kein eigenes Modell dar. Es enthält eine Menge an Programmierpraktiken aus anderen Modellen, aber Pragmatic Programming definiert keinen Prozess, keine Phasen und keine Rollen. Weiters lieferte „Google“ am 26.06.2004 weniger als 400 Ergebnisse für Pragmatic Programming. Der Rational Unified Process (RUP) wurde ausgegrenzt, da dieser kein wirkliches agiles Modell darstellt. RUP kann man zwar agil anpassen, aber er ist dennoch ein schwergewichtiges Modell und folgt demnach anderen Grundprinzipien als die agilen Modelle.
4.1 Problemstellung und Zielsetzung
Wir teilen die ausgewählten agilen Modelle in konkrete Entwicklungsmodelle und Managementmodelle ein, erläutern die charakteristischen Merkmale und ermitteln in weiterer Folge die Stärken und Schwächen. Die Modellbeschreibungen sollen umfassende Erkenntnisse liefern, um sie aus neutraler Sicht bewerten und daraus Stärken und Schwächen ableiten zu können.
4.2 Hinweise zu den Originalquellen
Bis Ende Juni 2004 wurden acht verschiedene agile Modelle in Buchform beschrieben. Die Originalliteratur liegt in Form folgender Bücher vor:
• K. Beck: Extreme Programing Explained, Addison-Wesley Professional,
2000
• S. Palmer, J. Felsing: A Practical Guide to the Feature-Driven Development,
Prentice Hall PTR, 2002
• J. Stapleton: DSDM - Business Focused Development; Addison-Wesley,
2003
• S. Ambler: Agile Modeling, John Wiley & Sons, 2002
• J. Highsmith: Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems, Dorset House Publishing Company, 2000
• M. Poppendieck, T. Poppendieck: Lean Software Development, Addison-Wesley Professional, 2003
• M. Beedle, K. Schwaber: Agile Software Development with Scrum, Prentice
Hall, 2002
• A. Cockburn: Agile Software Development, Addison-Wesley Professional,
2001
4.3 Konkrete Entwicklungsmodelle
Die konkreten Entwicklungsmodelle unterbreiten Vorschläge, wie die Teams Software agil entwickeln können. Der Schwerpunkt liegt darin, wie man Projekte aufbauen kann, wenn man die dem jeweiligen Modell zugrunde liegenden Prinzipien beachtet. Hierfür stellen diese Modelle Praktiken zur Verfügung [Coldewey 2002 S. 73].
Zu Beginn erläutern wir XP, weil es das bekannteste Modell ist und es die meisten empirischen Studien zu diesem Modell gibt (vgl. Abrahamsson et al. 2003 S. 7).
Konkrete Entwicklungsmodelle 41 Danach folgen Erläuterungen zu FDD und DSDM, die im Gegensatz zu XP weniger konkret beschrieben sind. Den Abschluss in der Gruppe der konkreten Modelle bildet AM, da es nicht als eigenständiges Modell anwendbar ist, sondern als Ergänzung zu anderen Softwareentwicklungsmodellen konzipiert wurde. Wir erläutern es aber trotzdem, da es in der Literatur oft erwähnt wird und AM in Bezug auf die Modellierung, welche einen wichtigen Bereich der Softwareentwicklung darstellt, präziser ist als die anderen Modelle.
4.3.1 Extreme Programming (XP)
XP ist das bekannteste agile Softwareentwicklungsmodell und wurde Mitte der 90er Jahre von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt [Coldewey 2002 S. 74]. XP ist als Sammlung von bewährten Praktiken (engl. Best Practices) anzusehen, mit denen man Software effizient und rasch entwickeln kann. Das Modell konzentriert sich auf die Abwicklung von Projekten mit sich häufig ändernden Anforderungen, was im Laufe der Zeit zu hohen Änderungskosten führen kann. Die Kosten steigen im Gegensatz zu schwergewichtigen Entwicklungsmodellen nur anfänglich und bleiben im Laufe des Projektes konstant. Der Kurs von XP ist vergleichbar mit einer Autofahrt, wo der Weg jederzeit den Gegebenheiten angepasst werden kann. Das Projekt wird vom Kunden gesteuert, der von den Softwareentwicklern Feedback über den aktuellen Stand erhält [Beck 2000 S. 154]. Diese Vorgehensweise birgt die Gefahr in sich, dass durch zahlreiche und kurzfristige Änderungen die vorgeschlagenen Arbeitstechniken (Praktiken) nicht beachtet werden (siehe Kapitel „Praktiken bei XP“, S. 46). Konflikte zwischen kurzfristigen und langfristigen Zielen werden deshalb in Gruppen auf der Basis folgender vier Werte ausgetragen [Beck 2000 S. 29-35]: Kommunikation (engl. Communication): Der Kommunikationsfluss muss zwischen allen Beteiligten aufrecht erhalten und mögliche Kommunikationsprobleme eruiert und beseitigt werden. Probleme werden besprochen und Lösungsalternativen vorgeschlagen.
Einfachheit (engl. Simplicity): Ein Problem muss auf die einfachste Art gelöst werden und das Projektteam soll sich nicht mit zukünftigen Fragestellungen auseinander setzen.
Rückmeldung (engl. Feedback): Der Zustand des Systems bzw. des Projekts muss erfasst werden und regelmäßige Rückmeldungen liefern. Diese Rückmeldungen
Mut (engl. Courage): Mut wird benötigt, um überflüssigen Code zu entfernen und um Fehler von anderen Entwicklern auszubessern. Dadurch sollen Probleme rasch erkannt und der Projekterfolg langfristig gesichert werden. Um diese vier Werte in die Praxis umzusetzen, müssen konkrete Prinzipien abgeleitet werden. Diese zentralen Prinzipien werden nach [Beck 2000 S. 37-38] wie folgt beschrieben:
Schnelle Rückmeldung (engl. Rapid feedback): Die Zeit zwischen einer Aktion und einer Rückmeldung ist entscheidend für das Lernen. Nur wenn diese Zeit kurz ist, kann man einen effektiven Lernnutzen daraus ziehen.
Einfache Lösung (engl. Assume simplicity): Dieses Prinzip betont, dass ein flexibles Vorgehen bei der Softwareentwicklung wichtig ist, da sich Kundenwünsche häufig ändern können und es deshalb entscheidend ist, auf diese neuen Anforderungen einzugehen.
Inkrementelle Änderungen (engl. Incremental change): Änderungen werden in vielen kleinen Schritten durchgeführt, und nicht in einem einzelnen großen Schritt. Wird etwas geändert, muss es auf Fehler überprüft werden.
Änderungen erwarten (engl. Embracing change): Dies besagt, dass das dringendste Problem zuerst gelöst und weitere Optionen bewahrt werden sollen. Qualitätsarbeit (engl. Quality work): Die Beteiligten sollen nach hochwertigen Arbeitsergebnissen streben, um die Projektziele zu erreichen. Kennzeichnend für XP ist, dass versucht wird, die miteinander in Konflikt stehenden Variablen der Softwareentwicklung, Qualität, Zeit (Projektdauer) und Kosten konstant zu halten und die Erfüllung der Projektziele durch die abhängige Variable Quantität (Umfang) zu messen. Nimmt man von einer Variable mehr Kapazität in Anspruch, so führt das zu einer Reduzierung von Kapazität für die anderen Variablen. Dies bezeichnet man als so genanntes „Teufelsquadrat“. Es gibt Aufschluss darüber, welche dieser vier Variablen im Falle von Konflikten Priorität bei der Nutzung einer gegebenen Kapazität an Personal und Sachmitteln hat [Heinrich 2001a S. 40]. Durch die folgende Abbildung 1 wollen wir das „Teufelsquadrat“ näher veranschaulichen:
Konkrete Entwicklungsmodelle 43
Abbildung 1: Teufelsquadrat nach Sneed 4
Das in Abbildung 1 blau hinterlegte Quadrat zeigt, dass eine Inanspruchnahme von Kapazität einer Variable zu einer Reduzierung von Kapazität für die anderen Variablen führt. Deshalb der Begriff „Teufelsquadrat“.
XP wird in Projekten mit kleinen, disziplinierten Teams eingesetzt, die Aspekte wie Kommunikation, Feedback oder Einfachheit konsequent berücksichtigen. Man kann nicht nur langlebige Software erstellen, sondern muss auch während der Entwicklung auf ungenaue und sich rasch ändernde Anforderungen reagieren, da der Kunde jederzeit seine Bedürfnisse äußern kann. Es wird weniger Zeit in die Planung gesteckt und man beginnt früher als bei anderen Prozessmodellen mit der Implementierung. Ziel ist die Beseitigung von Schwachstellen, die in den unterschiedlichen Projekten auftreten können. Schwachstellen sind Personalschwund durch Unzufriedenheit und Druck im Projektteam, Schwerfälligkeit und hohe Kosten bei Projektänderungen, sowie ein hoher Aufwand für die Herstellung von Planungs-und Entwurfsdokumenten [Csallner et al. 2001 S. 7]. Damit die Software am Ende die vom Kunden benötigte Qualität hat, müssen die Regeln „Develop for today“ oder „Do the simplest thing that could possibly work“ beachtet werden. Das bedeutet, dass man sich ausschließlich auf die aktuellen Probleme konzentriert und jene, die später anstehen, nicht beachtet. Man geht davon
4.3.1.1 Phasen bei XP
Der XP-Life-Cycle besteht aus sechs Phasen. In Anlehnung an [Beck 2000 S. 131-
137] stellen wir diese wie folgt dar:
Planung
Abbildung 2: XP-Life-Cycle in Anlehnung an [Beck 2000 S. 131-137]
Die in Abbildung 2 dargestellten Pfeile bedeuten, dass nach dem Ende der einen Phase die nächste folgt. Eine Phase ist dann beendet, wenn die Ergebnisse geliefert werden. Im Folgenden werden die einzelnen Phasen mit ihren Ergebnissen erörtert: Erforschung (engl. Exploration): In dieser Phase gibt der Kunde jene Anforderungen an, welche im ersten Release berücksichtigt werden müssen. Jede dieser Anforderungen beschreibt ein Feature, das in das Programm aufgenommen werden muss. Das Projektteam macht sich mit den im Projekt verwendeten Werkzeugen, Praktiken und Technologien vertraut. Es werden hierbei Architekturvorschläge
Konkrete Entwicklungsmodelle 45 erstellt und Leistungsgrenzen der Technologie abgewogen. Weiters werden die Programmieraufgaben bezüglich Aufwand und Lösbarkeit eingeschätzt und eine Vertrauensbasis zwischen den Teammitgliedern geschaffen [Beck 2000 S. 131], [Abrahamsson et al. 2004 S. 20].
Planung (engl. Planning): Kennzeichnend für diese Phase ist das Aufstellen eines realistischen Terminplans und das Aufteilen in Iterationen. Die wichtigsten Probleme müssen am Beginn gelöst werden. Dazu müssen Reviews durchgeführt werden. Das erste Release sollte nach zwei bis sechs Monaten erfolgen. Erfolgt das Release zu früh bzw. zu spät, so besteht die Gefahr, dass entscheidende Probleme nicht gelöst werden können und erhöhte Risiken auftreten [Beck 2000 S. 133]. Iterationen (engl. Iterations): Die Planung ist durch ein- bis vierwöchige Iterationen gekennzeichnet, welche eine Reihe von funktionalen Testfällen für die Anforderungen liefern. In jeder Phase der Iteration gibt es Eingaben, Aktivitäten und Ergebnisse. Bei der Entwicklung werden alle Aktivitäten einer Prüfung unterzogen. Die Freigabe und der Betrieb erfolgt erst, wenn keine Korrektur mehr erforderlich ist. Zu beachten ist, dass man sich nicht in technische Details verirrt, dass man Planabweichungen laufend kontrolliert und dass automatische Testfälle und Integrationstests laufend erstellt und durchgeführt werden. Wenn Abweichungen vom Plan erkannt werden, muss entweder der Plan (durch hinzunehmen bzw. entfernen von Anforderungen) oder der Prozess geändert werden. Wichtig ist, dass am Ende jeder Iteration der Kunde die Funktionstests beendet hat und mit dem Ergebnis zufrieden ist. Am Ende der letzten Iteration wird „in Produktion gegangen“ [Beck 2000 S. 133-134].
In Produktion gehen (engl. Productionizing): Diese Phase umfasst die Entwicklungsumgebung, die Testumgebung und die Produktionsumgebung. In der Entwicklungsumgebung wird das Produkt entwickelt. In der Testumgebung wird dem Tester eine konsistente Umgebung zur Verfügung gestellt und in der Produktionsumgebung wird für alle Kunden der aktuelle Release - Stand generiert und nachher installiert [Beck 2000 S. 134], [Abrahamsson et al. 2004 S. 20].
Wartung (engl. Maintenance): Nach dem das Produkt zum ersten Mal freigegeben wurde, muss ein nach XP entwickelndes Projekt sowohl das vorhandene System am Laufen halten als auch neue Iterationen festlegen. Ebenso werden in dieser Phase neue Leute in das Team aufgenommen und ausscheidende Mitglieder ersetzt [Beck 2000 S. 135], [Abrahamsson et al. 2004 S. 20-21].
4.3.1.2 Praktiken bei XP
Die Technik des Extreme Programming basiert auf zwölf grundlegenden Praktiken oder Säulen. Voraussetzung für das Gelingen von XP-Softwareprojekten ist nach Vorgabe des Modellentwicklers die gesamte Anwendung aller zwölf Säulen: Das Planungsspiel (engl. The Planning Game): Hier wird der Umfang der jeweils nächsten Programmversion festgelegt. Einerseits werden die erweiterten Funktionalitäten festgesetzt, andererseits wird dem Programmierer eine Aufwandsschätzung ermöglicht. Die Iterationen werden in einer Art Spiel von den Entwicklern zusammen mit den Kunden geplant. Dabei stehen typische Anwendungsfälle (engl. User Stories), im Mittelpunkt. Vor jeder Iteration muss das Planungsspiel erneut durchgeführt werden [Beck 2000 S. 55], [Coldewey 2002 S. 74], [Csallner et al. 2001 S. 8].
Kurze Releasezyklen (engl. Small releases): Es werden Releasezyklen von nur wenigen Monaten durchgeführt, damit man auf das Kunden-Feedback rasch reagieren kann und nicht die Gefahr besteht, monatelang in die falsche Richtung zu arbeiten. Durch ein Feedback erspart sich das Entwicklerteam eine Menge Zeit, weil u. a. Missverständnisse schnell geklärt werden können [Beck 2000 S. 56], [Coldewey 2002 S. 74], [Csallner et al. 2001 S. 8]. Metapher (engl. Metaphor): Was bei schwergewichtigen Modellen die Systemarchitekturplanung ist, ist bei XP die Metapher. Alle technischen Komponenten werden mit Begriffen aus der realen Welt so beschrieben, dass die Projektgegebenheiten intuitiv besser verständlich sind. Dadurch sollen die Programmierer unterstützt und das Einbinden von neuen Mitgliedern in das Programmierteam erleichtert werden [Beck 2000 S. 56-57], [Coldewey 2002 S. 75], [Csallner et al. 2001 S. 8].
Konkrete Entwicklungsmodelle 47 Einfacher Entwurf (engl. Simple design): Der Entwurf sollte einfach gehalten werden, er muss allerdings folgende Eigenschaften erfüllen [Beck 2000 S. 57], [Coldewey 2002 S. 74-75], [Csallner et al. 2001 S. 8]:
• er besteht alle Tests
• er weist keine Redundanzen auf
• er widerspiegelt die Absicht der Entwickler
• er weist die kleinstmögliche Anzahl an Klassen und Methoden auf Es darf bei jeder Iteration nur das implementiert werden, was nötig ist. Das bedeutet, dass der Entwurf zu jeder Zeit die zuvor definierten Kriterien erfüllen muss, ohne auf zukünftige Entwicklungen besonders Rücksicht zu nehmen.
Testen (engl. Testing): Testen ist ein sehr wesentlicher Punkt von XP. Es existiert für jede vom Kunden benötigte Funktion ein Test. Wird etwas am Code geändert, müssen alle Testfälle erneut durchlaufen werden. Will man den Zeitaufwand minimieren, der beim Testen anfällt, sollten automatisierte Testumgebungen eingesetzt werden. Dadurch ist es möglich, die Korrektheit eines Systems ständig, auch nach kleinen Änderungen zu überprüfen. Entwickler führen Modultests und die Kunden Funktionstests durch. Wird ein Fehler im Code entdeckt, werden zunächst die Testfälle ergänzt, und dann der Code. Man erwartet sich dadurch eine hohe Testabdeckung und ein beiderseitiges Vertrauen in das Produkt [Beck 2000 S. 57- 58], [Coldewey 2002 S. 74-75], [Csallner et al. 2001 S. 9]. Umbau (engl. Refactoring): Das bedeutet, dass die Softwareentwickler das Programm restrukturieren, ohne Funktionen zu ändern. Das Ziel ist, es ständig zu verbessern, zu vereinfachen und dabei die volle Funktionalität zu erhalten. Dies hat die Erhaltung der Änderungsfähigkeit und niedrige Änderungskosten zur Folge. Refactoring wird nach erfolgreichem Abschluss eines Auftrags durchgeführt. Es setzt automatisierte Modultests voraus. Wird kein automatisierter Test durchgeführt, so ist die Gefahr groß, dass funktionstüchtige Komponenten anderer Teile beeinflusst werden [Link 2002a S. 8].
Programmieren in Paaren (engl. Pair Programming): Bei einem Projekt, das mit XP abgewickelt wird, arbeiten im Normalfall immer zwei Programmierer an einem Rechner zusammen. Während die Person, die gerade am Rechner arbeitet, sich Gedanken über die zu implementierende Funktion macht, sollte der andere Testfälle planen oder Refactoring - Möglichkeiten prüfen. Die Rollen sollen abwechselnd besetzt werden, damit der Code einer genaueren Begutachtung unterzogen wird und sich das Wissen über alle Systemkomponenten auf alle Programmierer verteilt [Beck 2000 S. 58-59], [Coldewey 2002 S. 75], [Csallner et al. 2001 S. 9].
Fortlaufende Integration (engl. Continuous integration): Der neue Code wird hier ständig getestet und integriert. Das Programmierpaar, das den Code entwickelt hat, nimmt die Integration vor. Dies passiert in der Regel mehrmals am Tag. Wenn alle Testfälle durchlaufen sind, dann ist die Integration abgeschlossen [Beck 2000 S. 59- 60], [Coldewey 2002 S. 75], [Csallner et al. 2001 S. 9]. 40-Stunden-Woche (engl. 40-hour week): Wird ein Projekt mit dem XP - Vorgehensmodell abgewickelt, so soll in der Regel nicht länger als 40 Stunden in der Woche gearbeitet werden. Denn Überstunden sind ein Zeichen für Probleme, und da unter Stress entstandener Code meist weniger Qualität aufweist, sollen Überstunden vermieden werden [Beck 2000 S. 60]. Die festgesetzten Termine bleiben unverändert, der Arbeitsumfang kann hier jedoch variieren, indem bestimmte Benutzeranforderungen erst in einer der nächsten Iterationen umgesetzt werden [Coldewey 2002 S. 75].
Kunde vor Ort (engl. On-site customer): Der Kunde, der mit dem System arbeitet, sollte bei der Entwicklung anwesend sein, um etwaige Fragen rasch klären zu können. Man möchte durch das direkte Feedback Missverständnisse von vornherein vermeiden [Beck 2000 S. 60-61], [Coldewey 2002 S. 74]. Neben der Kommunikation mit den Entwicklern kann der Kunde während des Projektes seine Alltagsarbeit verrichten, bleibt dabei aber vor Ort [Csallner et al. 2001 S. 8]. Programmierstandards (engl. Coding standards): Da mehrere Programmierer an einem Code arbeiten, ist es sehr wichtig, grundlegende Programmierstandards festzulegen. Zu beachten ist u. a. die Namenskonvention für die Variablen oder Quellcode-Formatierungsvorgaben. Darüber hinaus sollten die Richtlinien eines guten Programmierstils eingehalten werden, wie z. B. Einrückungen im Quellcode, keine Mischung von deutschen und englischen Begriffen und aussagekräftige Variablen- und Klassennamen. Dieser Standard soll von allen Programmierern akzeptiert werden [Beck 2000 S. 61], [Coldewey 2002 S. 75], [Csallner et al. 2001 S. 9].
Konkrete Entwicklungsmodelle 49 4.3.1.3 Rollen bei XP
In einem Projektteam arbeiten mehrere Personen zusammen. Sie haben unterschiedliche Tätigkeiten und Verantwortungsbereiche. XP sieht für die unterschiedlichen Projektaufgaben folgende Rollen vor [Beck 2000 S. 141-148]: Programmierer (engl. Programmer): Der Programmierer hält den Programmcode so einfach als möglich und schreibt Modultests, die sicherstellen sollen, dass das Programm keine Fehler aufweist. Er schätzt den Aufwand zur Umsetzung der Kundenanforderungen und kommuniziert mit anderen Programmierern und Teammitgliedern.
Kunde (engl. Customer): Der Kunde äußert seine Wünsche und schreibt Abnahmetests. Er entscheidet, wann die Anforderungen erfüllt sind und setzt Prioritäten für die Reihenfolge der zu implementierenden Anforderungen. Tester (engl. Tester): Der Tester unterstützt den Kunden beim Schreiben der Abnahmetests. Er führt regelmäßige Abnahmetests durch und veröffentlicht die Testergebnisse.
Terminmanager (engl. Tracker): Der Terminmanager liefert Informationen über den Projektfortschritt. Er kommuniziert ständig mit den Programmierern und erkundigt sich, ob der vorgegebene Zeitplan eingehalten werden kann. Bei Problemen leitet er Gegenmaßnahmen ein.
Trainer (engl. Coach): Der Trainer ist einerseits für den Gesamtprozess und andererseits für das Einhalten der von XP vorgeschriebenen Praktiken verantwortlich.
Berater (engl. Consultant): Der Berater ist ein externes Mitglied mit dem notwendigen technischen Wissen und unterstützt das Team beim Lösen spezifischer Probleme.
Projektmanager (engl. Big Boss): Der Manager als Bindeglied zwischen Kunden und Entwickler sorgt für deren Kommunikation, plant Treffen und kümmert sich um projektspezifische Probleme der Beteiligten. Er muss Konflikte innerhalb des Teams ansprechen und lösen.
4.3.1.4 Bewertung von XP
XP ist das bekannteste agile Modell. Dies zeigt sich durch die vielen modellspezifischen Fachartikel und Bücher. Es ist jedoch nicht für jedes Projekt
4.3.2 Feature Driven Development (FDD)
FDD wurde Mitte der 90er Jahre von Jeff DeLuca und Peter Coad entwickelt. Es konzentriert sich auf kurze, maximal zweiwöchige Iterationen, die eine greifbare Funktionalität liefern. FDD sieht ein wöchentliches, maximal 30-minütiges Treffen vor, wo der Status der Features diskutiert und ein Bericht darüber geschrieben wird [Paetsch et al. 2002 S. 4].
4.3.2.1 Phasen bei FDD
FDD besteht aus fünf Phasen. Diese werden von [Palmer und Felsing 2002 S. 56-59] und [Coldewey 2002 S. 75-76] wie folgt beschrieben: Entwickeln eines Gesamtmodells (engl. Develop an Overall Model): Der Kunde äußert seine Wünsche und Vorstellungen, die das System leisten soll. Anschließend wird der Aufgabenumfang festgelegt und eine erste Zerlegung durchgeführt. Die notwendigen Eigenschaften („Need-to-have“) werden von den nicht unbedingt notwendigen („Nice-to-have“) getrennt. Einzelne Teams erstellen dann unter der
Konkrete Entwicklungsmodelle 51 Leitung eines Chefarchitekten Modelle für die Teilgebiete. Am Ende der Phase werden diese Modelle integriert und im weiteren Projektverlauf gepflegt. Erstellen einer Feature Liste (engl. Build a Features List): Im nächsten Schritt wird von den einzelnen Teams eine Liste von Features gebildet, die implementiert werden und einen wirtschaftlichen Nutzen schaffen. Ein Feature sollte innerhalb von zwei Wochen realisiert und getestet werden können. Ist die Liste erstellt, wird von Chefprogrammierern ein Plan aufgestellt.
Planung pro Feature (engl. Plan By Feature): Zunächst wird ein Planungsteam, bestehend aus dem Projektmanager, dem Entwicklungschef und den Chefprogrammierern gebildet. Dieses Team legt die Reihenfolge und das Datum der zu implementierenden Features fest. Anschließend werden den Entwicklern Klassen zugeordnet, für die sie verantwortlich sind. Die Chefprogrammierer übernehmen die Verantwortung für die Features.
Entwurf pro Feature (engl. Design By Feature): In der vierten Phase werden den Chefprogrammierern Features vorgelegt. Diese suchen sich dann die Features aus und stellen dementsprechend ein Team zusammen, das für den Entwurf verantwortlich ist. Darüber hinaus aktualisieren die Entwickler gemäß dem festgelegten Entwurf die Klassen mit den Methoden.
Implementierung pro Feature (engl. Build By Feature): Die in der vorigen Phase deklarierten Methoden werden von den Entwicklern implementiert. Anschließend inspiziert das Team unter der Leitung der Chefprogrammierer den Code für die implementierten Methoden. Die hier auftretenden Fehler werden an die Entwickler weitergeleitet. Diese führen Modultests durch und zeigen, dass die restlichen Methoden der Klasse nach der Implementierung des Features weiterhin korrekt funktionieren. Eine erfolgreich implementierte und getestete Klasse wird im Konfigurationsmanagementsystem freigegeben.
Abbildung 3 zeigt die fünf Phasen mit der jeweiligen Einstiegsbedingung und dem Ergebnis. Die beiden letztgenannten Phasen sind iterativ, das bedeutet, dass sie mehrmals - für jedes Feature - ausgeführt werden [Palmer und Felsing 2002 S. 58]:
Abbildung 3: Fünf Phasen des FDD
4.3.2.2 Praktiken bei FDD
FDD ist wie XP eine Sammlung von bewährten Praktiken. Die Modellentwickler von FDD betonen, dass die Praktiken nicht neu sind, durch die spezielle Anwendung sind die fünf Phasen aber einzigartig. Um den größten Nutzen des Modells zu bekommen, müssen alle im Folgenden beschriebenen Praktiken eingesetzt werden [Palmer und Felsing 2002 S. 36-54]:
Darstellen des Problembereichs (engl. Domain Object Modeling): Dies umfasst die Erforschung und Erläuterung des Problembereichs. Dazu verwendet man Klassendiagramme, welche die Eigenschaften der Objekte innerhalb eines Problembereichs und deren Beziehungen darstellen.
Konkrete Entwicklungsmodelle 53 Entwickeln pro Feature (engl. Developing by Feature): Entwickeln und Nachvollziehen des Fortschritts durch eine Liste von kleinen kundenspezifischen Funktionen.
Individuelle Klassenverantwortlichkeit (engl. Individual Class Ownership): Für jede Klasse ist eine Person für die Konsistenz und die konzeptionelle Integrität verantwortlich.
Festlegen der Feature Teams (engl. Feature Teams): Diese Teams führen Entwurfstätigkeiten in kleinen Gruppen durch. Wesentliches Merkmal ist das Einfließen von unterschiedlichen Ansichten in die Entwurfsentscheidung. Bevor man sich für einen Entwurf entscheidet, werden die unterschiedlichen Vorschläge bewertet.
Inspektion (engl. Inspections): Dies umfasst zwei wesentliche Ziele. Zum einen müssen Fehler rasch identifiziert werden und zum anderen steht der Wissenstransfer im Mittelpunkt. Hierbei sollen weniger erfahrene Entwickler rasch die Programmierrichtlinien erlernen.
Regelmäßiger Aufbau (engl. Regular Builds): Dadurch sollen die Integrationsfehler so rasch als möglich veranschaulicht werden. Das Ziel ist es, zu jeder Zeit ein aktuelles System zur Verfügung zu haben, dass dem Kunden vorgeführt werden kann.
Konfigurationsmanagement (engl. Configuration Management): Das Konfigurationsmanagement ermöglicht die Identifikation und das Nachvollziehen der aktuellsten Versionen des Quellcodes.
Fortschrittskontrolle (engl. Progress Reporting): Hierbei erfolgt eine ständige und genaue Fortschrittskontrolle in allen Bereichen, d. h. sowohl außerhalb als auch innerhalb des Projekts.
4.3.2.3 Rollen bei FDD
FDD teilt die Rollen in die Kategorien Schlüsselrollen (engl. Key Roles), Unterstützende Rollen (engl. Supporting Roles) und Weitere Rollen (engl. Additional Roles) ein. Diese werden nach [Palmer und Felsing 2002 S. 28-33] wie folgt beschrieben:
Projektmanager (engl. Project Manager): Er ist für den administrativen und finanziellen Bereich verantwortlich. Er muss das Team vor äußeren Einflüssen schützen und für passende Arbeitsbedingungen sorgen. Darüber hinaus muss er den Projektumfang, den Projektplan und die Projektbesetzung festlegen. Chefarchitekt (engl. Chief Architect): Er ist verantwortlich für den Entwurf und stellt diesbezüglich auch die letzte Entscheidungsinstanz dar. Diese Rolle kann bei komplexen Projekten in einen „Domain-Architect“ und einen „Technical Architect“ aufgeteilt werden.
Entwicklungsmanager (engl. Development Manager): Er leitet alle Aktivitäten bezüglich der Entwicklung und löst die Probleme, die im Team auftreten können. Die Aufgaben des Entwicklungsmanagers können kombiniert werden mit jenen des Chef-Architekten oder des Projektmanagers.
Chefprogrammierer (engl. Chief Programmer): Er ist ein erfahrener Entwickler, der für die Anforderungsanalyse und den Entwurf verantwortlich ist. Er leitet hierbei kleine Teams in den Bereichen Analyse, Entwurf und Entwicklung neuer Features. Zusätzlich kommuniziert er mit anderen Chefprogrammierern und berichtet wöchentlich von den Fortschritten.
Klassenverantwortlicher (engl. Class Owner): Er arbeitet unter der Führung von Chefprogrammierern in den Aufgabenbereichen Entwurf, Codierung, Testen und Dokumentation. Er muss jene Klassen implementieren, für die er verantwortlich ist. Der Klassenverantwortliche formt die Feature Teams.
Domainexperte (engl. Domain-Expert): Er kann ein Kunde, ein Benutzer oder ein Analyst sein. Er muss die unterschiedlichen Anforderungen des Systems während der Entwicklung kennen. Er reicht das Wissen an die Entwickler weiter, um die Leistungsfähigkeit des Systems sicherzustellen. Unterstützende Rollen
Domainmanager (engl. Domain-Manager): In größeren Projekten leitet er den Domain-Experten und ist weiters für die Anforderungen verantwortlich. Diese Rolle wird in kleineren Projekten von Projektmanagern ausgeübt. Releasemanager (engl. Release-Manager): Er kontrolliert den Projektfortschritt, in dem er die Berichte des Chefprogrammierers begutachtet bzw. bei Unklarheiten
- Arbeit zitieren
- Mag. Thomas Ecker, Michael Wesinger (Autor:in), 2005, Stärken und Schwächen agiler Softwareentwicklungsmodelle, München, GRIN Verlag, https://www.grin.com/document/186037
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.