CASH DOCTOR MOBILE APP: RDCR ARB TEAM 12 2/10/14.

CASH DOCTOR MOBILE APP:RDCR ARB

TEAM 12

2/10/14

2

Team Members▪ 7 returning team members, 1 new

Team Member Role

Rob Stehlin Client

Alisha Parvez Developer/Life Cycle Planner

Danny Lee Quality Focal Point/Trainer

Ekasit Jarussinvichai Developer

Kenneth Anguka IV&V

Le Zhuang Developer/Feasibility Analyst

Shreya Sharma Tester

Steven Helferich Project Manager

Xichao Wang Tester

3

Team Strong and Weak Points

Strong points Weak points

Fast learners and hard working Inexperienced in Backbone.js

Good communication within the team

Proprietary software usage

Actively look address to major risks

Conflicting schedules

Ample previous work experience

Contacting backend team

4

What else has changed?▪ New team member▪ Needed to bring him up to speed on project progress and details

▪ Dropped components▪ Agreement at last ARB to table the Tesseract OCR in favor a user-

submitted form

▪ Development has begun▪ The first features have been developed, including the Share and

Search features

5

Project Evaluation▪ Team has rebounded from prototyping problems in the first

semester well▪ Overall positive attitude in team meetings and a desire to solve

the any problems in development▪ Prototyped the most valuable features of the application and can

now begin full development

▪ Some risks and problems remain, mostly in coordinating with the backend team▪ This particular risk has potentially been mitigated recently

▪ Team is very confident in being fully prepared for a successful CCD in late March and a fully functioning application at transition time

6

Full Test Cases and PlanRequirement ID Requirement Description Verification Type Test Case ID (if

applicable)

WC_3082 System shall capture an image and user entered invoice details for sharing. Demo TC-01

WC_3085 System shall integrate with the existing database at Cash Doctor. Testing TC-02

WC_3079 System shall run on iOS, Android, and Windows Phone. Demo TC-03

WC_3084 System shall search for healthcare pricing, provider by location, price, code, and specialty. Demo TC-04

WC_3087System shall allow consumer access to his/her existing account by user ID and password, and can view his/her existing dashboard.

Demo TC-05

WC_3077 System will be appealing to the target consumer (80% female). Analysis LOS-1

WC_3090 System shall allow consumer to compare healthcare prices. Demo TC-06

WC_3083 System shall allow consumers to manually enter price information for sharing. Demo TC-07

WC_3086 System shall allow consumer to register as a user. Demo TC-08

7

Full Test Cases and PlansRequirement ID

Requirement Description Verification Type Test Case ID (if applicable)

WC_3089 System shall allow consumer to create a review of a provider. Demo TC-09

WC_3088 System shall allow consumer to create a private network and join existing networks. Demo TC-21

WC_3094System shall allow users to find their current location to access relevant providers in and around area (some mile radius).

Demo TC-10

WC_3076 System will be easy to use and intuitive by all users. Analysis LOS-2

WC_3080 System shall be able to support at least 1000 simultaneous users. Analysis LOS-3

WC_3098System shall allow a user to subscribe to notifications so that he/she shall have access to relevant up-to-date information.

Demo TC-11

WC_3091 System shall allow consumer to rate a provider. Demo TC-12

WC_3093System shall allow provider to share pricing, offerings, and other content so as to drive traffic and increase sales.

Demo TC-13

WC_3078 System will be accurate within a 5 mile radius at a 90% confidence interval. Analysis TC-14

8

Full Test Cases and PlansRequirement ID

Requirement Description Verification Type Test Case ID (if applicable)

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

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.

Demo TC-16

WC_3092System shall allow a corporation to view its employees and the prices they've shared so as to encourage participation.

Demo TC-17

WC_3185 System shall allow a user to gain access to features when the user shares health care pricing Demo TC-18

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.

Demo TC-19

WC_3095System shall allow a user to filter notifications. User shall be able to filter based on location, price, code, specialty, and provider.

Demo TC-20

9

Covered Test Cases▪ Test cases currently being executed:

Test Case Requirement Win ConditionTC-01-01 System shall capture an

image and user entered invoice details for sharing.

WC_3082

TC-01-02 System shall integrate with the existing database at Cash Doctor.

WC_3085

TC-01-05 System shall allow consumer access to his/her existing account by user ID and password, and can view his/her existing dashboard.

WC_3087

TC-01-07 System shall allow consumers to manually enter price information for sharing.

WC_3083

TC-01-08 System shall allow consumer to register as a user. WC_3086

10

Test Cases 1 in detailTest Case Number TC-01-01Test Item Capturing the data

Test Priority M

Pre-conditions CMS database is initialized

Post-conditions User captures a photo, enters details about the invoice, and is able to submit and save this to the database.

Input Specifications The image, total price, and service(s) of the medical bill.

Expected Output Specifications Stores the image and invoice details in the database

Pass/Fail Criteria Pass: System is able to capture image and details of the invoice correctly.Fail: System is unable to capture and save the image or details of the invoice correctly due to any reason

Assumptions and Constraints None

Dependencies NoneTraceability WC_3082

11

Test Cases 2 in detailTest Case Number TC-01-02Test Item Integrate with the existing database

Test Priority M

Pre-conditions CMS database is initialized

Post-conditions System is able to interact with the database successfully

Input Specifications Data is entered in the database

Expected Output Specifications Retrieve the previously entered data from the database

Pass/Fail Criteria Pass: User is able to store/retrieve data into the database and confirm accuracyFail: System is unable to save or retrieve the data

Assumptions and Constraints None

Dependencies NoneTraceability WC_3085

12

Test Case 5 in detailTest Case Number TC-01-05Test Item User is able to successfully access their account page and

view their dashboard.

Test Priority M

Pre-conditions CMS database should be initialized

Post-conditions Mobile application displays the account status page and dashboard

Input Specifications The user’s USERID and PASSWORD

Expected Output Specifications The account page and dashboard

Pass/Fail Criteria Pass: The correct account page and dashboard is displayed.Fail: The account page or dashboard fails to display or contains incorrect information.

Assumptions and Constraints None

Dependencies NoneTraceability WC_3087

13

Test Case 7 in detailTest Case Number TC-01-07Test Item Input content verification

(User is able to manually enter the price on a shared invoice and save to the database.)

Test Priority M

Pre-conditions User is on the share price page

Post-conditions The price has been entered and saved to the database

Input Specifications Price

Expected Output Specifications Page confirming the shared price

Pass/Fail Criteria Pass: Confirmation page displays the manually entered priceFail: User is unable to manually enter the price or the pice entered is not saved to the database.

Assumptions and Constraints None

Dependencies NoneTraceability  WC-3083

14

Test Case 8 in detailTest Case Number TC-01-08Test Item Email verification (User Registration)

Test Priority M

Pre-conditions User is at the registrtation page

Post-conditions User remains at the registration page. A warning appears with the message advising the user to input a valid email address.

Input Specifications Invalid-formed email address has been entered by users

Expected Output Specifications The registration page that informs the users to input a valid email address.

Pass/Fail Criteria Pass: User remains at the registration page with a warning.Fail: User arrives as successful registration page.

Assumptions and Constraints None

Dependencies NoneTraceability WC-3086

15

Test Cases and Plan ScheduleDate Test Identifier Responsible

personResources Training needs

12/08/14 (Prototype) - Shreya Sharma Intel XDK and Manual Testing

Web Technologies, Basic testing

experience, scripting1st Sprint 2015

(Basic Functionality)

TC-01-01, TC-01-02, TC-01-05, TC-01-07,

TC-01-08

Shreya Sharma, Xichao Wang

Selenium WebDriver, Manual Testing

Web Technologies, Basic testing

experience, scripting

2nd Sprint 2015 (Integration with NDIs: Complete)

TC-01-03, TC-01-04 TC-01-06, TC-01-09 TC-01-10 TC-01-11, TC-01-12,

TC-01-13

Shreya Sharma Xichao Wang

Kenneth Anguka, Danny

Lee

iOS SDK, Android SDK iOS SDK, Android SDK

3rd Sprint 2015 (Provider Features)

TC-01-14, TC-01-15, TC-01-16, TC-01-17, TC-01-18, TC-01-19, TC-01-20, TC-01-21

Shreya Sharma Xichao Wang

Kenneth Anguka, Danny

Lee

iPhone 6 Samsung Galaxy 5S

Nokia Lumia 720Windows SDK

4th Sprint 2015 (Corporation

Features and other add ons)

Overall functionalities

Shreya Sharma Xichao Wang

Kenneth Anguka, Danny

Lee

iPhone 6 Samsung Galaxy 5S

Nokia Lumia 720N/A

16

Testing strategy

• Manual Testing (UI Testing, Cross platform testing)

• Automation Testing (Regression and Sanity Testing)

• Unit testing

• Integration testing

• System testing

• Core Capabilities Drive-through

• Requirement Traceability

• Acceptance testing

17

Testing strategy▪ Manual Testing

Detailed level test cases have been made for every high level test case.

Two examples are : Login and Share Page

18

Selenium Automation Testing Framework▪ To test our application in a highly efficient.

▪ Using Java as the language for coding.

▪ Central element of our testing strategy as this saves us time and is more efficient.

▪ Manual and automation would be used together.

▪ Critical and useful for the client after transition.

19

OCD and System Purpose

▪ No major changes in OCD or system purpose since the last ARB

20

21

Prototype Update▪ Major changes to prototype and development trajectory

▪ Last semester spent prototyping high-risk feature that has been tabled by agreement

▪ OCR has been replaced with a user-completed form passed to the database▪ Inconvenient for the user; will have to test with users to get

actual level of inconvenience▪ Simpler for the developers and the backend team

22

Prototype Update▪ Pages under development with testing on a one week lag

from an issue integrating with the backend

▪ Login, Forgot Password, Create Profile, Update Profile pages completed▪ Undergoing testing currently to find defects

▪ Share, Search and Dashboard pages still under development

Prototype Update

23

Dashboard(Consumer)

Dashboard(Provider)

24

Prototype Update

Login Page

▪ WC_3087: As I consumer, I can access my existing account by user ID and password, and can view my existing dashboard.

▪ WC_3086: As a consumer, I can register as a user.

25

Prototype Update

Register Consumer Page

▪ WC_3086: As a consumer, I can register as a user.

26

Prototype Update

Edit Profile Page

▪ WC_3098: As a user, I can follow to notifications so that I will have access to relevant up-to-date information.

27

Prototype Update

Search Page

▪ WC_3084: A consumer can search for healthcare pricing, provider by location, price, code, specialty.

28

Prototype Update

Share Page

▪ WC_3083: A consumer can manually enter price information for sharing.

29

Architecture Overview

JSON data

30

Design Patterns and Frameworks

▪ Backbone.js▪ Client side JavaScript Model-View framework

▪ Bootstrap▪ Front-end development framework based on

HTML, CSS, and JS

▪ Cordova▪ Mobile development framework

31

Software Component Model

32

Architecture Changes▪ Decision made last semester to:▪ Remove usage of open-source OCR engine, Tesseract▪ Too unreliable▪ Not enough development time for other modules▪ Most business value captured by simpler solutions

▪ Replace OCR with user-completed forms▪ Less convenient, in principle, for users▪ Simpler for developers, admins

33

Life Cycle Plan

34

Responsibilities in 577bTeam Member Role Responsibilities

Alisha Parvez Developer, Life Cycle Planner Search Module, Project plan, Deliverables

Danny Lee Quality Focal Point Unit Testing

Ekasit Jarussinvichai

Developer, Prototyper Dashboard, Login submodules, Deliverables

Kenneth Anguka IV & V Testing

Le Zhuang Developer, Feasibility Analyst Edit Profile submodule, Deliverables

Shreya Sharma Automation Tester, System Architect

Unit Testing, Module Testing

Steven Helferich Developer, Project Manger Share Module, Project Report, Deliverables

Xichao Wang Tester, Operational Concept Engineer

Unit testing, Deliverables

35

Iteration Plan

There are two iterations in the development phase.

▪ First iteration(Construction iteration) is subdivided into two iterations- Iteration one for Core Capability which includes all three

modules, testing, and quality assurance Iteration two is Full Capability Iteration including improving

products, process, and providing user manuals all features.

▪ Second iteration (Transition iteration) where training and installation will be done.

36

Capabilities to be Implemented

ID Capability Description Priority Iteration

1 Search For searching providers according to various filters

2 1st

2 Share For sharing invoices by entering manually

1 1st

3 Networking Creating groups and adding people to the groups

3 1st

37

Capabilities to be Tested

ID Capability Description Priority Iteration

1 Search For searching providers according to various filters

2 1st

2 Share For sharing invoices by entering manually

1 1st

3 Networking Creating groups and adding people to the groups

3 1st

38

Project Plan

COCOMO Estimate

According to COINCOMO,

The COINCOMO estimation effort calculated from the 3 modules gives an effort of 13.36 PM

For pessimistic approach, it will be 10.40 person

For optimistic approach, it will be 6.7 person

For most likely approach ,it will be 8.3 person

Therefore, we will be able to complete the project within time if we work a little extra.

42

▪ Danny Lee▪ Ensure quality▪ Bug/defect tracking

▪ Traceability Matrix

▪ Defect Reporting

Quality Focal Point

43

Quality Focal PointOCD Win Win Negotiation SSAD Test Case

OC-1 Manual Information Search: The application should enable consumersto search healthcare information by inputting location, code, price andspecialty WC_3084 UC5 TC-04-01

OC-2 Geo-Location Search: The application should be able to findconsumers’ location and show relevant providers around. WC_3094 UC5

TC-10-01, TC-10-02, TC-10-03, TC-10-04, TC-14-01, TC-14-02

OC-3 Price Comparison: The application should enable consumers tocompare price between different providers WC_3090 UC8 TC-06-01

OC-4 User Registration: The application should enable consumers to register as a user WC_3086 UC1, UC10 TC-08-01, TC-08-02, TC-08-03

OC-5 Price Sharing: The application should enable users to share healthcareservices price by manually inputting or capturing invoice WC_3082 WC_3083 UC4, UC9

TC-01-01, TC-07-01, TC-13-01, TC-13-02, TC-13-03

OC-6 Provider Rating: The application should enable users to rate providersand create a review WC_3091 WC_3089 UC7, UC9 TC-09-01, TC-09-02, TC-12-01

OC-7 Networking: The application should enable users tocreate a private network and join existing networks. WC_3088 UC6 TC-11-01, TC-11-02

OC-8 Profile Management: The application should enable users to create andmanage a health profile. WC_3087 WC_3093 WC_3186

UC2, UC3, UC11, UC12 TC-15-01, TC-15-02

OC-9 Notification Management: The application should enable users tosubscribe form providers to get update notifications. And it also allows usersto filter notifications WC_3095 WC_3098 UC6 TC-19-01, TC-20-01

Example of Tracing

45

▪ Share track▪ 3 reported bugs

▪ Search track▪ In progress

▪ Profile track▪ Under development

▪ Login track▪ 5 reported bugs

Defect Reporting

46

Feasibility Evidence Description

▪ Technical Debt

▪Metrics

▪ Definition of Done

▪ Risks Change

47

Technical Debt▪ OCR Win-condition removed

▪ Undertested NDI: Ke server▪ No specification of use▪ No anticipated response

▪ Covered bugs▪ Identified defects

▪ Lack of code comments▪ Code that mysteriously works…

48

Metrics▪ Lines of Code▪ Track Velocity

▪ Defect Report▪ Track # of defects, defect rate & defect density

▪ Test Case Coverage▪ Track % of passed, % of testing

▪ Feature Delivery▪ Track # of win-conditions satisfied

1/17/1

5

1/18/1

5

1/19/1

5

1/20/1

5

1/21/1

5

1/22/1

5

1/23/1

5

1/24/1

5

1/25/1

5

1/26/1

5

1/27/1

5

1/28/1

5

1/29/1

5

1/30/1

5

1/31/1

5

2/1/1

5

2/2/1

5

2/3/1

5

2/4/1

5

2/5/1

5

2/6/1

5

2/7/1

50

200

400

600

800

1000

1200

1400

1600

Line of Code

50

Definition of Done

▪ All modules must be implemented and reviewed

▪ All bugs in bugzilla must be resolved

▪ All test cases passed and core features delivered

▪ The product should be fully documented

▪ Transition of code documents and accounts should be completed

▪ All stakeholders should be satisfied

51

Risk AssessmentRisks Potential

MagnitudeProbability Loss

Risk Exposure

Back-end Incompatibility 9 9 81

Platform Inconsistency 6 8 48

Performance Limitation from Backend 8 6 48

Personnel Time Constraints 7 8 56

Personnel Capability deficiency 8 7 56

Client Time constraints 10 1 10

Inconvenience to Users (Share invoice) 7 2 14

Geolocation Share and Search Failure 7 3 21

Collaboration Inefficiency with 3rd Party 9 7 63

52

Risks Change▪ Removed▪ OCR failure▪ Scalability Uncertainty▪ Team Cohesion Failure

▪ Re-estimated▪ Backend incompatibility: probability 5->9▪ Personnel time constraints: probability 5->8▪ Personnel capability deficiency: probability 4->7▪ Client time constraint: magnitude 6->10,

probability 4->1

53

Risks Change▪ Added▪ Unattractiveness/inconvenience of long

invoice for users

▪ Geolocation share and search failure

▪ Collaboration inefficiency with backend contractor

54

Risks Mitigation Plans▪ Communication with backend team and Backend

Incompatibility:▪ Contact client and backend team both▪ Plan ahead and address future risks early on in case of

delays▪ Reach out to Backbone.js community for general issues

▪ Platform Inconsistency:▪ Have successfully deployed prototype to phone to verify

functionality

▪ Inconvenience to users:▪ Early testing of functional application with target users▪ Surveys