Cash DoctorMobile Application 3.0

Team 12DCR ARB

1

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

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

GlossaryTerm ALIASES Meaning

ConsumerUser, Customer

The consumer is the user for the application, the one who provides data, searches for it, compares it and/or networks for it.

Provider User, DoctorThe provider is either a doctor or an institution of doctors/hospital providing their rates for services, specialitites and/or offers.

Network GroupA network is the result of consumers collaborating with consumers and providers by following groups based on different criterias.

Profile Dashboard The profile provides the details about a consumer

Corporations CompaniesIt is a group of a corporation , allowing only employees to join using some method.

Follow SubscibeIt is when a consumer clicks the follow link on the provider or group profile

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

Test Plan and Cases

5

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

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

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

Requirements

9

Requirements Cont.

10

Requirements Cont.

11

Staffing

12

Testing Schedule

13

Operational Concept Description

14

• Benefit-Chain Diagram

• System Boundary

• Element Relationship Diagram

• WorkFlow of Proposed System

15

Benefit-Chain Diagram

16

System Boundary

17

Element Relationship Diagram

18

Workflow of Proposed System

19

Prototype

20

Prototype - Integration with Server

21

22

Prototype - Integration with Server

23

24

Sample of typical medical bills

(A) (B) (C)

25

Sample of typical medical bills

(A) (B) (C)

26

Sample of typical medical bills

Description Price

No medical code!

27

Sample of typical medical bills

Description Quantity PriceCode

28

Sample of typical medical bills

29

Sample of typical medical bills

30

REQUIREMENTS

31

32

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_3087System 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).

Requirements

34

WC_3090 System shall allow consumer to compare healthcare prices.

WC_3083 System shall allow consumers to manually enter price information for sharing.

WC_3086 System 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_3094System shall allow users to find their current location to access relevant providers in and around area (some mile radius).

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_3098System shall allow a user to subscribe to notifications so that he/she shall have access to relevant up-to-date information.

WC_3091 System shall allow consumer to rate a provider.

WC_3093System 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.

Requirements

36

WC_3186 System shall allow a user to create a health profile that will attach profile specific offers from providers

WC_3187System 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_3097System 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_3095System shall allow a user to filter notifications. User shall be able to filter based on location, price, code, specialty, and provider.

System and Software Architecture Description

37

SYSTEM CONTEXT

38

BEHAVIOUR

OVERVIEW

JSON data

Server Side

ARTIFACTS AND INFORMATION DIAGRAM

DESIGN DIAGRAM

SOFTWARE COMPONENT MODEL

DESIGN PATTERNS AND FRAMEWORKS

Front-end development framework based on HTML+CSS+JS

Client side Javascript Model View Framework

Mobile development framework

45

NCS

Open source OCR engine for scanning medical bills

46

Feasibility Evidence Description

47

Feasibility Evidence

•Business case analysis – ROI analysis•Major Risks•NDIs and Capability Feasibility

48

Business Case Analysis

Cost AnalysisYear Personnel Cost

(hour)Personnel Cost

(dollar)Software/

Hardware Cost (dollar)

Total (dollar)

2014 31 930 1300 22302015 576 17280 1000 182802016 1000 30000 1000 310002017 1000 30000 1000 310002018 2000 60000 2000 62000

49

Business Case Analysis

Revenue / Profit AnalysisYear Optimistic

Userbase

Conservative

Userbase

Optimistic Revenue

Conservative Revenue

Optimistic Profit

Conservative Profit

2014 0 0 0 0 -2230 -2230

2015 500 250 5625 2812.5 -12655 -15467.5

2016 2,000 1,000 22500 11250 -8500 -19750

2017 8,000 4,000 90000 45000 59000 14000

2018 20,000 10,000 225000 112500 163000 50500

Revenue = $600 billion * (userbase / population of US) * 1% * 15%Profit = Revenue - Cost

50

Business Analysis

51

Major Risks

Risk Potential Magnitude

Probability Loss Risk Exposure

OCR Failure on Mobile Platform 4 10 40

Back-end Incompatibility 7 9 63

Platform Inconsistency 7 8 56

Performance Limitation 6 9 54

Scalability Uncertainty 6 8 48

Personal Time Constraints 7 8 56

Client Time Constrains 6 6 36

Team Cohesion Failure 4 9 36

52

NDIs and Capability Feasibility

•NDIs: Ke Solution, Google Map, Tesserate OCR , Apache Cordova

•Connectors: Bootstrap, jQuery, Backbone.js

53

NDIs and Capability FeasibilityCapability Requirement App-server

interactionNative APIs

Geo-location

OCR Easy UI

Manual Information Search X X

Geo-Location Search X X X X

Price Comparison X X X X

User Registration X X

Price Sharing X X X X X

Provider Rating X X

Networking X X

Profile Management X X

Notification Management X X X

54

Life Cycle Plan

55

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

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

RESPONSIBILITIES

58

59

60

SKILLS

61

APPROACH

•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

STRATEGY FOR NEXT SEMESTER•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

•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

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

Methods, Tools and Facilities

66

TOOLS USAGE PROVIDER

Bugzilla Tracks project progress TA

Winbook Keeps track of the information resulting from negotiations with client, win conditions and issues raised

TA

 Microsoft Visio

 Documents OCD workflow

 Microsoft

Microsoft Office Documents editing, sheets, presentations etc…

Microsoft

Visual Paradigm Captures UML and auto generate SSAD

Visual Paradigm International

COINCOMO Estimates the software developing cost

USC CSSE

Effort Report Records the total weekly working hours on the project

USC CSSE

MPP Makes the project plan Microsoft

Project Report Records lines of code Microsoft

Balsamiq mockups For prototyping Balsamiq

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

COINCOMO ESTIMATE

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

68

69

PROJECT PLAN

Quality Management Plan

70

Traceability MatrixOC-1 Manual Information Search WC_3084 UC4: Search healthcare information

OC-2 Geo-Location SearchWC_3084WC_3094 UC4: Search healthcare information

OC-3 Price Comparison WC_3090UC12: Customer can compare medical price information

OC-4 User Registration WC_3086UC1: Create/Login customer profileUC8: Create/Login Provider profile

OC-5 Price SharingWC_3083WC_3082

UC3: Prices shared by the customersUC9: Provider shares Healthcare Information

OC-6 Provider RatingWC_3089WC_3091 UC11: Customer can rate/review a provider

OC-7 Networking WC_3088UC5: Create a networkUC6: Join an existing network

OC-8 Profile Management WC_3187 UC2: Update customer Profile

OC-9 Notification ManagementWC_3098WC_3095 UC7: Get notified based on the network subscribed for

71

Quality Management Strategy

• Project Manager and IIV&V reviews all Bugzilla tasks on a weekly basis.

• Report is emailed to the team.

72

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

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

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

Questions?

76