Grundlagen der Programmentwurfstechnik Fundamentals of Software Engineering 1

Transkript

1 Vorlesung 2 Fundamentals of Software Engineering 1 Inhaltsverzeichnis 1. Einführung 2. Allgemeine Modellbildung 3. Strukturierte Analyse 4. Strukturierter Entwurf von Echtzeit Systemen 5. Datenmodellierung 6. Benutzerschnittstellen und. Softwaretest 1

2 Inhaltsverzeichnis 1. Einführung 1.1 Einleitung 1.2 Geschichte der Software-Entwicklung 1.4 Der Software Lebenszyklus 141V Vorgehensmodelle 1.5 Systematische Projektplanung Quiz: Was ist Software/Software Engineering? 2

3 Katastrophen durch fehlerhafte Software Ariane - Programm Programm der Europäischen Weltraumorganisation Hauptunternehmer EADS Astrium Space Transportation Kommerzielles, unbemanntes Programm Erster Start Ariane 1: Geplanter erster Start Ariane 5: 4. Juni 1996 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 M.Euro 3

4 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. Bei der Ariane 5 gab es diese Anforderung nicht mehr! 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 Abgleichfunktion einen Wert, der wesentlich größer ist als erwartet. 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. Homogene Redundanz!! Die Software des Steuerrechners ist auf den Ausfall beider Trägheitsnavigationssysteme nicht ausgelegt und interpretiert die gemeldeten Fehlercodes als Flugbahndaten. 4

5 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. -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, diesie über ihre Umgebung macht, müssen dokumentiert 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. 5

6 -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. Das typische Software Projekt Im Jahr 1994: Dauer: ein bis zwei Jahre Größe: mindestens LOC (großes Projekt) Erfolgsquote: nur ca. 70 und 80 % aller Projekte werden erfolgreich abgeschlossen Effizienz: < 10 LOC / Tag am Projekt beteiligte Person Fehlerentdeckung - während der Entwicklung: ng Fehler/ LOC - nach Auslieferung: 4 Fehler/ LOC Die meisten von Benutzern gefundenen Fehler gehen auf Fehler in der Analyse und Design Phase zurück 6

7 Fachgebiet Quelle: Technische Spektrum Informatik der : Wissenschaft Grundlagen 12/94 der Programmentwurfstechnik. und heute?? % 16% 31% 16% 53% 53% Erfolgreich 16% Mängelbehaftet 53% Totalausfall 31% Erfolgreich16% Mängelbehaftet 53% Totalausfall 31% Quelle: Chaos Studie der Standish Group 7

8 Typ 1: erfolgreich Typ2: teilweise erfolgreich/mängelbehaftet Typ 3: nicht erfolgreich/abgebrochen Kostenentwicklung in Rechnersystemen Heute 20% Hardware 80% Software davon: 1/3 Entwicklung 2/3 Wartung 8

9 Kostenentwicklung in Rechnersystemen 3% Anforderungsanalyse 3% Spezifikation 5% Entwurf 7% Codierung 8% Modultest 7% Integrationstest 67% Wartung -Effekte von Fehlern im Herstellungsprozess - Spezifikation Entwurf Implementierung Abnahmetest 7% 27% 56% 9

10 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 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 10

11 1.4 Der Software Lebenszyklus 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 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 11

12 1.4 Der Software Lebenszyklus 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 12

13 1.5 Systematische Projektplanung Kaufmännische Aspekte 1.5 Systematische Projektplanung Das Pflichtenheft Das Pflichtenheft enthält eine Zusammenfassung aller fachlichen Basisanforderungen Soll ausschließlich die Sprache und Terminologie der Anwendungswelt verwenden Soll für Auftraggeber, Anwender und Anwendungsspezialisten lesbar sein Bleibt im Umfang auf das absolut notwendige Mindestmaß beschränkt Mögliche Gliederung Einführung Auftrag Problemanalyse Machbarkeit Gültigkeitsbereich des Pflichtenhefts Projektorganisation Phasenplan/Vorgehensmodell Ablaufkontrolle Vereinbarungen 13

14 Vertiefung Weiterführung CEFE AG 19 (1995): Klassische Fehler in der Software Entwicklung In Softwaretechnik Trends, Band 15 Heft 4, STEINMETZ, G. (1982). Was ist ein Pflichtenheft? In it - Information Technology, 24(1-6), pp Retrieved 26 Apr. 2017, from doi: /itit Barry W. Boehm: 14