Anbieter zum Thema
Auf all diese Fragen gibt es natürlich keine generelle Aussage. Es gibt jedoch Erfahrungswerte und entsprechende Methoden und Techniken. Im Folgenden soll der Zusammenhang zwischen Safety, Softwarefehlern und Qualitätssicherungsaktivitäten wie dem Testen näher erläutert werden.
Fehler ist nicht gleich Fehler
Grundsätzlich können Fehler in der Software zwar mit bewährten Qualitätssicherungsmethoden identifiziert und behoben werden, dennoch bietet die zusätzliche Durchführung von Safety-Analysen auf Softwareebene einen erheblichen Mehrwert. Warum ist dies der Fall?
Um diese Frage zu klären, wollen wir den umgangssprachlichen Begriff des „Softwarefehlers“ etwas näher beleuchten. Als „Softwarefehler“ wird im allgemeinen Sprachgebrauch meist ein Ausführungsfehler, also ein wahrnehmbares Fehlverhalten des Systems, bezeichnet. Dieses Fehlverhalten gilt es zu vermeiden, weshalb uns bei dessen Analyse, Identifikation und Behebung insbesondere die Ursachen des Fehlverhaltens interessieren.

Ein Fehler in der Software, also ein Softwarefehler, ist hierbei nur eine mögliche Ursache für dieses Fehlverhalten, wie im Folgenden beschrieben und in Abbildung 1 gezeigt wird. Zuerst möchten wir hierzu den Begriff des externen Fehlverhaltens erläutern, bevor wir zeigen, dass man zwischen mehreren Arten von Softwarefehlern unterscheiden muss.
Was ist externes Fehlerverhalten?
Von externem Fehlverhalten sprechen wir immer dann, wenn die Fehlerursache nicht in unserem betrachteten Softwaresystem liegt, sondern aus anderen Softwaresystemen oder aus der Hardware stammt. Sollte ein solches externes Fehlerverhalten vorliegen, sind Ausführungsfehler unvermeidlich. Auch wenn die eigentliche Ursache nicht in „unserer“ Software liegt, ist es wichtig zu wissen, welche Auswirkungen das Fehlverhalten auf unser System hat, denn nur so können geeignete Gegenmaßnahmen bereits beim Systementwurf gewählt werden.
Grundvoraussetzung hierfür ist ein tiefes Verständnis für die Ursache-Wirkung-Zusammenhänge im System. Dabei helfen uns effiziente Software-Safety-Analysen, denn bei komplexen und unübersichtlichen Systemen ist es äußerst schwierig, ausreichende Maßnahmen zur Fehlerbeherrschung zu identifizieren.
Die Krux mit den Spezifikationsfehlern
Betrachtet man extern verursachtes Fehlverhalten nicht und konzentriert sich stattdessen nur auf seine eigene Software, sollte man sich im Klaren darüber sein, dass es auch hier mehrere Arten von Fehlerursachen gibt. Zum einen gibt es die Fehler, die zur Klasse der Implementierungsfehler zählen. Diese Fehler zeichnen sich dadurch aus, dass das Verhalten der Software von der Spezifikation abweicht. Eine nicht initialisierte Variable zum Beispiel mag zwar komplexe Fehlereffekte haben, ist aber leicht zu korrigieren.
Viel schwieriger ist es bei der Klasse der Spezifikationsfehler. Wenn die Anforderungen bzw. die Spezifikation an ein System fehlerhaft ist, sind die Fehlereffekte in der Regel nicht ohne weiteres absehbar. Beim Implementierungsfehler genügt eigentlich schon das klassische Testen; um Spezifikationsfehler zu finden, benötigen wir unbedingt eine Sicherheitsanalyse.
Wird beispielsweise die Fahrzeuggeschwindigkeit auf Basis der Raddrehzahl berechnet, so ist das zugrundeliegende Berechnungsmodell ungültig, sobald die Räder Schlupf haben. Auch wenn der Algorithmus korrekt implementiert wurde, ergibt sich in vielen Fahrsituationen ein konzeptbedingter Fehler.
Artikelfiles und Artikellinks
(ID:24136900)