Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.05.1996 - 

Thema der Woche/Die "Steinzeit" der Software-Entwicklung ist ueberwunden

RAD - bestaendig ist nur eins: der Wandel

Eine Sehnsucht so alt wie die Software-Entwicklung: Anwendungen sollen schneller entstehen und praeziser den aktuellen Anforderungen entsprechen. Die weltweit wachsende Marktdynamik bringt ein neues Kriterium ins Spiel. Heute verlangen die Anwender, dass sich die Softwaresysteme in kuerzester Zeit an veraenderte Situationen - neue Zielgruppen, Produkte und Marketing- Strategien - anpassen lassen. Die in den 70er Jahren entwickelten Grundlagen des Software- Engineering koennen diesen Notwendigkeiten nicht genuegen. Das "Wasserfallmodell" ging davon aus, dass die Stufen Analyse, Design, Test und Implementierung in genau dieser Reihenfolge zu betreten sind und jede neue Phase erst dann begonnen wird, wenn die vorhergehende abgeschlossen ist.

Die Folge: Das einmal festgelegte Progammdesign wird genau so und nicht anders implementiert - selbst wenn sich die Beduerfnisse der Anwender inzwischen geaendert haben. Bei den ueblichen Entwicklungsprozessen von mehreren Jahren Dauer ist das ein Unding. Kein Wunder, dass sich dieser - in der Theorie einleuchtende - Ansatz in der Praxis kaum jemals bewaehrt hat.

Zeitgleich mit dem Siegeszug der PCs wurden in vielen Software- Abteilungen die nach ingenieurmaessigen Grundsaetzen definierten Entwicklungsstrategien aufgeweicht. Den Benutzern war nicht mehr zu vermitteln, dass sie monate- wenn nicht jahrelang auf jede Applikation warten sollten.

Die Entwickler wandten sich den sogenannten Client-Server-Tools zu - Produkten wie "Powerbuilder" von Powersoft (uebernommen von Sybase) oder "SQL Windows" von Gupta (kuerzlich umbenannt in "Centura"). Diese fuer die Client-, sprich: PC-Seite der Anwendung konzipierten Softwarewerkzeuge stellen vorgefertigte Bildschirmobjekte und Datenbankzugriffe zur Verfuegung, mit deren Hilfe DV-Profis relativ schnell lauffaehige Programme erstellen koennen.

Allerdings haben diese Werkzeuge auch Nachteile. Einer davon ist der schlappe Durchsatz der Applikationen, die in solchen Programmiersprachen der vierten Generation (Fourth Generation Languages = 4GLs) codiert sind.

In juengster Vergangenheit hat sich jedoch eine neue Kategorie von Entwicklungs-Tools herausgebildet. Diese Produkte machen den Applikationen Beine, weil sie keinen eigenen Code, sondern 3GL- Befehle erzeugen. Ausserdem sind sie relativ billig und so benutzerfreundlich, dass sogar die geuebteren unter den Endanwendern damit umgehen koennen. Prominentester Vertreter dieser Fraktion ist "Visual Basic" (VB) von Microsoft. Als ernstzunehmender Konkurrent hat sich neuerdings "Delphi" von Borland etabliert, eine grafische Programmierumgebung auf der Basis der Compiler-Sprache Object Pascal. All diesen Tools ist gemeinsam, dass sie entweder eigene oder an Microsofts OLE Custom Controls (OCX) orientierte Komponenten integrieren. Die Moeglichkeit, auf solche Softwarebausteine zuzugreifen, erspart den Entwicklern muehevolle Kleinarbeit.

Trotz - oder gerade wegen - dieses Produktivitaetsvorteils haftet den Programmiersprachen der vierten (oder fuenften?) Generation ein Makel an: Je schneller die Entwicklung, desto geringer die Qualitaet, so das weitverbreitete (Vor-)Urteil.

Tatsache ist, dass die Analysephase beim Rapid Application Development stark verkuerzt wird. Das heisst aber keineswegs, dass sie nicht stattfaende. Im Gegenteil: Mit objektorientierten Analysewerkzeugen lassen sich bereits Klassenbibliotheken fuer Client-Server-Werkzeuge generieren. Allerdings raeumen Marktkenner wie Wolfgang Martin von der deutschen Meta Group ein, dass die RAD- Tools erst in wenigen Anwenderunternehmen als Teil eines definierten Entwicklungsprozesses gesehen und eingesetzt werden.

Einig sind sich die Software-Analysten auch darin, dass diese Werkzeuge leicht an ihre Grenzen stossen, wenn es darum geht, komplexe und transaktionsintensive Systeme zu erstellen. Hier plaediert beispielsweise Michael Bauer, Geschaeftsfuehrer der Informatik Training GmbH, Radolfzell, fuer erprobte 4GL-Systeme wie "Natural" von der Software AG oder komponentenbasierte Produkte wie "Dynasty". In Frage kommen sicher auch der Dy- nasty- Konkurrent "Forte" sowie objektorientierte Umgebungen auf Basis von Smalltalk oder C++.

Die Tool-Frage ist nach Ansicht der Software-Experten jedoch nachrangig. RAD haengt nicht vom eingesetzten Produkt ab, sondern von der Art und Weise, wie die Software-Entwicklung in Angriff genommen wird, so lautet der Tenor. Die RAD-Vorgehensweise manifestiert sich vor allem in zwei Faktoren: dem iterativen Entwicklungsprozess und der Integration der Fachabteilungen. Die Grundidee besteht in einem Gegenentwurf zum Wasserfallmodell. Analyse, Design, Implementierung und Test werden als Teile eines fortlaufenden Prozesses begriffen, der sowohl Vorwaerts- als auch Rueckwaertsbezuege zulaesst.

In der Praxis sieht das folgendermassen aus: Zusammen mit den spaeteren Benutzern ermitteln die Entwickler - beispielsweise in einem gemeinsamen Workshop - die Anforderungen, denen die Applikation gerecht werden soll. Ihre Ideen fuer die Umsetzung uebertragen die Softwareprofis dann in einen Prototypen. Oft reicht es, diesen ersten Entwurf in Form von Bildschirmmasken zu realisieren.

Der Loesungsvorschlag wird den Fachabteilungen zur Begutachtung ueberlassen. Deren Feedback entscheidet darueber, in welche Richtung das Rumpfsystem weiterentwickelt wird. Die Tests erfolgen parallel zur Entwicklung.

Bei komplexen Systemen ist es sinnvoll, fuer jede Erweiterung beziehungsweise Aenderung erneut in die Analyse und das Design einzusteigen. Der Entwicklungsprozess aehnelt also nicht mehr einem Wasserfall, sondern einer Spirale. Nach Auffassung des Marktforschungsunternehmens Meta Group werden hier die Grenzen des Rapid Application Development ueberschritten, und es beginnt das Reich einer neuen, komponentenbasierten Art des Computer Aided Software Engineering (CASE). Aber letztlich ist das wohl eine Frage der Definition.

Die unkonventionellste Idee des RAD ist das Timebox-Development. Etwas flapsig ausgedrueckt, bedeutet dieser Begriff: Die Anwendung gilt als fertig, wenn die fuer das Projekt vorgesehene Zeit abgelaufen ist (oder andere Stop-Kriterien greifen). Wenn das System nicht in einer Linie, sondern quasi in konzentrischen Kreisen entwickelt wird, ist es moeglich, den Prozess an einer beliebigen Stelle abzubrechen und trotzdem eine mehr oder weniger funktionstuechtige Applikation mitzunehmen - spaetere Weiterentwicklung nicht ausgeschlossen.

Die Vorgehensweise des RAD klingt chaotisch, und sie ist es auch - in einem positiven Sinn. Sie erlaubt kreative Loesungen, weil sie sich nicht von der irrigen Annahme leiten laesst, jede Anforderung an ein System waere von vornherein planbar. Um dennoch den Ueberblick zu behalten, sollten die Verantwortlichen - zumindest bei groesseren Entwicklungsprojekten - auf so konventionelle Einrichtungen wie einem Projekt-Management und einer Versionskontrolle bestehen. Ist geplant, selbstentwickelte Objektklassen wiederzuverwenden, so bedarf es zusaetzlichen Organisationsaufwands.

Darueber hinaus gibt es auch auf einer unternehmensuebergreifenden Ebene Bemuehungen, das Chaos in geordnete Bahnen zu leiten. So haben unter anderem die Anwenderunternehmen British Airways und British Telecom sowie die IT-Anbieter IBM und ICL eine "Dynamic Systems Development Method" (DSDM) erarbeitet, die ein methodisches Rueckgrat fuer das Rapid Application Development bilden soll.

Fallstudie I: RWG beendet den Sprachenstreit

Dass der Prototyp nicht unbedingt als Grundlage fuer den spaeteren Programmkern dienen muss, zeigt das Beispiel des Rechenzentrums Wuerttembergischer Genossenschaften (RWG) in Stuttgart. Dort uebernahm Ute Buerkle, heute Bereichsleiterin Produktplanung, vor fuenf Jahren die Projektverantwortung fuer die Entwicklung eines PC- basierten Workflow-Systems.

Neun Monate lang versuchten Buerkle und ihr Team, die gewuenschte Funktionalitaet konventionell zu programmieren. Dann war ihnen klar, dass das System auf diese Weise nicht flexibel genug werden wuerde.

Aus Performance-Gruenden (und weil es damals noch keine ausgereifte Smalltalk-Umgebung zu kaufen gab) beschloss die Projektleiterin, einen Neuanfang mit C++ zu wagen. Doch der erste Loesungsvorschlag, den die Anwender an ihren Arbeitsplaetzen erproben, wird nach wie vor in der Smalltalk-Umgebung "Parts" von Parcplace Digitalk realisiert - laut Buerkle deshalb, weil die Interpreter-Sprache einfacher und schneller zu handhaben ist als C++.

Fallstudie II: Gerling-Konzern erprobt das Timebox-Development

Gerd Franken wagte den Sprung ins kalte Wasser. 1991 beschloss sein Arbeitgeber, der Koelner Gerling-Konzern, innerhalb eines Jahres einen voellig neuen Geschaeftsbereich aufzubauen. Das Assekuranzunternehmen wollte so schnell wie moeglich mit einem eigenen Angebot auf dem Markt fuer private Krankenversicherungen praesent sein.

Die steigende Nachfrage der Kunden hatte dem Versicherer klargemacht, dass er ein hochprofitables Marktsegment brachliegen liess. "Fuer konventionelle Methoden war da keine Zeit", erinnert sich Franken, heute Abteilungsleiter bei der Gerling-Konzern Informatik GmbH (GKI).

Mit einem kleinen Team aus Entwicklern und Benutzern sowie dem brandneuen Smalltalk-Werkzeug "Enfin" ging der Softwareprofi daran, ein Krankenversicherungs-Geschaeft abzubilden. Franken bezeichnet dieses Unterfangen heute selbst als "waghalsig". Aber Gerling habe keine andere Wahl gehabt: "Entweder Sie gehen das Risiko ein, oder Sie machen das Geschaeft nicht."

Wie vorher vereinbart, wurde das System Anfang 1992 an die neue Gerling-Krankenkasse uebergeben, die nach Beteilungen durch den Deutschen Herold und die Deutsche Bank heute als Globale Krankenversicherung AG (GKI) firmiert. Verglichen mit dem aktuellen Stand war die Anwendung, so Franken, damals erst zu einem Viertel fertiggestellt. Aber sie funktionierte. Und wegen ihrer auf Erweiterbarkeit ausgelegten Architektur ist sie so flexibel, dass sie auch kuenftig weiter verfeinert werden kann.

Kriterien fuer RAD

Prototyping-Ansatz: Grundlage der RAD-Entwicklung ist ein vorzeigbarer Prototyp - egal, ob er nur Bildschirmmasken oder bereits rudimentaere Funktionen enthaelt.

Iterative Entwicklung: Auf der Basis eines Programmkerns laesst sich die Anwendung schrittweise verfeinern. Die Entwicklungszyklen werden mehrfach und in beliebiger Richtung durchlaufen.

Anwenderintegration: Das Projektteam setzt sich aus Softwareprofis und Benutzern zusammen. Letztere entscheiden ueber jede Erweiterung und Aenderung der Applikation.

Timebox-Development: Das anfangs festgelegte Einfuehrungsdatum ist verbindlich, auch wenn das System zunaechst noch nicht alle Anforderungen abdeckt.

Wiederverwendung: Fertige Komponenten und Klassenbibliotheken zu integrieren spart Zeit. Die Wiederverwendung eigener Objekte allerdings muss sorgfaeltig organisiert werden.