| Projektphase |
Prozeßschritt |
Beschreibung |
| Geschäftsprozeß-Analyse |
Gemeinsames Vokabular definieren |
Es wird ein gemeinsames Vokabular mit Begriffsdefinitionen aus dem Problemraum erstellt, das dann konsistent in allen Beschreibungen verwendet wird. Das Vokabular hält die Textbeschreibungen einheitlich und vermeidet Mißverständnisse über die Verwendung und Bedeutung von Begriffen unter den Projektmitgliedern. |
|
Akteure bestimmen
Use-Case-Modell
erarbeiten
Use-Case beschreiben |
Die Geschäftsprozeß-Analyse findet auf Basis von Use-Case-Beschreibungen statt. Das Vorgehen ist eine konsistente und geradlinige Art, um die Anforderungen an unterstützende IT-Systeme zu erstellen.
Es werden die Akteure ermittelt um die Grenzen des jeweiligen Geschäftsprozesses zu bestimmen. Anhand von Use-Case-Beschreibungen und einem Use-Case-Modell, wird der Ablauf der Geschäftsprozesse dokumentiert. |
|
Use-Case-Analyse |
Im Rahmen der Use-Case-Analyse während der Geschäftsprozeß-Analyse, werden die Objekte identifiziert um die Use-Case-Abläufe zu realisieren. Weiterhin werden die Zuständigkeiten in Form von Funktionen, Attributen und Beziehungen auf die Objekte verteilt. |
|
Review der Geschäftsprozeß-Analyse |
Es findet ein Review über die erarbeiteten Ergebnisse der Geschäftsprozeß-Analyse statt. |
| Anforderungs-Analyse |
Projektvision erstellen |
Die Projektvision beschreibt die Hauptmerkmale des Systems, definiert die Grenzen des Systems, identifiziert die Nutzer des Systems und legt fest welche Probleme mit dem zu erstellenden System gelöst werden sollen. |
|
Akteure bestimmen
Use-Case-Modell erarbeiten
Use-Case beschreiben |
Die Anforderungs-Analyse findet, wie die Geschäftsprozeß-Analyse auch, auf Basis von Use-Case-Beschreibungen statt.
Es wird ein Use-Case-Modell erarbeitet, sowie die Use-Cases beschrieben. |
|
Design der Benutzerschnittstelle |
Es wird das Design der Benutzerschnittstelle modelliert und diese im Rahmen eines Prototypen visualisiert. |
|
Review der Anforderungen |
Die Ergebnisse der Anforderungs-Analyse werden einem Review unterzogen. |
| Konzeption Architektur |
Architektonische Analyse |
Im Rahmen der architektonischen Analyse erfolgt die Definition und Festlegung der:
- generellen Architekturprinzipien
- Schlüsselmechanismen
- Modellierungsrichtlinien
- Strategie zur Wiederverwendung von Softwarekomponenten
- Organisation der High-Level-Subsysteme
|
|
Use-Case-Analyse |
Im Rahmen der Use-Case-Analyse werden die Klassen identifiziert, um die Use-Case-Abläufe zu realisieren. Weiterhin werden die Zuständigkeiten in Form von Funktionen, Attributen und Beziehungen auf die Klassen verteilt. |
|
Architektonisches Design |
Die Interaktionen zwischen den Analyse-Klassen werden studiert, um Schnittstellen, Design-Klassen und Design-Subsysteme zu identifizieren.
Weiterhin werden Gemeinsamkeiten im Design erarbeitet um die Wiederverwendung zu fördern.
|
|
Beschreibung der Gleichläufigkeit |
Es werden die Anforderungen bezüglich der gleichzeitigen Ausführung der Anwender durch mehrere Benutzer im Design beschrieben.
Weiterhin werden die notwendigen Prozesse und Kommunikationsmechanismen zwischen den Prozessen identifiziert.
|
|
Beschreibung der Verteilung |
Es wird die Verteilung der einzelnen Komponenten auf die geplanten Rechner auf Basis von Client-Server-Konzepten festgelegt und beschrieben. |
|
Subsysteme Design |
Für jedes Subsystem wird das spezifizierte Verhalten der Schnittstellen durch die Beschreibung der Interaktionen zwischen den im Subsystem enthaltenen Klassen modelliert. Weiterhin wird die interne Struktur der Subsysteme sowie die Abhängigkeiten zu anderen Subsystemen modelliert. |
|
Review der Architektur |
Die Architektur wird einem Review unterzogen. |
| Konzeption Design |
Klassen-Design |
In dieser Phase werden die Klassen soweit detailliert, daß genügend Informationen für die direkte Implementierung der Klasse vorhanden ist. Hierzu gehört die Identifikation persistenter Klassen sowie die Modellierung der Schnittstellen, Funktionen, Attribute, Beziehungen, Generalisierungen und möglichen Zuständen der Klassen. |
|
Datenbank-Design |
Im Rahmen des Designs der Datenbank, werden die notwendigen Tabellen und Beziehungen auf Basis der Klassenmodelle modelliert und die Transformationen zwischen den Design-Klassen und Tabellen festgelegt. Weiterhin wird das notwendige Speicherlayout der Datenbanken festgelegt. |
|
Review des Designs |
Das endgültige Design wird einem Review unterzogen. |
| Implementation |
Strukturierung des Implementationsmodells |
Festlegen der Struktur in der die Implementierung entwickelt wird. |
|
Implementation Komponenten |
Es wird der Sourcecode zu den identifizierten Design-Klassen entwickelt. |
|
Integration Subsysteme |
Die entwickelten Komponenten werden zu Subsystemen integriert. |
|
Test Subsysteme |
Es findet eine Überprüfung der Subsysteme bezüglich der internen Struktur und Spezifikation statt. |
|
Integration Systeme |
Die entwickelten Subsysteme werden zu einem lauffähigen System integriert. |
| Test |
Testplanung |
Es werden Informationen zum Test gesammelt und ein Testplan erstellt. |
|
Design des Tests |
Es werden Testfälle identifiziert und ein Design der Testprozeduren erstellt. |
|
Test implementieren |
Die Testumgebung und Testprozeduren werden entwickelt. |
|
Integrations-Test |
Überprüfung des Systems bezüglich der Zusammenarbeit der Komponenten untereinander. |
|
System-Test |
Überprüfung der fachlichen Funktionalität |
|
Performance-Test |
Überprüfung des Systems bezüglich der Laufzeit (Antwortverhalten) und der benötigten Systemressourcen. |
| Einführung |
Technische und organisatorische Vorbereitungen |
|
|
Schulungen |
Schulung und Einweisung der Anwender. |
|
Installation |
Installation der Software auf den Wirkrechnern. |