Phasenmodelle des Software-Entwicklungsprozesses

Gefragt ist experimentelles und exploratives Vorgehen

31.08.1990

Dr. Heinz-Dieter Knöll ist Professor für Wirtschaftsinformatik im Fachbereich Wirtschaft der Fachhochschule Nordostniedersachsen in Lüneburg. Dipl.-Inf. Alfred Schäfer arbeitet als geschäftsführender Gesellschafter der SES GmbH in Ottobrunn.

Die Realisierung ständig komplexer werdender Systeme erfordert ingenieurmäßiges Vorgehen. Dabei stößt das bisherige vom Individualismus geprägte Vorgehen an seine Grenzen. Typische Erscheinung davon sind mangelnde Qualität und zu geringe Produktivität. Man postulierte als Gegenmaßnahme das Software-Engineering mit den Hauptzielen Verbesserungen der Software-Qualität und Produktivitätssteigerung.

Seit sich Software-Engineering institutionalisiert hat, beschäftigt man sich damit, den Erstellungsprozeß von Softwareprodukten zu analysieren und zu optimieren. Dabei griff man auf Erfahrungen aus realisierten Systemen zurück. Dies waren jedoch Systeme für Back-Office-Anwendungen mit festem, bekanntem Informationsbedarf, stabilen Abläufen sowie Massen- und Routinearbeiten, die zunächst stapelorientiert und zentralisiert organisiert waren. Die daraus gewonnenen Software-Engineering-Erkenntnisse führten zu den bekannten Methoden und Verfahrensmodellen, wie zum Beispiel zum Wasserfall- Phasenmodell (Abbildung 1).

Diesem Phasenmodell folgen die meisten Projekt-Management-Systeme, die zur Zeit am Markt erhältlich sind. Als Idee steht hinter dem Wasserfall-Phasenmodell die Aufteilung des Software-Entwicklungsprozesses in einzelne Phasen, in denen eine schrittweise Verfeinerung der vorherigen Phasen erfolgt.

Üblicherweise wird der Software-Entwicklungsprozeß in vier bis sechs Phasen unterteilte die die unterschiedlichsten Bezeichnungen haben. Das wesentliche Prinzip des Wasserfall-Phasenmodells ist darin zu sehen, daß eine neue Phase erst dann begonnen werden darf, wenn die vorherige vollständig abgeschlossen ist und die in ihr erzeugten Ergebnisse mit denen der Vorphase verglichen wurden. Dieses Vorgehen soll sicherstellen, daß die Vorphase vollständig und richtig verfeinert wurde. Erst nach der Abnahme einer beendeten Phase beginnt eine neue Phase und die Ergebnisse der Vorphase werden weiter detailliert.

Obwohl sich dieses Phasenmodell prinzipell bewährt hat, zeigte sich in der Praxis, daß es bei großen und sehr komplexen Anwendungen nur schwer durchzuhalten ist. Dies liegt daran, daß in den frühen Phasen die Abhängigkeiten der einzelnen Lösungsvorschläge zueinander sich nicht gänzlich offenbaren. Entwickelte man die anfänglich spezifizierten Systeme konsequent nach dem Wasserfall-Phasenmodell zu Ende, würden dabei Systeme entstehen, die entweder nicht lauffähig sind oder die Fachaufgaben nur unzureichend erfüllen. Dabei versuchen die Software-Entwickler, die Bürde der vollständigen und widerspruchsfreien Spezifikation dem Endbenutzer aufladen.

Besonders drastisch werden die Schwächen des Wasserfall-Phasenmodells beim Einsatz von integrierten CASE-Systemen deutlich. Solche Systeme, wie zum Beispiel "Softorg", die den gesamten Software-Lebenszyklus abdecken, haben häufig aus Performance-Gründen für jede Phase eine separate Datenbank. Diese Datenbanken können im Sinne des Software-Lebenszyklus vorwärts ineinander konvertiert werden, um so eine Basis für die nächste Phase zu schaffen. Eine automatische Rückdokumentation der Änderungen in den Datenbanken der vorherigen Phasen ist meist nicht vorgesehen. So wird im Vertrauen auf die CASE-Technologie häufig "Unsinn multipliziert" (Original-Zitat von Harry Sneed).

Mittlerweile haben sich die DV-gestützten Anwendungssysteme dialogorientiert entwickelt. Es blieb jedoch grundsätzlich dabei, Aufgabengebiete aus dem Back-Office-Bereich zu unterstützen. Gleichzeitig wuchs auch das Bedürfnis, aggregierte Informationen aus den operativen Systemen für dispositive Aufgabenstellungen abzuleiten. Der erste Ansatz von Management-Informationssystemen in den 70er Jahren kann als Fehlschlag gewertet werden. Dies lag wohl auch in der fehlenden technologischen Unterstützung für die Entwickler begründet. Gleichwohl resultierte aus diesen Anstrengungen ein Technologieschub auf dem Gebiet der Datenhaltung in Form von weiterentwickelten Datenbanksystemen für übergreifende Datenhaltung statt Insellösungen.

Heute stehen CASE, objektorientierte Programmiersprachen und Sprachen der vierten Generation im Wettstreit, wobei die Qualitätssicherung bei letzteren noch Wünsche offenläßt. Nicht geändert hat sich das Verfahrensmodell, dem auch beim Einsatz dieser Werkzeuge müssen Systeme geplant und modelliert werden.

Insbesondere hat sich der analytische Ansatz, der bei bekannten Problemstellungen, wie es Back-Office-Anwendungen sind, immer weiter verfeinert und ausgeweitet, bis hinzu tief ins Detail gehenden Arbeitsablauf-Vorschriften mit riesigem administrativen und bürokratischem Überbau, der jede zielgerichtete Vorgehensweise erstickt.

Die negativen Erfahrungen bei der Anwendung des Wasserfall-Phasenmodells für sehr große komplexe und neuartige Softwareprojekte veranlaßte Barry Boehm, den wissenschaftlichen Leiter des größten Softwarehauses der USA, dazu, ein alternatives Modell zu entwickeln: das Spiral-Phasenmodell (Abbildung 2). jeder Spiral-Umlauf besteht aus vier Phasen: 1. Erarbeitung von Zielen, Alternativen und Randbedingungen, 2. Bewertung der Alternativen, Bestimmung und Bewertung der Risiken, 3. Entwicklung und Abnahme des Spiral-Durchlaufs, 4. Planung der nachfolgenden Phasen.

In den verschiedenen Durchläufen der Spirale wird das zu erstellende Softwaresystem stufenweise erweitert, bis dann im endgültigen Durchlauf nach einem operationalen Prototyp das Softwaresystem ähnlich wie im Wasserfall-Phasenmodell erstellt wird.

Dieses Phasenmodell hat sich in den USA bereits in der Praxis bewährt. Es läßt sich- immer dann einsetzen, wenn Systeme zu entwickeln sind, bei denen entweder der Betriebsbereich oder das Problem in dem Betriebsbereich neu sind. Für Anwendungssysteme, in denen beides, der Betriebsbereich und das Problemfeld in dem Betriebsbereich, neu sind, erweist sich dieses Phasenmodell zu schwerfällig und zu zäh in der Handhabung. Erst nach der Beendigung einer Phase können korrigierte Konzeptionen erarbeitet werden, die sich dann, aufbauend auf der vorherigen Phase, als Baustein realisieren lassen.

Inzwischen sind aber in den Unternehmen, die schon lange DV einsetzen, die Back-Office-Anwendungen weitgehend abgedeckt. Die Anwender fordern zunehmend Unterstützung im Front-Office-Bereich.

Dieser unterscheidet sich jedoch von der Aufgabenstellung im Back-Office-Bereich ganz erheblich - insbesondere ist er hochdynamisch, da sich die Unternehmen mit ihren Leistungen und Produkten ständig dem Marktgeschehen anpassen müssen. Er ist auch nicht standardisierbar, da sich aus den Leistungen des Front-Office-Bereichs die Individualität und die Marktberechtigung der einzelnen Unternehmen herleiten.

Durch die hohe Dynamik sowie durch die ständigen Änderungen und Neuerungen kann man hier nicht auf fundierte Erfahrungswerte zurückgreifen. Deshalb findet man auch niemanden, der die Aufgabenstellung exakt kennt. Ein stabiler Informationsbedarf und das Beherrschen der Problemstellung sind jedoch Grundvoraussetzungen, um nach einer analytischen Vorgehensweise Systeme zu entwickeln.

Als Antwort auf die Schwierigkeiten, die bei der Anwendung von Wasserfall- und Spiral-Modellen auftreten, wenn Programme entwickelt werden sollen, bei denen sowohl das Problem als auch der Betriebsbereich neu und unbekannt ist, würde von Knöll und Schäfer das Modell der expermentellen, explorativen Software-Entwicklung als Konzept vorgeschlagen.

Dieser Ansatz soll die Grundlage für die nächste CASE-Tool-Generation darstellen. Im ersten Durchlauf sind die sechs Phasen dieses Modells nacheinander abzuarbeiten:

1. Modellieren des Anwendungssystems anhand einer grafischen Sprache gemeinsam, mit dem Endbenutzer, 2. Beschreibung der Masken, Listen und Datenbanken als Prototypen,

3. Beschreibung der Transaktionen, 4. Modellieren der Transaktionen auf Funktionsebene anhand einer grafischen Sprache gemeinsam mit dem Endbenutzer, 5. Beschreibung der Funktionen 6. Test des Prototyps.

Das Modell einer Endbenutzerorientierten grafischen Sprache wird in einer der nächsten Ausgaben vorgestellt werden.

Das Modell der experimentellen, explorativen Software-Entwicklung sieht vor, daß nach dem ersten Durchlauf aller Phasen an jeder beliebigen Stelle wieder eingestiegen werden kann, und zwar in die Modellierung des Anwendungssystems oder der Transaktionen. Aus den erfaßten Daten stellt ein ablauffähiger Prototyp zur Verfügung, der sich auf seine Korrektheit hin testen läßt. Nur eine solche Vorgehensweise kann der Problematik der Anwendungsentwicklung von völlig neuen, hochdynamischen Aufgabenstellungen gerecht werden.

Es ist klar, daß ein solches Vorgehensmodell ausschließlich computerunterstützt ablaufen kann, wobei gewaltige Computerressourcen benötigt werden. Vermutlich wird auch der Entwicklungsaufwand, den das vorgeschlagene CASE-System erfordert, die finanzielle Leistungskraft eines einzelnen Unternehmens übersteigen. So bleibt zu hoffen, daß in Forschungsinstitutionen mit staatlicher Förderung ein solches System erstellt werden kann.

Zusammenfassend ist in Abbildung 3 noch einmal der Einsatzbereich der verschiedenen Phasenmodelle dargestellt. Bei sogenannten Back-Office-Anwendungen, die die Sachbearbeitung im Hintergrund unterstützen, kann das Wasserfall-Phasenmodell auch heute noch Anwendung finden je mehr Neues hinzukommt - entweder auf der Problemseite oder auf der Seite des Betriebsbereichs - empfiehlt sich der Einsatz des Spiral-Modells.

Bei völlig unbekannten Problemen in neuen Betriebsbereichen Müßte mit der experimentellen, explorativen Vorgehensweise das System entwickelt werden.