Modell
Grundgedanken
Der Agile Unified Process (AUP) baut auf den folgenden Prinzipien und Thesen auf:
- Vertrauen: Leute wissen, was sie machen. Die Annahme ist, dass Leute keine detaillierten Dokumentationen lesen, aber sie wollen Beratung auf einem hohen Niveau und Trainings von Zeit zu Zeit.
- Einfachheit: Alles ist auf wenigen Seiten prägnant beschrieben.
- Agilität: Der Prozess geht konform mit den Werten und Prinzipien der agilen Softwareentwicklung.
- Aktivitäten konzentrieren: Der Fokus liegt auf den „hochwertigen“ Aktivitäten, die wirklich zählen, und nicht auf allen möglichen Sachen, die dem Projekt zustoßen könnten.
- Werkzeug-Unabhängigkeit: Die Werkzeuge sind nicht vorgegeben und können somit frei bestimmt werden.
- Produktanpassung: Das Produkt muss möglicherweise angepasst werden, damit es Ihren Anforderungen genügt. Der Prozess soll Sie dabei unterstützen.
Phasen
Der Prozess besteht aus sieben Workflows und vier Phasen. Die Phasen werden einmalig innerhalb eines Projekts durchlaufen, die Workflows hingegen iterativ. In bestimmten Phasen werden bestimmte Workflows mehr oder weniger intensiv durchgeführt.
Die vier Phasen des AUP sind dieselben wie jene des RUP:
- Beginn: Das Team bestimmt den (initialen) Umfang des Projektes, eine mögliche Architektur und sichert sich die Finanzierung sowie die Akzeptanz der Stakeholder.
- Ausarbeitung: Die Machbarkeit wird sichergestellt und die Architektur endgültig definiert.
- Entwicklung: Die Software wird, basierend auf den Prioritäten des/der Stakeholder, inkrementell entwickelt.
- Übergang: Die Software wird vom Team validiert und in der Produktionsumgebung eingesetzt.
Workflows
Die Workflows definieren die Aktivitäten, die das Entwicklungsteam ausführen muss, um laufende Software zu entwickeln, zu validieren und zu liefern, die die Bedürfnisse der Stakeholder befriedigt. Die Einordnung erfolgt danach, in welchen Phasen die einzelnen Workflows relevant sind.
Initialisierung, Ausarbeitung, Konstruktion, Übergang
- Verstehen: Das Geschäft der Organisation soll verstanden werden, um in weiterer Folge die Problemstellung im richtigen Kontext zu sehen und eine brauchbare Lösung für dieses spezifische Problem zu liefern.
- Implementierung: Es sollen Modelle in ausführbaren Code umgewandelt werden und dabei auch Unit Tests des erstellten Codes durchgeführt werden.
- Konfigurationsmanagement: Der Zugriff zu den Projektartefakten muss geregelt werden. Dabei geht es nicht nur um die Aufzeichnung von verschiedenen Versionen der Artefakte, vielmehr sollen auch die einzelnen Änderungen kontrolliert und verwaltet werden. Ein Grund dafür ist zum Beispiel, dass bei etwaigen Änderungen nicht die falsche Version eines Artefaktes weiterverwendet wird.
- Projektmanagement: Aktivitäten, die während des Projektes anfallen, müssen gesteuert werden. Das beinhaltet die Handhabung von Risiken, die Anweisung von Leuten (Tasks zuweisen, Änderungen verfolgen etc.) sowie die Koordination mit Leuten und Systemen außerhalb des Projektes, um sicherzustellen, dass die Lieferung pünktlich erfolgt und die Kosten innerhalb des Budgets bleiben.
Ausarbeitung, Konstruktion, Übergang
- Testen: Es sollen Fehler gefunden werden, es soll validiert werden, dass die Software wie vorgesehen funktioniert, und es soll verifiziert werden, dass die Anforderungen erfüllt werden.
- Umgebung: Der restliche Aufwand muss unterstützt werden, indem sichergestellt wird, dass der richtige Prozess, die richtige Führung und die richtigen Tools (Hardware, Software) dem Team zur Verfügung stehen.
Konstruktion, Übergang
- Einsatz: Die Lieferung der Software soll geplant und die Umsetzung des Plans soll durchgeführt werden.
Hierbei gibt es einige Unterschiede zum Rational Unified Process (RUP) zu beachten: Zum einen wurden die Arbeitsschritte Geschäftsmodellierung, Anforderungen und Analyse & Design beim AUP zu Verstehen zusammengefasst. Zum anderen ist der Arbeitsschritt Konfigurations- und Änderungsmanagement nur als Konfigurationsmanagement dargestellt. Das Änderungsmanagement ist bei der agilen Softwareentwicklung typischerweise in der Anforderungsfindung verortet, wohingegen es sich beim AUP unter dem Punkt Verstehen wiederfindet.
Releasemanagement
Statt eines „Big Bang“-Release wie bei älteren Softwareprojekten, wo die gesamte Software auf einmal in die Produktion geliefert wurde, wird beim AUP die Software in Portionen (Version 1, Version 2, …) geliefert. Üblicherweise wird nach dem Ende jeder Iteration ein Development-Release in eine Testumgebung (Vor-Produktionsumgebung) veröffentlicht, wobei der Development-Release den Anspruch erhebt, potenziell in die Produktion geliefert werden zu könnte. In dieser Testumgebung kann dann die Qualitätssicherung durchgeführt werden, bevor dann eine Version, die ein Mindestmaß an Qualität aufweist, in die Produktion gehen kann.