Die Andersartigkeit des Ansatzes Standardsoftware auf der Basis von Referenzmodellen zu entwickeln, dokumentiert sich unter anderem darin, daß der Aufwand für Kundenanpassungen im wesentlichen durch Customizing, Tailoring und regelbasiertes Konfigurieren um Größenordnungen reduziert werden kann.

Die hier vorgestellte Methode, die an die objektorientierte Programmierung angelehnt ist, zielt auf maximale Wiederverwendbarkeit von Geschäftsobjekten, Geschäftsregeln und Geschäftsprozessen. Sie stellt gleichzeitig die Projektinfrastruktur von 4GL-Client-Server-Entwicklung auf Klassenbibliotheks-basierte Entwicklung von Standardsoftware um. Der Kern der Standardsoftwaresysteme beinhaltet die jeweils allgemeinsten Architekturobjekte und Geschäftsprozesse und kann von einem sehr kleinen Team entwickelt und gewartet werden.

In den Individualprojekten können mehrere Softwareentwicklungsteams unter der Koordina- tion des Kernteams arbeiten, um ableitend von der Architektur des Kernsystems Struktur und Verhalten zu modellieren, simulieren und zu implementieren.

Das Kernentwicklungsteam ist umgekehrt verantwortlich für die Identifizierung wiederverwendbarer Geschäftsobjekte und zur Integration der wiederverwendbaren Teile in das Standardsoftware-Kernsystem. Dieser Prozeß ermöglicht einen maximalen Faktor an Wiederverwendbarkeit und erleichtert somit wesentlich die Wartbarkeit der Standardsoftware. Die für Wiederverwendbarkeit beauftragten Personen des Kernentwicklungsteams haben die Funktion eines Klassenbibliotheksverwalters oder eben eines Beauftragten für Wiederverwendung auszufüllen. Sie halten auch die Kommunikation zwischen den verschiedenen Softwareprojekten aufrecht.

Durch Weiterbildung der Mitarbeiter von Systemanalytikern zu Anwendungsdesignern und Modellierern und durch Anheben des Niveaus der Anwendungsentwickler auf die Ebene von Wiederverwendungsbeauftragten werden die Mitarbeiter in die Lage versetzt, in der gleichen Zeit mehrfach so produktiv zu sein wie bei den derzeit angewendeten Verfahren. Durch Umstellung auf diese Methode wird der Flaschenhals von der Menge der zu bewältigenden Programmieraufgaben wechseln zu einem Mangel an hochqualifizierten Systemanalytikern, denn die Implementierungsphase wird durch die Vorgenerierung von Programmlogik, Benutzungsoberflächen und Datenbankanbindung hoch automatisiert.

Naturgemäß wird sich dadurch die Qualität der Anwendungssysteme erheblich verbessern, da größere Anteile der Implementierung durch die Vorgenerierung fehlerfrei sind. Die Flexibilität in bezug auf Änderung von Verhalten und Funktionalität wird ebenfalls verbessert, da durch dynamische Regelinterpretation Hunderte und Tausende von Geschäftsregeln angepaßt werden können, ohne die konventionelle Anwendungslogik zu verändern. Damit ist die Geschwindigkeit zur Umsetzung und Vermarktung (time to market) von Standardsoftwaresystemen bei Anwendung dieser Methode im wesentlichen nur begrenzt durch menschliche Ressourcen für Analyse, Design und Verifizierung.

Schritt für Schritt kann Know-how aus den herkömmlichen Entwicklunsprozessen übernommen werden für die Entwicklung von objektorientierten Standardsoftware-Kernsystemen.

Viele Client-Server-Projekte werden derzeit entwickelt mit relationalen Datenbanksystemen (RDBMS) wie zum Beispiel Oracle, Informix, Sybase etc. in Kombination mit 4GL-Programmiersprachen wie Oracle Forms, SQL Windows oder Powerbuilder. Das Relationenschema dient als konzeptuelles Anwendungsmodell, und das 4GL-Werkzeug dient zur Entwicklung der grafischen Benutzungsoberfläche, des Datenbankzugriffs und der Anwendungslogik. Neue Anforderungen werden von Systemanalytikern gesammelt und an die Softwareentwickler zur Erstellung des High-level-Designs weitergegeben.

Der konventionelle Software-Entwicklungsprozeß erfordert eine Reihe von Schritten, um das High-level-Design in eine laufende Applikation zu überführen. Dazu gehören schwerpunktmäßig

- die Erstellung des konzeptuellen Datenbankschemas,

- das Design für die Dialoge der Benutzungsoberflächen,

- die Programmierung der Datenbank-Anfragen und Transaktionen und

- die Implementierung der Geschäftsprozeß- und der Anwendungslogik.

Das wiederholte Durchlaufen dieser Schritte führt zu einer Vielzahl von Problemen in der Wartung und Erweiterung der Anwendung.

Vorgenerierung von Geschäftsobjekten

Heute gibt es bereits mehrere Ansätze von Generatorsystemen, die ausgehend von einem solchen Anwendungsmodell vollständig lauffähige Subsysteme mit grafischer Benutzungsoberfläche, Datenbank-Transaktionen und Geschäftsprozeß-Logik erzeugen. Ein solcher Generator übersetzt die Prozeßlogik genau in die entsprechende Implementierungslogik. Mithilfe eines grafischen Prozeßmodell-Editors können die Prozeßmodelle leicht geändert und auf die spezifischen Kundenwünsche hin angepaßt werden.

Ein solcher Generator sorgt zugleich für einen Produktivitätssprung in der Anwendungsentwicklung, da der Aufwand vom Testen und Debuggen zurück über die Implementierung in die Phase von Analyse und Design verlagert wird. Eine Reihe von Strukturbrüchen im Softwareentwicklungsprozeß wird dadurch vermieden. Ebenso entfällt im hohen Maße die Notwendigkeit für das Reverse Engineering, da der überwiegende Teil der Anwendungssystementwicklung in die Analyse- und Designphase verlagert wurde.

Zusammenstellung von Objekten zu Systemen

Aus einzelnen solcher Geschäftsobjekte, die aus einer Ansammlung von Teil-Objektmodellen wie Kundenverwaltung, Geräte, Normen, Verträge, Organisationseinheiten etc. und Geschäftsprozessen bestehen, lassen sich vollständige Anwendungssysteme zusammenfügen. In diesem Moment ist es sehr wichtig, Überlappungen zu identifizieren und diese Teile des Anwendungssystems zur Wiederverwendbarkeit heranzuziehen.

So gesehen kommt der Zusammenführung von Geschäftsobjekten zu integrierten Systemen mehr und mehr Bedeutung zu.

Das Zusammenführen ist dabei weniger zu verstehen im Sinne der komponentenweisen Zusammensetzung, sondern vielmehr in der Integration zu einem Gesamtsystem unter Weglassen von mehrfach vorhandener Struktur und Funktionalität.

Die so entstandenen Anwendungssysteme werden dann im Regelfall nicht losgelöst eingesetzt, sondern müssen in andere funktionale Systeme eingebettet werden oder sie selber betten andere Anwendungssysteme mit ein, oder es werden zumindest Schnittstellen dorthin geschaffen. Dazu gehören beispielsweise sowohl technische Systeme wie Klassenbibliotheken (C++, Java, Smalltalk) für Benutzungsoberflächen, Datenbanksysteme, Kommunikationsbibliotheken etc. als auch Anwendungssysteme wie Standardsoftware für Buchhaltung, Lohnabrechnung, Rechnungsstellung etc.

Auf der Basis eines gegebenen Anwendungssystems werden in der Regel mehrere oder bei Standardsoftware sogar viele Projekt- und/ oder Kunden-spezifische Erweiterungen parallel durchgeführt (Projekt A, B, C, D). In herkömmlichen Softwareentwicklungsumgebungen ist diese Vorgehensweise in hohem Maße mit Problemen behaftet.

Hin zu Referenzmodell-basierten Systemen

Ohne Anwendung von objektorientierten Modellierungs- und Programmiermethodiken ist es praktisch unmöglich, Wiederverwendbarkeit auszunutzen und zur redundanzfreien Softwareentwicklung zu kommen.

Bei großen Standardsoftwaresystemen (mehrere hundert Klassen, mehrere tausend Attribute, mehrere hundert bis tausend Funktionen) ist es für Systemanalytiker, Designer und Entwickler praktisch unmöglich, die Kontrolle über den Softwareentwicklungsprozeß zu behalten, weil in der Regel nach der "Kopieren-Einsetzen-Modifizieren"-Methode gearbeitet wird. Dies wird häufig auch noch durch die verwendeten Programmierwerkzeuge (zum Beispiel 4GL-Sprachen) erzwungen, da sie - wenn überhaupt - nur beschränkte Möglichkeiten zum Aufbau Hersteller-unabhängiger Klassenbibliotheken vorweisen.

Da die Wiederverwendbarkeit von der Projektinfrastruktur in der Regel schon nicht zur Verfügung steht, ist es auch für die verschiedenen Projektteams praktisch unmöglich, über das Wiederverwendbarkeitspotential auf dem laufenden zu bleiben. Der dazu benötigte Kommunikationsaufwand wäre einfach zu groß.

Also muß der Softwareentwicklungsprozeß als solcher signifikant geändert werden. Wie beschrieben, muß er zunächst einmal auf die Verwendung von objektorientierten Analyse- und Design-Techniken umgestellt werden. Dann müssen Personal-Ressourcen ausgerichtet werden auf die Erstellung von Basisbibliotheken, Toolkits, Frameworks und Kernsystemen, die einen möglichst hohen Grad an Standardisierung aufweisen. Diese Kernsysteme erlauben es dann, aus dem Vorhandenen das Objektmodell abzuleiten und zu erweitern und zwar in einer Weise, die von vornherein das Potential hat, Redundanz zu vermeiden und die Wiederverwendbarkeit zu erhöhen. Gleichzeitig wird die "Kopieren-Einsetzen-Modifizieren"-Programmiermethodik vermieden.

Damit ist bereits für die Bereiche sehr großer Standardsoftware-Systeme das Potential für die Wiederverwendbarkeit geschaffen, so daß es im wesentlichen nur noch von der Disziplin der Entwickler abhängt, ob sie nun tatsächlich auch ausgenutzt wird. Von den Klassenbibliotheken, die man - so vorhanden - dann lieber auf dem Markt kaufen sollte, anstelle sie selbst zu entwickeln, lassen sich dann die Funktionen des eigenen Anwendungssystems ableiten und in die projektspezifischen Erweiterungen mit einbringen.

Es kommen aber in der Regel nicht nur Projekt-spezifische Erweiterungen hinzu, sondern gleichzeitig entstehen Kandidaten, die für die Wiederverwendbarkeit im Kernsystem geeignet sind (zum Beispiel spezielle Grafikelemente, die in einer Prozeßvisualisierungsanwendung entwickelt wurden, die später auch für Geschäftsgrafiken genutzt werden können).

Die Kandidaten für Wiederverwendbarkeit müssen durch speziell für die Funktion ausgebildete Spezialisten (Librarians, Wiederwendbarkeitsbeauftragte) identifiziert und aufbereitet werden. Die wiederverwendbare Funktionalität wird mit dem Kernsystem verschmolzen (siehe Abbildung 2) und führt zu einem Kernsystem mit wesentlich höherem Faktor an Wiederverwendbarkeit (= Quo- tient aus wiederverwendbarer Funktionalität zu individuell neu entwickelter Funktionalität).

Umverlagerung der Tätigkeiten

Die Beauftragten für Wiederverwendbarkeit müssen die Anwendungsentwickler in der Anwendung der neuen Bibliotheksfunktionen trainieren. Nachdem der Prozeß eingeschwungen ist, besteht Anwendungsentwicklung zu einem hohen Maße aus Modellierung, Konfiguration, Tailorisierung, Simulation und Optimierung anstelle von Compilierung, Testen und Debuggen.

Der Ansatz dieser Methode besteht darin, einen Großteil der bereits vorhanden Ressourcen sukzessive für produktive Entwicklungstätigkeiten freizusetzen. Die Umverlagerung der Tätigkeiten der Systemanalytiker und Softwareentwickler würde allmählich in Richtung Analyse und Design von Geschäftsobjekten, Geschäftsregeln und Geschäftsprozessen sowie deren Simulation und Optimierung gehen. Das ist möglich, weil konventionelle Anwendungsentwicklung Schritt für Schritt durch schnelle Anwendungsentwicklung und Anwendungsgenerierung ersetzt wird. Zusätzlich kann aus vorhandenen Ressourcen ein kleines Team von Entwicklern zusammengestellt werden (eine bis drei Personen, je nach Größe der Systeme), die für die Herstellung und Anwendung von Wiederverwendbarkeit zuständig sind und die Architektur des Kernsystems und der Kerngeschäftsprozesse zu gestalten haben.

Systemanalytiker, Anwendungsdesigner und Entwickler benutzen die gleichen Werkzeuge und Methoden, um die Reibungsverluste zwischen den verschiedenen Projektphasen so gering wie möglich zu halten. Durch Einsatz moderner Modellierungs- und Programmiertechniken wie

- objektorientierte Analyse und Design,

- regelbasierte und Constraints-basierte Wissensverarbeitung, sowie

- Geschäftsprozeßmodellierung mit grafischen Editoren

verlagert sich die Anwendungsentwicklung mehr und mehr in Richtung deskriptiver und deklarativer Programmierung. Der Entwickler beschreibt mehr das "Was" anstelle das "Wie" der Lösung. Die Implementierung kann mehr und mehr durch generative Systeme, Konfiguratoren und Simulatoren abgelöst werden.

Teams, denen diese Ressourcen nicht zu Verfügung stehen, sollten mit Beratungshäusern zusammenarbeiten. Deren Erfahrung sollte in der Startphase der Projekte dann auf das eigene Projektteam durch Coaching-Maßnahmen übertragen werden. Durch konsequentes Anwenden dieser Methodik kann dann im überschaubaren Zeitrahmen von wenigen Monaten bis Jahren sichergestellt werden, daß auch in sehr großen Projekten die Produktivität noch um Größenordnungen gesteigert werden kann. Aus mehreren großen Projekten liegen bereits Erfahrungen vor, daß nicht nur ein durchschnittlicher Produktivitätsgewinn von Faktor zehn, sondern in Bereichen wie der Vorgenerierung der Anwendung nachweisebare Steigerungen um Faktoren 100, 1000 und 10000 erreichbar sind.

ANGEKLICKT

Wie lange wird man es sich noch leisten können, Standardsoftware konventionell zu erstellen? Nicht mehr allzulange. Anders als vielleicht noch vor 20 bis 30 Jahren gibt es heute in vielen Bereichen große Softwaresysteme, die man der Standardsoftware zurechnet. Wer wettbewerbsfähig werden möchte oder bleiben will, sollte schon damit begonnen haben, objektorientiert zu entwickeln. Dies nämlich ist Voraussetzung für einen hohen Grad an Wiederverwendbarkeit und für eine neue Art der Softwareentwicklung, die hier näher vorgestellt wird: Generierung von Standardsoftware auf Basis von Referenzmodellen.

* Hermann Bense ist Geschäftsführer der Nexus, Gesellschaft für wissensverarbeitende Systeme mbH, Dortmund.