 |
 |
 |
|
 |
|||
 |
|||
| SZ.6 Entwicklung wissensbasierter Systeme |
SC.6 Development of Knowledge-Based Systems
 Inhalt
|
|
|---|
SZ.6.1 Ablaufbeschreibung für die Aktivitäten im Submodell SE
Charakteristisch für wissensbasierte IT-Systemen sind Anwenderforderungen, die zum Großteil als Regelbasis formulierbar sind. Es wird davon ausgegangen, daß neben diesen Teilen auch weitere, konventionell beschriebene und zu entwickelnde Anteile vorhanden sind.
Das Szenario zeigt, wie wissensbasierte und konventionelle Anteile parallel entwickelt werden und wie die Erstellung und schrittweise Verfeinerung der Regelbasis in die Aktivitätenfolge gemäß V-Modell integriert wird. Zusätzlich werden Hinweise zur Interpretation der Produktmuster (insbesondere für die Anwenderforderungen) gegeben
Die Entwicklung wissensbasierter Systeme folgt der Strategie der inkrementellen Entwicklung, um die schrittweise Verbreiterung und Verfeinerung der Regelbasis im Dialog mit dem Anwender geeignet abbilden zu können.
Der Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme ist in Abbildung SZ.6 illustriert.
Vorbemerkungen:
- Grundlage der nachfolgenden Beschreibungen ist das Szenario zur inkrementellen Systementwicklung.
- Die Ergänzungen zur Entwicklung wissensbasierter Systeme sind kursiv dargestellt.
Abbildung SZ.6: Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme
Zeitpunkt T 0 - Start
Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.Zeitpunkt T 1 - Erste Ausbaustufe
Als Ergebnis von Aktivität SE1.2 - Anwendungssystem beschreiben liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt. Wissensbasierte Anteile sind hierbei auszuweisen, um den Geltungsbereich der Wissensbasis festlegen zu können.Für einige der in Aktivität SE1.5 - System fachlich strukturieren identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.
Die Darstellung der Funktionalität der wissensbasierten Anteile geschieht als Regelbasis, die bereichsüberschreitend erarbeitet wird. Die Regelbasis füllt das Kapitel "Anforderungen an die Funktionalität" als Teil der "Fachlichen Anforderungen".
Die Ergebnisse der Aktivitäten SE 1.2 und SE 1.5 bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 1 in einer ersten Version vorliegen
Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:
- Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. (1)
- Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.
- Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.
- Die wissensbasierten Anteile müssen ausgewiesen sein.
Die einzelnen Bereiche werden soweit detailliert und ausgearbeitet, wie es für die erste produktive Systemversion notwendig ist. In späteren Stufen können die einzelnen Bereiche verfeinert und um neue ergänzt werden
Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE1 - System-Anforderungsanalyse-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt. Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet.
Für den wissenbasierten Anteil ist mit der Regelbasis (Teil der fachlichen Anwenderforderungen) im Normalfall bereits ein relevanter Anteil der Implementierung vorgegeben. Jedoch ist auch eine Regelbasis im Rahmen des Grobentwurfs zu modularisieren und im Rahmen des Feinentwurf zu beschreiben. Dies ist unabhängig von der gewählten Darstellungssprache
Für den konventionellen Anteil erfolgt die Entwicklung parallel zum wissensbasierten Anteil. Beide Anteile werden im Rahmen der Integrationsschritte zusammengefügt.
Zeitpunkt T 2 bis T N-1 - Weitere Ausbaustufen
Zum Zeitpunkt T 2 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE1.2 - Anwendungssystem beschreiben eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen (wissensbasierten und konventionellen) Bereichen kommen.Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Insbesondere wird die Regelbasis der wissensbasierten Anteile fortgeschrieben und verfeinert. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt. Die damit in einer zweiten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.
Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.
Diese Arbeitsschritte werden für jedes Inkrement wiederholt.
Zeitpunkt T N - vollständige Systembeschreibung
Zum Zeitpunkt T N liegen Anwenderforderungen, Systemarchitektur und Technischen Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung At the time of T N, User Requirements, System Architecture, and Technical Requirements are complete and have all been submitted. After realization and making the System available to be used, the entire System is in use.
SZ.6.2 Zusammenspiel mit den übrigen Submodellen
Das Zusammenspiel mit den übrigen Submodellen entspricht ohne Änderungen dem Szenario zur Anwendung des V-Modells bei einer inkrementellen Systementwicklung.
SZ.6.3 Kriterien für die Auswahl des Szenarios
Die folgende Auflistung von Vor- und Nachteilen und die Nennung der wichtigsten Voraussetzungen unterstützt die Entscheidungsfindung zur Auswahl der dargestellten inkrementellen Vorgehensweise zur Entwicklung wissensbasierter Systeme.
Vorteile:
- Anwendernahe Modellierung von fachlichen Anforderungen, die geeignet als Regelbasis darstellbar sind,
- flexible Änderung von Regelbasen und nahtloser Übergang in die Realisierungsschritte,
- frühzeitige Auslieferung eines Basissystems und dadurch frühzeitiger Einsatz eines operablen Systemkerns beim Anwender,
- sPriorisierung der Lieferreihenfolge durch den Anwender (ev. auf der Basis von Erfahrungen mit den ersten ausgelieferten Systemteilen),
- einfacher Austausch von Systemteilen (nämlich den Inkrementen) im Pflege- und Änderungsfall,
- problemloser Wechsel des Auftragnehmers nach Abschluß der Realisierung eines Inkrements,
- rVerfeinerung der Anwenderforderungen im Laufe der Entwicklung (die Anwenderforderungen müssen zu Beginn nicht vollständig vorliegen),
- deutlich kürzere Zyklen bei Änderung von Anwenderforderungen gegenüber konventioneller Entwicklung.
- In der Praxis ergibt sich immer eine Mischung aus wissensbasierten und konventionellen Anteilen, die parallel entwickelt werden müssen. Die obengenannten Vorteile einer rein wissensbasierten Lösung sind daher gegebenenfalls zu relativieren,
- ungünstiges Laufzeitverhalten bei regelbasierten Lösungen im Vergleich zu konventionellen Lösungen,
- inflexible Reaktion auf unvorhergesehene Änderungen, wenn ausgelieferte Systemteile oder deren Schnittstellen betroffen sind,
- Notwendigkeit der frühzeitigen Festschreibung des Gesamthorizonts für die gesamte Entwicklungszeit.
- Anwenderforderungen, die als Regelbasis geeignet modelliert werden können,
- Separierbarkeit des Systems bei klaren Schnittstellen (modularer Aufbau der Systemarchitektur).
Hinweise: (1) Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.
|
|
|
This page online • GDPA Online • Last Updated 03.Mar.2004 by C. Freericks |