Einführung

Warum scheitern SW-Projekte?

Zu den am häufigsten genannten Ursachen gehören:

schwaches Projektmanagement, erkennbar an den Symptomen

falsche Aufwandsschätzungen
fehlende Kontrollen
fehlende oder lückenhafte Planung
unklare Kompetenzabgrenzung

verfrühte Lösungen mit der Konsequenz, dass die wahren Anforderungen des Anwenders nicht mehr wahrgenommen werden. Niemand erwartet sofort Lösungen!
veränderliche Anforderungen
Akzeptanzprobleme
fehlende methodische Führung der Entwickler
unklare Anforderungen an das System

Warum ist es so schwierig, Software zu machen?

Darauf gibt Denert mehrere Antworten:

Softwaresysteme gehören zu den komplexesten Gebilden, die je von Menschenhand geschaffen wurden. Sie sind aus einer riesigen Zahl von Bauelementen zusammengesetzt, die in vielfältiger Weise interagieren. Man kann sie weder im vorhinein, beim Entwurf, noch im nachhinein, beim Testen, im Betrieb und in der Wartung vollständig verstehen. Im Kontrast zu anderen komplexen Systemen, wie etwa Flugzeugen oder Kraftwerken, ist Software immateriell. man kann sie nicht sehen, fühlen, hören. Von ihrer Größe, Funktion und Komplexität läßt sich durch Anschauung keine Vorstellung gewinnen.
Menschen machen Projekte, und nicht Methoden, Werkzeuge oder SW-Entwicklungsumgebungen. So können gute Leute auch unter schwierigen Bedingungen und mit schlechten Hilfsmitteln gute Software erstellen. Probleme entstehen aber aus menschlichen Unzulänglichkeiten, die in der SW-Entwicklung besonders deutlich werden:

Komplexe Sachverhalte gedanklich voll zu durchdringen, ist eine seltene Fähigkeit.
Softwarelösungen verlangen absolute Präzision. Das dazu nötige logische Denken machen sich nur wenige Menschen zu eigen, sei es wegen fehlender Veranlagung oder unzureichender Ausbildung.
Gute Software zu entwickeln ist eine kreative Aufgabe, zu der nur wenige befähigt sind.
Programmieren im Großen (Programming-in-the-large), d.h. das Entwerfen eines Systems aus zusammenspielenden Moduln, wird von wenigen beherrscht, wohl auch, weil die Informatikausbildung zu sehr ausgerichtet ist auf das Programmieren im Kleinen (Programming-in-the-small): d.h. ein einzelnes Programm oder Modul aus den Anweisungen einer Programmiersprache zu erstellen.
Software entsteht so gut wie immer im Team. Dabei gibt es häufig Kommunikationsprobleme. Der Losung "Never change a winning team" sollte man daher folgen, wann immer möglich.
Die erforderliche Qualifikation des Software-Ingenieurs wird häufig unterschätzt. Programmieren scheint ja so einfach zu sein, man braucht nur ein paar Statements einer Sprache hinzuschreiben - besonders schnell und leicht in Basic auf dem eigenen PC - und schon läuft ein Programm. Wohl auch deshalb gibt es auf dem Gebiet der Datenverabeitung so viel Dilettantismus!

Das richtige Projekt machen. Rechtzeitig, vollständig und genau festzulegen, was ein System leisten soll, ist die Aufgabe der Anforderungsdefinition. Sie gehört zu den heikelsten Kapiteln des SW-Entwicklung und ist eine ständige und ergiebige Quelle von Problemen. Modellbildung und/oder Prototyping werden häufig eingesetzt, um diese Probleme zu entschärfen. Erst wenn eine unmißverständliche Anforderungsdefinition etabliert ist, kann man sich dem nächsten Schritt zuwenden, das Projekt richtig zu machen.
Der Stand der Kunst der Methoden und Werkzeuge für die SW-Entwicklung läßt zu wünschen übrig, und was es an Gutem gibt, ist zu wenig bekannt.

Was versteht man unter "Software-Engineering"?

Als der Begriff geprägt wurde, sollte er provozieren und dazu aufrufen, auch die Herstellung von Software als Ingenieurdisziplin zu betreiben. Bis heute gibt es allerdings keine allgemein anerkannte, feststehende Definition, aber zahlreiche Ansätze, z.B:

Denert schreibt: Software-Engineering ist die Anwendung wissenschaftlicher Erkenntnisse mit dem Ziel, Computer mittels Programmen, Verfahren und zugehörigen Dokumenten dem Menschen nutzbar zu machen.
Parnas schreibt: Software Engineering ist die Programmierung unter mindestens einer der zwei Bedingungen:
Fairley schreibt: Software Engineering ist die technische und organisatorische Disziplin zur systematischen Herstellung von Softwareprodukten, die zeitgerecht und innerhalb vorgegebener Kostenschranken hergestellt und modifiziert werden.
Sommerville schreibt: Software Engineering befaßt sich mit dem Bau von Softwaresystemen, die nicht von einem Entwickler alleine hergestellt werden können. Software Engineering beruht auf der Anwendung ingenieurmäßiger Prinzipien und umfaßt sowohl technische als auch nichttechnische Aspekte.

Nach Pomberger/Blaschek wird von der Disziplin Software-Engineering erwartet, dass sie Methoden, Werkzeuge, Normen und Hilfsmittel bereitstellt, um die folgenden, immer wieder auftretenden Hauptprobleme bei der Erstellung großer Programmsysteme in den Griff zu bekommen:

Spezifikation der Anforderugen
Beherrschung der Komplexität
Zerlegung eines Systems in Teilsysteme
Spezifikation der Schnittstellen zwischen den Teilsystemen
Wiederverwendbarkeit von Bausteinen, Entwicklung von Halbfabrikaten
Projektorganisation, vor allem in Hinblick auf arbeitsteilige System-Entwicklung
Effizienz
Dokumentation und Wartbarkeit der Gesamtlösung
Änderbarkeit und Erweiterbarkeit
Übertragbarkeit auf und Anpaßbarkeit an verschiedene Hardwaresysteme

Dies führt zur folgenden Definition:

Software-Engineering ist die praktische Anwendung wissenschaftlicher Erkenntnisse für die wirtschaftliche Herstellung und den wirtschaftlichen Einsatz qualitativ hochwertiger Software.

Was ist Prototyping?

Zur Klärung der Benutzeranforderungen, aber auch von Entwicklungsproblemen, wird häufig ein Prototyp erstellt: ein schnell und billig realisierbares, ausführbares Modell des Softwareproduktes. Dies trägt in vielen Fällen zur Qualitätssicherung und zur Risikominderung bei. Es werden drei Arten von Prototyping unterscheiden:

Exploratives Prototyping

Ziel: Möglichst vollständige Systemspezifikation
Zweck: Den Entwicklern Einblick in den Anwendungsbereich ermöglichen, als Grundlage für die Diskussion mit den Anwendern dienen, Realisierbarkeit des System im vorgegebenen organisatorischen Umfeld abklären; Problemanalyse und Systemspezifikation werden unterstützt.
Vorgehensweise: Ausgehend von ersten Vorstellungen über das geplante System wird ein Prototyp schnell und leicht veränderbar erstellt, um diese ersten Vorstellungen zu präzisieren. Maßgeblich ist nicht die Qualität des Prototyps, sondern seine Funktionalität und leichte Veränderbarkeit.

Experimentelles Prototyping

Ziel: Vollständige Spezifikation von Teilsystemen als Grundlage für die Implementierung
Zweck: Die Tauglichkeit von Teilsspezifikationen, von Architekturmodellen und von Lösungsideen für einzelne Systemkomenten experimentell nachweisen; System- und Komponentenentwurf wird unterstützt.
Vorgehensweise: Ausgehend von ersten Vorstellungen über die Zerlegung des Systems wird ein Prototyp gebaut, der es erlaubt, die Qualität und Flexibilität der Systemzerlegung auf der Grundlage von Experimenten zu beurteilen.

Evolutionäres Prototyping

Ziel: Inkrementelle, d.h. schrittweise aufbauende Systementwicklung
Zweck: Auf direktem Weg, ohne Zwischenergebnisse wegzuwerfen, mit ständiger Erfolgskontrolle vom Prototyp zum Produkt zu gelangen; alle Phasen des Entwicklungsprozesses werden unterstützt.
Vorgehensweise: Für die von vornherein klaren Benutzeranforderungen wird ein Prototyp entwickelt, der als Basissystem für den nächsten Schritt dient, in dem weitere Benutzeranforderungen integriert werden. Dies wird solange wiederholt, bis der Prototyp zum Produkt geworden, also praktisch einsetzbar ist.

Prototypen lassen sich danach unterscheiden, ob sie

vollständig oder unvollständig sind
wiederverwendbar (bei der Implementierung des geplanten Systems) oder von vornherein als Wegwerfprototyp konzipiert sind.

Ein SW-Prototyp ist ein Modell des geplanten Software-Produkts,das

mit wesentlich geringerem Aufwand (schnell + billig) hergestellt ist,
einfach zu ändern und zu erweitern ist,
ausführbar ist
evtl. unvollständig ist, jedoch dem Anwender erlaubt, alle wesentlichen Systemeigenschaften vor der eigentlichen Systementwicklung zu erproben.

Zur Geschichte des Software-Engineering

Software-Engineering ist ein junges Gebiet, dessen Geburtsstunde auf zwei Konferenzen des NATO Science Committee in Garmisch (1968) und Rom (1969) schlug. Damals wurde auch der Begriff Software-Engineering geprägt. Zunächst wurde er noch nicht als positiv-programmatischer Ansatz zur systematischen Softwarekonstruktion verstanden, sondern war eher als Attacke auf das damalige Selbstverständnis der "Programmierkünstler" verstanden: Programmerstellung wurde als Kunst angesehen, die einer rationalen Betrachtung nur schwer zugänglich war. So hing denn auch der Erfolg oder Mißerfolg eines Projektes entscheidend von einzelnen, hochbegabten Programmierern ab, die ihr Wissen mit sich trugen. Gute, hochwertige Programme waren so zwar möglich, ihr Entstehen aber doch weitgehend vom Zufall abhängig. Das Management von SW-Projekten war klar unterentwickelt

Schon vorher, seit etwa 1965, begann man, von der Softwarekrise zu sprechen. Gemeint waren damit die enorm ansteigenden Schwierigkeiten bei der Softwareentwicklung, sowohl bei Betriebssystemen als auch bei Applikationssoftware: Softwareentwicklung hinkte erheblich der revolutionär verlaufenden Hardwareentwicklung hinterher. Softwareprojekte kamen fast regelmäßig in erheblichen Verzug, wenn sie denn nicht vollständig scheiterten, z.B. wegen erheblicher Qualitätsprobleme. Zu dieser Zeit wurde Software auch noch als Anhängsel der Hardware betrachtet, die meist kostenlos mitgeliefert wurde.

Man wurde sich rasch einig, daß ein ingenieurmäßiger Ansatz zur Softwareentwicklung nur Vorteile bringen konnte: disziplinierte Entwicklung, Abgrenzung von Tätigkeiten sowie Verwendung von Normen und Standards.

Die folgende Zeittafel (nach Denert) wirft Schlaglichter auf einige Ereignisse, die die Entwicklung des Fachgebietes Software-Enginering beinflußten:

1965 Simula: Class Concept

1968 Dijkstra: Goto considered harmful

1968/1969 NATO-Konferenzen, der Begriff Software-Engineering wird geprägt. Die ersten Softwarehäuser werden gegründet

1970 Codd: Relationales Datenmodell

1971 Weinberg: Psychology of Computer Programming ("egoless"attitude)

1971 Baker: Chief Programmer Team

1972 Parnas: On the criteria to be used in decomposing systems in to modules; Software module specification

1973 Nassi/Shneiderman: Struktogramme

ab 1973 diverse SW Life Cycle-Modelle

1975 Guttag: Algebraische Spezifikation abstrakter Datentypen

1975 Brooks: The Mythical Man Month ("Adding manpower to a late project makes it later")

1976 DeRemer/Kron: Programming in the large versus small

1975 Structured Analysis/Design

1976 Fagan: Code Inspection

1976 Chen: Entity/Relationship Approach

1977 SADT (Structured Analysis and Design Technique)

1975-1980 Sprachen: CLU/Alphard/Euclid/Modula Ada

1981 Boehm COCOMO

ab 1980 Diverse Entwicklungsumgebungen und Methodensysteme kommen: Promod, Epos, Predict Case ... und einige gehen auch wieder.
Relationale Datenbanksysteme (RDBMS) kommen in der Praxis zum Einsatz, Sprachen der sog. 4. Generation gewinnen an Bedeutung.
Unix setzt sich durch

1985/86 SDI-Debatte

ab ca. 1987 CASE-Tools mit graphischen Oberflächen überfluten den Markt; sie unterstützen hauptsächlich Structured Analysis und Entity/Relationship Daten-Modellierung

1988 Meyer: Object-oriented Software Construction; Eiffel

1989 Objektorientierte Methodik gewinnt immer mehr Anhänger

1965	Simula: Class Concept
1968	Dijkstra: Goto considered harmful
1968/1969	NATO-Konferenzen, der Begriff Software-Engineering wird geprägt. Die ersten Softwarehäuser werden gegründet
1970	Codd: Relationales Datenmodell
1971	Weinberg: Psychology of Computer Programming ("egoless"attitude)
1971	Baker: Chief Programmer Team
1972	Parnas: On the criteria to be used in decomposing systems in to modules; Software module specification
1973	Nassi/Shneiderman: Struktogramme
ab 1973	diverse SW Life Cycle-Modelle
1975	Guttag: Algebraische Spezifikation abstrakter Datentypen
1975	Brooks: The Mythical Man Month ("Adding manpower to a late project makes it later")
1976	DeRemer/Kron: Programming in the large versus small
1975	Structured Analysis/Design
1976	Fagan: Code Inspection
1976	Chen: Entity/Relationship Approach
1977	SADT (Structured Analysis and Design Technique)
1975-1980	Sprachen: CLU/Alphard/Euclid/Modula Ada
1981	Boehm COCOMO
ab 1980	Diverse Entwicklungsumgebungen und Methodensysteme kommen: Promod, Epos, Predict Case ... und einige gehen auch wieder. Relationale Datenbanksysteme (RDBMS) kommen in der Praxis zum Einsatz, Sprachen der sog. 4. Generation gewinnen an Bedeutung. Unix setzt sich durch
1985/86	SDI-Debatte
ab ca. 1987	CASE-Tools mit graphischen Oberflächen überfluten den Markt; sie unterstützen hauptsächlich Structured Analysis und Entity/Relationship Daten-Modellierung
1988	Meyer: Object-oriented Software Construction; Eiffel
1989	Objektorientierte Methodik gewinnt immer mehr Anhänger