1. Cash Doctor Mobile Application 3.0 Team 12 DCR ARB 1

2. Introduction Cash Doctor Mobile application provides: The primary purpose of the Cash Doctor Mobile Application 3.0 is empowering consumers with control over the cost and quality of care by sharing pricing and review information of healthcare. 2

3. Team 12 (Team CashDoc) Steven Helferich: Project Manager Kenneth Anguka: IIV&V Xichao Wang: Operational Concept Engineer Alisha Parvez: Life Cycle Planner Ekasit Jarussinvichai: Requirements Engineer Kshama Krishnan: Prototyper Le Zhuang: Feasibility Analyst Shreya Sharma: Software Architect 3

4. Glossary TermALIASESMeaning Consumer User, Customer The consumer is the user for the application, the one who provides data, searches for it, compares it and/or networks for it. ProviderUser, Doctor The provider is either a doctor or an institution of doctors/hospital providing their rates for services, specialitites and/or offers. NetworkGroup A network is the result of consumers collaborating with consumers and providers by following groups based on different criterias. ProfileDashboardThe profile provides the details about a consumer CorporationsCompanies It is a group of a corporation, allowing only employees to join using some method. FollowSubscibe It is when a consumer clicks the follow link on the provider or group profile

5. Team Strengths & Weaknesses Strengths Operational: Coordination and Cohesiveness Technical: Savvy to new technology Actively address major risks Weaknesses Operational: Schedules  Communicating over electronic media is difficult Technical: Proprietary Software usage  mitigated! 4

6. Test Plan and Cases 5

7. Test Strategy and Preparation The test strategy that we will employ will involve testing of the user interface as well as testing of the underlying logic and data processing code. There will be programmatic separation of the user interface code from the logic and data processing code in order. Application’s functionality will be tested independently from the user interface. 6

8. Hardware Preparation Our application will eventually run on three different hardware platforms. –iPhone 6 –Samsung Galaxy Note 4 –Nokia Lumia 830. These three hardware platforms will provide us a good variation of screen sizes and software platforms Each device will exercise the iOS, Android, and Windows Phone OS platforms. 7

9. Software Preparation Prior to obtaining hardware, our application will be emulated to run on the iPhone SDK, Android SDK, and the Windows Phone SDK. 8

10. Requirements 9

11. Requirements Cont. 10

12. Requirements Cont. 11

13. Staffing 12

14. Testing Schedule 13

15. Operational Concept Description 14

16. Benefit-Chain Diagram System Boundary Element Relationship Diagram WorkFlow of Proposed System 15

17. Benefit-Chain Diagram 16

18. System Boundary 17

19. Element Relationship Diagram 18

20. Workflow of Proposed System 19

21. Prototype 20

22. Prototype - Integration with Server 21

23. 22

24. Prototype - Integration with Server 23

25. 24

26. Sample of typical medical bills (A)(B)(C) 25

27. Sample of typical medical bills (A)(B)(C) 26

28. Sample of typical medical bills Description Price No medical code! 27

29. Sample of typical medical bills DescriptionQuantityPriceCode 28

30. Sample of typical medical bills 29

31. Sample of typical medical bills 30

32. REQUIREMENTS 31

33. 32

34. Requirements 33 WC_3082 System shall capture an image and code an invoice for sharing. WC_3085 System shall integrate with the existing database at Cash Doc. WC_3079 System shall run on iPhone, Android, and Windows phone. WC_3084 System shall search for healthcare pricing, provider by location, price, code, and specialty. WC_3087 System shall allow consumer access to his/her existing account by user ID and password, and can view his/her existing dashboard. WC_3077 (Analysis) System will be appealing to the target consumer (80% female).

35. Requirements 34 WC_3090System shall allow consumer to compare healthcare prices. WC_3083 System shall allow consumers to manually enter price information for sharing. WC_3086System shall allow consumer to register as a user. WC_3089 System shall allow consumer to create a review of a provider. WC_3088 System shall allow consumer to create a private network and join existing networks. WC_3094 System shall allow users to find their current location to access relevant providers in and around area (some mile radius).

36. Requirements 35 WC_3076 (Analysis)System will be easy to use and intuitive by all users. WC_3080 (Analysis) System shall be able to support at least 1000 simultaneous users. WC_3098 System shall allow a user to subscribe to notifications so that he/she shall have access to relevant up-to-date information. WC_3091System shall allow consumer to rate a provider. WC_3093 System shall allow provider to share pricing, offerings, and other content so as to drive traffic and increase sales. WC_3078 (Analysis) System will be accurate within a 5 mile radius at a 90% confidence interval.

37. Requirements 36 WC_3186 System shall allow a user to create a health profile that will attach profile specific offers from providers WC_3187 System shall be able to receive push content from provider and relay it to users. Push content shall be unique to user's personal profile. WC_3092 System shall allow a corporation to view its employees and the prices they've shared so as to encourage participation. WC_3185 System shall allow a user to gain access to features when the user shares health care pricing WC_3097 System shall allow a provider to send offerings to users that are connected to their network so that they can drive volume and increase sales. WC_3095 System shall allow a user to filter notifications. User shall be able to filter based on location, price, code, specialty, and provider.

38. System and Software Architecture Description 37

39. SYSTEM CONTEXT 38

40. BEHAVIOUR

41. OVERVIEW JSON data Server Side

42. ARTIFACTS AND INFORMATION DIAGRAM

43. DESIGN DIAGRAM

44. SOFTWARE COMPONENT MODEL

45. DESIGN PATTERNS AND FRAMEWORKS Front-end development framework based on HTML+CSS+JS Client side Javascript Model View Framework Mobile development framework 45

46. NCS Open source OCR engine for scanning medical bills 46

47. Feasibility Evidence Description 47

48. Feasibility Evidence Business case analysis – ROI analysis Major Risks NDIs and Capability Feasibility 48

49. Business Case Analysis Cost Analysis YearPersonnel Cost (hour) Personnel Cost (dollar) Software/Hard ware Cost (dollar) Total (dollar) 2014 3193013002230 2015 57617280100018280 2016 100030000100031000 2017 100030000100031000 2018 200060000200062000 49

50. Business Case Analysis Revenue / Profit Analysis Year Optimistic Userbase Conservati ve Userbase Optimistic Revenue Conservati ve Revenue Optimistic Profit Conservativ e Profit 201400 00-2230 2015500250 56252812.5-12655-15467.5 20162,0001,000 2250011250-8500-19750 20178,0004,000 90000450005900014000 201820,00010,000 22500011250016300050500 Revenue = $600 billion * (userbase / population of US) * 1% * 15% Profit = Revenue - Cost 50

51. Business Analysis 51

52. Major Risks RiskPotential Magnitude Probability LossRisk Exposure OCR Failure on Mobile Platform 41040 Back-end Incompatibility 7963 Platform Inconsistency 7856 Performance Limitation 6954 Scalability Uncertainty 6848 Personal Time Constraints 7856 Client Time Constrains 6636 Team Cohesion Failure 4936 52

53. NDIs and Capability Feasibility NDIs: Ke Solution, Google Map, Tesserate OCR, Apache Cordova Connectors: Bootstrap, jQuery, Backbone.js 53

54. NDIs and Capability Feasibility Capability RequirementApp-server interaction Native APIs Geo- location OCREasy UI Manual Information SearchXX Geo-Location SearchXXXX Price ComparisonXXXX User RegistrationXX Price SharingXXXXX Provider RatingXX NetworkingXX Profile ManagementXX Notification ManagementXXX 54

55. Life Cycle Plan 55

56. Purpose of the LCP The LCP helps in identifying tasks and their corresponding timelines. The LCP also lists down all the milestones and artifacts delivered according to the phases. It lists out the strategies to be followed in the project and also the skills required by each team member. The LCP is documented to provide details as to what is the status of the project and what is the future plan. It lists down the tools and resources being used in the project. It also defines each stakeholder’s responsibilities according to different phases. In a nutshell, LCP improves the quality of the project by proper planning and also reduces the risk exposure. Status of the LCP The status of the LCP is currently at the Draft Development Commitment Package version number 3.0. This is the version that will be delivered to the client. The major changes from Valuation phase are inclusion of iteration plan for the next semester and the strategy for development phase. 56

57. Assumptions The duration of the project is 24 weeks, which are 12 weeks in fall 2014 and 12 weeks in spring 2015. The project involves 8 personnel resources. Team meetings are held each week to discuss on the future tasks of the project. 57

58. RESPONSIBILITIES 58

59. 59

60. 60

61. SKILLS 61

62. A PPROACH Monitoring and Control -The effort spent on the project is being recorded on Bugzilla. -The number of lines of code is logged on as project report every two weeks. -Communication with the client is being done through Winbook and emails. -Commitment review is done before moving into each phase. The overall strategy is reported through project plan every two weeks. Closed Loop Feedback Control The team internally communicates through emails and google drive to keep everyone updated. The team also has team meeting every week to discuss about what we did in the previous week and what we are supposed to do next week. 62

63. S TRATEGY FOR N EXT S EMESTER Rebaseline Foundations Phase Duration:12/12/2014-02/11/2015 Concept: In this phase, the team will rebaseline prototypes, prioritize requirements, focus on key risk items. Deliverable: Rebaselined Development Commitment Package Milestone: Rebaselined DCR ARB Strategy: One Incremental Commitment Cycle Development phase - Construction Iteration Duration:02/11/2015-03/25/2015 Concept: In this phase, the development team should keep detailing project plan and recording project progress and emphasize on implementing the system and performing tests. Such a construction process should be iterated several times in this period of time. Besides, several milestones will be walked through in this phase, which includes core capability drivethrough and transition readiness review. Deliverable: Transition Readiness Review Package, Draft Transition Readiness Review Package Milestone: Transition Readiness Review, Core Capability Drivethrough Strategy: One Incremental Commitment Cycle 63

64. Development phase - Transition Iteration Duration:03/25/2015-04/27/2015 Concept: In this stage, the development team should perform system transition by providing maintenance information, tutorial session, technical support, as well as user menu which covers different user roles. The milestone of this phase is operational commitment review, which would directly lead to the final product release. Deliverable: Operational Commitment Review Package, Transition manual, Source code Milestone: Operation Commitment Review Strategy: One Incremental Commitment Cycle 64

65. Reviews ARB: This is a review that we perform with instructors and TAs to analyze our project progress. Team Meeting: Every Monday, the on-campus team has group meeting discussing about the progress and to-dos. The den-student is kept updated through mails and google drive documents. Bugzilla: We have maintained Bugzilla to trace our progress 65

66. Methods, Tools and Facilities 66 TOOLSUSAGEPROVIDER BugzillaTracks project progressTA WinbookKeeps track of the information resulting from negotiations with client, win conditions and issues raised TA Microsoft Visio Documents OCD workflow Microsoft Microsoft OfficeDocuments editing, sheets, presentations etc… Microsoft Visual ParadigmCaptures UML and auto generate SSAD Visual Paradigm International COINCOMOEstimates the software developing cost USC CSSE Effort ReportRecords the total weekly working hours on the project USC CSSE MPPMakes the project planMicrosoft Project ReportRecords lines of codeMicrosoft Balsamiq mockupsFor prototypingBalsamiq

67. Resources The following conditions were used to estimate the cost of our system, CashDoctor 3.0 Mobile App. This project has no budget for our development efforts, while the software is provided and tools are free. The duration of the project is 12 weeks in CSCI577a The duration of the project is 12 weeks in CSCI577b. There are eight team members. There are four modules in this system. Search module Share module Capture module Networking module Programming language is JavaScript The SLOC is estimated by prototyper 67

68. COINCOMO ESTIMATE According to COINCOMO, our most likely effort value is 43.63 and our most likely staff value is 6.3. 68

69. 69 P ROJECT P LAN

70. Quality Management Plan 70

71. Traceability Matrix OC-1 Manual Information SearchWC_3084UC4: Search healthcare information OC-2 Geo-Location Search WC_3084 WC_3094UC4: Search healthcare information OC-3 Price ComparisonWC_3090 UC12: Customer can compare medical price information OC-4 User RegistrationWC_3086 UC1: Create/Login customer profile UC8: Create/Login Provider profile OC-5 Price Sharing WC_3083 WC_3082 UC3: Prices shared by the customers UC9: Provider shares Healthcare Information OC-6 Provider Rating WC_3089 WC_3091UC11: Customer can rate/review a provider OC-7 NetworkingWC_3088 UC5: Create a network UC6: Join an existing network OC-8 Profile ManagementWC_3187UC2: Update customer Profile OC-9 Notification Management WC_3098 WC_3095UC7: Get notified based on the network subscribed for 71

72. Quality Management Strategy Project Manager and IIV&V reviews all Bugzilla tasks on a weekly basis. Report is emailed to the team. 72

73. Metrics and Tracking Current metrics used are bug-tracking at the moment Bugs pending, in progress, and resolved Average task life is 1 week currently Development phase will necessitate more metrics Burndown charts Testing metrics Tests planned, Tests executed Potential User Surveys of UI 73

74. Defect Identification Reviews Documents are reviewed by IIV&V and Project Manager prior to closing a task Mostly task tracking, but will become bug tracking by Spring 2015 semester Currently: 2 CONFIRMED 3 IN_PROGRESS 38 RESOLVED 74

75. Conclusion Team has the technical knowledge we need to move into development of the application Major risks have been assessed: Those that have not been directly resolved have mitigation plans in place Prototyping has been a major risk mitigation strategy Team feels confident moving into development phase 75

76. Questions? 76