*Dipl.-Kaufm. Andreas Bölscher ist Mitarbeiter der KPMG Deutsche Treuhand-Unternehmensberatung GmbH, München.

Probleme bereitet nach wie vor, trotz Verbreitung wissensbasierter Systeme in den Unternehmen, die Dokumentation ihrer Entwicklung. Gewöhnlich gibt es keine unternehmensweiten Dokumentationsrichtlinien, und wenn es sie gibt, werden sie selten so eingehalten, daß auch Außenstehende, die nicht an der Entwicklung beteiligt waren, das System verstehen.

Wissensbasierte Systeme (WBS) werden hier definiert als Computersysteme, die das Wissen und die Problemlösungsfähigkeit eines oder mehrerer Experten in einem (meist eng abgegrenzten) Anwendungsbereich zur Verfügung stellen. Als Wissensquelle für die Entwicklung eines WBS dienen nicht nur das Wissen eines menschlichen Experten, sondern beispielsweise auch Handbücher und Gesetzestexte. Nicht selten unterbleibt die Dokumentation gänzlich. Sobald es darum geht, sie zu erstellen, tauchen Ausreden auf wie

- "Dafür ist jetzt keine Zeit."

- "Die Dokumentation ist schnell nicht mehr aktuell."

- "Solche Unterlagen schaut sich eh niemand an."

- "Es gibt wichtigere Dinge zu tun."

Dieser Artikel will einige Vorschläge zur Dokumentation solcher Entwicklungen unterbreiten. Sie sind das Ergebnis mehrerer Projekte, an denen der Autor als externer Berater beteiligt war.

Aufwand darf nicht unterschätzt werden

Ein einsatzfähiges WBS besteht - wie jede entwickelte Software - aus seiner technischen Realisierung (dem Programmcode) und der Dokumentation. Ein Entwicklungsprozeß, der durch eine adäquate Dokumentation unterstützt wird, sichert den erfolgreichen Einsatz des fertigen Produkts nicht nur für partikuläre und isolierte Problemlösungen, sondern insbesondere für unternehmungsweite Aufgabenstellungen. Der zur Erstellung und Änderung der Dokumentation nötige Aufwand sollte jedoch nicht unterschätzt werden. Wie jede Anwendung ist auch ein WBS letztlich nur so gut wie seine Dokumentation.

In der Dokumentation wird die Entwicklung des WBS sowie die Erhebung und Strukturierung des Wissens beschrieben. Traditionell wird Dokumentation als "Nachdokumentation" verstanden; das heißt: In der Praxis wird sie meist nachträglich für ein bereits fertiges System produziert. Mehrere Gründe jedoch sprechen dafür, sie als integralen Bestandteil des Produktes zu betrachten und sie vom ersten Moment an parallel zur Entwicklung mitzuführen:

- Für ein erfolgreiches Projektmanagement ist die Dokumentation als Grundlage der Projektplanung und -steuerung unverzichtbar.

- Ein unstrukturiertes Wiederaufsetzen im Entwicklungsprozeß nach Fehlentwicklungen wird vermieden. Wenn jeder Schritt sauber dokumentiert ist, können Entwicklungspfade verlassen oder untaugliche Prototypen aufgegeben werden, ohne daß bisher gewonnene wiederverwertbare, allgemeingültige Erkenntnisse verlorengehen.

- Der erforderliche Aufwand verringert sich spürbar, wenn derjenige, der eine Information erzeugt oder verarbeitet, den Sachverhalt sofort dokumentiert.

- Bei einer Nachdokumentation am Ende der Implementierung sind oft wichtige Informationen, die während der Entwicklung angefallen sind, nicht mehr vorhanden.

- In der Praxis fehlen den Mitarbeitern nach dem Abschluß einer Projektphase sowohl die Zeit als auch die Motivation für eine ausreichende Nachdokumentation.

Die Erfahrung hat gezeigt, daß die (durchaus redundante) Projekt-Dokumentation ein wertvolles Hilfsmittel bei der Wissensanalyse ist. Dies gilt insbesondere für die frühen Phasen der Entwicklung, in denen die Entwickler mit der Terminologie des spezifischen Fachgebiets noch nicht vertraut sind, oder wenn Wissen aus vielen Quellen integriert werden muß. Häufig ist die Erfassung von bisher nur "diffusem" Wissen allein schon von hohem Nutzen für die Experten und auch die Unternehmensleitung.

Darüber hinaus ist gerade für ein WBS, das typischerweise eine intensive Pflege und Wartung des Wissensbestandes erfordert, eine ausführliche Projekt-Dokumentation unverzichtbar. Denn häufig sind es nicht die Entwickler, die später das fertige System warten.

Alle Bestandteile der Projekt-Dokumentation werden parallel zum Projektfortgang sukzessive erweitert und ergänzt.

Daneben gelten für die Dokumentation einer WBS-Entwicklung natürlich auch die üblichen Prinzipien des traditionellen Software Engineerings - daß in ihr etwa die Protokolle der internen Projektbesprechungen gesammelt werden oder daß sie eine Implementierungsbeschreibung enthält, in der die Namenskonventionen formuliert, WBS-Dateien und Dateien für die Datenkommunikation benannt sowie programmiertechnische Details beschrieben werden. Darauf soll an dieser Stelle nicht weiter eingegangen werden.

Im folgenden sollen die besonderen Bestandteile der Projekt-Dokumentation eines WBS erläutert werden. Zur Veranschaulichung wird ein fiktives WBS aus dem Bereich des internationalen Finanzmanagements dokumentiert.

1. Aufgabenbeschreibung des zukünftigen WBS

In diesem Abschnitt ist festzulegen, welcher Personenkreis im Unternehmen mit dem WBS wie zu unterstützen ist. Insbesondere sind die Art und Weise sowie der Umfang der Unterstützung zu bestimmen. Darüber hinaus wird eine Begründung für die Entwicklung des WBS in dem spezifischen Bereich geliefert sowie Ziel und Nutzen des späteren Systems erläutert. Es werden Zeiträume für die Entwicklung des ersten Prototypen sowie des Produktionssystems genannt und die Art der Integration des WBS in die vorhandene DV-Umgebung des Unternehmens beschrieben. Schließlich enthält sie eine Auflistung der Quellen für die Wissensakquisition mit einer kurzen Beschreibung der jeweiligen Inhalte.

Das WBS INFAM (Internationales Finanzmanagement) soll die Mitarbeiter im Firmenkundengeschäft der Crash Credit AG in der Wahl der optionalen Finanzierungsinstrumente beraten. Durch den Einsatz eines WBS wird das umfangreiche Know-how einer kleinen Gruppe von Experten dem ganzen Crash-Konzern zur Verfügung gestellt. Die Firmenkundenbetreuer werden in die Lage versetzt, ihre Kunden qualifizierter und selbständiger zu beraten. Damit es dem Anspruch eines Beratungs- und Auskunftssystems gerecht werden kann, wird die Erklärungskomponente einen Schwerpunkt bei der Entwicklung des WBS darstellen.

Es ist geplant, eine erste Version des Systems bis September 1990 fertigzustellen. INFAM 1.0 wird Wissen aus dem Bereich des Swapgeschäfts der Crash Credit AG beinhalten. Eine Integration in die Großrechnerumgebung von Crash ist nicht notwendig. INFAM soll in Zukunft die Firmenkunden-Betreuer vor Ort unterstützen und deshalb nur auf einem portablen PC-AT laufen.

Quellen für die Wissensakquisition sind:

- Frau Baisse und Herr Spekulatius, die anerkannte Experten in der Firmenkundenabteilung der Crash Credit AG, Frankfurt, sind.

- Hanspeter Gondring, Albrecht Herrmann: Zins- und Währungsswaps aus bankbetrieblicher Sicht. In: ÖBA 8/86, S. 327-339.

2. Wissensakquisitionsplan

Hier werden die Ziele aufgelistet, die mit der Wissensakquisition in einer bestimmten Zeit erreicht werden sollen. Er füllt die Entwicklungsphasen, die zeitlich nach der Auswahl des Anwendungsgebietes liegen, inhaltlich aus. Dokumentiert wird die Reihenfolge des Vorgehens, beispielsweise in Gestalt eines Zeitplans für die Entwicklung bestimmter Module oder Aspekte des Akquisitionsdesigns ("Wer erhebt welches Teilwissen, wie, wann, von wem, in welcher Reihenfolge?"). Der Wissensakquisitionsplan erlaubt zu kontrollieren, inwieweit die gesteckten Ziele mit dem bisher erhobenen Wissen erreicht wurden. Er wird als Dokument des Entwicklers beziehungsweise des Projektleiters geführt, der auch verantwortlich für diesen Teil der Dokumentation ist.

... soll möglichst einer der nächsten Schritte ein Test des Prototyps durch Frau Baisse sein, um das Modul "Basisswap" bis April abzuschließen. Ist dies ohne große Änderungen erfolgt, wird ein Test dieses Moduls mit zukünftigen Nutzern der Filiale Köln im Mai insbesondere die Akzeptanz der Benutzerschnittstelle überprüfen ... die nächste Einheit wird dann bis Juli entwickelt.

3. Knowledge Dictionary (Glossar)

Das Glossar ist eines der wichtigsten Projektdokumente. Vor allem in der Anfangsphase des Projekts, in der die Systementwickler sich mit neuen Fachbegriffen und Konzepten vertraut machen müssen, bietet das Glossar eine systematische Methode zur Speicherung und Verarbeitung der Begriffe und hilft, semantische Mißverständnisse zu vermeiden.

Dies gilt ebenso für die spätere Wartung und Pflege sowie für die Einarbeitung neuer Entwickler.

Das Glossar ist eine Auflistung von Begriffen und Abkürzungen aus dem Fachgebiet in der Form eines Stichwortverzeichnisses. Inhalt sind der jeweilige Begriff (gegebenenfalls Abkürzung), die Bezeichnung des zugehörigen Systemelements (Variablenbezeichnung), eine kurze verbale Erklärung, mögliche Attribute, Werte und Wertebereiche, die Informationsquelle und eine Spalte für Anmerkungen. Werte beziehungsweise Wertebereiche werden nur angegeben, wenn sie bestimmbar sind.

Eine Einbindung des Glossars in ein Data-Dictionary/Directory-System ist wünschenswert, da WBS zunehmend nur Module eines größeren Systemes der traditionellen DV sind. Die technische Integration eines WBS, beispielsweise mit den Shells KBMS von AICorp, ADS von Aion oder Twaice von Nixdorf, stellt keinen Engpaß in der Systementwicklung mehr dar.

4. Sammlung unumstößlicher Fakten

In jedem Gebiet (Domäne) gibt es Fakten, die unumstößlich und immer wahr sind. Das gilt vor allem für technische Disziplinen: Die Temperatur, bei der bestimmte Metalle schmelzen, ist ein Beispiel. Bestehen bezüglich der verwendeten Konzepte in der Domäne relativ wenige Unsicherheiten und Unschärfen, so kann die Sammlung unumstößlicher Fakten auch im Rahmen des Glossars abgebildet werden.

5. Transkribierte Interviews

Die Sammlung der Niederschriften der Experteninterviews kann in drei Formen erfolgen: als reine Wiedergabe des aufgezeichneten Interviews, als aufbereitete Niederschrift, in dem überflüssige Teile des Interviews gestrichen wurden, oder als Zusammenfassung. Im Interesse einer besseren Lesbarkeit und Verständlichkeit empfiehlt sich die Zusammenfassung, insbesondere wenn weitgehend auf schriftliche Wissensquellen zurückgegriffen werden kann. Hierbei ist allerdings mit großer Sorgfalt vorzugehen, damit nicht wichtige Details unterschlagen oder Fehlinterpretationen provoziert werden. Zugleich ist zu beachten, daß meist nur bei einer reinen Niederschrift die Information im Glossar einer wörtlichen Aussage des Experten zugeordnet werden kann.

Reine Niederschrift:

Interview mit Herrn Spekulatius am 1. 4. 1989:

Herr Spekulatius: Guten Tag, Herr Interviewer, Herr Protokollant.

Interviewer: Guten Tag, Herr Spekulatius. Wir haben uns bereits beim letzten Gespräch über das WBS unterhalten und wie wir Crash mit dieser Technik unterstützen wollen. Heute sind wir zusammengekommen, um Swaps und ihre Varianten zu besprechen. Können Sie uns zu Anfang erklären, was Swaps überhaupt sind?

S: "To swap" bedeutet soviel wie austauschen. Zu unterscheiden ist zwischen Zins- und Währungsswaps einerseits und Devisenswaps andererseits. Vielleicht beginne ich einfach mit den Zinsswaps, dann wird das Swapgeschäft transparent ...

Gut, Zinsswaps - auch interestrate-swaps genannt - kann man unterteilen in reine Zinsswaps und in Basisswaps.

Basisswaps sind eine Sonderform des Zinsswaps, da hier im Gegensatz zum reinen Zinsswap zwei variabel verzinsliche Verbindlichkeiten getauscht werden. Dazu aber später mehr ...

Beim reinen Zinsswap wird ein Straight Bond ...

I: Straight Bond?

S: Straight Bonds sind Festzins-Anleihen. Also, es wird eine festverzinsliche Anleihe mit einer variabel verzinslichen Verbindlichkeit, zum Beispiel einem Roll-over-Kredit, getauscht. Genau gesagt werden nur die Zinsserbindlichkeiten getauscht, die aus der Aufnahme von Geldmitteln in gleicher Höhe und Währung resultieren. Die eigentliche Aufnahme der Gelder nennt man übrigens Grandgeschäft. Crash hat erste Bonität. Getauscht wird mit Unternehmen, die keine so hohe Bonität aufweisen, wie zum Beispiel die Asia Corporation. Die Asia Corporation muß daher für Kredite eine höhere Risikoprämie zahlen. Crash bekommt zur Zeit festverzinsliche Kredite zu 6 Prozent p.a. und einen variabel verzinslichen Kredit zum Fibor. Asia muß sieben Prozent für den Festzins und Fibor plus 1/2 für den variablen zahlen.

Gehen wir davon aus, wir nehmen eine Festsatzverbindlichkeit zu sechs Prozent auf und Asia eine Roll-over-Verbindlichkeit zu Fibor plus 1/2 Prozent. Tauschen beide nun ihre Zinszahlungsverpflichtungen aus, so hat Asta einen Zinsvorteil von einem Prozent im Vergleich zum Festsatz: sieben Prozent minus sechs Prozent. Crash hat dagegen einen Zinsnachteil in Hobe von 1/2 Prozent im Vergleich zur direkten Roll-over-Aufnahme. (Fibor - (Fibor + 1/2 Prozent)). Asia zahlt nun das halbe Prozent an uns zum Ausgleich, und beim Restvorteil von 1/2 Prozent machen wir häufig Halbe-Halbe, so daß jeder 1/4 Prozent Zinsvorteil durch ein Swapgeschäft hatte.

Ein wichtiges Motiv für den Zinsswap - das hatte ich vergessen - sind unterschiedliche Interessen hinsichtlich der Zinsberechnungsbasis. Asia ist grundsätzlich an Festzinsverbindlichkeiten interessiert, da diese die Kalkulation zum Beispiel für Investitionen viel sicherer machen. Wir jedoch sind zur fristenkongruenten Refinanzierung unseres Aktivgeschäfts auch an variabel verzinslichen Verbindlichkeiten interessiert ...

Zusammenfassung:

lnterview mit Herrn Spekulatius am 1. 4. 1989; Thema: Swaps und ihre Varianten

Swaps sind zu unterscheiden in Zins- und Währungsswaps einerseits und Devisenswaps andererseits. Zinsswaps - auch interestrate-swaps genannt - kann man unterteilen in reine Zinsswaps und en Basisswaps.

Basisswaps sind eine Sonderform des Zinsswaps, da hier im Gegensatz zum reinen Zinsswap zwei variabel verzinsliche Verbindlichkeiten getauscht werden.

Reine Zinsswaps sind Geschäfte, bei denen zwei Parteien vereinbaren, die Zinsverbindlichkeiten zu tauschen, die aus der Aufnahme von Geldmitteln gleicher Höhe und Währung entstehen. Die eigentliche Aufnahme der Gelder nennt man Grundgeschäft. Beim reinen Zinsswap wird die Zinszahlungsverpflichtung einer variablen Verbindlichkeit gegen die einer festverzinslichen Mittelaufnahme getauscht.

Folgenede Voraussetzungen für den reinen Zinsswap müssen erfüllt sein:

a) Zwischen den Swap-Partnern muß ein deutlicher Bonitätsunterschied bestehen, der sich in unterschiedlichen Konditionen am Finanzmarkt niederschlägt. Crash ist ein Institut erster Bonität.

b) Der Partner mit der höheren Bonitätseinstufung sucht variabel verzinste Mittel, der andere festverzinste.

c ) Die Zinsdifferenz bei Festmittelbeschaffung durch die beiden Partner muß größer sein als die entsprechende Differenz bei einer zinsvariablen Finanzierung. Das Beispiel des Experten kann in folgende mathematische Formel umgesetzt werden:

|zf(A) - zf(B)| > |zv(A) - zv(B)|

mit

zf = Festzinssatz

zv = variabler Zinssatz

A = Schuldner erstklassiger Bonität

B = Schuldner geringerer Bonität

Sind die Voraussetzungen erfüllt, zo hat A einen relativen Vorteil am Markt für Festsatzmittel, B einen relativen Vorteil am Markt für variabel verzinsliche Mittel, weil hier der Zinsaufschlag, den B aufgrund seiner schlechteren Bonität zahlen muß, geringer ist. Durch einen Zinsswap können sie nun gemeinsam ihre Finanzierungskosten senken.

Die Höhe des Gewinns G = |zf(A) - zf(B)| - |zv(A) - zv(B)| ergibt sich aus der Zinsdifferenz. Der Gewinn wird bei Crash üblicherweise geteilt ...

6. Zwischenrepräsentationen

Die Repräsentation eines Wissensgebiets erfolgt in einen Drei-Ebenen-Modell. Ziel dieser mehrstufigen Repräsentation ist die schrittweise Annäherung an die Repräsentation auf der Implementierungsebene.

Auf der ersten Ebene wird eine Übersicht über die Domäne erstellt. Damit soll eine grobe Strukturierung des Wissensgebiets erreicht werden.

Problemlösungsstrategien der Experten werden noch nicht berücksichtigt. Diese Übersicht erfolgt in einer ersten Phase der Wissensakquisition, in der man sich mit der Domäne vertraut macht.

Auf der zweiten Ebene erfolgt eine sehr viel detailliertere Abbildung der Einflußfaktoren und Entwicklungsziele, die auch die Problemlösungsstrategie erfaßt.

Ziel dieser Repräsentationsebene ist die vollständige grafische Abbildung des Wissensgebiets vor einer Implementierung. Sie ist das Ergebnis der Wissenserhebung und -analyse.

Um in der Darstellung Prioritäten und Reihenfolgen ausdrücken zu können, werden folgende Konventionen eingehalten:

- Die Reihenfolge zu prüfender Entwicklungsziele wird durch gestichelte Pfeile zwischen den entsprechenden Knoten ausgedrückt.

- Prioritäten können durch entsprechende Numerierung der Kanten verdeutlicht werden.

Auf der dritten Ebene wird das Wissen der Domäne, das in der zweiten Ebene vollständig abgebildet ist, in einer regelorientierten, textuellen Form dargestellt. Sie ist eine der Implementierungs-Ebene nahekommende Wiedergabe, ohne jedoch werkzeugspezifisch zu sein und trägt die Bezeichnung "Pseudo-Code". Die Abbildung des Wissensgebiets auf einer dritten Ebene ist optional, da der Wartungsaufwand für diese Ebene sehr hoch ist. In vielen Projekten wird daher auf sie verzichtet.

7. Falldaten-Analysen

Falldaten (test cases) sind eine spezifische Art des Interview-Transkripts. Es enthält die Erläuterungen des Experten, wie er einen spezifischen Fall löst. Mit den Falldaten nennt der Experte seine Problemlösungstrategien. Das Ergebnis ist eine Mischung von Formalismen: das Transkript, die Analyse der Problemlösungsstrategien des Experten durch den Systementwickler und eine Aufgabenbeschreibung, die dem Testfall zugrundelag. Die Falldaten-Analysen sind die Grundlage für das Testen des Systems; einige WBS-Shells besitzen sogenannte Falldaten-Bibliotheken, in denen Testfälle gespeichert werden.

8. Projekt-Logbuch

Das Projekt-Logbuch ist ein Teil der persönlichen Dokumentation des Systementwicklers. Es sollte unklare Sachverhalte dokumentieren und wie sie behoben wurden (beziehungsweise warum nicht). Welche Schwierigkeiten auftraten, was wann und warum getan wurde, ist ebenfalls Inhalt des Projekt-Logbuchs. Die Konsequenzen früherer Handlungen und die ersten Entwürfe eines zukünftigen Plans werden festgehalten, dazu die wichtigsten Erfahrungen, die man während des Projekts sammelte. Das Projekt-Logbuch wird als Kladde geführt, in die auch künftige Änderungen aufgenommen werden können.

Damit sind die wesentlichen Besonderheiten aufgeführt, die bei der Entwicklung eines WBS anfallen. Daneben gelten die üblichen Prinzipien des Software Engineerings.

Die projektbegleitende Dokumentation ist auch in den frühen Phasen der Systementwicklung wichtig, weil sie häufig die einzigen greifbaren Zwischenergebnisse auf dem Weg zum späteren System enthält und eine unentbehrliche Basis für den Kommunikationsprozeß zwischen allen an der Systementwicklung Beteiligten darstellt.

Zunehmend wird die Dokumentation durch Werkzeuge unterstützt. Hersteller von Expertensystem-Shells bieten Module an, die zum Beispiel durch Hypermedia den Entwicklungsprozeß bereits vor der eigentlichen Implementierung unterstützen. Dies ist gegenwärtig ein Forschungsschwerpunkt verschiedener Hersteller, und man darf gespannt sein, was die Shells der Zukunft bieten werden.