MedFRS Device Diagnostic SoftwareTransition Readiness ReviewArchitected Agile December 4, 2013

Misha Dowd, Project ManagerDelnaz Gundevia, Life Cycle PlannerAnfal Abdul Jaleel, System ArchitectNanda Kishore Kolleje Rao, PrototyperAnupam Kumar, Feasibility AnalystJackie Cheng ,IIV&V

INTRODUCTIONAnupam Kumar

2

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

3

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.

4

Outline

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

5

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

6

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

7

DEMOAnfal Abdul Jaleel & Nanda Kishore Kolleje Rao

8

Requirements Achieved

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

9

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

SUPPORT PLANMisha Dowd

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

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

QUALITY FOCAL POINTJackie Cheng

30

*

Matrix Reporting

• Win-Win Condition• 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

0

5

10

15

20

25

30

35

40

Total Bugs

6-Oct

9-Oct

12-Oct

15-Oct

18-Oct

21-Oct

24-Oct

27-Oct

30-Oct

2-Nov

5-Nov

8-Nov

11-Nov

14-Nov

17-Nov

20-Nov

23-Nov

26-Nov

29-Nov

2-Dec

0

2

4

6

8

10

12

14

Bugs Over Time

Open bugs Close bugsTotal Active bugs

ARB

CCD

TRR

Defect StatusAR

B

CCD

TRR

32

Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14

3545

2735

3250

6660.5

3730.5

1892.5

2856

2362

1920

Weekly Total Member Hours

Effort Indicator

33

SolvedCapability 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 alphabeticallyOC-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 informationOC-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

*

Traceability Matrix

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

36

SUMMARY OF TRANSITION PLAN

37

HW, SW, SITE & STAFF PREPARATIONAnupam Kumar

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 & EVALUATIONAnfal Abdul Jaleel

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

• Metricsi. Functionality : whatever could be achieved (victim

categorization and treatment time) using the old system can be achieved with this system

ii. Benefit : Victim categorization and treatment time is lower with the new system

iii. Bonus : After the disaster victims can be tracked and located easily.

45

STAKEHOLDER ROLES & RESPONSIBILITIES Delnaz Gundevia

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

11/26/2013-12/03/2013 Developers Developing the remaining components

12/04/2013 Tester Tested the product in acceptance environment

12/09/2013 Team Handover the product to the client

12/12/2013 Team Train the client47

MILESTONE PLANDelnaz Gundevia

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

REQUIRED RESOURCESMisha Dowd

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 ELEMENTSMisha Dowd

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

53

Vision

• Create the next level of Disaster Management System• Cheap Alternative for the existing expensive Paper based

system• Always Reliable And Consistent

54

55

Thank You