Vorlesung 2 Fundamentals of Software Engineering 1 Inhaltsverzeichnis 1. Einführung 1.1 Einleitung 1.2 Geschichte der Software-Entwicklung 1.3 Software-Engineering Today 1.4 Software Projekte und Kosten 1.4 Der Software Lebenszyklus 1.4.1 Vorgehensmodelle 1.5 Systematische Projektplanung 1
1.3 Software-Engineering Today Katastrophen durch fehlerhafte Software Ariane - Programm Programm der Europäischen Weltraumorganisation Hauptunternehmer EADS Astrium Space Transportation Kommerzielles, unbemanntes Programm Erster Start Ariane 1: 24.12.1979 Geplanter erster Start Ariane 5: 4. Juni 1996 1.3 Software-Engineering Today Katastrophen durch fehlerhafte Software Beim Start der Ariane 5 am 4. Juni 1996 kam es zum Absturz Schaden Satelliten verloren: 600 M.Euro 2 Jahre Verzug im Entwicklungsprogramm: > 500 M.Euro 2 zusätzliche Erprobungsstarts bei Gesamtkosten des Projekts von 1987 bis 1998 von 6.700 M.Euro 2
1.3 Software-Engineering Today Katastrophen durch fehlerhafte Software 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 Abgleichfunktion, 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 1996. 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 Abgleichfunktion einen Wert, der wesentlich größer ist als erwartet. 1.3 Software-Engineering Today Katastrophen durch fehlerhafte Software 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ägheitsnavigationssystem 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. 3
1.3 Software-Engineering Today Katastrophen durch fehlerhafte Software 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. 1.3 Software-Engineering Today -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. 4
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. 1.4 Software Projekte und Kosten Quelle: Spektrum der Wissenschaft 12/94 Only 28% of software projects succeed these days, down from 34% a year or two ago. Outright failures [projects cancelled before completion] are up from 15% to 18%. The remaining 51% of software projects are seriously late, over budget and lacking features previously expected. Quelle: Chaos Report -Standish Group (2004) 5
Update: Erfolg und Misserfolg von Softwareprojekten Aus dem Bericht der Standish Group, Boston vom 23.April 2009 Erfolgreich 32% Totalausfall 24% Mängelbehaftet 44% Quelle: Goll, Methoden des Software Engineering, Springer 2012 1.4 Software Projekte und Kosten Kostenentwicklung in Rechnersystemen Heute 20% Hardware 80% Software davon: 1/3 Entwicklung 2/3 Wartung 6
1.4 Software Projekte und Kosten Kostenentwicklung in Rechnersystemen 3% Anforderungsanalyse 3% Spezifikation 5% Entwurf 7% Codierung 8% Modultest 7% Integrationstest 67% Wartung 1.4 Software Projekte und Kosten -Effekte von Fehlern im Herstellungsprozess - Spezifikation Entwurf Implementierung Abnahmetest 7% 27% 56% 7
1.4 Der Software Lebenszyklus Idee Anforderungsanalyse Imple- Spezifikation... P r o z Design e s s s c h r i t men- tierung t e. Test Systemintegration Produkt (vs. Ziel) Wartung Pflege Prozesse Projekt 1.4 Der Software Lebenszyklus 1.4.1 Vorgehensmodelle Sequentielles Life-Cycle Model [Winston Royce 1970] Unterteilung des Entwicklungsprozesses in Phasen sequentielle Abarbeitung der einzelnen Phasen Einzelne Phase können ineinander verzahnen Vorstudie Anforderungsanalyse Spezifikation der Anforderung Systementwurf Codierung Zeit konstruktive Tätigkeiten Modultest Integration Systemtest prüfende Tätigkeiten Betrieb und Wartung 8
1.4 Der Software Lebenszyklus 1.4.1 Vorgehensmodelle Vorstudie Anforderungsanalyse Spezifikation der Anforderung Systementwurf Codierung Modultest Betrieb und Wartung Integration Systemtest Das Wasserfallmodell nach Barry W. Boehm 1.4 Der Software Lebenszyklus 1.4.1 Vorgehensmodelle Das V-Modell Testfälle Anforderungsvalidierunvalidierung Entwurfs- Testvalidierung Anforderungsdefinition Testfälle Systemkonzeptvalidierung Systemdurchfürbarkeitskonzept Betrieb Pilotbetrieb/ Einführung Validierung konstruktive Aktivitäten Systemspezifikation/ Produktentwurf Komponentenentwurf Testfälle Testfälle Akzeptanztest/ Systemtest Integrationstest Verifikation prüfende Aktivitäten Testfälle Modulentwurf/ Code Einzeltest Zeit Das V-Modell nach Barry W. Boehm 9
1.4 Der Software Lebenszyklus 1.4.1 Vorgehensmodelle Schritt 1: identifiziere Ziele des Teilprodukts (Leistung, Funktionalität, Anpaßbarkeit,...) finde alternative Realisierungsmöglichkeiten (des Teilprodukts) finde Randbedingungen bei verschiedenen Alternativen kumulierte Kosten Risikoanalyse Risikoanalyse Schritt 2: evaluiere Alternativen (unter Berücksichtigung aller Alternativen) identifiziere und überwinde Risiken (durch Prototypen, Simulation,...) Fortschritt Zustimmung durch Reviews Schritt 4: Verbesserungsplan plane den nächsten Zyklus überprüfe die nächsten 3 Schritte (im nächsten Zyklus) sichere Einverständnis mit Beteiligten Risikoanalyse Risikoanalyse P1 Prototyp 2 Feinentwurf Anforderungsplan, Lebenszyklusplan Entwicklungs- plan Integration Entwurfsprüfung und Testplan Software Produktentwurf Abnahmetest und Einführung Integration und Test Prototyp 3 Betriebsfähiger Prototyp Konzept Soft- für den ware- Betrieb Anforddefinition Anforderungs- prüfung Modul codieren Modultest Das Spiral-Modell nach Barry W. Boehm Schritt 3: lege Prozessmodell fest (in abhängig vom Risiko) wende Prozessmodell an, bzw. entwickele nächste Produktstufe 1.5 Systematische Projektplanung Problem Voranalyse techn Entwurf sinnvoll? ja Pflichtenheft machbar ja funkt. Entwurf nein nein Abbruch Abbruch Codieren Testen Zusammenführen Inbetriebnahme nein Abnahme? Ja Abbruch Neubeginn Implem.? ja nein Abbruch Einsatz 10
1.5 Systematische Projektplanung Kaufmännische Aspekte Inhaltsverzeichnis 1. Einführung - Klassische Konzepte des Software Engineering- g 2.1 Aspekte der Modellbildung 2.2 Das Kontextmodell 2.3 Zustandsmodelle 2.4 Entscheidungstabellen 2.5 Datenmodelle 3. Strukturierte Analyse 4. Strukturierter Entwurf (SE) 5. Benutzersschnittstellen 6. Softwaretest 11
2.1 Aspekte der Modelbildung Übersicht: Basismethoden zur Systemmodellierung Quelle: Prof. Dr.-Ing. Dr. h. c. P. Göhner Universität Stuttgart Überblick: Klassische Systemmodelle Architekturmodelle Beispiele beschreiben die grundlegenden Elemente und die Struktur eines Softwaresystems Verhaltensmodelle beschreiben das Verhalten eines Softwaresystems Regelbasierte Modelle beschreiben die Entscheidungen bei ereignisgesteuerten Softwaresystemen Datenmodelle beschreiben die Daten und Datenstrukturen eines Softwaresystems Objektmodelle beschreiben das Softwaresystem mittels Klassen und Objekten Kontextmodell Funktionales Modell/ Funktionsbaum Zustandsmodell/Automaten Datenflussdiagramme Entscheidungstabellen EntityRelationship Modell Datenkatalog Klassenmodell Vererbungsmodell Interaktionsmodell 12
2.2 Das Kontextmodell Das Kontextmodell beschreibt die Systemumgebung und Systemgrenzen grenzt die internen Systemteile gegen die externen Elemente ab Notation das System der Terminator in der Systemumgebung Hinweis: Das Kontextmodell/- diagramm wird in späteren Kapiteln noch im Detail besprochen Verbindung/Daten 2.3 Zustandsmodelle Rückblick: Grundlagen der technischen Informatik 1 Fundamentals of Computer Engineering 1 X: Eingabemenge/Vektor Y: Ausgabemenge/Vektor Z: Zustandsmenge/Vektor X Z Y Eingangsvektor:X n Zustandsvektor:Z n Übergangsfunktion: g(x n,z n ) Folgevektor: Z n+1 = g(x n,z n ) Ausgangsfunktion: f(x n,z n ) Ausgangsvektor: Y n = f(x n,z n ) x 1 x k Z y 1 y l 13
2.3 Zustandsmodelle Mealy Automat X n g Zn+1 Spei- cher Z n f Y n X n f,g Y Ausgabefunktion T Y n = f(x n,z n ) Übergangsfunktion Z n+1 = g(x n,z n ) Moore Automat X n g Z n+1 Speicher Z n Z n+1 n Speicher h Z n Y T Ausgabefunktion Y n = h(z n T ) Übergangsfunktion Z n+1 = g(x n,z n ) 2.3 Zustandsmodelle Zustandsdiagramme 14
2.3 Zustandsmodelle Die Zustandsmatrix die Zustandsmatrix wird auch Automatentafel/Automatentabelle genannt. die Zeilen der Matrix beziehen sich auf die Zustände die Spalten der Matrix beziehen sich auf die Ereignisse. Zwei verschiedene Automatentypen Mealy-Automaten: für alle Matrixelemente werden jeweils ein Folgezustand und eine Aktion angegeben die Aktionen werden in Abhängigkeiten gg von den jeweiligen Zustandsübergängen ausgeführt werden. Moore-Automaten: Aktionen sind lediglich Funktionen der Zustände. für alle, von einem bestimmten Zustand ausgehenden Übergänge wird dieselbe Aktion ausgeführt. 2.3 Zustandsmodelle Zustandsmatrix eines Mealy Typs: Aktion ist einem Zustandswechsel zugeordnet 15
2.3 Zustandsmodelle Zustandsmatrix eines Moore Typs: Aktion ist einem Zustand zugeordnet 2.3 Zustandsmodelle Beispiel/Übung 1: Erstelle das (vereinfachte) Zustandsmodell für das System Fahrkartenautomat Angenommener Ablauf : 1. Wahl eines Tarifs 2. Wahl eines Zielbahnhofs 3. Vollständige Bezahlung 4. Fahrkarte ggfs. Restgeld entnehmen 5. Abbruch jederzeit möglich 16
2.4 Entscheidungstabellen Regel-basierte Verhaltensmodellierung von ereignisgesteuerten Systemen Basis einer algorithmisch formalisierten Beschreibung Systemfunktionen werden als Regel dargestellt, und sind zusammengesetzt aus Bedingungen und resultierenden Aktionen 2.4 Entscheidungstabellen e.) Regeln: jede Spalte beschreibt, aus welchen einzelnen Bedingungen sich die Erfüllung einer Regel ergibt (Bedingungsanzeigeteil) und welche Aktion ausgelöst wird, wenn diese Regel erfüllt ist (Aktionsanzeigeteil) a) Bedingungsteil: hier werden sämtliche Bedingungen, die für das vorliegende Problem relevant sind, formuliert b) Aktionsteil: hier werden alle möglichen Aktionen aufgelistet c) Bedingungsanzeigeteil: zur Zuordnung der einzelnenbedingungen zu den Regeln d) Aktionsanzeigeteil: zur Zuordnung bestimmter Aktionen zu den Regeln 17