0% ont trouvé ce document utile (0 vote)
48 vues32 pages

Ecole Superieiure Privee Des Technologies de L'Information Et de Management de Nabeul

Transféré par

Safa Ben Othmen
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
48 vues32 pages

Ecole Superieiure Privee Des Technologies de L'Information Et de Management de Nabeul

Transféré par

Safa Ben Othmen
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

ECOLE SUPERIEIURE PRIVEE DES TECHNOLOGIES DE L’INFORMATION ET DE

MANAGEMENT DE NABEUL

Réaliser par

Mariem BenAbdeljawed
Safa Ben Othmen
Wala saad Bennani

Rapport Mini Projet

« Frameworks Full Stack Web »

Conception et le développement d'une


application web de gestion Club Football

Sous la direction de:

Nesrine MEDDEB

Année universitaire
2024 - 2025
Table des matières

Introduction générale 1

1 Contexte de Projet 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7.1 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Analyse et spécification des besoins 6


2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Identification des Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Identification des Besoins non fonctionnels . . . . . . . . . . . . . . . . . . 8
2.4 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Pilotage avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Élaboration du backlog du produit . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Release 1 : Authentification && Gestion du profil


Gestion des événements et performances 12
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Planification du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Description textuelle du scénario . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Realisation de Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2.1 Interface page d’accueil . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2.2 Interface page d’Inscription . . . . . . . . . . . . . . . . . . . . . 14
3.2.2.3 Interface page d’authentification . . . . . . . . . . . . . . . . . . 15
3.2.2.4 Interface page gestion de profile . . . . . . . . . . . . . . . . . . . 15
3.3 Planification du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Description textuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2 Realisation de Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

i
3.3.2.1 Interface de page Ajouter Perfomance . . . . . . . . . . . . . . . 17
3.3.2.2 Interface de page mes perfomances . . . . . . . . . . . . . . . . . 18
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Release 2 : Gestion des abonnements et de billets


Gestion médical 19
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Planification du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1 Description textuelle du scénario . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Realisation de Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2.1 Interface de page billet . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2.2 Interface page billeterie . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2.3 Interface page acheter abonnement . . . . . . . . . . . . . . . . . 22
4.2.2.4 Interface page mes abonnements . . . . . . . . . . . . . . . . . . 22
4.3 Planification du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Description textuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.2 Realisation de Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2.1 Interface de page Ajouter Perfomance . . . . . . . . . . . . . . . 24
4.3.2.2 Interface de page mes perfomances . . . . . . . . . . . . . . . . . 25
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Conclusion 26

Bibliographie 27

ii
Table des figures

1.1 Cycle de la méthodologie ≪ Scrum ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Diagramme de cas d’utilisation globale . . . . . . . . . . . . . . . . . . . . . . . . 9


2.2 Planfication des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 page d’Acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


3.2 page d’Inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 gestion de profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 page mes perfomances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 page Ajouter Perfomance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 page billet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


4.2 page billeterie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 page acheter abonnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 mes abonnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 page mes perfomances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 page Ajouter Perfomance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iii
Liste des tableaux

2.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


3.2 Description textuelle de cas d’utilisation s’authentifier . . . . . . . . . . . . . . . . . 13
3.3 Description textuelle de cas d’utilisation gestion de profil . . . . . . . . . . . . . . . 13
3.4 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Description textuelle de cas d’utilisation : Créer un événement . . . . . . . . . . . . 16
3.6 Description textuelle de cas d’utilisation participer à un événement . . . . . . . . . . 16
3.7 Description textuelle de cas d’utilisation : Ajouter performance . . . . . . . . . . . . 16
3.8 Description textuelle de cas d’utilisation : Consulter mes performances . . . . . . . . 17

4.1 Backlog du produit pour le sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


4.2 Description textuelle de cas d’utilisation ajouter billet . . . . . . . . . . . . . . . . . 20
4.3 Description textuelle de cas d’utilisation Consulter mes abonnements . . . . . . . . 20
4.4 Description textuelle de cas d’utilisation consulter abonnement . . . . . . . . . . . . 20
4.5 Backlog du produit pour le staff médical . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 Description textuelle de cas d’utilisation : Créer un événement . . . . . . . . . . . . 23
4.7 Description textuelle de cas d’utilisation participer à un événement . . . . . . . . . . 23
4.8 Description textuelle de cas d’utilisation : Ajouter performance . . . . . . . . . . . . 23
4.9 Description textuelle de cas d’utilisation : Consulter mes performances . . . . . . . . 24

iv
Introduction générale

Dans un environnement sportif o‘u l’organisation et la gestion des informations sont cruciales pour
le bon fonctionnement du club, il est essentiel de disposer d’un syst‘eme centralis´e pour la gestion
des joueurs, des matchs, des r´esultats, des calendriers d’entraˆınement, ainsi que des autres donn´ees
pertinentes. Les informations actuellement dispers´ees et g´er´ees manuellement limitent l’efficacit´e
et ralentissent la prise de d´ecision. Ce projet vise ‘a d´evelopper une application web innovante pour
automatiser et centraliser la gestion de ces activit´es tout en offrant des fonctionnalit´es adapt´ees aux
diff´erents acteurs du club.

Grâce à une interface moderne et accessible, l’application vise à simplifier l’accès aux informa-
tions et à optimiser les processus internes pour deux types d’utilisateurs principaux : l’admin, respon-
sable de la gestion des joueurs, des matchs et des calendriers, et le user, qui consulte ces informations.
En adoptant les technologies de la pile MEAN (MongoDB, Express, Angular, Node.js) et une ap-
proche méthodologique agile basée sur Scrum, ce projet a pour ambition de transformer la gestion
sportive en offrant un système flexible, sécurisé et orienté vers la performance.

Le présent rapport, qui détaille les différentes etapes du développement de ce projet, est structuré
comme suit :

Chapitre 1 : Contexte de Projet


Ce chapitre introduit le contexte du projet et le cadre général, tout en présentant la problématique.
Il propose également une analyse des solutions existantes et définit les fonctionnalités clés du système
à développer.

Chapitre 2 : Analyse et Spécification des Besoins


Dans ce chapitre, nous décrivons les outils et technologies utilisés pour le développement de
l’application. Il détaille également les spécifications fonctionnelles et techniques nécessaires à la mise
en œuvre du projet.

Chapitre 3 : Release 1 – Authentification et Gestion du Profil


Gestion des Événements et des Performances
Ce chapitre présente les étapes de développement de la Release 1, avec une vue d’ensemble des
fonctionnalités implémentées, notamment l’authentification, la gestion des profils, ainsi que la gestion
des événements et des performances.

1
2

Chapitre 4 : Release 2 – Gestion des Abonnements et des Billets


Gestion Médicale
Ce chapitre expose les étapes de développement de la Release 2. Il détaille les fonctionnalités
mises en œuvre, incluant la gestion des abonnements, des billets, et les outils dédiés à la gestion
médicale.

Cette application permet ainsi au club d’améliorer sa réactivité et sa précision décisionnelle, of-
frant une solution numérique complète pour soutenir le développement et la compétitivité dans un
cadre sportif
Chapitre 1

Contexte de Projet

1.1 Introduction
Dans cette section, nous présentons le contexte général du projet, détaillons la problématique
à laquelle il cherche à répondre et introduisons les bases nécessaires à la compréhension de notre
démarche.

1.2 Contexte général du projet


le projet de gestion d’un club de football repose sur le développement d’une application web
interactive, visant à simplifier et automatiser la gestion des activités au sein du club. L’objectif est
de centraliser les données essentielles et d’offrir des outils adaptés pour une gestion efficace des
membres, des événements, des entraı̂nements, des paiements et des informations médicales. Cette
application permettra à différents types d’utilisateurs d’interagir facilement avec le système via des
interfaces spécifiques.

1.3 Problématique
La gestion d’un club de football implique de nombreux processus complexes et variés, allant
de la gestion des membres et des événements à la planification des entraı̂nements et au suivi des
performances des joueurs. Traditionnellement, ces tâches sont réalisées manuellement, souvent avec
l’utilisation d’outils non adaptés ou d’outils qui ne répondent pas aux besoins spécifiques des clubs
sportifs.

1.4 Étude de l’existant


Avant de concevoir notre application de gestion de club de football, il est essentiel de comprendre
les solutions existantes actuellement utilisées par les clubs pour gérer leurs opérations. Cela nous
permettra de mieux identifier les lacunes et d’offrir une solution plus adaptée. En étudiant l’existant,
nous avons observé plusieurs problèmes majeurs liés aux outils actuels utilisés dans la gestion des
clubs de football.

3
CHAPITRE 1. CONTEXTE DE PROJET 4

1.5 Analyse de l’existant


Bien que certaines applications spécialisées existent pour la gestion des clubs de football, elles
ne répondent pas toujours aux besoins spécifiques des clubs en termes de fonctionnalité et d’acces-
sibilité. Les applications payantes peuvent être coûteuses et difficiles à personnaliser, tandis que les
solutions gratuites sont souvent insuffisantes pour couvrir l’ensemble des besoins du club. Ces limi-
tations rendent nécessaire le développement d’une nouvelle solution plus adaptée et plus accessible.

1.6 Solution proposée


Afin de répondre aux besoins identifiés et de surmonter les limites des solutions existantes, nous
proposons de développer une application dédiée spécifiquement au Club de Football. Cette plate-
forme permettra une gestion complète et simplifiée de l’équipe, tout en étant accessible à un coût
raisonnable. Elle offrira des fonctionnalités telles que la gestion des membres, des événements, des
paiements, ainsi qu’un suivi des performances des joueurs. L’application sera conçue pour être in-
tuitive, sécurisée et accessible à tous les acteurs du club, qu’il s’agisse des administrateur,fidéle, des
joueurs ou du staff.

1.7 Méthodologie de développement


Dans cette section, nous détaillons la méthodologie choisie pour le développement de notre appli-
cation.

1.7.1 Choix méthodologique


Dans le cadre du développement de notre application de gestion pour le club de football, nous
avons choisi d’adopter la méthodologie agile Scrum. Cette approche est particulièrement adaptée
aux projets ayant des exigences évolutives et permettant des ajustements réguliers tout au long du
processus de développement. Scrum favorise la collaboration et la flexibilité, des éléments essentiels
pour mener à bien un projet tel que le nôtre.

1.7.1.1 Scrum
Dérivée d’une méthode de gestion des projets agile, SCRUM (qui désigne la ≪ mêlée≫) est par-
ticulièrement adaptée au management de projet informatique. La démarche de projet est d’effectuer
un découpage en ≪ sprint ≫, durant généralement 30 jours. La figure 7 présente une itération selon la
méthode Scrum.

1.8 Conclusion
Tout au long de ce chapitre, nous avons présenté le contexte général du projet, la problématique
à résoudre, ainsi que la méthodologie de développement choisie. Nous sommes maintenant prêts à
entamer la phase de planification et de spécification des besoins.
CHAPITRE 1. CONTEXTE DE PROJET 5

scrum.png

Figure 1.1 – Cycle de la méthodologie ≪ Scrum ≫


Chapitre 2

Analyse et spécification des besoins

2.1 Introduction
L’étape d’analyse et spécification des besoins est une étape indispensable pour comprendre les
fonctionnalités que le système doit fourni.D’abord nous présentons les acteurs concernés par notre
système. Puis, nous entamons l’étude des besoins fonctionnels et non fonctionnels. Par la suite, ces
besoins seront exprimés sous la forme des diagrammes de cas d’utilisation Nous terminons ce chapitre
avec la planification des releases.

2.2 Identification des acteurs


Tout système interactif doit permettre l’interaction entre ses utilisateurs. Un acteur désigne une
entité externe utilisant le système via ses interfaces. Pour notre projet, les acteurs identifiés sont :

• Administrateur : Gère le site, les inscriptions, le calendrier, les membres et les paiements.

• Visiteur : Consulte les informations publiques et peut s’inscrire.

• Abonné : Accède aux événements et offres de billets.

• Staff technique : Planifie les entraı̂nements et analyse les performances.

• Staff médical : Gère les dossiers médicaux des joueurs.

• Joueurs : Consultent leurs performances et leur calendrier d’entraı̂nement.

2.3 Capture des besoins


Dans cette partie, nous allons identifier les besoins fonctionnels et non fonctionnels de notre projet.

2.3.1 Identification des Besoins fonctionnels


Le projet doit répondre à certains besoins et inclure les modules nécessaires à l’utilisateur dans
l’application. Les tâches correspondantes, organisées par acteurs, sont définies comme suit :

6
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 7

Pour le visiteur
• S’inscrire : Créer un profil pour devenir abonné.
• Accéder aux annonces : Consulter les annonces sur la page d’accueil.

Pour l’administrateur
• S’authentifier : Se connecter avec son email et mot de passe.
• Gérer les membres : Supprimer des profils.
• Suivre les paiements : Gérer les paiements d’abonnements et billetterie.
• Gérer les événements : Créer, modifier, ou supprimer des événements.
• Gérer son profil : Modifier ses informations personnelles.

Pour le joueur
• S’authentifier : Se connecter avec un email et un mot de passe.
• Accéder aux calendriers : Consulter les dates, heures, lieux des matchs et des entraı̂nements.
• Suivi des performances : Consulter les statistiques (buts, passes, temps de jeu), et suivre sa
progression.
• Gérer son profil : Modifier ses infos personnelles et changer de mot de passe.
• Communication avec le staff : Échanger via messagerie interne avec le staff pour instructions
et notifications importantes.

Pour le staff technique


• S’authentifier : Se connecter avec email et mot de passe.
• Planification des entraı̂nements : Créer et gérer le calendrier des entraı̂nements.
• Consultation des calendriers : Accéder aux horaires et lieux des matchs et entraı̂nements.
• Analyse des matchs : Analyser les performances des joueurs.
• Communication avec les joueurs : Partager des informations avant/après matchs.
• Gérer son profil : Modifier ses informations personnelles.

Pour le staff médical


• S’authentifier : Se connecter pour accéder à l’espace sécurisé.
• Suivi médical : Gérer les dossiers médicaux des joueurs (blessures, traitements).
• Planification des rendez-vous : Organiser et modifier les consultations médicales.
• Communication avec les joueurs : Envoyer des messages liés à la santé.
• Gérer son profil : Modifier ses informations personnelles.
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 8

Pour l’abonné
• S’authentifier : Se connecter avec email et mot de passe.

• Consulter les activités : Accéder aux événements du club.

• Consulter les matchs : Voir le calendrier des matchs et détails des précédents.

• Achat de billets : Acheter des billets pour les matchs.

• Gérer son abonnement : Gérer son abonnement et informations de paiement.

• Gérer son profil : Modifier ses informations personnelles.

2.3.2 Identification des Besoins non fonctionnels


Après avoir défini les besoins fonctionnels, nous présentons les contraintes nécessaires pour assu-
rer la performance du système :

• Fiabilité : L’application doit fonctionner de manière cohérente, sans erreurs, assurant une sa-
tisfaction constante.

• Sécurité : La protection des données confidentielles de l’utilisateur est cruciale. Chaque utili-
sateur ne doit avoir accès qu’à son espace réservé.

2.4 Diagramme de cas d’utilisation


Une fois que les acteurs et les fonctionnalités de notre système sont déterminés, nous procédons
à la description du diagramme des cas d’utilisation global. Ce dernier est constitué d’un ensemble de
cas d’utilisation en interaction avec les acteurs.
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 9

Figure 2.1 – Diagramme de cas d’utilisation globale

2.5 Pilotage avec SCRUM


Cette partie est composée de trois éléments principaux du SCRUM qui sont : les rôles, le backlog
du produit et la planification des sprints.

2.5.1 Élaboration du backlog du produit


Le backlog Scrum est destiné à recueillir tous les besoins du client que l’équipe projet doit réaliser.
Il contient donc la liste des fonctionnalités intervenantes dans la constitution d’un produit.
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 10

ID Thème (User Story) Priorité

En tant que visiteur, je veux créer un


1 Inscription Moyenne
Profil

2 Authentification En tant qu’utilisateur, je veux m’authentifier pour accéder à mon espace personnel avec mon email et mot de passe. Élevée

En tant qu’utilisateur je veux modifier

3 Gestion du profil mes paramètres, consulter ou supprimer Moyenne

mon profil..

4 Gestion des membres En tant qu’administrateur, je veux gérer les profils des membres (suppression) Moyenne

5 Suivi des paiements En tant qu’administrateur, je veux suivre les paiements d’abonnements et de billets pour gérer les finances du club. Moyenne

6 Gestion des événements En tant qu’administrateur, je veux créer, modifier, et supprimer des événements Élevée

7 Suivi des performances En tant que joueur, je veux accéder à un rapport détaillé de mes performances pour évaluer mes progrès. Moyenne

8 Communication En tant que joueur, je peux échanger avec le staff technique et médical via une messagerie interne. Moyenne

9 Planification des entraı̂nements En tant que staff technique, je veux créer et gérer un calendrier des entraı̂nements pour organiser les sessions. Élevée

10 Consultation des calendriers En tant qu’utilisateur, je peux consulter le calendrier (des matchs, des entraı̂nements) Élevée

11 Analyse des matchs En tant que staff technique, je veux analyser les performances des joueurs lors des matchs pour améliorer leur préparation. Élevée

12 Suivi des performances En tant que staff technique, je veux suivre les performances des joueurs et générer des rapports d’analyse. Moyenne

13 Suivi médical des joueurs En tant que staff médical, je veux consulter et mettre à jour les dossiers médicaux des joueurs pour assurer leur suivi. Élevée

14 Planification des rendez-vous En tant que staff médical, je veux planifier, modifier ou annuler des rendez-vous médicaux pour les joueurs. Moyenne

15 Accès aux activités En tant qu’abonné, je veux consulter et participer à des événements organisés par le club Élevée

16 Achat de billets En tant qu’abonné, je veux acheter des billets pour les matchs du club en fonction des places disponibles. Moyenne

17 Gestion de l’abonnement En tant qu’abonné, je veux acheter ou consulter mes abonnements Moyenne

Table 2.1 – Backlog de produit

2.5.2 Planification des sprints


• Release : Une release correspond à la livraison d’une version de l’application. C’est la période
de temps qui s’écoule entre le début du travail sur cette version et sa livraison et qui passe par
une série de sprints successifs.

• Sprint : C’est le terme utilisé dans Scrum pour désigner une itération, c’est un bloc de temps
dont le but est de créer un incrément du produit potentiellement livrable. Ce but doit être défini
en terme métier et non en terme technique pour qu’il soit compréhensible par les membres ne
faisant pas partie de l’équipe.
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS 11

Figure 2.2 – Planfication des sprints

2.6 conclusion
Dans ce chapitre, nous avons identifié les acteurs et les besoins fonctionnels et non- fonctionnels
pour notre application. Puis, nous avons présenté et détaillé les différents cas d’utilisation. Enfin, nous
avons présenté le Backlog du produit et la planification des sprints.
Chapitre 3

Release 1 : Authentification && Gestion du


profil
Gestion des événements et performances

3.1 Introduction
Durant ce chapitre, nous détaillerons notre premier release composé de deux sprint . D’abord, nous
commençons par la planification illustrée par le Backlog Product de ces deux sprints. Ensuite, nous
élaborerons la partie de l’analyse et nous exposerons notre étude conceptuelle. Enfin, nous clôturerons
le chapitre par la présentation des interfaces développées dans le but de la validation.

3.2 Planification du sprint 1

Rang use case (User Story)


Visiteur S’inscrire En tant qu’internaute, je veux créer un profil
En tant qu’abonné, administrateur ou staff
Utilisateur S’authentifier je veux m’authentifier pour accéder à mon
espace personnel.
En tant qu’utilisateur, je veux modifier mes paramètres ou
Utilisateur Gérer mon profil
consulter
Administarteur Gestion des membres en tant qu’admin je peux supprimer les profils de membres

Table 3.1 – Backlog du sprint 1

3.2.1 Description textuelle du scénario


Le tableau présent la description de cas d’utilisation ≪ S’authentifier ≫

12
CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

Cas d’utilisation Description


Acteur(s) Administrateur, Joueur, Staff technique, Staff médical, Abonné
Précondition L’utilisateur dispose d’un compte valide (adresse email et mot de passe).
Postcondition L’utilisateur est connecté et accède à son espace personnel en fonction de son rôle.
1. L’utilisateur accède à l’interface de connexion sur l’application.

2. Il saisit son adresse email et son mot de passe.

3. L’utilisateur clique sur le bouton ”Se connecter”.


Scénario normale
4. Le système vérifie les informations fournies dans la base de données.

5. Si les informations sont valides, l’utilisateur est redirigé


vers son tableau de bord personnalisé.

6. Un message de bienvenue s’affiche : ”Connexion réussie, bienvenue !”


4.a [Email ou mot de passe incorrect] :
Scénario alternatif
Affichage d’un message d’erreur : ”Identifiants invalides, veuillez réessayer.”

Table 3.2 – Description textuelle de cas d’utilisation s’authentifier

la description textuelle des cas d’utilisation. Le tableau présent la description de cas d’utilisation
≪ Gestion profil≫

Cas d’utilisation Gestion des Profils


Acteur(s) Administrateur, Joueur, Staff technique, Staff médical, Abonné
Précondition L’utilisateur est connecté à l’application.
Postcondition Les informations du profil sont mises à jour avec succès.
1. L’utilisateur accède à son espace personnel après s’être authentifié.
2. Il clique sur l’option ”Modifier Profil”.
3. Le système affiche les informations actuelles du profil .
4. L’utilisateur met à jour les champs souhaités
Scénario normal
5. L’utilisateur clique sur ”Enregistrer les modifications”.
6. Le système vérifie les données saisies et met à
jour les informations dans la base de données.
7. Un message de confirmation s’affiche : ”Votre profil a été mis à jour avec succès.”

Table 3.3 – Description textuelle de cas d’utilisation gestion de profil


CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

3.2.2 Realisation de Sprint 1


3.2.2.1 Interface page d’accueil

Figure 3.1 – page d’Acceuil

3.2.2.2 Interface page d’Inscription

Figure 3.2 – page d’Inscription


CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

Figure 3.4 – gestion de profile

3.2.2.3 Interface page d’authentification

Figure 3.3 – Page d’authentification

3.2.2.4 Interface page gestion de profile

3.3 Planification du sprint 2

En Tant Que Je Voudrais (User Story)

Administrateur Créer, modifier, supprimer un événement

Utilisateur Consulter et Participer à une événement

staff technique ajouter perfomance pour fidele

Joueur Consulter mes perfomances

Table 3.4 – Backlog du sprint 2


CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

3.3.1 Description textuelle


Le tableau présent la description de cas d’utilisation ≪ créer événement≫

Cas d’utilisation Créer un événement


Acteur(s) Administrateur
Précondition L’administrateur est connecté à l’application.
Postcondition L’événement est créé avec succès dans le système.
1. L’administrateur accède à la section ”Événements”.
2. Le système affiche les informations nécessaires pour ajouter un événement.
Scénario normal 3. L’administrateur fournit les informations de l’événement.
4. L’administrateur clique sur le bouton ”Ajouter”.
5. Un message de confirmation s’affiche : ”L’événement a été créé avec succès”.

Table 3.5 – Description textuelle de cas d’utilisation : Créer un événement

Le tableau présent la description de cas d’utilisation ≪ Participer à un événement≫

Cas d’utilisation Consulter et participer à un événement


Acteur(s) Utilisateur
Précondition L’utilisateur dispose d’un compte valide et est connecté.
L’utilisateur peut consulter les événements disponibles
Postcondition
ou est inscrit avec succès à un événement.
1. L’utilisateur accède à la liste des événements.
2. le système affiche la liste des évenements publiées
Scénario normal 3. l’utilisateur sélectionne un événement .
4. Il clique sur ”Participer”.
5. Le système enregistre l’inscription

Table 3.6 – Description textuelle de cas d’utilisation participer à un événement

Le tableau présent la description de cas d’utilisation ≪ ajouter perfomance≫

Cas d’utilisation Ajouter des performances


Acteur(s) Staff technique
Précondition Le staff technique est connecté à son espace personnel sur l’application.
Postcondition Les performances du joueur sont ajoutées et sauvegardées dans le système.
1. Le staff technique accède à la section ”Performance”.
2. une liste des joueurs s’affichée.
3.le staff selectionne un joueur
Scénario normal 4.le système affiche le formulaire
5. le staff saisit les performances pour le joueur sélectionnée.
6. Il clique sur ”ajouter”.
7. Une confirmation s’affiche.

Table 3.7 – Description textuelle de cas d’utilisation : Ajouter performance

Le tableau présent la description de cas d’utilisation ≪ Consulter perfomance≫


CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

Figure 3.6 – page mes perfomances

Cas d’utilisation Consulter mes performances


Acteur(s) Joueur
Précondition Le joueur est connecté à l’application.
Postcondition Les performances du joueur sont affichées dans son tableau de bord personnel.
1. Le joueur accède à son espace personnel.
Scénario normal 2. Il clique sur l’onglet ”Mes performances”.
3. Le système affiche les perfomances du joueur

Table 3.8 – Description textuelle de cas d’utilisation : Consulter mes performances

3.3.2 Realisation de Sprint 2


3.3.2.1 Interface de page Ajouter Perfomance

Figure 3.5 – page Ajouter Perfomance


CHAPITRE 3. RELEASE 1 : AUTHENTIFICATION && GESTION DU PROFILGESTION DES ÉVÉNEMENT

3.3.2.2 Interface de page mes perfomances

3.4 Conclusion
Ce chapitre vient de présenter le premier release du projet où nous avons planifié, détaillé et
montré les interfaces qui lui correspondent. Dans le chapitre qui suit, notre effort sera consacré à
produire une nouvelle release.
Chapitre 4

Release 2 : Gestion des abonnements et de


billets
Gestion médical

4.1 Introduction
Durant ce chapitre, nous détaillerons notre deuxième release composé de 3 sprint et ayant pour
mission la gestion des abonnements et des billets et la gestion médical D’abord, nous commençons
par la planification illustrée par le Backlog Product de ces trois sprints. Ensuite, nous élaborerons la
partie de l’analyse et nous exposerons notre étude conceptuelle. Enfin, nous clôturerons le chapitre
par la présentation des interfaces développées dans le but de la validation.

4.2 Planification du sprint 3

Rang Use Case User Story


Fidèle Acheter un billet En tant qu’fidèle, je veux acheter un billet
pour un événement afin d’y assister.
Fidèle Souscrire un abonnement En tant qu’fidèle, je veux souscrire un
abonnement pour bénéficier d’un accès
régulier.
Administrateur Gérer les billets En tant qu’administrateur, je veux ajouter
les billets des matchs.
Administrateur Gérer les abonnements En tant qu’administrateur, je veux gérer
les abonnements.
Fidèle Consulter mes achats En tant que fidèle, je veux consulter mes
billets et abonnements pour suivre mes
activités.

Table 4.1 – Backlog du produit pour le sprint 3

4.2.1 Description textuelle du scénario


Le tableau présent la description de cas d’utilisation ≪ ajouter billet ≫

19
CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL20

Cas d’utilisation Ajouterbillet


Acteur(s) Admin
Précondition L’admin est connecté à l’application.
Postcondition le billet est ajoutée avec succèé.
1. L’admin accéede à la page de billet .
2. le système affiche le formulaire d’ajouter billet.
Scénario normal 3. l’admin saisit les informations des billets tel que le type et le prix
4.l’admin clique sur ajouter billet 4. Un message de confirmation s’affiche :
”billet ajoutée avec succès.”

Table 4.2 – Description textuelle de cas d’utilisation ajouter billet

Le tableau présent la description de cas d’utilisation ≪ acheter billet ≫

Cas d’utilisation Acheter billet


Acteur(s) Abonné(e)
Précondition L’utilisateur est connecté à l’application.
Postcondition le billet est achété avec succèé.
1. L’abonnée accéede à la page de billeterie .
2. il sélectionne le type de billet et ajouter au panier.
Scénario normal 3. le fidéle ouvre le panier et clique sur acheter
4. Un message de confirmation s’affiche :
”billet achété avec succès.”

Table 4.3 – Description textuelle de cas d’utilisation Consulter mes abonnements

Cas d’utilisation consulter abonnement


Acteur(s) Abonné(e)
Précondition L’utilisateur est connecté à l’application.
Postcondition la liste des abonnées achetés est affichée
1. L’abonnée accéede à la page de abonnement .
Scénario normal 2. l’abonée clique sur mes abonnées .
3. la liste des abonnements est affichées

Table 4.4 – Description textuelle de cas d’utilisation consulter abonnement


CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL21

4.2.2 Realisation de Sprint 3


4.2.2.1 Interface de page billet

Figure 4.1 – page billet

4.2.2.2 Interface page billeterie

Figure 4.2 – page billeterie


CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL22

4.2.2.3 Interface page acheter abonnement

Figure 4.3 – page acheter abonnement

4.2.2.4 Interface page mes abonnements

Figure 4.4 – mes abonnements

4.3 Planification du sprint 4

En Tant Que Je Voudrais (User Story)

Staff médical Suivre l’état de santé des joueurs et enregistrer les consultations médicales.

Staff médical Consulter le calendrier des rendez-vous médicaux et des matchs.

Table 4.5 – Backlog du produit pour le staff médical


CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL23

4.3.1 Description textuelle


Le tableau présent la description de cas d’utilisation ≪ créer événement≫

Cas d’utilisation Créer un événement


Acteur(s) Administrateur
Précondition L’administrateur est connecté à l’application.
Postcondition L’événement est créé avec succès dans le système.
1. L’administrateur accède à la section ”Événements”.
2. Le système affiche les informations nécessaires pour ajouter un événement.
Scénario normal 3. L’administrateur fournit les informations de l’événement.
4. L’administrateur clique sur le bouton ”Ajouter”.
5. Un message de confirmation s’affiche : ”L’événement a été créé avec succès”.

Table 4.6 – Description textuelle de cas d’utilisation : Créer un événement

Le tableau présent la description de cas d’utilisation ≪ Participer à un événement≫

Cas d’utilisation Consulter et participer à un événement


Acteur(s) Utilisateur
Précondition L’utilisateur dispose d’un compte valide et est connecté.
L’utilisateur peut consulter les événements disponibles
Postcondition
ou est inscrit avec succès à un événement.
1. L’utilisateur accède à la liste des événements.
2. le système affiche la liste des évenements publiées
Scénario normal 3. l’utilisateur sélectionne un événement .
4. Il clique sur ”Participer”.
5. Le système enregistre l’inscription

Table 4.7 – Description textuelle de cas d’utilisation participer à un événement

Le tableau présent la description de cas d’utilisation ≪ ajouter perfomance≫

Cas d’utilisation Ajouter des performances


Acteur(s) Staff technique
Précondition Le staff technique est connecté à son espace personnel sur l’application.
Postcondition Les performances du joueur sont ajoutées et sauvegardées dans le système.
1. Le staff technique accède à la section ”Performance”.
2. une liste des joueurs s’affichée.
3.le staff selectionne un joueur
Scénario normal 4.le système affiche le formulaire
5. le staff saisit les performances pour le joueur sélectionnée.
6. Il clique sur ”ajouter”.
7. Une confirmation s’affiche.

Table 4.8 – Description textuelle de cas d’utilisation : Ajouter performance

Le tableau présent la description de cas d’utilisation ≪ Consulter perfomance≫


CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL24

Figure 4.6 – page mes perfomances

Cas d’utilisation Consulter mes performances


Acteur(s) Joueur
Précondition Le joueur est connecté à l’application.
Postcondition Les performances du joueur sont affichées dans son tableau de bord personnel.
1. Le joueur accède à son espace personnel.
Scénario normal 2. Il clique sur l’onglet ”Mes performances”.
3. Le système affiche les perfomances du joueur

Table 4.9 – Description textuelle de cas d’utilisation : Consulter mes performances

4.3.2 Realisation de Sprint 2


4.3.2.1 Interface de page Ajouter Perfomance

Figure 4.5 – page Ajouter Perfomance


CHAPITRE 4. RELEASE 2 : GESTION DES ABONNEMENTS ET DE BILLETSGESTION MÉDICAL25

4.3.2.2 Interface de page mes perfomances

4.4 Conclusion
Ce chapitre vient de présenter le premier release du projet où nous avons planifié, détaillé et
montré les interfaces qui lui correspondent. Dans le chapitre qui suit, notre effort sera consacré à
produire une nouvelle release.
Conclusion

Diagnosing a disease in a healthy patient does not have the same consequences as predicting the
health of a sick individual. In the first case, unnecessary treatments might be administered, or additio-
nal tests might be requested, leading to costs and inconvenience. In contrast, in the second case, the
lack of diagnosis and appropriate treatment could lead to rapid and irreversible deterioration of the
patient’s health. This issue highlights the importance of the precision and reliability of prediction mo-
dels in medicine, especially for chronic diseases like diabetes. Therefore, to avoid diagnostic errors,
studying and applying data classification techniques in medicine is crucial.
In the context of this project, we applied the CRISP-DM methodology, which allowed us to follow
a structured process, from understanding the application domain (diabetes) to model deployment.
This methodology guided each step of the project, including data collection, cleaning, exploratory
analysis, modeling, model performance evaluation, and finally, deployment. Using an SVM (Support
Vector Machine) model, we were able to predict whether a person is likely to develop diabetes.

26
Bibliographie

27

Vous aimerez peut-être aussi