Ebba Thora Hvannberg , Jan Rudinsky University of Iceland [email protected]
description
Transcript of Ebba Thora Hvannberg , Jan Rudinsky University of Iceland [email protected]
The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement n° FP7-242474.
Crisis management training: Techniques for elicitingand describing requirements and early designs acrossdifferent incident types
Ebba Thora Hvannberg, Jan RudinskyUniversity of [email protected]
©2011 CRISIS All rights reserved
Crisis management is the core of response to serious accidents, such as train incidents, plane crashes and bomb threats
The challenges are variability of available resources, surroundings and context of work, high demand for synchronization and decision making, and time criticality
Training a system of crisis management is performed in large exercises where an accident and its response are simulated butin a real environment.
Crisis Management Training
©2011 CRISIS All rights reserved
Virtual environment The objective of the CRISIS project is to develop an virtual
environment which enables responders and commanders to train for crisis management
A training and simulation environment that will focus on real-time decision making and response to simulated but realistic crises or critical incidents, focusing primarily on problem diagnosis, planning, re-planning, and acting, rather than just procedural training or familiarity with policies;
©2011 CRISIS All rights reserved
Major incident cases
Id Location Incident Description
AI1 Iceland Aircraft incident An aircraft accident when engine failure caused crash landing
AI2 Portugal Aircraft incident An aircraft accident when engine failure caused crash landing
BT3 Portugal Bomb threat A man-made incident of a bomb located in an airport building
TC4 UK Train crash A train and a vehicle collision on a crossing due to signaling damage
From the developers’ perspective, a major challenge is to tailor the system to differentscenarios
©2011 CRISIS All rights reserved
Consolidation of different scenariosGetting more details from different scenarios and abstracting to
provide developers with the common factors in the software system
Tailor the system to a broader market, resulting in a valuable product
Recent interest in domain specific languages is a motivation to describe domain knowledge in generic models
©2011 CRISIS All rights reserved
Data CollectionSource Material collected AI1 AI2 BT3 TC4
Site visit with crisis managers Presentation and unstructured interview x x x
Meeting notes x x x xPhotos x x
End-user workshop Meeting notes and transcription from semi-structured interviews
x x x
Written description about work and systems
Manuals and emergency procedures x x x
Table-top exercise Photos and videos x
Large-scale exercise Photos and videos xTable 2. Material collected from stakeholders for each incident case
©2011 CRISIS All rights reserved
A development process model - Benyon
Design Constraints
Abstraction Formalize Design
Stories ConcreteScenarios
ConceptualScenarios
Usecases
Envisioning and
Evaluation
Imple-ment-ation
Under-standing
Gener-ating ideas
©2011 CRISIS All rights reserved
Understanding tasks, people, contexts
11:17 Rendezvous Point (RV) is established at the …………………
All units must report to the Transport Coordinator (TC) at the RV Units are only allowed to proceed to the scene once the Rescue Coordinator (RC)
permits entry11:17 Casualty Assembly Point (CAP) is established at the ………………..
The location must be defined and clearly marked Triage tables must be set up There will be four separate areas:
o Triage for sorting the injured into groups based on their injuries and requirement for medical treatment
o Priority 1 being life threatening injuries requiring immediate attention (RED)
o Priority 2 being non-life threatening injuries (YELLOW)o Priority 3 being minor injuries; classed as Walking Wounded (GREEN)
©2011 CRISIS All rights reserved
Second scenario - Bomb13.10h The evaluation commission decides to validate the threat.
Airport Emergency and Evacuation Plan is activated, an Emergency Operations Command is set up and Airport internal rescue means are deployed.
13.22h Evacuation of the Terminal. Who else does the DO have to speak to in order to action this?Who else should be informed at the airport?How do you make members of the public follow the procedures and not to disrupt the operation
©2011 CRISIS All rights reserved
Understanding - Sequence models
Casualty care— Trigger
• Casualty has passed secondary triage— Intent
• Treat casualty before transport is ready— Decisions and decision support— Output of actions — Required performance— Breakdowns
Physical model
Artefact model
©2011 CRISIS All rights reserved
More abstractions during Understanding
Mind maps of roles and their activities
Organizational, communication and command hierarchies (block diagrams)
Hierarchy of training competencies
Random events to insert into the main scenarios to provideuncertainties
EOC
OSC
Rescue Medical Security Transportation
Figure 1: ISAVIA Command Structure
©2011 CRISIS All rights reserved
Lessons learned from UnderstandingThe different representations show that analysts frequently go
back and forth between abstract and concrete presentations
Some consolidation across workers and data sources starts even at an early stage
Some stakeholders had difficulty validating the concrete written scenarios, but preferred to look at the more abstract sequence models
Diversity of abstractions reflects developers’ experience and practices
©2011 CRISIS All rights reserved
A development process model - Benyon
Design Constraints
Abstraction Formalize Design
Stories ConcreteScenarios
ConceptualScenarios
Usecases
Envisioning and
Evaluation
Imple-ment-ation
Under-standing
Gener-ating ideas
©2011 CRISIS All rights reserved
Concepts start to develop
©2011 CRISIS All rights reserved
Consolidation – two types Consolidating sequence models of work (Holzblatt)
— Is quite labor intensive— Has been carried out on meta-level constructs, such as triggers, goals and
steps of activities. — Mostly addressed work and strategies, but not technology support— There was little consolidation across management and organization
structures
Generic Reference scenario using control flow block diagrams — Very high level
©2011 CRISIS All rights reserved
Consolidation of different incident types
Rudinsky, J., Hvannberg, E., Consolidating Requirements AnalysisModels for a Crisis Management Training simulator, ISCRAM 2011
©2011 CRISIS All rights reserved
Lessons learned Moving from describing work to concepts of a system seems to
be done implicitly for the most part
The aspect of work requiring information and communication technology have been addressed but not been conceptualized in the training simulator
Admittedly by the analysts, the conceptual description is very ambitious, at times very high level but also detailed
©2011 CRISIS All rights reserved
A development process model - Benyon
Design Constraints
Abstraction Formalize Design
Stories ConcreteScenarios
ConceptualScenarios
Usecases
Envisioning and
Evaluation
Imple-ment-ation
Under-standing
Gener-ating ideas
©2011 CRISIS All rights reserved
Navigate
Envisioning
©2011 CRISIS All rights reserved
Navigate
Envisioning
©2011 CRISIS All rights reserved
Conclusions and future work A description of work with processes and communication
between them has been successful
Modelling tools need to be specific to:— Crisis management— Training — Simulators in a virtual environment , where there is need for variability
and uncertainty
Crisis mangement is likely to be an evolving system, in terms of technological context, advancing procedures and improved training
©2011 CRISIS All rights reserved
PARTNERS
©2011 CRISIS All rights reserved
From concrete to the conceptual
How much of the context should be removed in the conceptual model?
e.g. Triaging
Dines Björner, with his facets, and Benyon have clearlyseparated different aspects of the system, such as technical, organizational, human activities etc.