V stands for Victory - Das V-Modell
Wenn komplexe Dinge entwickelt werden müssen, kann nicht einfach darauf los konstruiert oder programmiert werden und am Ende darauf gehofft werden, dass das Richtige herauskommt.
Welche Anleitung kann man hier heranziehen?
Das sogenannte V-Modell bietet hier eine Anleitung. Ursprünglich wurde es für die Softwareentwicklung konzipiert. Grundsätzlich ist es eine Vorgehensweise im Lebenszyklus eines (Sicherheits-) Produkts. Ziel des Einsatzes des V-Modells ist die Vermeidung von systematischen Fehlern.
Grundlegend findet es seinen Einsatz bei der Entwicklung des Produkts (Entwicklungslebenszyklus). Weiters ist es bei Modifikationen wie Änderungen oder Erweiterungen des Produkts anwendbar.
Das V-Modell ist u. A. in der bekannten EN ISO 13849-1 zu finden.
Das V-Modell besteht aus konstruktiven (linke Seite, absteigend) und überprüfenden (rechte Seite, aufsteigend) Aktivitäten, auch Phasen genannt. Das Ergebnis jeder konstruktiven Phase muss gegenüber den Vorgaben der Vorgängerphase verifiziert werden. Jeder konstruktiven Phase steht eine überprüfende Phase gegenüber. Der chronologische Fortschritt eines Projektes ist von links nach rechts erkennbar.
Gegenüber dem Wasserfallmodell (lineares, nicht iteratives Vorgehensmodell) werden bereits während der konstruktiven Phasen (Schreiben der Spezifikation, Entwurf der Architektur) die zugehörigen Tests spezifiziert.
Diese Darstellung mit den beiden Ästen und der gemeinsamen Spitze der Implementierung (Kodierung) ähnelt dem Buchstaben „V“ und ist somit namensgebend.
Die beiden Wörter „Verifikation“ und „Validierung“, die ebenfalls mit „V“ beginnen, sind zwar nicht namensgebend, aber sehr wichtig und sollten nicht verwechselt werden. Für diese beiden Begriffe gibt es eine (von vielen, „trockene“) Definition in der DIN EN 61508-4, Kap. 3.8.1 bzw. 3.8.2. Folgende Hilfestellung, die eventuell leichter zu merken ist:
- Verifikation:
Folgende Fragen sollten beantwortet werden:- Wurden die Anforderungen der Phase erfüllt?
- Wie wurde etwas gemacht? -> Wurde es richtig/gut/sauber gemacht?
- Validierung:
Folgende Fragen sollten beantwortet werden:- Wurden die Anforderung der Verwendung erfüllt?
- Was wurde gemacht/erstellt? -> Wurde das Richtige gemacht/erstellt?
- Verifikation + Validierung = Das Richtige richtig machen!
- Kann man das Richtige falsch machen?
Ja: Man kann z.B. eine Software erstellen, die das tut, was sie tun soll (das Richtige), aber sie wurde sehr unübersichtlich kodiert und nicht dokumentiert. - Kann man das Falsche richtig machen?
Ja: Man kann z.B. eine Software übersichtlich kodieren und gut dokumentieren (es richtig machen), aber sie tut am Ende nicht das, was am Anfang gewünscht war.
- Kann man das Richtige falsch machen?
In den verschiedenen Darstellungen in der Literatur werden die Anzahl der Phasen und auch deren Bezeichnungen unterschiedlich dargestellt. Die Gegenüberstellung von einer Entwicklungs- zu einer Testphase ist jedoch immer gleich. Folgend einige Beispiele aus verschiedenen Quellen:
Gerhard Moser, MSc, CMSE®
Functional Safety Professional Railway (TÜV SÜD Rail)
System Integration | Application Engineer Pilz Österreich