-
Gebiet der
Erfindung
-
Die
Erfindung betrifft allgemein das Gebiet der Risikoverwaltung (Risk
Management) und speziell ein Verfahren und ein System zum Verwalten
von Risiken bei der Entwicklung von Einrichtungen mittels eines
Verwaltungsprozesses (Management Prozess).
-
Hintergrund
der Erfindung
-
Risk
Management betrifft einen Prozess zum Bestimmen, ob ein potenzielles
Risiko für
eine Einheit, beispielsweise eine Vorrichtung oder einen Prozess,
existiert, und wenn dies der Fall ist, ob eine korrigierende oder
mildernde Handlung, die das Risiko vermindert, notwendig ist. Ein
Risiko ist eine Gefahrenquelle oder eine potenzielle Quelle eines
Schadens, wobei der Schaden definiert als eine „körperliche Verletzung oder Schaden
an der Gesundheit von Leuten, am Eigentum oder an der Einrichtung". Ein Risiko hat
einen absoluten Schwerewert und eine absolute Wahrscheinlichkeit
für das
Auftreten. Die Kombination aus Schwere und Wahrscheinlichkeit des Auftretens
bildet das Risiko. Der Risikomanager (Risk Manager) entscheidet,
ob die Gefahr, die von dem Risiko ausgeht, akzeptabel oder unakzeptabel ist.
Wenn das Risiko unakzeptabel ist, nimmt der Risk Manager Handlungen
vor, um die Wirkung des Risikos zu reduzieren (herabzusetzen), indem
die Schwere reduziert wird, indem die Wahrscheinlichkeit reduziert
wird, oder indem beides reduziert wird.
-
Ein
Risk Management-Prozess für
medizinische Vorrichtungen ist sowohl in den Vereinigten Staaten
als auch in anderen Ländern
einem Mandat unterstellt. Die Bundesbehörde zur Überwachung von Nahrungs- und
Arzneimitteln sowie die Europäische
Union fordern diese Bestrebung für
Hardware und Softwaresysteme, die als medizinische Vorrichtungen
bestimmt sind. Ein augenblicklicher Standard für diese Bestrebung ist in einem
Dokument niedergelegt, das von ISO (International Organization for Standardization)
veröffentlicht
wurde unter „ISO 14971:2000,
Medical Devices – – The Application
of Risk Management to Medical Devices". Andere Standards existieren ebenfalls.
-
Bei
der Durchführung
von Risk Management unter Verwendung existierender Systeme, speichern Analysten
typischerweise die Ergebnisse und Querverweise mittels Papierdokumentation.
-
Die
Analysten benötigen
Zugriff auf die Dokumentation, um die relevante Information zu besitzen.
Die Papierdokumentation kann jedoch nicht die jüngsten Anforderungen, Risiken,
Herabsetzungen, Testpläne
und Testergebnisse enthalten. Die Einsichtnahme in die Papierdokumentation
und die Speicherung einer derartigen Dokumentation ist zeitaufwendig
und kann beim Referieren Fehler erzeugen. Existierende Systeme sind
händisch
aufwendig und erfordern zusätzliche
Ressourcen, die dem Verwalten der Papierdokumente gewidmet sind.
Ein System, das gemäß den Prinzipen
der vorliegenden Erfindung aufgebaut ist, adressiert diese Nachteile und
die entsprechenden Probleme.
-
Kurze Zusammenfassung
der Erfindung
-
Gemäß der Prinzipien
der Erfindung enthält ein
System zum Verwalten von Risiko eine Benutzerschnittstelle, die
eine Auswahl einer bestimmten betroffenen Einrichtung aus einer
Mehrzahl von vorbestimmten Typen von betroffenen Einrichtungen ermöglicht,
in Antwort auf einen Benutzerbefehl. Ein Speicher enthält Information,
die die ausgewählte
betroffene Einrichtung mit einem bestimmten Risiko, das möglicherweise
die ausgewählte
betroffene Einrichtung nachteilig beeinträchtigt, in Zusammenhang bringt.
Die Information in dem Speicher verknüpft die bestimmte Gefahr mit:
einer Härte
(Schwere) des bestimmten Risikos; einer Ursache des bestimmten Risikos;
und eine Wahrscheinlichkeit des Auftretens der Ursache. Ein Risikoprozessor
verwendet Information aus dem Speicher, um eine Risikoanzeige des
bestimmten Risikos für
die betroffene Einrichtung zu schaffen.
-
Kurzbeschreibung der Figuren
-
In
den Figuren zeigen:
-
1 ein
Blockdiagramm der vorliegenden Erfindung;
-
2 ein
Flussdiagramm, das die Beziehung zwischen Anforderungenmanagement
(Requirement Management) und Risk Management, wie durch die vorliegende
Erfindung verwendet, zeigt;
-
3 ein
Flussdiagramm, das die Funktion des Risk Management während der
Produktimplementierung und des Testens, wie durch die vorliegende
Erfindung implementiert, zeigt;
-
4 ein
Flussdiagramm, das die Verarbeitung von Anfragen eines Interessenvertreters
(Stakeholders) durch Migrations- (Herabsetzungs-) und Konvergenzanwendung
zeigt, wie in 3 verdeutlicht;
-
5 ein
Flussdiagramm, das ein erstes Ausführungsbeispiel der Analyse
der Wahrscheinlichkeit und der Schwere eines Risikos zeigt, bei Durchführung durch
den Risikoprozessor gemäß 1;
-
6 ein
Flussdiagramm, das ein zweites Ausführungsbeispiel der Risikowahrscheinlichkeit und
Schwereanalyse, die durch den Risikoprozessor gemäß 1 durchgeführt werden,
zeigt;
-
7 eine
erste grafische Benutzerschnittstelle GUI (Graphical User Interface),
die durch die vorliegende Erfindung implementiert wird;
-
8 eine
zweite grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
9 eine
dritte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
10 eine
vierte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
11 eine
fünfte
grafische Benutzerschnittschnelle, die durch die vorliegende Erfindung
implementiert wird;
-
12 eine
sechste grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
13 eine
siebente grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
14 eine
achte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
15 eine
neunte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
16 eine
zehnte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird;
-
17 eine
elfte grafische Benutzerschnittstelle, die durch die vorliegende
Erfindung implementiert wird; und
-
18 ein Blockdiagramm eines Computersystems,
auf welchem das Risk Management System gemäß der vorliegenden Erfindung
implementiert werden kann.
-
Detaillierte Beschreibung
der Erfindung
-
Gemäß der Erfindung
arbeitet ein Prozessor unter der Steuerung einer ausführbaren
Anwendung, um (a) Information von einer Eingabeinformationsvorrichtung
zu empfangen, (b) die Information durch Manipulieren, Analysieren,
Modifizieren, Konvertieren und/oder Übertragen der Information zu
verarbeiten, und/oder (c) die Information an eine Ausgabeinformationsvorrichtung
weiterzuleiten. Ein Prozessor kann die Fähigkeiten von beispielsweise
einer Steuerung oder von einem Mikroprozessor verwenden oder enthalten.
Der Prozessor kann mit einem Anzeigenprozessor oder Generator arbeiten.
Ein Anzeigenprozessor oder Generator ist ein bekanntes Element zum
Erzeugen von Signalen, die Anzeigebilder oder Bereiche davon darstellen.
Ein Prozessor und ein Anzeigenprozessor enthalten irgendeine Kombination
aus Hardware, Firmware und/oder Software.
-
Eine
ausführbare
Anwendung gemäß der Erfindung
enthält
Code oder maschinenlesbare Anweisungen zum Konditionieren des Prozessors,
um vorbestimmte Funktionen zu implementieren, beispielsweise diejenigen
eines Betriebssystems, Risk Management Systems, Gesundheitsweseninformationssystems
oder eines anderen Informationsverarbeitungssystems, beispielsweise
in Antwort auf einen Benutzerbefehl oder eine Eingabe. Eine ausführbare Prozedur
ist ein Codesegment oder eine maschinenlesbare Anweisung, Sub-Routine
oder ein anderer eindeutiger Codeabschnitt oder Bereich einer ausführbaren
Anwendung zum Durchführen
eines oder mehrerer bestimmter Prozesse. Diese Prozesse können ein
Empfangen von Eingabedaten und/oder Parametern umfassen, ein Durchführen von
Operationen mit den empfangenen Eingabedaten und/oder Durchführen von
Funktionen in Antwort auf die empfangenen Eingabeparameter, und
Bereitstellen der resultierenden Ausgabedaten und/oder Parameter. Eine
Benutzerschnittstelle enthält
ein oder mehrere Anzeigenbilder, die durch den Anzeigenprozessor unter
der Steuerung des Prozessors erzeugt werden, was eine Benutzerinteraktion
mit einem Prozessor oder mit einer anderen Vorrichtung erlaubt.
-
Das
Risk Management System gemäß der Erfindung
ist in einem Blockdiagramm in 1 verdeutlicht.
Das Risk Management System 1 ist in ein Qualitätsmanagementsystem 22 integriert,
das ein Prozess ist, der in dem Produkt-, Projekt- und Marktentwicklungsprozess
von Nutzen ist. Das Risk Management System 1 enthält eine
Benutzerschnittstelle 6, die Information enthält, die
ein oder mehrere Anzeigenbilder darstellt, die es einem Benutzer 2 ermöglichen
mit einem betroffenen Einrichtungsprozessor 3 und einem
Risikoprozessor 5 zu interagieren. In Antwort auf einen
Befehl von dem Benutzer kann eine bestimmte betroffene Einrichtung
von einer Mehrzahl von derartigen Einrichtungen, die durch den betroffenen
Einrichtungsprozessor 3 verwaltet werden, ausgewählt werden.
Die betroffene ausgewählte
Einrichtung kann eine von einer Mehrzahl von Typen von Einrichtungen
sein, beispielsweise (a) ein Projekt, (b) ein Produkt, (c) ein Markt,
(d) ein Produktmerkmal (Produktfeature) oder (e) ein Satz von Produktmerkmalen.
Im Zusammenhang mit einer Gesundheitspflege kann ein Typ einer betroffenen
Einrichtung beispielsweise eine Patientenumgebung sein. Andere spezifische
Beispiele eines Typs einer betroffenen Vorrichtung in Zusammenhang
mit Verkehrstechnik ist beispielsweise ein Autobahntunnel.
-
Sobald
eine betroffene Einrichtung durch den Benutzer 2 ausgewählt worden
ist, wird die Information, die die Identität der ausgewählten betroffenen
Einrichtung darstellt, an einen Risikoassoziationsspeicher 4 weitergeleitet.
Der Risikoassoziationsspeicher 4 enthält Information, die betroffene
Einrichtungen mit bestimmten Risiken in Zusammenhang bringt, die
möglicherweise
die Einrichtung nachteilig betreffen können. Der Risikoassoziationsspeicher 4 verknüpft ein
bestimmtes Risiko mit verschiedenen Eigenschaften des Risikos, beispielsweise
mit der Schwere des Risikos, der Ursache oder den Ursachen des Risikos
und der Wahrscheinlichkeit des Auftretens mindestens einer der möglichen
Ursachen. Im Falle eines Autobahntunnels ist beispielsweise ein
bestimmtes Risiko die Gefahr einer Explosion, die in dem Tunnel
auftritt, was sehr schwerwiegend sein kann. Eine derartige Explosion
kann beispielsweise durch den Transport von explosiven Materialien
durch den Tunnel in einem Fahrzeug verursacht werden. Die Wahrscheinlichkeit,
dass ein derartiges Fahrzeug sich als Teil des täglichen oder wöchentlichen
Verkehrsflusses dem Tunnel nähert, kann
berechnet werden.
-
Es
ist auch möglich,
dass eine Mehrzahl von Risiken existiert, die möglicherweise die ausgewählte betroffene
Einrichtung negativ beeinträchtigen
können.
Der Risikoassoziationsspeicher 4 kann auch die jeweiligen
individuellen Risiken der Mehrzahl von Risiken mit verschiedenen
Eigenschaften des Risikos verknüpfen,
beispielsweise mit der Schwere des Risikos, der Ursache oder den
Ursachen des Risikos und mit der Wahrscheinlichkeit des Auftretens
mindestens einer der möglichen
Ursachen, wie oben beschrieben.
-
Die
risikobezogene Information, die in Antwort auf die Identifikation
der betroffenen Einrichtung, die durch den Benutzer 2 ausgewählt worden
ist, von dem Risikoassoziationsspeicher 4 geholt wird,
wird an den Risikoprozessor 5 übermittelt. Der Risikoprozessor 5 liefert
in Antwort auf die Information von dem Risikoassoziationsspeicher 4 eine
Angabe des Risikos, dass ein bestimmtes Risiko für die ausgewählte betroffene
Einrichtung vorliegt. In dem Fall, dass eine Mehrzahl von Risiken
zu einer ausgewählten
betroffenen Einrichtung gehört,
ist der Risikoprozessor 5 in der Lage, Angaben des Risikos
der jeweiligen individuellen Risiken für die betroffene Einrichtung
bereitzustellen und die individuellen Risiken gemäß ihren
Risikoangaben zu klassifizieren (in eine Rangfolge zu bringen).
-
Der
Risikoprozessor 5 ist auch mit einem Detailanforderungsspeicher 7 gekoppelt,
der neben anderen Dingen Information enthält, die angibt, ob eine Herabsetzung
für das
bestimmte identifizierte Risiko notwendig ist. In dem Fall des zuvor
genannten Autobahntunnels kann ein Beispiel der Herabsetzung des Explosionsrisikos
innerhalb des Tunnels die Existenz von Maßnahmen enthalten, die den
Transport von explosiven Materialien in einem Tunnel verhindern. Ein
zusätzlicher
Schritt zum Herabsetzen in dem Fall kann das Anbringen von Schildern
am Tunneleingang sein, die den, wenn er sich dem Tunnel nähert, Fahrern
signalisieren, dass explosives Material nicht durch den Tunnel transportiert
werden darf. Der Risikoassoziationsspeicher 4 enthält ferner
Information, die ein bestimmtes Risiko mit einem oder mit mehreren
Tests verknüpft,
die verwendet werden können, um
zu verifizieren, dass das bestimmte Risiko herabgesetzt worden ist.
Der Detailanforderungsspeicher 7 enthält auch Information, die das
bestimmte Risiko mit der verbleibenden Schwere verknüpft, die
nach Herabsetzung des bestimmten Risikos verbleibt. Der Detailanforderungsspeicher 7 enthält ferner
Information, die das bestimmte Risiko mit einer Angabe verknüpft, dass
das bestimmte Risiko herabgesetzt worden ist, und ein Identifizieren
einer Person ermöglicht,
die für
die Herabsetzung verantwortlich ist.
-
Der
Risikoprozessor 5 kann aus der Information in dem Detailanforderungsspeicher 7 bestimmen,
ob ein bestimmtes Risiko eine Herabsetzung benötigt. Es kann auch Information
liefern, die einen Test betrifft, um zu bestimmen, ob das Risiko
herabgesetzt worden ist, um die Restschwere des Risikos nach der
Herabsetzung zu bestimmen, und um die Person, die verantwortlich
ist für
die Herabsetzung des Risikos zu bestimmen. Der Risikoprozessor 5 kann
Berichte 8 basierend auf dieser Information vorbereiten.
Die Berichte 8 werden an den Benutzer 2 geliefert,
um neben anderer Information den Status der betroffenen Einrichtungen,
die Gefahren und Risiken, die damit verbunden sind, irgendwelche
Herabsetzungen, die für
die betroffenen Einrichtungen durchgeführt wurden, und Restrisiko,
das nach der Herabsetzung verbleibt zu überwachen.
-
Das
System 1 enthält
auch einen Auditprozessor 132, der einen von dem Benutzer 2 gestarteten
Zugriff auf den Risikoassoziationsspeicher 4 und den Detailanforderungsspeicher 7 überwacht und Daten
aufzeichnet, die die bestimmte Information, auf die zugegriffen
wurde, angeben und den bestimmten Benutzer 2, der den Zugriff
gestartet hat, identifizieren. Der Auditprozessor 132 überwacht auch
Modifikationen der Information, die in den Speichern 4 und 7 gespeichert
ist, und zeichnet Daten auf, die die durchgeführten Modifikationen angeben und
die Quellenverarbeitungsvorrichtung identifizieren, die die Nachricht
erzeugt hat, die die Datenmodifikation verursacht oder anderweitig
gestartet hat. Der Risikoprozessor 5 holt Daten von dem
Auditprozessor 132 und erzeugt Berichte 8, die
eine Audit Trail Dokumentierung der vorangegangenen Vorgänge verkörpern. Die
Berichte 8 werden an den Benutzer 2 geliefert,
um den Zugriff auf die Speicher 4 und 7 und Modifikationen
der darin gespeicherten Information zu überwachen.
-
2 zeigt
ein Flussdiagramm, das verdeutlicht, dass das Anforderungsmanagement
und das Risk Management in einer Beziehung zueinander stehen und
zeigt die fortschreitenden Vorgänge,
die in bestimmten Produkt- und/oder Projektlebenszyklen auftreten.
In 2, wird zur Vereinfachung der Figur und der zugehörigen Beschreibung
im Folgenden Bezug genommen auf einen Produktlebenszyklus. Ein Fachmann
auf diesem Gebiet versteht, dass die gezeigten Schritte auch für Projektlebenszyklen
angewendet werden können.
In den in 2 gezeigten Schritten kann ein
Produktmanagementteam potenzielle Risiken basierend auf der Entwicklung
dieses Produkts aufdecken.
-
Der
Start des Produktlebenszyklus-Managementprozesses, der Block 9,
veranlasst die Initialisierung einer Produktportfolio-Managementfunktion
in Block 10. Der erste Schritt in Block 12 ist
für ein
Anforderungenmanagementteam, um Geschäftsmodelle basierend auf den
Bedürfnissen
und Anfragen eines Stakeholder (SRQ) zu erzeugen, unter Zugrundelegung
von vorgestellten Szenarien, um einen anfänglichen Business- und Finanzierungsplan
zu erzeugen. Wie oben beschrieben, kann sogar in dem ersten Schritt
in Block 12 das Anforderungenmanagementteam potenzielle
Risiken basierend auf den Stakeholder Anforderungen aufdecken. Basierend auf
den Stakeholder Anforderungen, die in Block 12 bestimmt
werden, werden die Stakeholder Anforderungen anfänglich in Block 13 identifiziert.
Diese können
jederzeit aktualisiert werden, während
die Produktportfolio-Managementfunktion 10 durchgeführt wird.
Sobald in Block 13 Stakeholder Anforderungen identifiziert
sind, können
in Block 14 Marketinganforderungen definiert werden, und
in einer Marketinganforderungenspezifikation niedergelegt werden,
die zusammen mit den Stakeholder Anforderungen verwendet wird, um
Produkt- und Produktkomponentenanforderungen in Block 15 zu
bilden. Systemanforderungen können
in Block 16 definiert werden, und in einer Systemanforderungenspezifikation
(SRS) niedergelegt werden, die Information enthalten kann, die von
einem Risiko-, Kompetenz- und/oder behördlichen Analysten erzeugt
werden. Die SRS, die in Block 16 erzeugt worden ist, dient
als Basis zum Definieren des Bereichs und zum Schätzen der
Kosten des Produkts in Block 18 zusammen mit dem Produkt-
und Produktkomponentenanforderungen aus Block 15. Die Information,
die den Bereich und die Kosten des Produktmanagementprozesses betrifft, erzeugt
in Block 18, kann verwendet werden, um den Finanzierungs-
und Geschäftsplan
in Block 17 zu verfeinern. Der verfeinerte Finanzierungs-
und Geschäftsplan,
wie in Block 17 erzeugt, wird dann in den Gesamtportfolio-Managementprozess 10 integriert. Die
Portfoliomanagementfunktion 10 ist in der Lage, direkt
mit dem Anforderungsteam zu interagieren, durch den Prozess des
Definierens des Bereichs und des Schätzens der Kosten des Produkts
in Block 18.
-
Sobald
die SRS in Block 16 bestimmt ist, und der Bereich und die
Kosten des Produkts in Block 18 definiert sind, wird in
Block 19 eine Analyse- und Ausführungsfunktion durchgeführt, um
die Produkt- und Produktkomponentenanforderungen zu untersuchen.
Die Analyse-Elaborations-Funktion
in Block 19 erlaubt dem Anforderungenteam zu bestimmen,
ob irgendwelche weiteren Risiken basierend auf der zusätzlichen
und aktualisierten Information offenkundig geworden sind. Basierend
auf den Ergebnissen der Analyse-Elaborations-Funktion in Block 19 wird
eine detailliertere SRS in Schritt 20 erzeugt, die detaillierte Analyseergebnisse,
Spezifikationen und Modelle enthält.
Der Abschluss der Funktionen in Block 19 und 20 erlaubt
dem Produkt in die Entwicklungsphase 21 einzutreten, zu
welchem Zeitpunkt ein Produktentwicklungsteam die zuvor identifizierten
Risiken adressiert, und Anforderungen zum Herabsetzen aus Sicht
der identifizierten Risiken erzeugt. Sobald die Entwicklungsphase
von Block 21 beendet ist, und das Entwicklungsteam das
Testen und Validieren beendet hat, um entsprechende Herabsetzungen
der identifizierten Risiken zu verifizieren, kann die Portfoliomanagementfunktion 10 bestätigen, dass
das Ende 11 der Produktlebenszyklus-Managementfunktion
erreicht worden ist.
-
2 zeigt
die Beziehung zwischen dem Anforderungsmanagement und den Risiko-Gefahren-Analysefunktionen. 3 zeigt
genauer, wie das Qualitätsmanagementsystem
(QMS) 22 gemäß der vorliegenden
Erfindung die Risiko-Gefahr-Managementschritte von der Produktvorkonzeption
durch die Produktendtestphase durchführt. Das QMS 22 enthält die Prozessschritte
zum Implementieren der Risiko-Gefahr-Prüfung und Analyse.
-
Die
Vorkonzeptphase der Produktentwicklung enthält verschiedene Subprozesse
oder Prozeduren. Ein Designsubprozess 27 ist die Konstruktion von
Geschäftsmodellen
basierend auf ver schiedenen Geschäftsszenarien. Das Geschäftsmodell
enthält
Stakeholder Anfragen (SRQs) und definiert eine gemeinsame Anforderungsarchitektur.
In der Vorkonzeptphase wird die Information, die während des
Geschäftsmodellkonstruktions-Subprozesses 27 erzeugt
worden ist, analysiert durch den Herabsetzungs- und Konvergenzsubprozess 26,
um zu verifizieren, dass ein Produkt korrekt definiert und analysiert
worden ist. Speziell analysiert in dem gezeigten Ausführungsbeispiel
der Herabsetzungs- und Konvergenzsubprozess 26, die Stakeholder
Anfragen, um zu bestimmen, ob diese Anfragen in das Produkt integriert
werden sollten.
-
Die
Information von dem Herabsetzungs- und Konvergenzsubprozess 26 wird
zurück
an den Geschäftsmodellkonstruktionssubprozess 27 geliefert,
um eine Verfeinerung des Geschäftsmodells durchzuführen, das
dann von einem Subprozess 28 analysiert wird, um zu verifizieren,
dass ein brauchbarer Geschäftsfall
erzeugt worden ist. Als Teil dieses Prozesses können potenzielle Risiken identifiziert werden.
Das Team, das die QMS 22 durchführen soll, kann zu diesem Zeitpunkt
Risiken identifizieren und Risikoeinträge erzeugen, die Daten enthalten,
die dieses Risiko repräsentieren.
Derartige Risikoeinträge
werden in dem Risikoassoziationsspeicher 4 gespeichert
(1). Statusinformation wird in die Risikoeinträge eingefügt, die
angibt, dass zusätzliche
Arbeit während
der nachfolgenden Konzeptphase erforderlich ist, wenn das Projekt
evtl. gestartet wird. Während
des Sammelns von Stakeholder Anfragen (SRQs), kann die QMS 22 verwendet
werden, um potenzielle Risiken aufzudecken und zu verfolgen. Die QMS 22 speichert
auch Daten in dem Risikoassoziationsspeicher 4, die die
Stakeholder Anfragen, die zu den Risikoeinträgen gehören, repräsentieren. Darüber hinaus
können
die Ursachen des Risikos offenkundig sein. Die QMS 22 kann
in dem Risikoassoziationsspeicher 4 auch Daten speichern,
die die Ursachen für
jeweilige Risiken repräsentieren,
wenn sie bekannt sind. Sobald die Konzeptphase gestartet ist, kann
eine zusätzliche
Analyse diese Anfangseinschätzungen
verfeinern.
-
Während einer
Konzeptphase 29 werden Merkmale des Zielprodukts oder Systems
spezifiziert. Wie zuvor können
Risikos auch in dieser Phase bestimmt werden. Die Unterstützung von
Gegenstandsexperten oder Analysten, wie beispielsweise Risikoexperten,
behördliche
Analysten, kann verwendet werden, um den Risikomanagementprozess durchzuführen, der
bestimmte Risiken und ihre Ursachen bestimmt. Daten, die die identifizierten
Risiken repräsentieren,
werden in dem Risikoassoziationsspeicher 4 (1)
gespeichert. Diese Information wird weitergeleitet an den Risikoprozessor
zur Analyse. Typische Analysetechniken, die verwendet werden, sind
eine Ausfallmodus- und Wirkungsanalyse (FMEA) oder eine Fehlerbaumanalyse
(FTA).
-
Der
Konzeptphase 29 folgt eine Elaborationsphase 30,
die bestimmt, ob zusätzliche
Risiken identifiziert sind. Die Dokumentation ist beendet für Ursachen
der identifizierten Risiken und entsprechenden Herabsetzungen, die
erforderlich sein können.
Das QMS 22 greift auf eine Risikomatrix zu, die für eine gegebene
Paarung von Risikoschwere und Wahrscheinlichkeit einen resultierenden
Wert der Risikotoleranz angibt. Während der Elaborationsphase 30 erfolgt
eine Bestimmung, ob die Herabsetzung für nicht tolerierbare Risiken
notwendig ist, oder alternativ, ob eine Änderung des vorgeschlagenen
Systems oder der Lösung
notwendig ist, um diese Risiken, bei denen eine Herabsetzung nicht
möglich
ist, zu reduzieren.
-
Am
Ende der Elaborationsphase 30 sind signifikante Risiken
und ihre Ursachen typischerweise identifiziert und herabgesetzt.
Es existiert ein nachverfolgbarer Datensatz, der seine Ursache hat
in herabgesetzten Ursachen von Schaden zu den Anforderungen oder
Vorgängen,
die die erforderliche Herabsetzung durchführen. Wenn eine Herabsetzung aufgetreten
ist, kann eine Bestimmung der Schwere und Wahrscheinlichkeit des
Restrisikos erfolgen.
-
Die
Elaborationsphase 30 wird gefolgt von einer Produktentwicklungsphase,
beginnend mit dem Subprozess 31, während dem ausführbare Prozeduren,
Komponenten oder andere Software und/oder Hardware designed werden.
Das Design und das Codieren mit dem Einheitenlevel erfolgt während des Subprozesses 32.
Während
der Schritte 31 und 32 adressiert das Entwicklungsteam
die zuvor identifizierten Herabsetzungsanforderungen und eine Verfeinerung
der identifizierten Herabsetzungsanforderungen kann während der
Subprozesse 31 und 32 entlang des iterativen Weges 45 erfolgen.
Die Herabsetzungen, die in den vorigen Subprozessen identifiziert
worden sind, können
designed und in ausführbare
Prozeduren, Komponenten und eine andere Software und/oder Hardware
implementiert werden, die in den Subprozessen 31 und 32 entwickelt
werden. Darüber
hinaus stellt die Analyse der Risiken weiterhin sicher, dass keine
zusätzlichen
Risiken während
des Designs und des Codierens erzeugt werden. Die Schritte 26 bis 32 definieren
Risikomanagementaktivitäten,
die zu einem Produkt gehören. Der
Entwicklungsphase folgt das Produkttesten. Die Einheitenlevel-Verifikationsdaten
werden an den Einheitentestlevel 33 über den Weg 34 geliefert.
Die entwickelten ausführbaren
Prozeduren, Komponenten und andere Software und/oder Hardware werden
getestet, um sicherzugehen, dass sie mit den Verifikationsdaten
in dem Einheitentestlevel 33 übereinstimmen. Die Komponentenverifikationsdaten 36 und
die Elaborationsphasenverifikationsdaten 38 werden verwendet,
um Komponententests 35 durchzuführen. Die Komponententests 35 stellen
sicher, dass die entwickelten ausführbaren Prozeduren, Komponenten
und andere Software und/oder Hardware jeweils den Verifikationsdaten 36 und 38 von
dem Komponentendesignsubprozess 31 und der Elaborationsphase 30 entsprechen.
-
Die
Region 24 unterhalb der Linie 25 enthält diejenigen
Aufgaben, die auf der Performance der tatsächlichen Komponente und Einheitenhardware und
Software, aus der das Endprodukt besteht, basieren. Die Aufgaben
in Region 23 repräsentieren
die Verifikation der Systemziele basierend auf der Performance der
Einheit und Komponentenhardware und Software, die zusammen als System
arbeiten. Folglich ist der nächste
Test der Integrationstest 37, gefolgt von dem Systemtest 40 und
dem Akzeptanztest 43. Das Testteam designed explizit jeden
Test, um die Verifikation der zuvor definierten Herabsetzungsanforderungen
einzufügen,
wie durch die Verifikationswege 39, 41 und 42 jeweils
angegeben.
-
In
dem Integrationstest 37 gemäß dem gezeigten Ausführungsbeispiel
wird speziell der Betrieb des Produkts oder des Systems getestet,
um sicherzustellen, dass es die Verifikationsdaten 39 und 41 von
der Elaborationsphase 30 und der Konzeptphase 29 jeweils
erfüllt. Ähnlich wird
in dem Systemtest 40 das Produkt oder das System getestet,
um sicherzustellen, dass es die Verifikationsdaten 39 und 41 von der
Konzeptphase 29 erfüllt,
und in dem Akzeptanztest 43 wird das Produkt oder das System
getestet, um sicherzustellen, dass es die Geschäftsmodellverifikationsdaten 42 und
den Geschäftsmodellverifikationsprozess 28 erfüllt. Sobald
der Akzeptanztest 43 erfolgreich abgeschlossen ist, erreicht
das Produkt oder das System einen allgemein verfügbaren Status 44.
Die Schritte 33 bis 44 definieren die Verifikation oder
Validierung der Risikosteueraktivitäten, die zu einem Produkt gehören. Die
Validierungsfunktionen adressieren die tatsächlichen Risiken, die herabgesetzt
wurden, um sicherzustellen, dass die Herabsetzung tatsächlich erfolgreich
war.
-
Die
Funktion des Herabsetzungs- und Konvergenzsubprozesses 26 wird
detailliert unter Bezugnahme auf 4 beschrieben.
Jede Stakeholder Anfrage (SRQ 61 wird analysiert, um ihren
Zustand auf Klarheit und Vollständigkeit
zu bestimmen. Wenn die SRQ 61 mehrdeutig ist, wird die
SRQ kategorisiert als einen vagen Zustand habend, in Schritt 47.
Die vagen SRQs 61 werden an den Stakeholder Identifizierer 49 weitergeleitet,
der den Stakeholder identifiziert, der die Anfrage erzeugt hat,
und der identifizierte Stakeholder wird angefordert die SRQ klarzustellen,
Schritt 48. Wenn eine SRQ 61 eine Lücke oder eine
fehlende Information in dem vorgeschlagenen Produkt oder System
und/oder der zugehörigen
Architektur identifiziert, wird der SRQ in Schritt 46 ein Void
Zustand zugewiesen. Die SRQs, die einen Void Zustand haben, müssen e benfalls
in Schritt 48 von einer Einrichtung, die die notwendige
Information aufweist, klargestellt werden.
-
Sobald
eine klare und vollständige
SRQ 61 empfangen worden ist, wird in Schritt 50 entschieden, ob
die SRQ als ein Merkmal des Produkts eingefügt wird. Wenn in Schritt 50 die
Entscheidung negativ ist, wird das nicht modifizierte Systemdesign
in Schritt 52 untersucht, um zu bestimmen, ob das Design
ein Potential beschädigt
zu werden besitzt, das die Einrichtung beeinträchtigt. Wenn in Schritt 50 die
Entscheidung eine positive ist, wird das Produktdesign modifiziert
oder in Schritt 51 überarbeitet.
Einschränkungen
oder nicht funktionsfähige
Anforderungen, betreffend die Infrastruktur, des Designs werden
in Schritt 53 dokumentiert. Der Dokumentationsschritt 53 stellt
sicher, dass das modifizierte Design in das Gesamtprodukt oder in
die Systeminfrastruktur passt. Die Dokumentation, die in Schritt 53 erzeugt wird,
wird ebenfalls in Schritt 52 untersucht, um zu bestimmen,
ob es einen potenziellen Schaden für die betroffene Einrichtung
verursachen kann.
-
Wenn
in Schritt 52 bestimmt wird, dass das Systemdesign kein
Schadensrisiko enthält,
wird die Designinformation in Schritt 55 an das Managementteam
weitergeleitet. Wenn das Projekt- oder Produktdesign anscheinend
ein Schadensrisiko enthält,
werden das bestimmte Risiko, deren Ursache und die Notwendigkeit
zur Herabsetzung als Teil des Risikoberichts in Schritt 54 dokumentiert.
Der Risikobericht wird ebenfalls an das Managementteam zur Betrachtung
in Schritt 55 weitergeleitet. Das Managementteam entscheidet
in Schritt 55, ob das Produktdesign eine weitere Modifikation
benötigt.
Wenn das Produkt ihr ursprüngliches,
nicht modifiziertes Design behält, geht
das Design zu Schritt 55, wo bestimmt wird, ob Herabsetzungs-
und Konvergenzanforderungen erfüllt
sind. Wenn das Managementteam entscheidet, dass eine Produktüberarbeitung
in Ordnung ist, werden die überarbeiteten
Produktmerkmale in eine Managemententscheidungsmatrix in Schritt 56 eingefügt. Die
Designmatrix wird in Schritt 45 untersucht, um die Einhaltung
der Herabsetzungs- und Konvergenzanforderungen zu bestimmen.
-
In
dem Fall, dass das Produkt- oder Systemdesign nicht die Herabsetzungs-
und Konvergenzeigenschaften erfüllt,
wird in Schritt 59 eine Entscheidung getroffen, um zu bestimmen,
ob irgendein weiterer Vorgang bezüglich der SRQ 61 stattfinden
soll. Wenn die Herabsetzungs- und Konvergenzanforderungen erfüllt sind,
erfolgt die Dokumentation der Herabsetzungsanforderungen in Schritt 58,
wobei die Anforderungendokumentation zu Schritt 59 weitergeleitet
wird, zur Bestimmung, welche Aktion vorgenommen werden soll. Wenn
das Projekt weitergeht, wird der Status der Anfrage, die von dem
Subprozess 26 (3) durchgeführt wurde, in Schritt 57 geschlossen.
Wenn keine weitere Aktion erforderlich ist, wird der Grund der Zurückweisung
der SRQ 61 in Schritt 60 dokumentiert und dann
der Status des Subprozesses 26 Anfrage in Schritt 57 geschlossen.
-
Die
Funktion des Risikoprozessors 5 (1) kann
besser verstanden werden bezüglich
der Durchführung
der Analyse der Wahrscheinlichkeit und der Schwere von Risiken,
und der Evaluierung, wie die Herabsetzung von nicht tolerierbaren
Risiken den Projektplan sowie die Produktentwicklung und das Testen
beeinträchtigt,
wie in 5 gezeigt. Die Analyse beginnt in Schritt 133 mit
der Identifikation eines Risikos, wobei ein Risiko definiert wird
als eine potenzielle Schadensquelle für eine betroffene Einrichtung.
Das Risiko, das in Schritt 133 identifiziert worden ist,
wird mindestens einer potenziellen Risikoanalyse von verschiedenen
unterschiedlichen Formen unterworfen. In dem gezeigten Ausführungsbeispiel
ist speziell eine erste derartige Analyse eine Ausfallmodus- und
Wirkungsanalyse (FMEA) in Schritt 62 und eine zweite ist
eine Fehlerbaumanalyse (FTA) in Schritt 68. Das Ergebnis
von einer oder von beiden Analysen erzeugt einen Satz, der mindestens
eine Ursache, die in Schritt 63 identifiziert wird, enthält. Eine
Ursache ist definiert als ein vorhersehbares Ereignis oder eine
Folge von Ereignissen, die eine Risikosituation erzeugen können.
-
Die
Ursachen, die in Schritt 63 identifiziert werden, werden
einer Schwereanalyse in Schritt 66 und einer Wahrscheinlichkeitsanalyse
in Schritt 67 unterworfen. Die Ergebnisse der Schwereanalyse und
der Wahrscheinlichkeitsanalyse in den Schritten 66 und 67 werden
jeweils in Schritt 65 analysiert, um einen absoluten Risikowert
zu berechnen. Im Allgemeinen hängt
die Gefahr des Risikos 133 von den jeweiligen Schweren 66 und
Wahrscheinlichkeiten des Auftretens 67 der Ursachen 63 ab.
Beispielsweise wird eine zusammengesetzte Schwere, die von den jeweiligen
Schweren der Ursachen 63 abhängt, und eine zusammengesetzte
Wahrscheinlichkeit, die von den jeweiligen Wahrscheinlichkeiten
des Auftretens der Ursachen 63 abhängt, dem Risiko 133 zugewiesen
werden. In diesem Beispiel kann das absolute Risiko 65 basierend
auf der zusammengesetzten Schwere und Wahrscheinlichkeit des Risikos 133 berechnet
werden. Alternativ können
die jeweiligen Schweren 66 und Wahrscheinlichkeiten 67 der
Ursachen 63 separat analysiert werden, um einen absoluten
Risikowert in Schritt 65 zu erzeugen.
-
Die
Wirkung des Risikowerts hängt
von der Identität
der betroffenen Einrichtung 64 ab, und von dem Risikowert,
der in Schritt 65 bestimmt wird, und dem Risiko von Schritt 133.
Der Risiko wert von Schritt 65, der Typ der betroffenen
Einrichtung von Schritt 64 und die Information, die das
Risiko von Schritt 133 darstellt, werden verarbeitet, um
einen Wert der Risikotoleranz in Schritt 69 zu erzeugen. Wenn
das Risiko tolerierbar ist, endet die Analyse mit einer Entscheidung
in Schritt 70, dass keine Herabsetzung erforderlich ist.
Wenn das Risiko nicht tolerierbar ist, wird die entsprechende Information
weitergeleitet an den Herabsetzungsanalysesubprozess zur weiteren
Analyse, gezeigt als in Schritt 71 beginnend.
-
Der
erste Schritt 72 in der Herabsetzungsanalyse dient zum
Bestimmen, ob die betroffene Einrichtung ein Projekt oder ein Produkt
ist. Wenn der betroffene Einrichtungstyp ein Projekt ist, werden
die entsprechenden Risikodaten an das Projektmanagementteam 73 übermittelt,
das das Projekt entsprechend in dem Prozessschritt 74 überarbeitet,
indem beispielsweise die Projektpläne überarbeitet werden, projektbezogene
Aufgaben durchgeführt
werden oder andere entsprechende Aktionen vorgenommen werden. Wenn
die betroffene Einrichtung ein Produkt ist, wird die Risikoinformation
analysiert entsprechend den relevanten Standards für dieses
Produkt. Im Falle einer medizinischen Vorrichtung beispielsweise
wird die Risikoinformation der ISO 14971 Analyse in Schritt 75 unterworfen.
Basierend auf den bestimmten Anforderungen des ISO 14971 Standards, wie
er für
das Risiko von Schritt 133 verwendet wird, werden die zu
erfüllenden
Standards an das Anforderungenengineeringteam in Schritt 76 weitergeleitet, das
ein Anforderungen- und Testprogramm in Schritt 77 formuliert.
-
Nachdem
die Herabsetzung für
das identifizierte Risiko für
die betroffene Einrichtung durchgeführt wurde, kann das Risiko
erneut analysiert werden. Dies ist in dem Phantom in 5 angegeben. Das
Risiko, das in 133 identifiziert worden ist, wird durch
FMEA 62 und/oder FTA 68 erneut analysiert, um
einen überarbeiteten
Satz von Ursachen 63 zu erzeugen. Die Schwere und die Wahrscheinlichkeit
des überarbeiteten
Satzes von Ursachen 63 werden bestimmt (66, 67)
und ein Nach-Herabsetzungsrisiko wird berechnet (65). Das
resultierende Nach-Verarbeitungsrisiko wird in Schritt 69 geprüft, um zu
bestimmen, ob das Risiko tolerierbar ist. Wenn es tolerierbar ist,
dann werden weitere Herabsetzungen in Schritt 71 definiert,
wie oben beschrieben.
-
Der
Risikoprozessor 5 (1) ist auch
in der Lage zum Verarbeiten und zum Analysieren von Risikoinformation
in alternativer Art und Weise. Ein zweites Ausführungsbeispiel des Funktions-Risikoprozessor 5 ist
in 6 gezeigt, wobei SRQs 61 parallel an
den Subprozess 28 (3) für brauchbare
Geschäftsfälle, den
Konzeptphasensubprozess 29 und den Elaborationsphasensubprozess 30 weitergeleitet werden.
Jeder der Subprozesse 28, 29 und 30 übermittelt
die er zeugte Information, und insbesondere die Information bezüglich der
Risiken, an Schritt 78, der einen der potenziellen verschiedenen
Modi der Risikoanalyse auswählt.
In dem gezeigten Ausführungsbeispiel
kann der Schritt 78 speziell auswählen, ob eine Fehlerbaumanalyse
(FTA) in Schritt 68 oder eine Ausfallmodus- und Wirkungsanalyse
(FMEA) in Schritt 62 durchgeführt wird.
-
Die
FMEA Analyse 62 ordnet potenzielle Ursachen, die durch
Block 79 dargestellt sind, einem entsprechenden Risiko
zu, das durch Block 81 dargestellt ist, während die
FTA Analyse 68 ein Risiko, das durch den Block 82 dargestellt
ist, mit entsprechenden potenziellen Ursachen, die durch Block 80 dargestellt
sind, verknüpft.
Die jeweiligen Ursachen (79, 80) und die Risiken
(81, 82), die durch die Analyseverfahren 62 und/oder 68 jeweils
erzeugt worden sind, werden an den Schritt 134 geliefert.
In Schritt 134 wird eine Risikoschwere und eine Wahrscheinlichkeit
des Auftretens für
einen betroffenen Einrichtungstyp mit jedem Risiko 81, 82 verknüpft. Darüber hinaus
wird ein Wert, der das Risiko repräsentiert, dass das Risiko 81, 82 für den betroffenen
Einrichtungstyp aufwirft, berechnet. In dem gezeigten Ausführungsbeispiel
ist der betroffene Einrichtungstyp identifiziert als Markt, Projekt
und/oder Produkt, Schritt 83. Unabhängig von dem betroffenen Einrichtungstyp
resultiert ein Bestimmen in den Schritten 84, 87 und 88,
dass das Risiko tolerierbar ist, in einer Information, die zu dem
zugrundeliegenden SRQ 61 gehört, als ein akzeptables Risiko,
das keine weitere Aktion erfordert.
-
Wenn
in Schritt 83 der betroffene Einrichtungstyp ein Markt
ist, und das Risiko in Schritt 84 als nicht tolerierbar
bestimmt wird, wird in Schritt 85 eine Marktanalyse durchgeführt, und
die Ergebnisse werden aus finanzieller Sicht in Schritt 86 erneut
untersucht. Die Ergebnisse der finanziellen Betrachtung in Schritt 86 werden
zur Verknüpfung
mit der zugrundeliegenden SRQ 61 zurückgegeben. Wenn der betroffene
Einrichtungstyp ein Produkt ist, dann wird ein relevanter Standard,
der dieses Produkt betrifft, herangezogen, um einen akzeptablen
Risikotoleranzlevel zu bestimmen. In dem gezeigten Ausführungsbeispiel,
wenn der betroffene Einrichtungstyp ein medizinisches Produkt ist,
wird speziell die Risikoinformation mit dem relevanten Standard,
ISO 14971, in Schritt 75 verglichen, um den tolerierbaren
Risikolevel zu bestimmen. Wenn in Schritt 87 das Risiko
als nicht tolerierbar bestimmt wird, geht die Risikoinformation
in einen Herabsetzungssubprozess in Schritt 71. Der Herabsetzungssubprozess 71 erzeugt
Herabsetzungsempfehlungen, die an den Anforderungenengineeringsubprozess
in Schritt 76 übermittelt werden.
Der Anforderungenengineeringsubprozess 76 erzeugt Herabsetzungsanforderungen,
die an eine Anforderungenspezifikations- und Testphase in Schritt 77 geleitet
werden. Die Ergebnisse der Test phase 77 werden dann mit
dem zugrundeliegenden SRQ 61 verknüpft. Wenn die betroffene Einrichtung ein
Projekt ist, und das Risiko in Schritt 88 als nicht tolerierbar
bestimmt wird, wird die Risikoinformation an den Projektmanagementsubprozess
in Schritt 73 geliefert. Der Projektmanagementsubprozess 73 erzeugt
einen Satz von überarbeiteten
Plänen,
Aufgaben oder anderen entsprechenden Maßnahmen in Schritt 74,
die zu der ursprünglichen
SRQ 61 gehören.
Wie oben unter Bezugnahme auf 5 beschrieben,
können
die Risiken erneut analysiert werden, um zu verifizieren, dass die
resultierenden Nachherabsetzungsrisiken akzeptabel sind.
-
Ein
Ausführungsbeispiel
kann verstanden werden unter Bezugnahme auf die 7 bis 17, die
verschiedene grafische Benutzerschnittstellen (GUI) Anzeigebilder
zeigen, die in Verbindung mit einer ausführbaren Anforderungenmanagementanwendung
verwendet werden können.
Ein Beispiel einer derartigen Anwendung ist das CaliberRM-Produkt
von Borland Software Corporation, 100 Enterprise Way, Scotts Valley,
California 95066-3249. Das CaliberRM-Programm kann beispielsweise
verwendet werden, um Information bezüglich der Arbeit zu erfassen,
die als Teil des Risikomanagementprozesses für medizinische Vorrichtungen
durchgeführt wird,
wie durch ISO 14971 angegeben.
-
7 zeigt
ein GUI-Anzeigenbild 89, das einen Link 90 auf
eine Risk Management und Hazard (RMH) Region enthält. Typischerweise
hat ein Hazard (Risiko) ein oder mehrere Ursachen. In dem GUI-Anzeigenbild 89 ist
dies hierarchisch auf der linken Seite des Bildes dargestellt. Ein
Hazard-Item existiert an einem Eltern-Level und kann verknüpft werden
mit einem oder mit mehreren Ursachen-Items, die in einem Kind-Level
bezüglich
des Hazard-Items existieren.
-
Die
RMH Region ist auf der rechten Seite des GUI-Anzeigenbildes 89 verdeutlicht,
und enthält einen „Tabbed" Bereich. Die Auswahl
durch einen Benutzer 2 (1) eines
Items in der hierarchischen Liste auf der linken Seite des GUI-Anzeigenbildes 89, verdeutlicht
durch eine Hervorhebung des ausgewählten Items, verursacht den
Tabbed Bereich auf der rechten Seite zur Anzeige von Details über das ausgewählte Item.
Eine Mehrzahl von Dateneintragefeldern in der RMH-Region des GUI-Anzeigenbildes 89 erlaubt
einem Benutzer 2 Daten bezüglich des ausgewählten Items
einzugeben oder zu aktualisieren. Derartige Dateneintragefelder
enthalten typischerweise eine Labelkomponente und entsprechende
Dateneintragekomponente, beispielsweise Checkboxen 91, 116 und 124,
Texteingabeboxen, Auswahlboxen und dergleichen.
-
Ein „Cause" (Ursachen) Dateneingabefeld 95 ermöglicht einem
Benutzer 2 (1) die Angabe, ob das hervorgehobene
Element ein Risiko oder eine Ursache ist, indem die Checkboxdateneingabekomponente 91 markiert
oder unmarkiert wird. Andere Dateneingabefelder ermöglichen
es dem Benutzer 2 die Eingabe entsprechender Information:
ein „Command/Reason
for Action" (Kommentar/Grund
für den Vorgang)
Dateneingabefeld 97; ein „Initial Hazard/Cause Probability" (Anfangsrisiko/Ursachenwahrscheinlichkeit)
Dateneingabefeld 108; ein „Initial Hazard Severity" (Anfangsrisikoschwere)
Dateneingabefeld 111; ein „Mitigation Required" (Herabsetzung erforderlich)
Dateneingabefeld 114; ein „Residual Hazard/Cause Probability" (Restrisiko/Ursachenwahrscheinlichkeit)
Dateneingabefeld 117; ein „Residual Hazard Severity" (Restrisikoschwere)
Dateneingabefeld 120; ein „Affected Entity Type" (betroffener Einrichtungstyp)
Dateneingabefeld 99; und ein „Signoff" Dateneingabefeld 123. Wenn
das Anforderungenteam Risiken und ihre Ursachen auffindet, sind
die Teammitglieder in der Lage, aktualisierte Dokumentationen einer
Ursache anzulegen oder auf dem aktuellen Stand zu halten (die Ursache
kann das Kind des Risikos sein), indem die Ursachencheckbox 91 markiert
wird und Information über
die Ursache in den anderen Dateneingabefeldern eingegeben wird.
-
Die
verschiedenen Datenfelder, die in der GUI 89 erscheinen,
entsprechen den Ursachenattributen, die von dem Benutzer 2 definierbar
sind (1). Im Allgemeinen ist ein Attribut spezifiziert durch
einen Namen und eine Beschreibung, und möglicherweise durch andere Daten,
die das Attribut beschreiben, Metadaten, beispielsweise Defaultwerte
oder Datentyp, (also Kanal, Text, Boolean, etc.).
-
Eine
GUI 93, wie in 8 gezeigt, erlaubt einem Benutzer 2 (1)
ein Attribut zu definieren. Speziell in dem Ausführungsbeispiel definieren Daten,
die in der GUI 93 gemäß 8 dargestellt
sind, das „Cause" Attribut, entsprechend
dem „Cause" Dateneingabefeld 95 in
der GUI 89 (7). Das „Cause" Dateneingabefeld 95 erlaubt
dem Benutzer 2 zwischen hierarchischen Elementen, die ein
Risiko betreffen, und denjenigen, die die zugehörigen Ursachen betreffen, zu
unterscheiden, wie oben beschrieben. In 8 ist ein
Ursachenattribut definiert durch den Eintrag von „Cause" in die Namentextbox 95.
Der Text in der Beschreibungstextbox 94 gibt an, dass, wenn
der Wert des „Cause" Attributs markiert
ist, das Element dann eine Ursache ist, und wenn der Wert nicht
markiert ist (not checked), das Element ein Risiko ist. Dies kann
verwendet werden, um den Benutzer bei der Lieferung von Daten für dieses
Dateneingabefeld zu führen.
Metadaten für
das „Cause" Attribut enthalten
die Spezifikation eines Boolean Datentyps, resultierend in dem Checkboxdateneingabefeld 95 und
einem Defaultwert von unchecked.
-
Die
GUI 96, wie in 9 gezeigt, erlaubt einem Benutzer 2 (1)
ein „Command/Reason
for Action" (Kommentar/Grund
für die
Aktion) Attribut zu definieren entsprechend dem „Command/Reason for Action" Dateneingabefeld 97 (7).
Das „Command/Reason
for Action" Dateneingabefeld 97 erlaubt
dem Benutzer 2 die Angabe von zusätzlicher Information, die zu
dem „Cause" Attribut 95 gehört (8).
In einer ähnlichen
Weise zu der oben beschriebenen für 8, kann
der Text in der Beschreibungstextbox 98 verwendet werden,
um den Benutzer bei der Lieferung von Daten für dieses Dateneingabefeld zu
führen,
und angeben, dass der Benutzer eine Textbeschreibung für die Aktion,
die vorzunehmen ist, für
die entsprechende Anforderung, Risiko oder Ursache eingibt. Eine
weitere Beschreibung kann gegeben werden. Der Datentyp dieses Attributs ist
definiert als „Multiple
Line Text Field" (Mehrzeilentextfeld),
das dem Benutzer 2 erlaubt, Textinformation einzugeben.
Eine derartige Information kann beispielsweise ein Grund sein, dass
ein Risiko, dass ein ALARP (As Low As Reasonably Practical) Risk
Rating keine Herabsetzung erfordert, oder irgendeine andere zusätzliche
Information bezüglich
eines Risikos und/oder einer Ursache, die dem Benutzer 2 geeignet
erscheint.
-
Bezugnehmend
auf 10, ist ein Benutzer 2 (1)
in der Lage das „Affected
Entity" (betroffene Einrichtung)
Attribut zu definieren, entsprechend dem „Affected Entitiy" (betroffene Einrichtung)
Dateneingabefeld 99 (7), mittels
der GUI 100. In 10 ist
der Typ des „Affected
Entity" Attributs
definiert als eine einzelne Auswahlliste. Dies erlaubt einem Benutzer
einen einzelnen Wert aus einer vorbestimmten Liste von Werten auszuwählen. Das
Feld 101 erlaubt dem Benutzer 2 die Liste von
erlaubten Werten für
eine betroffene Einrichtung zu definieren, beispielsweise für einen
Patienten 102, einen Benutzer oder eine andere Person 103,
Servicepersonal 104, Systemgeräte und Komponenten 105 und
die Umgebung 106. Die Defaultauswahl ist spezifiziert in dem
Feld 107, das beispielsweise ein ,Patient' 102 ist.
-
Das „Initial
Hazard/Cause Probability" Attribut,
entsprechend dem „Initial
Hazard/Cause Probability" Dateneingabefeld 108 (7)
ist in der in 11 gezeigten GUI 109 definiert.
Das „Initial
Hazard/Cause Probability" Attribut 108 ist
ebenfalls ein ,Einzelauswahllisten' Typ, und die Items in der Liste von
erlaubten Werten, in der Textbox 110 gezeigt, stellen jeweilige
Bereiche der Wahrscheinlichkeit dar. Unter Verwendung der GUI 89 (7)
verwendet ein Benutzer 2 (1) das „Initial
Hazard/Cause Probability" Dateneingabefeld 108,
um einen entsprechenden Wahrscheinlichkeitsbereichswert für jede Ursache 95 während der
Anfangsrisikoanalyse und vor irgendeiner Herabsetzungstätigkeit
auszuwählen.
Die Risikoanalyse kann durchgeführt
werden unter Verwendung des FTA 68 und/oder FMEA 62 (5 und 6)
Ansatzes, obwohl irgendein derartiger Ansatz verwendet werden kann.
Die jeweiligen Ursachen 95 haben individuelle Risikowahrscheinlichkeiten,
die in die entsprechenden Dateneingabefelder 108 (7) eingegeben
werden, die zu der Gesamtwahrscheinlichkeit beitragen, die dem Elternrisiko
zugewiesen wird. Das Risiko hat eine Wahrscheinlichkeit, dass es zumindest
gleich der größten Wahrscheinlichkeit
ist, die von den verschiedenen Ursachen, die zu diesem Risiko gehören, vorhanden
ist.
-
Ein
Benutzer 2 (1) kann eine Anfangsrisikoschwere
(also vor irgendeiner Herabsetzung) in das „Initial Hazard/Severity" Dateneingabefeld 111 (7)
während
der Anfangsrisikoanalyse eingeben. Das „Initial Hazard/Severity" Attribut, das dem „Initial Hazard/Severity" Dateneingabefeld 111 entspricht, wird
mittels der in 12 gezeigten GUI 112 definiert.
Die „Initial
Hazard Severity" Anfangsrisikoschwere
(111) ist auch als ,Einzelauswahlliste' (Single Selection List) definiert,
und die Liste der Werte in der Textbox 113 entspricht Bereichen
der Schwere. Im Allgemeinen ist die Risikoschwere 111 eine
Eigenschaft des Risikos selbst. Der Benutzer 2 kann entscheiden,
ob er Kontrolle über
die Zuweisung eines Werts zu der Schwere einer Ursache 95 wünscht. Individuelle
Werte können
aus dem Feld 113 ausgewählt
werden. Wenn eine Ursache 95 einen unverhältnismäßigen Wert
an Schwere aufweist, kann der Benutzer 2 ein anderes Risiko
herausfinden.
-
13 zeigt
eine GUI 115, die einem Benutzer 2 (1)
erlaubt, ein „Mitigation
Required" (Herabsetzung
erforderlich) Attribut zu definieren, entsprechend dem „Mitigation
Required" Dateneingabefeld 114 (7).
Das „Mitigation
Required" Attribut
ist definiert als ein Boolean Typ und durch eine Checkbox 116 in 7 dargestellt.
Das „Mitigation
Required" Dateneingabefeld
kann von dem Benutzer verwendet werden, um anzugeben, ob eine Herabsetzung
erforderlich ist und/oder ob Modifikationen des Designs erforderlich
sind, um die Schwere und/oder Wahrscheinlichkeit des Risikos zu
reduzieren.
-
Sobald
eine Anfangsschwere und Wahrscheinlichkeit einem Risiko und/oder
eine Ursache über
die Dateneingabefelder 111 und 108 (7)
zugewiesen ist, kann ein Benutzer 2 (1)
eine Risikomatrix heranziehen, um den Level des Risikos zu bestimmen,
der durch die Schwere und die Wahrscheinlichkeit repräsentiert
ist. Beispielsweise kann das Risiko ein nicht tolerierbares, ALARP
(As Low As Reasonably Practical) oder ein breit akzeptierbares Risiko
sein. Das nicht tolerierbare Risiko erfordert Maßnahmen; ein ALARP Risiko kann
unter gewissen Umständen
eine Maßnahme
erfordern; und ein akzeptables Risiko erfordert typischerweise keine
Maßnah me.
Durch Markieren der „Mitigation
Required" Checkbox 116 gibt
der Benutzer 2 an, dass eine Herabsetzung des Risikos notwendig
ist, um das Risiko zu reduzieren. Typischerweise schlägt der Benutzer 2 eine
entsprechende Herabsetzung für
eine Ursache oder für
Ursachen 95 vor, die die nicht tolerierbare oder ALARP-Risikosituation
erzeugen. Der Benutzer 2 erzeugt dadurch eine Spur von
der Ursache 95 zu den Herabsetzungsanforderungen.
-
Der
Benutzer 2 (1) führt auch eine Analyse durch,
um die Restschwere und Wahrscheinlichkeit eines Risikos und/oder
einer Ursache zu bestimmen, indem angenommen wird, dass die bestimmte Herabsetzung
oder die Herabsetzungen durchgeführt
werden. 14 verdeutlicht eine GUI 116,
die dem Benutzer 2 erlaubt, ein „Residual Hazard/Cause Probability" Attribut zu definieren,
entsprechend dem „Residual
Hazard/Cause Probability" (Restrisiko/Ursache
Wahrscheinlichkeit) Dateneingabefeld 117 (7).
Das „Residual
Hazard/Cause Probability" Attribut
ist ein Einzelauswahllistenattribut. Eine Liste von erlaubten Auswahlmöglichkeiten
ist in der Textbox 118 verdeutlicht. Unter Bezugnahme der
entsprechenden Risikoanalyse, also FTA 68 oder FMEA 62 (5 und 6),
bestimmt der Benutzer 2 Wahrscheinlichkeiten für die Ursachen 95,
indem angenommen wird, dass sie herabgesetzt worden sind. Der Benutzer 2 weist
eine Restwahrscheinlichkeit dem zugehörigen Risiko und/oder der Ursache
zu, indem in dem Dateneingabefeld 117 einer der Einträge in der
Liste von erlaubten Auswahlmöglichkeiten
in der Textbox 118 ausgewählt wird.
-
Als
Teil von der FTA 68 oder FMEA 62 Analyse, die
nach der Herabsetzung 71 durchgeführt wird (5)
wird ein „Residual
Hazard/Severity" (Restrisiko/-schwere)
für das
Risiko und/oder seine Ursachen berechnet. Die in 15 gezeigte
GUI 119 erlaubt einem Benutzer 2 (1),
ein „Residual
Hazard/Severity" Attribut
zu definieren, entsprechend dem „Residual Hazard/Severity" Dateneingabefeld 120 (7). Der „Residual
Hazard/Severity" Wert
ist definiert als eine ,Einzelauswahlliste' (Single Selection List) und die erlaubten
Schwerewerte sind in der Textbox 121 definiert. Der Benutzer 2 kann über das „Residual Hazard/Severity" Dateneingabefeld 120 eine
Restschwere mit dem zugehörigen
Risiko und/oder der Ursache verknüpfen, indem einer der Einträge in der Liste
von erlaubten Auswahlmöglichkeiten
in der Textbox 121 ausgewählt wird. Der Benutzer 2 bewertet
die Risikomatrix neu, um sicherzustellen, dass der Risikolevel tatsächlich ausreichend
reduziert worden ist, oder falls nicht, um zu bestimmen, ob zusätzliche korrigierende
Maßnahmen
erforderlich sind.
-
Wie
oben beschrieben, hat ein identifizierbares Individuum einen Verantwortungsgrad
zur Sicherstellung, dass Risiken und/oder Ursachen, die für eine Herabsetzung
markiert worden sind, tatsächlich herabgesetzt
worden sind. Die GUI 122, wie in 16 gezeigt,
verdeutlicht ein „Signoff" (Unterzeichnungs)
Attribut, entsprechend dem „Signoff" Dateneingabefeld 123 (7).
Das „Signoff" Attribut ist ein
Boolean Typ, dessen Wert durch die Checkbox 124 (7)
dargestellt ist. Dies erlaubt der verantwortlichen Person anzugeben,
dass die spezifizierte Herabsetzung oder die Herabsetzungen durchgeführt worden
sind, indem die Checkbox 124 markiert wird. Eine Markierung
gibt an, dass diese Person unterschrieben hat. Die Markierung der
Signoff Checkbox 124 ist eine positive Anzeige dafür, dass
eine Akzeptierung der existierenden Risikoannahmewerte vorliegt.
-
Die
Attribute und die entsprechenden Dateneingabefelder in 7,
wie oben beschrieben, liefern Information über die Risiken und die entsprechenden Ursachen,
die während
des Risikomanagementprozesses identifiziert werden. Andere Attribute,
die diesen Prozess betreffen, können
definiert werden, und Daten können über die
zugehörigen
Dateneingabefelder erfasst werden.
-
Wie
bereits diskutiert, hat jedes Produkt oder Projekt einen Lebenszyklusbeginn 9 und
ein Lebenszyklusende 11 (2). Ein „Requirement
Status" (Anforderungenstatus)
Attribut und ein entsprechendes „Requirement Status" (Anforderungsstatus)
Dateneingabefeld (nicht gezeigt), kann den Status des Risikomanagementprozesses
während
der Analyse angeben. Die GUI 125, wie in 17 gezeigt,
erlaubt einem Benutzer 2 (1) das „Requirement
Status" Attribut
zu definieren. Das „Requirement
Status" Attribut
ist definiert als ein Einzelauswahllistenattribut, und die Werte
in der Textbox geben die Zustände
an, dass der Risikomanagementprozess sein kann bei: ,Submitted' (beantragt) 126,
,Qualified' (qualifiziert) 127,
,Assigned' (zugewiesen) 129,
,Fulfilled' (erfüllt) 130,
,Sunsetted' (aufgegeben) 131,
,Rejected' (zurückgewiesen) 128 und
dergleichen. Wenn der Risk Managementprozess durch seine Zustände läuft, aktualisiert
ein Benutzer 2 den „Requirement
Status" über das
entsprechende Dateneingabefeld.
-
Im
Allgemeinen beginnt der Risk Managementprozess in dem ,Submitted' Zustand 126,
da jemand eine SRQ eingereicht hat, die ein Starten des Risikoevaluierungsprozesses
anfordert. Der Risikoevaluierungsprozess geht in einen ,Qualified' Zustand 127,
sobald ein „Peer
Review" stattgefunden
hat. Wenn ein Risiko oder eine Ursache als irrelevant befunden wird,
wird diesem Risiko der ,Rejected' Zustand 128 zugewiesen.
Ein ,Assigned' Zustand 129 gibt
an, dass das Risiko und seine Ursachen einen bestimmten Release
eines Systems zugewiesen ist. In diesem Fall werden die FTA 68 und/oder
FMEA 62 Analysen abgeschlossen für die Anfangsbeurteilung der
Schwere und der Wahrscheinlichkeit. Nachdem das „Signoff" Attribut 123 markiert ist
und die Validierung stattgefunden hat, geht der Status in den ,Fulfilled' Zustand 130.
Wenn ein System aus der Verbreitung zurückgezogen wird, oder ,Sunsetted', wird der Zustand
für die
betreffenden Risiken und Ursachen als ,Sunsetted' Zustand 131 markiert. Andere Zustände können definiert
und verwendet werden, um den Zustand des Risk Assessment Prozesses
anzugeben.
-
Andere
Attribute, beispielsweise die Namen der verantwortlichen Personen
(beispielsweise die Person, die für das Unterzeichnen verantwortlich
ist, dass die erforderliche Herabsetzung oder die Herabsetzungen
durchgeführt
wurde, wie durch das Dateneingabefeld 123 angegeben); den
tatsächlichen
Anfangs- und Restrisikolevel (nicht tolerierbares ALARP (As Low
As Reasonably Practical) oder breit akzeptierbar); und dergleichen
können
ebenfalls definiert werden und entsprechende Dateneingabefelder
in der GUI 89 gemäß 7 vorgesehen
werden.
-
Die
Dateneingabefelder in den oben genannten GUIs 89 (7)
können
in dem oben beschriebenen Projektlebenszyklusphasen zugreifbar sein.
Darüber
hinaus können
andere Attribute und entsprechende Dateneingabefelder durch den
Benutzer 2 (1) definiert werden, indem GUIs
verwendet werden, die ähnlich
zu den oben beschriebenen GUIs 93, 96, 100, 109, 112, 115, 116, 119 und 122 sind. Beispielsweise
kann in der Konzeptphase 29 das Anforderungenteam Merkmale
für das
Zielsystem erzeugen. Das Team kann die Unterstützung von Gegenstandsexperten
oder anderen Analysten, beispielsweise Risiko-, Experten- und behördliche
Analysten verwenden, um den Risk Managementprozess durchzuführen, der
Risiken und ihre Ursachen aufdeckt. Die allgemeinen Analysetechniken
sind FMEA 62 oder FTA 68. Als Teil der Risikoanalyse
kann das Team einen Systemarchitekten kontaktieren, um eine Architektur
zu erzeugen, die die Risiken und ihre Ursachen 95 enthält.
-
Wie
in 7 gezeigt, wenn das Team Risiken und ihre Ursachen
aufdeckt, dokumentieren die Teammitglieder diese Information, indem
das oben beschriebene System verwendet wird. Für die jeweiligen Ursachen markiert
der Benutzer 2 die „Cause" Box 91,
wählt den „Affected
Entity Type" (betroffener Einrichtungstyp) 99,
und wählt
die „Initial
Hazard/Severity" (anfängliches
Risiko/Schwere) 111. Das Team kann die „Initial Hazard/Cause Probability" (anfängliches
Risiko/Ursache Wahrscheinlichkeit) 108 auswählen. Typischerweise
wird dem Risiko die Wahrscheinlichkeit zugewiesen, die durch FTA 68 oder FMEA 62 bestimmt
worden ist. Die Risikoschwere ist das Worst Case Szenario, das aus
dem gleichzeitigen Auftreten aller Ursachen resul tiert. Wenn die
Ursachen und ihre Risiken bestimmt sind, kann das Team bestimmen,
ob eine Ursache 95 eine Herabsetzung erfordert oder nicht.
Das Team kann das „Comment/Reason
for Action" (Bericht/Grund
für die
Aktion) Feld 97 verwenden, um eine Wahl einer nicht Herabsetzung
oder eine Feststellung, dass keine Herabsetzung notwendig ist, zu
dokumentieren. Wenn ein Merkmal für den Zweck der Herabsetzung
entwickelt worden ist, können
die Ursachen, die eine Herabsetzung erfordern, für dieses Merkmal aufgespürt werden.
Andererseits kann das Team die Anforderungen erzeugen, um die Ursachen
in der Elaborationsphase 30 herabzusetzen (3).
-
Das
Risk Managementsystem, wie oben beschrieben, kann auf einem Computersystem 200 implementiert
sein, wie in 18 gezeigt. Das Computersystem 200 enthält eine
zentrale Verarbeitungseinheit (CPU) 202, einen Speicher 204,
eine Massenspeichervorrichtung 206 und eine Eingabe/Ausgabe-Schnittstelle 208,
die durch einen Computerbus 205 miteinander gekoppelt sind.
Die Eingabe/Ausgabe (I/O)-Schnittstelle 208 ist an eine
Benutzerschnittstelle gekoppelt, die aus einem Monitor 212,
einer Tastatur 213 und einem Zeigegerät, was gemäß dem Ausführungsbeispiel eine Maus 214 ist,
aufgebaut ist. Die I/O-Schnittstelle 208 ist auch an eine
entfernbare Speichervorrichtung 210 gekoppelt, die Daten auf
einem oder auf mehreren Speichermedien speichern oder von diesen
holen kann. Das Speichermedium 216 kann magnetische Vorrichtungen
enthalten, beispielsweise ein „Reel
To Reel" Computerband,
Kassettenbänder
und magnetische Plattenmedien, beispielsweise Floppy Disks und dergleichen. Das
Speichermedium 216 kann auch optische Vorrichtungen enthalten,
beispielsweise eine DVD (Digital Video Disc) oder CD (Compact Disc)
und dergleichen. Ein Fachmann auf diesem Gebiet versteht, dass irgendein
tragbares Speichermedium verwendet werden kann, beispielsweise Speichervorrichtungen,
die integrierte Halbleiterspeicherschaltungen enthalten. Die UO-Schnittstelle 208 kann
auch an andere periphere Vorrichtungen (nicht gezeigt) gekoppelt
sein, beispielsweise an Drucker zum Erzeugen von Berichten 8 (1)
oder Kommunikationsvorrichtungen (nicht gezeigt) zur Kommunikation
mit Fernsystemen, LAN (Local Area Networks) oder WAN (Wide Area
Networks), wie etwa das Internet.
-
Die
CPU 202 enthält
einen Prozessor, der die maschinenlesbaren Anweisungen ausführt, die eine
ausführbare
Anwendung und/oder ausführbare Prozeduren
bilden. Diese maschinenlesbaren Anweisungen werden in dem Speicher 204 gespeichert,
der ein ROM (Read Only Memory) und/oder ein RAM (Read/Write Memory)
sein kann. Die CPU 202 holt die maschinenlesbaren Anweisungen
aus dem Speicher 204 und führt diese aus, um die Operationen des
Risk Management Systems durchzuführen,
wie oben beschrieben.
-
In
dem gezeigten Ausführungsbeispiel
enthält
der I/O Prozessor 208 einen Anzeigenprozessor, der in Antwort
auf Befehle von der CPU 202 Signale erzeugt, die die GUI-Anzeigenbilder
darstellen, wie oben in 7 bis 17 beschrieben,
und diese bildrepräsentierenden
Signale an den Monitor 212 liefert, der die Bilder anzeigt.
Der I/O Prozessor 208 empfängt auch Benutzerbefehle und
Daten von der Tastatur 213 und/oder der Maus 214 und
liefert diese Information an die CPU 202. Die CPU 202 antwortet auf
die empfangenen Benutzerbefehle und Daten, um die Operation des
Risk Management Systems zu steuern, wie oben beschrieben.
-
Daten
können
aus der Massenspeichervorrichtung 206 geholt oder darin
gespeichert werden. Beispielsweise kann die Massenspeichervorrichtung 206 einen
Speicher für
eine oder für
mehrere Ablagen von Information enthalten, beispielsweise den Risikoassoziationsspeicher 4 und
den Detailanforderungsspeicher 7 (1). Die
Massenspeichervorrichtung 206 kann auch die maschinenlesbaren
Anweisungen speichern, die die ausführbare Anwendung und/oder ausführbaren
Prozeduren bilden. Die CPU 202 kann die ausführbare Anwendung
und/oder die ausführbaren
Prozeduren von der Massenspeichervorrichtung 206 holen
und sie in dem Speicher 204 speichern. Die CPU 202 kann
dann die maschinenlesbaren Anweisungen aus dem Speicher 204 holen
und die ausführbare
Anwendung und/oder die ausführbare
Prozeduren ausführen,
um die oben beschriebenen Risk Management Vorgänge durchzuführen.
-
Die
Daten können
auch aus einem konkreten Speichermedium 216 geholt und
darin gespeichert werden, über
die entfernbare Speicherschnittstelle 210. Irgendwelche
Daten können
in dem konkreten Speichermedium gespeichert und/oder aus diesem geholt
werden. In dem Ausführungsbeispiel
können speziell
die maschinenlesbaren Anweisungen in der ausführbaren Anwendung und/oder
den ausführbaren
Prozeduren, die das Risk Managementsystem bilden, in einem konkreten
Speichermedium gespeichert sein. Die CPU 202 kann den I/O
Prozessor 208 konditionieren, um die ausführbare Anwendung und/oder
die ausführbaren
Prozeduren aus dem entsprechenden konkreten Speichermedium über die entfernbare
Speicherschnittstelle 210 zu holen und die ausführbare Anwendung
und/oder die ausführbaren
Prozeduren in dem Massenspeicher 206 und/oder dem Speicher 204 zu
speichern. Die CPU 202 kann dann die ausführbare Anwendung
und/oder die ausführbaren
Prozeduren in dem Speicher 204 ausführen, um die oben beschriebenen
Risk Management Vorgänge
durchzuführen.