veoc assumptions and requirements documentveoc/resources/design... · 1 project&goals&...
Post on 20-Apr-2020
0 Views
Preview:
TRANSCRIPT
virtual Emergency Operations Center (vEOC)
Assumptions and Requirements Document
Purpose: This document outlines the assumptions and requirements underlying the design of the vEOC.
Table of Contents Table of Contents ............................................................................................................................................... 2 1 Project Goals ................................................................................................................................................ 5
2 Project Features .......................................................................................................................................... 5
3 Project URL ................................................................................................................................................... 5 4 Development ................................................................................................................................................ 5 4.1 Spiral Design 5 4.2 Ensayo Developmental Lifecycle 6 4.3 User-‐Centered Application Design 7 4.4 Expert Validation 7 4.5 Technologies Employed 8 4.6 Jetty Server 8 4.7 Virtual Machines 8 4.8 Secure Socket Layer (SSL) 8 4.9 Redmine Server 8
5 WebEOC-‐like Console ................................................................................................................................ 8 6 Assumptions .............................................................................................................................................. 11 6.1 EOC 11 6.2 Day-‐to-‐day Operations 11 6.3 Miami-‐Dade Incident Command Structure 12 6.4 EOC Floor Plan 15
7 Incident Command .................................................................................................................................. 16 8 User Views .................................................................................................................................................. 16 8.1 Trainee 16 8.2 Observer 16 8.3 Scenario Manager 16 8.4 Administrator 16 8.5 Staff Member 16 8.6 Researcher 16 8.7 Exercise Controller 16
9 Trainee Positions ..................................................................................................................................... 17 9.1 Liaisons 17 9.2 Logistics 17 9.3 Planning 17 9.4 Section Chiefs 17 9.5 Elected Officials 17
10 Mental Models ........................................................................................................................................ 17
10.1 Trainee 17 10.2 Staff Member 18 10.3 Observer 19 10.4 Administrator 19 10.5 Researcher 19 10.6 Scenario Manager 20
11 Concept Maps .......................................................................................................................................... 20 11.1 Emergency Manager Concept Map 20 11.2 Exercise Developer Concept Map 22 11.3 Planning Concept Map 23 11.4 Exercise Controller Concept Map 23 11.5 Trainee Concept Map 23
12 Types of Training .................................................................................................................................. 24 12.1 Individual 24 12.2 Groups 24 12.3 Organizational 24 12.4 Discussion-‐based 24 12.5 Operational-‐based 24 12.6 Seminars 24 12.7 Train the Trainer 24 12.8 Workshops 24 12.9 Tabletop Exercises 24 12.10 Games 24 12.11 Drills 24 12.12 Functional Exercises 24 12.13 Full-‐scale Exercises 24
13 Processes, Requirements, and Assumptions ............................................................................... 26 13.1 Login Process 26 13.2 Logistics Process 28 13.3 Mission Task Requirements 29
14 Software Architecture ......................................................................................................................... 29 14.1 Trainee 29 14.2 Exercise Developer 29 14.3 Researcher 30
15 UML Diagrams ........................................................................................................................................ 31
16 Purposes of CIMS ................................................................................................................................... 38
17 System Capabilities .............................................................................................................................. 38 18 Software Call Graph .............................................................................................................................. 48
19 Testing ...................................................................................................................................................... 48
20 Future Work ............................................................................................................................................ 48 Appendix ........................................................................................................................................................... 49
1 Project Goals To build a virtual Emergency Operations Center for: • Training emergency personnel • Research into emergency management decision making
2 Project Features • Distributed • Web-‐based • Intelligent agents that can supplant human trainees • Interactive Advisor • Dashboards
3 Project URL The project URL is http://veocdev.crc.nd.edu/veoc/RegularLogin2.php. Note: you have to be connected to the Notre Dame campus VPN in order to access this URL. (the development server)
4 Development
4.1 Spiral Design Ensayo has been developed using the spiral design model. The spiral model is an iterative model in which development proceeds through incremental releases of the system. The lifecycle usually beginning with a prototype and proceeds in iterations as outlined in figure 1 below.
location
people
Figure 1*: Spiral Lifecycle
*Source: Wikipedia -‐ touched up figure of Boehm original
4.2 Ensayo Developmental Lifecycle Specifically, Ensayo has a multi-‐tier lifecycle. (See Figure 2 below). There are five main tiers: simulated training for one individual versus the entire organization, artificial simulation of one individual versus the entire organization, different user roles (see subsequent section on User Views). various trainee positions, and finally, system modules. We began the design by simulated training for the entire organization. That is, training is designed for the entire organization to practice an exercise. After completing the training simulation of the entire organization, we will simulate training for selective groups of the Incident Command System (ICS). Finally, we will simulate training for one individual. Accordingly, simulation of artificial agents follows the opposite spectrum. First, we begin with no artificial agents. Next we simulate an individual agent. Then we simulate a small group of agents. Finally, we simulate the entire organization with artificial agents. We began the design by simulating different user roles (see subsequent section on User Views). various trainee positions, and finally, system modules.
4.3 User-‐Centered Application Design • Content: the features in the design • Functionality: what the program is capable of doing • Aesthetics: how pleasing the user-‐interface is to the eye • Usability: the user-‐friendliness of the design
4.4 Expert Validation In order to validate the system and obtain an expert subject matter knowledge base, we are working with one of the foremost emergency operations centers in the country – the Miami-‐Dade EOC.
!!!!!!!!!!!!!!
!
!!!
!!!!
!!
!
Logistics!Module!Decision!Support!
File!System!Tutorial!Module!
Scratchpad!! ! ! ! ! Interactive!Advisor!! ! ! ! ! ! Administration/Configuration!Module!! ! ! ! ! ! ! Access!Control!! ! ! ! ! ! ! ! Redundant!Database!! ! ! ! ! ! ! ! ! Backup!Database!
One!Individual!
Groups!of!Individuals!
Entire!Organization!
Liaison!!
Incident!Commander!!
Logistics!!
Section!Chiefs!!
Mayor!!
Trainee!Console!!G!Primary!Database!G!!Communications!Module!!
Scenario!Manager!G!!Exercise!Driver!!
Researcher!Console!!G!Research!Module!!
Staff!Console!!G!Research!Module!!
Administrator!Console!!G!Research!Module!!
4.5 Technologies Employed • On the client side, technologies include XHTML, CSS, Dynamic HTML, AJAX, Reverse AJAX, and JavaScript. • On the server side, technologies employed are PHP, MySQL, DOJO and the Jetty server.
4.6 Jetty Server We are using the Jetty Server version 6.1.14. The Jetty Server was chosen because of the DOJO toolkit/Reverse AJAX capabilities incorporated in the server. The Jetty website is http://jetty.codehaus.org/jetty/.
4.7 Virtual Machines We are using virtual machines in the development of Ensayo. There are several reasons. First, these virtual machines have provided the ability to sustain hardware failures. In case of a hardware failure, Ensayo can be up and running in a matter of minutes, as apposed to much longer recovery time associated with using the direct underlying hardware. Second, it is much more simple to backup the virtual machines than to backup traditional hardware. Furthermore, the state of Ensayo and the statespace of the underlying (virtual) hardware is backed-‐up in addition to the project files. This also simplifies failure recovery. Finally, virtual machines allow for easy installation and setup of Ensayo; Rather than needing to configure databases and servers, the user simply can play a virtual machine and have instant configuration and setup of Ensayo.
4.8 Secure Socket Layer (SSL) For security enhancements, we are using port 443. All transmissions go through the Secure Socket Layer in order to access Ensayo.
4.9 Redmine Server Development
5 WebEOC-‐like Console The vEOC is based on the WebEOC console. This is the Crisis Information Management System that Miami-‐Dade County uses at the EOC. It is composed of tabbed-‐based browsing and dynamically configurable boards.
Figure 1: Example screenshots from the WebEOC console.
In the original prototype, the system used a tab-‐based approach and stored the information in the client’s web-‐browser. Because there is a lot of information that emergency managers need some of the time, tabbed interfaces can waste space and become overloaded. An alternative to tabs, in a windows-‐based approach, each menu item creates a new pop-‐up window. This allows individuals to have more information readily available and to easily switch between various statuses.
Figure 2: Example vEOC console.
Figure 3: Example vEOC status boards.
6 Assumptions
6.1 EOC An Emergency Operations Center is a secure location where upper-‐level emergency officials gather to prepare for, manage, and coordinate the response to an incident (e.g. tsunami, earthquake, hurricane, pandemic).
6.2 Day-‐to-‐day Operations In day-‐to-‐day operations, emergency management staff are involved in preparedness and mitigation strategies for future crises (ICS 1 2002). They are organized into Health and Human Services, Systems, Planning and Preparedness, Infrastructure and Recovery, and Personnel and Administration. See Figure 4.
Figure 4: Department of Emergency Management organizational structure. This is the day-‐to-‐day structure of emergency
management at the Emergency Operations Center.
6.3 Miami-‐Dade Incident Command Structure When a disaster strikes, however, the emergency management staff drop their day-‐to-‐day roles and take on the role assigned to them by the Incident Commander. This role usually involves leading a section or branch of the incident command system or ICS (Johnson 2010). There are four main branches in accordance with ICS. The main sections are operations, planning, logistics, and finance/administration. (See Figure 4)
DirectorCurtis Sommerhoff
Homeland security program
manageer mdpd lieutenant
Efren lopez
deputy directorjonathan lord
external affairs coord
em governmental coord
david perez
executive secretary
lettie cogdell
public information
officerjamie hernandez
health & human services bureau
managerVolunteer
managementNixsa serrano
systems managerSSA/p
gissoheila ajabshir
planning & preparedness
bureau managertechnical hazards
Niel batista
infrastructure & recovery bureau
managerLocal mitigation
strategyFrank reddish
personnel & admin manager
Spa1finance & human
resourcesPamela broaster-
doyle
empa/empg projectgrant funded
tempmonique lopez
critical infrastructure em coordinator
raymond misomali
logistics & podsem coordinator
craig hall
recoveryem coordinator
paul vitro
dae & strategic planning
Em coordinatoranjila lebsock
cemp, coop, & evacem coordinatorsherry capers
special hazards & ccgp planning
em coordinatorroslyn viterbo
training & exercise
em coordinatortroy johnson
eoc readinessem coordinatoradrian walker
regional em planner
em specialistgrant funded
vacant
eoc readinessem coordinator
vacant
health servicesem coordinator
lorenzo sanchez
community prep & ada
em coordinatorMirtha gonzalez
psn & rhcfem coordinatorroberto cepeda
mass care & ambulance contract
em coordinatorcharles cyrille
At Miami-‐Dade County, Operations is further organized into four branches: Public Safety, Human Services, Infrastructure, and Municipal. Planning consists of Geographic Information Systems (GIS), the 311 Public Information Call Center, and three units to aid in incident planning and documentation. Finally, Logistics is divided into EOC Support and Disaster Resources. See Figure 5. The operations, planning, logistics, and finance/administration sections constitute the general staff. Leading the general staff and assuming responsibility for the incident is the Incident Commander. See Figure 5. The Incident Commander has additional support staff as well, called the command staff, which includes a public safety officer, a public information officer, and a liaison officer. (Irwin 1989).
Figure 5: Incident Command System (IS-‐100.a 2008). The command staff, the general staff, and the agency liaisons assist
the incident commander during an emergency.
6.4 EOC Floor Plan
Figure 6: Miami-‐Dade EOC Activation Floor Plan.
Mia
mi-
Dad
e Em
erge
ncy
Ope
rati
ons
Cen
ter
Act
ivat
ion
floo
r pl
an
Broward
County EM (REP Only)
Martin
County EM (REP Only)
Collier
County EM (REP Only)
Homestead Air Reserve Base (REP)
Intergovern-
mental Coordinator
MIT-Tech Support
MIT-
Application Support
Airports
Florida City (REP Only)
Monroe County
EM
Monroe County
EM
Miami Beach Divisional
EOC
North Miami Divisional
EOC
N Miami Bch Divisional
EOC
Homestead Divisional
EOC
Coral Gables Divisional
EOC
Hialeah Divisional
EOC
Florida DEM
Miam
i-Dad
e Fire
Re
scue
Dep
t.
Public Safety Manager
Public Safety Assistant
Miam
i-Dad
e Po
lice
Depa
rtmen
t
Miam
i-Dad
e Fire
Re
scue
Dep
t.
Miam
i-Dad
e Po
lice
Depa
rtmen
t
Florid
a Dep
t. of
Law
Enfor
ceme
nt
U.S.
Coa
st Gu
ard
DE
RM
Florid
a High
way
Patro
l
Natio
nal P
ark
Servi
ce
Miam
i-Dad
e Sc
hools
Poli
ce Flo
rida
Fish a
nd
Wild
life
Comm
ission
Miam
i-Dad
e Co
rrecti
ons
Dept.
Florida National Guard
Animal Services
PUBL
IC S
AFET
Y FU
NCT
ION
AL G
ROU
P
Operations Section
Assistant
Operations Section
Manager
podium
EOC Support Manager
Planning: Situation
Assessment
Miam
i-Dad
e Pu
blic S
choo
ls
Human Services Manager
Human Services Assistant
Miam
i-Dad
e Fir
e Res
cue
EMS
Amer
ican
Red C
ross
Spec
ial N
eeds
Co
ordin
ator
Miam
i-Dad
e He
alth
Depa
rtmen
t
Salva
tion
Army
Gr
eater
Miam
i Co
nven
tion
& Vi
sitor
s Bur
eau
AHCA
Dept.
of H
uman
Se
rvice
s
Miam
i-Dad
e Ho
using
Age
ncy
Team
Me
tro
Florid
a Dep
t. of
Child
ren &
Fa
milie
s
VOAD Mental Health (REP Only-BRC)
HU
MAN
SER
VICE
S FU
NCT
ION
AL G
RO
UP
Miam
i-Dad
e Pu
blic S
choo
ls
Infra-structure Manager
Infrastructure Assistant
Bell S
outh
Miam
i-Dad
e Tr
ansit
-Ev
acua
tion
Florid
a Pow
er
& Lig
ht
City
Gas
So. F
L Wate
r Ma
nage
ment
Distr
ict
Miam
i-Dad
e Tr
ansit
- Re
gular
Svs
.
Miam
i-Dad
e ET
SD
Miam
i-Dad
e So
lid W
aste
Dept.
Miam
i-Dad
e Pa
rks D
ept.
Miam
i-Dad
e W
ater &
Se
wer
Agric
ultur
e Ex
tensio
n
Miami-Dade Public Works
Florida Dept. of
Transportation
INFR
ASTR
UCT
URE
FU
NCT
ION
AL G
ROU
P
Port
CDivisional ity of Miami
EOC
of Miami
NOTE: REP Only=Agencies that only are present for radiological emergencies.
04/25
/07
7 Incident Command For this Hybrid of NIMS and (26 fema ESFs) and ICS.
8 User Views There are 6 different user views in the vEOC, that is, there are 6 main roles that a user may exercise: the trainee, the observer, the scenario manager, the staff member, the administrator, and the researcher.
8.1 Trainee The trainee prepares for emergency situations and practices decision making by interacting with the vEOC. The trainee has the ability to modify all status in the vEOC.
8.2 Observer The observer prepares for emergency situations by watching the trainees and other personnel in the vEOC; He/she does not have the ability to modify status in the vEOC other than to read and search through archives.
8.3 Scenario Manager The scenario manager creates scripts to train emergency personnel. The scenario manager also moderates the exercise/training sessions. The scenario manager is essentially equivalent to the controller in the functional exercise, with the exception that injects are automatically presented to the trainee. The scenario manager has the greater ability/responsibility to begin, pause, and terminate the exercise. The scenario manager can also speed up or slow down the exercise aswell.
8.4 Administrator The administrator maintains the vEOC software. The administrator also sets up and moderates user profiles.
8.5 Staff Member Staff members are upper level EOC sta_. For example, they may be EOC planning section personnel. Staff members can print reports and analyze performance and decision making of the EOC personnel.
8.6 Researcher Researchers are individuals interested in studying various aspects of decision making and emergency response. They typically are not EOC personnel.
8.7 Exercise Controller Needs to be developed
9 Trainee Positions
9.1 Liaisons
9.2 Logistics
9.3 Planning
9.4 Section Chiefs
9.5 Elected Officials
10 Mental Models
10.1 Trainee
10.2 Staff Member
10.3 Observer
10.4 Administrator
10.5 Researcher
10.6 Scenario Manager
11 Concept Maps
11.1 Emergency Manager Concept Map
Figure 7: An emergency manager concept graph. This concept map shows the various functions that emergency managers engage in on an on-‐going basis as well as during a crisis. The main activities center around both information and people.
11.2 Exercise Developer Concept Map
Figure 8: An exercise developer concept graph.
This concept map shows the various functions that exercise developers engage in when creating an exercise.
Exercise Developers
controller handbooks
player handbooks
evaluator handbooks
scripts
flow of the exercise
injects
players
evaluation metrics
objectives
past exercises
reports
indiviuals
groups
organization as a whole
develop
moderate
determine
based on
consisting of
sent totaken from
target capabilities
11.3 Planning Concept Map Needs to be mapped out
11.4 Exercise Controller Concept Map Needs to be mapped out better
11.5 Trainee Concept Map Needs to be mapped out
12 Types of Training
12.1 Individual
12.2 Groups
12.3 Organizational
12.4 Discussion-‐based
12.5 Operational-‐based
12.6 Seminars
12.7 Train the Trainer
12.8 Workshops
12.9 Tabletop Exercises
12.10 Games
12.11 Drills
12.12 Functional Exercises
12.13 Full-‐scale Exercises
13 Processes, Requirements, and Assumptions
13.1 Login Process
13.2 Logistics Process
Figure 10: The logistics resource request process.
This process was obtained through interviews with Craig Hall, the Logistics section chief at Miami-‐Dade. This process outlines the roles of the Logistics Section Chief, the Government Services Agency, and Department of Procurement Management in obtaining a resource. It also outlines how Miami-‐Dade county attempts to fill the request in-‐house first and then if this is not possible, it upchannels the request to the state (through the EM Constellation software program).
13.3 Mission Task Requirements • Anyone can assign a mission/task to anyone else • Other people should only see the mission/tasks for which they are assigned and which they assign to others • Only the person who created the mission/task should be able to edit it • The person to which it is assigned should be able to change the status of the mission/tasks • It would be nice to have a pop up box alerting the person when a person is assigned a new mission/task.
14 Software Architecture
14.1 Trainee
14.2 Exercise Developer
14.3 Researcher
15 UML Diagrams
-username-role-password
Login(RegularLogin2.php)
-username-role
Logout(logout.php)
Authentication(Authenticate.php)
Customize Screens (user resizes windows)
vEOC
-pick group-pick individual within group
-pick scripts
Pick Player(index.php)
Interact with Console
(mainpanel.php and exercisepanel.php)
-cus
tom
ize
scre
en
-cur
rent
Stat
e
Desk
top
Hist
ory
Repo
rts
Dash
boar
d
Inte
ract
ive
Advi
sor
-vie
w-e
nlar
ge-d
ecre
ase
-upl
oad
file
-dow
nloa
d fil
e
-cur
rent
File
C
urre
nt S
tatu
s
cha
nge
stat
us-re
ques
t res
ourc
e-a
nsw
er c
omm
unic
atio
n m
ediu
m-re
spon
d to
reso
urce
requ
est
-requ
est r
esou
rce
-upd
ate
stat
us-o
pen
com
mun
icat
ion
tool
-log
even
t (au
tom
atic
?)
-cur
rent
Stat
e
Cons
ole
Man
ager
Sear
ch
-sav
e-s
earc
h-p
rint
Log
Basi
c Se
arch
Adva
nced
Sea
rch
Infra
stru
ctur
e
Hum
an S
ervi
ces
Publ
ic S
afet
y
Spec
ial N
eeds
Hurr
evac
SLO
SH
SALT
eTea
m
Basi
c Lo
g
Adva
nced
Log
Repo
rt Te
mpl
ate
Repo
rt Li
brar
y
Ad-h
oc R
epor
t
Repo
rt Pr
evie
w
-ope
n-c
lose
Exte
rnal
Sof
twar
e In
terf
ace
-sen
d-re
ceiv
e
PDA
-list
en-ta
lk
radi
o
-talk
-list
en
face
to fa
ce
-sen
d m
essa
ge-re
ceiv
e m
essa
ge
phon
e
-sen
d-re
ceiv
e
Com
mun
icat
ion
Med
ia
-list
en-ta
lk
Land
line
-list
en-ta
lk-te
xt m
essa
ge-e
mai
l
Cellu
lar
-sen
d-re
ceiv
e-s
ave
-edi
t-d
elet
e
emai
l -ope
n-c
lose
inte
rnet
-ope
n -c
lose
Com
mun
icat
ion
Tool
s
-ope
n po
wer
poin
t?-c
lose
pro
gram
-sav
e fil
e-e
dit fi
le-o
pen
file
publ
ish
file
stat
us re
ports
-requ
est r
esou
rce
-app
rove
reso
urce
-log
reso
urce
-bud
get r
esou
rce
requ
est r
esou
rces
T
rain
ee
-get
Tim
eDiff
eren
t(s
tartT
ime,
curre
nttim
e) -c
urre
ntTi
me
-sta
rtTim
e
Tim
er
-get
Even
tDiff
eren
ce(c
urre
ntEv
ent,
corre
ctEv
ent)
-cur
rent
Even
t-c
orre
ctEv
ent
Hint
Man
ager
-reg
iste
r for
eve
nts
On-
Load
-cus
tom
ize
scre
en
-cur
rent
Stat
e
Desk
top
Hist
ory
Repo
rts
Dash
boar
d
Inte
ract
ive
Advi
sor
-vie
w-e
nlar
ge-d
ecre
ase
-upl
oad
file
-dow
nloa
d fil
e
-cur
rent
File
C
urre
nt S
tatu
s
-cha
nge
stat
us-re
ques
t res
ourc
e-a
nsw
er c
omm
unic
atio
n m
ediu
m-re
spon
d to
reso
urce
requ
est
-requ
est r
esou
rce
-upd
ate
stat
us-o
pen
com
mun
icat
ion
tool
-log
even
t (au
tom
atic
?)
-cur
rent
Stat
e
Cons
ole
Man
ager
Sear
ch
-sav
e-s
earc
h-p
rint
Log
Basi
c Se
arch
Adva
nced
Sea
rch
Infra
stru
ctur
e
Hum
an S
ervi
ces
Publ
ic S
afet
y
Spec
ial N
eeds
Hurr
evac
SLO
SH
SALT
eTea
m
Basi
c Lo
g
Adva
nced
Log
Repo
rt Te
mpl
ate
Repo
rt Li
brar
y
Ad-h
oc R
epor
t
Repo
rt Pr
evie
w
-ope
n-c
lose
Exte
rnal
Sof
twar
e In
terf
ace
-sen
d-re
ceiv
e
PDA
-list
en-ta
lk
radi
o
-talk
-list
en
face
to fa
ce
-sen
d m
essa
ge-re
ceiv
e m
essa
ge
phon
e
-sen
d-re
ceiv
e
Com
mun
icat
ion
Med
ia
-list
en-ta
lk
Land
line
-list
en-ta
lk-te
xt m
essa
ge-e
mai
l
Cellu
lar
-sen
d-re
ceiv
e-s
ave
-edi
t-d
elet
e
emai
l -ope
n-c
lose
inte
rnet
-ope
n -c
lose
Com
mun
icat
ion
Tool
s
-ope
n po
wer
poin
t?-c
lose
pro
gram
-sav
e fil
e-e
dit fi
le-o
pen
file
publ
ish
file
stat
us re
ports
-requ
est r
esou
rce
-app
rove
reso
urce
-log
reso
urce
-bud
get r
esou
rce
requ
est r
esou
rces
Obs
erve
r
-get
Tim
eDiff
eren
t(s
tartT
ime,
curre
nttim
e) -c
urre
ntTi
me
-sta
rtTim
e
Tim
er
-get
Even
tDiff
eren
ce(c
urre
ntEv
ent,
corre
ctEv
ent)
-cur
rent
Even
t-c
orre
ctEv
ent
Hint
Man
ager
-reg
iste
r for
ev
ents
On-
Load
-Cal
enda
r-C
hat
-Inst
ant
Mes
seng
er-N
otes
-Blo
g
New
sroo
m
Mod
ule
-Beg
in-P
ause
-Sto
p-E
nd-F
ast T
ime
-Nor
mal
Tim
e-N
ext E
vent
Con
trol
Mod
ule
-Cre
ate
Scrip
t-E
dit S
crip
t-D
elet
e Sc
ript
-Sav
e Sc
ript
-Impo
rt Sc
ript
-Exp
ort S
crip
t-P
rint S
crip
t
Libr
ary
Search
Bas
ic S
earc
h
Adv
ance
d Se
arch
Scen
ario
Man
ager
Reports
-sav
e-p
rint
-sav
e as
tem
plat
e
Ad-
hoc
Rep
ort
-new
-ope
n-s
ave
-edi
t-d
elet
e
Rep
ort T
empl
ate
-Add Member-Edit Member-Delete Member-Virtualize Member-De-virtualize Member-Access Control
User Profile
Environmental
Agent
Virtualize
De-virtualize
Administrator
Newsroom
Data Collection
Reports
Ad-hoc Report
Report Template
News
Chat
Statistics
Calendar
-new-open-save-edit-delete-import-export
Report LibraryStaff Member
Search
Advanced
Basic
New
sroo
m
Dat
a C
olle
ctio
n
Reports
Ad-
hoc
Rep
ort
Rep
ort T
empl
ate
New
s
Cha
t
Stat
istic
s
Cal
enda
r
Rep
ort L
ibra
ry
Doc
umen
ts
-Upl
oad
file
-Dow
nloa
d fil
e-N
ew fo
lder
-Del
ete
fold
er-E
dit f
olde
r-N
ew fi
le-E
dit fi
le-D
elet
e fil
e
Libr
ary
Sear
ch
Bas
ic S
earc
h
A
dvan
ced
Sear
ch
Col
lect
ion
Tem
plat
e
Res
earc
her
16 Purposes of CIMS Table 1: CIMS throughout the Emergency Response Lifecycle (Governmental/Emergency
Managers)
Phase of Emergency Response Lifecycle
Primary Role of CIMS
Secondary Role of CIMS
Example Applications
Mitigation (day to day) Updating the CIMS Data Repository WebEOC Preparedness (day to day)
-‐Risks assessment -‐Planning -‐Analysis -‐Training -‐Policy Development
Data Repository Ensayo, WebEOC
Response (during a crisis)
-‐Command and control -‐Common operating picture -‐Decision support -‐Coordination -‐Information control and dissemination
-‐Resource acquisition, allocation, and exchange -‐Documentation
WebEOC, Sharepoint
Recovery (following a crisis)
-‐Coordination -‐Information exchange -‐Resource acquisition, allocation, and exchange -‐Documentation
-‐Common Operating Picture -‐Decision Support
Sahana
Additional CIMS Characteristics
-‐Used throughout the emergency response lifecycle -‐Easy to learn/use -‐Adaptable -‐Easy to install Backup -‐Interoperable (with municipalities and state and national/international networks) -‐Trust in CIMS -‐Distributed
17 System Capabilities 1. Trainee
1.1. User Tutorial
1.1.1. Voiceover 1.1.2. Update to Maya?
1.2. Login 1.2.1. Main browser login message 1.2.2. User Login 1.2.3. Position Login
1.2.3.1. Select Role to Be 1.2.4. Select Script to Use for Exercise
1.3. Common Operating Picture 1.3.1. Starting Status
1.3.1.1. Check Starting Status
1.3.1.2. Create ability to have multiple starting statuses 1.3.2. Exercise Background
1.3.2.1. View Player Handbook 1.3.2.2. View EOC Floor Plan
1.3.2.2.1. Update to interactive floor plan 1.3.3. Road Closures
1.3.3.1. Check Status of Road Closures 1.3.3.2. Create Status of Road Closures
1.3.3.3. Edit/Update status of Road Closures 1.3.3.4. Dynamic status updates
1.3.4. Shelters 1.3.4.1. Check Status of Shelters 1.3.4.2. Create Status of Shelters 1.3.4.3. Edit/Update status of Shelters 1.3.4.4. Dynamic status updates
1.3.5. Hospitals 1.3.5.1. Check Status of Hospitals 1.3.5.2. Create Status of Hospitals 1.3.5.3. Edit/Update status of Hospitals 1.3.5.4. Dynamic status updates
1.3.6. Points of Distribution (PODs) 1.3.6.1. Check Status of PODs 1.3.6.2. Create Status of PODs 1.3.6.3. Edit/Update status of PODs 1.3.6.4. Dynamic status updates
1.3.7. Disaster Map 1.3.7.1. View the Disaster Map 1.3.7.2. Edit/Update Disaster Map 1.3.7.3. Clear Disaster Map
1.3.7.4. Save Disaster Map 1.4. Mission/Tasks
1.4.1. Create a Mission/Task 1.4.2. Edit/Update Mission/Task 1.4.3. Delete Mission/Task 1.4.4. Dynamic status updates
1.5. Resource Requests 1.5.1. Submit a Resource Request
1.5.1.1. Add standardized FEMA resource typing 1.5.2. Edit/Update a Resource Request 1.5.3. Delete a Resource Request
1.5.4. Check the status of a Resource Request 1.5.5. Dynamic status updates
1.6. Significant Events 1.6.1. Post a Significant Event 1.6.2. Edit a Significant Event 1.6.3. Delete a Significant Event 1.6.4. Dynamic status updates
1.7. Position Log 1.7.1. Post a Position Log 1.7.2. Edit a Position Log 1.7.3. Delete a Position Log
1.8. Logistics 1.8.1. Acquire a Contract Resource
1.8.1.1. In-house 1.8.1.2. Out-house
1.8.1.2.1. Log to EM Constellation 1.8.1.3. Dynamic status updates
1.8.2. Approve a Resource Request 1.8.2.1. Update a Resource Request
1.8.2.1.1. Change the status of resource request
1.8.2.1.2. Add notes section to resource request updates 1.9. Planning
1.9.1. Create Incident Action Plans 1.9.2. Edit Incident Action Plans 1.9.3. Delete Incident Action Plans
1.10. Disaster Assistant
1.10.1. Ask a Question to the Disaster Assistant
1.10.2. Update disaster assistant? 1.11. Dashboards
1.11.1. Lives Saved, Injured, Deceased 1.11.1.1. Add dashboard data 1.11.1.2. Update dashboard data 1.11.1.3. Delete dashboard data
1.11.2. Cost to county 1.11.2.1. Add dashboard data 1.11.2.2. Update dashboard data 1.11.2.3. Delete dashboard data
1.11.3. View a dashboard 1.12. Injects
1.12.1. Acknowledge inject 1.12.2. Clarify an inject 1.12.3. Respond to Injects 1.12.4. Review Received Injects 1.12.5. Log injects
1.13. Chat 1.13.1. Initiate Chat 1.13.2. End Chat 1.13.3. Receive Chat 1.13.4. Accept Chat 1.13.5. Reject Chat
1.14. Logout 1.14.1. Release trainee role
1.15. Create Help files 1.15.1. Find/use automatic help file creator
1.16. Logging 1.16.1. Log chats 1.16.2. Log significant events 1.16.3. Log user actions during the exercise
1.16.3.1. log user response to injects 1.16.4. log position logs
1.17. Loose Ends 1.17.1. Add validation controls to interfaces 1.17.2. Update Chat program?
1.18. Logout 1.18.1. Automatic logout if time expires
1.18.2. Automatic logout if user closes windows without logging out
2. Exercise Developer 2.1. Login
2.1.1. Main browser login message 2.2. User Tutorial 2.3. Handbook Developer
2.3.1. Update the handbook developer 2.3.2 Add figures to handbook developer
2.4. Starting Status 2.4.1. Create starting status
2.4.1.1. Update starting status 2.4.1.1.1. Text
2.4.1.1.1.1. Insert text 2.4.1.1.1.2. Update text
2.4.1.1.2. Figures 2.4.1.1.2.1. Insert figure 2.4.1.1.2.2. Change figure 2.4.1.1.2.3. Delete figure
2.4.1.2. Create multiple starting status reports 2.5. Target Capabilities
2.5.1. Target Capabilities 2.5.1.1. Add target capabilities to script
2.5.1.1.1. Add new target capability
2.5.1.1.2. Add target capability from database 2.5.1.2. Edit target capabilities
2.5.1.3. Delete target capabilities from script 2.5.2. Target Capability Metrics
2.5.2.1. Add target capability metrics to script
2.5.2.1.1. Add new target capability metric
2.5.2.1.2. Add target capability metric from database 2.5.2.2. Edit target capability metrics
2.5.2.3. Delete target capability metrics from script 2.5.3. Exercise Objectives
2.5.3.1. Create exercise objectives 2.5.3.2. Add exercise objectives to script 2.5.3.3. Delete exercise objectives to script
2.5.4. Create exercise handouts for evaluators 2.6. Scripting
2.6.1. Create a Script 2.6.2. Edit Script
2.6.2.1. Injects 2.6.2.1.1. Add inject from Database 2.6.2.1.2. Add New Inject
2.6.2.1.3. Delete an inject from the script 2.6.2.1.4. Edit an inject
2.6.2.1.5. Move Injects Around Ad-hocly 2.6.3. Delete Script 2.6.4. Import/Upload Script 2.6.5. Export Script 2.6.6. Archive Script
2.6.6.1. View Archived script? 2.7. Database controls
2.7.1. Clear the logs for the script 2.7.2. Reset the logs for the script 2.7.3. Clear the logs for the player
2.8. Exercise Controller 2.8.1. User Tutorial 2.8.2. Control the Exercise
2.8.2.1. Start Exercise 2.8.2.2. Pause Exercise 2.8.2.3. Terminate Exercise 2.8.2.4. Next Block 2.8.2.5. Fast Time 2.8.2.6. Move Injects Around Ad-hocly
2.8.3. Player Reports 2.8.3.1. View Player Reports 2.8.3.2. Filter player reports 2.8.3.3. Sort player report elements 2.9.3.4 More detailed player reports
2.8.4. Logout 2.9. Loose Ends
2.9.1. Add validation controls to interfaces
3. Researcher 3.1. Login
3.1.1. Main browser login message 3.2. Choose Exercise Metrics
3.2.1. Percentage injects received but not responded to (missed)
3.2.2. Average inject response time (when does response time start and end?) 3.2.3. Correctly respond to injects
3.2.4. Response to injects within capability metrics 3.3. View Chat Logs
3.3.1. Analyze chat logs 3.3.1.1. Sort chat log elements 3.3.1.2. Filter chat log elements
3.4. View Position Logs 3.4.1. Analyze position logs
3.4.1.1. Sort position log elements 3.4.1.2. Filter position log elements
3.5. View Player Reports 3.5.1. Create more detailed player reports
3.5.1.1. Include expected user actions to injects 3.5.1.2. Better logging
3.5.2. View single player report 3.5.2.1. Analyze player reports
3.5.2.1.1. Sort player report elements
3.5.2.1.2. Filter player report elements
3.5.2.1.3. More detailed player reports 3.5.3. View multiple player reports
3.5.3.1. Analyze player reports 3.5.3.1.1. Sort player report elements
3.5.3.1.2. Filter player report elements 3.6. Logout 3.7. Loose Ends
3.7.1. Add validation controls to interfaces
4. Administrator 4.1. Create Console
4.1.1. Login 4.1.2. Create User Logins 4.1.3. Delete User Logins 4.1.4. Reset Locked Players
4.2. Manual Database Access 4.2.1. Modify tables and data in tables
4.3. Logout
4.4. Loose Ends 4.4.1. Add validation controls to interfaces
5. Database 5.1. Input validation
5.1.1. Add validation controls to interfaces
6. Documentation 6.1. Developer
6.1.1. Inline documentation (code) 6.2. System Documentation
6.2.1. Flow charts 6.2.1.1. System Overview 6.2.1.2. Trainee 6.2.1.3. Exercise Developer 6.2.1.4. Exercise Controller 6.2.1.5. Researcher 6.2.1.6. Administrator
6.3. User Manuals 6.3.1. Installation 6.3.2. System Overview 6.3.3. Trainee 6.3.4. Exercise Developer 6.3.5. Exercise Controller 6.3.6. Researcher 6.3.7. Administrator
7. System Improvements 7.1. System backup
7.1.1. Eclipse on personal computer 7.1.2. Servers (through svn)
7.2. General Loose Ends 7.2.1. Expand menu bars to fit screen 7.2.2. Adjust menu size to menu minimization
7.2.3. Salvation Army listed twice/Public Safety listed twice
7.2.4. Compatibility with different web browsers 7.2.4.1. Firefox 3.6.18 or greater 7.2.4.2. Internet Explorer 7.2.4.3. Safari
7.3. Review Reverse AJAX functionality 7.3.1. Chat program
7.3.2. Remote functionality 7.3.3. Scripting
7.4. XML Standards
7.4.1. Create standards for data transfer and storage 7.4.2. Switch database to XML database
7.5. Artificial Tutoring System 7.5.1. Expert System
7.6. Code Release on Source Forge 7.6.1. Scrub documents
7.6.1.1. Create own Database
7.6.1.2. Create passwords and URLs to database
7.6.1.3. Delete passwords and URLs to server 7.6.1.4. Use a virtual player?
7.7. Experiment with Cyberinfrastructure lab at Notre Dame 7.7.1. Write Journal Paper
8. Testing 8.1. System
8.1.1. System scalability 8.1.2. Server scalability
8.2. Web-browser compatibility 8.2.1. Firefox 3.6.18 or greater 8.2.2. Internet Explorer 8.2.3. Safari
8.3. Trainee Console 8.3.1. All elements working 8.3.2. Input validation 8.3.3. User interface design and functionality 8.3.4. Security
8.4. Exercise Developer 8.4.1. All elements 8.4.2. Input validation 8.4.3. User interface design and functionality 8.4.4. Security
8.5. Exercise Controller 8.5.1. All elements 8.5.2. Input validation 8.5.3. User interface design and functionality 8.5.4. Security
8.6. Researcher 8.6.1. All elements 8.6.2. Input validation 8.6.3. User interface design and functionality 8.6.4. Security
8.7. Administrator 8.7.1. All elements 8.7.2. Input validation 8.7.3. User interface design and functionality 8.7.4. Security
8.8. Database 8.8.1. Input validation 8.8.2. Scalability 8.8.3. Security
18 Software Call Graph
19 Testing Automated and manual testing (see appendix of master test plan)
20 Future Work In the future, we would like to enhance system capabilities. We also aim to release the project in open source and/or integrate Ensayo into other applicable projects (e.g. Sahana, WebEOC) may want to break up the controller from the exercise developer. Bugs, better testing
David to update call graph, SSL information, and system architecture models;
Appendix Insert Master Test Plan
top related