Скачать презентацию Software in sicherheitsrelevanten Systemen Ralf Pinger Stefan Скачать презентацию Software in sicherheitsrelevanten Systemen Ralf Pinger Stefan

c72f15533efa625dc11dcfa0e8b06830.ppt

  • Количество слайдов: 87

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013 Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

Kapitel 6 - Software für sicherheitsrelevante Systeme Inhaltsübersicht 1. 2. 3. 4. 5. 6. Kapitel 6 - Software für sicherheitsrelevante Systeme Inhaltsübersicht 1. 2. 3. 4. 5. 6. 7. CENELEC EN 50128 – eine Gebrauchsanleitung Anforderungen SW-Entwicklungsmethoden SW-Test Qualitätssicherung von Entwicklungswerkzeugen Page 2 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 1 CENELEC § CENELEC ist das Europäische Normungskomitee für Elektrotechnik (Comité Européen de 6. 1 CENELEC § CENELEC ist das Europäische Normungskomitee für Elektrotechnik (Comité Européen de Normalisation Électrotechnique). § In der CENELEC sind die nationalen Normungskomitees von vielen europäischen Staaten vertreten (z. B. DKE - Deutsche Kommission Elektrotechnik, Elektronik, Informationstechnik im DIN und VDE). § In diesen Staaten werden nationale Normen durch CENELEC-Normen sukzessive ersetzt. § Die CENELEC hat unter anderem Normen zur funktionalen Sicherheit im Bahnbereich veröffentlicht Page 3 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 1 CENELEC – Struktur der Bahnnormen Page 4 3/15/2018 Ralf Pinger / Stefan 6. 1 CENELEC – Struktur der Bahnnormen Page 4 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 1 CENELEC Page 5 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten 6. 1 CENELEC Page 5 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 1 CENELEC – Lebenszyklus nach EN 50126 Für jede Phase werden definiert • 6. 1 CENELEC – Lebenszyklus nach EN 50126 Für jede Phase werden definiert • • • Ziele Input (Dokumente) Anforderungen Output (Dokumente) Verifikationsaufgaben Der Lebenszyklus umfaßt wesentlich mehr als nur die Entwicklung und beinhaltet Aufgaben für Hersteller und Betreiber! Bild: EN 50126 Page 6 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 1 CENELEC- Obligatorische Anforderungen CENELEC EN 50126 ist seit 1. 4. 2000 in 6. 1 CENELEC- Obligatorische Anforderungen CENELEC EN 50126 ist seit 1. 4. 2000 in allen CENELECMitgliedsländern als nationale Norm in Kraft gesetzt. § § Kompetenznachweise § Ausarbeitung und Durchführung eines RAM Programms § Ausarbeitung und Durchführung eines Sicherheitsplans § Implementierung eines EN 50126 und ISO 900 x konformen Geschäftsprozesses § Page 7 Klar definierte Verantwortlichkeit für RAMS-Aufgaben Effektives Konfigurationsmanagement für RAMS-Aufgaben 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – aktueller Stand der Normung § Aktuell EN 50128 06/2011 6. 2 EN 50128 – aktueller Stand der Normung § Aktuell EN 50128 06/2011 veröffentlicht § Die Überarbeitung der EN 50126 ist in Vorbereitung § Die neue EN 50126 soll die EN 50128 als eigenen Teil enthalten Page 8 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – eine Gebrauchsanleitung § Normen sind keine Gesetze und haben 6. 2 EN 50128 – eine Gebrauchsanleitung § Normen sind keine Gesetze und haben nur Empfehlungscharakter § Haben einen definierten Sprachgebrauch (hier DIN) positiv negativ Anforderung (requirement) muss shall darf nicht shall not Empfehlung (recommendation) sollte should sollte nicht should not Zulässigkeit (permission) darf may braucht nicht need not Möglichkeit (possibility) kann can kann nicht cannot Page 9 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Anwendungsbereich § Verfahren und technische Anforderungen für die Entwicklung 6. 2 EN 50128 – Anwendungsbereich § Verfahren und technische Anforderungen für die Entwicklung von programmierbaren elektronischen Systemen § gesamter Bereich der Sicherheitsanwendungen § gilt für jegliche sicherheitsrelevante Software, die in Eisenbahnsteuerungs- und überwachungssystemen verwendet wird, einschließlich: § Anwendungsprogrammierung; § Betriebssysteme; § unterstützende Werkzeuge; § Firmware. Anwendungsprogrammierung schließt Programmierung in Hochsprache, Maschinensprache und speziellen Anwendungssprachen ein (z. B. : ladder logic bei speicherprogrammierbaren Steuerungen). § gilt auch für Änderungen und Erweiterungen an bestehender Software Page 10 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Aufbau der Norm q q q Normativer Textteil Normative 6. 2 EN 50128 – Aufbau der Norm q q q Normativer Textteil Normative Anhänge A, B Informativer Anhang C, D Anhang A Auswahl von Methoden und Normativer Text el Kapit Techniken Refe renz Anhang B ) Anhang C Schlüsselrollen und Zusammenfassung der Verantwortlichkeiten Dokumentenkontrolle Page 11 3/15/2018 en ( D. nn Ralf Pinger / Stefan Gerken Anhang D Informationen zu Methoden / Techniken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 1: Normativer Textteil 7. 2 Software-Anforderungen 7. 2. 6. 2 EN 50128 – Beispiel 1: Normativer Textteil 7. 2 Software-Anforderungen 7. 2. 1 Ziele 7. 2. 1. 1 Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt. 7. 2. 1. 2 Beschreibung der Gesamtsoftware-Testspezifikation. 7. 2. 2 Eingangsdokumente 1) System-Anforderungsspezifikation … 7. 2. 3 Ausgangsdokumente 1) Software-Anforderungsspezifikation. . . 7. 2. 4 Anforderungen 7. 2. 4. 1 Eine Software-Anforderungsspezifikation muss unter der Verantwortung des Anforderungsmanagers auf der Grundlage der Eingangsdokumente nach 7. 2. 2 erstellt werden. Die Anforderungen in 7. 2. 4. 2 bis 7. 2. 4. 15 beziehen sich auf die Software. Anforderungsspezifikation. 7. 2. 4. 2 Die Software-Anforderungsspezifikation muss die geforderten Eigenschaften der zu entwickelnden Software darstellen. Diese Eigenschaften, die alle in der Normenreihe ISO/IEC 9126 (mit Ausnahme der Sicherheit) definiert sind, müssen einschließen: … 7. 2. 4. 3 Der Software-Sicherheits-Integritätslevel muss nach der Definition in Abschnitt 4 abgeleitet und in der Software-Anforderungsspezifikation festgehalten werden. Page 12 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – SSAS q SSAS heiß Softwaresicherheitsanforderungsstufe (SIL) q SSAS = 6. 2 EN 50128 – SSAS q SSAS heiß Softwaresicherheitsanforderungsstufe (SIL) q SSAS = SIL der Systemfunktionen m m q 5 SIL-Stufen Þ 0 = nichtsichere Anwendungen Þ 1 = niedrigste Anforderungsstufe Þ 4 = höchste Anforderungsstufe 2 Klassen für sichere Anwendungen (1, 2) und (3, 4) Maßnahmen sind notwendig bei unter-schiedlichen SSAS innerhalb eines Systems Page 13 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 1 aus Anhang A Page 14 3/15/2018 Ralf 6. 2 EN 50128 – Beispiel 1 aus Anhang A Page 14 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 1 aus Anhang D D. 13 Entscheidungstabellen (Wahrheitstabellen) 6. 2 EN 50128 – Beispiel 1 aus Anhang D D. 13 Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables)) Ziel Erstellen einer klaren und zusammenhängenden Spezifikation und Analyse komplexer logischer Kombinationen und Beziehungen. Beschreibung Diese verwandten Verfahren benutzen zweidimensionale Tabellen zur Kurzdarstellung logischer Beziehungen zwischen boolschen Programmvariablen. Durch die Kürze und die tabellarische Form eignen sich beide Verfahren zur Analyse komplexer logischer Kombinationen, ausgedrückt in codierter Form. Beide Verfahren können ausführt werden, falls sie als Spezifikation benutzt werden. Page 15 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 2 aus Anhang A Quelle: EN 50128 Page 6. 2 EN 50128 – Beispiel 2 aus Anhang A Quelle: EN 50128 Page 16 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung) Quelle: EN 50128 6. 2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung) Quelle: EN 50128 Page 17 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 2 aus Anhang D Quelle: EN 50128 Page 6. 2 EN 50128 – Beispiel 2 aus Anhang D Quelle: EN 50128 Page 18 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung) Fortsetzung D. 54 6. 2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung) Fortsetzung D. 54 Quelle: EN 50128 Page 19 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 Quelle: EN 50128 Page 20 3/15/2018 Ralf Pinger / Stefan 6. 2 EN 50128 Quelle: EN 50128 Page 20 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Prozess Ver Val Phase Ergebnisse Quelle: EN 50128 Page 6. 2 EN 50128 – Prozess Ver Val Phase Ergebnisse Quelle: EN 50128 Page 21 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Dokumente / Ergebnisse m Definitionen / Anforderungen zu den 6. 2 EN 50128 – Dokumente / Ergebnisse m Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil) m Vorgaben von Maßnahmen und Tools (Anhang A) m Vorgaben zu Kompetenzprofilen (Anhang B) m Vorgaben zu Reviews (Verifikation) m Verfolgbarkeit der Anforderungen Page 22 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Rollen und Unabhängigkeiten Anerkannter Fachbetrieb: Der Gutachter kann auch 6. 2 EN 50128 – Rollen und Unabhängigkeiten Anerkannter Fachbetrieb: Der Gutachter kann auch der entwickelnden Firma unterstellt sein, wenn eine ausreichende Unabhängigkeit zur entwickelnden Abteilung gewährleistet ist Voraussetzung: Anerkennung durch Zulassungsbehörde wie z. B. EBA Quelle: EN 50128 Page 23 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Aufgaben und Rollen Quelle: EN 50128 Page 24 3/15/2018 6. 2 EN 50128 – Aufgaben und Rollen Quelle: EN 50128 Page 24 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Verifikation und Validierung Verifikation: Untersuchungsprozess mit anschließender, auf Wird 6. 2 EN 50128 – Verifikation und Validierung Verifikation: Untersuchungsprozess mit anschließender, auf Wird richtig entwickelt Nachweisen beruhender Beurteilung, dass die Ergebnisse (Prozess, Dokumentation, Software oder Anwendung) einer bestimmten Entwicklungsphase die Anforderungen dieser Phase hinsichtlich Vollständigkeit, Richtigkeit und Konsistenz erfüllt DIN EN 50128, März 2012 Ist das Richtige entwickelt worden? Validierung: Analyseprozess gefolgt von einer auf Nachweisen beruhenden Beurteilung, ob ein Objekt (z. B. Prozess, Dokumentation, Software oder Anwendung) den Bedarf des Nutzers erfüllt, insbesondere bezüglich Sicherheit und Qualität, sowie mit einem Schwerpunkt auf die betriebliche Eignung für den Verwendungszweck in der vorgesehenen Betriebsumgebung DIN EN 50128, März 2012 Page 25 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 2 EN 50128 – Zusammenfassung m Vorgaben für den Entwicklungsprozess m Festlegung von 6. 2 EN 50128 – Zusammenfassung m Vorgaben für den Entwicklungsprozess m Festlegung von Maßnahmen und Tools m Anforderungen an Dokumente m Unabhängige Stellen Page 26 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3 Anforderungen – Inhaltsübersicht 1. 2. 3. 4. 5. 6. 7. Anforderungsmanagement Ermittlung 6. 3 Anforderungen – Inhaltsübersicht 1. 2. 3. 4. 5. 6. 7. Anforderungsmanagement Ermittlung von Anforderungen Rapid Prototyping Verfolgung von Anforderungen Identifikation von Anforderungen Umsetzung von Anforderungen Nachweis von Anforderungen Page 27 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3 Anforderungen – Ziele der EN 50128 § Beschreibung eines vollständigen Satzes von 6. 3 Anforderungen – Ziele der EN 50128 § Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt. § In dem durch den Software-Sicherheits-Integritätslevel festgelegten Umfang muss die Software-Anforderungsspezifikation so formuliert und strukturiert werden, dass sie vollständig, klar, genau, eindeutig, verifizierbar, testbar, wartbar und umsetzbar ist und auf alle Eingangsdokumente rückverfolgbar. § Beschreibung der Gesamtsoftware-Testspezifikation. Page 28 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 1 Anforderungsmanagement Management etymologisch: manage 1560 s, probably from Italian maneggiare 6. 3. 1 Anforderungsmanagement Management etymologisch: manage 1560 s, probably from Italian maneggiare "to handle, " especially "to control a horse, " from Latin manus "hand". Influenced by French manège "horsemanship" (earliest English sense was of handling horses), which also was from the Italian. Extended to other objects or business from 1570 s. Slang sense of "get by" first recorded 1650 s. management 1598, "act of managing, " from manage. Meaning "governing body" (originally of a theater) is from 1739. Manager is 1588 in the sense of "one who manages; " specific sense of "one who conducts a house of business or public institution" is from 1705. Quelle: http: //www. etymonline. com Page 29 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 1 Anforderungsmanagement – Motivation fehlende oder falsche Anforderungen § § haben Auswirkungen 6. 3. 1 Anforderungsmanagement – Motivation fehlende oder falsche Anforderungen § § haben Auswirkungen auf das gesamte Produkt werden üblicherweise erst bei Inbetriebnahme oder später erkannt gefährden die erfolgreiche Abnahme des Produkts können Auswirkungen auf die gesamte Architektur haben Änderungen sind entsprechend kostspielig Anforderungsmanagement § § ist eine Managementaufgabe zielt auf Effizienz zielt auf Fehlerarmut ordnet das Chaos Page 30 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 2 Ermittlung von Anforderungen Ziel der Anforderungsermittlung: § Erkennen der Anforderungen des 6. 3. 2 Ermittlung von Anforderungen Ziel der Anforderungsermittlung: § Erkennen der Anforderungen des Kunden Das bedeutet: § § § § Definition der Systemgrenzen Definition der Schnittstellen Definition der zu erbringenden Systemfunktionen Definition der Umgebungsbedingungen Definition der zu unterstützenden Kundenprozesse Definition der gesetzlichen Rahmenbedingungen Definition der wirtschaftlichen Rahmenbedingungen … Page 31 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 2 Ermittlung von Anforderungen Häufige Probleme § § Mensch § Sprache (Domäne 6. 3. 2 Ermittlung von Anforderungen Häufige Probleme § § Mensch § Sprache (Domäne vs. SW-Experte) § Divergierende Meinungen von Stakeholdern § Motivation zur Unterstützung Organisationen § Produktstrategie § Verfügbarkeit von Stakeholdern Fachlicher Inhalt § Kritikalität des Systems § Systemumfang § Unterschiedliche Detaillierung von Anforderungen § Nicht funktionale Anforderungen § Methoden Und vieles mehr Page 32 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 2 Ermittlung von Anforderungen Bewertung der Anforderungen: § Korrektheit § Vollständigkeit § 6. 3. 2 Ermittlung von Anforderungen Bewertung der Anforderungen: § Korrektheit § Vollständigkeit § Machbarkeit § Bewertung, ob Kundenanforderung § Wichtigkeit § Kosten Page 33 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 3 Rapid Prototyping § kommt eigentlich aus dem Maschinenbau § beschreibt den 6. 3. 3 Rapid Prototyping § kommt eigentlich aus dem Maschinenbau § beschreibt den schnellen Musterbau § ist als Software Engineering Methode adaptiert worden § wird in Verbindung mit agilen Vorgehensweisen eingesetzt § kann auch zur Anforderungsermittlung eingesetzt werden Page 34 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 3 Rapid Prototyping Vorteile § § § ausführbares Anforderungsmodell macht das System 6. 3. 3 Rapid Prototyping Vorteile § § § ausführbares Anforderungsmodell macht das System „erlebbar“ Ausführbares Testmodell als Diskussionsgrundlage mit dem Kunden dienen Anforderungsmodell kann als Testmodell verwendet werden Nachteile § § § Anforderungsmodell orientiert sich an einer Spezifikation oder Kundengesprächen Anforderungsmodell ist nicht architekturgetrieben Anforderungsmodell erzeugt den Eindruck doppelter Entwicklung Page 35 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 3 Vom Rapid Prototype zum Design-Modell Page 36 3/15/2018 Ralf Pinger / 6. 3. 3 Vom Rapid Prototype zum Design-Modell Page 36 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 3 Analyse-/Design-Modell Analyse-Modell: Design-Modell: § schneller Prototyp § Verständlichkeit/Wartbarkeit § keine vollständige 6. 3. 3 Analyse-/Design-Modell Analyse-Modell: Design-Modell: § schneller Prototyp § Verständlichkeit/Wartbarkeit § keine vollständige Durchdringung der Anforderungen notwendig § Einfache Lösungen entstehen in der Regel nicht im ersten Ansatz! § Anforderungsfehler werden frühzeitig offenbart § Hohe Durchdringung der Anforderungen notwendig § Schnelle Anpassbarkeit an Kundenänderungen (agil) § Architektur muss weitgehend bekannt sein § Ausprägungen: § Wegwerfprototyp § (Neu-) Entwicklung § … § Refaktorisierung bis zum Produkt § Refaktorisiert aus Analyse-Modell Page 37 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 4 Verfolgung von Anforderungen Ziele sind Identifikation von: § § Verfeinerungen Realisierungen 6. 3. 4 Verfolgung von Anforderungen Ziele sind Identifikation von: § § Verfeinerungen Realisierungen Wechselwirkungen Nachweisen Nebenwirkungen der Identifikation: § § Änderungsauswirkungsanalyse Regressionstests Fehleranalyse Kostenabschätzung für Änderungen Page 38 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 5 Identifikation von Anforderungen Anforderung bedarf § § einer eindeutigen Bezeichnung (z. 6. 3. 5 Identifikation von Anforderungen Anforderung bedarf § § einer eindeutigen Bezeichnung (z. B. Text, Nummer, Identifikator) eines vereinbarten Zwecks, z. B. § define § refine § implement § test § safety § RAM § motive § annotation § version um die Verfolgbarkeit und Nachvollziehbarkeit zu gewährleisten Page 39 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 6 Umsetzung von Anforderungen Arten der Umsetzung § Artefakte § Modellierung § 6. 3. 6 Umsetzung von Anforderungen Arten der Umsetzung § Artefakte § Modellierung § Programmierung § Dokumente § Verfeinerung der Anforderungen durch neue Anforderungen § Umsetzen nicht-funktionaler Anforderungen durch Prozesse Page 40 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 3. 7 Nachweis von Anforderungen Zielgruppen: § § § Kunde Gutachter Zulassungsbehörde Methoden: 6. 3. 7 Nachweis von Anforderungen Zielgruppen: § § § Kunde Gutachter Zulassungsbehörde Methoden: § Analyse § Sicherheitsnachweise § RAM-Nachweise § Qualitätsnachweise § Testberichte Page 41 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4 SW-Entwicklungsmethoden – Inhaltsübersicht 1. 2. 3. 4. Konventionelle Entwicklungsmethoden Halb-formale Entwicklungsmethoden Formale 6. 4 SW-Entwicklungsmethoden – Inhaltsübersicht 1. 2. 3. 4. Konventionelle Entwicklungsmethoden Halb-formale Entwicklungsmethoden Formale Entwicklungsmethoden Modellbasiertes Software-Engineering Page 42 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4 SW-Entwicklungsmethoden – Ziele der EN 50128 SW-Architektur & SW-Entwurf und Design § 6. 4 SW-Entwicklungsmethoden – Ziele der EN 50128 SW-Architektur & SW-Entwurf und Design § § § § Entwickeln einer Software-Architektur Überprüfen der Anforderungen an die System-Architektur Feststellen und Bewerten, der Wechselwirkungen zwischen Hardware und Software Auswahl eines Entwurfsverfahrens Entwurf und Implementierung von Software, die analysierbar, testbar, verifizierbar und wartbar ist Auswahl eines für die geforderte Software-Sicherheitsanforderungsstufe angemessenen Satzes von Werkzeugen Durchführung der Softwareintegration Page 43 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 1 Konventionelle Entwicklungsmethoden – Beispiele Konventionelle Entwicklungsmethoden § § § § VHIDT 6. 4. 1 Konventionelle Entwicklungsmethoden – Beispiele Konventionelle Entwicklungsmethoden § § § § VHIDT – Vom Hirn in die Tastatur Strukturierte Verfahren (laut EN 50128) § JSD - Jackson System Development § MASCOT - Modular Approach to Software Construction, Operation and Test § SADT - Structured Analysis and Design Technique § SDL § SSADM § Yourdon - Real-time Yourdon Modulares Vorgehen Entwurfs- und Codierstandards Streng typisierte Programmiersprache Strukturierte Programmierung Objektorientierte Programmierung Page 44 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 2 Modellierung – Beispiele Methoden der Modellierung aus der EN 50128 § 6. 4. 2 Modellierung – Beispiele Methoden der Modellierung aus der EN 50128 § § § § § Datenmodellierung Datenflussdiagramme Kontrollflussdiagramme Endliche Zustandsmaschinen/Zustandsübergangsdiagramme Zeit-Petri-Netze Entscheidungs-/Wahrheitstabellen Formale Methoden Leistungsmodellierung Strukturdiagramme Ablaufdiagramme Page 45 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 3 Formale Entwicklungsmethoden – Beispiele Formale Entwicklungsmethoden aus der EN 50128 § 6. 4. 3 Formale Entwicklungsmethoden – Beispiele Formale Entwicklungsmethoden aus der EN 50128 § § § § § CSP - Communicating Sequential Processes CCS - Calculus of Communicating Systems HOL - Higher Order Logic LOTOS - Language for Temporal Ordering Specification OBJ – ist eine algebraische Spezifikationssprache Temporal Logic VDM - Vienna Development Method Z B Model Checking Page 46 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering – Ursprünge § Erste Ansätze in den 80 er 6. 4. 4 Modellbasiertes Software-Engineering – Ursprünge § Erste Ansätze in den 80 er Jahren mit den CASE-Tools § Modellierungselemente waren: SA/SD § Es gab viele Erfolge mit CASE-Tools § Qualitätsverbesserung § Bessere Beherrschung der Komplexität § Mehr Abstraktion mehr Plattformunabhängigkeit § Die CASE-Tools hatten aber auch noch einige Unzulänglichkeiten § Roundtrip-Engineering nicht möglich § Formale Verifikation noch nicht ausgereift § Tool-Entwicklung war nicht fortschrittlich genug § Modellelemente waren für viele Probleme nicht ausreichend Page 47 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering – Erläuterung Modellbasierte Entwicklung definiert: § n Hierarchieebenen § 6. 4. 4 Modellbasiertes Software-Engineering – Erläuterung Modellbasierte Entwicklung definiert: § n Hierarchieebenen § auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache § Transformationen zwischen den Hierarchieebenen § möglichst weitgehende Automatisierung der Transformationen Page 48 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering 29. text 30 0027 90. p 2 align 2, 6. 4. 4 Modellbasiertes Software-Engineering 29. text 30 0027 90. p 2 align 2, , 3 31. globl main 32. type main, @function 33 main: 34 0028 55 pushl %ebp 35 0029 89 E 5 movl %esp, %ebp 36 002 b 83 EC 08 subl $8, %esp 37 002 e 83 E 4 F 0 andl $-16, %esp 38 0031 83 EC 0 C subl $12, %esp 39 0034 680 E 0000 pushl $. LC 1 39 00 40 0039 C 7050000 movl $3, a 40 00000300 41 0043 E 8 FCFFFF call puts 41 FF 42 0048 C 7042404 movl $4, (%esp) Page 49 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering void Step(void) { input. Aktuelle. Zeit. time. X = 6. 4. 4 Modellbasiertes Software-Engineering void Step(void) { input. Aktuelle. Zeit. time. X = Get. Tick. Count() - starttime; tbl_display. hour = timeinfo->tm_hour; tbl_display. min = timeinfo->tm_min; if ((stepcount > 1000) && (output. Starte. Daily. Test)) { input. Daily. Test. Result. vorhanden = kcg_true; input. Daily. Test. Result = DT_ok_TBL 1 p_Types; } write. SSS(&input); do{ stepcount = stepcount + 1; TBL 1 p_Main. Mixer(&input, &output); output 2 display(); } while(!output. Habe. Fertig); } Page 50 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering Page 51 3/15/2018 Ralf Pinger / Stefan Gerken Software 6. 4. 4 Modellbasiertes Software-Engineering Page 51 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering – Motivation § Logisch funktionale Inhalte auf hoher Abstraktionsebene 6. 4. 4 Modellbasiertes Software-Engineering – Motivation § Logisch funktionale Inhalte auf hoher Abstraktionsebene § Unabhängig von konkreter Hardwareplattform lange Produktlebenszyklen § Effizienzsteigerung in der Entwicklung § Frühzeitige Fehleroffenbarung § stärkere Verknüpfung von Implementierung und Dokumentation § Qualitätssteigerung § Einsatz von Analysewerkzeugen (z. B. Model Checker) Nachweis von Eigenschaften § Unterstützung der Zertifizierung von Systemen Page 52 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering – Abgrenzung Eigenschaften der modellbasierten Entwicklung (1) § § 6. 4. 4 Modellbasiertes Software-Engineering – Abgrenzung Eigenschaften der modellbasierten Entwicklung (1) § § § § Verwendung von Modellen zur Softwareentwicklung um die Abstraktion zu erhöhen Verwendung von Generatoren/Transformatoren bei der Softwareentwicklung Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung zwischen 20% und 100%) Die erste Abstraktionsebene wird vollständig manuell erzeugt Ziel ist die Steigerung der Softwarequalität bzw. -effizienz Schlagwort „Automation durch Formalisierung“ in frühen Entwicklungsphasen Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach Literaturquelle voneinander ab Page 53 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering – Abgrenzung Eigenschaften der modellbasierten Entwicklung (2) § § 6. 4. 4 Modellbasiertes Software-Engineering – Abgrenzung Eigenschaften der modellbasierten Entwicklung (2) § § § § Die Modelltransformation erzeugt Modelle zur manuellen Weiterbearbeitung MDA erfordert anwendungsspezifische Frameworks MDA erfordert plattformspezifische Generatoren MDA kann - abhängig von der Vollständigkeit der Codegenerierung – auch änderungsunfreundlich sein MDA sagt nichts über den Abstraktionsgrad der Ebenen aus Ebenen können aufeinander aufbauen. Logische Fortsetzung des Abstraktionsgedankens bei der Entwicklung – manuelle Drahtverbindung, Maschinencode, Assembler, Programmiersprache, Modellierungssprache Page 54 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4. Modellbasiertes Software-Engineering Page 55 3/15/2018 Ralf Pinger / Stefan Gerken Software 6. 4. 4. Modellbasiertes Software-Engineering Page 55 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 4. 4 Modellbasiertes Software-Engineering § Ausdehnung der Abstraktionsidee auf gesamten Prozess § Entwicklung: 6. 4. 4 Modellbasiertes Software-Engineering § Ausdehnung der Abstraktionsidee auf gesamten Prozess § Entwicklung: § UML entwickelt sich zur industriellen Standardsprache § SCADE für sicherheitsrelevante Systeme geeignet § kommerzielle Werkzeuge im industriellen Einsatz bewährt § Testen/Analyse: § UML entwickelt sich zur industriellen Standardsprache § kaum geeignete, kommerzielle Werkzeuge am Markt § sehr großes Potenzial vor allem in der Sicherungstechnik Page 56 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5 SW-Test – Inhaltsübersicht 1. 2. 3. 4. 5. Konventionelle Testmethoden (halb-)automatisierte Testmethoden 6. 5 SW-Test – Inhaltsübersicht 1. 2. 3. 4. 5. Konventionelle Testmethoden (halb-)automatisierte Testmethoden modellbasierte Testmethoden analytische Methoden Testende-Kriterien Page 57 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5 Testmethoden – Motivation Herausforderung des Testens: § Der Testling besitzt einen großen 6. 5 Testmethoden – Motivation Herausforderung des Testens: § Der Testling besitzt einen großen internen Zustandsraum (vielleicht 21000 interne Zustände) § Testfälle sind separat zu erstellen § 215 manuell erstellte Testfälle sind schon sehr viel, aber bestimmt nicht erschöpfend § nur ein kleiner Teil des Verhaltens wird getestet Page 58 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 1 Konventionelle Testmethoden Excel-basiert, Ringbuch-Ordner oder einfach die Waldabholz-Methode § § Testfälle 6. 5. 1 Konventionelle Testmethoden Excel-basiert, Ringbuch-Ordner oder einfach die Waldabholz-Methode § § Testfälle sind in einer Tabelle aufgelistet Eingabewerte, Ausführungsbeschreibung, Erwartungswert Testausführung erfolgt manuell § Einstellen der Eingabewerte/Sequenzen § Ausführen des Tests § Beobachtung der Reaktionen und Vergleich mit Sollwert Dokumentation des Tests in der Liste Probleme: § Regressionstest nur sehr aufwändig möglich § Bei Software-Änderungen wird nur ein sehr kleiner Teil des Tests wiederholt Unentdeckte Seiteneffekte möglich! Page 59 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 2 (halb-)automatisierte Testmethoden Ausprogrammierte Testfälle: § § § Testfälle werden ausprogrammiert Erwartungswerte 6. 5. 2 (halb-)automatisierte Testmethoden Ausprogrammierte Testfälle: § § § Testfälle werden ausprogrammiert Erwartungswerte werden ebenfalls hinterlegt und am Ende der Ausführung verglichen Test endet mit: „OK“ oder „FAILED“ § Testausführung wird regressionsfähig § Nach SW-Änderung können (alle) Testfälle wiederholt werden § Ungewollte Seiteneffekte können entdeckt werden § Unterstützt durch Unit-Test-Module: JUnit, etc. Probleme: § Testfälle „folgen sehr eng den Programmstrukturen“ § Änderung an SW zieht oft große Änderungen an den Testfällen nach sich Page 60 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen § § ist weitgehend noch Gegenstand der 6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen § § ist weitgehend noch Gegenstand der Forschung hat kaum geeignete, kommerzielle Werkzeuge am Markt hat sehr großes Potenzial vor allem in der Sicherungstechnik Testen umfasst 40 % des Gesamtaufwand eines Projekts Zwei unterschiedliche Ausprägungen § Einsatz von Standard-Sprachen § Einsatz domänenspezifischer Sprachen ist möglich Sehr hohes Potenzial zur Effizienzsteigerung § Generierung sehr vieler Testfälle ist möglich: Aber: Testorakel nicht vergessen Page 61 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen mit Standardsprachen § Verwenden einer bekannten Sprache 6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen mit Standardsprachen § Verwenden einer bekannten Sprache zur Testfallmodellierung § Teilsprache der UML § Use-Case-Diagramm § Aktivitäts-Diagramm § Sequenz-Diagramm § Zustands-Diagramm § Auch andere Sprachen sind denkbar, z. B. Markov-Ketten § Generieren der Testfälle aus diesen Beschreibungen § Anpassen an die Testumgebung notwendig § Werkzeuge sind bestenfalls Baukästen Page 62 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen mit domänenspezifischen Sprachen § Entwickeln einer domänenspezifischen 6. 5. 3 Modellbasierte Testmethoden Modellbasiertes Testen mit domänenspezifischen Sprachen § Entwickeln einer domänenspezifischen Sprache § Modellieren mit Meta-Modellierungswerkzeugen § EMF (Eclipse Modeling Framework) § Metaedit (kommerzielles Werkzeug) § Topcased (Open-source-Werkzeug) § In der Regel graphische Sprachen § Entwickeln eines Generators zur Testfallerzeugung § Leichter Zugang für Domänen-Experten Page 63 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Ein Fahrprofil Page 64 3/15/2018 Ralf Pinger / Stefan 6. 5. 3 Modellbasierte Testmethoden Ein Fahrprofil Page 64 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Editor für Fahrprofile • Meta-Sprache in Metaedit • Editor-Generierung 6. 5. 3 Modellbasierte Testmethoden Editor für Fahrprofile • Meta-Sprache in Metaedit • Editor-Generierung • Code-Generierung in XML-Format Page 65 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden • Metaedit bis zur Zwischensprache • Unterschiedliche Back-Ends für 6. 5. 3 Modellbasierte Testmethoden • Metaedit bis zur Zwischensprache • Unterschiedliche Back-Ends für verschiedene Zielplattformen • Identische Testfälle für • Simulation am PC • Integrationstestumgebung • Zielplattform Page 66 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden Strategie § Generierung aus abstrakten Beschreibungen: - Viele Testfälle 6. 5. 3 Modellbasierte Testmethoden Strategie § Generierung aus abstrakten Beschreibungen: - Viele Testfälle aus einer abstrakten Beschreibung - Basis meist Aktivitätsdiagramme oder Zustandsmaschinen - Grundprinzip: Fallunterscheidungen “ausrollen“ - Testorakel muss separat erzeugt werden § Generierung aus festgelegten Eingabesequenzen: - In der Regel ein Testfall pro abstrakter Beschreibung - Basis meist Sequenz-Diagramme, Use-Case-Diagramme - Grundprinzip: Ein “Durchlauf“ durch das System - Erzeugung vieler Testfälle durch Mischen - Testorakel kann mit beschrieben werden Page 67 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 3 Modellbasierte Testmethoden § Modellbasierte Entwicklung ist auf dem Weg zum Industriestandard 6. 5. 3 Modellbasierte Testmethoden § Modellbasierte Entwicklung ist auf dem Weg zum Industriestandard § Modellbasierte Entwicklungswerkzeuge sind auch für sicherheitsrelevante Systeme einsetzbar § Modellbasiertes Testen bietet erhebliches Einsparpotenzial § Werkzeugunterstützung für domänenspezifische Sprachen § Einfache Sprache für Domänenexperten - Leicht zu Erlernen - Nur der Sprachumfang der auch benötigt wird § Generierung kann durch Software-Experten leicht ausgeführt werden § Anpassung an Testumgebungen, Simulation. . . Page 68 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 4 Analytische Methoden Analyse § Testorakel: Ist mein Testfall durchgefallen? § Formale 6. 5. 4 Analytische Methoden Analyse § Testorakel: Ist mein Testfall durchgefallen? § Formale Verifikation: Erfüllt mein System die Anforderungen? § Timing-Analyse: Werden die Zeitanforderungen erfüllt? § Testende-Kriterien: Abdeckungsmessungen § Statische Analyse: Laufzeitfehler, Speicherverbrauch § Simulation: Wie verhält sich das System im Einsatz? § Güte des Designs: Ist die Architektur verständlich? Page 69 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 5. 5 Testende-Kriterien § Code-Abdeckung § Anweisungsüberdeckung – EN 50128 § Pfadüberdeckung § 6. 5. 5 Testende-Kriterien § Code-Abdeckung § Anweisungsüberdeckung – EN 50128 § Pfadüberdeckung § Modified Condition/Decision Coverage (MC/DC) – DO 178 C § Funktionsüberdeckung § Requirementsüberdeckung § Schnittstellenüberdeckung Page 70 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6 Qualität – Inhaltsübersicht 1. 2. 3. 4. 5. Prozesse Fehlerkultur SW-Qualitäts-Maße und 6. 6 Qualität – Inhaltsübersicht 1. 2. 3. 4. 5. Prozesse Fehlerkultur SW-Qualitäts-Maße und Qualitätsmetriken Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Änderbarkeit Page 71 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6. 1 Prozesse bilden die Grundlage für § Zertifizierbarkeit § Können geforderte Eigenschaften 6. 6. 1 Prozesse bilden die Grundlage für § Zertifizierbarkeit § Können geforderte Eigenschaften nachgewiesen werden? § Ist nach dem Stand der Technik entwickelt worden? § Qualität § Wurde an alles gedacht? § Gibt es genügend Maßnahmen zur Fehlerreduktion? § Wartbarkeit § Wo muss was geändert werden? § Vorhersagbarkeit eines Projekts § Wann wird was geliefert? § Wie viel kostet es? § Gerichtsfeste Nachweise Page 72 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6. 2 Fehlerkultur Offener Umgang mit Fehlern: § Fehler in Projekten sind ganz 6. 6. 2 Fehlerkultur Offener Umgang mit Fehlern: § Fehler in Projekten sind ganz normal § Der Gesamtprozess mit den unterschiedlichen Rollen soll gemachte Fehler erkennen und beseitigen § Erkannte Fehler dürfen/müssen offen kommuniziert werden § Das Erkennen von Fehlern ist die Grundlage für die künftige Vermeidung! Page 73 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6. 3 SW-Qualität von Software: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte 6. 6. 3 SW-Qualität von Software: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen (DIN ISO 9126) § Beurteilung von Software-Qualität nach ISO/IEC 9126 § Produktqualität, keine Prozessqualität § Richtigkeit § Interoperabilität § Fehlertoleranz § Bedienbarkeit § Zeitverhalten § Modifizierbarkeit § Testbarkeit § Stabilität §… Page 74 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6. 4 Qualitäts-Maße und Qualitätsmetriken Software-Qualitätsmetrik: § Meß- oder Bewertungsmaßstab eines SW-Qualitätsmerkmals Software-Qualitätsmaß: 6. 6. 4 Qualitäts-Maße und Qualitätsmetriken Software-Qualitätsmetrik: § Meß- oder Bewertungsmaßstab eines SW-Qualitätsmerkmals Software-Qualitätsmaß: § Ein Software-Qualitätsmaß ist eine quantitative Skala und eine Methode, mit der Wert bestimmt werden kann, den ein Indikator für ein bestimmtes Software-Produkt aufweist (DIN ISO 9126) Page 75 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 6. 5 Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Änderbarkeit Qualitätsmaße für Merkmale: § Funktionalität: 6. 6. 5 Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Änderbarkeit Qualitätsmaße für Merkmale: § Funktionalität: Sicherheitsanalyse, Benutzerbewertung, Ergebnis eines formalen Beweises § Zuverlässigkeit: MTTF, MTTR, Verfügbarkeit (AVAIL=MTTF/MTTF+MTTR), Ausfallrate, erweiterte Komplexitätsmetriken, Konformanz zu Codierrichtlinien § Benutzbarkeit: Benutzerbewertung, durchschnittlicher Lernaufwand, durchschnittlicher Zeitaufwand für eine Tätigkeit § Effizienz: durchschnittliche Antwortzeit, durchschnittlicher Speicherverbrauch, Durchsatz § Änderbarkeit: Mc. Cabe’s Cyclomatic Complexity, Halstead’s Software Metric, Stilmetriken (Namenskonventionen, Einrückung, …), Objekt-orientierte Metriken (DIT, NOC, RFC, …), Fan-in/fan-out-Metrik § Übertragbarkeit: wie Änderbarkeit, Konformität zu Standards Page 76 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen EN 50128 verlangt: § § § CENELEC-Norm gilt auch 6. 7 Qualitätssicherung von Entwicklungswerkzeugen EN 50128 verlangt: § § § CENELEC-Norm gilt auch für „unterstützende Werkzeuge“ „angemessener Satz an Werkzeugen“ soll eingesetzt werden. Automatische Testwerkzeuge und integrierte Entwicklungswerkzeuge werden empfohlen. Werkzeuge und Hilfsmittel sollten zum frühest möglichen Termin verfügbar sein. Software-Werkzeuge müssen für den Zweck geeignet sein. In der Praxis: § § § Werkzeuge mit Validierung, Begutachtung und Zulassung! Werkzeuge ohne Nachweis der Qualifizierung Und alles was dazwischen ist Page 77 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Neue Version der EN 50128 klassifiziert Werkzeuge (ähnlich ISO 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Neue Version der EN 50128 klassifiziert Werkzeuge (ähnlich ISO 61508) T 1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools T 2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt T 3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System Werkzeuge werden in Zukunft normativ stärker betrachtet Page 78 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Einsatz von Werkzeugen § bei Automatisierung manueller Tätigkeiten Aber 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Einsatz von Werkzeugen § bei Automatisierung manueller Tätigkeiten Aber § das Werkzeug besitzt deterministisches Fehlerverhalten § der Mensch besitzt stochastisches Fehlerverhalten Nachgelagerte Qualitätssicherung zum Fehlerfinden keine Qualifizierung von Werkzeugen notwendig! Einsparen von Qualitätssicherungsschritten: Qualifizierung von Werkzeugen notwendig! Page 79 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Beispiel: Compiler oder Generator § Generator mittels Validierungssuite überprüfen 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Beispiel: Compiler oder Generator § Generator mittels Validierungssuite überprüfen § Vorwärts- und Rückwärtsübersetzung mit Vergleich des Ausgangsmaterials § Zwei Mal diversitäre Vorwärtsübersetzung mit Ergebnisvergleich § Applikationstest mit Abdeckungsmessung auf Ebene des Bytecodes oder Assemblers § Generierung der Testfälle aus dem Modell mit Abdeckungsmessung § Generierung der Testfälle aus einem Testmodell mit anschließender Abdeckungsmessung § Formal beweisbare Übersetzung Page 80 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Validierungssuite § ausführliche Sammlung von Testfällen § Bei Unvollständigkeit 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Validierungssuite § ausführliche Sammlung von Testfällen § Bei Unvollständigkeit der Sammlung bleiben ungetestete Situationen übrig. § Testendekriterien bleiben genauso entscheidend wie bei den Tests des sicherheitsrelevanten Systems § Validierungssuite muss nicht besser sein als ein Test eines sicherheitsrelevanten Systems § gängige Praxis bei der Validierung von Compilern Page 81 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Zwei Mal diversitäre Vorwärtsübersetzung mit Ergebnisvergleich § § § 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Zwei Mal diversitäre Vorwärtsübersetzung mit Ergebnisvergleich § § § Setzen G 1 und G 2 auf denselben Spezifikationen auf? Können G 1 und G 2 wirklich unabhängig sein? diversitäre Auslegung des Vergleichers? In der Luftfahrt wird diversitäre Vorwärtsentwicklung im first und second level eingesetzt doppelter Transformationsaufwand (Kosten) Validierung der Ergebnisse bei jeder Übersetzung -> keine fehlenden Testfälle Page 82 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Vorwärts- und Rückwärtsübersetzung mit Vergleich des Ausgangsmaterials § § 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Vorwärts- und Rückwärtsübersetzung mit Vergleich des Ausgangsmaterials § § § § Diversität durch unterschiedliche Aufgaben besser gegeben Vergleich diversitär? Falls Transformation nicht eineindeutig ist, kann M‘ nicht wiederhergestellt werden. Evtl. zusätzliche Hilfen notwendig, damit M‘ aus dem Code herstellbar ist. Vergleicher kann mit Intelligenz ausgestattet werden (Äquivalenzvergleich) Validierung mit jeder Übersetzung. Fehler in V mit anschließender Fehlerverschleierung in R relativ unwahrscheinlich -> sehr gute Fehleroffenbarung Page 83 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Generierung der Testfälle aus dem Modell mit Abdeckungsmessung § 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Generierung der Testfälle aus dem Modell mit Abdeckungsmessung § Generierte Testfälle nur für die Korrektheit des Generators (Gen) § Abdeckungsmessung soll die Güte der erzeugten Testfälle dokumentieren und nachweisen (optional). § Validierung mit jeder Übersetzung und Testausführung -> keine offenen Testfälle § Keine Funktionstests des Modells, die müssen noch gesondert formuliert und durchgeführt werden. Page 84 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Applikationstest mit Abdeckungsmessung auf Ebene des Bytecodes oder Assemblers 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Applikationstest mit Abdeckungsmessung auf Ebene des Bytecodes oder Assemblers § § § Generierte Code wird mit Testfällen aus der Validierung abgedeckt keine offene Funktionalität im Code vorhanden, da Testabdeckung gemacht Test der Generierung wird mit den ohnehin notwendigen Funktionstests kombiniert -> Einsparung intensiver Generator-Tests Abdeckungsmessungen können sehr aufwändig sein, bei sehr viel generiertem Code Abdeckungsmessungen können manuelle Argumentation für nicht abgedeckte Testfälle haben -> aufwändig Page 85 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Generierung der Testfälle aus einem Testmodell mit anschließender Abdeckungsmessung 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Generierung der Testfälle aus einem Testmodell mit anschließender Abdeckungsmessung § § § ähnlich voriges Beispiel, allerdings werden die Testfälle aus einem separaten Testmodell erzeugt. impliziter Funktionstest des Systems korrekte Generierung wird über die korrekte Testausführung nachgewiesen doppelter Modellierungsaufwand (Modell + Testmodell) Abdeckungsmessung weist Güte der generierten Testfälle nach Abgleich zwischen Modell und Testmodell kann anhand der Abdeckungsmessungen schwierig sein Page 86 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013

6. 7 Qualitätssicherung von Entwicklungswerkzeugen Formal beweisbare Übersetzung § Korrektheit der Übersetzung anhand eines 6. 7 Qualitätssicherung von Entwicklungswerkzeugen Formal beweisbare Übersetzung § Korrektheit der Übersetzung anhand eines formalen Nachweises auf der Ebenen der Sprachdefinitionen § Formale Semantik der Sprachen notwendig § Evtl. aufwändige Nachweise notwendig § bisher noch keine industrielle Anwendung in der Breite möglich (Forschungsgegenstand) Page 87 3/15/2018 Ralf Pinger / Stefan Gerken Software in sicherheitsrelevanten Systemen Sommersemester 2013