This repository contains the source code and related resources for the Sports Club Management Project, developed as part of the ESA (Applied Software Engineering) and Visual Programming curricular units. The project aims to unify various sports club management functionalities into a single web-accessible platform.
Developed by:
The initial repository for this project was hosted privately on Bitbucket and has been moved to GitHub due to its widespread usage. All branches have been retained by choice, along with the entire commit history. Typically, a branch was created for each feature, followed by 4 development branches (one per sprint), where features were aggregated and, at the end of each sprint, merged into the master branch.
Also worth to mention, this is not a project that you want to spend you time trying to run 🙃 since it has a lot of moving parts and we've cut some corners to make it work and meet our needs (not the best practice).
As you can see on Technologies Used it requires some external service to get it working, some are directly from Azure and some are provided by 3rd parties.
In short, this repo was mainly made public so it could be used as reference as part of our CV's.
The Sports Club Management Project aims to provide a comprehensive platform for the administration of sports clubs. It consolidates various essential functionalities, such as club management, members (coaches, athletes), associates, and events. Additionally, it offers a payment system for club subscriptions, member fees, and event fees.
The application supports dynamic translations to ensure that fields are understandable for users of different languages. It also integrates Mapbox mapping resources for event and club location, making it easy to view their geographical positions.
The project was developed using the SCRUM methodology, based on 4 sprints. The first sprint lasted approximately 1 month, while subsequent sprints were planned to last 2 weeks each. At the end of each sprint, sprint planning, sprint review, and sprint retrospective meetings were conducted.
The project was built using the following technologies and services:
- Core Technologies: .NET, Razor Pages
- Database: SQL Server
- Integrated External APIs:
- Easypay: Payment entity
- Mapbox: Interactive maps and location
- Mailgun: Email sending service (confirmations and notifications)
- Microsoft Translator: Text translation tool
- Azure Object Storage: Storage for images and documents
- Azure Key Vault: Storage for access keys to external APIs
The project's code is organized as follows:
- Areas: Code generated by ASP.NET Identity, including views and associated logic.
- Controllers: MVC pattern controllers.
- Data: Classes generated by Entity Framework.
- Middlewares: Middlewares for request processing.
- Models: MVC models. Each service has its associated folder for better organization.
- Resources: Static translations in different languages.
- Services: Application services, with associated models/classes in separate folders.
- ViewComponents: Additional components, such as "language picker" and "role selector".
- Views: MVC views.
To automate the project's build, testing, and deployment process, continuous integration was set up using Azure Pipelines. The workflow was divided into two main stages: Development and Production.
With every push to the development branch, the following workflow is triggered:
- Build: The code is compiled, and dependencies are installed.
- Unit Tests: Unit tests, implemented with xUnit, are executed to verify code integrity.
- Automation Tests: Automation tests using Selenium are executed to verify the application's functionality.
- Development Deployment: The application is deployed to a development environment for further validation by developers.
When the code is merged into the master (production) branch, the following workflow is triggered:
- Build: The code is compiled, and dependencies are installed.
- Unit Tests: Unit tests are again executed to ensure code stability.
- Automation Tests: Automation tests are executed again to ensure functionality in the production version.
- Production Deployment: The application is deployed to the production environment for end users to access.
To ensure code quality and application functionality, unit tests and automation tests were implemented. In both cases, it was not possible to cover 100% of the code due to time constraints and other parallel projects. However, the implemented tests cover most of the application's core functionalities and components.
Unit tests were created using the xUnit framework. These tests focus on verifying the correctness of individual functions and code components. They are automatically executed during the build process and before deployment in both development and production environments.
Automation tests were created using Selenium, a tool that allows simulating user interactions with the application. These tests verify the correct functioning of features in a more realistic environment, simulating a user's interaction with the interface. They are also automatically executed during the build process and before deployment.
The video below provides an overview of the project, including a demonstration of its functionalities. It does not have audio, as comments on the video's content were made in real-time during the project presentation.
In the table below, functional requirements indicated by the client (responsible professor) are listed along with a brief description and priority. The requirements have been divided into 3 priority categories: Must Have, Should Have, and Could Have. Additionally, some requirements have been marked as Won't Have, indicating that they will not be implemented in the project.
| ID | Module | Description | Priority |
|---|---|---|---|
| RF1 | Authentication | The system should allow users to register in the application. | Must Have |
| RF2 | Authentication | The system should allow users to log in to the application. | Must Have |
| RF3 | Authentication | The system should allow users to recover their account password via email. | Must Have |
| RF4 | Authentication | The system should send a confirmation email to the user upon registration. | Must Have |
| RF5 | Authentication | The system should allow an authenticated user to log out. | Must Have |
| RF6 | Authentication | The system should allow the user to authenticate in the application through other platforms (Google, Microsoft). | Could Have |
| RF7 | Authentication | The system should allow the user to activate their account through a link. | Must Have |
| RF8 | Authentication | The system should allow a user to change their password. | Must Have |
| RF9 | Authentication | The system should allow a user to change their personal information. | Must Have |
| RF10 | Authentication | The system should allow a user to change their profile picture. | Could Have |
| RF11 | Authentication | The system should allow changing a user's status (online/offline). | Won't Have |
| RF12 | Authentication | The system should allow managing profile settings (site color theme, notifications). | Should Have |
| RF13 | Authentication | The system should support Portuguese and English languages. | Must Have |
| RF14 | Authentication | The system should allow changing the application's language. | Must Have |
| RF15 | Club Management | The system should allow club manager users to view club members. | Must Have |
| RF16 | Club Management | The system should allow club manager users to view the status (active and inactive) of club members. | Should Have |
| RF17 | Club Management | The system should allow club manager users to remove privileges from members who have not paid their dues. | Must Have |
| RF18 | Club Management | The system should allow club manager users to generate access codes for users to join the club. | Must Have |
| RF19 | Club Management | The system should allow users to use the access code generated by club managers to join the club. | Should Have |
| RF20 | Club Management | The system should allow the user to use the access link (with the generated code) sent by email to access the club. | Should Have |
| RF21 | Club Management | The system should allow generating a QR code with the access code. | Could Have |
| RF22 | Club Management | The system should allow the use of the generated QR code. | Could Have |
| RF23 | Club Management | The system should allow club managers to view a list of generated codes and the respective users who joined with those codes. | Could Have |
| RF24 | Club Management | The system should allow club staff users to view athletes belonging to the club. | Could Have |
| RF25 | Club Management | The system should allow club manager users to remove club members. | Must Have |
| RF26 | Club Management | The system should allow users to associate with multiple clubs. | Must Have |
| RF27 | Athlete Plans | The system should allow athlete users to update their EMD (Electrical Muscle Development). | Could Have |
| RF28 | Club Management | The system should allow club staff to manage teams. | Must Have |
| RF29 | Club Management | The system should allow the club administrator user to manage the existing club modalities. | Must Have |
| RF30 | Club Management | The system should allow the club administrator user to manage the club's terms and conditions. | Could Have |
| RF31 | Club Management | The system should allow users to view clubs on the map. | Could Have |
| RF32 | Club Management | The system should allow users to view club pages. | Should Have |
| RF33 | Club Management | The system should allow users to search for clubs. | Must Have |
| RF34 | Payment | The system should allow the visualization of subscription plans. | Must Have |
| RF35 | Payment | The system should allow club administrators to make payments for subscription plans. | Must Have |
| RF36 | Payment | The system should allow club administrators to enter the easypay platform API Key for payment processing. | Must Have |
| RF37 | Payment | The system should allow users to use various payment methods, including MBWay, Multibanco Reference, Credit/Debit Card. | Must Have |
| RF38 | Payment | The system should allow authenticated users to view their account statement. | Must Have |
| RF39 | Payment | The system should allow users to pay club membership fees with the desired frequency. | Must Have |
| RF40 | Payment | The system should allow the club administrator user to manage the subscription plan. | Must Have |
| RF41 | Payment | The system should allow club manager users to update the membership fee amounts to be paid by members. | Must Have |
| RF42 | Payment | The system should allow authenticated users to pay for event participation. | Should Have |
| RF43 | BackOffice Control | The system should allow the system administrator user to manage subscription plans for services. | Must Have |
| RF44 | Payment | The system should allow authenticated users to select the payment method to be used. | Must Have |
| RF45 | Events | The system should allow club staff users to manage different types of events and details. | Must Have |
| RF46 | Events | The system should allow club staff users to mark the event route on the map. | Must Have |
| RF47 | Events | The system should allow authenticated users to manage their event registrations. | Must Have |
| RF48 | Events | The system should allow all users to view existing public events and details. | Must Have |
| RF49 | Events | The system should allow all users associated with a club to view existing private events and details. | Must Have |
| RF50 | Events | The system should allow users to view information related to the event map (route, elevation, and relevant information about them). | Must Have |
| RF51 | Events | The system should allow users to share events on different platforms. | Won't Have |
| RF52 | Events | The system should allow viewing the number of participants in an event. | Could Have |
| RF53 | Events | The system should allow viewing event results. | Could Have |
| RF54 | Events | The system should allow viewing events on a calendar. | Should Have |
| RF55 | Athlete Plans | The system should allow coach and club administrator users to manage training/nutrition plans and goals for athletes. | Should Have |
| RF56 | Athlete Plans | The system should allow coaches and club administrators to manage training/nutrition plan templates. | Could Have |
| RF57 | Athlete Plans | The system should allow athlete users to view training/nutrition plans and goals. | Should Have |
| RF58 | Athlete Plans | The system should allow trainers to select the frequency of training/nutrition plans. | Could Have |
| RF59 | Athlete Plans | The system should allow athlete users to manage their bioimpedance data. | Should Have |
| RF60 | Statistics (Club) | The system should allow club manager users to view statistics on the number of different users in the club. | Should Have |
| RF61 | Statistics (Club) | The system should allow club manager users to filter different existing statistics. | Could Have |
| RF62 | Statistics (Club) | The system should present club administrators with statistics on club revenue (from events and dues) on a monthly or annual basis. | Should Have |
| RF63 | BackOffice Control | The system should allow the system administrator user to view statistics on the most and least subscribed plan. | Must Have |
| RF64 | BackOffice Control | The system should allow the system administrator user to view statistics on the number of clubs created and canceled. | Must Have |
| RF65 | BackOffice Control | The system should allow the system administrator user to view statistics on the number of clubs with overdue payments. | Must Have |
| RF66 | BackOffice Control | The system should allow the system administrator user to view statistics on the number of users in the club. | Must Have |
| RF67 | BackOffice Control | The system should allow the system administrator user to view which users are online and offline. | Won't Have |
| RF68 | BackOffice Control | The system should allow the system administrator user to view the number of codes used and generated in clubs for member registrations. | Could Have |
| RF69 | BackOffice Control | The system should allow the system administrator user to filter different existing statistics. | Could Have |
| RF70 | BackOffice Control | The system should allow users to update the terms and conditions of the provided services. | Won't Have |
| RF71 | Notifications | The system should notify the club administrator user when they have reached the maximum capacity of their subscription plan. | Must Have |
| RF72 | Notifications | The system should notify club members about the existence of new events. | Could Have |
| RF73 | Notifications | The system should notify event participants about changes (including event cancellations) in the events. | Could Have |
| RF74 | Notifications | The system should notify athlete users about the existence of new plans/goals. | Could Have |
| RF75 | Notifications | The system should notify athlete users about changes in plans/goals. | Could Have |
| RF76 | Notifications | The system should notify club members when the due date for their dues is approaching. | Should Have |
| RF77 | Notifications | The system should notify club members and club administrators of overdue dues and subscriptions, respectively. | Should Have |
| RF78 | Notifications | The system should notify the athlete user who updated their EMD. | Could Have |
| RF79 | Notifications | The system should notify users when a new club member joins. | Won't Have |
| RF80 | Notifications | The system should allow users to indicate which notifications they wish to receive. | Should Have |
| RF81 | Notifications | The system should notify the club administrator user when a new secretarial user code is generated and requires validation. | Must Have |
| RF82 | Notifications | The system should notify the invited user by email containing a link generated by the club management for membership. | Must Have |
| RF83 | Club Management | The system should allow users to view the club's terms and conditions. | Must Have |
| RF84 | BackOffice Control | The system should allow users to view the service's terms and conditions. | Must Have |
| RF85 | Club Management | The system should allow users to view the club's modalities. | Must Have |
| RF86 | Athlete Plans | The system should allow viewing athlete bioimpedance data. | Should Have |
| RF87 | BackOffice Control | The system should allow the system administrator user to view monthly, annual, and subscription plan revenue statistics. | Must Have |
| RF88 | Statistics (Club) | The system should allow club manager users to view statistics on the number of active and inactive members. | Must Have |
| RF89 | Statistics (Club) | The system should allow club manager users to view statistics on modalities, comparing them to the number of members in those. | Must Have |
| RF90 | Statistics (Club) | The system should allow club manager users to view statistics on the number of different types of users per year. | Must Have |
| RF91 | Club Management | The system should allow athlete and coach users to view the teams they belong to. | Must Have |
| RF92 | Notifications | The system should notify the club administrator user when the secretarial user intends to delete a secretarial user type and requires validation. | Must Have |
| RF93 | Club Management | The system should allow the club administrator user to edit club information. | Must Have |
| RF94 | BackOffice Control | The system should allow the system administrator user to create and edit modalities to be used by clubs. | Must Have |
| RF95 | BackOffice Control | The system should allow system administrators to add and remove other users as system administrators. | Must Have |
| RF96 | Athlete Plans | The system should allow athletes to view a schedule with their goals. | Must Have |
| RF97 | Athlete Plans | The system should allow athletes to view the history of their bioimpedance. | Must Have |
| RF98 | Notifications | The system should notify users when they register for or withdraw from events, either voluntarily or due to non-payment. | Should Have |
| RF99 | Notifications | The system should notify athletes when they are added or removed from teams. | Should Have |
| RF100 | Notifications | The system should notify users about their subscriptions and payments. | Should Have |
| RF101 | Notifications | The system should notify users about changes in dues and discontinued plans. | Should Have |
| RF102 | Notifications | The system should notify the athlete user when the expiration date of their EMD is approaching. | Won't Have |