14.04.2008 Autor: Manfred Kricke Rational Unified Process Manfred Kricke.
-
Upload
adelric-hemmert -
Category
Documents
-
view
115 -
download
0
Transcript of 14.04.2008 Autor: Manfred Kricke Rational Unified Process Manfred Kricke.
14.04.2008Autor: Manfred Kricke
Rational Unified Process
Manfred Kricke
14.04.2008Autor: Manfred Kricke
Die sechs Schlüsselprinzipien des RUP (Rational Unified Process)
• Adapt the process - Anpassen des Prozesses (Tailoring)• Balance stakeholder priorities - Anforderungen und
Interessen berücksichtigen • Collaborate across teams - Zusammenarbeit in Teams• Demonstrate value iteratively - Iterative Wertschöpfung
für den Anwender • Elevate the level of abstraction - den Abstraktionsgrad
hervorheben (UML-getrieben) • Focus continuously on quality - Fokussierung auf
kontinuierliche Qualitätssteigerung
Der RUP ist ein umfangreiches Rahmenwerk für Software-Entwicklungsprozess.
14.04.2008Autor: Manfred Kricke
Was zeichnet ihn noch aus?
• Detaillierter Software-Entwicklungsprozess (Software Engineering Process)– Wer (Rolle) macht was (Artefakte), wann (Prozessworkflow) und wie
(Aufgaben)
– Wird als „schwergewichtige“ Methodologie bewertet
• Basiert auf „Best-Practices“– Plug-Ins für verschiedene Anwendungsbereiche, z.B. CMMI-Mapping
– Kann als Wissenbasis (Knowledgebase) eingesetzt werden
• Basiert stark auf den Einsatz von Tools (Rational Produktfamilie)
• Use-Case getrieben– Basis für weitere Entwicklungen sind Use-Cases
• Architekturzentriert– Architektur gibt Struktur vor, Schwerpunkte sind Komponenten und
Subsysteme
• Risikominimierend (durch iterativ inkrementellen Prozess)
14.04.2008Autor: Manfred Kricke
Prozessstruktur des RUP
• Phasen(enden) stellen im wesentlichen Meilensteine dar
– Konzeption (Inception)
– Entwurf (Elaboration)
– Implementierung (Construction)
– Produktionsübergabe (Transition)
• Disziplinen sind in den Phasen von unterschiedlicher Bedeutung
– Business Modeling
– Requirements
– Analysis & Design
– Implementation
– Test
– Deployment
– Configuration & Change Mgnt
– Project Management
– Environment
• Horizontale Sicht– stellt den dynamischen Aspekt (Fortschritt auf
der Zeitachse, Phasen, Iterationen und Inkremente) dar
• Vertikale Sicht – gibt den statischen Aspekt (Beschreibungen der
Aufgaben, Rollen, Arbeitsergebnisse) wieder
horizontale Sichtve
rtik
ale
Sic
ht
14.04.2008Autor: Manfred Kricke
• Der dynamische Aspekt führt zur Zerlegung des Entwicklungsprozesses wird in kleinere Entwicklungszyklen
• Jeder Entwicklungszyklus führt zu einer vollständigeren „Generation“ des Produkts.• RUP zerlegt diesen Entwicklungszyklus in vier aufeinanderfolgende Phasen
– Konzeption (Inception)
– Entwurf (Elaboration)
– Implementierung (Construction)
– Produktionsübergabe (Transition)
• Jede dieser Phasen beinhaltet einen genau definierten Meilenstein – ein Zeitpunkt an dem für den Projekterfolg kritische Entscheidungen getroffen werden müssen. Aus diesem Grund müssen wichtige Fragestellungen beantwortet werden können.
Iterartionen, Inkremente und Phasen – die zeitliche Dimension
Zeit
Konzeption Entwurf Implementierung Produktionsüb.
Wesentliche Meilensteine
14.04.2008Autor: Manfred Kricke
Iterations-Bewertungen
Iteration n Bewertung
• Vergleichen des Kosten- und des Zeitplans mit der Planung der Iteration
• Festlegen, welche Ergebnisse in den künftigen Iterationen nachgearbeitet werden
• Risiken betrachten, neue, reduzierte, beseitigte, etc.
• Gesamtprojektplan anpassen
• Planung der nächsten Iteration vorbereiten
Überarbeiteter Risikoplan
Überarbeiter Projektplan
• Gesamtkosten
• Gesamtprojektplan
• Fokus und Inhalt
Iteration n +1 Plan
• Kosten
• Zeitplan
• Inhalt
Qualitätsergebnisse für Interation n
• Testergebnisse
• Fehlerhäufigkeit
• Architekturstabilität
• Andere Kennzahlen
Iteration n, Kosten und aktueller Zeitplan
Projektkennzahlen stellen die Basis für Iterations-Bewertungen dar.
14.04.2008Autor: Manfred Kricke
• „Generelle Vision“ der Kernproduktanforderungen – Schlüsselanforderungen
– Wichtigsten Abhängigkeiten/Rahmenbedingungen
• Initiales Use-Case-Model (Vollständigkeit ca. 10%- 20%)• Erster Geschäftsplan,
– Geschäftskontext, Erfolgskriterien und Finanz-Vorschau
• Initiale Risikobewertung und Projektglossar• Projektplan mit Phasen und Iterationen
Phase Konzeption – alle wesentlichen Anforderung sind bekannt
• Das Phasenende Konzeption stellt den ersten wesentlichen Meilenstein dar– Einverständnis der Stakeholder zu Projektumfang, Kosten- und Zeitschätzungen– Gemeinsames Verständnis der Anforderungen ist durch erste Use-Cases bewiesen– Geschätzte Kosten- und Zeitaufwände, Prioritäten, identifizierte Risiken und der Projektplan
haben einen gesicherten Stand– Tiefe und Breite der Zielarchitektur ist durch erste Realisierungen gesichert– Aktuelle Projektkennzahlen weichen nicht signifikant von den Planwerten ab
• Das Projekt kann gestoppt oder neu aufgesetzt werden, wenn diese Ziele nicht erreicht wurden
• Schlüsselfrage: Soll das System gebaut werden?
14.04.2008Autor: Manfred Kricke
• Use-Case-Model zu ca. 80% vollständig– Alle Use-Cases und Akteure sind identifiziert – Fast alle Use-Cases sind vollständig beschrieben
• Zusätzliche Anforderungen und nicht funktionale Anforderungen• Vollständige Software Architekturbeschreibung• Gesicherte Risikoliste und gesicherte Geschäftsvorfälle• Vollständiger Entwicklungsplan
– Projektplan mit allen Iterationen auf grober Aktivitäten-Ebene– Bewertungskriterien für jede Iteration
• Erste Version des Anwenderhandbuches
Phase Entwurf – gekennzeichnet durch Analyse des Problems
• Der Entwurfsmeilenstein ist durch Stabilität und Vervollständigung der initialen Ergebnisse geprägt
– Vision und Architektur sind stabil– Erste Realisierungen zeigen, dass die schwierigsten und mit den höchsten Risiken
behafteten Anforderungen verlässlich umgesetzt werden können– Der Plan für die Entwurfsphase ist ausreichend detailliert und basiert auf verlässlichen
Schätzungen– Alle Stakeholder sind sicher, dass die Vision erfüllt wird, wenn der aktuelle Plan eingehalten
wird– Der tatsächliche Ressourcenverbrauch ist gegenüber den bisherigen Planungen akzeptabel
• Schlüsselfrage: Kann das System gebaut werden?
14.04.2008Autor: Manfred Kricke
• Das Software-Produkt ist auf einer angemessenen Plattform integriert• Die Anwenderhandbücher stehen zur Verfügung• Eine Beschreibung des aktuellen Releases liegt vor
Phase Implementierung – die Entwicklung aller Komponenten und Funktionen
• Fokussierung des Meilensteins auf die Betreibbarkeit des Produkts– Das Release ist ausreichend stabil und reif genug, dass es den Anwendern zur Verfügung
gestellt werden kann– Alle Stakeholder sind mit der Übergabe in den produktiven Betrieb einverstanden– Der tatsächliche Ressourcenverbrauch ist gegenüber den bisherigen Planungen akzeptabel
• Schlüsselfrage: Haben wir das System gebaut?
14.04.2008Autor: Manfred Kricke
• Beta-Tests zur Validierung des neuen/geänderten Produkts gegen die Erwartungen der Anwender
• Installation/Migration der produktiven Datenbanken• Schulungen der Anwender und Betreiber• Rollout des neuen Produkts und ggf. Marketing bei Anwender und Kunden• Lessons Learned des Projekts
Phase Produktionsübergabe – das Produkt steht dem Anwender zur Verfügung
• Die Anforderungen der Anwender sind erfüllt und das Produkt ist betreibbar– Anwender können das Produkt nutzen– Stakeholder stimmen den Betrieb zu und die Baseline steht vollständig im Einklang mit der
Vision– Das finale Produkt wurde so schnell und effizient wie möglich erstellt
• Schlüsselfrage: Haben wir das System ausgeliefert?
14.04.2008Autor: Manfred Kricke
Verteilung des Aufwands auf die Phasen
Typische Verteilung
Konzeption Entwurf Implementierung Produktionsübergabe
5%
20%
65%
10%
Quelle: Wirtschaftsuniversität WienInstitut für InformationswirtschaftJanko/Hahsler/Koch
Je mehr echte Neuentwicklung, desto mehr Aufwand verlagert
sich von Implementierung nach Konzeption und Entwurf
Zeit
Res
sou
rcen
14.04.2008Autor: Manfred Kricke
Iterartionen, Inkremente und Phasen – die zeitliche Dimension
Zeit
Konzeption Entwurf Implementierung Produktionsüb.
Projektlaufzeit
1. Inkrement 2. Inkrement 3. Inkrement
Iteration 1 It. 2 It. 3 It. 4 It. 5 It.6
GeschäftsprozessmodellierungAnforderungen
Analyse & DesignImplementierung
TestAuslieferung
KonfigurationsmanagementPlanung, Support,
• Aufteilung in sinnvolle fachliche Pakete (User Value)
• Wichtige Entscheidungen zu Phasenmeilen (Management muss die Entscheidungen treffen)
• Mehrere Iterationen, in denen alle Disziplinien von unterschiedlich stark ausgeprägter Bedeutung sind, führen zum geforderten fachlich sinnvollen Paketen (User Value).
14.04.2008Autor: Manfred Kricke
Rollen , Artefakte und Aktivitäten – die statische Dimension
Architekt
Model
Model entwickeln
• Eine Rolle definiert das Verhalten und das Verhalten einer einzelnen Person oder einer Gruppe von Personen in einem Team
• Die Rolle kann als „Hut“ betrachtet werden, den eine Person in einem Projekt aufsetzten kann
Person(en)Rolle Aktivität
Anton
Bert
Conny
Danny
Emil
Architekt Model entwickeln
Designer Use-Case definieren
Entwickler Programmieren
Tester Programm testen
Management Meilenstein freigeben
• Personen können in einem Projekt auch mehr als einen Hut aufsetzen
• Dieses kann nicht parallel aber sequentiell erfolgen
• Abhängigkeiten wie, „ein Tester darf nicht seine eigene Entwicklung testen, müssen berücksichtigt werden“
14.04.2008Autor: Manfred Kricke
Aktivitäten sind spezifischen Rolle verantwortlich zugewiesen
• Jede Aktivität hat ein klares Ziel. In der Regel die Erstellung oder Weiterentwicklung von Artefakten, wie Designmodelle, eine Klasse, einen Plan oder die Durchführung eines Tests
• Aktivitäten können zwischen ein paar Stunden und ein paar Tage Zeit in Anspruch nehmen, in denen sie ein oder wenige Artefakte erstellen bzw. verändern
• Eine Aktivität sollte ein sinnvolles und planbares Element sein. Ist sie zu „klein“ geschnitten, wird sie meist vernachlässigt. Ist sie zu „groß“, lässt sich der Fortschritt schlecht messen und sie sollte weiter zerlegt werden
Aktivität
Testplan entwicklen
Iteration planen
Use-Case definieren
Design Review
Baseline erstellen
Rolle
Testmanager
Projektmanager
Systemanalyst
Reviewer
Konfig.-manager
14.04.2008Autor: Manfred Kricke
Artefakte sind die Ergebnisse der Aktivitäten
• Ein Artefakt ist eine Information, die von einem Prozess verwendet, erstellt oder verändert wird
• Artefakte sind „greifbare“ Produkte die im Projekt als Zwischenstufen bis zur Erstellung des Endprodukts erstellt werden
• Sie können so wohl Eingabe als auch gleichzeitig Ausgabe einer Aktivität sein• Einige Artefakte sind nach Projektende bedeutungslos, andere werden als „deliveries“
weiter Bestand haben
Modelle wie, Use-Case-Model, Design-Model, Komponenten-Model
Pläne wie, Zeitplan, Reviewplan, Budgetplan
Protokolle
Entscheidungsliste, Risikoliste oder offene Punkte Listen
14.04.2008Autor: Manfred Kricke
Disziplinen geben den Workflow wieder
Im Rational Unified Process gibt es neun Kern-Workflows, die
sich wie folgt aufteilen:• Sechs Ingenieurs-Disziplinen
– Geschäftsprozessmodellierung
– Anforderungsmanagement
– Analyse und Design
– Implementierung
– Test
– Auslieferung
• Drei unterstützende Disziplienen– Konfigurations- und Changemanagement
– Projektmanagement
– Entwicklungsumfeld
Achtung! Die Namen der sechs Ingenieurs-Disziplinen suggerieren die Phasen eines Wasserfall-Vorgehensmodels
14.04.2008Autor: Manfred Kricke
Geschäftsprozessmodellierung
• Erfassen der fachlichen Anforderungen• Für den Kunden wichtige Arbeitsabläufe/Prozesse
erfassen• Darstellung der Arbeitsabläufe in UML-Notation, z.B.
Aktivitätsdiagramm• Kontext der Einbindung in die bestehende Auswahl von
Anwendungen wird festgelegt
In der Geschäftprozessmodellierung müssen die Anforderungen vollständig erfasst werden – da dieses maßgeblich zum Projekterfolg
beiträgt. Außerdem muss mit den anderen Disziplinen eine angemessene Kommunikation stattfinden.
14.04.2008Autor: Manfred Kricke
Anforderungsmanagement
• Festlegen, was das System leisten leisten soll• Fachliche und „nicht funktionale“ Anforderungen sammeln
und managen• Stakeholder in angemessenem Umfang einbeziehen und der
Zustimmungen einholen• Use-Case und Use-Case-Model erstellen • Bidirektionale Nachverfolgbarkeit der Anforderungen
sicherstellen
XXXX
14.04.2008Autor: Manfred Kricke
Analyse und Design
• Festlegen, wie dass System realisiert werden wird• Ein vollständiges Designmodel wird entwickelt• Die in den Use-Case beschriebenen Aufgaben und
Funktionen werden spezifiziert• Auch alle übrigen Anforderungen analysiert • Eine robuste Architektur wird entwickelt, sie lässt
Änderungen der Anforderungen leicht umsetzen
Die Beantwortung aller Architekturfragen steht besonders in frühen Iterationen im Vordergrund. Die Gesamtarchitektur stellt eine
unterschiedliche Zahl von Sichten auf das System dar.
14.04.2008Autor: Manfred Kricke
Implementierung
• Definieren, wie und welchen Schichten die Source-Files des Systems geschnitten wird, z.B. Subsysteme
• Implementieren von Klassen und Objekten in Form von Komponenten (Source-Files, binär-Dateien, ausführbare Einheiten und andere)
• Modultests durchführen• Einzelergebnisse der Entwickler oder Entwicklerteams zu
einer ausführbaren Einheit zu integrieren
Bei der Implementierung ist große Aufmerksamkeit auf die Wiederverwendbarkeit von Ergebnissen zu richten.
14.04.2008Autor: Manfred Kricke
Test
• Schnittstellen zwischen den unterschiedlichen Komponenten testen
• Die ordnungsgemäße Integration aller Komponenten testen
• Prüfen, ob alle Anforderungen korrekt implementiert wurden
• Sicherstellen, dass alle Fehler entdeckt, adressiert und deren Beseitigung priorisiert wird
Hinter der Disziplin Test verbergen sich so wohl die Validation „Wurde das Richtige umgesetzt?“ und die Verifikation „Wurde es richtig
umgesetzt?“
14.04.2008Autor: Manfred Kricke
Auslieferung
• Hauptaufgabe ist das erfolgreiche Releasing und die Bereitstellung von Software
– Erstellen von externen Software-Releases
– Packages der Software erstellen
– Verteilung und Installation der Software
– Die Anwender unterstützen
• Häufig zählen dazu auch Aktivitäten wie– Planung und Durchführung von Beta-Tests
– Migration bestehender Software oder Daten
– Software „außer Betrieb“ nehmen
– Formale Abnahmen durch den Endanwender einholen
Die Disziplin hat eine sehr große Schnittstelle zu ITIL-Prozessen.
14.04.2008Autor: Manfred Kricke
Konfigurations- und Changemanagement
• Richtlinien für den Umgang mit unterschiedliche Software-Versionen zur Verfügung stellen
• Parallele Änderungen an einem Ergebnis managen, dieses ist bei iterativer von großer Bedeutung
• Die Verwaltung von Projektdaten regeln• Baselines erstellen und verwalten• Die Nachverfolgbarkeit von Änderungen sicherstellen: „Was
war der Auslöser für eine Änderung eines Ergebnisses?“
In der Geschäftprozessmodellierung müssen die Anforderungen vollständig erfasst werden – da dieses maßgeblich zum Projekterfolg
beiträgt. Außerdem muss mit den anderen Disziplinen eine angemessene Kommunikation stattfinden.
14.04.2008Autor: Manfred Kricke
Projektmanagement
• Zeit- und Budgetplanung, Definition von Meilensteinen• Integration verschiedener Detailpläne• Beschaffung und Ausbildung von geeigneten
Projektmitarbeitern• Risikomanagement – Vermeidungs- und Minimierungsstrategie
entwickeln, ebenso wie Aktionspläne bei Eintritt eines Risikos• Stakeholdermanagement – Einbeziehung von Personen und
Personengruppen mit Interesse am Projektgeschehen• Berichterstattung, Statusmeetings initiieren
Projektmanagement ist für den Projekterfolg verantwortlich.
14.04.2008Autor: Manfred Kricke
Entwicklungsumfeld
• Bereitstellen von technischen Arbeitsumgebungen• Toolbereitstellung und –unterstützung• Bereitstellen von Prozessen und Prozessunterstützung
Explizit ausgeklammert sind allerdings der Beschaffungsprozess oder die Toolauswahl in der Organisation.
14.04.2008Autor: Manfred Kricke
Einige Fallstricke, über die man bei der Einführung des Prozesses stolpern kann
• Keine Verabschiedung vom Wasserfall, iteratives Vorgehen wird nicht verinnerlicht
• Eine „pseudo iteratives Vorgehen“ (nur inkrementelles Vorgehen) für zu instabilen Modellen
• Verständnis des sinnvollen Tailorings nicht vorhanden – führt zu häufig zu sturem ausfüllen von „Formularen“
• Rollenmodel wird nicht gelebt – eine Person übernimmt nur eine Rolle
• Mitarbeiter sind nicht ausreichend im Prozess trainiert• Die erforderliche Toolunterstützung ist nicht gegeben
Eine Änderung von Prozessen erfordert immer ein professionelles Veränderungsmanagement – dieses ist ein sehr kritischer Erfolgsfaktor.
14.04.2008Autor: Manfred Kricke
Einige Fallstricke, über die man bei der Einführung des Prozesses stolpern kann
• Keine Verabschiedung vom Wasserfall, iteratives Vorgehen wird nicht verinnerlicht
• Eine „pseudo iteratives Vorgehen“ (nur inkrementelles Vorgehen) für zu instabilen Modellen
• Verständnis des sinnvollen Tailorings nicht vorhanden – führt zu häufig zu sturem ausfüllen von „Formularen“
• Rollenmodel wird nicht gelebt – eine Person übernimmt nur eine Rolle
• Mitarbeiter sind nicht ausreichend im Prozess trainiert• Die erforderliche Toolunterstützung ist nicht gegeben
Eine Änderung von Prozessen erfordert immer ein professionelles Veränderungsmanagement.
14.04.2008Autor: Manfred Kricke
Fazit zum Rational Unified Process
• Gute Präsentation durch webbasierte Oberfläche • Ausgereiftes Rollen und Workflowkonzept, Zuweisung von
Verantwortung• Risikovermindert durch iterativ inkrementelles Vorgehen• Hohe Detaillierungsgrad in den Beschreibungen• Mitarbeiter nehmen den RUP in der Regel gut an• Templates sind teilweise nicht ausgereift – Anpassung auf die
eigene Organisation ohnehin sinnvoll• Suggeriert manchmal „ist doch alles easy“• Optimale Teamgröße ab 10 Mitarbeiter, darunter eher zu
„schwergewichtig“ ab trotzdem aufgrund Tailoring anwendbar
RUP erfüllt die Anforderungen vieler Qualitäts- und Reifegradmodelle.
14.04.2008Autor: Manfred Kricke
Fragen?
14.04.2008Autor: Manfred Kricke
Manfred Kricke
Prozessarchitekt und Projektmanager