Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

4.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.

Ähnliche Präsentationen


Präsentation zum Thema: "4.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."—  Präsentation transkript:

1 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

2 Folie 2 H. Schlingloff, Software-Engineering II Übersicht 1. Eingebettete Systeme 1.1. Definitionen 1.2. Anforderungsanalyse 1.3. Modellierung 1.4. Architektur - Hard- und Software-Aufbau - Fehlertoleranz 1.5. Automotive Software Engineering 2. Software-Qualität 2.1 Definitionen und Standards 2.2 Funktionstest Überdeckungsmaße, Integrations- und Abnahmetest, Spezifikationsformalismen, Verifikation und Modellprüfung, Metriken, Reviews, Qualitätsstandards (CMM/I) Hinweise Mi , Fr MBEES (Vorlesung entfällt)

3 Folie 3 H. Schlingloff, Software-Engineering II : Softwarequalität: Definitionen Qualität = Übereinstimmung mit den Anforderungen DIN : die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen Also z.B.: Funktionalität, Benutzbarkeit, Zuverlässigkeit, aber auch Preisgünstigkeit,... Qualitätsanforderungen: die Gesamtheit der Einzelanforderungen an eine Einheit, die die Beschaffenheit dieser Einheit betreffen Qualitätsmaße: stellen den Grad der Ausprägung eines Qualitätsmerkmals (numerisch) dar z.B. MTBF für Zuverlässigkeit

4 Folie 4 H. Schlingloff, Software-Engineering II Eigenschaften einer Funktionseinheit, anhand derer die Qualität beschrieben und beurteilt wird Funktionalität, Zweckdienlichkeit, Robustheit, Zuverlässigkeit, Sicherheit, Effizienz, Benutzbarkeit, Verfügbarkeit, Geschwindigkeit, Änderbarkeit, Portierbarkeit, Prüfbarkeit, … kann aus Teilmerkmalen bestehen Hersteller- und Nutzersicht verschiedene Optimierungsfunktionen oft gegensätzliche Optimierungskriterien die beste Qualität gibt es nicht

5 Folie 5 H. Schlingloff, Software-Engineering II Korrektheit, Sicherheit, Zuverlässigkeit… ANSI 72983: Grad der Übereinstimmung zwischen Spezifikation und Programm vgl. Definition von Qualität! ungeeignete Definition (ein wenig schwanger…) Korrektheit bedeutet Abwesenheit von Fehlern Software ist korrekt, wenn sie genau das in der Spezifikation festgelegte funktionale Verhalten zeigt also nicht: Wartbarkeit, Effizienz, Funktionalität, … als Qualitätsmaß schlecht geeignet Üblicherweise sind mehrere verschiedene korrekte Implementierungen einer Spezifikation möglich

6 Folie 6 H. Schlingloff, Software-Engineering II Sicherheit Sicher ist sicher ein vielstrapaziertes Wort… ISO 8402: Sicherheit = Zustand, in dem das Risiko eines Personen- oder Sachschadens auf einen annehmbaren Wert begrenzt ist was heißt annehmbar ? Ein System heißt sicherheitskritisch, wenn es beim Ausfall großen Schaden verursachen kann großer Schaden: Der Ausfallverlust übersteigt die regulären Betriebsgewinne um ein Vielfaches Sicherer Zustand ist nicht immer sicher… fail-safe, safe-stop, fail-silent, … Sicherheit durch Erfahrung ist problematisch Erfahrung hat man erst wenn das Kind in den Brunnen gefallen ist Systeme müssen sicher sein ohne dass etwas schief geht

7 Folie 7 H. Schlingloff, Software-Engineering II Safety ist nicht alles Safety vs. Security Security = Informationssicherheit / Geschütztheit - Security = Schutz vor böswilligen Schäden - Safety = Schutz vor unbeabsichtigten Schäden Manchmal direkt gegensätzliche Ziele - Kaufhauskunden verbrennen weil Türen verriegelt Safety vs. Liveness Formale Definitionen von Sicherheitseigenschaften safety = nothing bad will ever happen - Wenn die Eigenschaft verletzt ist, gibt es eine endliche Folge von Ereignissen die dies bewirkt liveness = something good will eventually happen - Jede endliche Folge von Ereignissen kann so erweitert werden, dass die Eigenschaft doch noch erfüllt ist

8 Folie 8 H. Schlingloff, Software-Engineering II Zuverlässigkeit / Verläßlichkeit Zuverlässigkeit (Reliability) ist ein Maß für die Fähigkeit des Systems, funktionstüchtig zu bleiben; Wahrscheinlichkeit, dass das System während einer bestimmten Zeitdauer t nicht versagt DIN 40041: Zuverlässigkeit ist die Beschaffenheit bezüglich der Eignung, während oder nach vorgegebenen Zeitspannen bei vorgegebenen Arbeitsbedingungen die Zuverlässigkeits- anforderungen zu erfüllen Verläßlichkeit (Dependability) = Grad der Vertrauenswürdigkeit in die vom System erbrachte Leistung (subjektive Wertung)

9 Folie 9 H. Schlingloff, Software-Engineering II Verläßlichkeit

10 Folie 10 H. Schlingloff, Software-Engineering II Dependability Verlässlichkei t Availability Verfügbarkeit Reliability Zuverlässigkeit Safety Sicherheit Mean Time to Failure (MTTF) Mittlere Laufzeit vor Ausfall Mean Time To Repair (MTTR) Risikobehandlung: erkennen, eliminieren, reduzieren, Folgen minimieren Maintainability Wartbarkeit

11 Folie 11 H. Schlingloff, Software-Engineering II Verfügbarkeit Maß für die durchschnittliche Erbringung der Funktionalität Kenngrößen MTTF = Mean Time to Failure MTTR = Mean Time To Repair Availability = MTTF / (MTTF + MTTR) Verfügbarkeit und Sicherheit sind oft gegensätzliche Ziele! Ein Auto, das niemals fährt, ist sicher: es geht keine Gefahr von ihm aus, es ist aber nicht brauchbar Ein Auto, das immer fahren kann, auch wenn es auseinanderfällt, hat die höchste Verfügbarkeit, ist aber nicht sicher

12 Folie 12 H. Schlingloff, Software-Engineering II Pause!

13 Folie 13 H. Schlingloff, Software-Engineering II Sicherheitsstandards und -normen beschreiben Vorgehensweisen, um die Sicherheit von Produkten zu erhöhen spezialisiert auf Branchen Beispiele: IEC 61508, Functional safety of electrical/electronic/programmable electronic safety- related systems CENELEC EN / / 50129, Railway Applications - the specification and demonstration of Reliability, Availability, Maintainability and Safety; Software for railway control and protection systems; Safety related electronic systems for signalling. DO 178-B, Software Considerations in Airborne Systems and Equipment Certification

14 Folie 14 H. Schlingloff, Software-Engineering II Beispiel IEC61508 Entwurf 1995/1998, Endfassung August 2002 Zielsetzung: Standard zur Beurteilung sicherheitsbezogener Systeme durch allgemeine Anforderungen zur funktionalen Sicherheit funktionale Sicherheit: der Teil der Sicherheit, der davon abhängt ob ein System oder Gerät auf Eingaben richtig reagiert Beispiele: Nothaltsystem, Förderbandkontrolle, x-by-wire, Motordrehzahlbegrenzer, Strahlungsdosierung, … Statt einer Betrachtung einzelner Komponenten (Sensor, Aktuator, Prozessor) Ausrichtung auf sicherheitsgerichtete Funktion Abdeckung aller relevanter Phasen im Lebenszyklus (Konzept, Design, Implementierung, Betrieb)

15 Folie 15 H. Schlingloff, Software-Engineering II Ursachen gefährlicher Ausfälle incorrect specifications of the system, hardware or software omissions in the safety requirements specification (e.g. failure to develop all relevant safety functions during different modes of operation) random failures of hardware systematic failures of hardware and software common cause failures human error environmental influences (e.g. electromagnetic, temperature, mechanical phenomena) supply system voltage disturbances (e.g. loss of supply, reduced voltages, re-connection of supply)

16 Folie 16 H. Schlingloff, Software-Engineering II Struktur IEC61508 Part 1: General requirements - documentation, conformance to the standard, management and assessment, as well as the technical requirements for achieving safety throughout the system life cycle Part 2: Requirements for E/E/PE safety-related systems (hardware) Part 3: Software requirements Part 4: Definitions and abbreviations Part 5: Examples of methods for the determination of safety integrity levels Part 6: Guidelines on the application Part 7: Overview of techniques and measures Überblick: Lesen!

17 Folie 17 H. Schlingloff, Software-Engineering II Grundannahme Equipment under Control (EUC) stellt immanente Gefährdung der Umgebung dar korrekte Steuerung allein garantiert keine Sicherheit Steuerung und Sicherung müssen getrennt betrachtet werden (z.B. separate Kabel)

18 Folie 18 H. Schlingloff, Software-Engineering II Risikobegriffe Risikominderung durch verschiedene Technologien möglich; von IEC61508 wird nur E/E/PE betrachtet


Herunterladen ppt "4.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."

Ähnliche Präsentationen


Google-Anzeigen