Software Reliability Engineering im Infotainment - Georg-August ...

Weitere Magazine

Empfehlungen

Info

Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit (vgl. ebd., S. 310; ausführlich siehe Spillner; Linz 2005, S. 11). Zuverlässigkeit ist dabei ein zentrales Qualitätskriterium (vgl. Elbel; Mäckel o.Jg.), es wird ausführlich als Software Reliability in Kapitel 3 besprochen. Alle diese Qualitätsmerkmale muss man beim Testen berücksichtigen, um die Gesamtqualität einer Software bewerten zu können. Vorab muss festgelegt werden, welches Qualitätsniveau in den einzelnen Qualitätsmerkmalen erreicht werden soll – dies wird dann beim Testen überprüft. Thaller weist darauf hin, dass sich die Qualitätsattribute jedoch auch widersprechen können, dies muss man bei ihrer Festsetzung bedenken. So können sich beispielsweise Effizienz und Übertragbarkeit widersprechen (vgl. Thaller 1990, S. 88). Es muss also im Vorhinein festgelegt werden, welche Qualitätseigenschaften welche Priorität haben (vgl. Spillner; Linz 2005, S. 13). 2.2 Maßnahmen der Qualitätssicherung von eingebetteter Software 2.2.1 Überblick über verschiedene Prüftechniken Es gibt verschiedene Prüftechniken oder Methoden bei der Qualitätssicherung von eingebetteter Software, wie die folgende Abbildung 2.2-1 zeigt. Abbildung 2.2-1 Einordnung von Prüftechniken Quelle: Liggesmeyer 2002, S. 473; Liggesmeyer 2005a, S. 7 6
Zu den informalen Techniken gehören neben dem dynamischen Test auch die Inspektions- und Review-Techniken (statischer Test). Das (dynamische) Testen ist dabei „die wichtigste und häufigste Maßnahme der Qualitätssicherung.“ (Mellis 2001, S. 471). Unter Testen versteht man die Prüfung von codierten Programmen auf korrekte Formulierung und Ausführung. Testen ist ein analytisches Verfahren und gehört dort zu den so genannten dynamischen Prüfungen, um Fehler aufzufinden (vgl. Stahlknecht; Hasenkamp 2005, S. 288; vgl. Rätzmann 2004, S. 31). Dabei bedeutet ein Fehler die Nichterfüllung einer Anforderung (s.o.), eine Abweichung zwischen dem Istverhalten und dem Sollverhalten (vgl. Spillner; Linz 2005, S. 7). Das Testen kann prinzipiell nur die Anwesenheit von Programmierfehlern zeigen, jedoch nicht die völlige Abwesenheit von diesen (vgl. Stahlknecht; Hasenkamp 2005, S. 289). Man kann u.a. im Test nicht alle Anwendungssituationen nachbilden sowie nicht die Fehlerursache zeigen (vgl. Frühauf; Ludewig; Sandmayr 2007, S. 23). Der statische Test wird auch als statische Analyse bezeichnet (vgl. Spillner; Linz 2005, S. 77). Bei Inspektions- und Review- Techniken werden keine Werkzeuge im Vergleich mit den anderen statischen Techniken – wie Stilanalyse, Grafiken und Tabellen, Slicing und Datenflussanomalieanalyse – verwendet (vgl. Liggesmeyer 2005b, S. 211). Der Nachteil der informalen Techniken ist, dass die erzeugten Ergebnisse unvollständig sind im Gegensatz zu den formalen, dafür sind sie jedoch einfach und universell anwendbar. Diese informalen Techniken schließen Restfehler in der Software nicht aus, daher sind sie oftmals für sicherheitskritische Softwareanwendungsbereiche nicht ausreichend. Formale und stochastische Prüftechniken sind in der Software-Entwicklung nicht so verbreitet (vgl. Liggesmeyer 2002, S. 473; Liggesmeyer 2005a, S. 6f.). Das Testen stellt die Grundlage auch für die Anwendung stochastischer Analysen dar, da in den Testprozessen die erforderlichen Daten gewonnen werden. Der Nachteil der formalen Techniken ist, dass formale Techniken kompliziert sind und nur anwendbar auf bestimmte Bereiche. Stochastische Techniken wiederum liefern Ergebnisse, die quantifiziert werden, damit können sie zur Bestimmung der Restfehler dienen. Sie sind sozusagen ein Kompromiss zwischen formalen und informalen Techniken. Die stochastische Zuverlässigkeitsanalyse als eine Prüftechnik steht im Fokus der vorliegenden Arbeit, daher wird sie ausführlich in Kapitel 3 beschrieben. 7
Seite 1 und 2: GEORG-AUGUST-UNIVERSITÄT GÖTTINGE
Seite 3 und 4: Inhaltsverzeichnis Seite Zusammenfa
Seite 5 und 6: 5.1.1 Analyse der Komponente „gro
Seite 7 und 8: Tabellenverzeichnis Seite Tabelle 5
Seite 9 und 10: 1 Einleitung 1.1 Software Reliabili
Seite 11 und 12: werden zentrale Begriffe, Ziele und
Seite 13: Kundenverlust führen. Auch können
Seite 17 und 18: Umsetzung der Anforderung einer Pha
Seite 19 und 20: 2.2.4.2 Testendekriterien Besonders
Seite 21 und 22: Wert ist interpretierbar als der Er
Seite 23 und 24: equired, for a specified time, in a
Seite 25 und 26: MTTF (mean time to failure) ist die
Seite 27 und 28: 3.2.1.2 Merkmale Software Reliabili
Seite 29 und 30: 3.2.1.4 Ziele und Einsatz von Softw
Seite 31 und 32: „finite failure model“ (Farr 19
Seite 33 und 34: 3. Die isolierten Fehlerzustände s
Seite 35 und 36: 2. Die Fehlerwirkungsentdeckungswah
Seite 37 und 38: für i = 1, 2, ..., n konvertieren,
Seite 39 und 40: Der Chi-Quadrat-Test wird als „go
Seite 41 und 42: 4 Anwendungsfeld, Datenbasis und De
Seite 43 und 44: Abbildung 4.1-1 Head Unit im BMW-Au
Seite 45 und 46: 4.3 Analyse der Datenausgangsbasis
Seite 47 und 48: Bei allen ausgewählten Komponenten
Seite 49 und 50: (vgl. Xie 1991, S. 25). Da es sich
Seite 51 und 52: Abbildung 4.6-1 Beispiel Intervall-
Seite 53 und 54: Prognose der Restfehler sowohl mit
Seite 55 und 56: Man sieht in der Abbildung 5.1-3, d
Seite 57 und 58: Diese Daten mit den Daten der obige
Seite 59 und 60: Abbildung 5.1-5 Fehlerkurve und kum
Seite 61 und 62: Tabelle 5.1-3 Einschätzung und Pro
Seite 63 und 64: 5.1.3 Analyse der Komponente „kle
Seite 65 und 66:
Tabelle 5.1-5 Einschätzung und Pro
Seite 67 und 68:
Abbildung 5.1-11 Fehlerkurve und ku
Seite 69 und 70:
Tabelle 5.1-7 Einschätzung und Pro
Seite 71 und 72:
Tabelle 5.2-1 Anteil der Fehlerarte
Seite 73 und 74:
Head Unit wäre dies jedoch nicht r
Seite 75 und 76:
Tabelle 5.2-3 Vergleich der Restfeh
Seite 77 und 78:
Tabelle 5.2-5 Vergleich der Bestimm
Seite 79 und 80:
6 Zusammenfassung In diesem abschli
Seite 81 und 82:
Literaturverzeichnis (Birolini 2007
Seite 83 und 84:
(Stahlknecht; Hasenkamp 2005): Stah
Seite 85 und 86:
B Lesehilfe zum besseren Verständn
Seite 87 und 88:
C Abbildungen zur Datenanalyse (nic
Seite 89 und 90:
Abbildung C-5 Analyse der Daten mit
Seite 91:
Eidesstattliche Erklärung Ich erkl
Alle anzeigen

Software Reliability Engineering im Infotainment - Georg-August ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?