1. MedFRS Device Diagnostic Software Transition Readiness Review Architected Agile December 4, 2013
Misha Dowd, Project Manager
Delnaz Gundevia, Life Cycle Planner
Anfal Abdul Jaleel, System Architect
Nanda Kishore Kolleje Rao, Prototyper
Anupam Kumar, Feasibility Analyst
Jackie Cheng ,IIV&V

2. Anupam Kumar
Introduction

3. Operational Concept Overview
Project Objective
To create a system to expedite triage tagging in the event of a hazardous incident, and help EMT and EMS organize and coordinate their emergency response.
Goals
Expedite time for triage
Help maintain order in a chaotic medical situation 
Empower community to cope with disaster

4. Terminology & Definitions
EMT – Emergency Medical Technician
EMS – Emergency Medical Services (Medical, fire, police)
Hazard - A situation that poses a level of threat to life, heath, property or environment. A hazard that comes to pass becomes a hazardous incident. The scale of hazard can effect a few isolated people or large masses of people.
Triage tagging - The assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients or casualties.

5. Outline Introduction Core capability Demo Support Plan
Test cases and results
Quality focal point
Summary of Transition Plan
Feedback

6. Transition Strategy
Realize that project scope is very large for completion in a semester
Develop a working prototype with the essential features that captures the essence of the project objective
Set up the infrastructure, tools and handover the prototype along with the supporting documents to the client

7. Transition Objectives
To set up the foundation so that the client can use this foundation to expand the scope in the future (even in our absence)
To familiarize the client with the working of our prototype
To make the client aware of the capabilities and the limitations of our prototype
To consult the client on what the next steps should be

8. Anfal Abdul Jaleel & Nanda Kishore Kolleje Rao
Demo

9. Requirements Achieved
Victim Data Collection Application
Victim Categorization and ID System
Victim Data Sync System
Supervisor Management Console
Transport Coordinator Management Console

10. Architecture
Mobile Application
MedFRS Server
Web Application

11. Supervisor-Non Emergency
Add, Delete and Manage Hubs and buildings
Register and Manage Volunteers and Issue OTP
Register and Manage Supervisors and Transport Coordinators
Manage Database Tables

12. Demo – Screenshots- Maintenance

13. Demo - Screenshots

14. Demo - Screenshots

15. Demo - Screenshots

16. Supervisor-Emergency
Add disaster.
Aggregate victim information
Assign and print data for EMT

17. Demo – Screenshots- Disaster

18. Demo – Screenshots- Disaster

19. Volunteer Collect Victim Information Tag and ID the Victim
Submit Victim Data to the Server
Scan Barcode to retrieve Information of the Victim for Treating

20. Transport Coordinator Emergency
Assign Victim to Ambulances
Track and Update Victim Transport Details

21. Misha Dowd
Support Plan

22. SUPPORT PLAN
As of now the development team will not support any further development of the system
Development team will provide training and a list of future enhancements that we think will benefit the system

23. Test Case, Procedures and Results
Anfal Abdul Jaleel
Test Case, Procedures and Results

24. Test Cases ID Test Case TC 01 Application Authorization TC 02
Victim Data Collection
TC 03
Victim Data Retrieval
TC 04
Application Data
TC 05
Application Performance
TC 06
Database Performance
TC 07
Data Security
TC 08
Adding disasters
TC 09
Choosing disasters
TC 10
Record EMT building assignments
TC 11
View victims
TC 12
Update emergency tables
TC 13
Manage Buildings/hubs/disasters in database

25. Test Cases ID Test Case TC 14 Add building TC 15 Login TC 16
Add web user
TC 17
Add volunteer
TC 18
Manage users
TC 19
Manage volunteers

26. Testing Procedure All cases were tested manually
The functionality as well as unit integration testing for the iPhone app was done by Nandu
The functionality as well as unit integration testing for the website was done by Anfal
System integration testing for the mobile app and the website were done by Nandu, Anfal and Anupam
For each functionality, we tested for typical courses of actions as well as exceptional courses of action.

27. Testing Procedure
We assigned criticality of the test cases mainly based on business importance and then on design.

28. Test Result
20 Tests
18 Passed
1 Failed
2 Bugs

29. Jackie Cheng
Quality focal point

30. Matrix Reporting Win-Win Condition Bugzilla All 19 conditions Agreed
Each Condition is Categorized
18 out of 19 Conditions are ranked
Need to ensure client rank all the conditions
Bugzilla
32 out of 36 Bugs fixed and resolved
Outstanding Bugs are related to the prototype *

31. Defect Status
ARB
CCD
TRR
ARB
CCD
TRR

32. Effort Indicator

33. Solved Capability Goals
OC-1 Ability for volunteer to record victims condition (breathing, perfusion, mental state)
OC-2 Ability for volunteer to record victims vital stats
OC-3 Ability for volunteer to record victims identification information (name, age, sex, USCID, license etc.)
OC-4 Ability for volunteer to record victims other medical details as comment (broken bones, torn muscles, contamination etc.)
OC-5 Ability for system to classify victims condition automatically
OC-6 Ability for the Hub Supervisor to sort victim’s list based on victim condition and building name alphabetically
OC-7 Ability for supervisor to assign EMTs to buildings
OC-8 Ability for Supervisor/Transport Coordinator release EMTs from buildings
OC-9 Ability for Volunteer to scan barcode
OC-10 Ability for volunteer to retrieve all information about victim from system
OC-11 Ability for volunteer to enter room number/floor number/other relevant location information
OC-12 Ability for Transport Coordinator to note victim’s transport details and destination

34. Technical Debt Offline Data Sync Data Encryption
Multi Smartphone Support
Comprehensive Supervisor and Transport Co-coordinator panel

35. Test Case ID (if applicable)
Traceability Matrix
Requirement ID
Test Case ID (if applicable)
WC_2741
TC-01, TC-15, TC-16, TC-17, TC-18, TC-19
WC_2634
TC-02
WC_2635
WC_2636
WC_2637
WC_2638
WC_2755
WC_2757
WC_2641
TC-03
WC_2639
WC_2797
TC-04. TC-11
WC_2796
TC-05, TC-06, TC-08, TC-09, TC-12, TC-13, TC-14
WC_2742
TC-06
WC_2760
TC-06, TC-10
WC_2762
WC_2640
TC-10 *

36. Summary of Transition Plan

37. HW, SW, Site & Staff Preparation
Anupam Kumar
HW, SW, Site & Staff Preparation

38. Hardware preparation
To set up our prototype and development environment we would require:
A Macintosh machine
A Linux or windows machine
An iOS device (ipad or iphone)
Hardware requirements in the future iterations:
An android and windows based mobile device
Security certificate authority server

39. Software preparation To setup the prototype:
Install client app on iOS device
Install and set up web server on Linux machine
Install and set up MySQL database server on Linux machine
To setup the tool chain and development environment
Install XCode IDE on Macintosh machine
Install Eclipse IDE on windows/mac/Linux machine

40. Site and Staff preparation
Provide training sessions to the client on the system in general
Provide consulting sessions to the client
Walk the client through all the features and providing detailed explanation about each of them

41. Operational Testing, Training & Evaluation
Anfal Abdul Jaleel
Operational Testing, Training & Evaluation

42. Operational Testing
We plan to have our client Julie use the system after our given training.
We will note any problems she runs into and her feedback.
We shall update the system according to the feedback.

43. Operational Training
We shall walk through the modified Operating Procedure that we have envisioned while demoing the product to our client
We shall allow the client to use our system without any assistance from the team
We shall define/clarify any steps that caused confusion.

44. Operational Evaluation
Metrics
Functionality : whatever could be achieved (victim categorization and treatment time) using the old system can be achieved with this system
Benefit : Victim categorization and treatment time is lower with the new system
Bonus : After the disaster victims can be tracked and located easily.

45. Stakeholder roles & responsibilities
Delnaz Gundevia
Stakeholder roles & responsibilities

46. Stakeholder Roles and Responsibilities
Date
Role
Responsibility
11/16/2013
Developers
Developed the prototype partially
11/17/2013
Tester
Tested the product in acceptance environment
11/18/2013
Client
Tested the product
11/19/ /24/2013
Fix the bugs found in CCD prototype
11/26/ /03/2013
Developing the remaining components
12/04/2013
12/09/2013
Team
Handover the product to the client
12/12/2013
Train the client

47. Delnaz Gundevia
Milestone Plan

48. Milestone Plan Transition phase Start Date - 12/02/2013
Concept - Handover the product to the client and train her to operate the system. Complete all the supporting documentation and finish all the testing.

49. Misha Dowd
Required Resources

50. Required Resources Apple Software Liscense
Apple iPhone iOS 4S or later
At least 1 laptop for every supervisor and transportation coordinator
Laptop Specifications:
Windows XP or later
1 GB of RAM Memory
Wireless Connectivity
Hand Scanner for each laptop (optional)
Dedicated Server running Apache Tomcat 2.4

51. Software product elements
Misha Dowd
Software product elements

52. Software product elements
Code
Mobile application:MedFRS_PRO.app
MedFRS Database (MedFRS.sql)
MedFRS Server Scripts (PHP and Ruby on Rails)
Documentation:
CCD_TRR_F13a_T16_V1.0
FED_TRR_F13a_T16_V3.1
LCP_TRR_F13a_T16_V4.0
OCD_TRR_F13a_T16_V3.1
SSAD_TRR_F13a_T16_V3.0
TM_TRR_F13a_T16_V1.0
TP_TRR_F13a_T16_V1.0
TPC_DCP_F13a_T16_V2.0
TPR_TRR_F13a_T16_V1.0
UM_TRR_F13a_T16_V1.0
UML_TRR_F13a_T16_V3.0
Team Website:

53. Vision Create the next level of Disaster Management System
Cheap Alternative for the existing expensive Paper based system
Always Reliable And Consistent

54. Thank You