Software-Engineering dringt heute bis in ganzheitliche Fragestellungen der Systemorganisation sowie der Organisation von Strukturen und Abläufen allgemein vor. Dabei hat sich diese Disziplin gewandelt und weiterentwickelt zum Information-Engineering.

Das Software-Engineering hat seine Quellen in der Programmierung, beispielsweise Normierte Programmierung, Strukturierte Programmierung und Nassi-Schneiderman-Diagramme. Die Beachtung von Software-Engineering-Erkenntnissen und deren Methoden und Verfahren gehört heute zum Standard der Programmierung, zumindest der Programmierung in professioneller Umgebung.

Noch nicht so ganz als Standard scheinen sich die Methoden des System-Design durchgesetzt zu haben wie zum Beispiel Modularisierungsprinzipien, Geheimnisprinzip bis hin zu Leistungsbewertungsmethoden. Hierfür sind vor allem zwei Gründe zu sehen:

- Sofern das Entwicklungsteam klein genug (weniger als sechs Entwickler) ist, wirken diese Methoden in der Phase der Erstentwicklung (im Gegensatz zur Phase der Wartung) nur als Ballast. Daher werden sie - zum Nachteil der Wartung - gar nicht erst angewendet.

- Zusätzlich zu dieser Durchsetzungsschwäche tritt das zeitliche Zusammentreffen mit der Diskussion des Prototyping. Mit dem Argument "Performance-Nachteile" werden dann sehr schnell die Methoden des System-Design über Bord geworfen.

Obwohl sich also die Methoden des System-Design bis heute noch nicht überall durchgesetzt haben, wendeten sich die Experten des Software-Engineering einem neuen, noch weiter von der eigentlichen Programmierung entfernten Thema zu: Requirements-Analysis. Man hatte gemerkt, daß Anwender und Programmierer nicht mehr die gleiche Sprache sprechen. Der Anwender bekam nur in seltenen Glücksfällen das System, das seinen Anforderungen entsprach. Für diese Problemstellung wurde in manchen Ansätzen der untaugliche Versuch gemacht, den Anwender seine Anforderungen in einer formalen Sprache formulieren zu lassen (zum Beispiel in der Methode der algebraischen Spezifikation). Dabei ist es sicher richtig, daß große Teile der Anforderungen - wie zum Beispiel die Datenstrukturen - auf formal korrekte Weise festgelegt werden müssen. Auf der anderen Seite kann dies aber nur in der Sprache des Anwenders geschehen. Der Anwender sollte sonst lieber gleich selbst programmieren.

Diese Problematik der Requirements-Analysis wird wohl erst gelöst werden durch intelligente Tools, die es dem Anwender erlauben, in seiner Sprache zu spezifizieren, ihn dabei aber so weit führen und leiten, daß das Ergebnis formal korrekt ist. Dieses Ergebnis sollte dann durch Generatoren in Schnittstellen und Software soweit als möglich direkt umgesetzt werden, wobei auch die Modifikation schon mit diesem Tool erstellter Software leicht möglich sein muß. Als Vorbild und als Beweis der Realisierbarkeit kann man hier die Verkleidung von AB-Abfragesprachen in komfortable Benutzerschnittstellen heranziehen. Bei der Benutzung solcher Benutzerschnittstellen ist es nicht notwendig, daß der Anwender die Syntax der Abfragesprache beherrscht.

Anwenderwissen bedarf stärkerer Formalisierung

Durch die Möglichkeiten der Künstlichen Intelligenz werden die Fragen im Zusammenhang mit der Formalisierung des Anwenderwissens und der Anforderungen des Anwenders noch viel bedeutsamer, als man es vorher geahnt hätte. Knowledge-Engineering - und das heißt insbesondere die Formalisierung des Anwenderwissens - ist der Schlüssel zum Einsatz dieser neuen Technologien. Die meisten Versuche, Expertensysteme einzusetzen, werden in nächster Zeit am Knowledge-Engineering scheitern: Der hierfür zu verwendende Aufwand wird aufgrund des schlechten Formalisierungsgrades des Anwenderwissens immer hoch sein und in den meisten Fällen den erzielbaren Nutzen aufheben.

Genauso eng wie das Requirements-Engineering hängt das Information-Modelling mit der Formalisierung des Anwenderwissens und damit mit dem Knowledge-Engineering zusammen. Im Information-Modelling werden die für das Funktionieren eines Unternehmens oder einer Behörde relevanten Informationen hinsichtlich Struktur und Beziehungen - nicht ihre Inhalte - definiert. Die Notwendigkeit des Information-Modelling wurde zuerst erkannt von den Datenbankspezialisten. Sie entwickelten für ihre Zwecke des Datenbankdesigns Methoden zur Datenmodellierung. Solche Methoden wurden dann erweitert für das Information-Modelling.

Kommunikationsanalyse steht noch ganz am Anfang

Eine noch jüngere Geschichte hat die Kommunikationsanalyse im Software-Engineering. Streng genommen wird dabei das Information-Modelling erweitert um die Beschreibung der Kommunikationsbeziehungen, der Belastung der Kommunikationskanäle und der Vorgänge zur Erledigung der Aufgaben der Instanzen eines Unternehmens oder einer Organisation. Insgesamt ergibt sich damit eine Basis für die Beurteilung der Effizienz der Abläufe im Unternehmen, für die Verbesserung der Abläufe und der Erreichung der gesteckten Ziele sowie für die Unterstützung der Abläufe durch Informations- und Kommunikationstechnik.

Bei der Kommunikationsanalyse stellt sich - wie schon im System-Design - die Frage nach dem Verhältnis von Aufwand zu Nutzen. Es ist unmöglich, ein gesamtes Unternehmen kommunikationsanalytisch im Detail zu untersuchen. Aus diesem Grunde ist ein Ansatz zu wählen, in dem repräsentative Bereiche des Unternehmens im Detail, das Gesamtunternehmen aber nur auf einem relativ hohen Abstraktionsniveau untersucht werden. Durch Extrapolation kann dann auf die nicht untersuchten Bereiche die Informations- und Kommunikationstechnik ausgedehnt werden. Die Erfahrung hat gezeigt, daß ein solcher Ansatz praktikabel ist und durch Tools - basierend auf einer relationalen Datenbank - gut unterstützt werden kann.

Die Einführung von modernen Informations- und Kommunikationstechniken sollte heute immer gepaart werden mit einer repräsentativen Kommunikationsanalyse und einer Infrastrukturstrategie. Dabei legt die Infrastrukturstrategie die unternehmensinternen Standards für die Kommunikation fest. Es wird möglich, die Kommunikationsinfrastruktur nicht "auf einen Schlag" einführen zu müssen, sondern architekturkonforme "Inseln" zu einer Gesamtinfrastruktur zusammenwachsen zu lassen. Dabei werden die Inseln nach anwendungsorientiertem Nutzen ausgesucht, das heißt die Bürokommunikation ist nicht der alleinige Zweck der informations- und kommunikationstechnischen Ausstattung einer "Insel".

Phasenkonzept ist kein Wundermittel

Ein Gesamt-Software-Engineering-Modell (besser: System-Engineering-Modell) muß alle hier behandelten Themen von der Kommunikationsanalyse bis zur Programmierung - nicht einheitlich, sondern aufeinander abgestimmt - behandeln.

Die Themen

- Kommunikationsanalyse,

- Information-Modelling,

- Requirements-Engineering,

- System-Design und

- Programmierung

lassen ein Phasenkonzept durchscheinen. Auf der anderen Seite gibt es inzwischen relativ starke Kritiker an solchen Phasenkonzepten. Diese Kritik wird häufig verbunden mit dem Schlagwort "Prototyping" als Gegenpol.

Ein Phasenkonzept ist sicher kein Wundermittel gegen alle Krankheiten der Software-Entwicklung. Ein Phasenkonzept bringt sicher auch keine Verbesserung in der System-Entwicklung, wenn nur bestimmte Projektphasen eingeführt werden, diese Phasen aber nicht an ganz konkrete, abfragbare Phasenergebnisse gekoppelt werden. Phasen sollten deshalb nicht durch Aktivitäten, sondern durch Ergebnisse definiert sein. Die Ergebnisse sollten so fein strukturiert sein, daß sie eine Meßlatte für den Projektfortschritt bilden.

Dokumentation erweist sich als unerläßlich

Ferner ersetzt das sklavische Einhalten der Phasen des Projekts nicht die designerischen Fähigkeiten des Entwicklers oder die Intelligenz des Programmierers. Vielmehr muß das Entwicklungsteam in jeder Phase des Projekts zumindest ein Stück weit in die nächste Projektphase vordenken. Trotzdem bleiben die Phasenergebnisse der Maßstab des Projektfortschritts.

Wird ein Phasenkonzept, gleich um welches es sich handelt, in diesem Sinne eingesetzt, so ist es für die Entwicklung in großen Entwicklungsteams (mehr als fünf Entwickler) und von großen und komplexen Systemen (mehr als drei Mannjahre Aufwand) unentbehrlich. Solche Projekte können ohne ein vernünftiges Phasenkonzept fast nie erfolgreich abgewickelt werden.

Die zweite Komponente des klassischen Software-Engineering bildet - neben dem Phasenkonzept - die Dokumentation des Software-Systems. Sie wird notwendig, sobald eine Teamgröße von fünf Entwicklern überschritten wird, das System nicht vom Entwicklungsteam gewartet wird oder das System länger als zirka ein halbes Jahr benutzt wird.

Eine klassische Dokumentation enthält dann - in konsistentem Zustand - Pflichtenheft, Beschreibung des System-Design, Spezifikation der Modulen, gut kommentierten Quellcode beziehungsweise Konstruktionsbeschreibungen.

Das Pflichtenheft beschreibt dabei alle Funktionen des Systems aus der Sicht des zukünftigen Benutzers und zusätzlich die technischen Grundprinzipien des Systems.

Klassischer Ansatz beruht auf zwei Eckpfeilen

Phasenkonzept - verbunden mit entsprechender Methodik und entsprechenden Tools - sowie Dokumentation bilden die beiden Eckpfeiler des klassischen Software-Engineering. Als drittes Kennzeichen des klassischen Software-Engineering sei hier herausgestellt, daß nur der Entwickler, nicht aber der Anwender die Entwicklungstools benutzt.

Prototyping ist die Entwicklung eines Softwaresystems, ohne ein Pflichtenheft zu erstellen, ohne ein System-Design zu beschreiben, ohne eine Spezifikation der Modulen und ihrer Schnittstellen.

Natürlich können dabei "andere" Programmiersprachen behilflich sein. Wäre nämlich die Programmiersprache auf dem Level der Umgangssprache, so ließe sich ein solches Prototyping sofort ohne Einschränkungen sinnvoll und zielführend durchführen. Aber soweit sind wir noch nicht. Und sicher kann man das auch nicht behaupten von Lisp oder Prolog. Auch sogenannte End-user-Tools befinden sich in der Sprache näher am Level klassischer Programmiersprachen wie Cobol oder Pascal als auf dem Level der natürlichen Sprache. Dennoch ist der Effekt von richtig eingesetztem Prototyping oft nützlich, manchmal notwendig.

Ab einem Jahr Lebenserwartung ist eine Dokumentation nach Software-Engineering-Grundsätzen unbedingt notwendig. Das bedeutet, daß ab einer solchen Lebenserwartung, selbst wenn andere Gründe ein Prototyping erforderlich machen, das Vorgehen nach klassischem Software-Engineering zumindest nachgezogen werden muß.

Prototyp darf nicht zum eigentlichen System werden

Ein Softwaresystem (dies gilt allgemein für das Gesamtsystem) kann in zwei Richtungen innovativ sein: Es kann technisch innovativ sein, das heißt, es beinhaltet Komponenten, deren technische Lösung bisher nicht bekannt war. Oder es kann anwendungsorientiert innovativ sein, beinhaltet also Anwendungen, die bisher nicht durch Informationstechnik unterstützt wurden. Beide Richtungen der Innovation machen meist ein Prototyping sinnvoll, um die Machbarkeit der Lösung zu erforschen.

Wichtig bei Einsatz von Prototyping ist, daß der Prototyp nicht überlebt und damit zum System selbst wird über die Erprobungsphase hinaus. Erprobtes Einsatzgebiet für End-user-Tools und Productivity-Tools bilden nach dieser Einteilung Anwendungen mit kurzer Lebenserwartung und von niedrigem Innovationsgrad.

Dieses Bild der Koexistenz von Software-Engineering und Prototyping wird sich sicher in der Zukunft durch den Einsatz von Techniken der Künstlichen Intelligenz verschieben. Techniken der Künstlichen Intelligenz, eingesetzt für das Software-Engineering, werden die Verwendung von natürlicher Sprache in weiten Teilen des Software-Entwicklungsprozesses ermöglichen und damit die Grenze zwischen Software-Engineering und Prototyping verschieben. Durch den Einsatz von Techniken der Künstlichen Intelligenz, gepaart mit Datenlexika der zweiten Generation (für das Information Modelling), wird es möglich sein, selbstdokumentierende Programmiersprachen auf sehr hohem Niveau und eine entsprechende Toolunterstützung zu entwickeln. Bis dahin aber müssen wir mit der Trennung von Prototyping und klassischem Software-Engineering leben.

Für bestimmte Arten von Anwendungen haben sich programmierbare Productivity-Tools (zum Beispiel Framework) und Datenbanken mit Query-Languages, die in die Programmierumgebungen eingebettet werden können, als vorteilhaft erwiesen. Kriterien für den erfolgreichen Einsatz von Productivity-Tools und/oder Datenbanken sind:

- bis zu mittlere Komplexität der Anwendung;

- saubere Schnittstellen in Form von Datenübergabe zu Fremdsystemen oder Datenübernahme von Fremdsystemen;

- volumenmäßig auf Mikrosystemen implementierbar.

In diesen Fällen hat sich bei Einsatz von geeigneten Productivity-Tools und Datenbanken eine acht- bis zehnfache Entwicklungsproduktivität gezeigt. Dabei wurden Systeme implementiert mit bis zu 15 MB Datenvolumen, bis zu 150 Einzelprogrammen und Verteilung auf mehrere Systeme (keine verteilte Datenbank).

Auf diese Weise wurden aber auch Systeme entwickelt, für die nach dem vorangegangenen Abschnitt der Einsatz von Software-Engineering unbedingt notwendig ist. Dabei wird das Software-Engineering mit folgenden Modifikationen eingesetzt:

- Design

Als Grunddesign wird ein Datenmodell der Anwendung erstellt. Zusätzlich werden alle zu realisierenden Benutzerfunktionen und ihre Beziehungen zu den definierten Daten benannt, das heißt sie erhalten einen Namen, eine Kurzbeschreibung in zwei Sätzen und die Festlegung der Beziehungen zu den Daten (Erzeugen, Lesen, Modifizieren). Dieses Modell der Anwendung aus Daten, Funktionen und den Beziehungen läßt sich am günstigsten mit der Datenbank selbst verwalten. Darüber hinaus werden die Programme, ihre Beziehungen zu den Funktionen und zu den Daten auf gleiche Weise dokumentiert.

Keine Dokumentation wird angefertigt für das Layout der Funktionen wie zum Beispiel für die Masken. Es hat sich als praktikabel erwiesen, daß aufgrund der ungleich höheren Entwicklungsproduktivität einzelne Funktionen mehrfach geändert werden können.

- Dokumentation

Auf die Dokumentation des Systems kann man nicht verzichten, sobald die Lebenserwartung des Systems entsprechend hoch ist. Es ist jedoch möglich, nach den obigen Grundsätzen des Designs die Frage des Umfangs der Dokumentation allein aus dem Blickwinkel der Pflege und Wartung zu betrachten. Dabei stellt sich heraus, daß es ausreicht, das Design in obiger Weise in der Datenbank zu dokumentieren. Dies erlaubt auch fremden Entwicklern, sich in dem fertig implementierten System zurechtzufinden.

Productivity-Tools sind nur bedingt nutzbar

Bei der Verwendung von Spreadsheet-Programmen ist zusätzlich eine Crossreferenz-Liste für jedes Spreadsheet notwendig. Ferner ist selbstverständlich, daß der erstellte Quellcode gut kommentiert und strukturiert wird.

Leider sind all diese Vorteile nur mit den wenigsten Productivity-Tools voll ausnutzbar. So lassen sich zum Beispiel die meisten Spreadsheet-Programme - die für Planungsaufgaben sehr nützlich wären - nicht für diese Zwecke einsetzen, da sie nur über eine Makrosprache und nicht über eine Programmiersprache beziehungsweise Prozedursprache verfügen. Eine Makrosprache ist jedoch so lesbar wie unkommentierter Assembler-Code. Meist fehlen zusätzlich noch die Möglichkeiten von Unterprozeduren und Paramterübergabe oder gar ganz die für die Programmierung notwendigen Variablen. Hier gibt es für die Hersteller solcher Software - vor allem im PC-Bereich - noch eine ganze Reihe von Aufgaben zu erledigen bevor diese Software für die Realisierung von Anwendungen ohne zu großes Risiko eingesetzt werden kann.

Andererseits zeigt die Erfahrung mit Anwendern daß die Einsatz- und Nutzungsschwelle dann wesentlich niedriger ist, wenn dem Anwender ein auf seine Anforderungen zugeschnittenes Basissystem vorgefertigt wird. Mit diesem beginnt er zu arbeiten wie mit einem klassischen Anwendungssystem, mit dem er dann nach und nach so vertraut wird, daß er es auch frei als Productivity-Tool einsetzt. Gleichzeitig kann so vermieden werden, daß jeder einzelne Anwender wieder in die gleichen "Fallen des Productivity-Tools fällt".

Software-Engineering ist aus der Systementwicklung nicht mehr wegzudenken. Die DV-Branche würde sich anderenfalls in die "Steinzeit' der Software-Entwicklung zurückbegeben. Software-Engineering kann mit den modernen Tools, die mit den PCs gekommen sind, sinnvoll kombiniert werden. Die Disziplin hat sich ausgeweitet von der reinen Programmiermethodik bis zur Analyse der Organisation. Aber: Software-Engineering kann sich nur dann weiterentwickeln, wenn es praxisnah bleibt.

Dr. Hanns-Martin Meyer ist Geschäftsführer der Telenorma Datensysteme GmbH, Eschborn.