Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.10.1990 - 

Von der Anforderungsanalyse bis zum Prototyping

Expertensysteme zu projektieren ist ein schwieriges Handwerk

12.10.1990

Unternehmen, die bewußt keine Vorreiterrolle auf dem Gebiet der Expertensysteme übernehmen wollten, sehen sich jetzt mit der Aufgabe konfrontiert, solche Systeme, die sich in der einen oder anderen Form bei Konkurrenten bewährt haben, selbst zu entwickeln. Die Vorgehensweisen der einschlägigen Anbieter sind aber nach Einschätzung von Hartmut Krasemann* recht unterschiedlich und nicht immer angemessen.

Die Idee zu einem Expertensystem wird meist gleichzeitig in vielen Köpfen geboren. Sie wird hin und her gewendet und von

vielen Seiten abgeklopft: Lohnt sich die Investition, wieviel Lehrgeld müssen wir zahlen, wie hoch ist der zu erwartende Nutzen wirklich? Die zuverlässige Information, daß die Konkurrenz solch ein System in ähnlicher Form einsetzt, gibt oftmals den Ausschlag: Ein Expertensystem muß her. Aber: Expertensysteme sind eine "neue Art" Software. In der sowieso schon überlasteten DV-Abteilung, ist wenig oder gar kein Know-how über diese neue Technologie vorhanden. Woher also Rat und Tat nehmen?

Grundsätzlich bietet sich an:

l) Selbst realisieren (und Lehrgeld zahlen),

2) Hilfe von einer Universität holen (meist in Form einer Diplomarbeit),

3) Einen professionellen Berater einschalten.

Selbst realisieren ist eine gute Idee, wenn bereits zu Beginn einer der Anwender sich für längere Zeit (zirka 6 Monate - 1 Jahr) halb- oder vollzeitlich dem Expertensystem widmen kann, und ihm ein junger Informatiker mit Ausbildung in KI (Künstliche Intelligenz) zur Seite gestellt wird, der für das Expertensystem Zeit hat und der mit dem Anwendungsexperten ein Team bildet.

Die Vorteile dieser Konstruktion liegen auf der Hand: Die notwendige enge Zusammenarbeit von Anwendungs- und KI-Experten wird anders nur schwer erreicht, und die Systempflege kann in Entwicklerhand bleiben. Risiken liegen in der Qualifikation des Informatikers: Bringt er die richtigen Vorgehensweisen von der Universität mit? Kann er auch rechtzeitig die Nicht-Realisierbarkeit von Teilen des Systems erkennen oder verknüpft er die Realisierbarkeit mit seinem Job? Ist er auch dann noch im Unternehmen richtig eingesetzt, wenn dieses Projekt, so oder so, beendet ist?

Hilfe von der Universität zu holen, etwa in Form einer Diplomarbeit oder Dissertation, ist dann eine gute Idee, wenn

noch nicht klar ist, ob und wieviel wirklich investiert werden kann, weil für die Aufarbeitung des Wissensgebietes (Art des Wissens, Algorithmen etc.) noch Forschungsarbeit zu leisten ist und deshalb die Idee eines Expertensystems ausprobiert werden soll. Der Vorteil ist offensichtlich das sehr geringe Kostenrisiko, verbunden mit der Chance, die Machbarkeit eines Expertensystems zu klären. Die Risiken liegen in der nur losen Anbindung der akademischen Arbeit an die Interessen der Firma. Der Diplomand oder Doktorand will primär eine wissenschaftliche Leistung, die Firma will ein vollständiges und einsatzfähiges System.

Einen professionellen Berater sollte man dann einschalten, wenn das Expertensystem in vorgegebenem Zeit- und Kostenrahmen erstellt wird und in Betrieb genommen werden soll. Bei einem Berater wird die Beherrschung von Anwendung, Technologie und Vorgehensweisen vorausgesetzt. Allerdings ist es als Anwender nicht einfach, unter den Beratern die Spreu vom Weizen zu trennen. Drei Schritte sind angezeigt:

1 ) Überprüfen der Erfahrung des Beraters. Dies geschieht entweder durch persönliche Kenntnis oder durch Referenzen in vergleichbaren Anwendungen und in der Technologie.

2) Überprüfen seines Könnens. Neben dem Eindruck aus Präsentationen beziehungsweise dem Angebot sind hier letztendlich Referenzen von Expertensystemprojekten entscheidend. Dabei kommt es darauf an, daß die Referenz Expertensysteme aktive oder "laufende" Systeme sind und nicht mehr im Prototypstadium stecken.

3) Überprüfen der Vorgehensweise des Beraters. Nur eine angemessene Vorgehensweise kann Anwenderforderungen wie kontrollierte Erreichung der technischen und organisatorischen Projektziele, Know-how-Gewinn und Investitionssicherung erfüllen.

Insbesondere die Vorgehensweisen sind auf dem Markt alles andere als einheitlich. Allerdings beginnt sich auch hier ein gewisser Standard herauszubilden. Nach unseren Marktbeobachtungen ist die im folgenden vorgestellte Vorgehensweise mit kleinen Variationen bereits bei etwa einem Drittel der Berater etabliert.

Expertensysteme erschließen in den meisten Fällen völlig neue Anwendungen, die bisher nicht automatisiert gewesen sind. Für ein Expertensystem gibt es deshalb selten "Vorbilder", aus deren Fehlern man lernen könnte. Gleichzeitig verkörpern Expertensysteme, besonders wenn sie an ihrem Erstellungsaufwand gemessen werden, Anwendungen besonders hoher Komplexität, die vom Entwickler verstanden und in Lösungskonzepte umgesetzt werden müssen. Um eine neue komplexe Anwendung zu verstehen und in den Griff zu bekommen, sind modellbasierte Analyse- und Designmethoden notwendig. So wie in den siebziger und achtziger Jahren modellbasierte Methoden die klassische Systemanalyse geprägt haben (Strukturierte Analyse und Datenmodellierung), basiert heute die wahrscheinlich am besten ausgereifte Methodologie für die Erstellung wissensbasierter Systeme (Expertensysteme), die KADS-Methodologie, ebenso auf modellbasierter Analyse und Spezifikation wie die klassische Systemanalyse. Die richtige Vorgehensweise kombiniert deshalb klassisches Engineering mit zusätzlichen Elementen, die sich aus den Besonderheiten von Expertensystemen ergeben. Auf diese Besonderheiten werden wir im folgenden immer wieder zurückkommen. Die erste Projektphase einer Expertensystem-Projektierung ist deshalb eine Modellierung des gewünschten Systems (Systemmodell) und seiner Umgebung (Umgebungs- oder "Welt"- Modell). Hier ist es besonders wichtig, die Schnittstellen zwischen dem System und seiner Umgebung zu modellieren. Das in dieser Phase entstehende Dokument beschreibt das Weltmodell und das Systemmodell mit den Systemaufgaben, zerlegt in Teilaufgaben. Die Modelle werden je nach Komplexität klassisch beschrieben, z.B. mit Structured-, Analysis und Entity-Relationship-Diagrammen oder sogar als ausführbares Modell in einer geeigneten Wissensrepräsentationssprache formuliert.

Diese Projektphase ist eher konventionell, sie sollte in jedem Großprojekt ähnlich durchgeführt werden. Neu sind unter Umständen die Werkzeuge zur wissensbasierten Modellierung, die sich aber ebensogut in konventionellen Projekten vorteilhaft einsetzen lassen.

Sind die Anforderungen und Aufgaben formuliert, stellt sich die entscheidende Frage: Gibt es in der Informatik und der KI-Konzepte, Methoden und Verfahren, mit denen sich die Aufgaben mit all ihren Anforderungen lösen lassen? Hier kann eine mögliche Antwort durchaus lauten: Es gibt für die vorgegebene Aufgabe kein Problemlösungskonzept, das den Anforderungen genügt. Oder: Nur ein Teil der Aufgaben ist in einem Expertensystem implementierbar. Das Dokument, das in dieser Phase entsteht, enthält alle wesentlichen Problemlösungskonzepte. Wie in konventionellen Projekten dient es als Vorgabe für das später folgende Design. In Expertensystem-Projekte ist das Dokument zusätzlich ein ganz wichtiger Meilenstein, der Auskunft über die Machbarkeit des Systems gibt.

Die Qual der Wahl: Werkzeugauswahl

Die Werkzeugauswahl ist in konventionellen Projekten kein besonders großes Problem Die Hardware- und Softwareumgebung liegt oft fest, eine anwendungstypische universelle Programmiersprache ist Standard, konventionelle Projekte weisen eine solche Phase deshalb kaum auf. Warum also extra eine Projektphase "Werkzeugauswahl" in Expertensystem-Projekten? Würde man sich von vornherein auf eine universelle Programmiersprache wie Lisp oder Prolog beschränken, so würde es tatsächlich genügen, die notwendige Information zur Implementierung der Lösungskonzepte in Lisp oder Prolog zu liefern.

In einigen Anwendungsbereichen besonders in der technischen Diagnose, existieren allerdings fertige Programmschalen (Shells), die sich als Baustein in das System einbauen lassen. Diese Schalen müssen die Implementierung der gefundenen Lösungskonzepte erlauben und die notwendigen Schnittstellen zu der vorhandenen oder geplanten Systemumgebung bieten (Datenbanken, andere Programme, Anwenderschnittstelle, Systempflegeschnittstelle). Hier wird das Auswahlproblem sichtbar, gegebenenfalls muß wieder abgewogen werden zwischen dem Erfüllungsgrad der Anforderungen und der erreichbaren Expertensystem-Leistung. Das Phasenergebnis der Werkzeugauswahl ist die Angabe einer oder mehrerer Shells mit Modifikationen am Anforderungskatalog und am Lösungskonzept. Ein mögliches und in vielen Fällen auch wahrscheinliches Ergebnis dieser Phase ist auch die Aussage, daß eine universelle KI-Programmiersprache verwendet werden muß, in der allein die Lösungskonzepte verwirklicht werden können. Wichtig für die Werkzeugauswahl sind Verläßlichkeit und Stabilität der vorherigen Phasen, Anforderungsanalyse und Lösungskonzepte.

Im Zweifel eine universelle KI-Sprache

Aus der Projektpraxis sind Fälle bekannt, in denen sich weiterentwickelnde Anforderungen den ursprünglichen Einsatz einer Shell obsolet gemacht haben, nachdem das System bereits im Einsatz war. Deshalb ist im Zweifel immer der Einsatz einer universellen KI-Sprache vorzuziehen, obwohl dies auf den ersten Blick teurer sein kann.

Wenn die Grobstrukturen der Wissensbasis und die wichtigsten Lösungskonzepte festliegen, können die Feinanalyse und die Erhebung des Wissens geplant werden. Dies umfaßt unter anderem die Organisation des Projektteams (ideal ist ein Anwendungsexperte und ein Wissensingenieur) und die Identifizierung der weiteren Wissensquellen. Insbesondere die Wissensquellen sind ein Punkt, der besondere Beachtung verdient. Interviews mit dem Experten als alleinige Wissensquelle verbieten sich schon wegen der Kosten für die wertvolle Zeit des Experten. Der klassische Systemdesigner bringt immer auch ein tiefes Verständnis vergleichbarer Anwendungen mit. Idealerweise sollte das bei dem Wissensingenieur auch so sein.

Dort, wo diese Voraussetzung (heute noch) nicht erfüllbar ist muß sorgfältig geplant werden welche schriftlichen Wissensquellen ausgewertet werden sollen. Oberste Leitlinie dabei muß sein, möglichst präzise Unterlagen zu verwenden. Dies kollidiert oft mit Geheimhaltungsinteressen. Allerdings ist hier jeder Kompromiß fehl am Platz.

Ein Beispiel aus der Praxis, in dem es um die Auswahl technischer Geräte ging, belegt dies deutlich: Aus Geheimschutzgründen wurden die Konstruktionsunterlagen dem Projektteam nicht zugänglich gemacht. Man meinte, mit dem technischer Beschreibungen der Geräte für den Außendienst ausreichend detaillierte Unterlagen für die Konstruktion der Wissensbasis zur Verfügung zu stellen, zumal ja die Außendienstmitarbeiter, die von dem Expertensystem später unterstützt werden sollten, auch mit diesen Beschreibungen auskommen.

Leider stellte sich erst zu spät, nämlich nach Inbetriebnahme des Systems heraus, daß die Außendienstunterlagen in bestimmter Weise "geglättet" waren. Die Außendienstmitarbeiter hatten gelernt, mit diesen "Glättungen" umzugehen, allerdings war das Expertensystem dazu nicht fähig, es mußte deshalb im Feld versagen.

Ein letzter, aber wichtiger Punkt ist die Planung des Expertensystem-Einsatzes und der Expertensystem-Wartung. Die Aufwände für die Systemwartung sind oft viel höher als die Aufwände für die Systemerstellung. Sie beeinflussen das Nutzen-Kosten-Verhältnis ganz erheblich. Dies gilt für konventionelle Systeme, weil Modifikationen der Anforderungen während der Systemnutzung teure Änderungen an der Software nötig machen. Obwohl jede einzelne Änderung bei wissensbasierter (Expertensystem)-Software einfacher und preiswerter ist als bei konventionellen Programmen, gilt dies in der Summe auch für Expertensysteme, deren Wissensbasis vorhersehbaren und geplanten Änderungen unterliegt. Erst mit diesen Planungen ist Life-cycle-Kostenabschätzung möglich. Erst jetzt kann auch die Entscheidung für oder gegen die Entwicklung eines Expertensystems gefällt werden. In diese Entscheidung geht noch etwas anderes ein: eine Risikobewertung.

Die Lösungskonzepte sind oft weit weniger erprobt als jene in konventionellen Projekten. Ein Zurückziehen auf gut erprobte Lösungskonzepte würde ein innovatives vielversprechendes Expertensystem unter Umständen ausschließen. Deshalb macht es durchaus Sinn, ein gewisses Realisierungsrisiko einzugehen. Allerdings gehört dazu die quantitative Abschätzung dieses Risikos.

Kriterien für den Einsatz von Prototyping

In der Tat ist es durchaus möglich und sinnvoll, ein Expertensystem in "Paperwork" zu projektieren. Die Ergänzung der Projektierungsphase durch den Bau eines Prototypen ist in vielen Fällen möglich (aber verzichtbar), in einigen Fällen angezeigt, in einigen Fällen absolut unverzichtbar. Wann und wozu sollte nun Prototyping eingesetzt werden?

Zunächst einmal sei festgestellt, wozu Prototyping nicht eingesetzt werden kann: Mit Prototyping allein können weder die Anforderungen ermittelt noch die Lösungskonzepte gefunden werden. Die Expertensystem-Welt wimmelt nur so von Gegenbeispielen. Viele Expertensystem-"Prototypen" sind so entstanden, daß mit einer Anwendungsidee eine Shell beschafft wurde und dann explorativ (das heißt Anforderungen und Lösungskonzepte erforschend) eine Wissensbasis versuchsweise implementiert und erweitert wurde. Uns ist kein solcher Fall bekannt, der zu einem erfolgreichen System geführt hätte. Allerdings gibt es eine - eingangs beschriebene - Konstellation, in der exploratives Prototyping angebracht ist: Wenn für die Aufarbeitung eines Wissensgebietes noch Forschungsarbeit zu leisten ist.

Trotzdem ist Prototyping in einer kontrollierten Form ("kontrolliertes Prototyping") sinnvoll und in vielen Fällen auch notwendig:

1. Wenn die Lösungskonzepte vorliegen, können sie mit Hilfe eines Prototyps validiert werden. Dafür werden die Wissensstrukturen und Lösungsalgorithmen, die zu den Bereichen des Systems mit besonders hohem technischen Risiko gehören, im Prototyp implementiert, um das Risiko zu senken. Anders ausgedrückt: Ein Teil der Wissenserhebung und Implementierung wird vorweggenommen, um zu beweisen, daß die Lösungskonzepte Bestand haben. Hier kann sich zeigen, daß bestimmte Lösungskonzepte falsch sind. Die prototypische Implementierung gibt oft auch den Anstoß zu vorher nicht bedachten neuen und besseren Lösungskonzepten. Damit wird

der Prototyp zum Ausgangspunkt für ein Redesign.

2. Die Benutzerschnittstelle kann prototypisch, das heißt in ihren wesentlichen Zügen, implementiert werden. Dann kann die Benutzerschnittstelle schon in der Projektierungsphase von den späteren Anwendern validiert werden. Da die Benutzerschnittstellen von Expertensystemen in den Unternehmen meist keine Vorbilder haben, ist ihre Funktionalität ohne einen Prototyp für die späteren Anwender kaum vorstellbar.

Hier gilt, daß die Änderung von Anforderungen während der Projektierung mit viel geringeren Kosten verbunden ist, als wenn dies in späteren Phasen geschähe. Hinzu kommt, daß eine überzeugende Demonstration des späteren Systemnutzens ohne einen Prototyp mit Benutzeroberfläche nur schwer möglich ist.

Was ist zu beachten für das kontrollierte Prototyping? Auch ein Prototyp kann nur Antworten geben auf Fragen, die vorher gestellt wurden. Das heißt, vor dem Prototyping ist festzulegen, welche "kritischen Fragen" durch den Prototyp beantwortet werden sollen. Kritische Fragen können die nach der Gültigkeit bestimmter Lösungskonzepte sein oder nach der Handhabung bestimmter Teile der Benutzeroberfläche.

Welche Werkzeuge werden für das Prototyping benutzt? Im Idealfall kommt für das Prototyping von Benutzeroberflächen ein mächtiger GUI-(Graphical User Interface) Baukasten in Frage, für das Prototyping der Lösungskonzepte, also der Wissensstrukturen und Algorithmen, eine wissensbasierte Spezifikationssprache, die durch das teilweise Auffüllen mit Wissen als Prototyp animiert wird.

Dieser Idealfall ist nicht unrealistisch. Der Prototyp für ein

Computerdiagnose-System wurde beispielsweise auf folgende Art erstellt: Die Wissensbasis über Computer-Hardware-Komponenten mit ihren Eigenschaften wurde mit der wissensbasierten Spezifikationssprache SML spezifiziert und anschließend mit Wissen gefüllt. Dazu kam die Implementierung eines Lösungskonzepts, nämlich der Diagnose-Strategie, in Prolog. Die Benutzerschnittstelle schließlich wurde mit dem objektorientierten GUI-Baukasten PCE erstellt. Dies alles, erstellt in wenigen Personenwochen, ist als Prototyp bereits ein lauffähiges Programm, allerdings ohne jede Optimierung.

In der Praxis trifft man oft Randbedingungen, die den eben beschriebenen Idealfall ausschließen, seien es Hardware oder Softwareanforderungen wie Betriebssysteme, unter denen Werkzeuge der eben beschriebenen Art nicht verfügbar sind. Dann läßt sich Prototyping auch mit kleinen Abstrichen an der Produktivität einfach mit universellen KI-Programmiersprachen und Standard GUI-Paketen durchführen, zum Beispiel auf einem PC mit der einfachen Kombination von Prolog und Gem.

*Hartmut Krasemann leitet den Fachbereich Wissensbasierte Systeme der SCS Informationstechnik GmbH in Hamburg