Grundlagen der Programmentwurfstechnik Fundamentals of Software Engineering 1

Transkript

1 Vorlesung 1 Fundamentals of Software Engineering 1 Sommersemester 2013 Inhaltsverzeichnis 1. Allgemeine Begriffsbidlung 1.1 Einleitung 1.2 Geschichte der Software-Entwicklung 1.4 Der Software Lebenszyklus Vorgehensmodelle Kostenentwicklung in Rechnersystemen 1.4 Systematische Projektplanung 1

2 1.1 Einleitung Software-Komplexität Quelle: Christof Ebert Einleitung Software: Was ist das eigentlich? Software ist soviel mehr als nur der Quellcode 2

3 1.1 Einleitung Verschiedene Sichten auf das Produkt SOFTWARE 1.2 Geschichte der Software Entwicklung Dijkstra 1972: "Als es noch keine Rechner gab, war auch das Programmieren noch kein Problem; als es dann ein paar Rechner gab, war das Programmieren ein kleines Problem; und nun, wo wir gigantische Rechner haben, ist auch das Programmieren zu einem gigantischen Problem geworden" 3

4 1.2 Geschichte der Software Entwicklung - Begriffsdefinitionen: Software Engineering - Parnas 1974: Software -Engineering ist die Programmierung unter mindestens einer der zwei Bedingungen: Mehr als eine Person schreibt und benutzt das Programm Mehr als eine Fassung des Programms wird erzeugt. Dennis 1975: "Software Engineering ist die Anwendung von Prinzipien, Fähigkeiten und Kunstfertigkeiten auf den Entwurf und die Konstruktion von Programmsystemen Boehm 1979: "Software Engineering ist die praktische Anwendung wissenschaftlicher Erkenntnisse auf den Entwurf und die Konstruktion von Programmsystemen." 1.2 Geschichte der Software Entwicklung - Definitionen: Software Engineering - Sommerville 1985: "Software Engineering befasst sich mit dem Bau von Software-Systemen, die nicht von einem Entwickler alleine hergestellt werden können. Software-Engineering beruht auf der Anwendung ingenieursmäßiger Prinzipien und umfasst sowohl technische als auch nichttechnische Aspekte." IEEE-Standard The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering g to software. Booch 1998: The goal is to efficiently and predictable deliver a software product that meets the needs of the business 4

5 1988: Airbus downing during Iran-conflict. 1991: Sleipner Offshore Platform. Sinking caused by the wrong use of FEcode NASTRAN, : Ariane 5, Explosion; data conversion of a too large number 1999: Mars ClimateOrbiters, Loss; Mixture of pounds and kilograms 2002: Geldautomaten Aufgrund eines Softwareproblems konnten bei allen anderen Geldinstituten außer der Postbank selbst mit beliebigen Pincodes Euro abgehoben werden, ohne dass das Sparkonto mit der abgehobenen Summe belastet wurde. 2003: Deutsches Mautsystem 2004: The Role of Software in Spacecraft Accidents, Nancy Leveson, Ariane 5 Absturz 4. Juni 1996: First Start of "Ariane-5 Schaden 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 M Euro 5

6 Die Software für das Trägheitsnavigationssystem wird unverändert von der Ariane 4 übernommen. Alle Systeme der Rakete werden komponentenweise gründlich getestet. Ein gemeinsamer Test der gesamten Steuerungssoftware unterbleibt aus Kosten- und Machbarkeitsgründen. In der Software für das Trägheitsnavigationssystem gibt es eine Abgleichs-funktion, deren Werte eigentlich nur sinnvoll sind, solange die Rakete noch nicht fliegt. Diese Funktion arbeitet programmgemäß bis ca. 40 s nach Abheben (HO) 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 HO=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. 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ägheitsnavigations-system ist aus Sicherheitsgründen doppelt ausgelegt. Ein Umschalten auf das zweite System schlägt fehl, da dieses System das gleiche Problem hatte und sich vor 0,0505 s ebenfalls abgeschaltet hat. Die Software des Steuerrechners ist auf den Ausfall beider Trägheitsnavigationssysteme nicht ausgelegt und interpretiert die gemeldeten Fehlercodes als Flugbahndaten. 6

7 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. -Was können wir aus dem Absturz der Ariane5 lernen?- Spezifikation: Bestehende Software darf nicht unbesehen für eine neue Aufgabe wiederverwendet werden. Vorher muss geprüft werden, ob ihre Fähigkeiten den Anforderungen der neuen Aufgabe entsprechen. Dokumentation: Die Fähigkeiten einer Software sowie alle Annahmen, die sie über ihre Umgebung macht, müssen dokumentiert t sein. Andernfalls ist die Prüfung auf Wiederverwendbarkeit extrem aufwendig. Design by Contract: Kooperieren zwei Software-Komponenten miteinander, so müssen eindeutige Zusammenarbeitsregeln definiert, dokumentiert und eingehalten werden: Wer liefert wem was unter welchen Bedingungen. Fehlerbehandlung: Jede potentielle Fehlersituation in einer Software muss entweder behandelt werden oder die Gründe für die Nichtbehandlung müssen so dokumentiert werden, dass die Gültigkeit der dabei getroffenen Annahmen überprüfbar ist. Software & Hardware: Mehrfache identische Auslegung von Systemen hilft nicht gegen logische Fehler in der Software. Sicherheit: Bei Störungen in sicherheitskritischen Systemen ist Abschalten nur dann eine zulässige Maßnahme, wenn dadurch wieder ein sicherer Zustand erreicht wird. 7

8 1.2.1 Software bedingte Katastrophen -Was können wir aus dem Absturz der Ariane5 lernen?- Qualitätsmanagement Test: Bei der Prüfung von Software, die aus mehreren Komponenten besteht, genügt es nicht, jede Komponente nur isoliert für sich zu prüfen. Umfangreiche Systemtests unter möglichst realistischen Bedingungen sind notwendig. Review: Jedes Programm muss - neben einem sorgfältigen Test - durch kompetente Fachleute inspiziert werden, weil insbesondere die Erfüllbarkeit und Adäquatheit von Annahmen und Ergebnissen häufig nicht testbar ist. Effektivität: Software, die nicht benötigt wird, sollte auch nicht benutzt werden. Projektführung Risikomanagement: Die Risiken erkennen, angemessene technische Maßnahmen (siehe oben) planen, durchsetzen und überprüfen. 8