Bei der Entwicklung von Expertensystemen sind eine schlechte Projektplanung und der falsche Einsatz von Technologien häufig Gründe für vorzeitige Projektabbrüche. Dies würde nach Einschätzung von Hartmut Krasemann* nicht passieren, wenn sich die Anwender die Tugenden des Software-Engineerings ins Gedächtnis riefen. Das Vorgehen läßt sich großenteils auch auf die Expertensystem-Entwicklung anwenden, wenngleich aufgrund der Komplexität der Aufgabe einige Ergänzungen nötig werden.

Angaben über die Zahl der Expertensysteme in Deutschland schwanken zwischen weniger als 100 und mehreren tausend. Ursache für diese unterschiedlichen Angaben sind Schwierigkeiten, Expertensysteme zu definieren und das Stadium festzulegen, indem sich ein "fertiges" System befinden sollte.

Weitere Schätzungen gehen davon aus, daß mindestens neun von zehn Expertensystemen nie über das Prototypstadium hinauskommen. Hierfür gibt es im wesentlichen zwei Gründe: Erstens wird die Technologie überschätzt. Die unerfüllten Erwartungen und die steigenden Kosten frustrieren den Auftraggeber, und es kommt nicht selten zum Projektabbruch. Zweitens werden in der Projektdurchführung viele Fehler gemacht - von der mangelnden Projektplanung bis hin zum falschen Einsatz der Technologie.

SW-Engineering: Die Spreu vom Weizen trennen

Im klassischen Software-Engineering ist das "Wasserfallmodell" zum Inbegriff für die ingenieursmäßige Konstruktion eines Programms geworden. Das Modell macht Sinn als Beschreibung aufeinanderfolgender Phasen. Jede einzelne von diesen kann aufgrund vorhandener Erfahrung mit ausreichender Sicherheit geplant und durchgeführt werden.

In jüngster Zeit sind einige andere Entwicklungsphilosophien wieder ins Gespräch gekommen: die evolutionäre und die inkrementelle Entwicklung. Dazu kommt das Rapid Prototyping, das durch frühe Implementierung die Validierung von Anforderungen unterstützt. Alle diese Philosophien adressieren hauptsächlich das Problem sich ändernder Anforderungen, sie zielen also auf größere Systemerweiterbarkeit. Daher ist es nicht verwunderlich, wenn ihnen im Rahmen von Expertensystem-Entwicklungen besondere Aufmerksamkeit zu kommt.

War die Einführung des Wasserfallmodells ein Sieg des Projektmanagers über den Hacker, weil Zeit und Kosten gespart werden konnten, so könnte die evolutionäre oder inkrementelle Entwicklung den Sieg des Anwenders über den Projektmanager bedeuten, denn der Anwender kann sich zukünftige Änderungen der Anforderungen offenhalten. Doch ist mit "Rapid Prototyping" bereits die evolutionäre Weiterentwicklung eines Systems gesichert?

Wollen wir das klassische Software-Engineering optimal einsetzen, so stellt sich die Frage, was von diesem Verfahren brauchbar und was nicht mehr gültig ist.

Ebenso muß geklärt werden, welche Rolle das Prototyping nun spielt und wodurch die zukünftige Systemerweiterbarkeit gesichert wird.

Nach einem kurzen Blick auf die Technologie möchte ich deshalb den Engineering-Prozeß für Expertensysteme anhand der folgenden Phasen diskutieren:

1. Vorphase: Was muß ich vor Beginn über Technologie und Anwendung wissen?

2. Startphase: Ziele und Teamzusammenstellung werden festgelegt.

3. Konzeptphase: Sie bestimmt die Anforderungen und definiert das spätere System im Sinne einer Grobspezifikation.

4. Realisierungsphase: Dazu gehören Feinspezifikation, das detaillierte Design, die Wissenserhebung sowie Implementierung und Test.

In der Konzeptphase werden die Werkzeuge festgelegt, Kosten ermittelt und die detaillierte Durchführung der Realisierung geplant. In dieser Phase wird am deutlichsten, welche Tugenden des Software-Engineering erhalten bleiben und welche Aspekte, diktiert durch die neue Technologie, hinzukommen. Wir geben deshalb als Beispiel für diese Phase ein Diagramm der Aktivitäten an.

Expertensysteme enthalten sehr viel mehr Wissen als vertraute konventionelle Softwaresysteme. Bei unveränderter Technologie würde dies bedeuten, daß Expertensysteme deutlich komplexen sind als konventionelle Programme. Der erste Schritt zur Auflösung dieser Komplexität ist die Trennung des Wissens, des "was", vom Programm, dem "wie". Weitere Schritte sind die angemessene Repräsentation dieses Wissens und die Bereitstellung einer adäquaten Programm-Funktionalität.

Die relevanten Techniken der Wissensrepräsentation haben Namen erhalten wie "objektorientierte Wissensrepräsentation", "deklaratives Programmieren" oder auch "regelbasiertes Programmieren". Schon diese Begriffe weisen darauf hin, daß Regeln nicht alles sind die - Struktur des Wissens spielt in seiner Repräsentation eine ebenso große Rolle: Die KADS-Methodologie für wissensbasierte Systeme, die in Europa von IBM und der Cap-Gemini-Gruppe gemeinsam favorisiert wird, sieht vor, das Wissen gemäß vier aufeinander aufbauenden Schichten zu analysieren (vergleiche Abbildung 1).

Die Organisation des Wissens in diesen Schichten ist notwendige Voraussetzung für die Modularisierung, die die Wissensbasis eines Expertensystems erst änderbar und erweiterbar macht. Dies heißt natürlich nicht, daß ein Expertensystem Strategiewissen, also Wissen über die Anwendung einzelner Problemlösungs-Komponenten in der Aufgabenschicht, enthalten muß. Das hängt von den Anforderungen an das System ab. Es heißt aber, daß eine Vermischung der verschiedenen Wissensschichten, zum Beispiel in einer einzigen flachen Wissensbasis aus Regeln, die spätere Änder- und Erweiterbarkeit drastisch herabsetzt.

Der Unterteilung der Wissensbasis in Schichten steht eine entsprechende Modularisierung des "Programms", der sogenannten Inferenzmaschine, gegenüber. Die angemessene Funktionalität der Inferenzmaschine erfordert oft eine spezielle, auf die Struktur der Wissensbasis zugeschnittene Funktionalität. Der Informatiker oder Wissensingenieur bedient sich dazu gerne der Technik des sogenannten Meta-Programmierens.

Zur Problemlösung wird heute vorzugsweise die Programmiersprache Prolog eingesetzt. Dies heißt nicht, daß die Inferenzmaschine in jedem Fall individuell durch Meta-Programmieren erstellt werden muß. Insbesondere für Diagnoseanwendungen sind oft fertige Expertensystem-Schalen verfügbar, deren Inferenzmaschine ausreicht. Allerdings kann nicht jedes Expertensystem mit einer solchen Schale oder Shell erstellt werden, und nicht jedes System hat eine hohe Lebenserwartung.

Wird trotz "Gegenindikation" mit einer Shell gearbeitet, so führt die zwangsläufige Vermischung der verschiedenen Wissensschichten zu der oben bereits genannten drastischen Herabsetzung der Änder- und Erweiterbarkeit.

Die Trennung von Programm und Wissen sowie die Analyse und Modellierung des Wissens in Schichten und innerhalb der Schichten in Objekten, macht die Anwendung altvertrauter Techniken des klassischen Engineering zur Beherrschung komplexer Systeme nötig, die Modularisierung.

Die eben skizzierte Technologie gibt uns einige Techniken an die Hand, Software für so komplexe Anwendungen wie Expertensysteme modular und damit änder- und erweiterbar zu schreiben. Das sind die Chancen dieser Technologie. Aber das allein reicht nicht aus, um erfolgreich ein Expertensystem zu erstellen. Neben bisher ungelösten technologischen Fragen - zum Beispiel nach Standards für die Wissensrepräsentation, mit deren Hilfe Wissen erst in größerem Umfang wiederverwendbar gemacht werden könnte - gibt es eine Reihe pragmatischer Fragen, deren Beantwortung Voraussetzung für den Projekterfolg ist. Die Diskussion muß bereits in der Vorphase beginnen.

In erfolgreichen Projekten haben der Projektleiter und seine Organisation das Projekt, das heißt die Aufgabe und die Technologie, verstanden. Die Durchführung ist in kleine übersichtliche und kontrollierbare Abschnitte mit verschiedenen Zielen zerlegt worden, so daß sich der Projektfortschritt kontrollieren läßt. Der Projektleiter hat idealerweise ein ähnliches Projekt schon einmal durchgeführt und der Umfang von technischen Risiken war begrenzt auf ein für das Projektteam sinnvolles Maß.

Bei der Entwicklung eines Expertensystems ist diese Situation heute noch die Ausnahme. Fast immer wird die Anwendung das erste Mal automatisiert, so daß weder der Projektleiter, noch seine Organisation Erfahrung in einem anwendungsähnlichen Projekt haben. Oft ist gleichzeitig auch der Einsatz der Technologie neu.

Damit ergeben sich gleich zwei kritische Fragen: Kann der Anwender sicher sein, daß die geplante Anwendung mit Expertensystem-Technologie realisiert werden kann (und muß)? Ist die Technologie ausreichend verstanden worden, um diese Einschätzung durchfuhren zu können?

Schon allein, um die einzelnen Projektphasen mit ihren Zielen bestimmen und das Projektteam richtig zusammenstellen zu können, muß genügend Erfahrung mit der Anwendung der Technologie vorhanden sein.

Drei Wege, um ein Projekt durchzuführen

Für eine Beurteilung, ob eine Anwendung mit Expertensystem-Technologie automatisiert werden sollte, fehlen in der Regel die erfolgreichen Beispiele aus der eigenen Organisation. Richtungsweisende Tips können hier aus den zahlreichen Arbeitskreisen kommen, die es in fast jedem Industrieverband gibt.

Ein Hinweis auf die Notwendigkeit von Expertensystemen ergibt sich oft aus den bisherigen Versuchen, eine Anwendung mit konventionellen Mitteln, etwa mit Datenbanken, zu automatisieren. Genauso wichtig ist zu wissen, ob die Technologie ausreichend mächtig ist, um das gewünschte System zu implementieren. Hierbei wird die Technik manchmal arg überschätzt. Zu beachten ist, daß jede Anwendung, die automatisiert werden soll, auch verstanden und formalisierbar sein muß. Unsicherheiten bezüglich der Formalisierbarkeit machen eher ein Forschungs- als ein Entwicklungsprojekt nötig.

Oft gibt die Tatsache, daß die Konkurrenz ein Expertensystem einsetzt, den Ausschlag für die Entscheidung, ein solches System einzuführen. Dabei ist meistens wenig oder gar kein entsprechendes Know-how vorhanden. Um das Projekt dennoch durchzuführen bieten sich drei Verfahren an:

- Selbst realisieren und dabei lernen, aber auch Lehrgeld zahlen,

- Hilfe von einer Universität holen, meist in Form einer Diplomarbeit,

- einen professionellen Berater mit der Realisierung beauftragen.

Das Projekt selbst zu realisieren ist eine gute Idee, wenn das wesentliche Ziel der Erfahrungsgewinn ist und erst in Folgeprojekten einsatzfähige Expertensysteme entstehen müssen. Am besten stellt man einen der Anwender sechs Monate oder ein ganzes Jahr halb- oder vollzeitlich frei, damit er sich dem Expertensystem widmen kann. Ihm sollte ein Informatiker mit KI-Ausbildung zur Seite stehen, der mit dem Anwendungsexperten ein Team bildet.

Die Vorteile dieses Konzeptes liegen auf der Hand: Eine enge Zusammenarbeit von Anwendungs- und KI-Experten wird erreicht, und die Systempflege bleibt in der Hand des Entwicklers. Allerdings liegen in der Qualifikation des Informatikers Risiken. So steht in Frage, ob er die adäquate Vorbildung von der Universität mitbringt. Ein guter Informatiker sollte die Nichtrealisierbarkeit von Teilen des Systems erkennen. Die Beendigung des Projektes um jeden Preis, wobei kaum noch auf das Ergebnis geschaut wird, kann nicht das Ziel eines Unternehmens sein. Möglicherweise kann die Einschaltung eines erfahrenen Beraters hier den Schaden begrenzen.

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 und muß. Diese Situation ist dann gegeben, wenn für die Aufarbeitung des Wissensgebietes (Art und Formalisierung des Wissens, Algorithmen zur Verwendung des Wissens etc.) noch Forschungsarbeit zu leisten ist und in diesem Sinne ein Expertensystem 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 möglicherweise eher lockeren Anbindung der akademischen Arbeit an die Interessen der Firma. Der Diplomand oder Doktorand will primär eine wissenschaftliche Leistung vollbringen, die Firma benötigt ein vollständiges und einsatzfähiges System.

Einem professionellen Berater sollte die Realisierung dann übertragen werden, wenn das Expertensystem in vorgegebenem Zeit- und Kostenrahmen erstellt und in Betrieb genommen werden muß. Bei einem Berater wird die Beherrschung von Anwendung, Technologie und Vorgehensweisen vorausgesetzt. Allerdings steht der Anwender vor der schwierigen Aufgabe, unter den Beratern die Spreu vom Weizen zu trennen. Zu diesem Zweck sollten Erfahrung, Können und Vorgehensweise anhand entsprechender Referenzen überprüft werden.

Lauffähige Systeme werden ungern gezeigt

Im Gespräch mit dem Berater dürfte schnell klar werden, daß heute noch sehr wenig vorzeigbare Referenz-Expertensysteme im Einsatz sind. Hinzu kommt, daß lauffähige Expertensysteme nur ungern vorgezeigt werden, weil darin viel sensitives Wissen verborgen ist. Die Zahl der wirklich vorführbaren Systeme ist ohnehin gering, wenn man die eingangs genannten Systeme auf die vielen verschiedenartigen Anwendungsgebiete verteilt. Deshalb kommt ein relativ großes Gewicht heute noch der expliziten Beurteilung der Vorgehensweise des Beraters zu.

Leider sind die Vorgehensweisen der Anbieter 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.

Diese Vorgehensweise besteht in der Ermittlung und Vereinbarung der Anforderungen an das System sowie der nachfolgenden Definition und Vereinbarung der Systemleistungen. Einerseits ist es in Expertensystem-Projekten schwierig, ohne Vorerfahrung solche Vereinbarungen zu treffen, andererseits wird es nach aller Erfahrung ohne einen solchen Vertrag keine für den Anwender zufriedenstellende Implementierung des Systems geben. Deshalb muß das Ziel erst einmal sein, zu dieser Vereinbarung zu kommen.

Dies sollte in Form eines ersten Projektes geschehen, das mit kalkulierbarem Kostenrisiko durchgeführt werden kann. Dieses Projekt wird je nach Sprachgebrauch, Definition, Konzept oder Projektierung des Expertensystems benannt.

Ergebnis ist ein Dokument, das mindestens die Anforderungen an das Expertensystem beschreibt. Hinzu sollte ein Realisierungsplan kommen, der Sicherheit bezüglich Aufwand und Kosten gibt.

Folgende Schritte sind bei der Expertensystem-Projektierung einzuhalten (Vergleiche Abbildung 2):

1. Die Modellierung für die Anforderungsanalyse,

2. die technische Analyse zur Ermittlung der Problemlösungskonzepte,

3. die Werkzeugauswahl,

4. die Realisierungsplanung,

5. der ergänzende Einsatz eines Prototyping.

Der erste Schritt einer Expertensystem-Projektierung ist die Modellierung des gewünschten Systems (Systemmodell) und seiner Umgebung (Umgebungs- oder "Welt"-Modell). Dabei sollten vor allem die Schnittstellen zwischen dem System und seiner Umgebung modelliert werden. 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, zum Beispiel mit Structured-, Analysis- und Entity-Relationship-Diagrammen, oder sie werden sogar als ausführbares Modell in einer geeigneten Wissensrepräsentations-Sprache formuliert.

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

Im zweiten Schritt, nachdem die Anforderungen und Aufgaben formuliert sind, stellt sich die 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? Möglicherweise existiert für die vorgegebene Aufgabe kein Problemlösungs-Konzept, das den Anforderungen genügt. Ein weiteres Ergebnis könnte sein, daß nur ein Teil der Aufgaben in einem Expertensystem implementierbar ist.

Das Dokument, das in dieser Phase entsteht, enthält alle wesentlichen Problemlösungs-Konzepte. Wie in konventionellen Projekten dient es als Vorgabe für das später folgende Design. In Expertensystem-Projekten ist es zusätzlich ein ganz wichtiger Meilenstein, der Auskunft über die Machbarkeit des Systems gibt.

Der dritte Schritt heißt Werkzeugauswahl. Diese bereitet in konventionellen Projekten wenig Probleme. Die Hardware- und Software-Umgebung liegt oft fest, eine Applikations-typische universelle Programmiersprache ist Standard. Konventionelle Projekte weisen eine solche Phase deshalb kaum auf. Wozu 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 und dadurch die Kosten erheblich senken.

Werkzeuge oder Programmiersprache?

Diese Schalen müssen die Implementierung der gefundenen Lösungskonzepte erlauben und die notwendigen Schnittstellen zu der vorhandenen oder geplanten Systemumgebung bieten - zu Datenbanken, anderen Programmen, Anwenderschnittstellen und Systempflege-Schnittstellen. Hier wird das Auswahlproblem sichtbar. Gegebenenfalls muß wieder abgewägt werden zwischen dem Erfüllungsgrad der Anforderungen und der erreichbaren Expertensystem-Leistung.

Das Phasenergebnis der Werkzeugauswahl sollte die Angabe einer oder mehrerer Shells mit Modifikationen am Anforderungskatalog und am Lösungskonzept sein.

Ein mögliches und in vielen Fällen auch eingetretenes Ergebnis dieser Phase ist die Aussage, daß eine universelle Kl-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.

Es gibt Fälle, 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 die Anwendung einer universellen KI-Sprache vorzuziehen, obwohl dies auf den ersten Blick teurer sein kann.

Es folgt die Projektplanung. 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 - sowie die Identifizierung der weiteren Wissensquellen.

Gerade dieser Punkt verdient eine besondere Beachtung: Interviews mit dem Experten als alleinige Wissensquelle verbieten sich, weil die Zeit des Experten zu kostbar ist.

Ein Wissensingenieur sollte, ähnlich wie der klassische Systemdesigner, vergleichbare Anwendungen erkennen und verstehen. Dort, wo diese Voraussetzung (heute noch) nicht gegeben ist, muß sorgfältig geplant werden, welche schriftlichen Wissensquellen ausgewertet werden sollen.

Oberste Leitlinie ist dabei, möglichst präzise Unterlagen zu verwenden - auch, wenn dies mit Geheimhaltungsinteressen kollidiert,

Hier ist jeder Kompromiß fehl am Platz. Ein Beispiel aus der Praxis, in dem es um die Auswahl technischer Geräte geht, belegt dies deutlich: Aus Geheimschutzgründen wurden in einem Unternehmen die Konstruktionsunterlagen dem Projektteam vorenthalten. Der Auftraggeber glaubte, mit den technischen Beschreibungen der Geräte, ausreichend detaillierte Unterlagen für die Konstruktion der Wissensbasis zur Verfügung zu stellen.

Schließlich, so die Argumentation, müssen die Außendienstmitarbeiter, die das Expertensystem später nutzen sollen, auch mit diesen Beschreibungen auskommen. Leider stellte sich erst zu spät, nach Inbetriebnahme des Systems heraus, daß die Außendienst-Unterlagen in bestimmter Weise "geglättet" waren. Die Außendienst-Mitarbeiter hatten gelernt, mit diesen "Glättungen" umzugehen, allerdings war das Expertensystem dazu nicht fähig, es mußte deshalb im Feld versagen.

Ein letzter wichtiger Punkt ist die Planung des Expertensystem-Einsatzes und der Wartung. Die Aufwände für die Systemwartung sind oft viel höher als die Aufwände für die Erstellung. Sie beeinflussen das Kosten-Nutzen-Verhältnis ganz erheblich. Dies gilt für konventionelle Systeme, weil Modifikationen der Anforderungen während der Systemnutzung teuere Änderungen nötig machen.

Mit diesen Planungen ist eine vernünftige Nutzen- und Lifecycle-Kostenabschätzung möglich. Erst jetzt kann die Entscheidung für oder gegen die Entwicklung des Expertensystems im ganzen oder in inkrementellen Schritten gefällt werden. In diese Entscheidung geht außerdem eine Risikobewertung ein. Oft sind die Lösungskonzepte weit weniger erprobt als jene in konventionellen Projekten. Das Realisierungsrisiko, das gegenüber erprobten Lösungskonzepten besteht, sollte quantitativ abgeschätzt werden.

(wird fortgesetzt)