Zentralübung Automotive Software Engineering – Übungsblatt 8

Slides:



Advertisements
Ähnliche Präsentationen
Lexikon der Qualität Begriffe in Verbindung mit Qualität und ISO9000 finden sie auch im Lexikon der Qualität erläutert (
Advertisements

Qualität „Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener.
Phasen und ihre Workflows
Prof. Dr. Liggesmeyer, 1 Software Engineering: Dependability Prof. Dr.-Ing. Peter Liggesmeyer.
Analytische Qualitätssicherung
Eingebettete Systeme Qualität und Produktivität
Qualitätssicherung von Software (SWQS)
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Qualitätssicherung von Software (SWQS)
Spec# Proseminar Assertions im SS 2007 Uni Paderborn Andreas Martens Betreuer: Dipl. Inform. Björn Metzler.
Computergestützte Verifikation (Halbkurs) Karsten Schmidt Di 9-11 R Fr R
Computergestützte Verifikation
Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS : Software Model Checking.
Qualitätssicherung von Software
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
LE LM 10 - LO3 Verfahren zur Qualitätssicherung
Prozessqualität und Produktqualität
Erfahrungen aus Tests komplexer Systeme
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Einzeltests im Rahmen des V-Modelles Aufgaben Überprüfung des Programmcodes mit Hilfe.
Risiken und Chancen Risiko Beurteilung: Dazu gehört die Identifikationen von Risiken, ihre Analyse und das Ordnen nach Prioritäten. Risiko Kontrolle: Dazu.
Prüfung von SW-Komponenten – Überblick
Funktionalität Vorhandensein vor Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Richtigkeit - Liefern.
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.
Capability Maturity Model
Qualität von Software Qualität ist nicht messbar, sondern nur über die Erfüllung von Anforderungen zu definieren Die Erfüllung von Anforderungen ist oft.
K-Modeler Engineering
Testen, Analysieren und Verifizieren von Software
Validas Model Validation AG
Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Zentralübung Automotive Software Engineering – Übungsblatt 5 Sascha Schwind.
Mehr Qualität und schnellere Marktreife durch effiziente Softwaretests
INSTITUT FÜR DATENTECHNIK UND KOMMUNIKATIONS- NETZE 1 Harald Schrom ViEWcon08.
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering1 Zentralübung Automotive Software Engineering – Übungsblatt 3 Sascha Schwind.
Zentralübung Automotive Software Engineering – Übungsblatt 4
Whitebox Testen mit JUnit
Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec.
Statische Analyse Gero Leinemann.
Zusammenfassung der Vorlesung
AK Tools/Expertengruppe HiL Workshop Standardisierung HiL Status der Expertengruppe zum Thema Standardisierung Dr. Peter Rißling, BMW AG Version: 1.00.
QS in Softwareentwicklungsprojekten III
Binde & Wallner Engineering GmbH
Softwaretechnik und Informationssysteme (Gebiet und Modul II.1.1, Module III.1.x) Dozenten der Softwaretechnik.
Effiziente Algorithmen
Black Box Algorithmen Hartmut Klauck Universität Frankfurt SS
Einführung Modellgetriebene Softwareentwicklung, Metamodellierung Stephan Hildebrandt.
Fachhochschule München, Projektstudium Chipkarten SS 2002 Qualitätssicherung/Tester Wozu braucht man Tester? Vorbereitung Durchführung Ergebnisse Resumée.
Seminar: Entwicklung verteilter eingebetteter Systeme WS05/06 Betreuer: Info:
Qualitätssicherung Software(technik)praktikum - Vorlesung Qualitätssicherung
Qualitätsmanagement in der Entwicklung !?. artiso solutions GmbH | Oberer Wiesenweg 25 | Blaustein | Agenda 1. Ziele und Probleme.
Wasserfallmodell und Einzelbegriffe
HFWI System Development Teil B Der Softwareentwicklungsprozess
Technische Universität München Automotive Software Methoden und Technologien Zentralübung Übungsblatt 2: Domäne Antrieb 03. Mai 2012 Sascha Schwind.
Vienna University of Technology Pirker Simon 1. Überblick Definition Motivation Vorteile Entwurf von VP Pirker Simon 2.
Qualitätskriterien für Software
Unified Modeling Language UML
Technische Universität München Zentralübung Automotive Software Engineering – Übungsblatt 6.
Möglichkeiten der Visualisierung
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
Objektorientierung und sichere Software mit Ada
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Software Verification 2 Automated Verification Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für.
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Entwurf Dr. Wolfgang Wörndl
Systems Requirements & Achitectur ENG 2 & ENG 3 Training Kunde,
 Präsentation transkript:

Zentralübung Automotive Software Engineering – Übungsblatt 8 Sascha Schwind

Produktorientierte QS Statisch Überprüfung von Coding Standards, z.B. MISRA-C Metriken: Bewertung der Code-Komplexität, z.B. Cyclomatic Complexity, McCabe Zusicherung, z.B. Hoare Kalkül Theorem Prüfer, z.B. Isabelle Model Checking, z.B. SMV Reviews/Inspektion Dynamisch Tests Simulation Welche QS-Maßnahmen sind konstruktiv, welche sind analytisch?

Prozessorientierte QS Vorgaben Definierter Entwicklungsprozess, z.B. Instanziierung eines Standardvorgehensmodells, wie V-Modell XT Normen und Standards, Anforderungen an den Prozess, z.B. CMMI Bewertung Audits Assessments, z.B. nach SPICE Welche QS-Maßnahmen sind konstruktiv, welche sind analytisch?

Modellbasiertes Testen Testvariationen: Modell als Testorakel Umgebungsmodell Runtime Verification „Testebenen“: HIL, SIL Meist Generierung von Testfällen: Input- und Outputsequenzen

Fall 1: Testmodell = Implementierungsmodell Requirements Modell Codegenerierung Testfallgenerierung Code Abstrakte Testfälle Deployment/Glue Code Test Treiber Plattform Konkrete Testfälle Unterschiede? Was wird dabei getestet? Code-Generator Glue Code Hardware/Treiber/Basissoftware/OS Ggf. Diskretisierungsfehler

Fall 2: Eigenes Testmodell Requirements Impl. Modell Testmodell Codegenerierung Testfallgenerierung Code Abstrakte Testfälle Deployment/Glue Code Test Treiber Plattform Konkrete Testfälle Unterschiede? Was wird dabei getestet? Applikationslogik Interpretation der Anforderungen, Vollständigkeit der Anforderungen (z.T. Validierung) Aber: Aufwändig, weil redundante Entwicklung! Deshalb ist Abstraktion im Testmodell notwendig!

Statische Analyse [Righting Software, Larus et. al.] Kann man alle Fehler durch statische Analyse finden?  Nein, Halteproblem: Nicht-triviale Eigenschaften sind nicht entscheidbar. Statische Analysewerkzeuge sind immer ein Kompromiss zwischen Präzision und Vollständigkeit: Vollständig aber unpräzise: Heuristik-basierte Tools, z.B. Lint, FindBugs, FxCop, … ( False Positives) Unvollständig aber präzise: Abstrakte Simulation, Überprüfung von Vor- /Nachbedingungen und Invarianten, Prüfung gegen formale Spezifikation (z.B. in Temporaler Logik), … Immer: Fokus auf bestimmte Eigenschaften/Abstraktion! Probleme der Plattform werden oftmals ignoriert.

Generierung von Testfällen Kann man ein System vollständig testen?  Man kann meist nicht alle Testfälle überprüfen, da exponentiell viele (Kreuzprodukt aller Inputtypen)! Meist wird deshalb versucht bestimmte Überdeckungsmaße (Metriken für Testqualität) zu erreichen: Anforderungsüberdeckung Ein-/Ausgabeüberdeckung (Äquivalenzklassenbildung) Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Randfälle (Analog für Automaten: Knoten-/Kanten-/Pfadüberdeckung)