Rational Unified Process #

Der Grundstein für RUP wurde von den drei Amigos¹ gelegt, die sich auf ein einheitliches Notationssystem einigen wollten. Dieses System ist heute unter dem Namen UML bekannt.

Es ist mehrfach bestätigt worden, dass die Planung wie im Wasserfall-Modell viele Probleme bereitet. Jedoch zeigte sich auch, dass gar keine Planung auch sehr riskant sein kann. Das richtige Mass zu finden ist komplex. ²

Der Rational Unified Process beschreibt ein teils strukturiertes, teils agiles Vorgehen.

Es beinhalten:

4 Phasen (Inception, Elaboration, Construction, Transition)
Immer iterativ
Disciplines, Activities
Roles
Work Products (Artefacts)

Es sollte aber nicht alles angewendet werden, sondern es als eine Art Apotheke gesehen werden, bei der nur die benötigten Medikamente verwendet werden.

Es wird in UP oft von Risiko gesprochen, wobei hier auch geschäftliche Werte miteinbezogen werden müssen.

Die vier Phasen #

Inception: Wird häufig vom Management vorgegeben wie Zeitrahmen, Kostendach, grober Funktionsumfang. Es gibt vielleicht einen Anforderungsworkshop in dem auch Risiken und Qualitätsanforderungen definiert werden. Hier wird auch entschieden, ob das Produkt selbst gemacht oder eingekauft wird. Projektschätzung werden in Grössenordnungen 1k, 100k bis 1 Mio also ganz grob geschätzt.
Elaboration: Die Kernarchitektur wird iterativ implementiert und risikoreiche Probleme werden so ausgeschaltet oder abgesichert. Hier werden die meisten Anforderungen entdeckt und stabilisiert. Es entsteht eine funktionsfähige Applikation, mit Teilfunktionalität.
Construction: Ab hier ist die Richtung klar, es soll keine offenen Risiken mehr geben, Implementation der restlichen Features steht im Vordergrund.
Transition: Bei wasserfallartigen Projekten würde man hier die Datenmigration, Systemtest und Deployment machen. Beim iterativen Vorgehen ist diese Phase minimal. Es wird beispielsweise ein Feature freeze gemacht und der Code ein letztes mal deployed

Iterationen:

Jede Iteration soll in einem lauffähigen Produkt enden. Wenn Arbeitspakete noch nicht komplett erledigt sind, werden sie in die nächste Iteration verschoben. Im Idealfall nutzt er das Produkt nach jeder Iteration bereits.
Kunden-Feedback ist wichtig und eine der Hauptmerkmale von agilem Vorgehen.
Durch ständiges Feedback werden schneller Unklarheiten bekannt, die insgesamt zu mehr Freude beim Kunden, wie auch bei den Entwicklern führt.

Folgende Dinge sollten genauer angesehen werden, bevor voll gestartet wird.

Requirements: Use Cases, Domainmodell und nicht-funktionale Anforderungen, um den Scope grob erfassen zu können.
Architektur: Das System und die Software benötigen eine Architektur, die den Requirements und den nicht-funktionalen Anforderungen genügen muss.
Werkzeug-Kette: Bevor losgelegt wird, sollte die ganze Tool Chain eingerichtet sein also die IDE, Versionskontrolle, Unit Testing Frameworks sowie die Continuous Integration, Metrics und Static Code Analysis Tools