Project Summary

HYPO2 is a high altitude training camp for Olympic athletes. While most people watch the Olympics every 2 years, Olympic athletes are training every second before their events begin. HYPO2 is looking for a web-based application to help smooth out their process. This includes taking teams of athletes and having a better scheduling process for these athletes to make it easier for them to get here and get ready to train. Challenges of their current process is that most of HYPO2 is ran by hand. This means clients of HYPO2 have to email for every need they have. This includes creating a camp, requesting a service, cancelling a service, and so much more.

Solution

This is what the team was able to produce for HYPO2's vision. As of right now, most of HYPO2 workflows require constant communication for the easiest task. We made a web portal that gets rid of all the constant communication by taking care of creating the training camps without Gmail. This keeps track of camp information in a database rather than in a Google Drive and, finally, allowing clients to request or cancel an in-house and external services directly in the application rather than needing to email HYPO2.

Requirements

The Olympic Developers met weekly with our client, Sean Anthony. He is the founder and CEO of HYPO2 sports. We met weekly in order to gather a better idea of the client's vision for the product. For the requirements we had three types of users that will use the application: HYPO2 clients, admin and staff. Due to this, we broke the requirements up into four sections: shared user functionalities, Account-Specific functionalities, Non-Functional, and environmental requirements. Below is a quick overview of the requirements for each section of the project. For more detail, visit the Document tab and go to Requirements Document.

Shared User Functionalities

Shared functionalities are functionalities that will be shared between the 3 types of users that are using the web application. These functionalities will include both user accounts and user validation.

Account-Specific Functionalities

Account-Specific functionalities are functionalities that will be unique between the 3 types of users using the web application. These will include customer, administrator, and staff member functionalities.

Non-Functional Requirements

Non-Functional Requirements are how we will test the web application. The usability of the product is what will be tested. The groups testing during the coding process: HYPO2 clients, administrator, and staff.

Environmental Requirements

Environmental Requirements are requirements that were made mandatory by our client. These are a transferable repository, desktop compatibility, user manual, As-built report, and appearance.

Technologies

Here is an overview on the technologies that have been integrated into the HYPO2 web portal. For more information on the technologies, check out the tech feasibility in the documents tab.

AWS was used for our hosting services and has features that were integrated. These features include: Amazon incognito and amplify for logging in users.

MYSQL is used for holding the data for different types of users such as: coaches, employees of HYPO2, and administrators for the application.

Node JS is used as our backend framework to interact with our frontend framework and pulling and pushing data to our database.

React is our frontend framework due to the ease of use and familiarity that many members of the team have with it.

Software Architecture

Here is a visual of how we took the above technologies and constructed our architecture for the application. Visit the software design in the document tab for more details on the architecture, how we implemented the product, and individual use cases for each module.

Full Project Description