 „Software-Krise“ (Ende der sechziger Jahre) 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

Software Engineering SS 2009 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

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

Software Engineering SS 2009 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

Software Engineering SS 2009 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

Software Engineering SS 2009 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

erheblicher Imageschaden 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

Software-Krise wurde nicht bewältigt 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

Software Engineering SS 2009 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

2,5 fehlerhafte Zeilen (2,5%) Sie sind unvermeidlich. 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

Software Engineering SS 2009 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. bei Software entstehen keine Materialkosten, wird Quellcode gelöscht ist das nicht so schlimm wie wenn Baustoffe abgerissen werden Software hat keinen Materialwert. Den Wert der Software kann man am Datenträger nicht erkennen. Ein geändertes Bit hat unter Umständen radikale Auswirkungen. z. B. kann ein Dokument nicht mehr abgespeichert werden, oder eine Regelalgorithmus regelt völlig falsch. (Tollcollects Maudsystem zählte auf der Gegenfahrbahn die Kilometer rückwärts) Eine Brücke wird nicht plötzlich als Landebahn für einen Jumbo deklariert, aber Kleinanwendungen müssen plötzlich Eigenschaften aufweisen, für die sie nicht geschaffen sind. keiner darf eine Brücke bauen, ohne Ingenieur zu sein. ... mit der Entwicklung kommen die Wünsche... Software schafft Lösungen zu Problemen, die man vorher gar nicht hatte. Bsp.: Mailingaktionen müssen personalisiert sein. Steuererklärungen, SV-Abgaben, Arztabrechnungen müssen elektronisch erfolgen. Grenze ist nur die Fähigkeit des Entwicklers; (temporär die jeweils aktuelle Hardware) schöner Verpackungen, gutgestaltete Oberflächen, beredsame Verkäufer können leicht über schwere Mängel hinwegtäuschen Schwere Produktmängel werden als Bugs verniedlicht. Aber: Turingautomat! Alan Turing hat gezeigt: es lässt sich prinzipiell (theoretisch) nicht alles mit einem Computer berechnen, und auch in Zukunft von noch zu erfindenden Computern. (vgl. Gödel‘ sches Debakel Software Engineering SS 2009

Software Engineering SS 2009 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, ... Punkt 1: daher entwickeln auch Nichtspezialisten Software; Wegen der knappen Zeit bei der Entwicklung enthalten auch Betriebssystem und Werkzeuge (Compiler) Fehler Punkt 5: auch wissenschaftliche Probleme können gelöst werden (Simulationsprogramme) Alltagsprobleme wie Banking, ABS, Telefonieren, Software Engineering SS 2009

Software Engineering SS 2009 Einleitung und zu alledem: Software wird von besser (!) ausgebildeten „Indern“ günstiger entwickelt! Inder stehen nicht als Vertreter der Nation sondern als Synonym für kostengünstige Programmierer; z.B. aus Rumänien u.s.w, Software Engineering SS 2009

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

Software Engineering SS 2009 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 Sie sollten wissen, weshalb Sie später Ihr Gehalt erhalten. Software Engineering SS 2009

Software Engineering SS 2009 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 Sie sollten wissen, weshalb Sie später Ihr Gehalt erhalten. Software Engineering SS 2009

Software Engineering SS 2009 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 Sie sollten wissen, weshalb Sie später Ihr Gehalt erhalten. Software Engineering SS 2009

Software Engineering SS 2009 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. Sie sollten wissen, weshalb Sie später Ihr Gehalt erhalten. Software Engineering SS 2009