Family Proud TRR ARB Presentation Team 06

Operational Concept Design: System Purpose Family Proud is a revolutionary healthcare web application that connects patients with technology for access to the logistical, social, and medical resources that they need to improve their quality of care. Provides a private platform for patients to share their healthcare journey with their loved ones. The patient’s support network can remain up to date on the condition of their loved ones. Julius Family

Operational Concept Design: Shared Vision Assumptions Patients are not currently using a social network to document their health journey. Current resources available are not sufficient to provide patients the necessities. Patients have a strong support network. Patient has internet access and is capable of updating their network of their status. Stakeholders (Who?) Initiatives (What?) Value Propositions (Why?) Beneficiaries (For Whom?) Patient Patient’s support group network Healthcare systems Development Team Maintainers Client Design and develop a web application Maintain the system Market analysis Partner with healthcare facilities Use the system functionalities Improve quality of patient care Improve communication between patients and their support network Increased emotional support during time of need Patients Family Proud Cost Development costs Maintenance costs Advertising and marketing costs Web server Database storage Benefits Decrease hours spent searching for support groups Increase business revenue for third-party services Julius

Operational Concept Design: Benefit Chain Diagram Julius

Operational Concept Design: Core Capabilities Social Wall Peer-to-Peer Locator Shared Calendar Direct Messaging Julius

Transition: Transition Objectives Transfer new system to client Provide source code and API keys Transfer Github repository ownership to client’s account Switch COTS accounts to client’s accounts Provide user manual on how to run and maintain application Yan ?? Extent of capability transitioned: Intermediate. Fundamental capabilities provided. However, new capabilities and additions to current capabilities can be incorporated. Transition sites: One, homogenous transition site. Degree of post-transition developer support: None. None of our developers will continue to work on this project. Degree of validation of operational satisfaction of stakeholder objectives: Intermediate. Client satisfied, but still need input from potential users (patients and support group members). Nature of product transition: New system.

Transition: Transition Strategy Source code will be provided to client through a private Github repository. Private information, such as passwords and API keys, will be provided in person. COTS need to be registered under client. Firebase and Google Cloud Platform APIs are already under client’s accounts. Cloudinary will require client to sign up for his own account. IP Geolocation API will require client to register for its pro service to obtain commercial, unlimited use. User manual on how to run and maintain application will be provided to client and his technical team. Yan ??

Demo

Test Cases and Results Test Cases: Sign-in Number Test Item Result TC-1-1 Validate if the user can log into the web application using an existing username and password. Pass TC-1-2 Check if the user can successfully log out of their account. TC-1-3 Check if the user is able to land on the “Forgot password” page by clicking the “Forgot Password” link. TC-1-4 Check if the user receives an email that contains a link to reset their password after “Forget password” TC-1-5 Check if the password change is reflected after “Forget password.” TC-1-6 Check if clicking the “Sign up” button lands the user on to the Sign Up page. Swetha Core capabilities : Sign In, User registration, Inviting support group members, Social wall, Direct Messaging, Peer-to-Peer locator, Sharing Calendar, Database Test cases created to test the core capabilities and successful population of database with values.

Test Cases: User Registration Number Test Item Result TC-2-1 Check if user can successfully sign up for an account. Pass TC-2-2 Check if only an email id that hasn’t been registered is used for sign up. TC-2-3 Validate the email ID format under registration. TC-2-4 Validate the phone number format under registration. TC-2-5 Check if the health condition can be selected from the dropdown list. TC-2-6 Check if the click of the submit button lands the user on his social wall page. Swetha

Test Cases: Inviting Support Group Member Test Cases: Social Wall Number Test Item Result TC-3-1 Only valid email formats are accepted to send invitation to users. Pass TC-3-2 Check if the email invitation can reach the targeted email address. Test Cases: Social Wall Number Test Item Result TC-4-1 Check if the patient can post on their social wall. Pass TC-4-2 Check if the patient/support group member can comment on another user’s social wall. Swetha

Test Cases: Direct Messaging Test Cases: Peer-to-Peer Locator Number Test Item Result TC-5-1 Check if the user can search their friend list to successfully send a message to another user. Pass Test Cases: Peer-to-Peer Locator Number Test Item Result TC-8-1 Check if the patient can locate other users on the map and can directly message them. Pass Test Cases: Database Number Test Item Result TC-6-1 Validate that the user entry is created in the database after a new user registers. Pass TC-6-2 Check if any database updates are captured correctly in the database with all the fields updated. Swetha

Test Cases: Sharing Calendar Number Test Item Result TC-7-1 Check if the patient user can add a calendar event. Pass TC-7-2 Check if support group members can’t add event in their calendar. TC-7-3 Check if only patient users can add events in their calendar. TC-7-4 Check if only patient users can modify event in their calendar. TC-7-5 Check if the patient user can remove an event from their calendar. TC-7-6 Check if the support group member can’t remove an event from the patient user’s calendar. Swetha

Test Cases: Sharing Calendar (cont.) Number Test Item Result TC-7-7 Check if the patient user is able to see other users in the shared calendar list based on the patient users they support. Pass TC-7-8 Check if the user can view events from a calendar shared with them. TC-7-9 Check if the support group member user can sign up for a patient’s event. TC-7-10 Check if the support group member can remove an event they signed up for from their calendar. TC-7-11 Check if the event they signed up for is automatically removed upon the patient removing that event from their calendar. TC-7-12 Check if the support group member gets notified for an upcoming event. Swetha

Procedures Date Test Identifier Responsible Person Resources Training needs 10/05/2018 - 10/05/2018 UC1 - UC4 Swetha Code Needed N/A 10/05/2018 - 10/08/2018 UC5 - UC9 Junpeng UC10, UC15, UC16 Yan 10/12/2018 Track test case results Test Case Results 10/15/2018 - 10/22/2018 Repeat failed test cases 10/22/2018 - 10/29/2018 Test new test cases 10/29/2018 - 11/12/2018 Repeat failed test and new test cases 11/12/2018 - 11/27/2018 All test cases Swetha/Junpeng Swetha The created test cases are tested against the implementation. Failed test cases are tracked and fixed before starting on further implementation. Fixture of failed test cases is tested. New test cases are added to test the fully implemented tes cases. Repeat all the test cases to ensure no previous failure exists.

Procedures Functional Testing - Unit testing : Tested each functionality after implementation. - Integration testing : Tested the code after each sub branch has been merged with the master branch to ensure no issues exist after functionalities integration. Swetha The core capabilities are unit tested after functionality implementation. Later integration testing is performed after each merge in of the sub branch to the master branch.

Quality Focal Point: Technical Debt - Solved Description Resolution Method Some developers are not familiar with the technologies used, such as ReactJS and Firebase. We learned the technologies required for the project through online documentations and knowledge sharing among team members. Requirement definition was not specific enough for initial development stage, and some requirements may not be feasible due to time constraints. We had a client meeting in which we discussed and negotiated the implementation items based on priority and availability. Suffer from code smell and deficient comments in development. We have followed the ES6 coding standards in our implementation and have included comments to define what each function does. Junpeng

Quality Focal Point: Technical Debt - Solved Description Resolution Method Testing largely relies on sanity check, unit testing, and regression testing. We have performed unit testing of each functionality during implementation. Also, the regression test is performed after each sub-branch has merged with the master branch. Business logic is integrated with the UI code, which increases the difficulty of testing. The code is divided into two directories (i.e. backend and frontend.) This way the UI development is separated from the backend implementation. Junpeng

Quality Focal Point: Technical Debt - Unresolved Description Resolution Method There is some inconsistency in the database resulting from testing during early-stage development. We have cleaned inconsistent data, but we still need to implement data validation in Firebase to avoid those conflicts and bugs. Junpeng

Quality Focal Point: Traceability Matrix OCD Requirement SSAD Test Case OC-1: Sign In WC_4653 UC-1 TC-1-1, TC-1-2, TC-1-3, TC-1-4, TC-1-5, TC-1-6, TC-5-7, TC-5-8 OC-2: Invite Support Group Member WC_4732 UC-5 TC-3-1, TC-3-2 OC-3: Social Wall WC_4710 UC-3 TC-4-1, TC-4-2 WC_4731 UC-9 TC-2-1, TC-2-2, TC-2-3, TC-2-4 OC-4: Direct Messaging WC_4701 UC-4 TC-5-1 Junpeng

Quality Focal Point: Traceability Matrix OCD Requirement SSAD Test Case OC-5: Shared Calendar WC_4734 UC-2, UC-15 TC-7-1, TC-7-2, TC-7-3, TC-7-4, TC-7-5, TC-7-6 WC_4659 UC-7 TC-7-7, TC-7-8 WC_4657 UC-8 TC-7-9, TC-7-10, TC-7-11 WC_4658 UC-10 TC-7-12 OC-6: Peer-to-Peer Locator WC_4662 UC-6 TC-8-1 Junpeng Shared Calendar (WC_4734)As a patient, I am able to add calendar events. (WC_4659)As a patient, I can securely share my calendar with my support group. (WC_4657)As a support group member, I can sign up for a patient’s event. (WC_4658)As a support group member, I can get a notification when a patient has an upcoming event.

Estimated Time vs. Actual Time Quality Focal Point: Estimated Time vs. Actual Time per development task Junpeng

Quality Focal Point: Effort Hours Junpeng Refer to class schedule https://greenbay.usc.edu/csci577/fall2018/schedule when talking about the breakdown. (More documentation hours when packages are due!!!)

Transition Plan: Preparation Hardware Preparation Desktop / Laptop with Chrome 70 or Firefox 63. Software Preparation Register for pro service of IP Geolocation API. Register for Cloudinary account. Source code provided through private Github repository. Add configuration files with API keys and account information. Install Node.js and npm dependencies. Staff Preparation Knowledge of maintaining and implementing full-stack web applications. Knowledge of database design. Rui

Transition Plan: Testing, Training, and Evaluation Test cases for acceptance testing are provided to client. Tester performed test cases to ensure capabilities satisfy the requirements of the client. Training Provide user manual for the user and maintainer. How to run application What accounts are needed for the application Description of each implemented functionality Dependencies Evaluation Improve the code according to the feedbacks given by client during CCD. Rui Should we add a couple bullet points under training on what information the user manual will provide

Transition Plan: Stakeholders Responsibilities Client Register for their own database / API accounts. Identify future direction of web application. Read the user manual. Developers Implement feedbacks from CCD. Finalize the application and fix all the bugs. Complete all the required documents for final deliverables. Testers Make sure win conditions are met through testing. Make sure test cases are passed. Trainers Produce the user manual. Provide technical support if necessary. Maintainers Review and understand application code and technology stack. Responsible for future updates and bug fixing. Users Use the website and provide feedback according to the user experience. Rui

Transition Plan: Milestone Plan Rui

Transition Plan: Required Resources Documentation Technical Manual on how to run and maintain application Required documents on the team website Client training session Products Source code through private Github repository Rui

Questions?