Project Proposal
|
Mat. number |
Name |
|
Role |
| 11907556 | Watzinger Sebastian | e11907556@student.tuwien.ac.at | Security |
| 11775803 | Ferch Bastian | bastian.ferch@tuwien.ac.at | Team-Coordinator |
| 11808253 | Drucker Florian | e11808253@student.tuwien.ac.at | Vice Technical Architect |
| 11907549 | Stöger Stephan | e11907549@student.tuwien.ac.at | Test-Manager |
| 11809940 | Winkler Michael | e11809940@student.tuwien.ac.at | Vice Team- Coordinator |
| 11815125 | Strasser Michael | e11815125@student.tuwien.ac.at | Vice Test-Manager |
| 01641210 | Dmytro Kondrashov | e1641210@student.tuwien.ac.at | Technical Architect |
Our project is aimed for athletes, who have limited time for training and want a trainer, which should observe them during the training. The optimal time planning is often very essential in training and therefore needs to be planned.
This system will enable the possibility for the optimal training surroundings and progress beneath their other priorities in life. We want to achieve that, by creating a weekly training plan, which adapts to athletes and trainer time constraints. Furthermore our software will include various tools to analyze the athletes progress. All of the features should work automatically, but this could be constrained to some APIs, where the optional case would be access to the Garmin Connect APIs. Other possibilities would be the Strava API, which has less data, but it is also possible to synchronize automatically. The last option, which is always possible, is the usage of .iFit files, which have to be imported manually.
There are already some tools which analyze fitness progress, but none is focusing on the athlete's possible timeframes for training as we do.
If access to (some of) these systems is available to us, we will try to add an integration for it as well (for example Garmin API). This will increase usability and user-experience as manual imports will not be required. Regardless, our system shall be designed in a way, such that one only needs to write a new connector for the new API/datasource, requiring minimal effort to seamlessly integrate a new system into ours.
|
Feature |
Description |
Priority |
Effort |
|---|---|---|---|
|
Time constraint Trainer Athlete (CSP) |
Trainers should attend most of the training sessions for each athlete. Therefore we implement a CSP algorithm to fit all requirements, if possible. |
H | |
| Proposals for changing constraints when CSP is not solvable | If there is no solution for the training plan that satisfies all requirements, the program should propose a minimal set of changes to the requirements so the problem is solvable. Example: Propose to ask certain athletes if they are available at other times. | M | |
| Minimal shift of training times when new Athlete joins | When a new athlete joins the team, the training plan should be newly calculated. This should be done in a manner that disturbs the already fixed time slots of other athletes in a minimal way. | L | |
| Support training groups in CSP | Certain athletes may need to train in a group. This should be considered by the training planner. | L | |
| Display activity | Data for each activity should be displayed in multiple ways. This includes tables (e.g. time for each round of a run), graphs (e.g. heart rate over time) and maps (e.g. route of a run). | H | |
| Create training as trainer | A trainer should be able to create training sessions with given requirements(e.g. distance and speed) | H | |
|
Do training as athlete (and check as marked on calendar) |
A training, created by the trainer, should be able to be done. After importing it, the training should be automatically checked as done. Depending on the accuracy of the goals, the color should differ. | H |
| Feature | Description | Priority | Effort |
|---|---|---|---|
| create events and calculate finishing time (based on previous data) | Different events should be created and the finishing time should be calculated based on the previous training sessions. | M | |
| Calculate fitness of athlete | Based on multiple training and health data, the fitness should be calculated. Other health values can be calculated if any formula is found during the process. | M | |
| Rate trainings as athlete and trainer | A training should be rated as a athlete and the trainer should rate the performance of the athlete | L | |
| Import training data | Initially training data should be imported with .iFit and .tcd/.tcx files. If Garmin API is accessible, we prefer to use this method. The fallback API is Strava API, which sends less data and no health data. The health data can be manually imported otherwise. | H | |
| Compare your fitness to others in the application | All data should be anonymously compared to the current athlete and you can see your ranking. | L |
Frontend: Angular 17
Backend: Kotlin Spring 6.0.3
DB: PostgreSQL 16.0, MongoDB
Kubernetes (from ASE)
GitLab (from ASE)
- Do any similar products exist?
Yes, there are multiple products which implement some of our features. Garmin Connect, Strava and TrainingPeaks are some of our similar products. These are the most common ones, but there are many other smaller products.
- What are the reasons for the redevelopment in comparison to using the existing product?
Implement features to help trainers and athletes to plan training sessions together.
|
Stakeholder |
Roles & Responsibilities |
| Athletes | Want to get their training efforts visualized and evaluated. Want help planning training times when their trainers are available. Want to be able to plan events and calculate their finishing times. |
| Trainer | Want to be able to plan training for their athletes. Want help planning training together with their athletes. |
| Developers | Wants to connect trainers and athletes as well as help athletes maximize their potential using visualizations of their health- and workout-related information. |
| Project manager | Wants to equally spread the workload of the project across all team members and enable the team to communicate and work together efficiently. Furthermore, PM aims to ensure that the project is thoroughly planned through, ensuring timely completion of features to be able to present deliverables on-time. |
- Handling of health data needs special consideration according to GDPR
- Need lawful basis for processing health data (informed consent)
- stricter safeguards
- only collect and process health data that is strictly necessary for the intended purpose
- What legal environments apply for your product?
- Closed Source
| Features | 70h |
| Kickoff | 1h |
| Familiarization with new technologies | 5h |
| Quality Assurance, Testing, Documentation | 24h |
| Management Reviews (Preparation + Meeting) | 6h |
| Jour-Fixe | 12h |
| Internal Meetings, Project Management | 32h |
| Sum | 150h |
|
Risk |
Probability |
Impact |
Countermeasure |
|---|---|---|---|
| Team member drops out | Low | Duties of member has to be distributed among otder members. Critical role might be vacant. |
Vice role takes over. Scope of tde project might get reduced, based on tde time of tde dropout. |
| Training API not available | Medium | Healtd-/Workout-data can only be imported manually using iFit-files, severely impacting tde user-experience of tde application. |
Ensure to stay witdin API’s (rate-)limits. If problems are discovered, tdink about caching options to reduce API-calls appropriately. |
| Computed healtd/time predictions are not accurate | Medium | Key feature of tde application would be broken. Atdletes cannot draw useful conclusions from computed values. | Research otder algoritdms tdat compute tde desired predictions, re-implement algoritdms. |
| No useful visualizations are achieved | Low | Trainers and Atdletes cannot draw good conclusions from workout data | Research visualizations of similar applications, re-implement visualizations. |
| Unfinished code is pushed to main branch | Low | Failing tests, failing application | Deploy fixes, undo commit, ensure push to main-branch witdout PR is not possible. |