 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
Fehleranalyse anhand von Zustands- und Datenflussdiagrammen |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
| Diagramme wie z.B. Zustands- oder Datenflussdiagramme besitzen eine geringe Abstraktion und sind zu lokal. Deswegen sind sie oftmals weniger geeignet für eine Analyse des Gesamtsystems. In den einzelnen Pfaden der potentiellen Systemzuständen fällt es oftmals schwer sich manuell zurechtzufinden z.B. wenn man aus einer Zustandsmaschine analysieren will, wie und ob das System irrtümlicherweise von einem Zustand in einen anderen springen könnte, bekommnt man eine Enorme Anzahl von Möglichkeiten und ihre Analyse bringt wenig denn es ist auf eine sehr lokale (und damit begrenzte) Ebene.
Es ist zu empfehlen mit einer weniger detaillierten und lokalen Beschreibung anzufangen. Dafür wird eine abstraktere Sicht des Softwareverhaltens benötigt wie in Abbildungen 6.3 und 6.4. Weiterhin ist es wichtig nachvollziehen zu können, wie ein Fehler im System sich weiter verbreiten könnte. Siehe Abbildung 4: 
Abbildung 4: Fehlerfortpflanzung im Moduldatenfluss Bei einer Software-Gefahrenanalyse sollen folgende Risikofaktoren berücksichtigt werden: Umgebungs- und Nutzungsbedingungen Die spezifischen Umgebungs- und Nutzungsbedingungen, unter der eine Software ausgeführt wird, können die Ausführung der Software in einer unvorhergesehen Art und Weise verändern. Aus diesem Sachverhalt resultierende Gefahren sollten berücksichtigt werden. Steuerungsreihenfolge in Echtzeit In asynchronen Systemen kann die Ausführungsreihenfolge der Komponenten sehr schwer vorhergesagt werden. Eine Gefahrenanalyse sollte daher unabhängig von der Ausführungsreihenfolge durchgeführt werden. Funktionsaufrufe des Systems Um eine umfassende Gefahrenanalyse der Software zu gewährleisten, müssen auch Funktionen des Betriebssystems mit in die Analyse einbezogen werden oder durch eigene Funktionen ersetzt werden. Systemressourcen Die genaue Nutzung der Systemressourcen (Festplatten, Speicher, I/O Kanäle usw.) ist in einem Softwaresystem nicht immer leicht vorherzusagen. Zugriffsfehler auf benötigte Ressourcen können ein Fehlverhalten in völlig unerwarteter Art und Weise hervorrufen, obwohl die Funktionen sogar scheinbar 'unabhängig' voneinander sind. Eine Gefahrenanalyse der Software sollte daher untersuchen, wo ein fehlerhafter Zugriff auf Ressourcen gefährliche Konsequenzen haben kann. Timing In vielen Systemen kann die benötigte Zeitdauer für auszuführende Befehle und Berechnungen sehr wichtig für die sichere Nutzung eines Systems sein. Als besonders kritisch kann sich die maximale Ausführungszeit erweisen. Eine Gefahrenanalyse sollte Aktivitäten mit einem kritischen Zeitverhalten sichtbar machen. Auf solche Zeitkritische Erreichnisse sollte beim Systemtest besonders acht gegeben werden. Nachdem die Risikofaktoren (z.B. in einen Fault Modes and Effect Analysis Tabelle) und die Gefahrenstellen in den Software (z.B. aus dem Interaktionsdiagram) erfasst wurden, kann man mit einer Fehlerbaumanalyse weiter vorgehen. (siehe Abbildung 5) Die Fehlerbaumanalyse braucht nicht jede Codezeile zu berücksichtigen, man muss jedoch bestimmen, welche Variablen/Objekte wo verwendet werden, oder zumindes wie das gesamte System von deisen Variablen abhängt. Das Datenfluss Diagramm (Abbildung 4) kann ein gute Ausgangsposition für diese Analyse sein. 
Abbildung 5: FTA für ein Software Modul Um die Hazard Analyse Techniken auf Software anwenden zu können schlagen wir folgen Schritte vor:
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Fehleranalyse anhand... | ||||
| ||||
| ||||
| ||||
| ||||
| Ansprechpartner | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
