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

Anupam Kumar Introduction

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

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.

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

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

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

Anfal Abdul Jaleel & Nanda Kishore Kolleje Rao Demo

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

Architecture Mobile Application MedFRS Server Web Application

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

Demo – Screenshots- Maintenance

Demo - Screenshots

Demo - Screenshots

Demo - Screenshots

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

Demo – Screenshots- Disaster

Demo – Screenshots- Disaster

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

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

Misha Dowd Support Plan

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

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

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

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

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.

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

Test Result 20 Tests 18 Passed 1 Failed 2 Bugs

Jackie Cheng Quality focal point

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 *

Defect Status ARB CCD TRR ARB CCD TRR

Effort Indicator

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

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

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 *

Summary of Transition Plan

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

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

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

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

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

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.

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.

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.

Stakeholder roles & responsibilities Delnaz Gundevia Stakeholder roles & responsibilities

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/2013-11/24/2013 Fix the bugs found in CCD prototype 11/26/2013-12/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

    Delnaz Gundevia Milestone Plan

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.

Misha Dowd Required Resources

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

Software product elements Misha Dowd Software product elements

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: http://greenbay.usc.edu/csci577/fall2013/projects/team16/

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

Thank You