Software in sicherheitsrelevanten Systemen

Slides:



Advertisements
Ähnliche Präsentationen
Prüfung objektorientierter Programme -1
Advertisements

Integrations- und Funktionstests im Rahmen des V-Modelles
Anzahl der ausgefüllten und eingesandten Fragebögen: 211
Phasen und ihre Workflows
Vorgehensmodell - Wasserfallmodell
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
Telefonnummer.
1 JIM-Studie 2010 Jugend, Information, (Multi-)Media Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
LE LM 10 - LO3 Verfahren zur Qualitätssicherung
Was ist Qualität ? Qualität von Produkten oder Dienstleistungen ist das Gesamtergebnis aller Aktivitäten in jeder Phase des gesamten Leistungsprozesses.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
es gibt (fast) nichts, was nicht anders gemacht werden könnte
Zertifizierung von Software: CMM oder ISO 9000
Java: Objektorientierte Programmierung
Testen, Analysieren und Verifizieren von Software
Rechneraufbau & Rechnerstrukturen, Folie 2.1 © W. Oberschelp, G. Vossen W. Oberschelp G. Vossen Kapitel 2.
Internet facts 2008-II Graphiken zu dem Berichtsband AGOF e.V. September 2008.
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.
Rational Unified Process (RUP) - Definitionen
Vererbung Spezialisierung von Klassen in JAVA möglich durch
PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.
Fehlerabdeckung/ Regressionstest1 Testen und Analysieren von Software Fehlerbehebung und Re-Engineering Fehlerabdeckung/ Regressionstest Vortragende:
Differentielles Paar UIN rds gm UIN
Prof. Dr. Bernhard Wasmayr
Studienverlauf im Ausländerstudium
Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
Grundschutztools
Prof. Dr. Bernhard Wasmayr VWL 2. Semester
UML Begleitdokumentation des Projekts
AWA 2007 Natur und Umwelt Natürlich Leben
Rechneraufbau & Rechnerstrukturen, Folie 12.1 © W. Oberschelp, G. Vossen W. Oberschelp G. Vossen Kapitel 12.
Institut für Theoretische Informatik TU Carolo-Wilhelmina zu Braunschweig Teamprojekt in Software Systems Engineering und Theoretischer Informatik Einsatz.
1. 2 Schreibprojekt Zeitung 3 Überblick 1. Vorstellung ComputerLernWerkstatt 2. Schreibprojekt: Zeitung 2.1 Konzeption des Kurses 2.2 Projektverlauf.
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Prof. Dr. Günter Gerhardinger Soziale Arbeit mit Einzelnen und Familien Übersicht über die Lehrveranstaltung Grundlegende Bestimmungsfaktoren der Praxis.
20:00.
Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec.
Zusatzfolien zu B-Bäumen
Eine Einführung in die CD-ROM
Zentralübung Automotive Software Engineering – Übungsblatt 8
GBI Genios Wiso wiso bietet Ihnen das umfassendste Angebot deutsch- und englischsprachiger Literatur für die Wirtschafts- und Sozialwissenschaften. Wir.
Dokumentation der Umfrage
Wir üben die Malsätzchen
Syntaxanalyse Bottom-Up und LR(0)
Analyse von Ablaufdiagrammen
Wasserfallmodell und Einzelbegriffe
Ertragsteuern, 5. Auflage Christiana Djanani, Gernot Brähler, Christian Lösel, Andreas Krenzin © UVK Verlagsgesellschaft mbH, Konstanz und München 2012.
Paradigmenwechsel in der Unternehmensmodellierung Prof. Dr. Wolfgang Voigt Dipl.-Ing. Päd. Alexander Huwaldt UML Extrakt UML Seminar, Chemnitz
Geometrische Aufgaben
Symmetrische Blockchiffren DES – der Data Encryption Standard
Szenisches Lernen Wie Theaterelemente den Unterricht bereichern
AK Simulationswerkzeuge für das RE R. Schmid / Folie 1 Evaluation von simulationsfähigen RE-Werkzeugen Reto Schmid Institut für Informatik,
Zahlentheorie und Zahlenspiele Hartmut Menzer, Ingo Althöfer ISBN: © 2014 Oldenbourg Wissenschaftsverlag GmbH Abbildungsübersicht / List.
MINDREADER Ein magisch - interaktives Erlebnis mit ENZO PAOLO
Vienna University of Technology Pirker Simon 1. Überblick Definition Motivation Vorteile Entwurf von VP Pirker Simon 2.
1 (C)2006, Hermann Knoll, HTW Chur, FHO Quadratische Reste Definitionen: Quadratischer Rest Quadratwurzel Anwendungen.
Schutzvermerk nach DIN 34 beachten 20/05/14 Seite 1 Grundlagen XSoft Lösung :Logische Grundschaltung IEC-Grundlagen und logische Verknüpfungen.
Folie Beispiel für eine Einzelauswertung der Gemeindedaten (fiktive Daten)
Unternehmensbewertung Thomas Hering ISBN: © 2014 Oldenbourg Wissenschaftsverlag GmbH Abbildungsübersicht / List of Figures Tabellenübersicht.
Software Engineering Grundlagen
Folie Einzelauswertung der Gemeindedaten
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Datum:17. Dezember 2014 Thema:IFRS Update zum Jahresende – die Neuerungen im Überblick Referent:Eberhard Grötzner, EMA ® Anlass:12. Arbeitskreis Internationale.
1 Medienpädagogischer Forschungsverbund Südwest KIM-Studie 2014 Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
MDA – Model Driven Architecture
 Präsentation transkript:

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014

Kapitel 6 - Software für sicherheitsrelevante Systeme Inhaltsübersicht CENELEC EN 50128 – eine Gebrauchsanleitung Anforderungen SW-Entwicklungsmethoden SW-Test Qualität Qualitätssicherung von Entwicklungswerkzeugen 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.1 CENELEC – Struktur der Bahnnormen gilt für alle Eisenbahnanwendungen (nicht nur Signaltechnik) wendet sich an Hersteller, Betreiber und Zulassungsbehörden definiert einen Lebenszyklus für RAMS-Management definiert einen systematischen, risikobasierten Prozess für die Spezifikation und den Nachweis von RAMS-Anforderungen gibt keine RAMS-Ziele, -Anforderungen oder -Lösungen vor behandelt das Thema Security (=Informationssicherheit) nicht definiert keine Regeln oder Prozesse für die Zertifizierung oder Zulassung von Systemen 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.1 CENELEC- Obligatorische Anforderungen CENELEC EN 50126 ist seit 1.4.2000 in allen CENELEC- Mitgliedsländern als nationale Norm in Kraft gesetzt. Klar definierte Verantwortlichkeit für RAMS-Aufgaben Kompetenznachweise Ausarbeitung und Durchführung eines RAM Programms Ausarbeitung und Durchführung eines Sicherheitsplans Implementierung eines EN 50126 und ISO 900x konformen Geschäftsprozesses Effektives Konfigurationsmanagement für RAMS-Aufgaben Eine Übersichtsfolien über den Aufbau der 50128 fehlt hier noch evtl. Folie 20,21 vorziehen. Referenz auf die Norm fehlt. Die Folien 7 – 19 sind undurchsichtig unverständlich. 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 Zusammenfassung aus Kapitel 1 der EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

Anhang A Normativer Text Anhang D Anhang B Anhang C 6.2 EN 50128 – Aufbau der Norm Normativer Textteil Normative Anhänge A, B Informativer Anhang C, D Anhang A Auswahl von Methoden und Techniken Normativer Text Kapitel Aufbau der Norm: Normativer Text verweist auf andere Teile des normativen Textes Tabellen im Anhang A.1 Anhang A.1 verweist auf normativen Text (entsprechendes Kapitel in Klammern in der Überschrift jeder Tabelle) detaillierte Tabellen in Anhang A.2 (unter Ref. Tabelle A.x) Erläuterungen in Anhang D (unter Ref. D.x). Forderungen zur Erfüllung der Norm: der normative Text muss erfüllt werden. in Anhang A steht drin, was erfüllt werden muss. Anhang A besteht aus einem allgemeinen Teil A.1 und einem detaillierten Teil A.2 Anhänge A und B sind normativ und müssen erfüllt werden Anhänge C und D sind informativ (das heißt aber nicht, dass der Inhalt ignoriert werden darf) Referenzen (D.nn) Anhang D Anhang B Anhang C Schlüsselrollen und Verantwortlichkeiten Zusammenfassung der Dokumentenkontrolle Informationen zu Methoden / Techniken 10.04.2017 Ralf Pinger / Stefan Gerken

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 System-Anforderungsspezifikation … 7.2.3 Ausgangsdokumente 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. Gliederung für Phasen bzw. Vorgänge so wie hier dargestellt Ziele Eingangsdokumente Ausgangsdokumente Anforderungen jeweils ca. 2 Seiten im Normtext Der gesamte Text ist verbindlich – unabhängig vom SSIL Verbindliche Phasen sind in Tabelle C.1 festgelegt; in Tabelle A.1 sind die erforderlichen Dokumente festgelegt – allerdings sind im normativen Text noch zusätzliche Dokumente genannt ISO/IEC 9126: Q-Norm mit Metriken (Erheben und Auswählen von Daten für Metriken, Grundlagen, nur Teil 1 von vier Teilen ist in der gültigen Version bisher verfügbar, aber es existiert auch noch eine ältere zurückgezogene Version) 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – SIL SILheißt Sicherheitsanforderungsstufe 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 Rückwirkungsfreiheit z.B. System mit verschiedenen Rechnern. (Kapitel 7.3.4.9) Achtung mit COTS – neu pre-existing SW - (Kapitel 7.3.4.7). Auch hier ist bei unterschiedlichen SSIL die Rückwirkungsfreiheit zu betrachten und zu begründen. 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Beispiel 1 aus Anhang A NR: abgeraten -: keine Aussage R: empfohlen HR: dringend empfohlen M: verbindlich Referenzspalte (Detailtabellen aus Anhang A oder Anhang D) und „SIL“-Spalten Forderungen erläutern für den Fall, dass mehrere HRs auftauchen (siehe auch Feld mit Bemerkungen) Wie sieht Anhang A aus, wo sind die Verweise zum normativen Text und Anhang B Was muss man machen um welchen SIL zu erreichen? Forderungen: Auswahlkriterien (siehe 2.) Es können auch andere Methoden verwendet werden, die zu argumentieren sind HIER: Eigentlich ist die 50128 eine Norm, die ein Maß (SIL 0 bis SIL 4) für den Softwareentwicklungsprozess definiert (keine Metrik, da SIL 4 nicht doppelt so gut ist wie SIL 2). Folge: Hieran kann man einen Softwareentwicklungsprozess messen und beurteilen (sind zwei Meter Höhe erreicht oder gerissen) 10.04.2017 Ralf Pinger / Stefan Gerken

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. Was unter Ziel steht taugt dazu, die Argumentation für eine alternative Maßnahme zu erbringen Was steht in Anhang D: Erklärung oder Information zu den Anforderungen aus Text und Anhang A. 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Beispiel 2 aus Anhang A Beispiel: verschiedene Programmiersprachen und ihre Anwendung: 1-4 Hochsprachen, 4 ist nicht anerkannt (Hackersprache), aber Siemens hat EBA überzeugt (genehmigtes Subset) IEC 61508/7: C wird HR mit subset, coding standard und static analysis tools Java als Programmiersprache erlaubt – inkludiert aber nicht automatisch JIT oder Ablaufumgebung. Das wäre ggf. Proprietäre SW oder pre-existing SW und müsste gesondert betrachtet werden Security ist Teil der Safety-Betrachtungen – dieses betrifft speziell Ablaufumgebungen, falls die sicherungstechnische Anlage von außen angreifbar ist. Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung) Falls Programmiersprache nicht vorhanden: Anhang D.54 folgen Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Beispiel 2 aus Anhang D Für die, die es ganz genau wissen wollen (gibt immer einige, da hat man es dann schriftlich) ES GIBT EINE ZWEITE FOLIE ALS FORTSETZUNG! Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung) Fortsetzung D.54 Für die, die es ganz genau wissen wollen (gibt immer einige, da hat man es dann schriftlich) DIESES IST DIE ZWEITE FOLIE ALS FORTSETZUNG! Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 In diesem Ablauf (aus EN50128, Bild 2) wird deutlich, dass die Sicherheit in die Software hineingebracht wird, indem im Rahmen der Sicherheitsvorgaben aus der System-Spezifikation eine sorgfältige Zuordnung der sicherheitsrelevanten Funktionen zu Aufgaben der Software durchgeführt wird. Das Ergebnis findet sich in der Software-Anforderungsspezifikation. Nach qualitativ hochwertigem Design und Analyse- und Testschritten, kann die Software-Abnahme und zu guter Letzt die Zulassung erfolgen. Die Norm hört hier jedoch nicht auf, sondern bringt auch Vorgaben zu Projektierung und auch Wartung in der Betriebsphase. Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

Ver Val Phase Ergebnisse 6.2 EN 50128 – Prozess Ablauf der Entwicklung Eckpunkte: V-Modell Zu jedem Entstehungsschritt ein überprüfender Schritt Einblick in die einzelnen Phasen und Verifikation und Validierung In jeder Phase Testspezifikationen Verifikation Validation Modul- und Hardware-/Softwareintegrationstest durch Entwickler Neu: SW-Wartung Problem: Korrektheit der Anforderungsspezifikation! => Vielleicht der Validierer? Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Verifikation und Validierung Wird richtig entwickelt Verifikation: Untersuchungsprozess mit anschließender, auf 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 Gelbe Wolken sind hier wichtig Früher hieß es „Analyse und Test“! Aber auch wichtig ist die Sichtweise (Verifikation ist Sichtweise des Herstellers, Validierung Sichtweise des Kunden) ACHTUNG: In anderen Branchen können die Begriffe andere Bedeutungen haben. 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Dokumente / Ergebnisse Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil) Vorgaben von Maßnahmen und Tools (Anhang A) Vorgaben zu Kompetenzprofilen (Anhang B) Vorgaben zu Reviews (Verifikation) Verfolgbarkeit der Anforderungen Wichtige Punkte für die Entwicklungsphasen Punkt 1: ab Kapitel 6 (SW Sicherung) der Norm strenge Anforderungen an Phasenablauf und Ergebnisdokumente Punkt 2: Annex A und B sind unbedingt zu berücksichtigen Punkt 3: in der Norm gibt es strenge Anforderungen an die Durchführung und Dokumentation (inhaltlich) für Reviews und Tests Punkt 4: mehrfach wird die Verfolgbarkeit der Anforderungen von der Norm verlangt Das vorgestellte Benummerungsschema ist eine Notation, ersetzt aber keine Methodik, dazu gehört auch eine Vorgehensweise, ist im Methodenratgeber aber enthalten (Keine Aussage zur Qualität) 10.04.2017 Ralf Pinger / Stefan Gerken

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 Weitere zwei Seiten Text mit möglichen Abweichungen vom Bild SIL 0: einer darf gemäß Norm DI, Ver, Val sein, aber nicht nach ISO 9000 „persönliche“ Unabhängigkeit des Validierers bei sicherheitsrelevanter SW außerdem Projektunabhängigkeit des Validierers bei SIL  3 Firmenunabhängigkeit des Gutachters oder Anerkannter Fachbetrieb (z.B. EBA) mit besonderen Auflagen an die Gutachter Unabhängigkeiten der Ver‘s, Val‘s und Gut‘s in Abhängigkeit der nachzuweisenden SILs. Gutachter vom EBA anerkannt Kompetenznachweis als Dokument erforderlich Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

6.2 EN 50128 – Aufgaben und Rollen Quelle: EN 50128 10.04.2017 Ralf Pinger / Stefan Gerken

Vorgaben für den Entwicklungsprozess 6.2 EN 50128 – Zusammenfassung Vorgaben für den Entwicklungsprozess Festlegung von Maßnahmen und Tools Anforderungen an Dokumente Unabhängige Stellen Grundidee: Wo stehe ich? Wo will ich hin? Wie erreiche ich mein Ziel? Wie überwache ich, dass die ersten drei Punkte immer noch gültig sind („KVP“) - und alles auditierbar und nachprüfbar dokumentiert. Daraus folgt z.B.: Rollen definieren notwendige Kompetenzen definieren Leute entsprechend ihrer Rolle und Kompetenz einsetzen normativer Textteil: alle Punkte müssen erfüllt sein Norm nur die Mindestanforderung 10.04.2017 Ralf Pinger / Stefan Gerken

6.3 Anforderungen – Inhaltsübersicht Anforderungsmanagement Ermittlung von Anforderungen Rapid Prototyping Verfolgung von Anforderungen Identifikation von Anforderungen Umsetzung von Anforderungen Nachweis von Anforderungen 10.04.2017 Ralf Pinger / Stefan Gerken

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. Dieses schließt die Anforderungen aus dem Basissystem ein oder auch funktionale Anforderungen, die aus nicht-funktionalen Anforderungen wie Sicherheit abgeleitet werden. Das wäre hier etwas wie: In dem durch die Beschreibung des Systems geforderten Umfang muss die Software-Anforderungsspezifikation die Software-Selbsttests und die Hardware-Prüfungen durch die Software berücksichtigen. Der Software-Selbsttest besteht im Erkennen und Melden eigener Fehlfunktionen und von Fehlern durch die Software selbst Die Software-Anforderungsspezifikation muss alle Schnittstellen zu beliebigen anderen Systemen identifizieren und beschreiben, sei es innerhalb oder außerhalb der zu steuernden Einrichtung, einschließlich der Bedienerschnittstelle, wo immer eine direkte Verbindung besteht oder geplant ist Diagnose 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 … Siehe unter anderen http://www.sophist.de 10.04.2017 Ralf Pinger / Stefan Gerken

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 Siehe unter anderen http://www.sophist.de 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.2 Ermittlung von Anforderungen Bewertung der Anforderungen: Korrektheit Vollständigkeit Machbarkeit Bewertung, ob Kundenanforderung Wichtigkeit Kosten Siehe unter anderen http://www.sophist.de 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.3 Rapid Prototyping 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 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.3 Rapid Prototyping Vorteile Nachteile 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 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.3 Vom Rapid Prototype zum Design-Modell Analyse-Modell = Anforderungsmodell Erläuterung fehlt hier noch. 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.3 Analyse-/Design-Modell Analyse-Modell: schneller Prototyp keine vollständige Durchdringung der Anforderungen notwendig Anforderungsfehler werden frühzeitig offenbart Schnelle Anpassbarkeit an Kundenänderungen (agil) Ausprägungen: Wegwerfprototyp … Refaktorisierung bis zum Produkt Design-Modell: Verständlichkeit/Wartbarkeit Einfache Lösungen entstehen in der Regel nicht im ersten Ansatz! Hohe Durchdringung der Anforderungen notwendig Architektur muss weitgehend bekannt sein Ausprägungen: (Neu-) Entwicklung … Refaktorisiert aus Analyse-Modell Vorteil: bei erkannten Problemen sind diese im Prototypen leicht identifizierbar bei Änderungen in der Spezifikation ist der Prototyp leicht anpassbar Direkte Umsetzung eines Analysemodells ohne Design-Modell in eine Implementierung führt selten zu einem guten Design – man braucht im Normalfall beides! 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 Die Notation bezieht sich auf die Anforderungsverfolgung und das Management, nicht auf das “Engineering”, welches sich auch um Elecitation (Finden/Erheben von Anforderungen) kümmert. 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.3.7 Nachweis von Anforderungen Zielgruppen: Kunde Gutachter Zulassungsbehörde Methoden: Analyse Sicherheitsnachweise RAM-Nachweise Qualitätsnachweise Test Testberichte 10.04.2017 Ralf Pinger / Stefan Gerken

6.4 SW-Entwicklungsmethoden – Inhaltsübersicht Konventionelle Entwicklungsmethoden Halb-formale Entwicklungsmethoden Formale Entwicklungsmethoden Modellbasiertes Software-Engineering 10.04.2017 Ralf Pinger / Stefan Gerken

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 Software, die analysierbar, testbar, verifizierbar und wartbar ist Auswahl eines für die geforderte Software-Sicherheitsanforderungsstufe angemessenen Satzes von Werkzeugen Durchführung der Softwareintegration 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.1 Konventionelle Entwicklungsmethoden – Beispiele 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 Fast alle aus der EN 50128 Erläuterungen aus der CENELEC zu den Methoden Das Hauptziel der strukturierten Methodik ist es, die Qualität der Softwareentwicklung unter besonderer Berücksichtigung der frühen Phasen des Lebenszyklus zu fördern. Die Verfahren zielen darauf ab, dies sowohl durch genaue und intuitive Verfahren als auch durch Notation (rechnergestützt) zu erreichen, dass die Existenz von Anforderungs- und Implementierungsmerkmalen in einer logischen Reihenfolge in strukturierter Art und Weise identifiziert werden. Beschreibung Es existieren mehrere strukturierte Methodiken. Einige, wie z. B. SSADM und LBMS, sind für traditionelle Funktionen der Datenverarbeitung und Transaktionsbearbeitung entworfen, während andere Verfahren (MASCOT, JSD, Echtzeit nach Yourdon) mehr in Richtung Prozesssteuerungs- und Echtzeitanwendungen zielen (welche eher sicherheitskritisch sind). Strukturierte Verfahren sind im Wesentlichen „Denkwerkzeuge“ zum systematischen Verständnis und Aufteilung eines Problems oder Systems. Ihre Hauptmerkmale sind: – eine logische Gedankenfolge zur Unterteilung eines größeren Problems in handhabbare Teile; – Identifikation des Gesamtsystems, einschließlich seiner Umgebung wie auch des geforderten Systems selbst; – Zerlegung der Daten und Funktionen in dem geforderten System; – Prüflisten, das heißt Listen der zu definierenden Begriffe; – wenig intellektueller Überhang - Einfach, intuitiv, pragmatisch. Die unterstützende Notation hilft präzis zu sein bei der Identifikation von Problemen und Systembetrachtungseinheiten (z. B. Prozess- und Datenflüsse), aber die Prozessfunktionen, welche durch diese Betrachtungseinheiten ausgeführt werden, werden eher durch informale Notation beschrieben. Einige Verfahren verwenden jedoch teilweise formale (mathematische) Notationen (zum Beispiel JSD wendet reguläre Ausdrücke an; Yourdon, SOM und SDL verwenden endliche Zustandsautomaten). Diese Präzisierung reduziert nicht nur die Möglichkeit für Missverständnisse, sondern sieht auch die Möglichkeit einer automatischen Verarbeitung vor. Ein anderer Vorteil der strukturierten Notation ist die Transparenz, die es ermöglicht, dass eine Spezifikation oder ein Entwurf durch den Anwender intuitiv gegen sein fachliches aber nicht aufgeschriebenes Fachwissen überprüft werden kann. Modulares Vorgehen: Begrenzung der Modulgröße "Information-Hiding"/Einkapselung Begrenzung der Parameteranzahl Ein Eingang/Ein Ausgang für Unterprogramme und Funktionen Vollständig definierte Schnittstelle Entwurfs- und Codierstandards Codierstandards existieren Leitlinie für Codierstil Keine dynamischen Objekte Keine dynamischen Variablen Beschränkter Gebrauch von Zeigern Beschränkter Gebrauch von Rekursionen keine unbedingten Sprünge 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 Auszüge aus der EN50128 Ziel „Formale Methoden“ beziehen sich auf mathematisch strenge Verfahren und Werkzeuge zur Spezifikation, Entwurf und Verifikation von Software- und Hardwaresystemen. Beschreibung Der Wortlaut „mathematisch streng“ bedeutet, dass die bei den formalen Verfahren exakt formulierten Aussagen in einer mathematischen Logik verwenden, und dass die formalen Verifikationen exakte Schlussfolgerungen in dieser Logik sind (d. h. jeder Schritt folgt aus einer Ableitungsregel und kann somit durch einen mathematischen Prozess kontrolliert werden). Der Wert der formalen Verfahren besteht in der Bereitstellung eines Mittels zur symbolischen Untersuchung des gesamten Zustandsraumes eines digitalen Entwurfes (unanhängig davon, ob es Hardware oder Software ist) und bestimmt, dass die Richtigkeit oder Sicherheitseigenschaft für alle möglichen Eingangsgrößen wahr ist. Aufgrund der gewaltigen Komplexität realer Systeme wird dies in der gegenwärtigen Praxis jedoch nur selten angewendet (mit Ausnahme der kritischen Komponenten von sicherheitskritischen Systemen). … Obwohl die Anwendung der mathematischen Logik das gemeinsame Thema quer durch die Disziplin der formalen Verfahren ist, gibt es nicht die beste „Formale Methoden“. Jeder Anwendungsbereich erfordert verschiedene Modellierungsverfahren und unterschiedliche Nachweisansätze. Selbst innerhalb eines bestimmten Anwendungsbereiches gibt es für die unterschiedlichen Phasen des Lebenszyklusses, Werkzeuge und Techniken, welche diese am besten unterstützen. Beispielsweise kann ein Theorem-Beweiser am besten zur Analyse der Korrektheit einer Spezifikation auf Register-Transfer-Ebene (RTL) eines Chips für FFTBerechnungen angewendet werden, während möglicherweise algebraisch abgeleitete Verfahren am besten zur Analyse der Korrektheit von Entwurfsverfeinerungen auf Gatter-Ebene angewendet werden kann. Deshalb sind weltweit eine große Anzahl von formalen Verfahren in Entwicklung. In den folgenden Unterabschnitten dieser Verfahrensübersicht werden mehrere Beispiele formaler Verfahren beschrieben. Die hier angegebene Liste von Beispielen ist nicht vollständig. Die formalen Verfahren sind BVerfahren, Modellprüfung, CCS, CSP, HOL, LOTOS, OBJ, Zeitliche Logik, VDM und Z. 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.4 Modellbasiertes Software-Engineering – Ursprünge Erste Ansätze in den 80er 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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.4 Modellbasiertes Software-Engineering 29 .text 30 0027 90 .p2align 2,,3 31 .globl main 32 .type main,@function 33 main: 34 0028 55 pushl %ebp 35 0029 89E5 movl %esp, %ebp 36 002b 83EC08 subl $8, %esp 37 002e 83E4F0 andl $-16, %esp 38 0031 83EC0C subl $12, %esp 39 0034 680E0000 pushl $.LC1 39 00 40 0039 C7050000 movl $3, a 40 00000300 41 0043 E8FCFFFF call puts 41 FF 42 0048 C7042404 movl $4, (%esp) 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.4 Modellbasiertes Software-Engineering void Step(void) { input.AktuelleZeit.timeX = GetTickCount() - starttime; tbl_display.hour = timeinfo->tm_hour; tbl_display.min = timeinfo->tm_min; if ((stepcount > 1000) && (output.StarteDailyTest)) { input.DailyTestResult.vorhanden = kcg_true; input.DailyTestResult.Result = DT_ok_TBL1p_Types; } writeSSS(&input); do{ stepcount = stepcount + 1; TBL1p_MainMixer(&input, &output); output2display(); } while(!output.HabeFertig); 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.4 Modellbasiertes Software-Engineering 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.4.4. Modellbasiertes Software-Engineering 10.04.2017 Ralf Pinger / Stefan Gerken

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: kaum geeignete, kommerzielle Werkzeuge am Markt sehr großes Potenzial vor allem in der Sicherungstechnik 10.04.2017 Ralf Pinger / Stefan Gerken

6.5 SW-Test – Inhaltsübersicht Konventionelle Testmethoden (halb-)automatisierte Testmethoden modellbasierte Testmethoden analytische Methoden Testende-Kriterien 10.04.2017 Ralf Pinger / Stefan Gerken

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 Zum Vergleich: Anzahl Elektronen im sichtbaren Universum Eddington number N_edd = 136×2256 = 1.57×1079 10.04.2017 Ralf Pinger / Stefan Gerken

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! 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.5.3 Modellbasierte Testmethoden Ein Fahrprofil 10.04.2017 Ralf Pinger / Stefan Gerken

6.5.3 Modellbasierte Testmethoden Editor für Fahrprofile Meta-Sprache in Metaedit Editor-Generierung Code-Generierung in XML-Format 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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 ... 10.04.2017 Ralf Pinger / Stefan Gerken

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? 10.04.2017 Ralf Pinger / Stefan Gerken

6.5.5 Testende-Kriterien Testende-Kriterien Code-Abdeckung Anweisungsüberdeckung – EN 50128 Pfadüberdeckung Modified Condition/Decision Coverage (MC/DC) – DO 178C Funktionsüberdeckung Requirementsüberdeckung Schnittstellenüberdeckung Modified Condition/Decision Coverage (MC/DC), is used in the standard DO-178B to ensure that Level A (Catastrophic) software is tested adequately. It is a form of exhaustive testing, in that during testing all of the below must be true at least once: Independence of a condition is shown by proving that only one condition changes at a time. The most critical (Level A) software, which is defined as that which could prevent continued safe flight and landing of the aircraft, must satisfy a level of coverage called Modified Condition/Decision Coverage (MC/DC). [edit] Definitions Condition A condition is a leaf-level Boolean expression (it cannot be broken down into a simpler Boolean expression). Condition Coverage Every condition in a decision in the program has taken all possible outcomes at least once. Decision Coverage Every point of entry and exit in the program has been invoked at least once, and every decision in the program has taken all possible outcomes at least once. Condition/Decision Coverage Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, and every decision in the program has taken all possible outcomes at least once. Modified Condition/Decision Coverage Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently. A condition is shown to affect a decision’s outcome independently by varying just that condition while holding fixed all other possible conditions. The condition/decision criterion does not guarantee the coverage of all conditions in the module because in many test cases, some conditions of a decision are masked by the other conditions. Using the modified condition/decision criterion, each condition must be shown to be able to act on the decision outcome by itself, everything else being held fixed. The MC/DC criterion is thus much stronger than the condition/decision coverage 10.04.2017 Ralf Pinger / Stefan Gerken

6.6.1 Prozesse 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 10.04.2017 Ralf Pinger / Stefan Gerken

Offener Umgang mit Fehlern: 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! 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

6.7 Qualitätssicherung von Entwicklungswerkzeugen Neue Version der EN 50128 klassifiziert Werkzeuge T1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools T2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt T3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System ISO 61508 klassifiziert Werkzeuge nach: Einfluss des Tools auf das Ergebnis (ähnliche T1, T2, T3) Fehleraufdeckung durch nachgelagerte Prozessschritte 10.04.2017 Ralf Pinger / Stefan Gerken

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! gleicher Prozess wie bei manueller Erstellung der Ergebnisse Einsparen von Qualitätssicherungsschritten:  Qualifizierung von Werkzeugen notwendig! Deterministisches Fehlerverhalten: Fehler treten immer dann auf, wenn die Voraussetzungen für den Fehler erfüllt sind. In der Regel sind die Fehler an vielen Stellen in der Software vorhanden. Wird ein solcher Fehler an einer einzigen Stelle in der Qualitätssicherung gefunden und behoben, sind alle Fehler dieser Klasse aus dem Produkt verschwunden. Ein einziger Testfall zum Finden aller Fehler dieser Fehlerklasse! Stochastisches Fehlerverhalten: unterschiedliche Fehler treten an unterschiedlichen Stellen in der Software auf. Für jeden Fehler braucht man einen eigenen Testfallen zum Finden. In der Praxis (Gutachtersicht) werden Werkzeuge oft mit demselben Aufwand erstellt, wie das sicherheitsrelevante System! Der eigentliche Zweck des Werkzeugs geht dabei oft verloren. Manchmal wird der Einsatz von Werkzeugen dadurch verhindert -> Werkzeuge sind in der Regel aber besser als manuelle Tätigkeiten! 10.04.2017 Ralf Pinger / Stefan Gerken

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 Deterministisches Fehlerverhalten: Fehler treten immer dann auf, wenn die Voraussetzungen für den Fehler erfüllt sind. In der Regel sind die Fehler an vielen Stellen in der Software vorhanden. Wird ein solcher Fehler an einer einzigen Stelle in der Qualitätssicherung gefunden und behoben, sind alle Fehler dieser Klasse aus dem Produkt verschwunden. Ein einziger Testfall zum Finden aller Fehler dieser Fehlerklasse! Stochastisches Fehlerverhalten: unterschiedliche Fehler treten an unterschiedlichen Stellen in der Software auf. Für jeden Fehler braucht man einen eigenen Testfallen zum Finden. In der Praxis (Gutachtersicht) werden Werkzeuge oft mit demselben Aufwand erstellt, wie das sicherheitsrelevante System! Der eigentliche Zweck des Werkzeugs geht dabei oft verloren. Manchmal wird der Einsatz von Werkzeugen dadurch verhindert -> Werkzeuge sind in der Regel aber besser als manuelle Tätigkeiten! 10.04.2017 Ralf Pinger / Stefan Gerken

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 Deterministisches Fehlerverhalten: Fehler treten immer dann auf, wenn die Voraussetzungen für den Fehler erfüllt sind. In der Regel sind die Fehler an vielen Stellen in der Software vorhanden. Wird ein solcher Fehler an einer einzigen Stelle in der Qualitätssicherung gefunden und behoben, sind alle Fehler dieser Klasse aus dem Produkt verschwunden. Ein einziger Testfall zum Finden aller Fehler dieser Fehlerklasse! Stochastisches Fehlerverhalten: unterschiedliche Fehler treten an unterschiedlichen Stellen in der Software auf. Für jeden Fehler braucht man einen eigenen Testfallen zum Finden. In der Praxis (Gutachtersicht) werden Werkzeuge oft mit demselben Aufwand erstellt, wie das sicherheitsrelevante System! Der eigentliche Zweck des Werkzeugs geht dabei oft verloren. Manchmal wird der Einsatz von Werkzeugen dadurch verhindert -> Werkzeuge sind in der Regel aber besser als manuelle Tätigkeiten! 10.04.2017 Ralf Pinger / Stefan Gerken

6.7 Qualitätssicherung von Entwicklungswerkzeugen Zwei Mal diversitäre Vorwärtsüber- setzung mit Ergebnisvergleich Setzen G1 und G2 auf denselben Spezifikationen auf? Können G1 und G2 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 10.04.2017 Ralf Pinger / Stefan Gerken

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 es bleibt theoretische Restfehlerwahrscheinlichkeit doppelter Aufwand sehr gut in der Praxis 10.04.2017 Ralf Pinger / Stefan Gerken

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. 10.04.2017 Ralf Pinger / Stefan Gerken

6.7 Qualitätssicherung von Entwicklungswerkzeugen Applikationstest mit Abdeckungs- messung 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 10.04.2017 Ralf Pinger / Stefan Gerken

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 10.04.2017 Ralf Pinger / Stefan Gerken

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) 10.04.2017 Ralf Pinger / Stefan Gerken