Leseprobe
Inhaltsverzeichnis
Vorwort
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
Abstract
1. Einleitung
2. Traditionelle Programmierung
3. Extreme Programming
4. Methodik: Extreme Programming und traditionelle Programmierung im Vergleich
4.1 Kommunikation, Team und Stand-up Meetings
4.1.1 Extreme Programming Modell
4.1.2 Traditionelles Modell
4.1.3 Kritische Bewertung
4.2 Pair Programming, Standards, kollektives Eigentum
4.2.1 Extreme Programming Modell
4.2.2 Traditionelles Modell
4.2.3 Kritische Bewertung
4.3 Refactoring, testgetriebene Entwicklung, Iterationen
4.3.1 Extreme Programming Modell
4.3.2 Traditionelles Modell
4.3.3 Kritische Bewertung
4.4 Überstunden, Mut, Dokumentation
4.4.1 Extreme Programming Modell
4.4.2 Traditionelles Modell
4.4.3 Kritische Bewertung
5. Traditionelle Programmierung und Extreme Programming in der Praxis
5.1 Vorstellung Fiktiv Versicherung AG
5.2 Ausgangslage
5.3 Ablauf des Projekts
5.4 Lösungsansatz mit Extreme Progamming
6. Fazit
Literatur- und Quellenverzeichnis
Vorwort
„Zusammenkunft ist ein Anfang,
Zusammenhalt ist ein Fortschritt,
Zusammenarbeit ist ein Erfolg.“
Henry I. Ford
Abbildungsverzeichnis
Abb. 1: Ablauf eines traditionellen Projekts - Wasserfallmodell
Abb. 2: Typischer Verlauf eines IT Projekts
Abb. 3: Rollen innerhalb eines XP Projekts
Abb. 4: Ablauf eines XP Projekts
Abb. 5: Ablauf einer XP Iteration
Abb. 6: Organigramm IM Abteilung Fiktiv Versicherung AG
Abb. 7: Projektverteilung IM Abteilung Fiktiv Versicherung AG
Abb. 8: Ablauf eines XP Projekts
Abb. 9: Klassische Webarchitektur
Tabellenverzeichnis
Tab. 1: Meilensteinplanung für Callcentersoftware der Fiktiv Versicherung AG
Tab. 2: Projekt Callcentersoftware - XP Iterationen der Fiktiv Versicherung AG
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abstract
English
The traditional Software development and Extreme Programming are two procedures to create software. The waterfall lifecycle model shows the operation of the traditional Software development. In that case, the phases are horizontally ordered and are executed in succession.
The classical procedure is only applicable, if it is possible to set the standards when starting the project. If mistakes are identified while rolling out the software, they have to be removed with many efforts. Because of the grave disadvantages, the waterfall lifecycle model with its demanding financial efforts, it is today not really convenient and is replaced by a variety of alternative and additional procedural methods such as Extreme Programming.
The paper at hand compares the traditional Software development with Extreme Programming and tries to solve an unsuccessful example of the practice.
German
Die traditionelle Softwareprogrammierung und Extreme Programming stellen zwei Vorgehensweisen zur Programmierung von Software dar. Die traditionelle Softwareprogrammierung orientiert sich klassisch an dem Wasserfallmodell. In diesem sind die Phasen horizontal angeordnet und werden nacheinander durchlaufen. Das klassische Modell ist nur dann verwendbar, wenn Anforderungen schon frühzeitig festgeschrieben werden können. Treten Fehler erst bei der Softwareeinführung ein, so müssen diese mit erheblichem Aufwand entfernt werden. Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanziellen Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer und ergänzender Vorgehensweisen, wie zum Beispiel Extreme Programming, ersetzt.
Die vorliegende Studie vergleicht die traditionelle Softwareprogrammierung mit Extreme Programming und versucht damit ein gescheitertes Praxisbeispiel zu lösen.
1. Einleitung
Unternehmen sind heute mehr denn je auf moderne Informationstechnologien angewiesen, um ihre Wettbewerbssituation zu sichern. Trotz vorhandener Projektmanagementtechniken treten in der Softwareentwicklung immer wieder Schwierigkeiten auf, wenn Projekte erfolgreich abgeschlossen werden sollen. Laut einer Studie aus dem Jahre 2008 der Firma TimeKontor AG mit Firmensitz in Berlin scheitern rund zwei Drittel aller IT-Vorhaben. Das Scheitern solcher IT- Projekte ist auf mehrere Faktoren zurückzuführen. Zum einen werden Anforderungen durch Fachabteilungen nicht präzise genug definiert. Fachabteilungen zählen Hunderte von Einzelfällen auf, haben allerdings Schwierigkeiten damit, der Gesamtanforderung einen Rahmen zu geben. Andererseits scheitern viele IT-Vorhaben wegen mangelnder Kommunikation. Viele Mitarbeiter neigen dazu, Probleme bewusst zu vertuschen anstatt sie gezielt anzusprechen.
Insgesamt kann dieses Verhalten dann zu erheblichen Projektverzögerungen führen. Um das Risiko des Scheiterns abzumildern, entscheiden sich immer mehr IT Strategen dahingehend, den von ihnen vorgegebenen Softwareentwicklungsprozess zu überarbeiten.
Eine in der heutigen Zeit moderne Form der Softwareentwicklung ist das Extreme Programming, im Folgenden kurz XP genannt. Diesem liegt ein agiles Manifest zu Grunde. Richtig eingesetzt, hilft die Anwendung von XP Kundenzufriedenheit und Wertschöpfung nachhaltig zu steigern.
Zuerst wird nun der traditionelle Softwareentwicklungsprozess unter Zuhilfenahme des Wasserfallmodells inhaltlich vorgestellt, bevor dann auf den Ablauf des Extreme Programming näher eingegangen wird. Beide Vorgehensweisen werden daraufhin anhand verschiedener Techniken miteinander verglichen und bewertet. Im Anschluss wird XP mit den zuvor vorgestellten Vergleichskriterien auf ein aus der Praxis kommendes Projekt auf dessen Nutzen untersucht und bewertet.
Mit der vorliegenden Arbeit soll gezeigt werden, inwiefern XP das traditionelle Entwicklungsvorgehen, wie zum Beispiel Softwareentwicklung nach dem Wasserfallmodell, bezüglich des Gesamtnutzens ablösen kann.
Ein Fazit beendet die Ausführungen.
2. Traditionelle Programmierung
Die traditionellen Softwareentwicklungsmodelle orientieren sich in Abgrenzung zu XP an so genannten Phasen, die traditionell durch das Wasserfallmodell wiedergegeben werden, was bedeutet, dass diese Modelle keinen iterativen Ansatz verfolgen.
Im Wesentlichen bestehen klassische Projekte aus Projektleitung, Projektmitarbeitern und bei komplexeren Projekten dem PLA (vgl. Schnelle, 2006, S.2).
Die Projektleitung plant bestimmte Projektphasen, setzt Termine, so genannte Meilensteine, fest und ist im ständigen Informationsaustausch mit dem PLA, der die Überwachungsfunktion wahrnimmt.
Die einzelnen Projektmitarbeiter arbeiten die festgesetzten Inhalte der Meilensteine systematisch ab.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Ablauf eines traditionellen Projekts - Wasserfallmodel l(Quelle: www.ibr.cs.tu-bs.de/wasserfallmodell.jpg)
Bei diesem Modell sind die einzelnen Softwareentwicklungsprozesse in Phasen aufgeteilt, die nacheinander durchlaufen werden. Ein Rücksprung zu einer vorherigen Phase ist möglich, sollten aber vermieden werden. Jede der einzelnen Phasen hat einen definierten Start- und Endzeitpunkt, die in den dafür vorgesehenen Meilensteinsitzungen bestimmt wird.
In der Anforderungserhebungsphase werden zusammen mit dem Kunden dessen Anforderungen besprochen. In allen anderen Phasen ist der Kunde kaum bis nicht involviert.
In der darauf folgenden Analyse werden die technischen Mittel, wie zum Beispiel die Art der verwendeten Datenbanken, Programmiersprachen festgelegt.
In der im Anschluss folgenden Entwurfsphase wird ein erstes Konzept beschrieben, das so genannte Pflichtenheft. Anhand dieses Pflichtenhefts, das vom Kunden gebilligt werden muss, wird die Software erstellt. Dies geschieht mittels der darauf folgenden Phase.
Nachdem die Software implementiert, also programmiert wurde, wird sie getestet, in Betrieb genommen und anschließend gewartet.
Der Entwicklungsaufwand ist sequentiell, das heisst die nächstfolgende Phase kann erst begonnen werden, wenn die Vorherige erfolgreich abgeschlossen wurde. Durch diesen sequentiellen Ablauf lässt sich schnell erkennen, dass auf Änderungen seitens des Kunden nur relativ unflexibel reagiert werden kann.
Da dieses Modell relativ starr ist, sollte es nur dort eingesetzt werden, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase genau beschreiben lassen.
Als wesentlicher Nachteil dieses Modells muss besonders die mangelnde Kundenbeteiligung genannt werden. Der Kunde und somit Auftraggeber ist nur in der Anforderungsphase sowie im eigentlichen Betrieb involviert. Auch die Möglichkeit eines Feedbacks seitens des Kunden ist nicht dauerhaft gegeben.
Des Weiteren laufen die einzelnen Phasen in der Theorie nacheinander ab. In der Praxis allerdings lassen sich Rücksprünge nicht vermeiden. Dies führt zu einem enormen Mehraufwand seitens der Projektbeteiligten.
Weiterhin ist das anfängliche Festschreiben der Anforderungen problematisch, da es durch wiederholtes Durchlaufen der einzelnen Projektphasen bei Anforderungsänderungen zu massiven Zeitproblemen kommen kann.
Ferner ist dieses Vorgehen sehr dokumentenlastig, da jede einzelne Phase dokumentiert werden muss.
Zusammenfassend wird beim traditionellen Entwickeln von Software auf eine iterative Vorgehensweise verzichtet. Die Durchführung der Softwareentwicklung orientiert sich an starren Entwicklungsphasen, auf die nicht flexibel reagiert werden kann. Die Gesamtanforderung des auszuliefernden Produktes wird anfangs in Zusammenarbeit mit dem Kunden anhand des Pflichtenheftes festgelegt. Anschließend werden die in Meilensteinen festgesetzten Programmfragmente umgesetzt. Ferner werden technische Hürden erst bei der Umsetzung erkannt, was einen möglichen Mehraufwand zur Folge hat. Ein Test der umgesetzten Software bezogen auf die fachlichen Funktionen findet bei fast allen traditionellen Vorgehensweisen erst am Ende statt. Auftretende Fehler werden somit zu spät erkannt und nehmen deshalb unnötige Zeit in Anspruch. Änderungen an der Software sind nach dessen Fertigstellung oft nur mit sehr großem Aufwand möglich (vgl. Elmer, 2005, S. 8).
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2: Typischer Verlauf eines IT Projekts (Quelle: www.softwareindustrialization.com/content/binary/design.jpg
Durch den Einsatz von agilen Projekt- und Entwicklungsmethoden kann der oft in der Praxis auftretende Effekt, den die vorstehende Grafik beschreibt, zumindest in der Weise abgemildert werden, dass die Eintrittswahrscheinlichkeit bis auf ein Minimum reduziert werden kann.
3. Extreme Programming
Extreme Programming ist ein Prozessmodell innerhalb der Softwareentwicklung, das das Lösen einer Programmieraufgabe in den Vordergrund stellt und hierbei auf ein formalisiertes Vorgehen größtenteils verzichtet. Ziel dieses Modells ist die schrittweise Annäherung an Kundenwünsche.
Extreme Programming wurde erstmals im Jahre 1995 eingesetzt, als es darum ging, eine Lohnabrechnungssoftware innerhalb der Chrysler Group umzusetzen. Nach Übernahme von Daimler im Jahre 2000 wurde dieses Projekt eingestellt und durch eine bereits existierende Standardlösung ersetzt. Beteiligt am damaligen Projekt waren die drei Begründer von XP, Kent Beck, Ward Cunningham sowie Ron Jeffries.
Heute stellt dies eine moderne Vorgehensweise innerhalb der Softwaretechnik dar und beruht im Wesentlichen auf Werten wie Kommunikation, Einfachheit, Feedback, Mut und Respekt (vgl. Kannengieser, 2007, S.67). Hierbei wird es ermöglicht, langlebige Software zu erstellen und im Laufe der eigentlichen Entwicklung auf sich ändernde Anforderungen rasch zu reagieren.
Während im traditionellen Softwareentwicklungsprozess an Phasenmodellen, wie zum Beispiel dem Wasserfallmodell, festgehalten wird, steht bei XP die eigentliche Implementierung im Vordergrund. Daher ist XP vor allem bei Softwareprogrammierern beliebt, da es von den oft als lästig empfundenen Formalitäten, wie zum Beispiel der Dokumentation, befreit ist.
Durch das Bekanntwerden dieses neuen Ansatzes zur Softwareerstellung, ist es gelungen, die Aufmerksamkeit des Fachpublikums vor allem auf agile Methoden zu lenken.
Das Grundprinzip von XP beruht darauf, Software in kurzen Zyklen iterativ zu entwickeln, das heisst die zu erstellende Software wächst mit ihren Anforderungen. Dies macht sie aus Kundensicht transparent.
Durch diese inkrementelle Vorgehensweise ist XP wesentlich flexibler als das traditionelle Vorgehen, da keine vollständige technische Spezifikation der zu entwickelnden Softwarelösung vorausgesetzt werden muss. Dies bedeutet wiederum, dass es bei XP kein Pflichtenheft gibt.
[...]