Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Einleitung Vorgehen bei der Entwicklung von Software: Die gute, alte.

Ähnliche Präsentationen


Präsentation zum Thema: "Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Einleitung Vorgehen bei der Entwicklung von Software: Die gute, alte."—  Präsentation transkript:

1 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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)

2 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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:...

3 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 3 Einleitung Absturz einer Marssonde wegen Umrechnung Fuß – Meter Elster Interpol

4 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 4 Ariane 5, 1996, Quelle: Lions, J. L. (1996), Report by the Inquiry Board. Paris: ESA. Einleitung

5 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 5 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 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. Einleitung

6 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 6 –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. Einleitung

7 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 7 Einleitung Entstandener Schaden: –4 Satelliten verloren: 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

8 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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

9 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 9 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 OHare – verlorene Postsendungen pro Tag – falsche Medikamentenrezepte im Jahr –500 nicht einwandfreie chirurgische Eingriffe in der Woche – vom falschen Konto abgezogene Schecks pro Stunde (Quality Magazine vom April 1989, R. Loischar) Einleitung

10 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 10 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 Zeilen sind das 25 Fehler In einem Programm (Dokument) mit Zeilen sind das 250 Fehler Je größer und komplexer das Programm desto mehr Fehler. Sie sind unvermeidlich. Einleitung

11 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 11 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. Einleitung

12 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 12 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, –... Einleitung

13 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 13 und zu alledem: Software wird von besser (!) ausgebildeten Indern günstiger entwickelt! Einleitung

14 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 14 Einleitung Wie kann s gehen? Wir brauchen einen beherrschten Prozess, Software zu entwickeln. Wir brauchen Software Engineering!

15 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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

16 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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

17 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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

18 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 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.


Herunterladen ppt "Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Einleitung Vorgehen bei der Entwicklung von Software: Die gute, alte."

Ähnliche Präsentationen


Google-Anzeigen