Safety + Security
Sichere Software dank ISO 26262
Fortsetzung des Artikels von Teil 4
Rückverfolgung aller Anforderungen
Bis hierhin wurden in diesem Prozess nur die Sicherheitsanforderungen des Systems berücksichtigt, da sie die einzigen Anforderungen sind, mit denen sich die ISO 26262 beschäftigt. Man kann leicht die Tatsache aus den Augen verlieren, dass funktionale Sicherheit nicht das Hauptziel der Entwicklungsaufgabe darstellt, wenn man bedenkt, dass im Allgemeinen ein Fahrzeug am sichersten ist, wenn es irgendwo geparkt steht. Folglich ist die Rückverfolgung von Anforderungen nicht nur ein Grundstein der Norm, sondern auch ein Schlüsselfaktor in der Erstellung eines Produktes, das zeitgemäß und zweckdienlich ist.
Trotz der guten Vorsätze fallen viele Projekte einem Muster zusammenhangloser Software-Entwicklung zum Opfer, bei der Anforderungen, Design, Implementierung und Prüfartefakte aus isolierten Entwicklungsphasen produziert werden. Solche Isolierung führt zu heiklen Verbindungen zwischen diesem Stadium und/oder dem Entwicklungs-Team und der allgemeinen Anforderungsnachvollziehbarkeitsmatrix (Reliability Traceability Matrix; RTM). Leider können diese Situationen genauso leicht bei Projekten unter Einsatz von Anforderungs-Management-Werkzeugen auf dem neuesten Stand der Technik, Entwurfswerkzeugen, integrierter Entwicklungsumgebung und Testwerkzeugen auftreten. Normalerweise tritt dies ein, weil viele Anforderungs-Management-Werkzeuge zentralisierte, datenbankartige Architekturen und Applikationsmodelle benutzen. Solche Implementierungen bieten eine reiche Funktionsvielfalt, um gute Qualität und gutes Management in der Anforderungsdomäne anzuregen, aber wenig, um nachfolgende Bemühungen zu unterstützen, mit denen Projekte entwickelt, implementiert und getestet werden.
Die klassische Ansicht der Software-Entwicklung zeigt jede Phase in die nächste übergehend, eventuell mit Feedback von früheren Phasen, und eine Umgebungsstruktur von Konfigurations-Management und -Prozess (z.B. Agile, RUP). Es wird vorausgesetzt, dass Rückverfolgbarkeit ein Teil der Beziehung der einzelnen Phasen zueinander ist, allerdings wird der Mechanismus, mit dem die Verknüpfungen protokolliert werden, selten angegeben. Tatsache ist, dass, während jede einzelne Phase effizient durchgeführt wird, aufgrund der Investition in modernste Tooltechnologie, es unwahrscheinlich ist, dass diese Werkzeuge eine direkte Wirkung auf die RTM haben. Demzufolge wird die RTM im Laufe des Projekts immer schlechter gepflegt und schließlich meistens ganz am Ende in aller Eile abgewickelt. Das Nettoergebnis fehlt oder besteht aus einer oberflächlichen Bezugsprüfung zwischen Anforderungen und Implementierung und den daraus folgenden Unzulänglichkeiten im resultierenden System.
In Wahrheit befindet sich die RTM im Herzen eines jeden Projekts (Bild 3). Ob die Verknüpfungen physisch aufgezeichnet und bewältigt werden oder nicht, sie sind trotzdem vorhanden – z.B. wenn ein Entwickler eine Verknüpfung ganz einfach durch das Lesen einer Design-Spezifikation, die er dann zum Einführen der Implementierung benutzt, erstellt.
Jobangebote+ passend zum Thema
Diese alternative Ansicht der Entwicklungslandschaft stellt die Wichtigkeit dar, die der RTM zugewiesen werden sollte. Aufgrund dieser fundamentalen Zentralität ist es unerlässlich, dass Projekt-Manager der Investition in Werkzeugbestückung für den RTM-Aufbau die gleiche Priorität zusprechen, wie dem Einkauf von Werkzeugen für Anforderungs-Management, Versionskontrolle, Änderungs-Management, Modellierung und Test. Ebenso muss die RTM ausdrücklich in jedem Lebenszyklusmodell vorhanden sein, um ihre Wichtigkeit zu betonen (Bild 4). Dermaßen hervorgehoben dargestellt wird die RTM effizient und präzise als wesentlicher Teil des Entwicklungsprozesses konstruiert und gepflegt.
Für Projekte wie Flugleitungssysteme oder Systeme zur Fernlenkung von Flugkörpern ist die Anlehnung an ein Modell, in dem die RTM sichtbar im Mittelpunkt steht, eine Selbstverständlichkeit. Die ISO 26262 stellt ähnliche Anforderungen an das Automobilentwicklungs-Team, besonders mit Hinsicht auf die Sicherheitsanforderungen, und in der Folge ist ein ähnliches Modell angebracht.
- Sichere Software dank ISO 26262
- Eine enge Verwandtschaft
- Software-Sicherheit im Automobil
- Wer bezahlt, bestimmt
- Rückverfolgung aller Anforderungen
- Die Argumente für „praxiserprobt“ und „mehr Vertrauen durch Erprobung“
- Der Werkzeug-Qualifizierungsprozess
- Der Autor:
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Funktionale Sicherheit
TÜV Süd bewertet LDRA-Tools
Funktionale Sicherheit
TÜV SÜD Automotive und Timing-Architects vereinbaren Zusammenarbeit
Fahrzeugsicherheit
Euro-NCAP benennt sicherste Fahrzeuge von 2012
Safety & Security
Kombinierte Sicherheit
Toshiba Electronics Europe
Sicherheitsmodul für Schutz gegen Software-Code-Manipulation und IP-Diebstahl
Software-Entwicklung leicht gemacht
Statische Analyse-Tools tragen zur Erfüllung der ISO 26262 bei
Vergleichbarkeit der Sicherheitsstandards…
Mehr Sicherheit im Auto durch Flugzeugtechnologie
