6.4 Softwareentwicklung als Ingenieurdisziplin

Prinzipiell wird Software nach den klassischen Vorgehensmodellen in folgenden sechs Phasen im Rahmen eines Projekts entwickelt:

1. Analyse
2. Entwurf (Design)
3. Implementierung
4. Test
5. Inbetriebnahme
6. Wartung

Während im Wasserfallmodell und V-Modell diese Phasen mit kurzen Rückkoppelungen im Idealfall nur einmal durchlaufen werden, erfolgt eine iterative Wiederholung der Phasen in der evolutionären Softwareentwicklung. Entscheidend dabei ist, dass während der Analyse möglichst alle Anforderungen an die zu entwickelnde Software erkannt werden. Später auftretende Änderungen können nach dem Entwurf der Software oft nur schlecht oder unter hohem Kostenaufwand berücksichtigt werden. Aus dieser Darstellung ergibt sich die auf Barry Boehm (vgl. z. B. Col03) zurückgehende Kostenkurve, wie in Abbildung 9 auf Seite zu sehen.

Abbildung: zeitliche Abhängigkeit der Kosten für Änderungen nach Boehm

Diese zeigt, dass später auftretende Anforderungen wesentlich höhere Kosten (exponentieller Anstieg) verursachen, als frühzeitig erkannte Anforderungen. Deshalb wird in der klassischen Softwareentwicklung der Schwerpunkt auf die Analyse gelegt, um möglichst alle Anforderungen zu erkennen. Darin inbegriffen ist die These, dass die Softwarearchitektur nur schwer änderbar ist und somit nur unter hohen Kosten Änderungen der Anforderungen berücksichtigt werden können.

Dieses Vorgehen findet sich in einer Reihe von Ingenieurdisziplinen wieder. Für die Softwareentwicklung wird oftmals die Metapher des Hausbaus benutzt. Bevor mit dem eigentlichen Bau begonnen werden kann, muss zuerst eine Architektur (Entwurf) anhand der Anforderungen der späteren Bewohner erarbeitet werden. Diese Architektur kann dann durch eine Baufirma realisiert werden. Sollten sich während der Bauausführung Änderungen ergeben, können diese nur schwer berücksichtigt werden, da größere Änderungen eine Überarbeitung der Architektur erfordern würden.

Die Baumetapher hat sich als sehr wertvoll für die Softwareentwicklung erwiesen. Kein Architekt bzw. Konstrukteur entwickelt heute jedes Haus oder jede Brücke komplett neu. Vielmehr wird auf einen reichen Erfahrungsschatz zurückgegriffen und bekannte Elemente werden kombiniert. In diesem Zusammenhang entstand der Gedanke wieder verwendbarer Softwarekomponenten. So können heute enorme Produktivitätssteigerungen durch den Einsatz von Frameworks wie Microsoft .NET, Suns Java Klassen oder der Qt Bibliothek von Trolltech erreicht werden. Weiterhin wurde ein Katalog mit möglichen Software Architekturen und Entwurfsmustern erstellt. (vgl. Gam96) Als Vorbild für die Entwurfsmuster werden die Architekturmuster des Architekturprofessors Christopher Alexander zitiert.

Jede Phase in der klassischen Softwareentwicklung erzeugt definierte Artefakte. Diese Artefakte dokumentieren den kompletten Prozess und das Produkt. Anhand dieser Dokumentation kann das Projekt nachvollzogen und kontrolliert werden. Eine Einarbeitung eines neuen Mitarbeiters ist mit dieser Dokumentation möglich. Darüber hinaus dienen die bereits produzierten Artefakte als Arbeitsgrundlage der folgenden Phasen. Im Idealfall benötigt ein Mitarbeiter kein Vorwissen aus den vergangenen Phasen um seine Arbeit fortzusetzen. In der Endkonsequenz werden Mitarbeiter dadurch theoretisch leichter austauschbar. Dies führt zu einer Geringschätzung des Mitarbeiters und es wird somit eher in Werkzeuge und Prozesse als in Mitarbeiter und deren Qualifikation investiert.

Aufgrund der klar definierten Ergebnisse einer Phase kann objektiv entschieden werden, ob eine Phase in der Softwareentwicklung erfolgreich beendet ist. Ein umfangreiches Controlling ist möglich. Es wurden eine Vielzahl von Softwaremetriken zur Beurteilung der Qualität der produzierten Software, aber auch zur Beurteilung der Qualität des Projektes insgesamt, entwickelt. Diese Metriken unterstützen zukünftige Projekte z. B. bei Aufwandsschätzungen. Insgesamt gesehen findet eine ständige Optimierung der Softwareentwicklung statt. Diese Optimierung ist notwendig, um die stetig komplexer werdenden Anforderungen bewältigen zu können.

Weiterhin existiert die Tendenz eine möglichst hohe Automatisierung, z. B. im Rahmen der Model Driven Architectur³⁵, während der Softwareentwicklung zu erreichen. Neben einer Kostenreduktion durch Einsparung von Mitarbeitern wird eine Qualitätssteigerung angestrebt. Dazu sind hohe Investitionen in Werkzeuge notwendig, vergleichbar dem Aufbau von vollständig automatisierten Fertigungsstraßen in der Güterindustrie. Auch hier sind die Parallelen zu anderen Ingenieurdisziplinen unverkennbar.

All diesen verschiedenen Ausprägungen der klassischen Softwareentwicklung liegen letztendlich zwei Grundannahmen zugrunde, die mit dem Begriff mechanisches Weltbild³⁶ nach Newton zusammengefasst werden können. Die zwei Grundannahmen lauten:

1. Determinismus
2. Linearität

Es wird jetzt gezeigt, worin sich diese Grundannahmen konkret manifestieren.