Zum Inhalt springen

Agile Unified Process

aus Wikipedia, der freien Enzyklopädie

Der Agile Unified Process (AUP) ist ein hybrider Modellierungsansatz, der den Unified Process (UP) mit agiler Softwareentwicklung verbindet.[1][2] Es handelt sich dabei um ein Vorgehensmodell welches Scott Ambler nach dem Enterprise Unified Process (EUP) entwickelt und veröffentlicht wurde.

AUP kombiniert das konventionelle Prozessmodell Unified Process (UP) bzw. Rational Unified Process (RUP), das ursprünglich vom Unternehmen Rational Software (heute IBM) entwickelt wurde, mit den Prinzipien, Vorgehensweisen und Werten der agilen Softwareentwicklung. Das AUP wird durch die folgenden agile Software-Techniken ergänzt, die beispielsweise zur Steigerung der Produktivität beitragen:

Geschichte

[Bearbeiten | Quelltext bearbeiten]

Scott Ambler hat die Arbeit an dem Ansatz etwa 2006 eingestellt[3] und ab etwa 2009 am sogenannten Disciplined Agile Delivery (DAD)-Framework weitergearbeitet.[3] Letzteres beinhaltet das AUP und wurde als Disciplined Agile (DA)[4] im Jahr 2019 an das Project Management Institute (PMI) verkauft. Ambler vermarktet den Enterprise Unified Process (EUP) weiterhin auf seiner eigenen Homepage.[5]

Modell

[Bearbeiten | Quelltext bearbeiten]

Grundgedanken

[Bearbeiten | Quelltext bearbeiten]

Der Agile Unified Process (AUP) baut auf den folgenden Prinzipien und Thesen auf:[3]

  • 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

[Bearbeiten | Quelltext bearbeiten]

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:[6]

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

Workflows

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]
  • 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

[Bearbeiten | Quelltext bearbeiten]
  • 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

[Bearbeiten | Quelltext bearbeiten]
  • 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

[Bearbeiten | Quelltext bearbeiten]
Laufende Releases für Test und Produktion.

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.

Siehe auch

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Jianwei Li, Xunan Wang: Research and practice of agile Unified Process. In: 2010 2nd International Conference on Software Technology and Engineering. Band 2, Oktober 2010, S. V2–340–V2–343, doi:10.1109/ICSTE.2010.5608794 (englisch, ieee.org [abgerufen am 21. August 2026]).
  2. ↑ Charles Edeki: Agile Unified Process. In: International Journal Of Computer Science And Mobile Applications - IJCSMA. Band 1, Nr. 3, 2013 (englisch, archive.org [PDF]).
  3. 1 2 3 Scott Ambler: The Agile Unified Process (AUP) Home Page. Ambysoft Inc., 2019, archiviert vom Original am 8. August 2019; abgerufen am 21. August 2026.
  4. ↑ Introduction to Disciplined Agile® | Disciplined Agile®. In: PMI. 2026, abgerufen am 21. August 2026 (englisch).
  5. ↑ Enterprise Unified Process (EUP). In: Scott Ambler. 2026, abgerufen am 21. August 2026 (amerikanisches Englisch).
  6. ↑ Ioannis Christou, Stavros Ponis, Eleni Palaiologou: Using the Agile Unified Process in Banking. In: IEEE Software. Band 27, Nr. 3, Mai 2010, ISSN 0740-7459, S. 72–79, doi:10.1109/MS.2009.156 (englisch, ieee.org [abgerufen am 21. August 2026]).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Agile_Unified_Process&oldid=269879654“