Logo weiterlesen.de
Entwicklung eines Vorgehens zum Safety Assessment fürsicherheits-kritische Informationssysteme in der zivilen Gefahrenabwehram Beispiel der Feuerwehr

Christina Schäfer

Entwicklung eines Vorgehens zum
Safety Assessment für sicherheits-kritische
Informationssysteme in der
zivilen Gefahrenabwehr
am Beispiel der Feuerwehr

Entwicklung eines Vorgehens zum
Safety Assessment
für sicherheits-kritische Informationssysteme
in der zivilen Gefahrenabwehr
am Beispiel der Feuerwehr

zur Erlangung des akademischen Grades
DOKTOR DER INGENIEURWISSENSCHAFTEN (Dr.-Ing.)
der Fakultät für Maschinenbau
der Universität Paderborn

genehmigte
DISSERTATION

von
Dipl.-Inf. Christina Schäfer
aus Bochum

Tag des Kolloquiums: 05. Dezember 2018

Referent:          Prof. Dr.-Ing. Rainer Koch

Korreferent:      Prof. Dr. Gerd Szwillus

Zusammenfassung

Informationssysteme erhalten in der heutigen Zeit immer mehr Bedeutung in unterschiedlichsten Berufszweigen. Insbesondere in sicherheits-kritischen Kontexten werden Aufgaben durch Informationstechnologien übernommen oder unterstützt.

Die vorliegende Arbeit zielt auf eine Analyse des Entwicklungsprozesses von sicherheits-kritischen Informationssystemen und eröffnet Möglichkeiten erhöhte Sicherheitsstrukturen in bestehende Prozesse zu integrieren. Zunächst wurden Indikatoren bezüglich des Risikos in der Entwicklung von Informationssystemen in der zivilen Gefahrenabwehr ermittelt und mit bestehenden Ansätzen verglichen. Darauf aufbauend wurde zum einen ein Safety Assessment als paralleler Entwicklungszweig festgelegt und zum anderen ein Methodenkatalog für den Kontext der zivilen Gefahrenabwehr erstellt. Methoden wurden im Kontext angewendet und auf ihren Beitrag zum Safety Assessment geprüft.

Summary

Information systems are becoming more and more important in a wide variety of occupations today. In particular in safety-critical contexts, tasks are taken over or supported by information technologies.

The presented work provides an analysis of the development process of safetycritical information systems and opens possibilities to integrate increased safety structures into existing processes. First, indicators on civil safety information systems were identified and compared with existing approaches. Based on this, on the one hand, a Safety Assessment was defined as a parallel development process, and on the other hand, a method portfolio for the context of civil safety was created. Methods were applied in context and tested for their contribution to the Safety Assessment.

Vorwort und Danksagung

„Derjenige, der etwas zerbricht, um herauszufinden, was es ist, hat den Pfad der Weisheit verlassen.“ (J.R.R. Tolkien)

Die vorliegende Dissertation versucht einen Pfad für die Entwicklung von sicherheits-kritischen Informationssystemen zu schaffen, der eine gebrauchstaugliche Anwendung der Systeme in der zivilen Gefahrenabwehr schafft, ohne dass etwas „zerbricht“. Die Arbeit wurde im Rahmen meiner Tätigkeiten als Wissenschaftliche Mitarbeiterin in der Arbeitsgruppe „Computeranwendung und Integration in Konstruktion und Planung“ verfasst. Dazu war es mir möglich in verschiedene Forschungsprojekte Einblick zu erhalten, zu lernen und selbst zu gestalten. Dafür möchte ich besonders Dank an meinen Doktorvater Herrn Prof.-Dr.-Ing. Rainer Koch richten, für die Teilhabe in einem spannenden Forschungsfeld, die Betreuung meiner Arbeit und viele anregende Gespräche. Zusätzlich möchte ich meinen Dank an Herrn Prof. Dr. Gerd Szwillus ausdrücken, der maßgeblich meinen Start in das Themenfeld begleitet hat. Darüber hinaus hat der stets interessante Diskurs mit Kollegen und Freunden meine Arbeit geprägt, sodass ich sie hier nicht unerwähnt lassen möchte. Dass die vorliegende Arbeit letztlich fertiggestellt wurde, verdanke ich aber maßgeblich meiner Familie, die mich bestärkt, an mich geglaubt und mir immer wieder Mut gemacht hat, weiterzumachen. Dabei möchte ich insbesondere meinem Mann Daniel Schäfer, meinen Kindern Janina und Jonah und meinen Eltern Udo und Andrea Reck danken.

Damit bleibt: Es gilt mein Dank allen, die mich auf meinem Pfad hierhin begleitet haben!

Paderborn, den 12.12.2018

Christina Schäfer

Teile dieser Arbeit sind in folgenden Dokumenten vorveröffentlicht

• POTTEBAUM, J.; SCHÄFER, C.: IT-Systeme für das Krisenmanagement. In: Sicherheitskritische Mensch-Computer-Interaktion. Wiesbaden : Springer Fachmedien Wiesbaden, 2018, S. 253–276

• ZINKE, R.; KÜNZER, L.; SCHRÖDER, B.; SCHÄFER, C.: Integrating Human Factors into Evacuation Simulations - Application of the Persona Method for Generating Populations. Analytical Modeling and. In: Simulation Proceedings of the 14th ISCRAM Conference, 2017

• SCHAFER, C.; SAUERLAND, T.; POTTEBAUM, J.; MARTERER, R.; BEHNKE, D.; WIETFELD, C.; GRAY, P.; DESPOTOV, B.: Cloud-based semantic services for pan-European emergency preparation and planning. In: 2017 Annual IEEE International Systems Conference (SysCon) : IEEE, 2017 — ISBN 978-1-5090-4623-2, S. 1–7

• POTTEBAUM, J.; SCHAFER, C.; KUHNERT, M.; BEHNKE, D.; WIETFELD, C.; BUSCHER, M.; PETERSEN, K.: Common information space for collaborative emergency management. In: 2016 IEEE Symposium on Technologies for Homeland Security (HST) : IEEE, 2016 — ISBN 9781-5090-0770-7, S. 1–6

• SCHÄFER, C.; ZINKE, R.; KÜNZER, L.; HOFINGER, G.; KOCH, R.: Applying Persona Method for Describing Users of Escape Routes. In: Transportation Research Procedia Bd. 2 (2014), S. 636–641

• SCHÄFER, C.; KÜNZER, L.; ZINKE, R.: Intergation und Modellierung von menschlichen Faktoren für die Evakuierung von U-Bahn-Systemen. In: Proceedings of the INFORMATIK 2013. Koblenz, 2013

• FRIBERG, T.; SCHÄFER, C.; KOCH, R.: Methodology for Analysing Unstructured Usability Evaluation Data. In: . Berlin, Heidelberg : Springer, 2012, S. 249–260

• LINDEMANN, C. ; SCHÄFER, C. ; KOCH, R.: Requirements of Knowledge-Management in Industrial Organisations and the Sector of Public Safety and Security: Same or Different? In: Proceedings of the 8th International Conference on Intellectual Capital, Knowledge Management & Organisational Learning – ICICKM (2011)

• SCHÄFER, C ; POTTEBAUM, J ; LÖKEN, J ; und R. und KOCH: Geo-Entscheidungsunterstützung für die ABC-Gefahrenabwehr. In: Geoinformatik 2010. Kiel : Geoinformatik, 2010.

• RECK, C.: Entwicklung eines Konzepts zur modellbasierten Fehlerdiagnose. Informatiktage 2009, März 2009.

Inhaltsverzeichnis

Einleitung

1.1 Motivation und Problemstellung

1.2 Zielsetzung und Vorgehen

Handlungsbedarf – Nutzungsperspektive

2.1 Bedarf an IT-Unterstützung im Problemlösungsprozess zur Erhöhung des Wissens von Akteuren in der zivilen Gefahrenabwehr

2.2 Erfahrung und die Bedeutung des Wissens des Designers / Entwicklers über den Nutzer

2.3 Benutzerspezifische Qualitätseigenschaften

Grundlagen

3.1 Vorgehensmodelle zur Softwareentwicklung und die Einbeziehung des Benutzers

3.2 Wissen des Designers und Entwicklers über den Nutzer erhöhen

3.2.1 Aufgabenanalyse (Task-Analysis)

3.2.2 Zielanalyse

3.2.3 Szenario-Analyse

3.3 Wissen der Einsatzkräfte selbst durch und über das System erhöhen

3.3.1 Prototyping

3.3.2 Schulung und E-Learning

3.3.3 Wissensmanagement

3.3.3.1 Lessons Learned

3.3.3.2 Wissenskarten

3.4 Den Nutzer als Individuum/Rolle in der Entwicklung anerkennen und abbilden

3.4.1 Wissensakquise über den Benutzer

3.4.2 Benutzermodell und Gruppen-Benutzermodell

3.4.3 Mögliche Inhalte eines Benutzermodells

3.4.4 Repräsentation und Auswertung des Benutzermodells

Anpassung des Handlungsbedarfs

4.1 Entwicklungsmethodik

4.2 Methodenkatalog

Ermittlung von Risiko-Indikatoren für sicherheits-kritische Informationssysteme am Beispiel der Feuerwehr

5.1 Analyse von Feuerwehrstrukturen

5.1.1 Fazit zur Analyse der Feuerwehrstrukturen

5.2 Sichtung durchgeführter Analysen

5.2.1 Szenarien und Use Case

5.2.2 Sichtung von Anforderungen

5.2.2.1 Vergleich mit anderen Projektergebnissen

5.3 Vergleichende Literatur

5.4 Zusammenstellung der Indikatoren

Implikationen für die Entwicklung von sicherheits-kritischen Informationssystemen

6.1 Adaption des Softwareentwicklungsprozesses

6.1.1 Methoden in der Analyse

6.1.1.1 Erhebungsmethoden

6.1.1.2 Kreativmethoden

6.1.1.3 Analysemethoden

6.1.2 Methoden im Design und in der Implementierung

6.1.3 Methoden in der Evaluation

6.2 Wechselseitige Beziehung zwischen SAP und SDP

6.2.1 Auszug einer Hazard Analysis

6.3 Veröffentlichung eines Methodenkatalogs

Bewertung der Ergebnisse

Fazit

8.1 Zusammenfassung

8.2 Ausblick

Literaturverzeichnis

9.1 Unveröffentlichte Arbeiten

9.2 Studentische Arbeiten

10 Anhang

Verzeichnis der Abkürzungen

AAO

Alarm- und Ausrücke-Ordnung

ABC

Atomar, Biologisch, Chemisch

ABC-ErkKW

ABC- Erkunderkraftwagen

AKNZ

Akademie für Krisenmanagement, Notfallplanung und Zivilschutz

ANYWHERE

EnhANcing emergencY management and response to extreme
WeatHER and climate Events

AirShield

Airborne Remote Sensing for Hazard Inspection by Network-Enabled Lightweight Drones

BBK

Bundesamt für Bevölkerungsschutz und Katastrophenhilfe

BMBF

Bundesministerium für Bildung und Forschung

BPEL

Business Process Execution Language

BPM

Business Process Management

bzw.

beziehungsweise

CBRN

Chemisch, Biologisch, Radiologisch und Nuklear

CIS

Common Information Space

DSS

Decision Support System

EAL

Einsatzabschnittsleiter

EPK

Ereignisgetriebene Prozessketten

FHA

Failure Hazard Analysis

FMEA

Fehlermöglichkeits- und -einflussanalyse

FwDV

Feuerwehrdienstvorschrift

GDT

Goal-Directed-Taskanalysis

GIS

Geo-Informationssystem

GOMS

Gesamtziel, Operatoren, Methoden, Selektionsregeln

GUI

Graphical User Interface

HW

Hardware

IS

Informationssystem

IT

Informationstechnologie

JPDL

jBPM Process Definition Language

LL

Lessons Learned

MEA

Means-End Analysis

OrGaMIR

Organisationsübergreifende Gefahrenabwehr zum Schutz von Menschen und kritischen Infrastrukturen durch optimierte Prävention und Reaktion

OWL

Web Ontology Language

PSSA

Preliminary System Safety Analysis

QoC

Quality of Context

RDF

Resource Description Framework

SA

Situation Awareness

SAP

Safety Assessment Process

SDP

System Development Process

SecInCoRe

Secure Dynamic Cloud for Information, Communication and Resource
Interoperability based on Pan-European Disaster Inventory

SKIS

Sicherheits-kritisches Informationssystem

SKMMS

Sicherheits-kritisches Mensch-Maschine-System

SKS

Sicherheits-kritisches System

SSA

System Safety Analysis

SW

Software

TEL

Technische Einsatzleitung

UAV

Unmanned Air Vehicle

u.U.

unter Umständen

z.B.

zum Beispiel

Abbildungsverzeichnis

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

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

Abbildung 1-3 Zusammenhang der Entwicklungsmuster der betrachteten Systemklassen

Abbildung 1-4 Relevante Themen in der Arbeit

Abbildung 1-5 Vorgehen in der Arbeit

Abbildung 2-1 Zusammenhang zwischen Risiko und Problem

Abbildung 2-2 Prozess zur Problemlösung in Anlehnung an den Risikomanagementprozess gemäß ISO 31000

Abbildung 2-3 Zusammenhänge zwischen Problemlöser, Kontext und Aufgabe

Abbildung 2-4 Detaillierter Problemlösungsprozess

Abbildung 2-5 Stakeholder Analyse

Abbildung 2-6 Beispiel Ursachen-Wirkungs-Diagramm

Abbildung 2-7 Störungsbehebungsprozess

Abbildung 2-8 Gesamtsystem AirShield

Abbildung 2-9 Verteilung der Aussagen zur Kapselung auf Rollen

Abbildung 2-10 Anforderung einer Maßnahme

Abbildung 2-11 Prozess der Maßnahmenbearbeitung

Abbildung 2-12 Benutzungsschnittstelle zur Entscheidungsunterstützung

Abbildung 2-13 Angaben der Probanden zum Prozess in Bezug zu ihrer Rolle

Abbildung 3-1 Relevante Themen bezogen auf Kapitel 3

Abbildung 3-2 Studie zu Hindernissen und Schwierigkeiten in der Softwareentwicklung von Forrester Consulting 2013

Abbildung 3-3 User Centred Design Process

Abbildung 3-4 Goal-Directed Design Process nach Alan Cooper

Abbildung 3-5 Wechselwirkung zwischen Nutzer, Aufgabe und Informationssystem

Abbildung 3-6 Wissensmanagementmodell nach Probst

Abbildung 3-7 Benutzermodellierungs-Prozess

Abbildung 3-8 Inhalte von Benutzermodellen

Abbildung 3-9 Persona Ontologie

Abbildung 4-1 Zusammenhänge zwischen verschiedenen Entwicklungsmethodiken

Abbildung 5-1 Relevante Themen in Kapitel 5

Abbildung 5-2 Vorgehen zur Identifizierung von Indikatoren

Abbildung 5-3 Brand in einer Recyclinganlage in Bochum [Quelle: www.notfallinfo.de]

Abbildung 5-4 Zusammenhänge von Fehlerursachen

Abbildung 5-5 Softwarequalität nach ISO 9126

Abbildung 5-6 Benutzbarkeit als Merkmal in der Analyse von Anforderungen

Abbildung 5-7 Situational Awareness Model von Endsley

Abbildung 5-8 Zeitverhalten als Merkmal in der Analyse von Anforderungen

Abbildung 5-9 Zusammenhänge zwischen den Indikatoren

Abbildung 6-1 Relevante Themen in Kapitel 6

Abbildung 6-2 „Safety Assessment Process“ und „System Development Process“ nach SAE ARP 4761 und SAE ARP 4754

Abbildung 6-3 Anpassung im Safety Assessment Process und System Development Process

Abbildung 6-4 Komponenten des Risikos

Abbildung 6-5 Methoden in der Analyse

Abbildung 6-6 Workshop-Ergebnisse aus dem Projekt SecInCoRe

Abbildung 6-7 Intervallspanne für Gruppenzugehörigkeit

Abbildung 6-8 Intervallspanne für Ortskenntnis

Abbildung 6-9 Hauptziele zur Nutzung von Software zur Erhöhung des Selbstschutzes

Abbildung 6-10 Weitere Zielanalyse zur Erhöhung

Abbildung 6-11 Auszug der Prozessanalyse im Projekt AirShield

Abbildung 6-12 Methoden im Design und in der Implementierung

Abbildung 6-13: Erster GUI-Demonstrator für die Komponente DSS

Abbildung 6-14: GUI-Prototyp

Abbildung 6-15: Erster Demonstrator des DSS

Abbildung 6-16: DSS-Client

Abbildung 6-17: Anzeige zusätzlicher Informationen zum Gefahrstoff

Abbildung 6-18 Erhöhung des Reifegrades während der Entwicklungszeit

Abbildung 6-19 Methoden in der Evaluation

Abbildung 6-20 Wechselwirkung zwischen SAP und SDP

Abbildung 6-21 Ergebnis der Evaluation des Projekts AirShield bezogen auf die Information

Abbildung 6-22 Aufbau einer Maßnahme

Abbildung 6-23 Abhängigkeiten zwischen dem Ereignis „falsche Informationen wurden bereitgestellt“ und deren Ursache und Wirkung

Abbildung 6-24 Auszug der Prozessanalyse in dem BMBF Projekt AirShield

Abbildung 6-25 Portfolio der Risiken

Abbildung 6-26 Methodenkatalog im ANYWHERE CIS

Abbildung 6-27 Methode Scenario-based Interview im ANYWHERE CIS

Abbildung 7-1 Zusammenhang zwischen Projekt und verwendeter Methode

Abbildung 10-1 Einzelne Faktoren im Entscheidungsfindungsprozess

Abbildung 10-2 Drei Dimensionen der Heterogenität von Konzepten einer Ontologie

Abbildung 10-3 Elemente der SecInCoRe Taxonomie

Abbildung 10-4 Semantische Suche

Abbildung 10-5 Visualisierung der GraphView

Tabellenverzeichnis

Tabelle 3-1 Techniken zur impliziten Informationserfassung über den Nutzer [Quelle: siehe [GSCM07

Tabelle 4-1 Für die Arbeit erfasste Guidelines

Tabelle 4-2 Guidelines in Kategorien zusammengefasst

Tabelle 5-1 Anfordern von entscheidungsunterstützenden Informationen

Tabelle 5-2 Planen einer Flugroute

Tabelle 5-3 Design Prinzipien nach Endsley [EnJo17]

Tabelle 6-1 Zielformulierung [Quelle: Verfasser]

Tabelle 6-2 Methoden Schablone [Quelle: Verfasser]

Tabelle 6-3 Methode Beobachtung [Quelle: Verfasser]

Tabelle 6-4 Methode Brainstorming / Mindmapping [Quelle: Verfasser]

Tabelle 6-5 Methode Clustering [Quelle: Verfasser]

Tabelle 6-6 Methode Personas [Quelle: Verfasser]

Tabelle 6-7 Methode Zielanalyse [Quelle: Verfasser]

Tabelle 6-8 Methode Prozessanalyse [Quelle: Verfasser]

Tabelle 6-9 Methode Prototyping [Quelle: Verfasser]

Tabelle 6-10 Methode Interview [Quelle: Verfasser]

Tabelle 6-11 Generische, potentielle Risiken bezogen auf relevante Informationen für die Entwicklung von SKIS [Quelle: Verfasser]

Tabelle 6-12 Schwere von Unfallklassen in militärischen Systemen [siehe auch [Stor96

Tabelle 10-1 Methode Regelbasiertes Benutzermodell [Quelle: Verfasser]

Tabelle 10-2 Meethode Ontologie [Quelle: Verfasser]

Tabelle 10-3 Methode Wissenskarten [Quelle: Verfasser]

Tabelle 10-4 Auswertung Anforderungsanalysen

Tabelle 10-5 Design-Prinzipien nach Endsley [EnJo17]

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

Handlungsbedarf – Nutzungsperspektive

Ein Handlungsbedarf ergibt sich zum einen aus identifizierten Lücken im aktuellen Stand der Technik und zum anderen aus beobachtbaren Problemen in der entsprechenden Domäne.

An dieser Stelle setzt Kapitel 2 an und diskutiert beobachtete bzw. identifizierte Probleme aus der Domäne „zivile Gefahrenabwehr“ bzw. aus der Nutzung von SKIS, sodass ein erster Handlungsbedarf abgeleitet werden kann. Dazu legt Kapitel 2.1 erste Grundsteine zur Definition von Problemen und Komplexität in der besagten Domäne. Darüber hinaus werden die Rolle von Erfahrung und Wissen zum Problemlösen beschrieben und schließlich individuelle Faktoren in der Systemgestaltung identifiziert.

Zur Einordnung des Handlungsbedarfs werden im Verlauf des Kapitels Annahmen (Annahme 1 bis Annahme 6) in Bezug zur Entwicklung und Nutzung von SKIS aufgestellt. Die Annahmen werden in Kapitel 4 wieder aufgegriffen, um den Handlungsbedarf mit dem Hintergrund des Stands der Technik zu vervollständigen. Diese Annahmen basieren auf den identifizierten Bedarfen, die im Folgenden vorgestellt werden.

Der Handlungsbedarf wird hier in zwei Aspekten aufgezeigt:

• Zunächst soll ein grundsätzlicher Bedarf der IT-Unterstützung und Potentiale für SKIS auch in komplexen Situationen aufgezeigt werden (siehe Kapitel 2.1)

• Neben dem grundsätzlichen Potential an IT-Unterstützung stehen bereits identifizierte Probleme in der Nutzung. Hier sollen in den folgenden Kapiteln 2.2 und 2.3 Beispiele aufgeführt werden, die zum einen den Differenzierungsbedarf zwischen einzelnen Nutzern, insbesondere mit Berücksichtigung von unterschiedlichen Wissens- und Erfahrungsständen, in den Mittelpunkt stellen (siehe Kapitel 2.2 und 2.3)

2.1 Bedarf an IT-Unterstützung im Problemlösungsprozess zur Erhöhung des Wissens von Akteuren in der zivilen Gefahrenabwehr

Probleme lassen sich im Allgemeinen mit dem „Kopf“ oder dem „Bauch“ lösen und insbesondere mit wachsender Erfahrung kann der „Bauch“ zur Entscheidungsfindung und so zur Problemlösung beitragen [Bund12].

Nicht immer ermöglicht der Handlungsrahmen (z. B. eines Feuerwehreinsatzes) die nötige Zeit für lang andauernde Analysen. Speziell Akteure, die SKIS in komplexen Kontexten verwenden, müssen schnell und effektiv auf Unerwartetes reagieren und dabei in einer risikobehafteten Umgebung nahezu fehlerfrei agieren, da ein Fehlverhalten der Akteure schwerwiegende Auswirkungen haben kann. [Mist05] Daraus kann folgende Annahme abgeleitet werden:

Annahme 1:. Fehler im Umgang mit zeit- und sicherheits-kritischen Informationssystemen verursachen gravierende Folgen für den Menschen und das Umfeld.

Im Folgenden werden Eigenschaften und Definitionen von Komplexität sowie Problemen dargestellt, um ein grundlegendes Verständnis für die vorliegende Arbeit zu bilden und den Bedarf an IT-Unterstützung bzw. der Nutzung von SKIS im Problemlösungsprozess aufzuzeigen.

Wohland und Wiemeyer (siehe [WoWi07]) beschreiben die Differenz zwischen kompliziert und komplex wie folgt: “Mit Wissen kann man komplizierte Aufgaben lösen, aber nur mit Können kann man komplexe Aufgaben lösen.&

Wollen Sie wissen, wie es weiter geht?

Hier können Sie "Entwicklung eines Vorgehens zum Safety Assessment für sicherheits-kritische Informationssysteme" sofort kaufen und weiterlesen:

Amazon

Apple Books

ebook.de

Thalia

Weltbild

Viel Spaß!



Kaufen