Deliverable 3 - scanonc/Local-Sports GitHub Wiki
1. Architecture Y Data
1.1 Deployment Diagram
Description:
- Users access the app from PC/mobile via a web browser over HTTP.
- The Local Sports Django project runs on a server, inside a Linux execution environment.
- OS-level tools: Python, Git, pip. Project dependencies are installed from requirements.txt.
- Apps: core, users, matches.
- Persistence: SQLite3, holding User, Match, Match_Participant, Join_Request,Favorite, Report, Invitation.
- External dependency over HTTP: Bootstrap CDN for styling.
- External dependency over HTTP: Resend for Emails
Changes:
- Update the execution environment from Windows to Linux.
- Added three new tables to the SQLite3 database to support the Sprint 3 features: Favorite, Report, Invitation.
- Added resend and python-dotenv as project dependencies.
- Added Resend API as an external service.
- Added .env file.
1.2 Component Diagram
Description:
- core: Manages site navigation, homepage (FR0), and general core layouts.
- user: Handles authentication (Signup, Login, Logout) (FR1), modules for managing favorite players (FR17) and reporting users (FR18), exposes the notification interface consumed by matches (FR9, FR9.1).
- matches: Manages match creation (FR1, FR2), browsing/filtering (FR3, FR12), joining and waiting lists (FR5, FR10), leaving matches (FR6, FR11), attendance confirmation (FR7), participant lists (FR8), match cancellation (FR9), match history (FR13), player invitations (FR15), and shareable link generation (FR16).
- Resend API: Handles the delivery of email notifications triggered by the matches component(FR14, FR14.1)
Changes:
- Added FR17 FavoritePlayers and FR18 ReportUsers interfaces to users.
- Added FR13 MatchHistory, FR15 InvitePlayers, and FR16 GenerateInviteLink interfaces to matches.
- Split the single FR14 Notification dependency into two explicit notification interfaces on users (FR14 NotificationMatchUpdates and FR14.1 Notification MatchCancellation) both consumed by matches, reflecting that update and cancellation now trigger notifications independently.
- Added Resend API as an external component with a SendEmail interface.
- matches now depends on Resend API.
- Added FR14 and FR14.1 notify email.
1.3 Data Model
Description:
- User: id, username, email, password, skill_level, profile_picture, created_at.
- Match: id, title, date_time, location, skill_level, max_players, visibility, status, created_at, updated_at, FK organizer, and now invite_token, invite_active.
- MatchParticipant: id, status, attendance_confirmed, joined_at, updated_at, FK match, FK player.
- JoinRequest: id, request_date, request_status, FK player, FK match.
- Notification: id, message, is_read, created_at, FK user, FK match.
- Favorite: id, created_at, FK user, FK favorite_user_id.
- Report: id, reason, description, created_at, FK user, FK reported_user_id.
- Invitation: id, status, created_at, FK user, FK match.
Relationships:
- User 1..N Match (as organizer)
- User 1..N MatchParticipant --- Match 1..N MatchParticipant
- User 1..N JoinRequest --- Match 1..N JoinRequest
- User 1..N Notification --- Match 1..N Notification
- User 1..N Invitation --- Match 1..N Invitation
- User 1..N Favorite
- User 1..N Report
Changes:
- Added invite_token and invite_active fields to Match to support shareable invite links (FR16).
- Added Favorite entity to support marking other players as favorites (FR17).
- Added Report entity to support reporting other players with a reason and description (FR18).
- Added Invitation entity linking Match and User to support organizer-driven player invitations (FR15).
2. Corporate Image
Project name:
- Local-Sports
Logo:
Slogan:
- “Less organizing, more playing.”
Palette:
- #14532D verde oscuro
- #4ADE80 verde claro
- #0B1E3D azul oscuro
Main Interfaces:
Home Page
Create a match
Browse matches
3. Repository
Link:
https://github.com/scanonc/Local-Sports
Default branch:
main.
Work branches:
feature/name, fix/name
Pull Requests:
is required 1 review by the Scrum Master
4. Video
5. Project Management
5.1. Backlog (excerpt — MVP scope)
| ID | Requirement (As a… I want… so that…) | Acceptance Criteria | Status | Tasks | Owner |
|---|---|---|---|---|---|
| FR1 | As a registered player, I can create a football match so that other players can participate in it. | When a registered player submits the match creation form, the system creates a new football match. | Done | Create the match form, implement match creation logic, validate form data, save the match, and test the creation flow. | Sebastian Cañón |
| FR2 | As a match organizer, I can store football match details so that the match information is available to players. | When the organizer creates or edits a match, the system stores its date, time, location, skill level, maximum number of players, and visibility setting (public or approval required). | Done | Define match model fields, implement data persistence, validate match details, and support match visibility settings. | Sebastian Cañón |
| FR3 | As a player, I can view available football matches so that I can find games to join. | When a player accesses the match listing, the system displays the available football matches. | Done | Retrieve available matches, implement the listing view, create the match-list template, and display relevant match information. | Yohn Gaviria |
| FR4 | As a player, I can request to join a match requiring approval so that the organizer can decide whether I can participate. | When a player requests to join a match requiring approval, the system records the request and allows the organizer to approve or reject it. | Done | Implement the join request model, request creation, request status management, duplicate-request validation, and organizer decision handling. | Yohn Gaviria |
| FR5 | As a player, I can join a public football match so that I can participate without waiting for organizer approval. | When a player requests to join a public match, the system adds the player to the match if the maximum number of participants has not been reached. | Done | Implement public match joining, validate match visibility and capacity, register participants, and prevent duplicate participation. | Ismael García |
| FR6 | As a participant, I can leave a football match so that I can free my spot if I can no longer attend. | When a participant leaves a match, the system removes the participant and updates the available spots. | Done | Implement the leave-match action, update participant records, recalculate available spots, and validate participation permissions. | Ismael García |
| FR7 | As a registered participant, I can confirm my attendance so that the organizer knows whether I will attend the match. | When a participant confirms attendance, the system records the confirmation and displays the updated attendance status. | Done | Implement the attendance confirmation action, persist the attendance status, update the match details interface, and test the confirmation flow. | Yohn Gaviria |
| FR8 | As a player, I can view match participants so that I know who is registered for a football match. | When a player opens a match's details, the system displays the list of registered participants. | Done | Retrieve registered participants, integrate the participant list into the match detail view, update the template, and verify the displayed information. | Yohn Gaviria |
| FR9 | As a match organizer, I can cancel a football match so that registered participants know the game will no longer take place. | When the organizer cancels a football match, the system cancels the match and sends a push notification to all registered participants. | Done | Implement match cancellation, validate organizer permissions, update the match status, and trigger participant notifications. | Sebastian Cañón |
| FR10 | As a player, I can join a waiting list for a full match so that I can participate if a spot becomes available. | When a player attempts to join a match that has reached its maximum number of participants, the system adds the player to the waiting list. | Done | Implement waiting-list registration, validate match capacity, prevent duplicate entries, and store waiting-list positions. | Ismael García |
| FR11 | As a waiting-list participant, I can receive an available spot so that I can join a match when another participant leaves. | When a participant leaves a match with a waiting list, the system offers the available spot to the first player on the waiting list. | Done | Implement waiting-list ordering, detect available spots, offer the spot to the first waiting player, and update participation records. | Ismael García |
| FR12 | As a player, I can filter football matches by date, location, and skill level so that I can find games that match my preferences. | When a player searches for football matches, the system filters the available matches by date, location, and skill level. | Done | Implement filter controls, apply date, location, and skill-level filters to the match query, update the match-list template, and test filtering. | Sebastian Cañón |
5.3. Sprint Retrospective
After the Sprint 3 Review, the team analyzed the progress made during the Sprint and the feedback received from the professor. Based on this evaluation, we identified the following aspects:
What should we continue doing? (Best Practices)
- Continue using GitHub and its Wiki to organize tasks, document progress, and keep track of project development.
- Continue holding weekly meetings to discuss completed tasks, upcoming activities, and difficulties encountered during development.
- Continue dividing responsibilities among team members to make progress on different functionalities.
- Continue reviewing and improving the project's diagrams and documentation as new functionalities are implemented.
What should we start doing? (Process Improvements)
- Start reviewing the component diagram more carefully to ensure that all necessary relationships between components and requirements are correctly represented.
- Start evaluating the readability of the website's typography to ensure that important information is clearly visible to users.
- Start validating the consistency between the implemented functionalities, the requirements, and the architectural diagrams before each Sprint Review.
What should we stop doing? (Process Problems and Bottlenecks)
- Stop leaving visual design details, such as font readability, without sufficient review before presenting the application.
- Stop postponing the verification of diagrams and documentation until the end of the Sprint, as this can lead to inconsistencies between the system design and its implementation.