/SCManagement

SCManagement is a web application for managing sports clubs

Primary LanguageC#

Sports Club Management Project

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:

Disclaimer

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.

Project Description

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.

Methodology

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.

Technologies Used

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

Code Structure

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.

Integration with Azure Pipelines

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.

Development Pipeline (Development Branch)

With every push to the development branch, the following workflow is triggered:

  1. Build: The code is compiled, and dependencies are installed.
  2. Unit Tests: Unit tests, implemented with xUnit, are executed to verify code integrity.
  3. Automation Tests: Automation tests using Selenium are executed to verify the application's functionality.
  4. Development Deployment: The application is deployed to a development environment for further validation by developers.

Production Pipeline (Master Branch)

When the code is merged into the master (production) branch, the following workflow is triggered:

  1. Build: The code is compiled, and dependencies are installed.
  2. Unit Tests: Unit tests are again executed to ensure code stability.
  3. Automation Tests: Automation tests are executed again to ensure functionality in the production version.
  4. Production Deployment: The application is deployed to the production environment for end users to access.

Unit and Automation Testing

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 (xUnit)

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 (Selenium)

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.

Project Design

Presentation

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.

General Architecture

General Architecture

Class Diagram

Class Diagram

System Requirements

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