1. Family Proud TRR ARB Presentation
Team 06

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

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

4. Operational Concept Design: Benefit Chain Diagram
Julius

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

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

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

8. Demo

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

10. 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 id that hasn’t been registered is used for sign up.
TC-2-3
Validate the 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

11. Test Cases: Inviting Support Group Member Test Cases: Social Wall
Number
Test Item
Result
TC-3-1
Only valid formats are accepted to send invitation to users.
Pass
TC-3-2
Check if the invitation can reach the targeted 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

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

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

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

15. Procedures Date Test Identifier Responsible Person Resources
Training needs
10/05/ /05/2018
UC1 - UC4
Swetha
Code Needed
N/A
10/05/ /08/2018
UC5 - UC9
Junpeng
UC10, UC15, UC16
Yan
10/12/2018
Track test case results
Test Case Results
10/15/ /22/2018
Repeat failed test cases
10/22/ /29/2018
Test new test cases
10/29/ /12/2018
Repeat failed test and new test cases
11/12/ /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.

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

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

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

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

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

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

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

23. Quality Focal Point: Effort Hours
Junpeng
Refer to class schedule when talking about the breakdown. (More documentation hours when packages are due!!!)

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

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

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

27. Transition Plan: Milestone Plan
Rui

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

29. Questions?