Extreme Programming vs. Wasserfallmodell an Hand der Entwicklung eines Messengers für ein Intranet ================================================================================================== Generell ist zu sagen, dass die Entwicklung eines Messengers machbar ist, da es bereits vergleichbare Programme gibt, was wiederum die Erstellung einer Machbarkeitsstudie überflüssig macht. Die Funktionalität muss natürlich mit dem Kunden abgesprochen werden. Je nach Kundenwunsch kann man hier ebenfalls auf bereits bestehende Möglichkeiten zurückgreifen. Das Projekt bewegt sich des Weiteren in einem überschaubaren Rahmen. Die Entwicklung eines Messengers erfordert zum Teil, flexibel auf die Wünsche des Kunden einzugehen. Dazu wäre es von Vorteil, neben der Verwendung von einer kleinen Gruppe von Programmierern (maximal ca. 10 Personen) den Kunden in die Entwicklung des Programms mit einzubeziehen. Dadurch lassen sich auch schnell und vor allem kostengünstig seine Wünsche in das laufende Projekt mit einbeziehen. Wäre vorher eine intensive Planung erfolgt, so wären im Nachhinein Änderungen bzw. das Beseitigen von Fehlern mit hohen Kosten verbunden; man schätzt ungefähr, dass die Kosten bei jeder Änderung pro Phase verzehnfacht werden. Bei Extreme Programming sind die Kosten für die Änderung am Projekt oder zur Beseitigung eines Fehlers immer konstant. Ein weiterer Vorteil, der damit einhergeht ist die Tatsache, dass der Auftraggeber - wenn er der Entwicklung beiwohnt - schon frühzeitig einen Einblick in die Funktionsweise des fertigen Systems bekommt; ein Umstand, der nicht einmal durch ein ausführliches Pflichtenheft ersetzt werden kann. Hier kann sich der Kunde z.B. schon ein konkretes Bild im Hinblick auf die Kommunikation zwischen Client und Server machen und man kann dem Kunden auch zeigen, wie der Server die Anmeldedaten verwaltet und speichert. Zur Beschreibung der Funktionalität reicht es aus, so genannte Stories zu schreiben, in denen der Kunde seine Vorstellungen beschreiben kann, was das System leisten soll. Sind die Stories bzw. die damit verbundenen Probleme zu komplex, kann man das Problem in kleinere Probleme (Stories) aufteilen. Die sichere Kommunikation zwischen Client und Server könnte je nach verwendetem Protokoll z.B. ein komplexes Problem werden, das dann ggf. aufteilt werden muss (z.B. in Message Handler, Verschlüsselung, ...). Basierend auf diesen Stories werden dann zunächst Testfälle entwickelt, die nachher ermöglichen, die jeweilige Funktionalität zu testen und damit einhergehend den Programmierern ein besseres Verständnis der Problematik liefern können. Ständiges Testen während der Entwicklung hilft darüber hinaus, die gewünschte Funktionalität zu erhalten. Weiterhin ist es dadurch möglich, sich die Arbeit in Hinblick auf die Kommunikation zwischen Client und Server zu erleichtern, da man direkt testen kann, ob das Protokoll noch funktioniert. In einem Pflichtenheft wird genaustens spezifiziert, was die Software leisten soll. Da im nächsten Schritt - dem Entwurf - die Systemarchitektur bereits festgelegt wird, kann man das Projekt besser strukturieren und muss nachher nur noch die Struktur "füllen"; ein Nachteil von Extreme Programming, da hier Entscheidungen sehr schnell und unmittelbar bevor sie anstehen getroffen werden (innerhalb von max. 10 Minuten). Dies macht es schwierig, die Konsequenzen, welche eine Entscheidung haben kann, zum Zeitpunkt, wenn sie getroffen wird, abzuschätzen. Somit können sich schlechte Entscheidungen negativ auf die Software auswirken, z.B. in Form von umständlich und somit meist unverständlich programmierten Abschnitten, die vielleicht einfacher zu lösen wären, würde man sich die Zeit nehmen, in einer Planungsphase genauer darüber nachzudenken. Dies ist vor allem gefährlich bei der Entwicklung des Netzwerkprotokolls, da hier vorschnelle Entscheidungen die Sicherheit der Kommunikation zwischen Clients über den Server negativ beeinträchtigen können. Würde man jedoch wie früher mit dem Wasserfallmodell arbeiten, so müsste für ein so relativ kleines Projekt viel Aufwand betrieben werden, da in jeder Phase ein Dokument erstellt werden muss, welches beschreibt, was genau gemacht wurde. Diese Vorgehensweise produziert viel Papier und ist darüber hinaus kein Garant für die Qualität des Programms. Das Fehlen einer Dokumentation kann jedoch auch ein Risiko darstellen. Dies ist z.B. der Fall, wenn Programmierer ausscheiden. Somit kann man deren Arbeit nicht unmittelbar an einer Dokumentation, jedoch aber z.B. bei dem Studieren von Testfällen oder Stories, nachvollziehen. Entschärft wird diese Situation außerdem dadurch, dass beim Extreme Programming zum einen in Paaren programmiert wird und zum anderen diese Programmiererpaare häufig wechseln. Dies ermöglicht jedem einen Einblick in das komplette System. Falls also ein Teil der Programmierer ausscheiden sollten, ist immer noch ein ausreichend großer Teil der Programmierer da, die diesen Verlust decken können. Extreme Programming ermöglich es auf Grund der Programmierung in Paaren, dass ein Programmierer durch den anderen ermutigt werden kann und somit auch Problemlösungen entstehen können, die ein einzelner Programmierer nie alleine ersonnen hätte. Ein weiterer Vorteil der Arbeitsweise mit Extreme Programming anstelle des Wasserfallmodells ist das so genannte Refactoring. Refactoring bedeutet, dass man die interne Struktur der Software ändert, um sie leichter verständlich zu machen. Dies ermöglicht am Ende auch eine kostengünstigere Wartung der Software. Dies stellt dann unter anderem den Ausgleich für schlechte, zu schnell getroffene Entscheidungen (siehe oben) dar. Ein Garant dafür, dass die Änderungen am Code die Funktionalität in keinster Weise beeinträchtigen sind weiterhin die Testfälle, welche sowohl vor als auch nach der Änderung am Code ausgeführt werden. Die Änderungen werden in kleinen Schritten vollzogen, ständig begleitet durch laufende Tests. Das ständige Testen ist in keinster Weise teuer, da die Testfälle einmal geschrieben werden und während der ganzen Entwicklung wieder verwendet werden können. Es kann sogar auch möglich sein, dass diese Vorgehensweise sogar Kosten verringert. Abschließend bleibt die Frage: Welche Vorteile hat Extreme Programming gegenüber dem Wasserfallmodell? Die Punkte, bei denen das Projekt am meisten profitieren kann sind das Programmieren in Paaren, das ständige Testen und das Refactoring. Das Einbeziehen der Entwickler in den Planungsprozess schadet ebenfalls nicht. Das größte Risiko besteht wohl im Fehlen einer Entwurfsphase und der fehlenden Dokumentation. Das Projekt könnte als undokumentiertes System irgendwann enden, welches nur schwer zu modifizieren ist. Bei Extreme Programming verfolgt man weiterhin das Ziel, nur das zu implementieren, was gerade gebraucht wird. Man konzentriert sich also eher auf die Funktionalität eines Systems (ganz wichtig bei der Sicherheit des Netzwerkprotokolls) und nicht auf das Einbauen von unnötigen Spielereien. Im Falle der Entwicklung eines Messengers für ein Intranet würde ich zu Extreme Programming anstatt zum Wasserfallmodell raten, da man sich mit diesem Modell - trotz dass es bei diesem Projekt auch nicht zu einhundert Prozent geeignet ist - mehr auf das Wesentliche konzentrieren kann. Bei Extreme Programming sind alle Entwickler ständig bemüht, den Code zum Wohle des Softwaresystems zu optimieren, was gerade bei Netzwerken eine große Rolle spielen kann.