Einleitung

1. Einleitung • Vorgehen bei der Entwicklung von Software: • Die „gute, alte“ Zeit: • „ad hoc“-Entwicklung: Problematik wurde direkt in Quellcode umgesetzt und „ausprobiert“ (Coding und Testing); (Übungsaufgaben-Projekte) • Software wird von einer Person oder kleinen Teams erstellt. • Software setzt Spezialisten zum Bedienen voraus, der für Fehleingaben die Verantwortung trägt. • Programm = Umsetzung eines Algorithmus • Projekte waren überschaubar. • Software meist nur ein ausführbares File. • Diese Vorgehensweise stieß aber an Ihre Grenzen: • Mit zunehmender Komplexität konnte auf diese Art kein größeres Programm entwickelt werden. •  „Software-Krise“ (Ende der sechziger Jahre) Software Engineering SS 2009

2. Einleitung • Vorgehen bei der Entwicklung von Software: • heute: • Projekte sind komplex. • Software ist mehr als nur ein File. • Software muss von Jedermann bedienbar sein. • Software muss von größeren Teams entwickelt werden können. • Termin- und Kostenrahmen müssen eingehalten werden. • Fehler können nicht mehr akzeptiert werden. • aber: ... Software Engineering SS 2009

3. Einleitung • Absturz einer Marssonde wegen Umrechnung „Fuß – Meter“ • Elster • Interpol Software Engineering SS 2009

4. Einleitung • Ariane 5, 1996, Quelle: Lions, J. L. (1996), Report by the Inquiry Board. Paris: ESA. http://sspg1.bnsc.rl.ac.uk/Share/ISTP/ariane5r.htm Software Engineering SS 2009

5. Einleitung • Was war passiert? • Die Software für das Trägheitsnavigationssystem wird unverändert von der Ariane 4 übernommen. Ein Test dieser Software unterbleibt daher. • Die übrigen Systeme der Rakete werden komponentenweise gründlich getestet. Ein gemeinsamer Test der gesamten Steuerungssoftware der Rakete unterbleibt aus Kosten- und Machbarkeitsgründen. • In der Software für das Trägheitsnavigationssystem gibt es eine Abgleichsfunktion, deren Werte eigentlich nur sinnvoll sind, solange die Rakete noch nicht fliegt. Diese Funktion arbeitet programmgemäß bis ca. 40 s nach H0 weiter, weil das bei der Ariane 4 im Fall eines Countdownabbruchs kurz vor dem Abheben sinnvoll war. • Flug 501 startet am 4. Juni 1996. Die Triebwerke zünden um H0= 9: 33: 59 Ortszeit. Die ersten 36 Sekunden des Flugs verlaufen normal. • Da die Ariane 5 eine andere Flugbahn hat als die Ariane 4, berechnet die Abgleichsfunktion einen Wert, der wesentlich größer ist als erwartet. • Bei der Konvertierung dieses Werts von einer 64 Bit Gleitkommazahl in eine 16- Bit Festkommazahl tritt ein Überlauf ein; der Rechner erzeugt eine Ausnahmebedingung. Software Engineering SS 2009

6. Einleitung • Die Ausnahmebedingung wird nicht behandelt (obwohl dies in der verwendeten Programmiersprache Ada möglich wäre). • Der Trägheitsnavigationsrechner setzt eine Fehlermeldung an den Steuerrechner der Rakete ab und schaltet sich 36,75 s nach H0 ab. • Das Trägheitsnavigationssystem ist aus Sicherheitsgründen doppelt ausgelegt. Ein Umschalten auf das zweite System schlägt fehl, da dieses System das gleiche Problem gehabt und sich vor 0,05 s ebenfalls abgeschaltet hat. • Die Software des Steuerrechners ist auf den Ausfall beider Trägheitsnavigationssysteme nicht ausgelegt und interpretiert die gemeldeten Fehlercodes als Flugbahndaten. • Dies führt zu völlig unsinnigen Berechnungen und als Folge davon zu unsinnigen Stellbefehlen an die Steuerdüsen der Rakete: Diese werden bis zum maximal möglichen Anstellwinkel ausgeschwenkt. • Aufgrund der resultierenden Scherkräfte zerbricht die Rakete, worauf der Selbstzerstörungsmechanismus ordnungsgemäß anspricht. Dieser sprengt Rakete und Nutzlast und verhindert damit, dass größere Trümmerteile auf den Boden fallen. Software Engineering SS 2009

7. Einleitung • Entstandener Schaden: • 4 Satelliten verloren: 400- 500 M Euro • 2 Jahre Verzug im Entwicklungsprogramm: > 500 M Euro • 2 zusätzliche Erprobungsstarts • bei Gesamtkosten des Projekts von 1987 bis 1998 von 6700 M Euro • und vor allem: • erheblicher Imageschaden Software Engineering SS 2009

8. Einleitung • Fazit: • Software wird oft • teurer als geplant • später fertig als geplant • Software entspricht nicht den Erwartungen • Sehr viele Projekte scheitern Software-Krise wurde nicht bewältigt Software Engineering SS 2009

9. Einleitung • „Fast richtig ist nicht besser als falsch!“ • Zu 99,9 Prozent richtig ausgeführte Arbeiten in den USA bedeuten im Durchschnitt: • Während einer Stunde verschmutztes Trinkwasser pro Monat • Zwei unsichere Landungen pro Tag auf dem Internationalen Flughafen von O‘Hare • 16.000 verlorene Postsendungen pro Tag • 20.000 falsche Medikamentenrezepte im Jahr • 500 nicht einwandfreie chirurgische Eingriffe in der Woche • 22.000 vom falschen Konto abgezogene Schecks pro Stunde (Quality Magazine vom April 1989, R. Loischar) Software Engineering SS 2009

10. Einleitung Für die reine Softwarecodierung gilt: Von 100 Zeilen, die der Mensch schreibt bzw. 100 Strichen, die der Mensch zeichnet, werden: 5 fehlerhaft sein Davon wird der Mensch 50% selbst merken. Es bleiben also 2,5 fehlerhafte Zeilen (2,5%) In einem Programm (Dokument) mit 1.000 Zeilen sind das 25 Fehler In einem Programm (Dokument) mit 10.000 Zeilen sind das 250 Fehler Je größer und komplexer das Programm desto mehr Fehler. Sie sind unvermeidlich. Software Engineering SS 2009

11. Einleitung Woran liegt‘ s? Besonderheiten des Produktes Software: • Software ist immateriell. • Software ist unstetig. • Die Zweckbestimmung ist oft nicht zu Beginn festgelegt. • Jeder darf Software für alle Bereiche und Einsatzbedingungen entwickeln. • Software scheint beliebig änderbar und erweiterbar. • Software schafft neue Realitäten. • Es gibt keine theoretischen Grenzen. • Fehler können nicht direkt erkannt werden. • Fehler werden eher toleriert. • Der Glaube an die Allmacht von Software ist unbegrenzt. Software Engineering SS 2009

12. Einleitung aber: • wir brauchen immer schneller immer mehr immer komplexere Software. • Software bestimmt immer mehr unseren Alltag. • Software muss von jedem bedient werden können. • Software kann ohne Werkzeuge nicht mehr entwickelt werden • Software ist nicht mehr nur die Umsetzung von Algorithmen sondern ein Alltagsgegenstand, • der komplexe Aufgaben und Probleme lösen kann, • der bei Alltagsproblemen unterstützt, • der bei der Erstellung medizinischer Diagnose unterstützt, • der unterhalten kann, • der als Werkzeug für weitere Entwicklung dient, • ... Software Engineering SS 2009

13. Einleitung und zu alledem: Software wird von besser (!) ausgebildeten „Indern“ günstiger entwickelt! Software Engineering SS 2009

14. Einleitung Wie kann‘ s gehen? Wir brauchen einen „beherrschten Prozess“, Software zu entwickeln.  Wir brauchen Software Engineering! Software Engineering SS 2009

15. Einleitung • Lernziele • Inhalt des Begriffes Software • Inhalt des Begriffes Software Engineering • Eigenheiten des Produktes Software kennen und die Problematik, die damit verbunden ist. • Kennen der verschiedenen Vorgehensmodelle und Prozesse • Vor- und Nachteile von Vorgehensmodelle kennen; das „richtige“ Vorgehensmodell auswählen • Aufwand abschätzen • Angebote verstehen und erstellen • Machbarkeitsstudien durchführen Software Engineering SS 2009

16. Einleitung • Lernziele • Planung durchführen; diverse Pläne erstellen • Anforderungen erarbeiten • Anforderungen strukturieren • Softwarearchitekturen sinnvoll einsetzen • Architekturen umsetzen; Implementierungspläne erstellen • Werkzeuge kennen und einsetzen. • Bedienungsanleitungen sind Bestandteil des Produktes • Testverfahren kennen und anwenden; Tests planen Software Engineering SS 2009

17. Einleitung • Lernziele • Wenn man eigentlich fertig ist... • Software installieren und in Betriebnehmen • Schulungen entwerfen und abhalten • Was gehört zur Softwarepflege? • „Updates“, „Upgrades“, „Bugfixes“ & Co. • Rückrufaktionen Software Engineering SS 2009

18. Einleitung • Lernziele • Projektübergreifende Maßnahmen • Qualitätsmanagement • festlegen, was „gute“ Software ist • Qualitätssichernde Maßnahmen einsetzen • Metriken festlegen können • Qualität bewerten können • Risikomanagement beherrschen • Dokumentation:Wissen was, wann, wie und von wem dokumentiert wird. Software Engineering SS 2009