Software Engineering
↓ Klassische Risiken bei der Software-Entwicklung
↓ Risikomanagement durch iterative Entwicklung
↓ Planungs-Spiel statt unrealistischer Meilensteine
↓ Wartbarkeit durch einfache Software-Architekturen
↓ Überblick durch Verwendung von System-Metaphern
↓ Referenzen
- Unrealistische Aufwandsabschätzungen
--> frustrierte Entwickler
- Schlechte Kontrollmöglichkeiten
--> frustrierte Projektleiter
- Unbefriedigende Resultate wegen zu geringer Involvierung des Kunden
--> frustrierte Kunden
- Schlechte Wartbarkeit durch gewachsene Software-Architekturen,
die zudem meist schlecht dokumentiert sind
Im Folgenden wird die Entwicklungsmethodik
eXtreme Programming (XP) erwähnt. Ziel von XP ist, Software schnell und in guter Qualität auszulierfern, unter Minimierung der Risiken. XP ist ein leichtgewichtiger Entwicklungsprozess für Teams von max 10-15 Leuten. XP besteht aus einer pragmatischen Sammlung von Vorgehensweisen für Softwareentwickler und Projektleiter
Um das Risiko bei der Software-Entwicklung zu reduzieren ist es wichtig, viele kurze Iterationen zu haben. Innerhalb einer Iteration wird das Software-System um vorher festgelegte Leistungsmerkmale erweitert. Am Ende einer jeden Iteration steht ein lauffähiges System mit gewachsenem Funktionsumfang. Kurze Iterationen erlauben es in den Entwicklungsprozess eingreifen zu können. Je kleiner die atomaren Tätigkeiten einer Iteration sind, desto sanfter kann der Entwicklungsprozess gesteuert werden. Eine der wichtigsten Regeln ist, ständig ein lauffähiges System zu behalten. Die erste Iteration in einem neuen Projekt ist dafür verantwortlich, ein solches zu schaffen. Die fortlaufende Integration neuer Funktionalität während der darauf folgenden Iterationen muß gewährleisten, daß das System weiterhin lauffähig bleibt.
Der Kunde ist derjenige, der das Ziel am klarsten vor sich sieht. Am Anfang des Projekts formuliert er seine Erwartungen über die Leistungsmerkmale in Form von Benutzungsbeispielen ("Stories"), die handschriftlich festgehalten werden. XP hat die strenge Forderung nach einem On-Site-Customer, d.h. der Kunde (oder ein Vertreter) ist in das Entwicklungsteam integriert und arbeitet vor Ort im gleichen Raum. So kann er durch schnelles Feedback wirksam bei der Steuerung des Entwicklungsprozess helfen.
Das Planungs-Spiel, ein weiterer Hauptbestandteil von XP, soll dafür sorgen, daß weder nur Geschäftsinteressen, zumeist vertreten durch den Kunden und den Projektleiter, noch die Interessen der Entwickler einseitig oder vorrangig behandelt werden. Vielmehr wird eine Aufteilung beschlossen: Personen, die Geschäftsinteressen vertreten, entscheiden über den Fokus der Iterationen, die Priorität von Leistungsmerkmalen und welche Leistungsmerkmale zu welchem Zeitpunkt zur Verfügung stehen sollen. Die Entwickler hingegen entscheiden über den Aufwand, der notwendig ist um ein Leistungsmerkmal zu implementieren. Der Kunde und der Projektleiter respektieren und akzeptieren diese Schätzung.
Die Entwickler schätzen den Aufwand in Ideal-Tagen, die noch mit einem Last-Faktor multipliziert werden. Der Last-Faktor ist zu Beginn eines Projektes mit einem neuen Team meist unbekannt und muß daher zuerst ermittelt werden. Bei Teams, die schon zuvor an ähnlichen Projekten gearbeitet haben, liegen meist schon Erfahrungswerte vor. Der Last-Faktor ergibt sich aus dem Verhältnis der tatsächlichen Dauer einer Tätigkeit gegenüber der Schätzung, die die Entwickler anfangs abgegeben hatten. Die Entwickler lernen dabei das richtige Schätzen von Aufwänden und gewinnen das Vertrauen in den Prozess.
XP spiegelt eine Grundregel erfahrener Programmierer wieder, welche besagt, daß die Architektur einer Applikation immer so einfach wie möglich gehalten werden sollte. Dabei soll auf bekannte Entwurfsmuster (Design Pattern) zurückgegriffen werden, d.h. Lösungen für bereits bekannte Probleme sollen konsequent eingesetzt werden. Wichtig beim Entwurf ist, daß die
wesentlichen Zusammenhänge der Teilaspekte richtig erfasst werden, und der Blick nicht von Nebenaspekten verstellt wird. Im gleichen Sinne sollte dann auch die Implementierung ablaufen, d.h. zuerst eine funktionierende Fassung von Basisfunktionalität zur Verfügung stellen, dann die Nebenaspekte behandlen.
Eine Eigenschaft von einfachen Architekturen ist, daß sie die DRY-Regel beachten. Dry steht hierbei für "Don't repeat yourself" und besagt, daß eine Funktionalität nur einmal im Quellcode implementiert werden sollte.
Während der Entwicklung einer Lösung sind die Entwickler oft so vertieft in die Details ihres Problems, daß sie keinen Überblick über das gesamte Projekt haben und es ihnen schwer fällt sich in andere Probleme, als das an dem sie gerade arbeiten, hinein zu denken. Dies kann unter anderem zu dupliziertem Quellcode und nicht benötigter Funktionalität führen. XP versucht dies zu vermeiden, aber den Entwickler trotzdem nicht aus seiner Welt zu reißen, indem eine System-Metapher für das Projekt gewählt wird. Diese System-Metapher beschreibt den Kontext und die Komponenten innerhalb des Projekts konsistent mit Begriffen, die z.B. aus der realen Welt stammen können. Sind keine solchen Assoziationen mit Begriffen aus der realen Welt möglich, wie es bei Frameworks in der Regel der Fall ist, so eignen sich dafür auch Entwurfsmuster und daraus entstehende Pattern Languages.
Eine eindeutige Begriffswelt hilft nicht nur bei der aktuellen Arbeit und bei der Kommunikation zwischen Entwicklern und Projektleitern, sondern auch um neue Teammitglieder in das Team zu integrieren -- sogenanntes Insourcing.
iX 5/2000: "Frameworks: Königsweg der Wiederverwendung?"
Java Spektrum 3/2000: "Muster und Frameworks mit UML-Werkzeugen effektiv nutzen"
Java Spektrum 1/2001, S. 15: "Hintergründe von eXtreme Programming"