Software−Engineering ist Multi−Personen−Konstruktion von Multi−Versionen−Software (Parnas).

Unter „Software−Engineering” (SE) versteht man die Anwendung von Prinzipien, Methoden und Techniken auf den Entwurf und die Implementierung von Programmen und Programmsystemen. Der Begriff Software−Engineering steht für die Auffassung, dass die Erstellung, Anpassung und Wartung von Programmsystemen kein künstlerischer, sondern vorwiegend ein ingenieurmäßig ablaufender Prozeß ist, vergleiche [INFODUDEN S. 655].
In einer Projektarbeit werden die individuellen Anforderungen des Auftraggebers (Kunde) vom Auftragnehmer realisiert/entwickelt. Als Resultat erhält der Kunde ein softwareintensives System gemäß seinen Anforderungen.

Der Kunde möchte in erster Linie eine zuverlässige Software, vielleicht toleriert er noch ein paar Fehlerchen, aber

• zuverlässig und robust muss sie sein!
• Dann muss sie meist schnell fertig sein — zumindest möchte der Kunde den Tag der Fertigstellung wissen.
• Dann muss sie, die Software, so benutzungsfreundlich wie möglich sein.
• Und der Preis muss stimmen!

Bis dann die Software endlich fertig ist, ist der Kunde vielleicht auf eine andere Betriebssoftware umgestiegen, und Sie als Entwickler müssen das ganze Software−Paket, sofern man es als Paket betrachten kann, auf die andere Betriebssoftware anpassen.
Falls der Kunde mit der Software nun endlich mehr oder weniger zufrieden arbeitet, fällt ihm noch dies und jenes ein, was er noch dazu haben möchte! Dann sind vielleicht nur Sie als einziger Entwickler dieser jungen, neuen Software, auch der Einzige, der diese Software vielleicht erweitern kann. :−(
Die Hauptfrage ist doch:

1. Kann der Kunde mit seiner neuen Software wirklich zufrieden sein?

Wenn die Software „hint' und vorne” nicht funktionieren sollte und keine Besserung in Aussicht ist, müssen Sie als Entwickler schmerzhafte Vertragsstrafen über sich ergehen lassen, zudem fühlt sich der Kunde um sein Geld betrogen. Womit wir schon beim nächsten Problem wären: die Entwicklungskosten bezüglich der Aufwandsschätzung.
Software−Engineering bringt Ansätze zur Lösung vieler Probleme, aber auch Strukturierungsansätze damit gar nicht erst neue Probleme bzw. Katastrophen entstehen.

Die Geschichte ist voll von Software−Katastrophen:

• 1994: Bei der Wahl des Oberbürgermeisters in Neu−Ulm 1994 wurde zunächst eine Wahlbeteiligung von 104% ermittelt. Später musste man feststellen, dass sich in die Auswertungssoftware ein mysteriöser Faktor 2 eingeschlichen hatte. (Partsch)
• 1994/95: Ein Fehler in der softwaregesteuerten Innenbeleuchtung eines deutschen Automobil−Herstellers führte 1994/1995 zu vollständigem Batterieausfall des betroffenen PKW−Typs. Die Kosten der dadurch ausgelösten Rückrufaktion werden auf mehrere Millionen Mark geschätzt. (Partsch)
• 2004/05: Ein Softwarefehler hat sich beim deutschen Arbeitsamt eingeschlichen. Die Kontonummern der Antragsteller auf Arbeitslosengeld wurden falsch formatiert ausgegeben, die führenden Nullen wurden hinten angehängt.
• 2007: Hamburg, am Montag, den 11. Juni 2007 war ein Pilot einer Verkehrsmaschine gezwungen eine Notlandung hinzulegen. Eine ganze Stunde versuchte er zu landen, doch der Board−Computer weigerte sich und versagte den Landevorgang mit einer Fehlermeldung. Dieser Unfall ging glücklicherweise glimpflich aus und forderte keine Menschenleben.

… um nur ein paar Katastrophen zu nennen. Softwarefehler gehören nicht der Vergangenheit an! Oftmals haben kleine Ungenauigkeiten bei der Entwicklung verheerende Folgen. Es ist schließlich unsere Aufgabe aus der Vergangenheit zu lernen. Denn wir wissen ja: Erfahrung ist die Summe aller ausgewerteten Mißerfolge!

Um den Berufsstand der Informatiker zu sichern, sind die Software−Entwickler stets darum bemüht qualitativ hochwertige Software zu produzieren. Deshalb wird bei der Softwareproduktion auf folgende Eigenschaften besonders großen Wert gelegt:

• Zuverlässigkeit
  • Robustheit
    Die Software muss absturzsicher sein. Beispielsweise sollte die Software bei Falschbehandlung stets in einen definierten Zustand zurückkehren. Das Gleiche sollte aber auch dann gelten, wenn zum Beispiel ein Peripheriegerät abgeschaltet sein sollte bzw. fehlen sollte.
  • Korrektheit
    Die Ausgabe muss stets korrekt gemäß der Spezifikation sein.
• Abstraktion und Wartbarkeit
  Oftmals müssen Änderungen an der Software vorgenommen werden, sei es durch Programmfehler, durch Wechsel des Betriebssystems oder durch Modernisierung der Anforderungen. Der Aufwand, ein bestehendes Softwaresystem je nach Bedarf abzuändern, ist unproblematischer, je abstrakter die Programmarchitektur angelegt wurde.
  Zum Beispiel könnte das Programm aus Schichten gemäß der ANSI−Norm bestehen.