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

nützliche Quantitäten, ist (3) einfach, (4) breit anwendbar und basiert (5) auf soliden
Vermutungen (vgl. Musa 1999, S. 260).
SRM müssen zwei Situationen abdecken, nämlich Programme, in welchen die
Fehlerzustände behoben werden, wenn Fehlerwirkungen erscheinen („fault removal“)
und Programme, in welchen die Fehlerzustände nicht bzw. später behoben werden („no
fault removal“). Bei letzterem identifizieren die Tester die Fehlerzustände, aber die
Entwickler beheben die Fehlerzustände nicht bis zum nächsten Release – d.h. die
Fehlerwirkungsintensität ist konstant für die Dauer des Release. Man kann diese
Fehlerwirkungsprozesse mit Homogeneous Poisson Prozessen modellieren (vgl. Musa
1999, S. 265). Bei „fault removal“ ist die Situation schwieriger: „The situation of „with
fault removal“ occurs in reliability growth test“ (Musa 1999, S. 265).
Für viele Modelle gibt es analytische Ausdrucke (1) für die durchschnittliche Anzahl
von Fehlerwirkungen an jedem Zeitpunkt, (2) die durchschnittliche Anzahl von
Fehlerwirkungen in einem Zeitintervall, (3) die Intensität von Fehlerwirkungen an
jedem Zeitpunkt und (4) die Wahrscheinlichkeit der Verteilung von
Fehlerwirkungsintervallen (vgl. Musa 1999, S. 260).
3.2.1.3 Annahmen
Die Prognose des zukünftigen Verhaltens der Fehlerwirkungen nimmt an, dass sich die
Werte der Modellparameter während der Prognoseperiode nicht ändern. Wenn es jedoch
der Fall ist, dass die „fault introduction“ und „fault removal“ wesentlich geändert
werden, muss man entweder eine Kompensation für die Änderung vornehmen oder man
muss warten, bis genügend neue Fehlerwirkungen erscheinen, so dass man neue
Schätzungen der Modellparameter machen könnte. Das Einfügen solcher Änderungen
ist theoretisch möglich, aber in der Praxis wegen der zusätzlichen Komplexität
unmöglich (vgl. Musa 1999, S. 260).
Die meisten SRM basieren auf der Verwendung von stabilen Programmen in einer
stabilen Art. Diese Methode bedeutet, dass weder der Code noch die Verwendung
(operational set of possible operations and their probabilities of ocurrence) gewechselt
worden sind. Wenn die Programme und Umgebung sich verändern, muss man die
entsprechenden Modelle wählen. Daher gibt es Modelle, die die
Fehlerzustandsbehebung fokussieren (vgl. Musa 1999, S. 260f.).
20