Zum Inhalt springen

Kurs:Wirtschaftsinformatik SS09/SE1/Lernskript/Unified Process

Aus Wikiversity

Charakteristika

[Bearbeiten]

Iterative and Incremental

[Bearbeiten]

Unified Process ist ein iterativer und inkrementeller Prozeß. Die Elaboration, Construction und Transition sind eingeteilt in eine Serie von iterativen Zeitfenstern. Jede Iteration endet bei einem Inkrement, d.h. ein Release eines um Funktionalität verbessertes System.

Die Iterationen finden in den Prozeßdisziplinen Requirement, Design, Impleementation und Testing statt. Der Arbeitaufwand in jeder Iteration wird im Projektverlauf entschieden.

Use Case Driven

[Bearbeiten]

Beim Unified Process werden Use Cases verwendet, um Funktionalität und Inhalt der Anforderungen zu erkunden. Jede Iteration veerbraucht eine Menge an Use Cases oder Szenarien beginnend mit den Requirements entlang des Weges an der Implementation vorbei zum Testing und endend beim Deployment.

Architecture Centric

[Bearbeiten]

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Der Unified Process hat seinen Lebensnerv bei der Ernsthaftigkeit, wie das Projekt Team die Architektur formt. Kein einzelnes Architekturmodell ist in der Lage, alle Aspekte in der Praxis einzufangen, daher unterstützt das Unified Process unterschiedliche Varianten, Modelle und Views. Eines der wesentlichen Ergebnisse beim Unified Process ist das executable architecture- das Fundament für weitere Entwicklung als Resultat der Elaboration. Diese Teilimplementation validiert die Architektur und dient als Basis weiterer Entwicklungsschritte.

Risk Focused

[Bearbeiten]

Beim Unified Process fokussiert sich das Projektteam möglichst früh auf die kritischen Risiken im Lebenszyklus. Die Iteration , insbesondere in der Elaboration sollen in einer Reihenfolge und Ordnung sich ereignen, so dass die kritischen Risiken rasch angegriffen werden.


  • Softwareprozess im Sinne der Entwickler der UML, Hauptaugenmerk auf Anforderungsmanagement, Analyse und Design
  • iterativ und inkrementell, dadurch Entschärfung von Risken und Handhabung sich ändern-

der Anforderungen

  • use-case-getrieben, um bedeutende Anforderungen zu identifizieren, eine einfache Erstel-

lung und Validierung der Architektur zu ermöglichen und den Prozess voranzutreiben

  • Architekturzentriert, um Verständnis des Systems zu vertiefen, Entwicklung zu organisieren,

Wiederverwendung zu fördern und die Weiterentwicklung des Systems zu unterstützen

Phasen beim Unified Process

[Bearbeiten]
  • Inception (Konzeption): Festlegung des Geschäftsfelds und des Umfangs des Projekts

sowie der zugehörigen Systemgrenzen

  • Elaboration (Entwurf): Planung der notwendigen Aktivitäten und Ressourcen sowie Spezi-

fizierung der Funktionalität und Architektur

  • Construction (Konstruktion): Implementierung basierend auf der erstellten Architektur
  • Transition (Übergabe): Bereitstellung des Produkts für den Kunden sowie Konfiguration

und Überprüfung der Einhaltung der Vorgaben durch Beta-Tests der Benutzer

Core-Workflows

[Bearbeiten]

Diese Phasen werden iterativ (auch mehrmals) durchlaufen, wobei folgende Core Workflows in jeder Phase als Aktivitäten auftreten können

  • Requirements
  • Analysis
  • Design
  • Implementation
  • Test

Rational Unified Process

[Bearbeiten]
  • eine konkrete Implementierung des Unified Process ist der Rational Unified Process

Vor- und Nachteile des Unified Process

[Bearbeiten]
  • Vorteile: basiert auf der UML, Berücksichtigung der Wechselwirkung zwischen Anforderun-

gen und Architektur, basiert auf Erfahrungen mehrerer Vorgehensweisen

  • Nachteile: insgesamt noch unausgereift und zu wenig erprobt, keine klaren Definitionen von

Rollen, zu unkonkret für praktische Anwendungen

  • Charakteristiken: iterativ und inkrementell (Folge: Entschärfung von Risiken, …), Use
  • Case – getrieben (Folge: einfache Erstellung und Validierung der Architektur

möglich) und architekturzentriert (Folge: Widerverwendbarkeit, Weiternetwicklung möglich)


Vorteile

[Bearbeiten]
  • Basierend auf UML
  • Berücksichtigt Use – Cases
  • Wechselwirkung Anforderungen ↔ Architektur
  • Iterativ
  • Erfahrungen mehrerer Vorgehensweisen

Nachteile

[Bearbeiten]
  • Unausgereift
  • wenig erprobt
  • zu unkonkret