Project Contract

Team Members

Mat. number	Name	E-Mail	Role
11907556	Watzinger Sebastian	e11907556@student.tuwien.ac.at	Security Engineer
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	Requirements Engineer (Vice Team- Coordinator)
11815125	Strasser Michael	e11815125@student.tuwien.ac.at	Vice Test-Manager
01641210	Kondrashov Dmytro	e1641210@student.tuwien.ac.at	Technical Architect

Project description

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.

Initial situation & existing similar products

There already is a well-established market for products like ours. For example manufacturers may offer (to some degree) similar products in addition to their smartwatch or fitness tracker. These are, however, mostly focused on gathering and analyzing health- and sports-related data, while offering little to no possibility for planning training activity in advance.

These devices often utilize manufacturer-specific interfaces, making them inaccessible. To address this problem, products like Strava exist, which allow recording, analyzing and visualizing data from various manufacturers and device-types.

However, these products also do not address the athletes' need to schedule and plan workouts with their trainer.

For this problem, applications like TrainingPeaks and Trainerplan exists.

But in our experience, TrainingPeaks is lacking usability and is more of an expert system, not made for a general audience. Trainerplan on the other hand is a bit more pricey, but also forces the trainer to manually add, assign and handle workouts.

Target audience 

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.
Admin	The system administrator wants to create activity templates, for commonly used activities, and wants to have a user management.

Functional requirements

• Iceberglist

1. Automatic activity schedule generation (CSP)
   • ID: #9
   • depends on: #10, #21
   • Priority: High
   • Description: Trainers should attend most of the activities for each athlete. Therefore we implement a CSP algorithm to fit all requirements, if possible.
     Requirements include timeframes trainers and athletes are available and which parts of the activity require the presence of the trainer.
   • Acceptance criteria:
     1. Trainer provides a set of activities without fixed time slots (drafts).
     2. Program returns timeslots for each activity with regard to the time constraints of both trainer and athletes, if such a configuration is possible
2. Create activity as user
   • ID: #10
   • depends on: #23
   • Priority: High
   • Description: A user should be able to create activity with given requirements(e.g. distance and speed). This includes a list of Intervals. The trainer can provide a fixed timeslot. If not, the activity is stored as a draft.
   • Acceptance criteria:
     1. User provides necessary data (kind of exercise, intervals, athlete etc.)
     2. If a fixed time is specified, the activity is fixed.
     3. If the given time collides with an already fixed activity , warn the trainer before storing the activity.
     4. If no time is provided, the program returns a draft.
     5. If an athlete creates an activity, he can not make trainer attendance required.
3. Display activity
   • ID: #11
   • depends on: #12
   • Priority: High
   • Description: 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).
   • Acceptance criteria:
     1. trainers as well as athletes can open a detailed description for each activity
     2. displays health- and activity data using graphs, tables and maps
     3. display activity on calendar
4. Import activity data
   • ID: #12
   • depends on: #23
   • Priority: High
   • Description: 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.
   • Acceptance criteria:
     1. Import data via .iFit Files
     2. Import data via Garmin Connect API
     3. Import data via Strava API (backup for Garmin Connect API)
5. Calculate activity precision
   • ID: #13
   • depends on: #12, #10
   • Priority: High
   • Description: An activity, created by the trainer, should be able to be done. After importing it, the activity should be automatically checked as done. Depending on the accuracy of the goals, the color should differ.
   • Acceptance criteria:
     1. When new data is imported, the program checks whether it matches with predefined activities.
     2. The color of the activity in the UI depends on how accurately the data matches the predefined activity (for example: green if the data matches the activity, yellow if there are some inconsistencies, red if the activity was not performed)
6. Proposals for changing constraints when CSP is not solvable
   • ID: #14
   • depends on: #9
   • Priority: Medium
   • Description: If there is no solution for the training plan that satisfies all requirements, the program should propose changes to the schedule.
   • Acceptance criteria:
     1. When there is no possible schedule, the program proposes a minimal set of changes to the requirements so the problem is solvable. 
     2. Examples:
        1. Propose to ask certain athletes if they are available at other times
        2. propose that the activity is marked to be performed without the presence of the trainer.
7. Create an event and calculate finishing times:
   • ID: #15
   • depends on: #12 #16
   • Priority: Medium
   • Description: Different events should be created and the finishing time should be calculated based on the previous training sessions.
   • Acceptance criteria:
     1. An Event should be created
     2. The finish time should be calculated
     3. An Event should also be considered in the csp algorithm
     4. An event should be showed in the calender
8. Calculate fitness of athlete
   • ID: #16
   • depends on: #12
   • Priority: Medium
   • Description: Based on multiple activities and health data, the fitness should be calculated. Other health values can be calculated if any formula is found during the process.
   • Acceptance criteria:
     1. Calculate fitness and show as graph
     2. Calculated values are based on scientific literature
     3. Find other interesting health values
9. Rate trainings as athlete and trainer
   • ID: #17
   • depends on: #11
   • Priority: Low
   • Description: An activity should be rated as a athlete and the trainer should rate the performance of the athlete
   • Acceptance criteria:
     1. Athletes can rate activities based on how exhausting/fun it was.
     2. Trainers can rate the performance of the athlete.
     3. Athletes and trainers can post comments on activities.
10. Minimal shift of training when new athlete joins(CSP)
    • ID: #18
    • depends on: #9
    • Priority: Low
    • Description: When a new athlete joins the team, the training plan should be newly calculated.
    • Acceptance criteria:
      1. When calculating a new plan, it should be done in a manner that disturbs the already fixed time slots of other athletes in a minimal way.
      2. Fixed plans cannot be changed without consent of athletes whose time slots would be changed.
11. Support training groups in CSP
    • ID: #19
    • depends on: #9, #10, #24
    • Priority: Medium
    • Description: Certain athletes may need to train in a group. This should be considered by the training planner.
    • Acceptance criteria:
      1. When creating an activity as a trainer it is possible to assign it to multiple athletes.
      2. The CSP should consider the time constraints of all assigned athletes (as well as the trainer).
12. Compare your fitness to others in the application
    • ID: #20
    • depends on: #12, #16
    • Priority: Low
    • Description: Athletes can compare different metrics to other athletes.
    • Acceptance Criteria: 
      1. All available data should be anonymously compared to the current athlete.
      2. Athletes can see their ranking based on fitness scores, finishing times.
13. Create personal time constraints
    • ID: #21
    • depends on: #23
    • Priority: High
    • Description: Users can create general and specific time constraints that affect at which time the automatic scheduler can schedule their activities.
    • Acceptance Criteria:
      1. Users can specify general time constraints: Times of the week users generally (don’t) have time for activities.
      2. Users can specify specific time constraints: Certain times, days, weeks or months they are not available outside of their regular schedule.
14. Export calendar as .ical
    • ID: #22
    • depends on: #10, #15
    • Priority: Low
    • Description: Users can export their calendar (with their assigned training times) as .ical.
    • Acceptance Criteria:
      1. Exported Calendar should show the same dates as in our App.
      2. Exported Calendar should be importable in the most commonly used calendar apps (google calendar, microsoft calendar, ...)
15. Create user account
    • ID: #23
    • depends on:
    • Priority: High
    • Description: Create user via registration form
    • Acceptance Criteria:
      1. user can register with valid email
      2. user gets registration email with activation link
      3. user accepts user agreements (informed consent, privacy terms, terms of service, …)
      4. user can match with a trainer if user signs up as athlete
16. Create training groups
    • ID: #24
    • depends on: #23
    • Priority: Low
    • Description: Create trainings group
    • Acceptance Criteria:
      1. Create groups as trainer
      2. These groups can be considered as one Athlete for the trainer in the CSP
17. Create Zone Groups
    • ID: #25
    • depends on: #23
    • Priority: Medium
    • Description: Create zone groups
      1. Manually create Zone groups
      2. A Zone Group contains min and max values and a name
      3. Generate ZoneGroup based on scientific value
18. Notification System
    • ID: #26
    • depends on: #23
    • Priority: Medium
    • Description: As a user I would like to get notifications. For example notifications should be sent if a training is set or comments are made on one of your activities.
    • Acceptance criteria:
      1. Important actions (such as the fixation of a training plan) trigger notifications
      2. Affected users receive notifications in-app as well as per email
      3. Notifications can be viewed and deleted
      4. Users can change their notification preferences in-app (e.g. unsubscribe from email notifications)

Non functional requirements

Performance:

• Description: The system should be responsive and provide quick responses to user interactions, ensuring that activities are scheduled and displayed without significant delays.
• Acceptance criteria:
  • Loading of any particular page should not take longer than 3 seconds if the internet connection is stable.
  • All common database queries used by the application should take a maximum of 1 second.

Security:

• Description: User data, including personal health information, training plans, and activity history, must be securely stored and transmitted. Access to sensitive data should be restricted to authorized users only.
• Considering the data this application processes, security & privacy are very important requirements. Therefore, a separate document specifying security requirements is provided.
• Security document

Scalability:

• Description: The system should be able to handle an increasing number of users, trainers, and athletes as it gains popularity without a significant degradation in performance. This includes the ability to accommodate a growing database of training data and user profiles.
• Acceptance criteria:
  • The platform should handle at least 100 trainers and 1000 athletes without suffering any noticeable performance penalty

Usability:

• Description: The user interface must be intuitive and user-friendly, making it easy for both trainers and athletes to create, schedule, and review activities. It should be accessible on various devices, including tablets and desktop computers.
• Acceptance criteria:
  • Users should be able to use all basic functionality of the application without prior training.
  • Accessing core features (create new activity, run automatic scheduler, see activities and events in calendar) should be possible within max. 5 clicks.
  • The user interface should work properly on all common screen sizes (desktop, tablet and phone) and orientations (portrait, landscape).
  • The application should respond to user actions within 1 second. If actions take longer, the application should signify to the user that it currently processes/loads data.
  • The application interface should be designed consistently (buttons, clickable/non-clickable text etc.).

Domain model

DB-Schema

Basic Model

{width="736.5934959349594" height="454.9171598594802"}

Worker Model

 

Working structure & simple project plan

Horizontal responsibilities

• Team Coordinator

  • Role description: Team coordinators must have good project management knowledge and are responsible for keeping the artifacts of ongoing project management (e.g. project plan) up to date.
  • Team:
    • Ferch Bastian
    • Winkler Michael (vice)
  • Tasks:
    • Organization and planning (ongoing documentation) 
      • Project plan
      • WBS
      • Risk analysis
      • Iceberg list
    • Controlling & Tracking:
      • Time lists, organizational tickets from the tracker 
      • Status survey for the status report (reviews), see supply components
    • Control of task distribution (work/developer), 
    • see rough project plan and iceberg list 
    • Primary contact person for clients 
      • Organization of internal and external meetings Group meetings (Jour-Fixe), tutor meetings, IR's, MR's 

• Technical Architect

  • Role description: Technical architects manage the program infrastructure of the project, e.g. folder structure and dependencies. The expert knowledge of the technical architects includes very good knowledge of the programming languages, toolkits and frameworks used, as well as architectural design and software patterns.
  • Team:
    • Kondrashov Dmytro
    • Drucker Florian (vice)
  • Tasks:
    • Project Object Model (Maven pom.xml)
      • Dependency management, especially versions
      • Plugins (e.g. linting)
      • used external repositories
    • Expert knowledge of all technologies used in technical development, e.g. Maven, Spring.
    • Creation of coding guidelines (Checkstyle).
    • Creation of guidelines for source code documentation (Javadoc).
    • Management of all enhancement tickets in the tracker
    • Design of program architecture and components

• Test Manager

  • Role description: The test manager ensures, that every feature has automated tests and does integration tests by hand. If anything is not tested, he has to tell the team member, that tests are missing.
  • Team:
    • Stöger Stephan
    • Strasser Michael (vice)
  • Tasks:
    • Test infrastructure
      • Test libraries, test data
      • Test Suites: Integration with Spring Framework
      • separation of test code / production code.
    • Creation of test plan
      • Test procedure
      • planning of test runs
    • Verification of compliance with testing guidelines
    • Monitoring of integration tests and system tests
    • Regular review of all unit tests

• Requirements Engineer

  • Role description: The Requirements Engineer describes all features in detail and reviews them in terms of completeness and their integration into other features.
  • Team:
    • Winkler Michael
  • Tasks:
    • Description of features:
      • Specification of subfeatures
      • Specification of objects to implement
    • Review features for their completeness:
      • review correct integration of features

• Security Engineer

  • Role description: The Security Engineer is responsible for safeguarding the software from potential security threats and vulnerabilities and maintains an overview of security-related aspects of the application (cryptography-related functions, security-related plugins such as Spring Security).
    Furthermore, the Security Engineer is responsible for guarding sensitive user data and compliance with security & privacy regulations.
  • Team:
    • Watzinger Sebastian
  • Tasks:
    • Analyze potential security threats and risks, including cyberattacks and unauthorized access.
    • Design and implement the software's security architecture, including access controls, authentication mechanisms, and encryption protocols.
    • Review source code for security vulnerabilities (before merging).
    • Promote secure coding practices among the development team, including input validation, secure communication, and safe storage of sensitive data.
    • Ensure that the software complies with industry-specific and legal security standards and regulations, such as GDPR.
    • Document security-related information.

Simple project plan

*Work Breakdown Structure

Milestones:

• MS1(MR1):
  • Wireframes
  • Domain Model
• MS2(MR2):
  • fully functional application with basic functions including a part of our complex problem
• MS3(MR3):
  • fully functional application with a lot of additional features and more constraints for our complex problem

Project boundaries

AthleteView is not targeted at professional athletes. Our users have a busy life, but still want to improve their fitness with a trainer. Therefore our application does not include the option with multiple activities per day. Therefore our CSP does not support more than 7 activities per week.

AthleteView is supposed to provide the following:

• Training overview for athletes and trainers
• Support for creating and managing training plans by providing automatic scheduling and overview of time constraints.
• Flexible communication of individual schedules and time constraints
• Trainings can be created only for the next week

AthleteView is not supposed for the following:

• to replace current fitness tracker apps like Garmin Connect, Strava and Wahoo Fitness.
• to entirely replace the contact between athlete and trainer

Supply components (what will be delivered)

• Software
  • Docker Container for the frontend
  • Docker Container for the backend
• Artifacts & documentation
  • Security document
  • Test plan document
  • Sprint reviews
  • Project report
• We wont deliever an app for mobile devices. This will be a web application.

Risk assessment

Risk	Probability	Impact	Countermeasure
Team member drops out	Low	Duties of member has to be distributed among other members. Critical role might be vacant.	Vice role takes over. Scope of the project might get reduced, based on the time of the dropout.
Training API not available	Medium	Health-/Workout-data can only be imported manually using iFit-files, severely impacting the user-experience of the application.	Ensure to stay within API’s (rate-)limits. If problems are discovered, think about caching options to reduce API-calls appropriately.
Computed health/time predictions are not accurate	Medium	Key feature of the application would be broken. Athletes cannot draw useful conclusions from computed values.	Research other algorithms that compute the desired predictions, re-implement algorithms.
Underestimated time required for feature implementation	Medium	Team can not fit all features into the planned time estimation	Should be spotted at the MR2 at the latest. Drop some features that are not essential to the application
No useful visualizations are achieved	Low	Trainers and Athletes 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 without PR is not possible.

Information process

Our project group primarily relies on Discord as our central communication platform, where all team members have their roles. This allows us to ping both vice and main roles with one ping, so we can get faster replies and improve the communication process..

In addition, we maintain a Signal Group chat, ensuring swift communication for urgent discussions or updates.

This allows us to be very flexible, ensuring that internal meetings can be held ad-hoc if necessary. In addition to that, there will be a weekly meeting (Jour-Fixe) with our Tutor Alexander Lesjak. Lastly, there will be internal and management review sessions throughout the planning/development process as well, 3 management reviews (MR) and 2 internal reviews (IR) will be held where all project members are present alongside our tutor and assistant (which can be understood as our “client”). These meetings correspond with the planned milestones too. The project lead maintains communications with our tutor throughout the project’s evolution via e-mail.

Furthermore, we store crucial documentation and created artifacts within the GitLab wiki, providing a structured and accessible repository for our project-related materials.

The provided infrastructure includes a GitLab repository with a wiki and a integrated CI/CD

Special features

We will fake the Garmin Connect API, because we did not gain access to it. This will ensure, that this application will be able to run in production mode, if all API calls are switched.

Presentation including Mockups

Presentation_MR1.pdf