1. Was ist Software-Engineering ?

Kurz gefaßt könnte man Software-Engineering als das organisierte, methodische Erstellen von größeren Softwareprojekten bezeichnen. Natürlich ist die erste Fertigkeit, die zur Erstellung von Software beherrscht werden muß, das Programmieren der Hardware auf der die von der Software zu erledigende Arbeit verrichtet werden soll. Aber selbst dieser eng gefaßte Bereich hat im Laufe des technischen Fortschritts auf dem Gebiet der Computer eine deutliche Veränderung erfahren.

Erste Rechnersysteme waren eigentlich gar nicht anders zu bedienen als durch direkte Programmierung in Form von Lochkarten oder ähnlichem. Der Benutzer war gleichzeitig der Programmierer. Die Möglichkeit, auf einem Computer Programme starten zu können, die man von anderen Personen zur Verfügung gestellt bekam, ohne selber Programmieren können zu müssen, ist heute für jeden Anwender selbstverständlich, muß aber schon als Fortschritt zu den ursprünglichsten Rechnerinstallationen angesehen werden.

Die Arbeit des Programmierers war jedoch immer noch sehr nah an der Maschine, die Abbildung der realen Problemstellung in ein lauffähiges Programm war nur sehr schwer durch direkte Programmierung der Rechenanlage in ihrer jeweiligen Maschinensprache zu erreichen. Höhere Programmiersprachen wie Cobol oder Fortran erlaubten in geringem Maße Abstraktion von der Maschine und erleichterten das Übertragen einer Aufgabe in ein Programm.

Mit der anwachsenden Verbreitung von Computern wuchs auch allgemein das Interesse, vielfältige Aufgaben mit ihnen ausführen zu können, damit also auch der Bedarf nach Software. Wo früher der Besitzer einer Rechenanlage oft noch Konstrukteur, Anwender und Programmierer in einer Person waren, standen jetzt Firmen und Institutionen, die sowohl Hardware als auch Software von entsprechenden Anbietern kaufen mußten.

1.1 Die Software-Krise

Die so entstandene Software Industrie mußte jedoch bald feststellen, daß es kaum möglich war, die Bedürfnisse der Kunden zufriedenzustellen, ohne die althergebrachte Arbeitsweise zu überdenken. Die Problematik war so offensichtlich, daß Fachleute in den späten 60er Jahren von einer Software-Krise sprechen.

Die Erstellung eines in Auftrag gegebenen Software Systems, die sowieso im Vergleich zu den Kosten der Hardware immer teurer geworden war (siehe Abb. 1), überschritt sowohl die Dauer als auch den Preis betreffend die vereinbarten Rahmenbedingungen oder aber konnte qualitätsmäßig nicht zufriedenstellen.

Oft mußten angesetzte Aufträge wieder abgesagt werden, weil der Kunde die bestellte "Ware" nicht mehr bezahlen konnte oder wollte. Auf der anderen Seite aber wollten die hochqualifizierten Programmierer für ihre Arbeit auch angemessen bezahlt werden. Die damaligen Großkunden der Softwareindustrie initiierten daraufhin eigens zum Besprechen eines Ausweges Konferenzen mit den Fachleuten auf Anbieterseite.
In dieser Zeit kommt die Bezeichnung Software-Engineering zum erstenmal in Gebrauch. Man hatte erkannt, daß Hauptursache der Krise die Schwerfälligkeit der damaligen Arbeitsweise bezüglich geringfügiger Änderungen der Software war.

Schon lange konnte kein Programm oder gar System aus mehreren Programmen oder Komponenten mehr von einer Person alleine programmiert werden. Nicht nur die Änderung der Anforderungen an ein Programm, nachdem es bereits fertiggestellt war, sondern auch die nachträgliche Behebung von Fehlfunktionen konnte kaum von den ursprünglichen Programmierern ausgeführt werden. Dokumentation war möglicherweise ausreichend erstellt, um den Anwender zufriedenzustellen, die Wartbarkeit litt aber oft unter unzureichender Weitsicht beim Entwurf und die ursprünglichen Gedanken der Programmierer waren dem Wartungspersonal oft nicht mehr zugänglich. Vor allem aber war die Vorgehensweise beim Entwurf größerer Softwaresyteme sehr wenig tolerant gegenüber Fehlplanung.

1.2 Das Wasserfallmodell

Die als Wasserfallmodell bekanntgewordene Vorgehensweise (siehe Abb. 2), kann als erste Systematisierung der für jeden Konstruktionsprozeß typischen Phasen des Entwurfes, usw. im Software Engineering angesehen werden.

Im Sinne der Zerlegung einer großen Aufgabe in mehrere kleine versucht man in jeder der einzelnen Phasen ein Teilprodukt zu erstellen, und auch ausreichend zu dokumentieren, so daß es der nächsten Phase zur Weiterbearbeitung übergeben werden kann. Offensichtlich kann und sollte man jede einzelne Phase noch einmal in Planung, Realisierung und Überprüfung zergliedern, um die Korrektheit des Teilproduktes jeder einzelnen Phase sicherzustellen. Das Ziel war es, Rückwirkungen der Erkenntnisse einer Phase auf vorherige Phasen möglichst auszuschließen.
Aus der Erfahrung wußte man, daß jede Fehlplanung in einer der verschiedenen Phasen um so aufwendiger beziehungsweise kostenintensiver zu beheben war, je weiter man innerhalb der Phasen schon fortgeschritten, war bevor der Fehler erkannt wurde. Deshalb mußte eben besonders auf Konsistenz und Eindeutigkeit jedes Zwischenproduktes geachtet werden. Hier wird auch die Notwendigkeit deutlich, geeignete Methoden, Notationen u.ä. zu finden, auf die sich die beteiligten Personen einigen konnten, um eine ordentliche Kommunikation zwischen den einzelnen Arbeitsschritten zu gewährleisten.

Obwohl gerade mit dem Ziel entworfen, unter den einzelnen Phasen möglichst korrekte Zwischenergebnisse auszutauschen, konnte das Wasserfallmodell die Probleme die sich ergaben, wenn trotz größter Sorgfalt Fehlplanungen in einer frühen Phase offenbar wurden, natürlich überhaupt nicht mindern.

1.3 Das Spiralmodell

Das nun angestrebte Verfahren, die notwendigen Phasen des Entwurfes, usw. möglichst durchgängig oder wiederholbar zu gestalten, wird allgemein als Spiralmodell idealisiert (siehe Abb.3).

Man versucht im Prinzip die gleichen Tätigkeiten (Entwurf,..) auf verschiedene Entwicklungsstufen eines Projektes wiederholt anwenden zu können, und so nach und nach die vollständige Funktionalität zu realisieren. Außerdem kann in jedem erneuten Durchlaufen eines Zyklus ein anderes Teilgebiet des Projektes gezielt angesprochen werden, wenn dort in einer vorhergehenden Phase Mängel entdeckt worden sind. Hier kann ein unvollständiger Prototyp des Systems erstellt werden, an dem der Kunde prüfen kann, ob das Produkt den Wünschen entspricht. Das entspricht grundsätzlich einem mehrfachen Durchlaufen des Wasserfallmodells, nur daß hier explizit gewünscht ist, bei jedem Durchlauf der "Spirale" ein Modell zu erstellen oder zu verfeinern, welches von jeder der anderen Phasen weiter bearbeitet werden kann. (Im Gegensatz zum Wasserfallmodell, wo das Zwischenprodukt einer späten Phase sich in der Form vollständig von dem unterscheiden darf, was eine frühe Phase als Information erwartet.)

Mit Modell ist hierbei immer eine Repräsentation des Problems, der zu bearbeitenden Daten, der bearbeitenden Funktionen und ähnlicher Dinge gemeint, die sich zwischen einfacher Abstraktion der Problemwelt und Darstellung der endgültigen Implementierung bewegt. Das können Diagramme oder andere graphische oder gar textuelle Aufzeichnungen sein. Die Notwendigkeit einer möglichst eindeutigen Notation weg von umgangssprachlichen Beschreibungen dürfte offensichtlich sein.

Hinzu kommt, daß vor allem das Vorgehen des Spiralmodells eine Form der Modellierung /Repräsentation braucht, die nicht nur wohldefiniert sein muß, sondern auch gut zwischen Problemmodellierung orientiert an der realen Welt und dem Entwurf der Implementierung zu vermitteln versteht. Gerade hier beanspruchen die Vertreter objektorientierter Vorgehensweisen für sich, den Bedürfnissen besonders gerecht werden zu können.


---

Index             Weiter 

---