Klassische Softwareprogrammierung und Extreme Programming im Vergleich unter Anwendung eines Praxisbeispiels

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 Anforderun­gen 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 alterna­tiver und ergänzender Vorgehensweisen, wie zum Beispiel Extreme Program­ming, 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 Pro­jektmanagementtechniken 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 Anforde­rungen 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 Softwareent­wicklungsprozess 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 Kundenzu­friedenheit und Wertschöpfung nachhaltig zu steigern.

Zuerst wird nun der traditionelle Softwareentwicklungsprozess unter Zuhilfe­nahme 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 Was­serfallmodell, 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, Projektmitar­beitern 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 Meilen­steine 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 vor­herigen Phase ist möglich, sollten aber vermieden werden. Jede der einzelnen Phasen hat einen definierten Start- und Endzeitpunkt, die in den dafür vorgese­henen Meilensteinsitzungen bestimmt wird.

In der Anforderungserhebungsphase werden zusammen mit dem Kunden des­sen Anforderungen besprochen. In allen anderen Phasen ist der Kunde kaum bis nicht involviert.

In der darauf folgenden Analyse werden die technischen Mittel, wie zum Bei­spiel die Art der verwendeten Datenbanken, Programmiersprachen festgelegt.

In der im Anschluss folgenden Entwurfsphase wird ein erstes Konzept be­schrieben, 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 gete­stet, 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 beschrei­ben lassen.

Als wesentlicher Nachteil dieses Modells muss besonders die mangelnde Kun­denbeteiligung genannt werden. Der Kunde und somit Auftraggeber ist nur in der Anforderungsphase sowie im eigentlichen Betrieb involviert. Auch die Mög­lichkeit 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 Anfor­derungsänderungen zu massiven Zeitproblemen kommen kann.

Ferner ist dieses Vorgehen sehr dokumentenlastig, da jede einzelne Phase do­kumentiert 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 an­fangs in Zusammenarbeit mit dem Kunden anhand des Pflichtenheftes festge­legt. Anschließend werden die in Meilensteinen festgesetzten Programmfrag­mente umgesetzt. Ferner werden technische Hürden erst bei der Umsetzung erkannt, was einen möglichen Mehraufwand zur Folge hat. Ein Test der umge­setzten 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. Ände­rungen 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, zumin­dest 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 Softwareentwick­lung, das das Lösen einer Programmieraufgabe in den Vordergrund stellt und hierbei auf ein formalisiertes Vorgehen größtenteils verzichtet. Ziel dieses Mo­dells 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 umzuset­zen. Nach Übernahme von Daimler im Jahre 2000 wurde dieses Projekt einge­stellt und durch eine bereits existierende Standardlösung ersetzt. Beteiligt am damaligen Projekt waren die drei Begründer von XP, Kent Beck, Ward Cun­ningham 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 Ent­wicklung 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 ei­gentliche Implementierung im Vordergrund. Daher ist XP vor allem bei Soft­wareprogrammierern beliebt, da es von den oft als lästig empfundenen Formali­tä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 Me­thoden 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 Anforderun­gen. 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 wie­derum, dass es bei XP kein Pflichtenheft gibt.

[...]