Agile Unified Process

Der Agile Unified Process (AUP) ist ein hybrider Modellierungsansatz, der den Rational Unified Process (RUP) mit agiler Softwareentwicklung verbindet. Dieser wurde von Scott W. Ambler entwickelt. Der AUP bietet einen iterativ-inkrementellen Zugang zur Softwareentwicklung, indem ein solides Prozess-Framework, basierend auf dem RUP für alle Arten von Softwareprojekten, geboten wird, in Kombination mit den Werten, Prinzipien und Vorgehensweisen der agilen Softwareentwicklung. Zudem kommen folgende agilen Techniken beim AUP zur Anwendung, zum Zweck der Erhöhung der Produktivität:

• Test Driven Development (TDD)
• Agile Model Driven Development (AMDD)
• Agile Change Management
• Database Refactoring

Die Arbeit an AUP wurde von Scott W. Ambler im Jahr 2006 eingestellt. Seit 2009 hat er die Arbeit am Disciplined Agile Delivery (DAD) Framework aufgenommen, in dem das AUP als Basis mitinbegriffen ist. DAD wurde 2019 vom Project Management Institute übernommen.

Philosophien des AUP

Der AUP wurde basierend auf folgenden Prinzipien aufgebaut:

• Your staff knows what they're doing (dt.: Ihre Leute wissen, was sie machen): Die Leute lesen keine detaillierten Dokumentationen, aber sie wollen Beratung auf einem hohen Level und Trainings von Zeit zu Zeit. Der AUP bietet Links zu vielen Details, aber sie werden keinem aufgezwungen.
• Simplicity (Einfachheit): Alles ist auf wenigen Seiten prägnant beschrieben.
• Agility (Agilität): Der AUP geht konform mit den Werten und Prinzipien der Agile Alliance
• Focus on high-value activities (Auf die hochwertigen Aktivitäten konzentrieren): Der Fokus liegt auf den Aktivitäten, die wirklich zählen, und nicht auf allen möglichen Sachen, die dem Projekt zustoßen könnten.
• Tool independence (Tool-Unabhängigkeit): Die Tools, die mit dem AUP verwendet werden, sind nicht vorgegeben und können somit selbst bestimmt werden.
• You’ll want to tailor this product to meet your own needs (dt.: Sie werden dieses Produkt womöglich anpassen müssen, damit es Ihren Anforderungen genügt): Das AUP-Produkt kann ganz einfach mit HTML-Bearbeitungstools angepasst werden.

Aufbau

Der AUP besteht aus sieben Workflows und vier Phasen. Die Phasen werden einmalig innerhalb eines Projektes durchlaufen, während die Workflows iterativ durchgeführt werden. Es werden bestimmte Workflows in bestimmten Phasen mehr oder weniger intensiv durchgeführt.

Phasen

Die vier Phasen des AUP, die im Folgenden näher beschrieben werden, sind dieselben wie jene des RUP:

1. Inception (Beginn): Das Team bestimmt den (initialen) Umfang des Projektes, eine mögliche Architektur und sichert sich die Finanzierung sowie die Akzeptanz der Stakeholder.
2. Elaboration (Ausarbeitung): Die Machbarkeit wird sichergestellt und die Architektur endgültig definiert.
3. Construction (Entwicklung): Die Software wird, basierend auf den Prioritäten des/der Stakeholder, inkrementell entwickelt.
4. Transition (Übergang): Die Software wird vom Team validiert und in der Produktionsumgebung eingesetzt.

Workflows

Die Workflows definieren die Aktivitäten, die das Entwicklungsteam durchführen muss, um laufende Software, die die Bedürfnisse der Stakeholder befriedigen, zu bauen, zu validieren und zu liefern (in Klammern werden am Ende jeder Beschreibung die Phasen angegeben, in denen die einzelnen Workflows von Relevanz sind):

• Model (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. (Inception, Elaboration, Construction, Transition)
• Implementation (Implementierung): Es sollen Modelle in ausführbaren Code umgewandelt werden und dabei auch Unit Tests des erstellten Codes durchgeführt werden. (Inception, Elaboration, Construction, Transition)
• Test (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. (Elaboration, Construction, Transition)
• Deployment (Einsatz): Die Lieferung der Software soll geplant und die Umsetzung des Plans soll durchgeführt werden. (Construction, Transition)
• Configuration Management (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. (Inception, Elaboration, Construction, Transition)
• Project Management (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. (Inception, Elaboration, Construction, Transition)
• Environment (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. (Inception, Elaboration, Transition)

Hierbei gibt es einige Unterschiede zum RUP. Zum einen wurden die Arbeitsschritte Business Modeling, Requirements und Analysis & Design zu Model beim AUP zusammengefasst. Zum anderen ist der Arbeitsschritt Configuration & Change Management hier als Configuration Management dargestellt. Das Change Management wird bei der agilen Softwareentwicklung typischerweise bei der Anforderungsfindung loziert, das beim AUP unter Model zu finden ist.

Releases

Statt des „Big Bang“-Vorgangs beim Release, wo die gesamte Software auf einmal in die Produktion geliefert wird, 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) released, wobei der Development-Release etwas sein muss, was potenziell in die Produktion geliefert werden 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 als sogenannte Production-Release. Dies wird im folgenden Bild auf einer Projekt-Zeitlinie dargestellt: