 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
Lifecycle eines Szenarios |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
| Lifecycle und Management - Szenarien als eigenständige Artefakte
Szenarien sind keine Selbstläufer! Erfahrungen aus der Praxis zeigen, dass die Erstellung, Dokumentation und Evaluation von Szenarien eine eigenständige Aufgabe mit nennenswertem Aufwand darstellt. Bei Szenarien handelt es sich um komplexe Artefakte, die einem Entwicklungsprozess unterliegen und deshalb gepflegt und fortgeschrieben werden müssen. Weiterhin zeigt sich die Notwendigkeit, in einigen Fällen mehrere Darstellungsformen für ein Szenario anzubieten. Evolution von Szenarien Es können mehrere Evolutionsformen unterschieden werden • Übergang von informaler zu formaler Definition Die ersten Szenarien für ein System werden vielfach in Freitextform formuliert. Nach Erreichung eines hinreichend breiten Verständnisses bei den Beteiligten werden diese Texte in vorgegebene Musterstrukturen überführt, um so erste Inkonsistenzen und Lücken erkennen und weiteres Wissen einbringen zu können. Häufig folgt ein dritter Schritt, in dem die strukturierten Texte in eine formalere Darstellung, z.B. MTDs (Message Trace Diagrams) überführt werden. Auch dieser Schritt dient der weiteren Vervollständigung und Behebung von Inkonsistenzen. • Übergang von Black-Box zu White-Box Szenarien Hinsichtlich ihres Inhalts befassen sich die Szenarien zu Beginn eines Projekts in der Regel mit der Interaktion des Systems mit seiner Außenwelt (Benutzer, ggf. bereits bestehenden Softwarekomponenten) und auch mit den Wechselwirkungen von Objekten der Außenwelt untereinander. Sind diese Aspekte hinreichend verstanden, kann oftmals die Betrachtung - ausgehend von dem Geschehen an der Schnittstelle - in natürlicher Weise ausgedehnt werden auf mögliche, korrespondierende Strukturen innerhalb des Systems und deren interne Interaktionen, so dass das System nicht länger als black-box erscheint. • Top-Down Verfeinerung Zu Beginn eines Projektes beschränken sich Szenarien häufig auf Vorgänge auf hohem Niveau, wie z.B. komplette Geschäftsprozesse, um eine Übersicht über die Gesamt- funktionalität des Systems zu geben. Im Rahmen der weiteren Detaillierung werden auch die Aufgaben und Teilaufgaben innerhalb der Geschäftsprozesse mit einbezogen. Sichten auf Szenarien Für größere Szenarien mit bereits weit fortgeschrittenem Detaillierungsgrad hat es sich als notwendig erwiesen, (Teil-) Sichten bereitzustellen. Sichten umfassen sowohl unterschiedliche Repräsentationsformen eines (Gesamt-) Szenarios als auch Aufteilungen von Gesamtszenarien. Im ersten Fall ist es beispielsweise erforderlich, neben der detaillierten, für Entwickler und Domänenexperten gedachten Fassung eines Szenarios auch eine etwas gröbere Sicht für Manager bereit zu stellen. Hierbei kann sich auch die Darstellungsform ändern, z.B. wird der schnelleren Erfassbarkeit wegen eine grafische Darstellung gewählt. Soll ein Gesamtszenario aufgeteilt werden, können verschiedene Gesichtspunkte eine Rolle spielen. So sind beispielsweise nicht immer alle im Gesamtszenario beschriebenen Prozesse für alle Beteiligten von Bedeutung. In diesen Fällen könnten also unterschiedliche Sichten entsprechend der Interessensprofile wichtiger Beteiligter gebildet werden. Ein anderer Gesichtspunkt ist die Aufteilung hinsichtlich der Realisierung. Hier wird man darauf bedacht sein, die Trennlinien so zu ziehen, dass die Kommunikation zwischen den unterschiedlichen Komponenten möglichst minimal und gut verstanden ist. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Lifecycle eines Szenarios | ||||
| ||||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
