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

2.2.2 Anforderungen an die Prüfung eingebetteter Software
„Software Engineering für eingebettete Systeme ist eine wichtige Disziplin, die
zwischen dem „klassischen“ Software Engineering und dem System Engineering
angesiedelt ist.“ (Liggesmeyer 2005a, S. 1). Es werden Techniken, Methoden und
Prozessen aus beiden genannten Disziplinen angepasst und ergänzt. Das heißt, die oben
genannten Prüftechniken sind auch für die Prüfung eingebetteter Software relevant. Bei
eingebetteter Software kommen jedoch noch einige Anforderungen hinzu, wie z.B.
nicht-funktionale Qualitätsanforderungen (z.B. safety) sowie bei sicherheitskritischen
Systemen Zulassungsprozesse (vgl. Liggesmeyer 2005a, S. 8). Der dynamische Test –
wie Pfadüberdeckungs- und Ausweisungsüberdeckungstest – und stochastische
Verfahren ermöglichen eine wichtige quantitative Aussage zur Zuverlässigkeit für
eingebettete Software. Es ist auch möglich, die kombinierte Verwendung von statischer
Analyse und formale Techniken zur Prüfung eingebetteter Software zu wählen, um so
deren jeweilige Schwächen zu vermeiden (vgl. Liggesmeyer 2005b, S. 213). Die
Quantifizierung der stochastischen Zuverlässigkeitsanalyse ermöglicht die Aufdeckung
von Restrisiken, die durch Software verursacht werden (vgl. Liggesmeyer 2005b, S.
221) (vgl. ausführlich Kap. 3). Zusammenfassend lässt sich sagen, dass gerade bei der
Prüfung eingebetteter Software Risiken, die von Restfehlern ausgehen, quantifiziert
werden sollten, das heißt, Software Reliability Modelle zusätzlich zu dynamischen
Tests eingesetzt werden sollten: „Die Quantifizierung der Zuverlässigkeit eingebetteter
Software ist wichtig im Rahmen der Ermittlung der durch die Software verursachten
Restrisiken.“ (Liggesmeyer 2005b, S. 221).
2.2.3 Testen innerhalb des Softwareentwicklungsprozesses
Je nach Phase des Lebenszyklus von Software kann man verschiedene Arten von Tests
unterscheiden. Spillner und Linz (2005, S. 40) beschreiben das Testen am V-Modell
nach Boehm (zur Weiterentwicklung und grafischen Darstellung hin zum W-Modell
vgl. Spillner et al. 2006). In diesem Modell wird das Testen als gleichwertig zu
Entwicklung und Programmierung dargestellt, daher hat das Testen einen eigenen
gleichberechtigten „Ast“. Im Gegensatz zum Wasserfall-Modell, bei dem
Entwicklungsschritten Tests nur zugeordnet werden, scheint das V-Modell für das
Testen noch vielversprechender. Das „V“ weist darüber hinaus auf Verifikation und
Validation hin (vgl. Spillner; Linz 2005, S. 41). Verifikation überprüft ob die
8