1996-1997-1998-1999-2000-2001-2002
Re: V-Modell und "safety" (466)
Beckmann, M.
Thursday, 27. April 2000 11:23
Mail 0465

Mail 0466

Mail 0467

Mail 0468

Mail 0469
From: Uta.Birk@t-online.de (Markus Beckmann)
On Tue, 25 Apr 2000 17:18:23 +0200, you wrote:
>From: Adam Moik
>Organization: www.ddf3d.de
>
>Hallo,
>
>ich suche nach Informationen zum Einsatz des V-Modells bei der
>Entwicklung von Systemen/Software mit Sicherheitsverantwortung
>(safety nicht security). Gibt es ausser "spezieller" Normen (wie z.B.
>der IEC 61508) direkt entsprechende "Erweiterungen" für das V-Modell?
Gleichfalls Hallo!
Derartige spezielle Erweiterungen sind mit nicht bekannt,
aber... ein paar Gedanken zum Thema Sicherheit und V-Modell:
In meinen Augen ist das Thema Sicherheit - insbesondere im
Hinblick auf "safety" - ein wenig im V-Modell versteckt,
denn (fast) überall ist die Rede von "IT-Sicherheit". Das
weckt aber wohl eher Assoziationen mit "security" (s.u.)!
In diesem Zusammenhang muss man aber bedenken, dass es im
Abschnitt "1.6 Erfüllung von Sicherheitskriterien" des Re-
gelungsteils heisst:
"Unter 'IT-Sicherheit' wird im folgende sowohl Sicherheit
im Sinne von Security ('klassische' IT-Sicherheit) als
auch im Sinne von Safety (Verfahrens- oder Betriebssicher-
heit) verstanden."
Das erscheint zwar auf den ersten Blick etwas gewagt, wird
aber verständlicher, wenn man sich den "Systembegriff im
V-Modell" (das ist eben so benannter Abschnitt 1.3 des Re-
gelungsteils) vor Augen führt. Dort heisst es:
"Für das V-Modell werden nur die Systeme betrachtet, deren
Aufgabenerfüllung vorwiegend durch den Einsatz von IT rea-
lisiert wird. Dazu zählen neben den IT-Systemen auch IT-An-
teile in anderen Systemen."
Und noch einen zweiten Aspekt sollte man vor dem Hintergrund
dieses Systembegrifft bedenken: Wenn sich die Betrachtung
auf IT-(Anteil von)Systeme(n) konzentriert, dann sind Sicher-
heitsgesichtspunkte - im Sinne der Verfahrens- oder Betriebs-
sicherheit, also Safety, - nur _ein_ Aspekt der Anwenderfor-
derungen. So wie der Anwender fordert, dass das System die
definierte Funktionalität besitzt, fordert er nicht mehr
oder weniger nachdrücklich auch, dass das System die defi-
nierten Sicherheitsanforderungen erfüllt.
In sofern kann man erst einmal sagen, dass Safty-Anforde-
rungen einige Anforderungen unter vielen sein können. Da-
her besteht erst einmal keine Notwendigkeit, solche Dinge
in besonderem Masse in einem Standard zu verankern. Die
Gewichtung derartiger Anforderungen kann ja zum Beispiel
über eine Festlegung von Qualitätszielen erfolgen...
Auf der anderen Seite ist für Kunden, die Safety als Pro-
dukt - oder einen Tel davon - verkaufen, schon wichtig, zu
erkennen, wie sich dieses Thema durch die Prozess- und
Projekt-Durchführung zieht. Dies kann durch die Ergänzung
von Safety-bezogenen Prozessen in einem massgeschneiderten
V-Modell geschehen, oder durch die Festschreibung im
Projekthandbuch, wenn man das auf der Ebene einzelner Pro-
jekte regeln möchte.
Gruss,
Markus Beckmann
>Gruss
>A. Moik
Sicherheit und Kritikalität / Safety and Criticality
 |
 |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
 |
|