Stefan Kauer 29.01.2013 Qualitätssicherung bei der Entwicklung sicherheitskritischer Software.

Slides:



Advertisements
Ähnliche Präsentationen
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Advertisements

Prüfung objektorientierter Programme -1
Integrations- und Funktionstests im Rahmen des V-Modelles
Submodell Softwareentwicklung (SE)
Phasen und ihre Workflows
Qualitätssicherung von Software (SWQS)

Das „Vorgehensmodell“
Systemverwaltung wie es Ihnen gefällt.
Kooperierende autonome Fahrzeuge
Bastian Cramer, Universität Paderborn Entwurfsmuster für Webanwendungen Projektgruppe: Generierung von Webanwendungen aus visuellen Spezifikationen.
Evaluierung und Implementierung der Automated Test Life-Cycle Methodology (ATLM) am Beispiel der IT3-Software Vorträger: Ling Yan.
Software-Lebenszyklus
LE LM 10 - LO3 Verfahren zur Qualitätssicherung
Schulung der Mitarbeiter
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Agile Software Entwicklung mit dem RUP Agile Softwareentwicklung Best Practice bei.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme MuSofT LE 3.1-4V - Modell Überblick V-Modell Regelungen, die die Gesamtheit aller Aktivitäten,
Testen, Analysieren und Verifizieren von Software
Rational Unified Process (RUP) - Definitionen
Software Risk Evaluation Method (SRE)
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests.
M A P K I T Management eines J2EE basierten eCommerce Systems am Beispiel des ATG Dynamo Applikationsservers und BMC Patrol als Managementframework.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests.
INSTITUT FÜR DATENTECHNIK UND KOMMUNIKATIONS- NETZE 1 Harald Schrom ViEWcon08.
Vorgehensmodelle: Schwergewichtige Modelle
Spezifikation von Anforderungen
Portfolio des Competence Center ECS
Michael Haverbeck System Engineer
Zentralübung Automotive Software Engineering – Übungsblatt 8
ArcGIS als WPS Server Aktueller Stand der Umsetzung
Institut für Wirtschaftsinformatik und Anwendungssysteme
REQUIREMENTS ENGINEERING
Als geeignetes Präservationsverfahren Migration gebräuchliche Strategie der digitalen Langzeitarchivierung zuverlässiger Weg, die wichtigsten Properties.
Agenda 13: Begrüßung & Einführung in das Thema
Hardware / Software Codesign Hardware versus Software.
Signal-Prozessoren DSV1, 2009, Hhrt, 1 Mikro-Prozessor Von Neumann-Architektur Daten und Programmcode im gleichen Speicher => Sequenzieller Zugriff auf.
Embedded Systems Prof. Dr. H. Kristl
Engineering tools for the NEO engineer
Wasserfallmodell und Einzelbegriffe
PRO:CONTROL Ziel des Moduls Arbeitspakete
Projektmanagement Ziel und Umfang eines Softwareprojektes definieren
Clean Code Software-Entwicklung als Handwerkskunst Thomas Nagel, November 2011.
Embedded Linux Portierung auf mobiles Datenerfassungsterminal
Hardware / Software Codesign Hardware vs. Software: Maßnahmen zur Erreichung der Design-Ziele.
Vienna University of Technology Pirker Simon 1. Überblick Definition Motivation Vorteile Entwurf von VP Pirker Simon 2.
The EventCollector Concept Präsentation der Diplomarbeit von Thomas Moser und Lukas Karrer Distributed System Group,
Rational Unified Process
Software Engineering Grundlagen
Application Lifecycle Management Day 25. August 2008 Erfolgreiche Software- Entwicklung in Offshore-Projekten mit Microsoft Team Foundation Server Thomas.
Unified Process Historisch-Kulturwissenschaftliche Informationsverarbeitung Übung: Planung von Softwareprojekten Dozent: Christoph Stollwerk WS 2014/2015.
Institut Experimentelles Software Engineering Fraunhofer IESE Vorstellung des neuen GI Arbeitskreis: Produktlinientools Isabel John, Fraunhofer IESE
Institut für Angewandte Mikroelektronik und Datentechnik Phase 5 Architectural impact on ASIC and FPGA Nils Büscher Selected Topics in VLSI Design (Module.
Weg mit Fehlern, die kein Entwickler versteht …
Objektorientierung und sichere Software mit Ada
Ralf M. Schnell Technical Evangelist Microsoft Deutschland GmbH
Christian Binder Senior Platform Strategy Manager Microsoft Deutschland GmbH.
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Arbeiten in einem agilen Team mit VS & TFS 11
© EADS Sichere SW - Juli 2007 Qualitätssicherung bei der Entwicklung sicherheitskritischer SW © EADS Stefan Kauer EADS Deutschland GmbH Defence & Security.
MDA – Model Driven Architecture
…Be readY.
Projektmanagement und Softwarequalität
SEMINARVORTRAG Von Jonas Robers METHODEN UND TOOLS ZUR ERFASSUNG VON TESTFÄLLEN.
A. Steininger TU Vienna 1 Multicore eleganter Work-Around um die Design-Crisis Problemverschiebung in die SW (= auf höhere Ebene) ABER: hohe Parallelität.
Hardware / Software Codesign Hardware versus Software.
IT QM Part2 Lecture 7 PSE GSC
Test Summary: ein Fehler pro Tag Test First
 Präsentation transkript:

Stefan Kauer Qualitätssicherung bei der Entwicklung sicherheitskritischer Software

© 2013 CASSIDIAN - All rights reserved Page 2 Sicherheitskritische SW / Stefan Kauer Januar 2013 Begriff Fehlerhaftes Verhalten oder Ausfall des Geräts kann zu Verlust von Menschenleben oder Sachgütern von erheblichem Wert führen Stufen der Kritikalität (Level A, B, C, D, E oder 1,2,3 je nach Standard, z.B. flight critical, mission critical, …) Verschiedene Einstufungen je nach (militärischem oder zivilen) Standard Kritikalität bestimmt –Welche Tätigkeiten –Wie durchzuführen –Wie zu dokumentieren –Tool-Qualifikation –…–…

© 2013 CASSIDIAN - All rights reserved Page 3 Sicherheitskritische SW / Stefan Kauer Januar 2013 Art der Geräte Elektronische Komponenten für militärische Fluggeräte (Hubschrauber, Flugzeuge,...) sicherheitskritisch zertifiziert entsprechend Zertifizierungsprozess (bezieht sich auf ganzes Gerät: (mechanisch / elektrisch / SW /... ) sehr lange Betriebszeit (10-30 Jahre) –Wartung –Weiterentwicklung –Archivierung alter" Tools / Rechner... –Single Source / Obszolesenz-Probleme / Management –…–… embedded (Entwicklungssystem Zielsystem!)

© 2013 CASSIDIAN - All rights reserved Page 4 Sicherheitskritische SW / Stefan Kauer Januar 2013 Art der Geräte eingeschränkte HW aufgrund Zertifizierung und anderer Randbedingungen oft keine user interaction (dafür Interface zu anderem HW-Modul / -gerät) Zusätzlich bei Projekten im Gegensatz zu Produkten: –kundenspezifisch –special purpose - das Gerät kann nichts, was nicht benutzt wird, also nicht universell", alles-in-einem –geringe Stückzahlen (einige 100) …

© 2013 CASSIDIAN - All rights reserved Page 5 Sicherheitskritische SW / Stefan Kauer Januar 2013 Avioniksystem Main Computer Bus Controller Device 1Device n …. Avionic Bus …. Redundanz bei Geräten und Bus MC überwacht Geräte per BIT-Meldung MC überwachen sich gegenseitig …

© 2013 CASSIDIAN - All rights reserved Page 6 Sicherheitskritische SW / Stefan Kauer Januar 2013 Avioniksystem interner Bus Gerät Boards

© 2013 CASSIDIAN - All rights reserved Page 7 Sicherheitskritische SW / Stefan Kauer Januar 2013 Avioniksystem HW - CPU (GPU, DSPs, MC) - Speicher (RAM, ROM, flash, Video, spezial, ….) - FPGA, CPLD, ASIC, … - spezial HW - interner Bus - I/O -… Board SW - Boot-ROM - FW - Treiber - BSP - OS - Application SW -…

© 2013 CASSIDIAN - All rights reserved Page 8 Sicherheitskritische SW / Stefan Kauer Januar 2013 Ebenen Avioniksystem Gerät Board Modul … Auf jeder Ebene gibt es Anforderungen und entsprechende Tests

© 2013 CASSIDIAN - All rights reserved Page 9 Sicherheitskritische SW / Stefan Kauer Januar 2013 Qualität - Begriffe Äußere Qualität – auch Ergebnisqualität –Kunden- bzw. Benutzersicht –Erfüllung der (Kunden)Requirements bzw. der Spezifikation Innere Qualität – auch Struktur- und Prozessqualität –Entwicklersicht –Was sind unsere Qualitätsziele?

© 2013 CASSIDIAN - All rights reserved Page 10 Sicherheitskritische SW / Stefan Kauer Januar 2013 Qualitätsziele / -kriterien Portierbarkeit (Portability) Performanz (Performance / Efficiency) Lesbarkeit (Readability) Wartbarkeit (Maintainability) –Fehlerspeicher –Wartungszugänge (z.B. serielle Schnittstelle RS232) Änderbarkeit (Changeability) Zuverlässigkeit (Reliability) –Selbsttest- / Diagnose-Funktionen (PBIT, IBIT, CBIT) –Life sign / Watchdog –…–… Robustheit (Robustness) –Inputs prüfen Sicherheit (Safety / Security) Wiederverwendbarkeit (Reusability)

© 2013 CASSIDIAN - All rights reserved Page 11 Sicherheitskritische SW / Stefan Kauer Januar 2013 Qualitätsziele / -kriterien Testbarkeit (Testability) Verwendbarkeit (Usability) teilweise widersprechende Ziele Priorisierung nötig Bei jeder Designentscheidung alle Kriterien bewerten (Qualitätsbewusstsein) Compliance: Dokumentation muss mit Gerät übereinstimmen –Fehler zugeben - concession / deviation –nicht erfüllbare Requirements nennen

© 2013 CASSIDIAN - All rights reserved Page 12 Sicherheitskritische SW / Stefan Kauer Januar 2013 Maßnahmen zur Qualitätssicherung Standardisierung in allen Entwicklungsphasen –Planung –Projektmanagement –Requirements Engineering –Architektur / Design –Implementierung (coding-Standards) –Tests / Abnahmen –Problem- und Änderungs-Management –Konfigurations-Management (Versionen / HW / SW / Konfig.-Stand / Umgebung / …) –Dokumentation / Archivierung

© 2013 CASSIDIAN - All rights reserved Page 13 Sicherheitskritische SW / Stefan Kauer Januar 2013 Maßnahmen zur Qualitätssicherung Prozessorientierung –In house Standard, z.B. V-Modell (tailoring), flyXT –Von customer / purchaser, z.B. EFA-Standard –Übergreifend, z.B. DO178B, DoD-STD-2167A Reviews auf allen Ebenen und in allen Phasen Traceability (Verfolgbarkeit, Durchgängigkeit) –Zwischen Requirements der Ebenen n und n+1 –Zwischen Tests und Requirements der Ebene n –Zwischen Requirements der niedrigsten Ebene (low level Requirements) und Implementierung –Zwischen Änderung der Implementierung und Change Request oder Problem Report –…–…

© 2013 CASSIDIAN - All rights reserved Page 14 Sicherheitskritische SW / Stefan Kauer Januar 2013 Test / Integration / Abnahme SW-Module –Entwickler-Tests –Unit Tests (White Box Tests) – nach Testplan, möglichst automatisiert -> Code Coverage Ziel: bis zu 100% (je nach Kritikalität) mit Code Inspection –Code Walk Through -> Einhaltung der Codier-Regeln Integration der SW-Module auf Board –freie Tests –Requirement based tests (black box tests) - nach Testplan, möglichst automatisiert (traceability) –Test für jeden gefixten Fehler durchführen Integration der boards im Gerät –freie Tests –Requirement based tests (black box tests) - nach Testplan, möglichst automatisiert –Formale Abnahme (konfigurierte Testdaten u. -umgebung / Protokoll Integration der Geräte in Avioniksystem

© 2013 CASSIDIAN - All rights reserved Page 15 Sicherheitskritische SW / Stefan Kauer Januar 2013 Fehlerbehandlung Formale Erfassung / Verfolgung / Bearbeitung Toolgestützt Integriert mit Versionskontrollsystem Vorgehen 1.Ist es ein Fehler? Welches Requirement ist verletzt? 2.Reproduzieren 3.Analysieren 3.Eventuell reparieren, Testfall entwickeln, testen, dokumentieren

© 2013 CASSIDIAN - All rights reserved Page 16 Sicherheitskritische SW / Stefan Kauer Januar 2013 Fehlerverfolgung open occurance describe / assign new accept accepted reassign reject closed reopen fix fixed verify not fixed

© 2013 CASSIDIAN - All rights reserved Page 17 Sicherheitskritische SW / Stefan Kauer Januar 2013 Tools Requirements-Engineering Design / Codegen (?) Versions- Konfigurationskontrolle mit integrierter Fehlerverfolgung Compiler Coverage (Testabdeckung Unit Test) Coding Standard Checker Re-Engineering: Erzeugung Klassen / Paket / Modul-Diagramme Generator für Schnittstellen-Beschreibung … Tool-Qualifikation - schwierig

© 2013 CASSIDIAN - All rights reserved Page 18 Sicherheitskritische SW / Stefan Kauer Januar 2013 The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization is prohibited. Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design. Thank you for your attention!