Programme von der Stange gelten als Ultima ratio gegen Anwendungsstau und Kostenexplosion. Die Hoffnungen werden jedoch oft genug enttaeuscht. Zudem koennten neue Techniken der Software- Entwicklung das Zeit- und Geld-Argument fuer Standardsoftware ueber kurz oder lang entkraeften. Johann Baumeister* erlaeutert, wieso.

Bis in die 80er Jahre hinein war der Software-Einsatz durch Individualprogrammierung gekennzeichnet. Dann kehrte sich der Trend um - hin zur Standardsoftware. Entscheidend fuer den vermehrten Einsatz der Loesungen von der Stange war der Kostenaspekt. Beigetragen hat aber auch der ueber Jahre angewachsene Anwendungsstau.

Auf der Seite der immer haeufiger eingesetzten PCs wurde dieser Prozess durch den im Vergleich zur Individualprogrammierung auf Grossrechnersystemen geradezu laecherlich geringen Preis der Standardprogramme verstaerkt.

Wiederaufleben der Individualprogramme

Die Hoffnung, auf der Basis von Standardsoftware ohne grossen Installations- und Konfigurationsaufwand massgeschneiderte Loesungen zu schaffen, erwies sich jedoch haeufig als truegerisch. Die Konfiguration fuer die spezifischen Benutzerbelange entpuppte sich als muehsam und zeitaufwendig. Zudem wird - im Gegensatz zur traditionellen Inhouse-Entwicklung - bei Standardprodukten und deren Implementierung oft ausschliesslich auf externes Know-how zurueckgegriffen. Daraus ergibt sich eine neue Abhaengigkeit.

Standardprodukte decken Standardbelange ab und lassen sich nur mit extremen Anstrengungen oder mit einem gewissen Overhead auf unternehmensspezifische Belange abstimmen. Darueber hinaus erzwingen sie teilweise einen bestimmten Ablauf der Geschaeftsfaelle, der mit den Programmroutinen konform zu gehen hat.

Kundenorientierte Dokumente (Angebote, Abrechnungen, Exposes, personifizierte Mailings etc.) werden kuenftig vermehrt auf die Integration von Daten (Text, Tabelle, Grafik) setzen. Damit gewinnen Verbunddokumente (Compound Documents) an Bedeutung. Sie lassen sich mit Standardloesungen kaum abdecken.

Fuer ein erneutes Wiederaufleben der Individualloesungen spricht aber noch ein anderes Kriterium: Je mehr sich das Produktangebot der Unternehmen aehnelt, desto hoeher ist der Stellenwert, den die individuelle Verpackung durch Tarife, Marketing etc. geniesst. Als aktuelles Beispiel sei auf die derzeit gueltigen Bedingungen der Service-Provider fuer Funktelefondienste (Handies) hingewiesen: Sollten die Kunden jemals den Ueberblick ueber den Angebots- Dschungel gewinnen, so muessen die Bedingungen eben neu festgelegt werden - mit entsprechend adaptiver Software.

Wie eingangs erwaehnt, wird der Einsatz von Standardsoftware vor allem mit Preisvorteilen und kurzfristiger Verfuegbarkeit begruendet. Doch beide Argumente koennten ueber kurz oder lang relativiert werden - in dem Masse, wie sich neue Techniken der individuellen Software-Entwicklung durchsetzen. Unter dem Sammelbegriff Rapid Application Development (RAD) versprechen moderne Softwarewerkzeuge kuerzere Entwicklungszeiten und damit auch geringere Kosten.

Wenn RAD nichts weiter bedeuten wuerde als eine beschleunigte Entwicklung des Applikationscodes, so waere ihr Nutzen recht beschraenkt. Anders sieht es aus, wenn dieser Ansatz den kompletten Zyklus der Software-Entwicklung mit einbezieht. In diesem Fall resultiert daraus ein beachtlicher Zeit- und Effizienzgewinn.

Der vollstaendige Prozess deckt die Bereiche Problemanalyse, Design, Programmierung (Codierung), Tests mit Fehlersuche, Einweisung der Benutzer, Dokumentation, Software- und Konfigurations-Management sowie die nachfolgende Wartung beziehungsweise Weiterentwicklung ab.

Die Analyse des Anwendungs- oder Kundenproblems laesst sich vereinfachen und beschleunigen, indem auf CASE-Tools zurueckgegriffen wird. Viele der angebotenen Softwarewerkzeuge sind mittlerweile in der Lage, aus dem Design Skelette von Programmen oder SQL-Scripts zum Erzeugen der Datenbank abzuleiten. Dieser Vorgang sollte sich jedoch auch umkehren lassen. Wegen der gewaltigen Mengen vorhandener Datenbestaende und Anwendungen ist Reverse Engineering meist der einzig gangbare Weg. Im Idealfall bietet die Software-Umgebung die Moeglichkeit, sowohl in der Modelldarstellung als auch in der Implementierung zu veraendern und zu tunen.

Eine Loesung dieser Art bietet beispielsweise die bidirektionale Bruecke zwischen dem CASE-Tool Silverrun und dem Entwicklungswerkzeug Power Builder. Um eine Online-Synchronisation zwischen den beiden Tools zu ermoeglichen, greift Silverrun via ODBC auf das Repository von Power Builder zu und tauscht mit diesem Modellinformationen aus. Zudem enthaelt die Bridge-Software ein Reverse-Engineering-Modul.

Als weiteres Beispiel soll Team Windows von Gupta dienen. Das Tool ergaenzt SQL Windows um Funktionen fuer die Multiuser-Entwicklung im Team und fuer das Projekt-Management. Mit Hilfe des Team-Windows- Link, den das Third-Party-Werkzeug "Erwin" bietet, lassen sich die Datenmodelle einschliesslich der Beschreibungen von Tabellen, Feldern und Beziehungen in das Repository uebertragen.

Laufzeitprobleme bei den 4GL-Tools

Mit Sprachen der dritten Generation (Cobol, C etc.) ist RAD kaum zu verwirklichen. Mehr Erfolg ist hier den Vertretern der naechsten Generation beschieden. Sie nehmen dem Entwickler haeufig einen Grossteil der muehevollen Kleinarbeit ab und erlauben es ihm, sich mit dem eigentlichen Applikationsproblem auseinanderzusetzen. Allerdings haben sie gegenueber den Drittgenerationssprachen mit Laufzeitnachteilen zu kaempfen.

Als Mittelweg bietet sich an, ein Tool der vierten Generation zu verwenden, das seinerseits als Codegenerator fuer schnellere Umgebungen, beispielsweise fuer C, dient. Fuer einen schnellen Prototyp ist es sinnvoll, den Programmcode zu interpretieren oder aber P-Code zu erzeugen. Die endgueltige Programmversion hingegen wird besser in maschinennaeheren Code uebersetzt.

Aber auch Programmhilfen wie Assistenten oder Agenten koennen - im richtigen Kontext eingesetzt - hilfreich sein. Dies gilt zumindest dann, wenn sich die erzeugten Programmteile von Hand weiterbearbeiten und optimieren lassen.

Ein anderer Weg der Codeerzeugung besteht in der Aufteilung des Anwendungscodes auf kleine Einheiten, wie sie in der objektorientierten Programmierung durch Objekt- und Klassenbildung ueblich ist. Welche Moeglichkeiten in dieser Vorgehensweise stecken, haben die Visual Basic Extensions (VBXe) beispielhaft aufgezeigt. Sie werden als Codemodule angeboten und lassen sich ohne grossen Aufwand direkt in eigene Anwendungen integrieren. Schnittstellen sind mittlerweile in den neueren Releases vieler Entwicklungswerkzeuge enthalten. VBX-Module sind jedoch auf 16- Bit-Code beschraenkt und weisen systembedingte Schwaechen auf, so beispielsweise das Fehlen von Vererbungsmoeglichkeiten. Deshalb hat der Anbieter Microsoft bereits im vergangenen Jahr einen Nachfolger - OLE Custom Control (OCX) - vorgestellt.

Und wieder zeigt sich, dass die Software-Industrie bereit ist, das Konzept durch Loesungskomponenten zu unterstuetzen. Ob VBX, OCX oder ein aehnlicher Ansatz - vom Standpunkt der schnellen Anwendungsentwicklung tut sich hier ein durchaus interessanter Weg auf. Dieses Konzept ermoeglicht RAD durch Integration bestehender Codeteile. Sollte sich spaeter herausstellen, dass Aenderungen notwendig sind oder die Laufzeit reduziert werden muss, laesst sich das betreffende Modul herausloesen und beispielsweise durch C-Code ersetzen.

Stueckweise zur kompletten Anwendung

Die derzeit fortschrittlichste RAD-Auspraegung stellt die Componentware dar. Hinter diesem Terminus technicus verbirgt sich das Konzept, Anwendungsloesungen durch eine Kombination von Softwarebausteinen zu erstellen.

Wie weit dieses Konzept der Modularisierung bereits vorangeschritten ist, zeigt beispielsweise der Software-Anbieter Heiler Software. Das Unternehmen liefert unter anderem ein komplettes Textverwaltungssystem als einen Baustein, der dazu bestimmt ist, in Benutzeranwendungen integriert zu werden. Nach Herstellerangaben umfasst das Modul nicht weniger als 50000 Zeilen Sourcecode.

Auch die traditionellen Hersteller von Entwicklungswerkzeugen bemuehen sich neuerdings, in ihren Produkten den Komponentenansatz zu verfolgen. Powersoft liefert unter der Bezeichnung

"Component Pack" zwei Module mit den Funktionen Kalkulation ("Formula One") und Rechtschreibpruefung ("Visual Speller"). Gupta realisiert sein "Quick Objects" genanntes Konzept durch ein Component-Development-Kit namens "SQL Windows CDK".

Waehrend die OCXe auf Windows und Einplatzsysteme zielen, konzentrieren sich aequivalente Loesungen fuer Unix-Netze auf die Common Object Request Broker Architecture (Corba), die von der OMG definiert und von vielen Software-Anbietern implementiert wurde. Wenn diese Technik konsequent eingesetzt wird, lassen sich auf diese Weise ebenfalls Benutzeranwendungen durch Integration und Kombination von definierten Softwaremodulen zusammensetzen.

Als Anwendungsbereiche fuer solche Softwarebausteine bieten sich vor allem Client-Server-Systeme an. Denkbar ist etwa eine Abrechnungssoftware, die mit Hilfe eines Kalkulationsbausteins und einer integrierten Grafikkomponente, ergaenzt durch ein Textmodul fuer Projekt- oder Produktbeschreibungen, erstellt wurde.

Hier zeigen sich jedoch gleichzeitig die Grenzen dieser Technik. In Umgebungen, die aufgrund ihres Datenvolumens und der Laufzeiten dedizierte Grossrechnersysteme erfordern, ist der Einsatz von Komponentensoftware derzeit nicht empfehlenswert.

*Johann Baumeister arbeitet als Berater und Systemanalytiker in Muenchen