Phasenmodell ist kein Garant für Wirtschaftlichkeit:

Auf die Installation folgt oft der Kostenschock

13.01.1984

Die hochgehaltene Welt der Phasenkonzepte gerät zunehmend unter Beschuß. Verschanzen sich doch die Software-Ingenieure bei der Durchführung ihrer Projekte nicht selten hinter dem geordneten Rahmen ihres Modells. Schwierigkeiten - bei der Anforderungsdefinition bereits erahnt - werden jedoch im Vertrauen auf die eingesetzte Methodik so lange unterdrückt, bis sie sich nach der Programminstallation als Katastrophe äußern. An der propagierten Wirtschaftlichkeit der Konzepte scheiden sich denn auch die Geister. Die Autoren dieses Beitrages üben Kritik am Phasenmodell.

Als organisatorischer Rahmen für die Durchführung von Softwareprojekten wird in der Softwaretechnik generell ein Vorgehen in Phasen empfohlen, wobei jede Phase als Endergebnis ein Dokument hat, das als Grundlage für die nächste Phase dient. Es gibt in der Literatur mehrere in etwa gleichwertige Vorschläge für eine phasenorientierte Projektorganisation.

Als Ausgangspunkt werden wir uns auf das in Abbildung 1 dargestellte Phasenmodell beziehen.

In Abbildung 1 bedeutet das Rechteck eine Phase und die Ellipse ein Dokument. Ein Pfeil von Kästchen zu Kringel bedeutet, daß das Dokument als Ergebnis aus der vorangehenden Phase entsteht, ein Pfeil von Kringel zu Kästchen bedeutet, daß das Dokument vor Beginn der darauffolgenden Phase vorliegen sollte.

Da wir uns hier vor allem für eine Nahtstelle zwischen DV-Systemen und Benutzerorganisation interessieren und die Terminologie bei einzelnen Anwendern unterschiedlich ist, wollen wir die Anfangsphasen und Basisdokumente kurz erklären.

Wesentlich ist die Abgrenzung zwischen der Anforderungsdefinition, die beschreibt, welche Aufgaben der Benutzerorganisation durch das System unterstützt werden sollen, und der funktionellen Spezifikation, die eine Beschreibung der Systemfunktionen und der verwendeten Basismaschine enthält, sowie eine Stellungnahme, inwieweit die Systemfunktionen den gestellten Anforderungen gerecht werden.

Ebenso wesentlich ist die Forderung, daß das definierende Dokument für die Softwareherstellung eine funktionelle Spezifikation im obigen Sinne sein soll und nicht eine Entwurfsspezifikation, die bereits die Zerlegung eines Systems beschreibt (Moduln und Schnittstellen). In der Praxis werden diese Abgrenzungen durchaus nicht immer strikt eingehalten. So enthält ein Pflichtenheft meistens eine Mischung aus Anforderungen und Lösungen, und die Spezifikation wird häufig mit der Entwurfsspezifikation gleichgesetzt. Da sich die Forschung vornehmlich mit formalen Methoden und sehr viel weniger mit den Inhalten und der sinnvollen Verwendung von Dokumenten auseinandersetzt, wird auch in der Literatur häufig kein sauberer Trennstrich gezogen.

Anforderungsdefinition und funktionelle Spezifikation beziehen sich auf verschiedene semantische Ebenen und haben eine unterschiedliche Struktur. Zu einer Anforderung gibt es in der Regel ein ganzes Spektrum von DV-Lösungen. Die Annahme, man könne die Lösung quasi automatisch aus den Anforderungen ableiten, ist daher irreführend und gefährlich. Die funktionelle Analyse dient zur Auswahl der Systemfunktionen auf der Grundlage der gestellten Anforderungen. Dabei sind zu berücksichtigen:

- die Ergebnisse einer Durchführbarkeitsstudie, die gerätebezogene und wirtschaftliche Aspekte miteinbezieht, sowie

- ergonomische und arbeitspsychologische Gesichtspunkte, die die Auswahl von Systemfunktionen wesentlich beeinflussen.

Das in der funktionellen Spezifikation festgehaltene Ergebnis ist häufig ein Kompromiß.

Die funktionelle Spezifikation ist die Arbeitsgrundlage für die Softwareproduktion. Sie hat das Basisdokument für Entwurf, Programmierung und Test. Sie ist auch die Grundlage für die Schulung und Einarbeitung der Benutzer. Idealerweise sollte sie daher dem Hersteller ein berechnungsorientiertes Modell des gewünschten Programmes und dem Anwender ein anwendungsorientiertes Modell desselben Programmes geben. In der Praxis fallen die beiden Modelle häufig in einer teilweise formalisierten Prosadarstellung zusammen.

Auf die übrigen Phasen und Dokumente gehen wir nicht explizit ein.

Das Phasenmodell für die Softwareproduktion wurde aus den folgenden Gründen eingeführt:

- Es liefert vertragliche Grundlagen für die Softwareentwicklung in Form von Dokumenten.

- Es definiert Zwischenergebnisse im Herstellungsprozeß.

- Es ermöglicht eine Groborientierung für die Terminplanung und Aufwandschätzung.

Diesen Zielen wird das Phasenmodell durchaus gerecht. Es stellt jedoch, wie alle Autoren immer wieder betonen, die Wirklichkeit der Softwareentwicklung in idealisierter Form dar. Es wird zwar ausdrücklich die Möglichkeit eingeräumt, aus einer späteren Phase in eine frühere zurückzugehen, etwa um Fehlentscheidungen zu korrigieren, aber diese Rückgriffe werden durch das Modell nicht nahegelegt. Ganz im Gegenteil legt das Pasenmodell eine inflexible Vorgehensweise nahe, denn bei einer engen Terminplanung werden Rückgriffe so wenig wie möglich durchgeführt. Wichtig Annahmen des Phasenmodells sind:

- daß alle wesentlichen Anforderungen von vornherein ermittelt werden können und dann feststehen,

- daß umfangreiche Dokumente zur Verständigung über die Software zwischen Herstellern und Benutzern ausreichen,

- daß ein System einmal hergestellt und danach gewartet wird, anstatt von vornherein eine Folge von Systemversionen anzustreben.

Abbildung 2 verdeutlicht, daß bei der Herstellung von Software, die in die Arbeitsabläufe von Menschen eingebettet werden soll, sich jede dieser Annahmen als problematisch erweist:

das Phasenmodell ermutig eine defensive Haltung von Softwareentwicklern und Benutzern. Ernste Schwierigkeiten, die man bei der Problemanalyse bereits erahnt, werden solange unterdrückt, bis sie sich nach der Installation des Systems als Katastrophe äußern.

Kommunikation zwischen Herstellern und Benutzern ist nur in den Anfangsphasen eingeplant. Zu diesem Zeitpunkt ist sie aber in der Regel unverläßlich. Die Benutzerorganisation hat zwar eine sorgfältige Ist-Analyse gemacht und ein Soll-Konzept entwickelt, aber dieses bezieht sich notgedrungen auf Arbeitsvorgänge, die mit Hilfe der zu entwickelnden Software durchzuführen sind, die also noch niemand im einzelnen kennt. Der Softwarehersteller sieht sich nur für die Ermittlung der Durchführbarkeit der von ihm vorgeschlagenen Lösung kompetent, setzt aber voraus, daß dem Anwender der Einsatzkontext genau bekannt ist. Beim Unterzeichnen der funktionellen Spezifikation - der vertraglichen Grundlage für die Softwareherstellung - geht der Anwender häufig ein großes Risiko ein.

Sobald die funktionelle Spezifikation akzeptiert worden ist, ist der Benutzer am Herstellungsprozeß nicht mehr beteiligt. Natürlich findet noch nach Bedarf eine Kommunikation mit dem Benutzer statt. Damit aber das Entwicklungsteam bei der Arbeit nicht gestört wird, läuft diese häufig über die Projektleitung oder über den Vertrieb. Von dieser Kommunikation abgeschnitten, trifft das Entwicklungsteam anhand der vorliegenden Basisdokumente eine Reihe von Einzelentscheidungen, deren Auswirkungen es nicht übersieht. Bei großen Programmsystemen dauern die Phasen Entwurf und Programmierung sehr lange, was die Wahrscheinlichkeit von Mißverständnissen erhöht, weil die nach dem Phasenmodell erarbeiteten Dokumente keine für den Benutzer auswertbaren Zwischenergebnisse liefern.

Aus softwareinternen Gründen ergibt sich in der Regel spätestens beim Testen die Notwendigkeit zu Rückgriffen in frühere Phasen. Rückgriffe dieser Art sind beim Phasenmodell zwar ausdrücklich vorgesehen, können aber aus Termingründen häufig nicht sorgfältig genug erfolgen.

Etwa zur gleichen Zeit beginnen die Anwender die Auswirkungen der Softwareentscheidung auf ihre Arbeitsabläufe zu übersehen, was in der Regel zu Änderungswünschen führt.

Je weiter die Softwareentwicklung fortgeschritten ist, desto häufiger werden Änderungswünsche mit dem Kommentar "Ja, aber es kostet mehr" abgewiesen. Wegen der Untergliederung der Softwareentwicklung in die eigentliche Produktion und die nachfolgende Wartung, die meist getrennt budgetiert werden und in denen in der Regel unterschiedliche Menschen beschäftigt sind, liegt zwar zum Zeitpunkt der Installation ein Programm vor, aber es zwingt die Benutzer möglicherweise zu unerwünschten Arbeitsabläufen und kann nicht mehr mit vertretbarem Aufwand geändert werden.

Wir haben hier einen Widerspruch aufgedeckt:

- Auf der einen Seite fordert die Softwaretechnik aus guten Gründen, daß festgelegt werden soll, was gemacht wird, bevor man festlegt, wie es (programmtechnisch) gelöst wird.

- Auf der anderen Seite können Anforderungen an das DV-System mißverstanden sein, ist das Softwareumfeld veränderlich, und letztlich verändert das DV-System bei seinem Einsatz selbst sein Umfeld, so daß es zu neuen Anforderungen führt.

Dieser Widerspruch kann nur überwunden werden, wenn man ihn anerkennt. Dazu gehören eine Vorgehensweise in Schritten, die für den Benutzer auswertbare Zwischenergebnisse liefert, und die Einplanung von tiefgreifenden Revisionen, um strukturellen Verschlechterungen durch Änderungsarbeit entgegenzuwirken und um veränderte Anforderungen zu berücksichtigen.

*Dr. Christiane Floyd ist Professorin für Softwaretechnik an der Technischen Universität Berlin; Reinhard Keil ist wissenschaftlicher Mitarbeiter in dem Institut.

Der Beitrag wurde entnommen aus: Peter Mambrey/Reinhard Oppermann (Hrsg.): Beteiligung von Betroffenen bei der Entwicklung von Informationssystemen; Campus-Verlag, Frankfurt/Main, 1983. Der Nachdruck erfolgte mit freundlicher Genehmigung des Verlages.