= Exercise Management =
[[TOC]]

== Overview ==
This blueprint is based on the need to an application to allow the management or exercises (or simulations) for training purposes. This is an application that provides the management tools associated with preparing, delivering, and reviewing exercises. Some of these requirements have been based on requirements when Sahana Software Foundation products have been tendering for Emergency Management Information System tenders, others have been obtained from experience delivering exercises including up to Whole-of-Government level.

 * Domain contributors: Gavin Treadgold

== Concepts ==
* Exercise Master Log - the fundamental tool of an exercise is a master log. A master log generally consists of 'message injects' that record:
 * Date and Time - the date and time the message is due to be communicated to the relevant exercise participants.
 * From - who the inject is 'from', usually it is from Exercise Control, or Exercise Control on behalf of one of the Exercise Participants
 * To - who the inject is 'to', usually one or more Exercise Participants. These could be organisations, groups, roles or people.
 * Message - the actual message inject that will be sent to the relevant participants.
 * Note - a note field that is usually only available to Exercise Control and contains guidance about this inject to those delivering the exercise. Some inject entries may be just notes to Exercise Control to see if certain states or conditions have been reached in the exercise.
* Participants Directory - the list of all exercise participants that is generally available to all of the exercise organisers
* Static Pages - there are a number of static pages that need to be associated with exercises, usually things such as Exercise Rules, and perhaps Background information (simulation information that should be read as background, but is not delivered as message injects).

== Users ==
These are the broad classes of users commonly associated with exercises.
* Exercise Control - a group of people that have full access to the tools to manage exercises. This group is responsible for the development and delivery of the exercise
 * Exercise Facilitators/Coordinators - a second group that has read-only access to the exercise information, often a subset that is relevant only to the group that they are overseeing in the exercise. Facilitators/Coordinators are a subset of Exercise Control.
* Exercise Participants - the end users that 'experience' the simulation.

== Requirements ==
A fundamental requirement of delivering an exercise is an internal messaging system that simulates email/messaging.
=== Exercise Development ===
* Integrated with Organisations, Groups,  Roles, and People
* Supports self-registration of participants
* Allows Exercise Control members to construct a Master Log and create and view the message injects
* Able to produce a pdf file for each message inject for emailing and/or printing on a message inject template (GT can provide examples)
* Able to filter messages to/from a particular organisation, group, role or person; or a particular subject/thread
* Allows the production/export of a Participants Directory in relevant formats (e.g. pdf, CSV, XLS).
=== Exercise Delivery ===
* Able to deliver messages at the time specified in the master log to the specified participants
* Able to capture messages between exercise participants
* Produce a master log of exercise injects and participants actual messages
* Able to package the whole exercise details (organisations, participants, injects and messages etc) up into a package, and transfer it to another machine
* Allow participants/exercise control to record actions e.g. that they have undertaken a certain action at that time and record it in the master log
* Able to track a particular thread of exercise messages (including original and related injects, as well as participants messages)
=== Exercise Review === 
* Able to play through a recorded 'exercise' and review messages

== Implementation Notes ==
I wonder if this should be build as an extension to the hrm_training_event & [BluePrintScenario event_scenario] modules

=== Static Pages ===
Can easily be done using the CMS module
=== Internal Messaging System ===
I guess the point about not using the real Email/SMS networks is that we don't wish to be dependent on these?

What I see here is simple Store & Forward, no need for real-time Chat.

I do have a concern about this distracting the user from the rest of the system if this functionality wouldn't be something used outside of simulations, so I'm wondering whether this should be built upon project/task so they see these messages from their 'My Tasks' view....we then build a notification box visibile in the user profile area (so every page) so see that there are unread tasks there (& ideally how many) which provides 1-click access to these.

== See Also ==
* [http://wiki.sahanafoundation.org/doku.php/community:gsoc:gsoc2012:ideas#simulation_generator Simulation generator propoject proposal for GSoC 2012]
* http://dfmerrick.wordpress.com/2012/05/01/making-sense-of-the-info-flood-a-social-media-exercise-system/