Читать книгу Entwicklung eines Vorgehens zum Safety Assessment für sicherheits-kritische Informationssysteme - Christina Schäfer - Страница 12

1 Einleitung

Viele Arbeitswelten werden in der heutigen Zeit zunehmend komplexer und weitreichend technisiert und somit wird auch die Möglichkeit zur IT-Unterstützung gegeben. Dieser gesellschaftliche Wandel erfordert dadurch auch ein Umdenken in der Entwicklung einer solchen Unterstützung.

1.1 Motivation und Problemstellung

Einsatzkräfte der Feuerwehr haben in allen Phasen des Crisis Management Cycles (siehe [DrMS15]) Mitigation, Preparedness, Response und Recovery Bedarf an IT-Unterstützung (siehe auch [PoSc18]).

Darüber hinaus können Aufgaben durch eine schnelle rezipierbare Unterstützung effizienter und sicherer erfüllt werden, z.B. durch Verwendung eines angemessenen Informationssystems. Ein solches Informationssystem kann damit Grundlage für die Entscheidungsfindung in komplexen Situationen sein. Nach Dörner (siehe [DKRS94]) sind Merkmale eines komplexen Systems die Anzahl der Variablen, die Vernetzung der Variablen, Intransparenz und eine Eigendynamik der Situation. Diese Eigenschaften treffen auf die Arbeitswelt der Feuerwehr zu. Daraus resultiert aber auch, dass ein Informationssystem für Einsatzkräfte der Feuerwehr durch die getroffenen Entscheidungen der Einsatzkräfte indirekt Einfluss auf die Umgebung und den Menschen in der entsprechenden Umgebung nimmt.

Die vorliegende Arbeit beschäftigt sich im Folgenden mit der Entwicklung und der Auswirkung auf die Entwicklung von sicherheits-kritischen Informationssystemen, also Systeme, die durch die Bereitstellung von Informationen Einfluss auf Entscheidungen von Menschen in sicherheits-kritischen Kontexten haben. Dazu wird in der Arbeit zwischen sicherheits-kritischen Systemen (SKS), sicherheits-kritischen Mensch-Maschine-Systemen (SKMMS) und sicherheitskritischen Informationssystemen (SKIS) unterschieden. „Unter einem Mensch-Maschine-System wird die zweckmäßige Abstraktion des zielgerichteten Zusammenwirkens von Personen mit technischen Systemen zur Erfüllung eines fremd- oder selbstgestellten Auftrags verstanden. Die allgemeine Struktur eines Mensch-Maschine-System ist die eines rückgekoppelten Systems, in dem ein Mensch oder ein Team entsprechend seiner organisatorischen Verankerung, seiner Zielstellung, des Auftrags und der wahrgenommenen Rückmeldung über Umgebung und Prozesszustand Entscheidungen fällt und das technische System steuert.“ [GiTi02] Des Weiteren definiert Johannsen (siehe [Joha93]) mindestens zwei notwendige Komponenten eines Mensch-Maschine-Systems:

• Den handelnden Menschen

• Die benutzbare Maschine

Ein sicherheits-kritisches Mensch-Maschine-System verursacht im Falle eines Schadensereignisses neben den hohen ökonomischen Auswirkungen für den Betreiber zusätzlich eine erhebliche Gefährdung von Mensch und auch Umwelt [Acat16].

Die nachfolgende Abbildung zeigt Zusammenhänge und Beispiele zu den in der vorliegenden Arbeit genannten Systemarten.

Quelle: Verfasser

Abbildung 1-1 Zusammenhänge zwischen Sicherheits-kritischen Systemen, Sicherheits-kritischen Mensch-Maschine-Systemen und Sicherheits-kritischen Informationssystemen

Bei der Entwicklung von SKS wird der Analyse und Berücksichtigung von Störfällen besondere Aufmerksamkeit geschenkt, da SKS auf die physische Umgebung direkt einwirken und daraus resultierend Schaden für das Umfeld und den Menschen hervorrufen können. Ein solcher Störfall wird in dem Kontext von SKS “Hazard” genannt. “A hazard is a state or set of conditions of a system (or an object) that, together with other conditions in the environment of the system (or object), will lead inevitably to an accident (loss event)” ([Leve01], S.177). Dazu werden in der Softwareentwicklung vier Phasen einbezogen: ”Hazard elimination“, ”Hazard reduction“, ”Hazard control“ und ”Damage minimization“ [BUOT11].

Im Gegensatz dazu stehen bei der Entwicklung von SKMMS die Usability und das Design der Benutzungsschnittstelle im Vordergrund.

Insbesondere im genannten Kontext der zivilen Gefahrenabwehr sind Aufgaben und Arbeitsabläufe komplex und es besteht die Anforderung des komplexen Problemlösens. Die Definition von Frensch und Funke (vgl. [FrFu95]) für komplexes Problemlösen zeigt verschiedene Dimensionen auf, die eine Unterscheidung des Problemlösers und damit eine individuelle Wahrnehmung von Komplexität induziert, wie „cognitive, emotional, personal, and social abilities and knowledge“. Dabei kann festgestellt werden, dass Komplexität ein subjektives Empfinden einer Person ist, denn „eine hohe Komplexität stellt hohe Anforderungen an die Fähigkeit des Akteurs, Informationen zu sammeln, zu integrieren und Handlungen zu planen“ [Dörn11].

Um das Zusammenspiel zwischen Systemen und Menschen zu verdeutlichen, mit besonderer Berücksichtigung von Auswirkungen im Fehlerfall, wurde hier ein Use Case basierter Ansatz verfolgt, um entsprechende Anwendungsfälle zu identifizieren und potentielle Fehler und Fehlerursachen aufzuzeigen (vgl.[DePB03]). Die gesammelten Use Cases und potentielle Nutzungsprobleme wurden analysiert. Ein Auszug aus dem Resultat der Analyse von Use Cases eines entscheidungsunterstützenden Informationssystems wird in der anschließenden Abbildung dargestellt. Die Pfeile in der Abbildung sollen den Verlauf der Analyse verdeutlichen.

Quelle: Verfasser

Abbildung 1-2 Auswertung der Use Cases eines entscheidungsunterstützenden Informationssystems

Einfache Use Cases wie „Informationen suchen“ können schon eine Vielzahl an Nutzungs-problemen hervorrufen, die damit Auswirkung auf Gesundheit und Leben von Menschen nehmen, wie in der Abbildung 1-2 verdeutlicht.

Für die vorliegende Arbeit stellt sich damit die Frage, wie risikobasierte Ansätze aus der Entwicklung von SKS, die potentielle Störfälle in den Mittelpunkt stellen, und Lösungswege aus dem Usability Engineering, die den Mensch fokussieren, angemessen zu kombinieren sind.

Die Zusammenhänge sind in der nachfolgenden Abbildung näher aufgeführt. Methoden, z.B. aus dem Usability Engineering, sind im inneren Kreis visualisiert und sind Basiselemente, die bereits aus verschiedenen Forschungsergebnissen vorliegen. Diese sollen entsprechend variiert und in den Entwicklungsprozess von SKIS eingebettet werden (mittlerer Kreis). Umfasst werden die Entwicklungsschritte von Elementen der Risikoanalyse (äußerer Kreis), die weitere relevante Grundlagen liefern, zurzeit aber nicht in die Entwicklungsparadigmen eingebettet sind. Ziel muss es daher sein, die vorhandenen Entwicklungsmuster folgerichtig zusammenzuführen und eine wechselseitige Vernetzung zu erzeugen.

Quelle: Verfasser

Abbildung 1-3 Zusammenhang der Entwicklungsmuster der betrachteten Systemklassen

1.2 Zielsetzung und Vorgehen

“Because software is like all capital, is embodied knowledge, and because that knowledge is initially dispersed, tacit, latent, and incomplete in large measure, software development is a social learning process. The process is a dialog in which the knowledge that must become the software is brought together and embodied in the software. The process provides interaction between users and designers, between users and evolving tools, and between designers and evolving tools [technology].” ([Baet98], S. 20)

Baetjer versteht Software als verkörpertes Wissen, entstanden aus der Interaktion zwischen Nutzer, Designer und involvierten Werkzeugen. In der vorliegenden Arbeit wird zusätzlich das Risiko, das in der Interaktion entstehen kann oder der Nutzung der Software als weitere Größe in Betracht gezogen.

Ziel der Arbeit ist es somit, den Kontext und die Anforderungen der Arbeitswelt „zivile Gefahrenabwehr“ mit den Methoden und Entwicklungsansätzen von SKMMS und SKS in Beziehung zu setzen und ein optimiertes Verfahren für die Entwicklung der Systemklasse SKIS abzuleiten. Darüber hinaus sollen geeignete Maßnahmen zum Safety Assessment in den Entwicklungsphasen eines Informationssystems zum Lösen komplexer Probleme in der zivilen Gefahrenabwehr erarbeitet werden. Dabei stellt ein Safety Assessment eine Risikoüberprüfung und Beurteilung von Entwicklungsständen dar, in Bezug auf den zu erwartenden Anwendungskontext. Dazu soll im Folgenden ein Beispiel aus der Luftfahrt gegeben werden, sodass Risiken und Ursachen von Störfällen mit SKMMS aufgezeigt werden.

Fallbeispiel SKMMS (siehe [Bund02]) - Durch einen Zusammenstoß zweier Flugzeuge in 11.000 m Höhe ist im Jahr 2002 ein folgenschwerer Absturz verursacht worden – Der Absturz ist sowohl auf menschliches wie auch technisches Versagen zurückzuführen. Das Annäherungswarnsystem veranlasste eine rechtzeitige optische und akustische Warnung. Jedoch wurden widersprüchliche Angaben vom zuständigen Fluglotsen getätigt. Zudem lag ein erhöhter Stresspegel und Überlastung auf Seiten der Piloten und der Lotsen vor, sodass es zu dem entstandenen Fehler kam. Darüber hinaus bestand bei den Beteiligten ein geringes Vertrauen in das System, da aufgrund von Fehlalarmen die Bedeutung der Warnung unterschätzt und letztlich auf die Angaben des Fluglotsen vertraut wurde.

Die Luftfahrt bietet prägnante Beispiele für SKMMS. Gordon Dupont [Dupo17] stellt nach umfassender Analyse von Unfällen in der Luftfahrt mit seinen „Dirty Dozen“ Ursachen für diese Fehler auf, findet jedoch maßgeblich menschliche Ursachen:

• Lack of communication (mangelnde Kommunikation)

• Complacency (Selbstgefälligkeit)

• Lack of Knowledge (Fehlendes Wissen)

• Distraction (Ablenkung)

• Lack of Teamwork (Fehlende Zusammenarbeit)

• Fatigue (Müdigkeit)

• Lack of Resources (Fehlende Ressourcen)

• Pressure (psychischer und zeitlicher Druck)

• Lack of Assertiveness (Fehlendes Durchsetzungsvermögen)

• Stress (Stress)

• Lack of Awareness (Fehlende Übersicht)

• Norm (Standardisierung, ungeschriebene Regeln)

Die aufgeführte Liste stellt auch potentielle Risiken dar, die in der Entwicklung von neuen Systemen Berücksichtigung finden sollten, damit während der Nutzung die Fehlerrate reduziert werden kann.

Darüber hinaus zeigt das vorangegangene Beispiel deutlich die Probleme in der Automatisierung von Arbeitsabläufen und dem Zusammenspiel von Mensch und Technik. Vielfach müssen Menschen nur noch überwachende Tätigkeiten ausführen, sollen dann aber in Störungssituationen eingreifen und spontan folgerichtig handeln. Der Mensch muss so in schwierigen Fällen die Aufgaben erledigen, die sonst eine Maschine oder System übernimmt. Das Wissen über den Umgang mit dem System ist dann jedoch reduziert, da eine geringere Häufigkeit der Nutzung festzustellen ist [BaHL12]. Dieses Phänomen ist ebenfalls in der Luftfahrt vorzufinden, z.B. seit der Einführung des Autopiloten. Auch Herczeg (siehe [Herc14]) führt aus, dass ein durchdachtes Zusammenspiel zwischen menschlicher Kontrolle und technischer Automatisierung zu beachten ist.

Die zivile Gefahrenabwehr ist dazu differenziert zu betrachten. Eine vollständige Automatisierung ist auszuschließen, aber die Unterstützung durch Technologien und demnach auch durch Informationssysteme steigt stetig. Auf diese Weise rückt die Bedeutung von SKIS in den Mittelpunkt der Arbeit als eine Systemklasse, die nicht direkt in das Umfeld des Menschen eingreift, aber durch die Informationsbereitstellung weitreichend Einfluss nehmen kann.

Die Arbeit setzt folgerichtig drei Phasen für die Zielerreichung voraus: Es werden Entwicklungsmethodiken zur Entwicklung von SKIS analysiert und dabei auch Verfahren zur Entwicklung von SKS betrachtet, ein Methodenportfolio erstellt und daraus Vorgehensempfehlungen abgeleitet, um ein nachhaltiges Safety Assessment zu etablieren, siehe Abbildung 1-4.

Quelle: Verfasser

Abbildung 1-4 Relevante Themen in der Arbeit

Zur systematischen Identifikation von Potentialen und Bedarfen werden Schritt 1 und Schritt 2 aus Abbildung 1-4 weiter untergliedert:

Zu Schritt 1: Systementwicklung

1. Entwicklungsmethodik für SKS

2. Entwicklungsmethodik für Mensch-Maschine-Systeme

Zu Schritt 2: Methodenbaukasten

1. Wissen des Designers und Entwicklers über den Nutzer erhöhen:

• Methoden und Kreativtechnik zur Analyse (vgl. z.B. [PoRu15])

• Methoden des Usability Engineering’s (vgl. z.B. [Niel93])

2. Wissen der Einsatzkräfte selbst durch und über das System erhöhen:

• Methoden des Wissensmanagements (vgl. z.B. [Lehn14])

• Methoden des Lernens

3. Den Nutzer als Individuum in der Entwicklung anerkennen und das „Wissen des Systems“ über den Nutzer erhöhen:

• Methoden der Individualisierung und Benutzermodellierung (vgl. z.B. [Kobs04])

Alle aufgeführten Klassen von Methoden ermöglichen eine zielgerichtete Gestaltung von SKIS und bedürfen einer Prüfung und Adaption auf den beschriebenen Kontext. Zudem können darüber Eingangsgrößen für einen Safety Assessment Process gewährleistet werden. Insgesamt soll eine risikobewusste Entwicklung von SKIS ermöglicht werden.

Zur Erreichung des Ziels wird für die Arbeit folgendes Vorgehen festgelegt:

• Zunächst sollen bestehende Problem- und Bedarfsanalysen durchgeführt werden, um den Rahmen der Arbeit zu fixieren. In Kapitel 2 werden vom Verfasser Praxisbeispiele aufgeführt, die verschiedene Problemstellungen im Umgang mit SKIS darstellen. Zusätzlich werden in Kapitel 3 relevante Grundlagen zur Softwareentwicklungsparadigmen wie auch Methoden des Usability Engineerings, Benutzermodellierung und Wissensmanagements erarbeitet, sodass insgesamt ein Handlungsbedarf bestimmt werden kann (Kapitel 4).

• Auf Basis der Ergebnisse aus Kapitel 2, 3 und 4 sollen dann Indikatoren und Einflussgrößen in der zivilen Gefahrenabwehr erhoben werden, die grundsätzliche Risikopotentiale beinhalten (Kapitel 5).

• Damit kann dann anschließend ein valides Konzept zur Integration eines Safety Assessment in die Entwicklung von SKIS aufgebaut (siehe Kapitel 6) und evaluiert werden (siehe Kapitel 7). Die genannten Methoden wurden vom Verfasser im Zusammenhang zur zivilen Gefahrenabwehr durchgeführt, der überwiegende Teil bezieht sich also auf die Entwicklung von SKIS für die zivile Gefahrenabwehr. Zusätzlich wurden aber auch Methoden aufgeführt, die für die Analyse von Systemen oder zur Erhebung von Anforderungen genutzt wurden, die als Endanwender nicht Einsatzkräfte der zivilen Gefahrenabwehr haben, sich aber im Kontext auch auf Vorgänge in der zivilen Gefahrenabwehr beziehen, z.B. Systeme, die den Selbstschutz von Bürgern erhöhen sollen.

Das Vorgehen in der vorliegenden Arbeit wird in Abbildung 1-5 gezeigt.

Quelle: Verfasser

Abbildung 1-5 Vorgehen in der Arbeit