Pflichtenheft von byteme - PI - Praktische Informatik

56 KAPITEL 6. ENTWICKLUNGSPROZESS
hinsichtlich des aktuellen Lösungsansatzes strategisch vorausdenkt und versucht, Auswirkungen
der aktuellen Implementierung auf das Gesamtsystem abzuschätzen. Die
Rollen können dabei jederzeit getauscht werden.
Die Gruppe ist in drei Kleingruppen gegliedert, die sich zwar nicht, wie in XP
vorgesehen, regelmäßig neu bilden, da dies aus organisatorischen Gründen (Zeit- und
Wohnsituation) nicht praktikabel ist. Jedoch wird eine Umgruppierung zu einem späteren
Zeitpunkt des Projekts nicht ausgeschlossen.
Model
Visualisierung
Controller
Mario Vekic, Sinisa Djukanovic
Kai Stroh, Sebastian Eifert
Matthias Orgler, Carole Urvoy
Grundlegend zu all diesen Punkten gehört auch die enge Zusammenarbeit zwischen
Auftraggeber und -nehmer, um den Fortschritt des Projektes in die richtige Richtung
garantieren zu können. Es wäre wünschenswert, während der Programmierphase kontinuierlich
Rückmeldungen vom Auftraggeber zu erhalten und für die jeweils nächste
Iteration zu berücksichtigen.
6.2.2.2 Refactoring
Software, die benutzt wird, muss laufend den sich ändernden Anforderungen angepasst
werden, d.h. sie muss gewartet werden. Leider führt Software-Wartung in der Regel
zur Degeneration der Struktur der Software. Das macht weitere Änderungen immer
schwieriger, bis schließlich nur noch eine Neuimplementierung sinnvoll ist.
Eine Möglichkeit, dieser „natürlichen“ Degeneration der Software-Struktur entgegenzuwirken,
ist die kontinuierliche Software-Restrukturierung oder „Refactoring“,
die dafür sorgt, dass die Software jederzeit verständlich und änderbar bleibt.
Das Refactoring umfasst also konstruktive Maßnahmen, die dazu dienen, eine vorhandene
Software oder Teile davon verständlicher und leichter änderbar zu machen,
ohne dabei das beobachtbare Verhalten zu verändern.
Durch die Wahl von Eclipse als Entwicklungsumgebung fällt die Anwendung solcher
Maßnahmen relativ leicht, da dort bereits weitreichende Unterstützungsfunktionen
zur Durchführung verschiedener Refactoring-Prozesse vorhanden sind.
6.3 Iterationsplan
Wie im Abschnitt zur Prozessstruktur (s. 6.2) bereits erwähnt, werden wir das Projekt
nicht „in einem Rutsch“ implementieren, sondern mehrere, kleinere Iterationen durchführen.
Dies hat mehrere Vorteile. Zunächst einmal sind die Teilaufgaben, die in jeder
Iteration zu lösen sind, weniger komplex und damit besser überschaubar als die Gesamtaufgabe.
Weiterhin besteht bei einem iterativen Vorgehen die Möglichkeit, frühzeitig
(d.h. spätestens nach dem ersten Release) Feedback vom Auftraggeber zu erhalten
und damit eventuelle Unklarheiten aufzuklären. Schließlich versucht man, durch mehrere
Meilensteine das Projektrisiko zu senken. Dies ist darin begründet, dass die riskantesten
und schwierigsten Aufgaben möglichst früh im Projekt implementiert werden,
d.h. wenn noch viel Zeit für möglicherweise nötige Umstrukturierungen bleibt, während
in späteren Iterationen nur noch vergleichsweise einfache und damit sicherer zu
bewältigende Aufgaben übrig bleiben. Der aktuelle Iterationsplan wird stets in unserem
Wiki festgehalten.