Читать книгу Softwaretest in der Praxis - Stefan Schmerler - Страница 6

2 Zuverlässigkeitsanalysen

Zuverlässigkeitsanalysen unterstützen den Absicherungsprozess durch die Einführung von Metriken zur Beurteilung des Reifegrads, insbesondere des Ausfallverhaltens von Software. Auf diese Weise bekommt der Tester objektive Kriterien an die Hand, nach denen er entscheiden kann, ob die angestrebten Qualitätsziele erreicht wurden und der Testprozess beendet werden kann.

2.1 Wichtige Eigenschaften von Embedded Software

Im Gegensatz zu Bürosoftware kann von Software eingebetteter Systeme eine erhebliche Gefährdung ausgehen. Aus diesem Grunde wurden bereits vor einigen Jahren Normen geschaffen, die sich mit Sicherheitsaspekten von Software auseinandersetzen. Eine dieser Normen ist die ISO 26262 [7]. Sie definiert:

Sicherheit ist die Abwesenheit unakzeptabler Risiken.

Realistischerweise wird auch für sicherheitskritische Systeme keine vollständige Abwesenheit von Risiken gefordert, vielmehr ist das Restrisiko auf einen annehmbaren Wert zu begrenzen. Man unterscheidet ferner zwischen Safety und Security:

Safety steht für den Schutz der Umwelt vor Fehlern der Elektronik, Security für den Schutz der Elektronik gegen Manipulation von außen.

Es bleibt festzustellen: Software ist sicher im Sinne von Safety, eingebettete Software nicht unbedingt. Je größer die möglichen Auswirkungen von Fehlverhalten sind, desto sicherheitskritischer ist die Software einzustufen.

Zuverlässigkeit

DIN EN ISO 9000 definiert den Begriff Zuverlässigkeit als Sammelbegriff zur Beschreibung der Verfügbarkeit eines Systems mit den Einflussfaktoren Funktionsfähigkeit, Instandhaltbarkeit und Instandhaltungsbereitschaft. Man benutzt hier auch den englischen Ausdruck Dependability.

DIN 40041

Die DIN 40041 verwendet einen engeren Zuverlässigkeitsbegriff im Sinne einer stochastischen Qualitätseigenschaft im Hinblick auf das Verhalten während oder nach bestimmten Zeitspannen unter vorgegebenen Anwendungsbedingungen. In dieser Definition spricht man im Englischen von Reliability.

Zuverlässigkeit ist ein Maß für die Funktionstüchtigkeit, ausgedrückt durch die Wahrscheinlichkeit, über eine definierte Zeit und bei definierten Randbedingungen funktionstüchtig zu bleiben.

Das Qualitätsmerkmal der Zuverlässigkeit untergliedert sich in vier Teilmerkmale:

▶Die Verfügbarkeit (Availability) beschreibt die Betriebsbereitschaft eines Systems oder einer Komponente.

▶Der Reifegrad (Maturity) gibt an, wie gut ein System funktional die Anforderungen erfüllt, durch die es spezifiziert wurde.

▶Unter Fehlertoleranz (Fault Tolerance) ist zu verstehen, wie gut ein System oder eine Komponente trotz Vorhandensein von Hardware- oder Softwarefehlern funktional noch seinen Anforderungen entspricht.

▶Die Wiederherstellbarkeit (Recoverability) gibt an, wie lange im Fehlerfall der funktionale Ausfall des Systems oder der Komponente voraussichtlich anhalten wird.

MTBF

Als stochastische Eigenschaft können nun Kenngrößen definiert werden, allen voran die MTBF (Mean Time between Failure). Bei reparierbaren Systemen ist dies der Mittelwert der Zeitspanne zwischen zwei Ausfällen eines technischen Systems. Diese statistische Information sagt allerdings wenig über dessen Lebensdauer aus. Wenn z. B. ein Festplattenhersteller seine Geräte mit einer MTBF von 2.000.000 Stunden bewirbt – das entspricht einem mittleren Ausfall nach 228 Jahren – lehrt die eigene Erfahrung bereits, dass dies ein theoretischer Wert unter idealen Laborbedingungen sein muss, nicht die real zu erwartende Lebensdauer. Die Werte sind ferner Hochrechnungen des Ausfallverhaltens auf Grundlage von Beobachtungen über deutlich kürzere Zeiträume.

MTTF

Unter Mean Time to Failure (MTTF) versteht man bei nichtreparierbaren Systemen die mittlere Betriebsdauer bis zum Ausfall.

MTTR

Mean Time to Repair (MTTR) wiederum bezeichnet bei reparierbaren Systemen den Mittelwert des Stillstandszeitintervalls (Reparaturdauer).

Verfügbarkeit

Aus diesen Größen lässt sich die Verfügbarkeit, also das Maß für die Fähigkeit eines Systems, zu einem gegebenen Zeitpunkt funktionstüchtig zu sein, als das folgende Verhältnis berechnen:

Höhere Verfügbarkeit ergibt sich durch Vergrößerung der Zuverlässigkeit (Zähler) und Verringerung der Stillstandszeitintervalle (Nenner).

Echtzeiteigenschaften: hart,

fest oder weich

Eine weitere für den Reifegrad eingebetteter Systeme wichtige Eigenschaft ist die Echtzeitfähigkeit. Dem Test dieser Eigenschaft ist im weiteren Verlauf dieses Buchs ein eigenes Kapitel gewidmet. Grob unterscheidet man nach harter, fester und weicher Echtzeitfähigkeit. Für harte Echtzeitsysteme bedeutet eine Abweichung im Zeitverhalten (besonders die Nichteinhaltung von Deadlines) in der Regel einen Fehler. Zu späte Reaktionen sind also Funktionsfehler.

Das Zeitverhalten wird wie

eine Funktion behandelt.

Bei festen Echtzeitanforderungen droht zwar nicht unbedingt ein unmittelbarer Schaden. Nach Ablauf der Zeitanforderung ist das Ergebnis der Berechnung jedoch nutzlos und kann verworfen werden. Weiche Echtzeitfähigkeit bedeutet hingegen, dass gemäß Spezifikation verspätete Reaktionen nur störend sind, sie führen aber zu keinem kritischen Systemverhalten und werden auch nicht verworfen.

2.2 Zuverlässigkeitsmodelle

Von zentraler Bedeutung beim Testen ist die sinnvolle Feststellung eines Testende-Kriteriums. Bei einem sinnvoll bestimmten Mindestreifegrad kann und sollte der Testprozess abgebrochen werden. Auch ein »Übertesten« sollte aus wirtschaftlichen Gründen nicht erfolgen – Aufwand und Nutzen stehen dann in keinem guten Verhältnis mehr.

Metriken für den Reifegrad

Voraussetzung für all dies sind quantifizierbare Eigenschaften des Softwarereifegrads – wir brauchen Metriken! Genau hier helfen uns Zuverlässigkeitsmodelle.

Was ist ein Zuverlässigkeitsmodell?

Ein Zuverlässigkeitsmodell ermöglicht Aussagen über das in Zukunft zu erwartende Ausfallverhalten, ohne auf statistische Werte warten zu müssen. Man kann z. B. schlecht fünf Jahre bei der Ermittlung einer MTTF warten, um eine Metrik hinsichtlich Ausfallverhalten zu erhalten. Aus diesem Grund greift man auf Daten zurück, die aus dem während der Entwicklung beobachteten Ausfallverhalten gewonnen wurden. Der Vorteil dieses Vorgehens liegt auf der Hand: Wir schaffen uns auf diese Weise die Möglichkeit zur Prävention. Im Auge behalten muss man nur die Beurteilungsqualität. Wie immer bei der Nutzung eines Modells liegt eine Abstraktionsstufe zwischen Modell und Realität. Gängige Methoden der Zuverlässigkeitsermittlung sind z. B.

▶FMECA (Failure Mode, Effects and Criticality Analysis): IEC 6081206

▶Zuverlässigkeitsblockdiagramm: IEC 6107806

▶FTA (Fault Tree Analysis/Fehlerbaumanalyse): DIN 2542490

▶Markov-Analysen: IEC 6116506

Auf einen Teil dieser Methoden wird im weiteren Verlauf noch eingegangen. Allen gemein ist das Ansinnen, Struktur und Metrik in den Beurteilungsprozess für die Zuverlässigkeit von Software zu bringen.

2.2.1 Software-FMECA

Bei der Software-FMECA handelt es sich um eine präventive Methode zur Identifikation von Fehlern, ihrer Risiken und Auswirkungen. Ziel ist die Quantifizierung von Risiken sowie das Finden geeigneter Abhilfemaßnahmen. Die Durchführung einer Software-FMECA erfolgt in einer Abfolge von vier Schritten, die im Folgenden dargestellt werden. Die Einführung einer Risikoprioritätszahl hilft bei der quantitativen Bewertung von Risiken.

1.Ausfallanalyse: Hier macht man sich Gedanken über die wesentlichen Ausfälle, die das System zeigen könnte. Insbesondere die Fragestellung »Was darf unter keinen Umständen passieren?« ist hier sehr hilfreich.

2.Dann erfolgt für jedes dieser Risiken eine Risikobewertung durch Ermittlung einer Risikoprioritätszahl (RPZ).

RPZ = Eintrittswskt × Gewicht der Folgen × Wskt des Nichtentdeckens

Für jeden der drei Einflussfaktoren wird ein Wert zwischen 1 und 10 angesetzt (1: niedrig/gering, 10: hoch), sodass sich für jedes der Risiken eine RPZ im Bereich 1 bis 1000 ergibt.

3.Für jedes der Risiken sind Maßnahmenvorschläge zu erarbeiten, beginnend bei Risiken mit hoher RPZ. Dies sind die Risiken, die z. B. eine hohe Eintrittswahrscheinlichkeit bei moderatem Schaden aufweisen bzw. immensen Schaden bei moderater Eintrittswahrscheinlichkeit.

4.Die RPZ wird nach Einarbeiten der Maßnahmen erneut analysiert.

Oftmals wird in der Praxis bei größeren Entwicklungsprojekten eine Software-FMECA vorgeschrieben. Dies ist ein einfaches Hilfsmittel und bringt Systematik und vor allem Metrik in den Reifegradprozess. Man ist gezwungen, sich ggf. noch vor Beginn der Entwicklung Gedanken über mögliches Fehlverhalten zu machen und Gegenmaßnahmen vorzusehen. Auch hier möchte man die Vorteile der Prävention nutzen und ein System nicht nachträglich durch aufgetretene Fehler kennenlernen. Die FMECA zielt auf die Erkennung gravierender Mängel ab und hat sich in der Praxis sehr bewährt.

2.2.2 Fehlerbaumanalyse

Die Fehlerbaumanalyse gehört zur Gruppe der qualitativen wie auch zu den quantitativen Analysemethoden. Sie kommt zum Einsatz bei sicherheitskritischen, komplexen Systemen.

komplexe Fehlermechanismen herunter-

brechen auf beherrschbare Problemgrößen

Das Prinzip der Fehlerbauanalyse ist es, komplexe funktionale Zusammenhänge, über deren Ausfallverhalten man keine klaren Aussagen treffen kann, aufzubrechen in kleinere, beurteilbare Einheiten und die Teilergebnisse zu einer Gesamtaussage zu aggregieren. Hochkomplexe Systeme werden auf diese Weise in ihrem Ausfallverhalten quantitativ beurteilbar.

Eine Besonderheit der Fehlerbaumanalyse ist die Möglichkeit der grafischen Repräsentation, um den Zusammenhang zwischen Fehlerursache und -wirkung zu veranschaulichen.

Zum Einsatz kommen nach DIN 25424 genormte Symbole als Elementarbausteine, aus denen der Baum des Gesamtsystems sukzessive zusammengesetzt wird (Abb. 2-1).

die elementaren Verknüpfungen

Die Grundlogik für die drei elementaren Verknüpfungen NICHT, ODER und UND ist jeweils, dass eine Fehlerwirkung (A = 1) eintritt, falls die verknüpften Ereignisse die jeweils genannte Eigenschaft erfüllen.

Durch Aufbau komplexer Strukturen aus Elementarbausteinen mit bekanntem Ausfallverhalten kann also modelliert werden, wie Fehler sich in einem System fortpflanzen bzw. ausbreiten. Am Ende steht ein Blick auf das Ausfallverhalten des Gesamtsystems. Dies sind interessante Erkenntnisse, insbesondere, wenn bereits Vorkehrungen zur aktiven Fehlererkennung und -beseitigung im laufenden Betrieb vorgesehen sind.

Abb. 2-1: Symbole Fehlerbaumanalyse gemäß DIN 25424

Sekundärverknüpfung für Fehler, die

sich nur möglicherweise fortpflanzen

Vor diesem Hintergrund sind auch die beiden letzten Elementarbausteine in Abb. 2-1 zu sehen. Bei der Sekundärverknüpfung gilt folgende Logik: Falls sich der Wert an Eingang E1 einer Sekundärverknüpfung von logisch 0 nach 1 ändert, so wird mit einer an Eingang E2 angegebenen Dauer und Wahrscheinlichkeit der Wert des Ausgangs auf logisch 1 gesetzt. Es werden also Sekundärausfälle beschrieben, die nur möglicherweise von Primärausfällen hervorgerufen werden.

Modellierung von Redundanz

Mit der Reserveverknüpfung lässt sich eine Strategie der aktiven Fehlerbehebung durch Redundanz (z. B. bei sicherheitskritischen Systemen) modellieren.

E1 und E2 sind die Eingänge der Verknüpfung. Sie stellen redundante Funktionselemente dar: E1 für Betrieb, E2 für Reserve. Fällt E1 aus (E1: 0 → 1), so wird auf E2 durch die Umschalteinrichtung E12 (E12: 0 → 1) umgeschaltet. Nach der Reparatur kann durch die Umschalteinrichtung E21 auf die Einheit E1 zurückgeschaltet werden (E21: 0 → 1). Der Ausgang A besitzt den Wert 1, falls beide Einheiten ausgefallen sind (E1 = E2 = 1). Das System fällt somit nur dann aus, wenn auch die redundante Reserveeinheit ausgefallen ist.

Aufbau des Fehlerbaums top-down

von der Wurzel bis zu den Blättern

Die Erstellung eines Fehlerbaums für ein System erfolgt nun derart, dass komplexe Systeme top-down aus ihren Teilsystemen modelliert werden. Der Ausgang eines Teilsystems S1 wird dabei mit dem Eingang eines anderen Teilsystems S2 verknüpft, wenn der Ausfall von S1 Auswirkungen auf die Funktionsfähigkeit von S2 hat.

Eine Weiterentwicklung dieses Vorgehens ist es, anstelle von Binärwerten 0/1 die Ereignisse mit Ausfallfunktionen F(t) zu belegen, wobei Folgendes gilt:

▶Der Ausfallfunktionswert F(t1) ist die Wahrscheinlichkeit eines Ausfalls bis zur Zeit t1.

▶F(t) ist eine monoton steigende Funktion: Zum Zeitpunkt t = 0 ist die Ausfallwahrscheinlichkeit 0, für t → ∞ wird sie 1.

Sind den Eingängen einer UND-Verknüpfung die Verteilungsfunktionen F1(t) und F2(t) zugeordnet, so ergibt sich für die Ausfallfunktion des Ausgangs FA(t):

Sind den Eingängen einer ODER-Verknüpfung die Verteilungsfunktionen F1(t) und F2(t) zugeordnet, so ist die Ausfallfunktion des Ausgangs FA(t):

wobei die Überlebenswahrscheinlichkeit R(t) = 1 – F(t) beträgt.

Voraussetzung für die Gültigkeit der angegebenen Formeln ist die statistische Unabhängigkeit der verknüpften Ereignisse. Ist diese gegeben, ergibt sich z. B. für die Ermittlung der resultierenden Ausfallfunktion des kleinen Beispielsystems mit den Elementarverknüpfungen UND und ODER der folgende Graph. Die quantitative Auswertung versagt allerdings, falls statistische Abhängigkeit der Ereignisse Ei vorliegt. Die Identität zweier Ereignisse (ein Ereignis tritt mehrfach auf) als Sonderfall statistischer Abhängigkeit wäre somit unzulässig. Tritt aber ein Ereignis mehrfach auf, kann ggf. der Fehlerbaum durch einfache Anwendung boolescher Algebra, in diesem Fall des Distributivgesetzes, so umgeformt werden, dass keine Ereignisredundanz mehr vorliegt (Abb. 2-2).

Abb. 2-2: Boolesche Umformungen sind hilfreich.

2.2.3 Markov-Modellierung

Das Systemverhalten wird als sto-

chastischer Prozess verstanden.

Eine weitere gängige Methode der Zuverlässigkeitsmodellierung ist die Markov-Modellierung. Sie beschreibt das Systemverhalten mit Zustandsautomaten als stochastischen Prozess. Ziel ist es, die Wahrscheinlichkeit für das Eintreten zukünftiger Ereignisse anzugeben. Fasst man das Auftreten eines Fehlers als Ereignis auf, dessen Wahrscheinlichkeit für die Beurteilung des Reifegrads von Bedeutung ist, kann eine Analyse von Markov-Modellen wertvolle Aussagen liefern. Insbesondere ist die Frage interessant, mit welcher Wahrscheinlichkeit unser System denn nun defekt ist, wenn man es zu einem zufälligen Zeitpunkt betrachtet.

zufällige Zustandsübergänge

Bei einer Markov-Kette besteht die Möglichkeit, die Kanten eines Zustandsautomaten mit Wahrscheinlichkeiten zu versehen und somit zufällige Zustandsänderungen im Modell zu hinterlegen.

Dies gestattet die Beschreibung eines zufälligen Ausfallverhaltens mittels der statistischen Ausfallrate λ und der Reparaturrate μ. Im Beispiel ist der intakte Systemzustand mit A bezeichnet, der Systemausfallzustand mit B.

Ausfallrate λ

Die Ausfallrate λ ist zu verstehen als Grenzwert der in einem Zeitintervall Δt ausgefallenen Einheiten bezogen auf die zu Beginn noch funktionsfähigen Einheiten R(t) für Δt → 0.

Abb. 2-3: Illustration der Ausfallrate am Beispiel von Glühbirnen

Es handelt sich um die bedingte Wahrscheinlichkeit, dass ein System, das bis zum Zeitpunkt t ausfallfrei war, auch noch das Zeitintervall Δt ohne Ausfall übersteht.

Reparaturrate μ

Die Reparaturrate μ ist entsprechend zu verstehen als Anzahl der Reparaturen bezogen auf die Zeiteinheit. Für die zeitliche Veränderung der Aufenthaltswahrscheinlichkeit in den Zuständen A oder B gilt schließlich:

Mit welcher Wahrscheinlichkeit ist ein

System defekt, wenn man es zu einem

zufälligen Zeitpunkt betrachtet?

Die erste Gleichung bedeutet, dass die Änderung der Wahrscheinlichkeit, dass sich das System in Zustand A befindet, also funktionstüchtig ist, verursacht werden kann durch einen Wechsel von B (»defekt«) nach A (also positives Vorzeichen) abzüglich einer Bewegung von A nach B (negatives Vorzeichen). Eine ähnliche Interpretation findet sich für die zweite Gleichung, die eine Veränderung des Systems beschreibt, das sich in Zustand B befindet.

Es bleibt noch festzustellen, dass PA(t) + PB(t) = 1 gilt, da sich das System stets in einem der beiden Zustände befinden muss. Ohne Herleitung ergibt sich nach Lösung des Differenzialgleichungssystems für die Wahrscheinlichkeit, ein System mit gegebener Ausfall- und Reparaturrate im fehlerfreien Zustand anzutreffen, der Ausdruck

Wir haben eine quantitative

Aussage über die Zuverlässigkeit!

Auch dies kann eine interessante Aussage über die Zuverlässigkeit von reparierbaren Systemen sein, wenn Ausfall- und Reparaturrate bekannt sind.

2.2.4 Stochastische Zuverlässigkeitsanalyse für Software

Wir versuchen, Aussagen über das zu-

künftige Ausfallverhalten zu erhalten.

Mit Zuverlässigkeitsmodellen versucht man, durch Beobachtung des Ausfallverhaltens über einen bestimmten Zeitraum Prognosen über das zukünftig zu erwartende Ausfallverhalten zu erlangen. Zuverlässigkeitsmodelle werden häufig durch Kenngrößen parametriert, wobei die Parameter in einer Beobachtungsphase stochastisch ermittelt werden.

Fällt Software wirklich zufällig aus?

Die Aussagekraft der Ergebnisse von Softwarezuverlässigkeitsmodellen hängt natürlich stark von der Qualität der zugrunde liegenden Modelle ab, besitzt aber einen präventiven Charakter. Die Frage ist dabei allerdings, inwieweit Software überhaupt stochastisches Ausfallverhalten aufweist. Ein spontaner – also rein zufälliger – Ausfall ist zwar nicht möglich und Software verschleißt auch nicht, dennoch erscheint der Ausfall aus Sicht des Benutzers oft als durchaus zufällig und unmotiviert. Viele Softwarefehlerzustände, wie z. B. nichtinitialisierte Zeiger in der Sprache C, treten quasi zufällig auf, zumindest abhängig von zufälligen Speicherinhalten im nichtinitialisierten Arbeitsspeicher. Auch die Art und Intensität der Benutzung von Software beeinflusst die Häufigkeit, mit der vorhandene Fehler tatsächlich zutage treten.

Wenn Software aber stochastisches Ausfallverhalten aufweist, können Software und Hardware mit analogen Zuverlässigkeitsmodellen betrachtet werden, d. h., wir können Kenngrößen übertragen, die wir aus der Hardwarezuverlässigkeit kennen.

Lebensdauer T - wir ziehen eine Analogie

zwischen Software und Glühbirnen.

Interessant wäre zunächst die Lebensdauer T. Hinsichtlich der Lebensdauer als stochastischer Kenngröße bemühen wir hier die Analogie zu einem Kollektiv von sagen wir N = 1000 Glühbirnen, die eine gewisse Lebensdauer bis zu ihrem ersten (und letzten) Ausfall aufweisen. Bei N Glühbirnen ergibt sich eine Wahrscheinlichkeitsverteilungsfunktion F(t) für den Ausfall. Die Lebensdauer T repräsentiert hierbei die Zufallsvariable und F(t) die zugehörige Verteilungsfunktion. Es gilt: F(t1) ist die Wahrscheinlichkeit, dass der Ausfall in 0 ≤ t ≤ t1 erfolgt ist, die Lebensdauer also T ≤ t1 beträgt, und es ergibt sich

Überlebenswahrscheinlichkeit R(t)

R(t) bezeichnet die Überlebenswahrscheinlichkeit 1 − F(t), d. h. die Wahrscheinlichkeit, dass bis zum Zeitpunkt t noch kein Ausfall aufgetreten ist. Da F(t) die Verteilungsfunktion einer Zufallsvariable ist, ergibt sich als Wahrscheinlichkeitsdichtefunktion f (t) = dF(t) / dt.

Ermittlung der Ausfallrate λ

Des Weiteren lässt sich eine Ausfallrate λ(t) bestimmen als Grenzwert der in einem Zeitintervall Δt ausgefallenen Einheiten pro Zeiteinheit bezogen auf die zu Beginn von Δt noch funktionsfähigen Elemente R(t) für Δt → 0:

Die MTTF bzw. Mean Time between Failure (MTBF) bei reparierbaren Systemen ergibt sich gemäß der Definition des stochastischen Erwartungswerts E(T ) zu

Annahme eines exponentialverteilten

Ausfallverhaltens von Software

Leider haben wir aber noch keine Dichte der Ausfallfunktion f (t) bzw. Verteilungsfunktion für das Ausfallverhalten für Software, um diese Größen auswerten zu können. Es ist auch nicht klar, ob es überhaupt eine dedizierte Ausfallfunktion für Software gibt. Wir kennen aber die Randwerte F(0) = 0 und F(t → ∞) = 1 und treffen hier die Annahme einer Exponentialfunktion F(t) = 1 – e-λ(t) mit dem Parameter λ(t) (Abb. 2-4).

Abb. 2-4: Annahme exponentialverteilter Ausfallfunktion für Software

Unter dieser Annahme (deren Korrektheit wir im Übrigen noch beurteilen werden) können wir unsere Kenngrößen Lebensdauer und MTTF nun in alleiniger Abhängigkeit vom Parameter Ausfallrate λ ausdrücken.

Dies ist interessant: Unter der Annahme einer exponentialverteilten Ausfallfunktion verliert die Ausfallrate ihre Abhängigkeit von der Zeit, sie wird zeitlich konstant.

zeitunabhängiges Ausfall-

verhalten von Software

Dies ist ein Indiz dafür, dass unsere Annahme einer exponentialverteilten Ausfallfunktion, die wir ja noch beurteilen wollten, korrekt war. In der Tat kann das Ausfallverhalten von Software ja nicht zeitabhängig sein – Software verändert sich nicht oder verliert ihren Reifegrad, je länger sie benutzt wird. Ganz im Gegensatz zu Glühbirnen oder Halbleitern in der Mikroelektronik. Dort haben wir es mit einem ausgeprägt zeitabhängigen Ausfallverhalten zu tun: Wir erinnern uns an die Badewannenkurve des Ausfallverhaltens von Halbleitern, das ganz zu Beginn (Produktionsfehler) und nach einigen Jahren Betrieb (Halbleiteralterung) ansteigt und in den zwischenzeitlichen Nutzungsjahren konstant niedrige Werte aufweist.

Die MTTF für Softwareausfälle wird damit ebenfalls zeitunabhängig:

Interessant ist noch die Ausfallzeit T50 , also diejenige Zeit, zu der die Wahrscheinlichkeit eines Softwareausfalls 50 % beträgt: F(T50 ) = 0,5:

unterschiedliches Ausfallverhalten

von Hardware und Software

Bemerkenswerterweise ist diese Zeit nicht der Erwartungswert der Lebensdauer (also die mittlere Lebensdauer) – sie ist deutlich kleiner, d. h. die Überlebenswahrscheinlichkeit 50 % wird bereits deutlich früher erreicht als der mittleren Lebensdauer entspricht.

Das unterschiedliche Ausfallverhalten von Hardware und Software wird in der folgenden Darstellung illustriert. Die zeitabhängige Ausfallrate λ bei Hardware führt dazu, dass im Laufe der Zeit neue Fehler hinzukommen. Alle zu einem Zeitpunkt vorhandenen Fehler sind immer sichtbar, d. h. beobachtbar und zeigen Fehlerwirkung (linkes Bild in Abb. 2-5).

Abb. 2-5: Zeitabhängigkeit von Ausfallraten bei HW und SW

2.2.5 Stochastische Zuverlässigkeitsmodelle für Software

Musa, Jelinski-Moranda,

Littlewood-Verrall

Seit den 1970er Jahren wurde eine Reihe von Zuverlässigkeitsmodellen für Software entwickelt. Verbreitet und noch immer anwendbar sind die Modelle nach John D. Musa [8], das Jelinski-Moranda-Modell [9] und auch das Littlewood-Verrall-Modell [10].

Allen gemeinsam ist das Vorgehen, die freien Parameter des Zuverlässigkeitsmodells so zu bestimmen, dass das Verhalten des Modells möglichst nahe am zu beobachtenden Ausfallverhalten in der Realität liegt. Hierfür gibt es mehrere Ansätze, zwei davon werden im Folgenden vorgestellt.

Im Verfahren der kleinsten Fehlerquadrate werden die Quadrate der Abweichungen zwischen jeder Beobachtung und dem Wert, den das Zuverlässigkeitsmodell an dieser Stelle liefert, durch Parameteradjustierung minimiert.

Maximiert wird die Wahrschein-

lichkeit für ähnliches Verhalten.

Im Maximum-Likelihood-Verfahren werden freie Parameter so gewählt, dass die Wahrscheinlichkeit maximiert wird, ein zur vorliegenden Beobachtung ähnliches Verhalten zu erzielen.

Wer auf den ersten Blick keinen wesentlichen Unterschied zwischen den beiden Arten der Parameterbestimmung erkennt, dem sei dies anhand eines kleinen Beispiels erläutert. Wir betrachten das Ausfallverhalten und die Lebensdauer T von N Komponenten (man könnte sich wieder 1000 Glühbirnen vorstellen). Nach und nach fallen einzelne Komponenten aus und nach langer Zeit ist zu erwarten, dass n = N Komponenten ausgefallen sind. Dies ist das beobachtete Ausfallverhalten:

Abb. 2-6: Beobachtetes zeitliches Ausfallverhalten

Beispiel für kleinste Fehlerquadrate

Nach der Methode der kleinsten Fehlerquadrate sollen nun die Parameter der Verteilungsfunktion bestimmt werden. Fi bezeichnen hier die Werte dieser empirischen Verteilungsfunktion entsprechend der obigen Tabelle, wohingegen F(ti) den Wert repräsentiert, den hier unser Zuverlässigkeitsmodell liefert und dessen Parameter wir bestimmen wollen. Die Methode der kleinsten Fehlerquadrate ergibt

Annahme: Exponential-

verteiltes Ausfallverhalten

Da wir ein Zuverlässigkeitsmodell für Software parametrieren, wird für das Ausfallverhalten eine Exponentialverteilung angesetzt. Die Minimierung der Differenzfunktion Δexp ergibt unter diesen Randbedingungen das folgende Gleichungssystem:

Ein numerisches Lösungsverfahren liefert die Lösung λ = 3,93 . 10-5/h. Die Summe der Fehlerquadrate beträgt dann 2,81 . 10-3.

dasselbe Beispiel für

Maximum-Likelihood

Wenden wir auf unser kleines Beispiel aber das Maximum-Likelihood-Kriterium an, so werden die Parameter der Verteilung so ermittelt, dass die Wahrscheinlichkeit maximiert wird, über die Verteilungsfunktion eine möglichst ähnliche Ausfallcharakteristik zu erhalten wie das beobachtete Verhalten.

Likelihood-Funktion

Die Likelihood-Funktion L muss also das Produkt der Dichten an den beobachteten Ausfallzeitpunkten sein – in gleicher Weise wie Wahrscheinlichkeiten multipliziert werden, wenn Ereignisse gemeinsam eintreten sollen. Ihr Wert ist proportional zu der Wahrscheinlichkeit, Ausfallzeitpunkte zu beobachten, die von der vorliegenden Beobachtung maximal Δt abweichen. Diese gilt es zu maximieren. Für das Ausfallverhalten wird wieder eine Exponentialverteilung angenommen.

Für die Likelihood-Funktion L bei n beobachteten Ausfallzeiten ergibt sich also:

Aufgrund der Monotonie der Logarithmusfunktion besitzen L und ln(L) dieselben Extrema:

Das Maximum der Likelihood-Funktion ergibt sich zu:

2.2.6 Zuverlässigkeitsmodell nach Musa

Auch wenn dieses Verfahren der Zuverlässigkeitsmodellierung schon etwas betagt ist, kann man beim Zuverlässigkeitsmodell nach Musa sehr schön Vorgehensweise und Nutzen von Zuverlässigkeitsmodellen erkennen.

Welchen Nutzen bietet dieser Ansatz?

Es gilt wiederum, aus Beobachtungen des Ausfallverhaltens in einer Beobachtungsphase bzw. während der Entwicklung auf das künftig zu erwartende Ausfallverhalten zu schließen. Musa liefert am Ende unter bestimmten Prämissen quantitative Aussagen hierfür und sogar eine Abschätzung für den Aufwand, der noch in den Test investiert werden muss, um ein bestimmtes Ausfall-/Reifegradziel zu erreichen. Dies ist schon allerhand für eine in der Praxis doch eher von Intuition geprägten Disziplin wie dem Softwaretest.

Doch beginnen wir mit den Prämissen. Die Annahme ist, dass ein Softwaresystem aufgrund von Fehlern zu (zumindest aus Anwendersicht) zufälligen Zeitpunkten t1, t2 usw. ausfällt. Um implementierungsunabhängiger zu werden, ist unter Zeit immer CPU-Zeit zu verstehen.

Prämissen für diesen Ansatz

Musa nimmt ferner an, dass die Anzahl der in einem Zeitintervall Δt beobachteten Ausfälle proportional zur Anzahl der zu dieser Zeit in der Software vorhandenen Fehler ist. Die bis zum Zeitpunkt t ≥ 0 beobachtete Anzahl von Ausfällen wird in μ(t) beschrieben und es gilt:

▶μ(t) steigt monoton mit μ(0) = 0.

▶Für die Anzahl der insgesamt erwarteten Ausfälle gilt μ(t → ∞) = a, mit a als Anzahl der im SUT beobachtbaren Fehler.

Die Anzahl der in Δt beobachteten Ausfälle ist proportional zu Δt und zur Zahl der noch nicht entdeckten Fehler – dies in Formeln ausgedrückt bedeutet mit a und b als Geradenparameter (Proportionalität):

Für Δt → 0 ergibt sich

Mit μ(0) = 0 und μ(t → ∞) = a findet man als Lösung der DGL

Wie viele Fehler sind noch zu beheben,

bis ein Zielreifegrad erreicht wird?

Weitere Umformungen, die ich uns hier ersparen möchte, liefern zwei Ergebnisse: Falls λ die aktuelle Ausfallrate der Software ist sowie λ0 diejenige zum Zeitpunkt 0 (zu Beginn von Test und Fehlerbeseitigung) und für die Ausfallrate ein Ziel λZ definiert ist, müssen bis zur Erreichung dieses Ziels noch Δμ zusätzliche Ausfälle beobachtet und deren Ursachen behoben worden sein (ohne Herleitung):

Für die zusätzliche Zeit Δt bis zur Erreichung dieses Ziels gibt Musa an (hier auch ohne Herleitung):

… und wie lange dauert dies?

Dies sind recht interessante Ergebnisse. Man kann auf diese Weise etwas konkretere Vorstellungen dafür erhalten, wie weit man im Absicherungsprozess bislang vorangekommen ist und wie lange es noch dauern könnte, um ein definiertes Reifegradziel λZ zu erreichen.

Das vorgestellte Modell besitzt zwei Parameter, die für einen spezifischen Anwendungsfall vorliegen müssen:

▶a: Die Gesamtzahl der beobachteten Ausfälle für t → ∞

▶λ0: Die Ausfallrate zu Beginn. Für sie wird später noch eine Abschätzung angegeben.

Auch zur Bestimmung oder wenigstens guten Abschätzung dieser Parameter hat sich Musa Gedanken gemacht – auch hierzu gleich mehr.

Nachbesserung bei den Prämissen

Eine Verbesserung dieses Ansatzes adressiert den Umstand, dass nicht jeder Ausfall zu einer Fehlerkorrektur führt – dies war aber eine Grundprämisse von Musa. In der Realität werden manche Fehler toleriert aufgrund zu geringer Fehlerwirkung und bei einem Teil der Fehlerkorrekturen werden gar neue Fehler in das System eingebracht.

Beobachtbarkeit von Fehlern

Zudem ist eine Prämisse, dass die Anzahl der in einem System vorhandenen Fehler gleich der Anzahl der Ausfälle für t → ∞ ist, genauer betrachtet unhaltbar. Nicht jeder Fehler ist beobachtbar! Auch hier muss daher noch nachgebessert werden. Musa tut dies, indem er einen Faktor B einführt als Verhältnis der für t → ∞ gefundenen und korrigierten Fehler fk zur Anzahl aller beobachtbaren Fehler a: B = fk /a. Wird jeder beobachtete Fehler durch die Korrekturmaßnahme auch korrigiert, so ist B = 1. Allerdings führt nicht jede Korrektur zur Fehlerbeseitigung, manchmal werden sogar bei der Korrektur neue Fehler eingebracht. Es wird für B auf Basis empirischer Untersuchungen ein Wert von 0,955 angegeben.

5% der Fehlerkorrekturen sind erfolg-

los oder selbst fehlerbehaftet.

Dies bedeutet nichts anderes, als dass etwa 5 % aller Fehlerkorrekturen erfolglos sind oder durch die Korrektur neue Fehler eingebracht wurden. Geht man davon aus, dass für t → ∞ alle in einer Software vorhandenen Fehler Ftotal aufgrund von Ausfällen gefunden und korrigiert werden, so ist mit der Anzahl an Ausfällen Fein software-

a zu rechnen: a = Ftotal /B. Es bleibt noch der Parameter λ0, für den man nach Musa die Abschätzung abgeben kann

wobei für Ftotal die in Abb. 2-7 aufgeführten Abschätzungen gegeben werden:

Abb. 2-7: Abschätzung für Ftotal

Bestimmung von f

Der Performancefaktor f wird durch Musa angegeben durch das Verhältnis der Ausführungsgeschwindigkeit (in Objektcode-Anweisungen pro Zeiteinheit) zum Softwareumfang (in Objektcode-Instruktionsanzahl).

Bestimmung von K

Zuletzt benötigen wir noch Werte für den Parameter K, der folgende Faktoren erfasst:

▶Nicht jede (fehlerhafte) Anweisung wird bei jeder Programmausführung durchlaufen.

▶Nicht jede Ausführung einer fehlerhaften Anweisung führt zu einem Fehlverhalten, da das Auftreten mancher Fehler an bestimmte Datenwerte gebunden ist.

Hinsichtlich des Parameters K wurden einige empirische Untersuchungen angestellt, nach welchen K unabhängig vom Codeumfang mit einem durchschnittlichen Wert von 4,2 . 10–7 angegeben werden kann.

Bewertung

Dennoch muss man sich bei der Bewertung dieses Ansatzes vor Augen führen, dass einige Prämissen und Abschätzungen getroffen wurden. Für ein »besseres Bauchgefühl« sollte er jedoch allemal genügen.

2.3 Zusammenfassung

▶Der Reifegrad von Software kann nicht über eine Metrik gemessen werden, man muss sich anderweitig behelfen. Eine Möglichkeit ist der Einsatz von Zuverlässigkeitsmodellen.

▶Ein Zuverlässigkeitsmodell ermöglicht Aussagen über das in Zukunft zu erwartende Ausfallverhalten von Software auf Basis bislang beobachteter Ausfälle.

▶Mit Fehlerbaumanalysen kann das statistische Ausfallverhalten komplexer Systeme aus dem Verhalten ihrer Module modelliert werden. Dabei wird transparent, welche Auswirkungen einzelne Fehlerursachen/-ereignisse auf das Gesamtausfallverhalten haben.

▶Markov-Modelle ermöglichen die Beschreibung des statistischen Ausfallverhaltens reparierbarer Systeme sowie die Ableitung wichtiger Kenngrößen.

▶Hardware besitzt ein zeitabhängiges Ausfallverhalten (»Badewannenkurve«), Software folgt einer zeitunabhängigen, exponentialverteilten Ausfallfunktion. Unter dieser Annahme lassen sich wichtige Kenngrößen für Software ableiten.

▶Das Zuverlässigkeitsmodell von Musa ermöglicht unter bestimmten Prämissen quantitative Aussagen über noch zu erbringende Testaufwände, um einen bestimmten Reifegrad beim Ausfallverhalten zu erzielen.