Enterprise Unified Process

Die Artikel Enterprise Unified Process und Agile Unified Process überschneiden sich thematisch. Informationen, die du hier suchst, können sich also auch im anderen Artikel befinden.
Gerne kannst du dich an der betreffenden Redundanzdiskussion beteiligen oder direkt dabei helfen, die Artikel zusammenzuführen oder besser voneinander abzugrenzen (→ Anleitung).

Der Enterprise Unified Process (EUP) ist eine erweiterte Variante des Rational Unified Process und wurde ab 1999 von Scott W. Ambler und Larry Constantine entwickelt. Eine grundlegende Überarbeitung und erneute Veröffentlichung wurde 2005 durch Ambler, John Nalbone und Michael Vizdos^[1] vorgenommen. EUP wurde schließlich durch das Disciplined Agile Delivery (DAD) Toolkit ersetzt und 2019 vom Project Management Institute übernommen.^[2]

Die Hauptmotivation für EUP waren einige Schwächen des RUP, speziell in den Bereichen system support und retirement für Softwaresysteme. Beide Bereiche wurden jeweils als neue Phase angefügt. Zusätzlich wurden neue Projekt- und Unternehmens-Arbeitsschritte definiert, um den gesamten Lebenszyklus eines Softwaresystems aus Unternehmenssicht abzudecken. RUP ist damit nur ein Teilbereich des EUP.

Diese Ergänzungen dienen einerseits der Organisation von Softwareprojekten aus Sicht des Kunden und definieren andererseits die Bereiche im Unternehmen, die vor und nach Softwareprojekten einen wesentlichen Beitrag zum Projekterfolg leisten. In dieser Unternehmenssicht spielen (neben dem Software-Lebenszyklus) noch andere Lebenszyklen eine Rolle, da das Softwaresystem in den IT-Lebenszyklus und dieser wieder in den Unternehmenslebenszyklus eingebunden ist.^[3] Mit Unternehmen ist hier immer das Unternehmen gemeint, das die Software auch tatsächlich einsetzt.

Wie auch RUP beschreibt der Enterprise Unified Process ein idealtypisches Organisations- und Vorgehensmodell. Er schafft einen Überblick über alle Aktivitäten, Rollen und Erzeugnisse, die für erfolgreiche Planung und Einsatz von Softwareprojekten im Unternehmen notwendig sind. Wie bei allen Vorgehensmodellen ist vor dem Einsatz in einem konkreten Unternehmen eine Anpassung (tailoring) notwendig, um a) auf die spezifischen Unternehmensbedingungen Rücksicht nehmen zu können und b) eine der Unternehmenslernkurve angepasste, stufenweise Übernahme der einzelnen Praktiken und Methoden zu gewährleisten.

Ebenso wie RUP, ist der Enterprise Unified Process im Großen sequentiell, im Kleinen iterativ ("serial in the large and iterativ in the small"^[4]).

• Konzeptionsphase
• Entwurfsphase
• Konstruktionsphase
• Übergabephase
• Produktion
• Außerbetriebnahme

Folgende Vorgehensweise wird für die Einführung von EUP im Unternehmen vorgeschlagen^[5]. Es muss aber jedes Unternehmen für sich entscheiden, wo die dringendsten Probleme liegen und mit welchen EUP-Elementen begonnen werden sollte.

1. Software Process Improvement
2. Phase "Production" und Arbeitsschritt "Operations und Support"
3. Enterprise Business Modelling, Enterprise Architecture und Portfolio Management
4. People Management und Enterprise Administration
5. Strategic Reuse
6. Phase "Retirement"

• Rational Unified Process
• Vorgehensmodell zur Softwareentwicklung
• Extreme Programming
• Vorgehensmodell

1. ↑ Siehe Ramsin(2008) und Ambler et al. (2005) zu den historischen Details des EUP
2. ↑ http://enterpriseunifiedprocess.com/
3. ↑ Ambler et al. (2005) S. 7
4. ↑ Ambler et al. (2005) S. 14 ff
5. ↑ Ambler et al. (2005) S. 326 ff.

• The Unified Process Inception Phase. CMP Books, 2000. 
• The Unified Process Elaboration Phase. CMP Books, 2000. 
• The Unified Process Construction Phase. CMP Books, 2000. 
• The Unified Process Transition and Production Phases. CMP Books, 2002, ISBN 1-57820-092-X (Online [abgerufen am 28. November 2009]). 
• The Enterprise Unified Process : extending the Rational Unified Process. Prentice Hall PTR, 2005, ISBN 978-0-13-191451-3. 
• Ramsin, Raman: Process-centered review of object oriented software development methodologies. In: ACM Computing Surveys (CSUR). Band 40, Nr. 1. Association of Computing Machinery ACM, 2008, S. 1–89, doi:10.1145/1322432.1322435.