Mehrere Evolutions-Zyklen führen aus der Software-Krise

Dr. Peter Hruschka ist Leiter der CASE-Beratung bei der GEI, Aachen.

Hier soll gezeigt werden, daß es branchentypische Zeitkonstanten für den Übergang vom wissenschaftlichen State-of-the-Art zur praxisrelevanten Anwendung gibt. Diese soll die Basis für eine Projektion in die Zukunft sein. Also: Mit welchen Zeitverschiebungen muß zwischen heutigem Wissensstand und industriellem Anwendungsstandard gerechnet werden?

Die wesentlichen Tendenzen dabei seien kurz vorweggenommen: Hinsichtlich der Methoden und Werkzeuge wird ein breit angelegter Transfer von der Wissenschaft in die Praxis erfolgen.

Die aus der Literatur bekannten Technologien, die in Pilotprojekten bereits ihre wirtschaftliche Effizienz und technische Funktionsfähigkeit bewiesen haben, werden Eingang in die tägliche Praxis finden.

Das wird auch Auswirkungen auf die Teamstruktur haben. Neben diesen methodischen Schwerpunkten lassen sich vier Tendenzen in der Entwicklung des Managements von Softwareprojekten erkennen: Erstens wird ein evolutionäres Entwicklungsparadigma, wie beispielsweise das von Barry Boehm 1987 veröffentlichte "Spiral-Modell", in dem Software-Entwicklung zyklisch angelegt ist, das bisherige phasenorientierte Modell ablösen.

Die Zyklen der Software-Entwicklung dürfen zweitens kürzer werden. Dabei wird drittens das Gewicht aus Qualitäts- und Kostengründen noch mehr auf die frühen Stadien der Software-Entwicklung verlagert. Und last, but not least wird der Wiederverwendbarkeit eine entscheidende wirtschaftliche Bedeutung zukommen.

Wie wird man an die Probleme konkret herangehen? Die Projektion in die Zukunft und das Herausfinden von Trends läßt sich umso zuverlässiger anstellen, je besser man die Vergangenheit kennt. Daher soll zunächst ein Rückblick auf einige Meilensteine im Bereich von Software-Engineering-Methoden geworfen werden. Auf dieser Grundlage sollen sich Trends der weiteren Entwicklung ergeben.

Zu den Meilensteinen der 70er Jahre zählt die strukturierte Programmierung. 1970 erschien mit der Publikation der Programmiersprache Pascal ein wesentlicher Beitrag auf diesem Gebiet. Etwa fünf Jahre später hat man die Idee der strukturierten Programmierung eine Stufe angehoben und über strukturierten Entwurf gesprochen. Es dauerte weitere fünf Jahre, bis man diese Ideen in die Analysephase übertragen hat. Daraus entstanden Methoden wie strukturierte Analyse und Entity-Relationship-Modellierung.

1982: Nur fünf Prozent arbeiten strukturiert

Was 1970 durch die Programmiersprachen ausgelöst wurde, setzte sich im Abstand von jeweils fünf Jahren beim Entwurf und bei der Analyse als Trend fort.

1982 - zwölf Jahre nach den ersten Publikationen über strukturierte Programmierung - hat Gerald Weinberg in einer weltweiten Untersuchung von über 800 Unternehmen festgestellt, daß nur fünf Prozent der Entwickler wirklich strukturiert arbeiten, und zwar unabhängig von der Programmiersprache. Bemerkenswert ist, daß die untersuchte Gruppe sich freiwillig an der Befragung beteiligt hat und alle Beteiligten sich in dem Glauben wägten, tatsächlich strukturiert zu arbeiten.

Bleiben also 95 Prozent, die nicht strukturiert im eigentlichen Sinne arbeiten. Davon befolgte etwa die Hälfte wiederum einige Regeln.

Bei einem weiteren Fünftel etwa konnte man feststellen, daß die Programme besser beziehungsweise weniger Spaghetti-haft geworden sind. Jedoch immerhin ein Viertel zeigte nicht einmal im Ansatz eine Spur von Strukturierung. Das Ergebnis dieser Untersuchung belegt die Trägheit, mit der hier der Transfer des wissenschaftlichen Know-hows in die Praxis der Programmierer erfolgte.

Es stellt sich jedoch die Frage, an welchen Stellen die größten, Reibungsverluste

in diesem Übertragungsprozeß auftreten. Detaillierteren Aufschluß darüber geben zwei Untersuchungen von Tom DeMarco und Watts Humphrey.

1989: Noch keine Verankerung

Im letzten Jahr hat Tom DeMarco eine Untersuchung zu den Konzepten, gemacht, die Mitte der 70er Jahre in, Design eingeführt wurden.

Die untersuchten Unternehmen in den USA und Europa bildeten dazu Teams von jeweils zwei Programmierern, denen freier Wahl der Programmiersprache die gleiche Aufgabe gestellt wurde. Ziel war herauszufinden, wie das Unternehmen in puncto Qualität und Programmierstil im internationalen Vergleich abschnitt. Bei der Auswertung zeigte sich, daß wesentliche Aspekte einer guten Programmierung beachtet wurden:

Die meisten Programmierer hielten sich an die Konzepte des Lokalitätsprinzips verwendeten kleine, stark gebundene Module und einen strukturierten Code. Andere Prinzipien wie das "lnformation Hiding" und das " Clean Room Development" a la Mills, nach dem nicht erst dem Compiler die Fehlersuche überlassen werden soll, wurden noch nicht so stark beherzigt. Interessanterweise setzten die Programmierer unterschiedliche Denkschemata und unterschiedliche Lösungen für gleiche Problemstellungen ein.

Zur gleichen Zeit untersuchte Watts Humphrey vom amerikanischen Software Engineering Institute, wo Unternehmen bezüglich Qualitätssicherungs-Verfahren, Methoden und Einführung von Verfahren und Projekt-Management stehen.

Die Auswertung der Antworten erfolgte nach fünf Kategorien:

1. Initial:

Die Mitarbeite verwenden eine Art von Ad-hoc-Stil-Methoden, einzelne, unzusammenhängende Werkzeuge. Der Prozeß ist eher noch im Projekt gemanagt und nicht auf Abteilungsebene.

2. Repeatable:

Die Mitarbeiter verwenden Methoden und Verfahren, die im nächsten Projekt wiederholbar sind. Sie sammeln Ergebnisse.

3. Defined:

Im ganzen Unternehmen werden wohldefinierte Vorgehensmodelle wie Analysemethoden, Designmethoden, Programmierstile und Qualitätssicherungsmethoden eingesetzt.

4. Managed:

Im ganzen Unternehmen werden nicht nur qualitativ Methoden eingesetzt, sondern Maßzahlen gebildet: Was bringt der Einsatz der Methoden?

5. Optimized:

Das Unternehmen nützt das Feedback aus Maßzahlen konsequent zur Effizienzsteigerung.

Gute Werkzeuge ohne Systematik eingesetzt

Die meisten Unternehmen befanden sich in dem Ad-hoc-initial-Stadium, wo zwar gute Werkzeuge eingesetzt werden, aber ohne die notwendige Systematik. Das Ergebnis der Studie war, daß Stufe vier und Stufe fünf von keinem Unternehmen erreicht wurden. Stufe drei erreichte fast kein Unternehmen.

Die unterschiedlichen Ergebnisse von Humphrey und DeMarco spiegeln die unterschiedlichen Ausgangssituationen der untersuchten Gruppen wider. Die "DeMarco-Gruppe" rekrutierte sich aus Leuten, die sich freiwillig für Zwei-Tages-Probleme gemeldet hatten. Humphrey hingegen untersuchte das Arbeitsverhalten in Großprojekten. Quintessenz aus beiden Untersuchungen ist, daß auf individueller Ebene bestimmte Entwicklungen zugig verinnerlicht werden können, ohne daß eine breite organisatorische Verankerung vorliegt.

Wie aber werden sich die strukturierten Methoden langfristig auf breiter Front weiterentwickeln? Grundlage für diese Trendaussagen sind die Voraussagen unterschiedlicher Spezialisten zu Kernfragen der strukturierten Methoden.

Bis zum Jahr 2000 wird es erstens zu einer Stabilisierung und Standardisierung der Notationen kommen müssen. Es werden sich Standards etablieren.

Erkennbar ist dieser Trend heute zum Beispiel im Bereich der strukturierten Analyse nach Yourdon/DeMarco. Die Strukturierte Analyse hat sich bereits zu einem De-facto-Standard etabliert. Wenn jemand Datenflußdiagramme zeichnet, orientiert er sich heute schon trotz nationaler Varianten am Stil von Yourdon/DeMarco.

Solche Standards bieten der Industrie Vorteile bei der Ausbildung der Benutzer, aber auch bei der Weiterentwicklung von Systemen.

Bekannte Ideen für neue Anwendungsbereiche

Ein zweiter wesentlicher Trend ist der Transfer bekannter Ideen in neue Bereiche: Nicht nur Analyse von Projekten und Systemen einer Abteilung, sondern abteilungs- oder unternehmensübergreifende Datenmodelle müssen bereits in frühen Stadien erstellt werden, wo es noch um Machbarkeitsuntersuchungen geht.

Dieser Aspekt ist insbesondere aufgrund der zunehmenden Internationalisierung von Konzernstrukturen von entscheidender wirtschaftlicher Bedeutung.

Als drittes läßt sich über die Software-Entwicklung hinaus ein Trend zum Systemdenken erkennen, das Hardware-Umgebung und organisatorische Aspekte als inhärente Bestandteile eines Gesamtsystems begreift.

Zudem wird die Erfahrung auch lehren, unter welchen Voraussetzungen in den Projekten welche Methoden wirklich gute Ergebnisse liefern. Die Verantwortlichen dürfen die Semantik besser verstehen und in der Art eines Kochrezepts die Dinge fortführen können: Wenn die Randbedingungen so und so sind, dann nehme man diese oder jene Methode.

Was sich am Horizont für die noch längere Zukunft abzeichnet, ist die Objektorientierung, die heute da steht, wo sich vor zehn Jahren die strukturierte Programmierung befand.

Sie wird sich voraussichtlich ähnlich entwickeln und auf längere Sicht hin einen praxisrelevanten Reifegrad erreichen. Ausgehend vom Aufkommen von Sprachen wie Smalltalk 80, ADA und Modula2 diskutiert man heute verschiedene Varianten von

objektorientiertem Entwurf.

Man kann aber nur davor warnen, zu rasch auf diesen Zug aufzuspringen. Objektorientierung ist eher als eine sinnvolle Ergänzung der Methoden zu sehen - nicht als

radikaler Ersatz.

Ein Faktor, der die Entwicklung der neuen Methoden weiter positiv beeinflussen wird, zeichnet sich durch die präzisere Orientierung auf Anwendungsbereiche ab. Man wird bestimmte Märkte gezielt mit domänenspezifischen Methoden bedienen müssen. Während man vor zehn bis 15 Jahren noch mit dem Anspruch antrat, mit einer Methode jedes Problem lösen zu können, zeichnet sich heute ab, daß man zumindest in zwei groben Bereichen denkt: Da ist einmal die Welt der kommerziellen Systeme, zum anderen der Bereich der Realzeitsysteme. Dieses Raster ist jedoch vielfach zu grob. Dazwischen liegen Gebiete, die sich als eigene Bereiche herauskristallisieren. Lediglich exemplarisch seien hier die Spezifizierung von Methoden im Bereich der Telekommunikation, der Büroautomatisierung und der Luft- und Raumfahrt-Industrie genannt.

Um es mit einer Analogie zu verdeutlichen: Brückenbauer und Hausbauer verwenden auch unterschiedliche Verfahren, obwohl beide Materialforschung und Statik als Grundlage haben.

Ähnlich solcher Spezialisierungen in der Baubranche wird man domänenspezifischer in der Software-Industrie arbeiten müssen, um leistungsfähiger und aussagekräftiger mit den entsprechenden Spezialwerkzeugen arbeiten zu können.

Bisher wurde das Wie, die Methoden, der Software-Entwicklung diskutiert. Das Verwirklichen neuer Ideen auf diesem Gebiet wird auch das Management von Softwareprojekten beeinflussen. Mit dem besseren Verständnis der Management-Techniken werden auch hier neue Aspekte in den Vordergrund treten. Dies spiegelt sich in den Modellen zur Beschreibung der Management-Techniken wider.

Eine dritte Akzentverschiebung zeichnet sich immer stärker ab: das systemorientierte Denken.

Man könnte eine solche Vorgehensweise fast mit einem Gesamtkunstwerk vergleichen, bei dem jeder Künstler seine individualistische Grundhaltung zugunsten eines fachübergreifenden, organischen Gesamtkunstwerks aufgibt.

Analog wird nicht mehr die Software-Entwicklung, sondern ein übergeordnetes Systemziel angestrebt. Obwohl schon Barry Boehms Phasenmodell den Begriff "System Requirements" enthält, war das ganze Modell doch auf die Software-Entwicklung ausgelegt, jetzt wird noch vor Beginn der Software-Entwicklung das Systemdenken als Ganzes in den Vordergrund rücken müssen. Das hat Auswirkungen bis hin zur Struktur und Organisation von Firmen: Es wird keine getrennten Teams für Hardware und Software geben.

Ein neuer Berufstypus dürfte sich etablieren können: der Systemingenieur. In anderen Disziplinen ist dies durchaus schon gängige Praxis. So wird im Flugzeugbau beispielsweise auch zunächst einmal das ganze Flugzeug in Systemkonzepten entwickelt.

System Engineering keine leere Worthülse

Und erst zu einem wesentlich späteren Zeitpunkt geht man in Detailmodelle hinein. System Engineering ist inzwischen keine leere Worthülse mehr. In Konferenzen setzt man sich bereits in größerem Stil darüber auseinander, wie sich die heutigen Methoden ausdehnen werden, wenn wir in Systemen denken.

Oder: Was passiert, wenn wir die Unterscheidung zwischen der Implementierung in Software und Hardware zunächst einmal nicht mehr treffen, sondern das System unabhängig von solchen Aspekten unter dem Systemgesichtspunkt betrachten. Amerikanische Militärstandards und entsprechende deutsche Standardvorschläge liegen bereits vor und identifizieren explizit die Phasen dieser neuen Herangehensweisen.

Es gibt auch Vorschriften, wie die Inhalte von diesen Phasen aussehen müssen.

Eine vierte Akzentverschiebung kommt nicht zuletzt in allen Phasen dazu: die Wiederverwendbarkeit auf allen Ebenen. Man wird nicht mehr einfach davon ausgehen, daß das Ergebnis einer Phase der Input für die nächste Phase ist. Man wird das Wissen im Laufe der Zeit ansammeln; nicht nur das Wissen über die Codierung, sondern insbesondere auch das Wissen über Designlösungen und Verfahren, die man angewandt hat, um zur Lösung zu kommen. Es geht also ganz besonders um prozedurales Wissen jenseits der Erkenntnisse über Objekte oder Produkte, die man entwickelt. Für den Projekt-Manager der Zukunft wird die Wiederverwendbarkeit ein ganz wesentlicher Aspekt sein müssen, auf den er in jeder Phase seiner Tätigkeit zurückgreifen wird. Im Rahmen der Alternativenabwägung dürfte die Frage der Wiederverwendbarkeit wie bei jeder kaufmännischen Entscheidung eine stets ins Kostenkalkül zu ziehende Möglichkeit sein. Die herausragende wirtschaftliche, Bedeutung der Wiederverwendbarkeit schlägt sich auch in vielen entsprechenden Forschungsprojekten nieder, die Wiederverwendung für alle Phasen der Entwicklung realisieren wollen. Voraussetzung ist natürlich, daß es Repositories gibt, um dieses Wissen abzuspeichern.

Ausgangspunkt ist auch hier eine Arbeit, die über 20 Jahre alt ist. Barry Boehm hat mit seinem Life-Cycle ein Modell populär gemacht, das in der Praxis der Projektabwicklung dominiert. Ziel des in Phasen angelegten Modells von der Anforderungsanalyse über den Programmentwurf bis zur Implementierung ist es, bereits in frühen Phasen die Modellbildung anzusetzen, um zu technologisch und kaufmännisch kontrollierbaren Zwischenergebnissen zu kommen. Ausgehend von diesem Modell sollen vier wesentliche Akzentverschiebungen diskutiert werden, die man sich in der Praxis überlagert vorstellen muß.

Die erste Akzentverlagerung wird darin bestehen, daß sich das Modell gewissermaßen aufrollt, da die nur auf Phasen ausgelegte Struktur des Life-Cycle-Modells die Realität der Software-Entwicklung nicht adäquat wiedergibt. In dem 1987 publizierten Spiral-Modell verlagert Boehm denn auch den Akzent die sich spiralenförmig fortsetzen.

Wie auch für andere Management-Entscheidungen typisch-werden in jedem Zyklus Ziele definiert, Alternativen und Einschränkungen geplant und Alternativen ausgewählt.

"Silver Bullet" wird Krise nicht lösen

Darauf setzt man dann Risikoanalysen: Was kostet das, wenn wir es selbst entwickeln, kaufen, übernehmen, alte Teile wiederverwenden? Über Prototypen wird man versuchen, die so gewonnenen Entscheidungen zu verifizieren. Vor allen Dingen größere Projekte, die über fünf bis zehn Jahre laufen, werden sicherlich in mehreren, gesteuerten,

kontrollierten Zyklen evolutionärer Natur, erfolgen müssen. Boehms Spiral-Modell ist nur ein Beispiel für den Trend zur evolutionären, iterativen Prozeßgestaltung mit dem Ziel, das Risiko minimieren zu können. Dabei muß der Blick in jeder Iteration auf das Gesamtprojekt gerichtet sein. Der Wille zur Risikoabschätzung ist die treibende Kraft für diesen neuen Trend.

Eine zweite Akzentverschiebung wird zugunsten einer früheren Ausführbarkeit stattfinden. Beim klassischen Phasenmodell war erst das codierte Programm ausführbar. In Zukunft wird man ganz andere Teile dynamisch ausfahren und evakuieren können. Unter Schlagwörtern wie Simulation oder Animation wird man auch Design-, Architektur- und Requirement-Modelle von Systemen ausführbar machen können.

Unter dem Stichwort Prototyping lassen sich sehr früh diynamische Modelle generieren. Damit können, ergänzend zu den bisherigen statischen Prüfungen, auch schon in frühen Phasen vor der Codierurig "Laufzeitfehler" gefunden werden. All die Modelle, die heute schon bekannt sind wie Datenflußdiagramme, Entity-Relationship-Diagramme oder Zustandsmodelle werden die Basis für diese ausführbaren Spezifikationen darstellen. Solche Trends sind auch Thema der Forschungsarbeit bei der GEI im Rahmen des "Eureka"-Software-Factory-Projekts.

Zum Wiederverwenden gehört schließlich auch das Wiederfinden. Hier gilt es, Kategorisierungsschemata zu entwickeln, nach denen sich das Wissen funktional gliedern läßt. Auf diese Problematik zielt auch die Objektorientierung wesentlich ab.

Symptomatisch für Krisen ist oftmals der idealistisch überhöhte Wunsch nach heilsamer Erlösung. In der Softwarebranche hat sich als Schlagwort dafür das berühmte "Silver Bullet" von Fred Brooks etabliert. Der Begriff geht zurück auf die Geschichte der Werwölfe, die man nur in einer mondklaren Nacht mit einer silbernen Kugel erlegen konnte.

Nach realistischen Einschätzungen dürfte die Krise in der Softwarebranche zumindest in den nächsten zehn bis 15 Jahren nicht durch ein Silver Bullet gelöst werden können. Dennoch gibt es, wie gezeigt wurde, bereits heute alle Ingredienzien, die einen evolutionären Lösungsweg vorzeichnen.