vEOC Assumptions and Requirements Documentveoc/resources/Design... · 1 Project&Goals&...

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


Collier


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

print

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


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


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

vEOC Assumptions and Requirements Documentveoc/resources/Design... · 1 Project&Goals&...

Documents

Transcript of vEOC Assumptions and Requirements Documentveoc/resources/Design... · 1 Project&Goals&...