Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Ein durchgehend geplanter Ablauf? Marktanalyse der Kundensituation? Erteilen des Entwicklungsauftrags? Festlegen des Entwicklungsprozesses? Informationstechnische Analyse und Design
Wie wird heute gearbeitet? Die Vorteile Ein durchgehend geplanter Ablauf? Implementierung der Ergebnisse? Entwicklung von Systemtests? Testen? Erstellen der Kundendokumentation? Auslieferung an die Kunden Alle Aspekte sind bereits vorher bekannt? Kundensituation? Lösung der Kundenprobleme? Architektur der Software? Genaue Vorschrift zur Implementierung Die Vorteile Die Vorteile Alle Aspekte sind bereits vorher bekannt? genau bekannter Aufwand der Realisierung? gesicherte Qualität? alle erstellten Features werden dokumentiert? festgelegter Einführungstermin? Der Personalaufwand ist bekannt? Der Zeitaufwand ist bekannt? Der Auslieferungstermin ist bekannt? Die Kosten sind bekannt
Die Vorteile Die Realität Der wirtschaftliche Erfolg des Projekts ist planbar von sind»hardware«die Entwicklungsprozesse sind die Risiken in bei der der Produktion Informationstechnik nicht genau nicht abschätzbar. Die Anzahl Die Anzahl der Variablen der Variablen im Entwicklungs- und Risiken ist prozess um vieles ist höher, sehr viel das größer, System das neigt System zu niegt dazu chaotischem»chaotisch Verhalten. zu werden. Die Erkenntnis... Die Erkenntnis... Entwicklungsprozesse in der Informationstechnologie sind nur schwer planbar. Sie sind nicht komplett beherrschbar
... und die Folgen Die Probleme... Es treten zwangsläufig nicht vorhersehbare Probleme auf, die zu Verzögerungen und Verteuerungen führen und nicht selten ein IT- Projekt vor der Fertigstellung scheitern lassen.? zu ungenaue Spezifikationen? zu langsame Entwicklung? zu viele Fehler? zu teuer? zu träge um auf Änderungen zu reagieren... und die Folgen Die Folge? das Produkt entspricht nicht den Erwartungen? die Markteinführung erfolgt zu spät? die Kunden sind unzufrieden? der Kostenrahmen wird gesprengt? der Markt hat sich bereits wieder geändert Das Produkt scheitert!
Der Unified Process Historisches Die Väter der Objektorientierung Grady Booch Anzahl der Variablen im Entwicklungs- Ivar Jacobson prozess ist sehr viel größer, das System niegt James Rumbaugh von 1987»Hardware«- 1995: Objectory sind Process die Risiken 1.0 - bei 3.8 der Produktion 1996-1997: nicht Rational genau Objectory abschätzbar. Process Die 4.1 Anzahl der Variablen Unified Modelling im Entwicklungs- Language prozess 1997 - heute: ist sehr Rational viel größer, Unified das Process System 5.0 niegt Schlagworte Schlagworte Im Der Gegensatz Unified Process zur industriellen kann durch folgende Fertigung von Schlagworte»Hardware«beschrieben sind die werden: Risiken bei der? Use-Case getrieben Anzahl der Variablen im Entwicklungs-? Architektur zentriert prozess? Iterativ ist sehr viel größer, das System niegt dazu? Inkrementell»chaotisch zu werden. Die Position eines Entwicklungsprozesses: Anwender- Entwicklungs Software Anzahl der Variablen im Entwicklungs- Forderungen prozeß System prozess ist sehr viel größer, das System niegt
Use-Case getrieben Use-Case getrieben von Ein Softwaresystem»Hardware«sind wird die entwickelt Risiken um bei den der Anwendern zu helfen. Dazu muß der Entwickler wissen, was die Anwender brauchen und wollen. Anzahl Um dies der herauszufinden Variablen im werden Entwicklungs- Aktionen in Useprozess Cases oder ist Anwendungsfällen sehr viel größer, das beschrieben. System niegt von Use-Cases»Hardware«beschreiben sind alle die Aktionen Risiken bei die das der Produktion Softwaresystem nicht ausführt. genau abschätzbar. Die Anzahl der Variablen im Entwicklungsprozess Use-Cases ist steuern sehr viel den größer, Entwicklungsprozeß. das System niegt Architektur zentriert Architektur zentriert Zuerst werden die Use-Case unabhängigen Teile der Architektur realisiert. Sie betreffen den von Anzahl der Plattform der Variablen unabhängigen im Entwicklungs- Teil. prozess ist sehr viel größer, das System niegt von Die Architektur»Hardware«wird sind mit die aus Risiken den wichtigsten bei der Use-Cases weiterentwickelt. Diese Use-Cases repräsentieren Schlüsselpositionen. Jeder dieser Anzahl Use-Cases der wird Variablen im Hinblick im Entwicklungs- auf Subsystem prozess spezifiziert ist und sehr realisiert. viel größer, das System niegt
Architektur zentriert Architektur zentriert von Je mehr»hardware«use-cases sind spezifiziert die Risiken sind, um bei so der mehr Produktion der Architektur nicht wird genau enthüllt.die abschätzbar. führt dazu, Die daß Anzahl die Architektur der Variablen mit der Anzahl im Entwicklungs- der beschriebenen prozess Use-Cases ist reift. sehr viel größer, das System niegt Dies wird solange durchgeführt, bis die Architektur des Systems als stabil beurteilt Anzahl werden kann. der Variablen im Entwicklungsprozess ist sehr viel größer, das System niegt Iterativ Iterativ von Die Entwicklung»Hardware«ist sind ein iterativer die Risiken Prozeß, bei der der in einer Abfolge von Teilaufgaben die Kundenvorgaben realisiert. Der Entwickler Anzahl nähert sich der schrittweise Variablen (in im Iterationen) Entwicklungs- immer prozess näher an ist die sehr Kundenvorgabe viel größer, an. das System niegt von Das»Hardware«Projekt wird deshalb sind die in kleine Risiken Teilprojekte bei der aufgeteilt. Um effektiv mit diesen kleinen Teil- projekten zu arbeiten, müssen sie kontrolliert Anzahl werden. der Sie müssen Variablen ausgewählt im Entwicklungs- und in einer prozess geplanten ist Vorgehensweise sehr viel größer, ausgeführt das System werden. niegt
Iterativ Iterativ Im In den Gegensatz Iterationen zur werden industriellen immer wieder Fertigung die von gleichen»hardware«tätigkeiten sind durchlaufen: die Risiken bei der? Analyse Anzahl der Variablen im Entwicklungs-? Design prozess? Implementation ist sehr viel größer, das System niegt dazu? Test»chaotisch zu werden. Im Für Gegensatz jede Iteration zur gilt: industriellen Fertigung? Produktion Alle implementierten nicht genau Use-Cases abschätzbar. erweitern Die im Zusammenspiel das Softwaresystem. Anzahl der Variablen im Entwicklungsprozess? Die größten ist sehr Risiken viel größer, werden das in den System Iteration niegt dazu berücksichtigt»chaotisch zu werden. Iterativ Iterativ Kontrollierte Iterationen reduzieren das Kostenrisiko, das bei Entwicklungen in einem Anzahl einzigen der Inkrement Variablen besteht. im Entwicklungsprozess ist sehr viel größer, das System niegt Im Kontrollierte Gegensatz Iteration zur industriellen vermindern das Fertigung Risiko, von nicht»hardware«zum geplante sind Zeitpunkt die Risiken mit der System- bei der Produktion entwicklung nicht fertig zu genau sein. abschätzbar. Schwierigkeiten Die Anzahl werden in der den Variablen frühen Iteration im Entwicklungs- bereits gelöst, prozess wenn die ist Mitarbeiter sehr viel noch größer, nicht das unter System Zeitdruck niegt dazu stehen.»chaotisch zu werden.
Iterativ Iterativ von Kontrollierte»Hardware«Iteration sind erhöhen die Risiken die Arbeits- der Produktion geschwindigkeit, nicht da genau die Entwickler abschätzbar. klare, Die Anzahl kurzfristige der Vorgaben Variablen erfüllen, im Entwicklungs- die schnell prozess realisiert ist werden sehr können viel größer, das System niegt von Kontrollierte»Hardware«Iteration sind ermöglichen die Risiken die bei Korrektur der der niemals vollständigen Anwenderforderungen noch während der Systementwicklung. Dadurch Anzahl werden auch der Variablen Änderungen im leichter Entwicklungs- möglich prozess gemacht. ist sehr viel größer, das System niegt Lebenszyklen Lebenszyklen Der Unified Process wiederholt seine Aktivitäten Im in einer Gegensatz Serie von zur Zyklen industriellen von der Geburt Fertigung bis zum von Tod»Hardware«eines Produktes. sind die Risiken bei der Geburt Tod Anzahl der Variablen im Entwicklungsprozess ist sehr viel größer, das System niegt Zyklen, die mit einem fertigen Release enden Jeder Zyklus besteht aus 4 Phase. Jede Phase ist Im in einzelne Gegensatz Iterationen zur industriellen unterteilt, die Fertigung in Releases von enden.»hardware«sind die Risiken bei der Inception Elaboration Construction Transition Anzahl der Variablen im Entwicklungsprozess ist sehr viel größer, das System niegt Releases
Das Produkt Das Produkt von Jeder»Hardware«Zyklus resultiert sind in die einem Risiken neuen bei Release. der Jedes Release ist bereit zur Auslieferung an den Kunden. Das fertige Produkt muß nicht nur den Anzahl Anforderungen der Variablen des Anwenders im Entwicklungs- genügen sondern prozess auch denen ist aller sehr anderen viel größer, Beteiligten. das System niegt Ein Produkt besteht nicht nur aus dem Sourcecode oder den lauffähigen Binaries: Produktion? Anforderungen nicht genau abschätzbar. Die? Anzahl Use-Cases der Variablen im Entwicklungs-? nichtfunktionale Spezifikationen prozess? Test-Cases ist sehr viel größer, das System niegt? dazu Architektur»chaotisch zu werden.? Klassenmodell Das Produkt Inception Phase Use-Case Modell? Produktion Analyse-Modell, nicht spezifiziert genau durch abschätzbar. die Use-Cases Die? Anzahl Design-Modell, der Variablen realisiert aus im den Use-Cases Entwicklungs-? Deployment-Modell, verteilt aus den Use-Cases prozess ist sehr viel größer, das System niegt? Implementation-Modell, implementiert aus den Use-Cases? Test-Modell, geprüft mit den Use-Cases Im In der Gegensatz Inception-Phase, zur industriellen der Anfangsphase Fertigung des von Projekts,»Hardware«wird aus einer sind guten die Risiken Idee eine bei Vision der Produktion des Endproduktes nicht entwickelt. genau abschätzbar. Es wird ein Die Use- Anzahl Case Modell der Variablen mit den kritischsten im Entwicklungs- Use- Cases prozess erarbeitet ist und sehr die viel Risiken größer, des Projekts das System niegt dazu identifiziert.»chaotisch zu werden.
Elaboration Phase Construction Phase von In der»hardware«elaboration Phase, sind die der Risiken Ausarbeitungs- der phase, werden die Use-Cases spezifiziert und die Architektur herausgearbeitet. Es werden einige Anzahl grundsätzliche der Variablen Use-Cases im implementiert Entwicklungs- und das prozess System macht ist sehr die viel ersten größer, Schritte das System niegt In der Construction Phase, der Konstruktions- Im phase, Gegensatz wird das zur System industriellen implementiert. Fertigung Die von Architektur»Hardware«ist nahezu sind vollständig die Risiken und bei das der Produktion ist fertig nicht für genau die Auslieferung abschätzbar. an Die die Anzahl Endanwender. der Variablen Alle wichtigen im Entwicklungs- Use-Cases sind prozess enthalten ist und sehr implementiert. viel größer, Einige das System Fehler sind niegt dazu noch vorhanden,»chaotisch die zu in werden. folgenden Versionen entfernt werden. Transition Phase Ein integrierter Pozeß In der Transition Phase, der Überleitungsphase, Im wird Gegensatz das System zur an industriellen einige ausgesucht Fertigung ß-Tester von ausgeliefert.»hardware«die gefundenen sind die Risiken Fehler werden bei der beseitigt und einige neue Use-Cases werden für die Auslieferungsversion noch implementiert. In Anzahl der Auslieferungsphase der Variablen werden im Entwicklungs- Kunden trainiert, prozess die Berater ist geschult sehr viel und größer, Fehler das lokalisiert System und niegt dazu klassifiziert,»chaotisch damit zu sie werden. im nächsten Kundenrelease nicht mehr vorhanden sind. Der Unified Process ist komponentenbasiert. Er Im nutzt Gegensatz moderne Werkzeuge zur industriellen zur Visualisierung Fertigung und von basiert»hardware«auf drei Grundideen: sind die Risiken den Use-Cases, bei der der Produktion Architektur und nicht der genau iterativen abschätzbar. und inkrementellen Die Anzahl Entwicklung. der Variablen Um die Ideen im Entwicklungs- zu Leben zu prozess erwecken, ist ist sehr ein vielschichtiger größer, das Prozeß System nötig. niegt dazu Dazu»chaotisch stellt der Unified zu werden. Process ein Framework zur Verfügung, das alle Tätigkeiten integriert.
Impressum Impressum Dieser Vortrag kann im Internet unter www.fischer-software.de herunter geladen werden. Er liegt als Star-Office und als Microsoft-Office Dokument vor. Bitte beachten Sie die Copyrights. Der Autor ist unter folgender Adresse erreichbar: Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Tel.: +49 711 9977390 Fax.: +49 711 9977391 Email: Hannes.Fischer@fischer-software.de Ende