Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "CASH DOCTOR MOBILE APP: RDCR ARB TEAM 12 2/10/14."— Presentation transcript:

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

2 ▪ 7 returning team members, 1 new 2 Team MemberRole Rob StehlinClient Alisha ParvezDeveloper/Life Cycle Planner Danny LeeQuality Focal Point/Trainer Ekasit JarussinvichaiDeveloper Kenneth AngukaIV&V Le ZhuangDeveloper/Feasibility Analyst Shreya SharmaTester Steven HelferichProject Manager Xichao WangTester

3 3 Strong pointsWeak points Fast learners and hard workingInexperienced 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 ▪ 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 4

5 ▪ 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 5

6 Requirement IDRequirement DescriptionVerification TypeTest Case ID (if applicable) WC_3082 System shall capture an image and user entered invoice details for sharing. DemoTC-01 WC_3085 System shall integrate with the existing database at Cash Doctor. TestingTC-02 WC_3079 System shall run on iOS, Android, and Windows Phone. DemoTC-03 WC_3084 System shall search for healthcare pricing, provider by location, price, code, and specialty. DemoTC-04 WC_3087 System shall allow consumer access to his/her existing account by user ID and password, and can view his/her existing dashboard. DemoTC-05 WC_3077 System will be appealing to the target consumer (80% female). AnalysisLOS-1 WC_3090 System shall allow consumer to compare healthcare prices. DemoTC-06 WC_3083 System shall allow consumers to manually enter price information for sharing. DemoTC-07 WC_3086 System shall allow consumer to register as a user. DemoTC-08 6

7 Requirement ID Requirement DescriptionVerification TypeTest Case ID (if applicable) WC_3089 System shall allow consumer to create a review of a provider. DemoTC-09 WC_3088 System shall allow consumer to create a private network and join existing networks. DemoTC-21 WC_3094 System shall allow users to find their current location to access relevant providers in and around area (some mile radius). DemoTC-10 WC_3076System will be easy to use and intuitive by all users.AnalysisLOS-2 WC_3080 System shall be able to support at least 1000 simultaneous users. AnalysisLOS-3 WC_3098 System shall allow a user to subscribe to notifications so that he/she shall have access to relevant up-to-date information. DemoTC-11 WC_3091System shall allow consumer to rate a provider.DemoTC-12 WC_3093 System shall allow provider to share pricing, offerings, and other content so as to drive traffic and increase sales. DemoTC-13 WC_3078 System will be accurate within a 5 mile radius at a 90% confidence interval. AnalysisTC-14 7

8 Requirement ID Requirement DescriptionVerification 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 DemoTC-15 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. DemoTC-16 WC_3092 System shall allow a corporation to view its employees and the prices they've shared so as to encourage participation. DemoTC-17 WC_3185 System shall allow a user to gain access to features when the user shares health care pricing DemoTC-18 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. DemoTC-19 WC_3095 System shall allow a user to filter notifications. User shall be able to filter based on location, price, code, specialty, and provider. DemoTC-20 8

9 ▪ Test cases currently being executed: 9 Test CaseRequirementWin Condition TC-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 Case NumberTC-01-01 Test ItemCapturing the data Test PriorityM Pre-conditionsCMS database is initialized Post-conditionsUser captures a photo, enters details about the invoice, and is able to submit and save this to the database. Input SpecificationsThe image, total price, and service(s) of the medical bill. Expected Output SpecificationsStores the image and invoice details in the database Pass/Fail CriteriaPass: 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 ConstraintsNone DependenciesNone Traceability WC_3082 10

11 Test Case NumberTC-01-02 Test ItemIntegrate with the existing database Test PriorityM Pre-conditionsCMS database is initialized Post-conditionsSystem is able to interact with the database successfully Input SpecificationsData is entered in the database Expected Output SpecificationsRetrieve the previously entered data from the database Pass/Fail CriteriaPass: User is able to store/retrieve data into the database and confirm accuracy Fail: System is unable to save or retrieve the data Assumptions and ConstraintsNone DependenciesNone Traceability WC_3085 11

12 Test Case NumberTC-01-05 Test ItemUser is able to successfully access their account page and view their dashboard. Test PriorityM Pre-conditionsCMS database should be initialized Post-conditionsMobile application displays the account status page and dashboard Input SpecificationsThe user’s USERID and PASSWORD Expected Output SpecificationsThe account page and dashboard Pass/Fail CriteriaPass: The correct account page and dashboard is displayed. Fail: The account page or dashboard fails to display or contains incorrect information. Assumptions and ConstraintsNone DependenciesNone Traceability WC_3087 12

13 Test Case NumberTC-01-07 Test ItemInput content verification (User is able to manually enter the price on a shared invoice and save to the database.) Test PriorityM Pre-conditionsUser is on the share price page Post-conditionsThe price has been entered and saved to the database Input SpecificationsPrice Expected Output SpecificationsPage confirming the shared price Pass/Fail CriteriaPass: Confirmation page displays the manually entered price Fail: User is unable to manually enter the price or the pice entered is not saved to the database. Assumptions and ConstraintsNone DependenciesNone Traceability WC-3083 13

14 Test Case NumberTC-01-08 Test ItemEmail verification (User Registration) Test PriorityM Pre-conditionsUser is at the registrtation page Post-conditionsUser remains at the registration page. A warning appears with the message advising the user to input a valid email address. Input SpecificationsInvalid-formed email address has been entered by users Expected Output SpecificationsThe registration page that informs the users to input a valid email address. Pass/Fail CriteriaPass: User remains at the registration page with a warning. Fail: User arrives as successful registration page. Assumptions and ConstraintsNone DependenciesNone TraceabilityWC-3086 14

15 15 DateTest IdentifierResponsible person ResourcesTraining needs 12/08/14 (Prototype)-Shreya Sharma Intel XDK and Manual Testing Web Technologies, Basic testing experience, scripting 1 st 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 2 nd 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 3 rd 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 720 Windows SDK 4 th 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 720 N/A

16 16 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 17 ▪ Manual Testing Detailed level test cases have been made for every high level test case. Two examples are : Login and Share Page

18 ▪ 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. 18

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

20 20

21 ▪ 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 21

22 ▪ 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 22

23 23 Dashboard (Consumer) Dashboard (Provider)

24 24 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 25 Register Consumer Page ▪ WC_3086: As a consumer, I can register as a user.

26 26 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 27 Search Page ▪ WC_3084: A consumer can search for healthcare pricing, provider by location, price, code, specialty.

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

29 29 JSON data

30 ▪ Backbone.js ▪ Client side JavaScript Model-View framework ▪ Bootstrap ▪ Front-end development framework based on HTML, CSS, and JS ▪ Cordova ▪ Mobile development framework 30

31 31

32 ▪ 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 32

33 33

34 34 Team MemberRoleResponsibilities Alisha ParvezDeveloper, Life Cycle PlannerSearch Module, Project plan, Deliverables Danny LeeQuality Focal PointUnit Testing Ekasit JarussinvichaiDeveloper, PrototyperDashboard, Login submodules, Deliverables Kenneth AngukaIV & VTesting Le Zhuang Developer, Feasibility AnalystEdit Profile submodule, Deliverables Shreya SharmaAutomation Tester, System Architect Unit Testing, Module Testing Steven HelferichDeveloper, Project MangerShare Module, Project Report, Deliverables Xichao WangTester, Operational Concept Engineer Unit testing, Deliverables

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

36 36 IDCapabilityDescriptionPriorityIteration 1Search For searching providers according to various filters 21 st 2Share For sharing invoices by entering manually 11 st 3Networking Creating groups and adding people to the groups 31 st

37 37 IDCapabilityDescriptionPriorityIteration 1Search For searching providers according to various filters 21 st 2Share For sharing invoices by entering manually 11 st 3Networking Creating groups and adding people to the groups 31 st

38 38

39

40

41 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 42

43 OCDWin Win NegotiationSSADTest Case OC-1 Manual Information Search: The application should enable consumers to search healthcare information by inputting location, code, price and specialtyWC_3084UC5TC-04-01 OC-2 Geo-Location Search: The application should be able to find consumers’ location and show relevant providers around.WC_3094UC5 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 to compare price between different providersWC_3090UC8TC-06-01 OC-4 User Registration: The application should enable consumers to register as a userWC_3086UC1, UC10TC-08-01, TC-08-02, TC-08-03 OC-5 Price Sharing: The application should enable users to share healthcare services price by manually inputting or capturing invoiceWC_3082 WC_3083UC4, 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 providers and create a reviewWC_3091 WC_3089UC7, UC9TC-09-01, TC-09-02, TC-12-01 OC-7 Networking: The application should enable users to create a private network and join existing networks.WC_3088UC6TC-11-01, TC-11-02 OC-8 Profile Management: The application should enable users to create and manage a health profile. WC_3087 WC_3093 WC_3186 UC2, UC3, UC11, UC12TC-15-01, TC-15-02 OC-9 Notification Management: The application should enable users to subscribe form providers to get update notifications. And it also allows users to filter notificationsWC_3095 WC_3098UC6TC-19-01, TC-20-01 43

44

45 ▪ Share track ▪ 3 reported bugs ▪ Search track ▪ In progress ▪ Profile track ▪ Under development ▪ Login track ▪ 5 reported bugs 45

46 ▪ Technical Debt ▪ Metrics ▪ Definition of Done ▪ Risks Change 46

47 ▪ 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… 47

48 ▪ 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 48

49

50 ▪ 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 50

51 RisksPotential Magnitude Probability Loss Risk Exposure Back-end Incompatibility9981 Platform Inconsistency6848 Performance Limitation from Backend8648 Personnel Time Constraints7856 Personnel Capability deficiency8756 Client Time constraints101 Inconvenience to Users (Share invoice)7214 Geolocation Share and Search Failure7321 Collaboration Inefficiency with 3 rd Party9763 51

52 ▪ 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 52

53 ▪ Added ▪ Unattractiveness/inconvenience of long invoice for users ▪ Geolocation share and search failure ▪ Collaboration inefficiency with backend contractor 53

54 ▪ 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 54


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

Similar presentations


Ads by Google