Chapitre 1 : présentation de cadre du projet

1) Introduction :

L'étude de projet consiste en une approche stratégique qui vise à garantir la bonne exécution
d'un projet en prenant en compte toutes les phases qui le composent. Dans ce premier
chapitre, nous contextualisons notre projet de fin d'études en définissant le cadre dans lequel il
a été élaboré, les problématiques et les objectifs à atteindre. Nous expliquons également la
méthodologie que nous avons suivie pour mener à bien notre travail.

Présentation de l’organisme d’accueil :

Notre projet de fin d'année a eu lieu chez INNOVUP, une start-up tunisienne fondée par M.
Khalil Driss en 2020 qui se spécialise dans le domaine de l'informatique et des nouvelles
technologies. L'équipe principale de notre startup se concentre sur la création d'applications
innovantes et de haute qualité qui améliorent la vie de ses utilisateurs. En outre, ils apportent
leur contribution au projet d'informatisation en aidant à automatiser le gouvernement tunisien.

Notre start-up offre à ses clients des solutions innovantes de premier ordre, visant à produire
des résultats de haute qualité. Nous sommes impatients de voir les avantages des innovations
révolutionnaires en Tunisie et espérons que l'Afrique sera la prochaine destination à en
bénéficier.

a. Les services :

Notre startup propose des différents et larges services en tous les domaines :

 Conception et développent web :

o Site web réactifs
o Backend et frontend avec différents langages de développent : angular, react,
springboot…
o Hébergement et maintenance des sites web
 Conception et développent mobile :
o Application mobile réactifs
o Hébergement et maintenances des application.

 Projet IOT
 Conception numériques :
 o Sliders, flayers, billboards…
o Des divers logos et des modèles Web, des modèles de lettres et des modèles
graphiques personnalisés pour le client
b. Organigramme de la société :

L’organisme de la startup composé par 3 structures principales :

directeur
generale

developpeur web
comerciale
et mobile

Figure 1:Organigramme de la société

2) Etude de l’existant :

L’étude de l’existant est une étape préalable sert à Identifier les lacunes et les imperfections
trouvés et donner un aperçu sur la pertinence de projet, sa faisabilité ainsi que sa continuité.
Elle se définit par la recherche des applications qui sont similaires ou semblables à la nôtre en
vue d’avoir une idée sur ce qui existe actuellement. Deux cas peuvent se présenter :

 Le site existe déjà, il faut donc chercher comment améliorer ses fonctionnalités.
 Le site est inexistant : il faut donc le créer.

Pour nous, nous n’avons pas trouvé un site existant déjà chez l’organisme d’accueil sur lequel
on va dégager les différents points négatifs et par conséquent tenter de l'améliorer. Nous
allons donc créer un nouveau site une recherche, nous avons relevé quelques constats qui
peuvent nous aider pour élaborer la liste des fonctionnalités de notre future application.

Une salle de sport est un lieu où sont rassemblés des équipements destinés à l'exercice
physique. A ce titre, c'est un espace de remise en forme et de bien-être. Les personnes qui
souhaitent s'y inscrire doivent s'y rendre pour en savoir plus sur les différents activités
sportifs et entraîneurs, ainsi que sur les prix et les heures d'ouverture des salles de sport. Et
concernant les salles l’inscription des sportifs, la gestion des coachs et les autres différentes
taches se fait manuellement sur des fichiers Excel que lors d’une panne de fonctionnement
peut causer des pertes des données.

3) Critique de l’existant et solution proposée :

a) Critique de l’existant :
Après une recherche approfondie dans divers sites, nous avons remarqué qu'il existe de
nombreuses insuffisances, telles que l'absence d'un site qui inclut toutes les salles de sport,
ainsi que nous avons pu dénombrer les faiblesses sur deux niveaux :

Niveau client (sportif) :

-la perte du temps après une langue étude pour trouver la salle adaptée avec ses besoins que ce
soit localisation, prix, activités ….

-Le déplacement pour faire l’inscription et le payement.

Niveau salle de sport :

-l’information est décentralisée et dispersée sur plusieurs fichiers ce qui cause le problème de
redondance.

-les contenus des salles sauvegardées dans des dossiers Excel provoque parfois perte des
données.

-l’abondance des informations et les responsabilités de chef que ce soit gestion des emplois du
temps, gestion des coaches et ses autres actions peut engendrer des difficultés.

b) Solution proposée :

Après avoir relevé un ensemble de constats, nous avons décidé en premier lieu de permettre à
tout salle de gérer ses propres catégories de cours et activités d’une façon indépendante des
autres pour qu’il soit plus libre et bénéficie d’une notoriété personnelle. Dans notre
application, la salle est un maître de lui-même.

Cette application permet aussi d’assurer la sécurité des données et leur fiabilité (payement).

Ce projet apporte deux avantages principaux. Le premier c’est le gain de temps relatif au
recherche et l’inscription aux salles pour le client, et le second c’est la simplification de la
tâche du responsable.

4) Langage et méthodologie de modélisation :

Tout projet ayant un niveau de complexité considérable rend l’adoption d’une méthodologie
de développement une nécessité pour garantir une qualité acceptable et éviter tout retard au
niveau des délais. Une méthodologie de développement définit les règles de conduite de notre
projet, les rôles des différents acteurs, l’ordonnancement des tâches, l’enchainement des
actions, etc…

a) Méthode Agile :
La qualité d'un logiciel informatique est le plus important facteur dans le développement
logiciel, les méthodes agiles donnent une grande envergure à cet aspect.

L'objectif principal des méthodes agiles donc est de guider les décisions et la conduite d'un
projet informatique. Plusieurs méthodes agiles ont vu le jour dernièrement, parmi les plus
connu on cite : Scrum, EXtreme Programming (XP), Rational United Process (RUP), Feature
Driven Development (FDD), etc.

La méthode adoptée dans la conduite de notre projet est la méthode SCRUM pour plusieurs
raisons que nous allons citer dans les prochaines parties.

b) La méthode de gestion de projet : SCRUM

SCRUM est la méthode agile la plus connue et utilisée dans la gestion des projets
informatiques. Sa mise en place était pour pallier aux problèmes du non satisfaction de client
ou pire pour les problèmes de retard de livraison ou de dépassement du budget.

SCRUM donc est une méthode efficace pour guider un projet jusqu'à arriver à son terme. Elle
se caractérise par décortiquer le projet en morceaux qui sont des itérations appelés « Sprints »
de courte durée d’un mois maximum.

SCRUM s'appuie sur un formalisme réduit :

• Rôles : Product Owner, Scrum master et une équipe

o Product Owner : Lui c’est l’expert qui collabore avec le client. Souvent le fondateur
ou le boss.

Il définit à la suite des feedbacks clients les spécificités fonctionnelles du produit.

Il les priorise ensuite avec l’équipe.
Il valide les fonctionnalités développées.
Il endosse le rôle du client auprès de l’équipe.
o Equipe : ‍Elle est constituée des développeurs. Dans la méthode SCRUM, il n’est pas
censé y avoir de hiérarchie entre eux, quand bien même leur savoir-faire et
compétence seraient différents. Idéalement une équipe contient 6 à 10 personnes pour
être la plus efficace possible.
o Scrum Master : Le Scrum Master est le guide de l'avancement du projet, celui qui
s’assure que les principes et les valeurs du Scrum sont respectés. C’est
le coordinateur des équipes qui vérifie que la communication est au top. Il améliore
aussi la productivité et il lève les obstacles.
 Les artéfacts de Scrum (Product Backlog, sprint Backlog, sprint rétrospective) :
o Product Backlog :
Dans cette phase, le Product Owner rencontre le client et analyse son besoin. Il
identifie toutes les fonctionnalités dont le produit devra être composé (les user
stories) dans ce qui s’appelle le Product Backlog.

Ce “ cahier des charges “ n’est pas fixé pour toujours, et pourra évoluer en
fonction des besoins du client et l'avancement du projet. L’équipe décide de ce
qu’elle peut faire et dans quel ordre le faire.

o Sprint Backlog :

La méthode SCRUM se caractérise par une répartition de chacune des tâches à

faire. L’équipe trie les fonctionnalités et tâches qu’elle répartit dans des Sprint
(durée de cycle de deux semaines).
Et pendant ce cycle, l’équipe s’occupera par exemple uniquement de coder une
fonctionnalité du produit qu’elle devra livrer à la fin de cette phase.
Le sprint planning meeting : on organise avant chaque sprint une réunion
de planification.
 C’est une sorte de négociation entre le Product Owner et l’équipe technique : le
sprint planning meeting. Cette réunion permet de sélectionner dans le Product
Backlog les exigences les plus prioritaires pour le client.
Le Product Owner propose des user stories. L’équipe technique analyse les user
stories, les traduit en tâches techniques, et regarde en combien de temps chacune
des user stories pourra être réalisée. Après négociation et décision concernant les
choses à faire, les tâches constituent le sprint Backlog.
o Sprint rétrospective : Rétrospective de sprint : Il s’agit d’une réunion qui aura lieu
à la fin du sprint. Cette fois-ci, c’est le Scrum Master qui intervient pour organiser
cette réunion. Au cours de cette rencontre, les idées de chaque membre de l’équipe
sont prises en considération en vue d’améliorer le rendement global de l’équipe «
La rétrospective du sprint est faite en interne avec toute l’équipe du projet le
dernier jour de l’itération. L’objectif est d’inspecter l’itération précédente, afin de
déterminer quels sont les éléments du processus de développement qui ont bien
fonctionné et ceux qui sont à améliorer. Chaque membre de l’équipe s’exprime sur
le déroulement de l’itération, afin d’améliorer en continu le processus projet.

Figure 2:Rôles de « SCRUM »

Par rapport à des autres approches, SCRUM s'avère léger, facile à maîtriser et à apprendre
mais également Extrêmement difficile à entreprendre. Toute au long de notre projet on a
essayé d'être fidèle et conforme aux plupart des évènements et de Timeboxes présents dans
cette méthode pour s'approcher au plus à satisfaire les besoins de notre client et respecter les
délais de livraison.
5) Conclusion :

Ce chapitre constitue une partie introductive de notre projet. En premier lieu, une présentation
du cadre général a été établie, en évoquant notamment notre objectif ainsi que les différentes
étapes et ramifications. En deuxième lieu la problématique a permis également de mettre en
relief les raisons qui ont contribuées à la naissance de notre projet, ainsi que les différentes
caractéristiques de la nouvelle solution. Enfin, nous avons décrit notre choix méthodologique
et technologique.
Chapitre 2 : Planification du projet
1) Introduction

Le chapitre précédent a introduit la méthodologie Scrum, que nous avons choisie pour
concevoir notre prochain système. Scrum est organisé en trois phases, la première étant la
phase de planification (appelée Sprint 0). Cette phase est essentielle pour la réalisation de
notre projet car elle permet de visualiser le produit, d'identifier les acteurs réactifs et de leur
associer un ensemble d'actions pour produire le backlog initial et planifier les premiers
sprints.
Dans ce chapitre, nous allons nous concentrer sur cette phase en commençant par la capture
des différents besoins de notre client, l'identification des rôles des utilisateurs et la préparation
de notre plan de sortie. Il s'agit d'une étape cruciale qui nous permettra de garantir le succès de
notre projet en fournissant une vision claire et en alignant les actions des acteurs impliqués.

2) Capture des besoins

2.1 Identification des acteurs

Les entités utilisant un système peuvent être soit des individus physiques tels que des
personnes, soit des entités immatérielles telles que des programmes informatiques. Les acteurs
sont des entités qui interagissent avec le système pour répondre à des besoins spécifiques.
Dans notre système, les acteurs qui peuvent interagir sont les suivants :
 Administrateur : cet acteur est le principal utilisateur de l'application. Il a le pouvoir de
gérer tous les utilisateurs de l'application ainsi que toutes les mises à jour disponibles
pour la manipulation des différents services.
 Propriétaire de salle de sport
 Sportif
2.2 Les besoins fonctionnels
Un langage UML, les besoins fonctionnels ou les cas d'utilisation sont définis comme un
ensemble d'actions que le système doit accomplir en collaboration avec les acteurs afin
d'atteindre un objectif précis. Ces besoins fonctionnels décrivent les différentes
fonctionnalités du système et les interactions entre le système et les acteurs, que ce soit des
utilisateurs, des systèmes externes ou d'autres entités. Ils permettent de déterminer les
exigences fonctionnelles du système et de spécifier les fonctionnalités qui seront
implémentées. En somme, les besoins fonctionnels ou cas d'utilisation sont un élément clé de
la modélisation des systèmes informatiques, car ils permettent de comprendre les actions
requises pour répondre aux besoins des utilisateurs et des autres parties prenantes. Dans le
cadre de notre système, les différents besoins fonctionnels comprennent :
 L’administrateur
Authentification : afin que l’administrateur puisse effectuer ses tâches, il doit être authentifié
par son login et mot de passe.
Gérer admin : l'administrateur peut ajouter, supprimer et modifier de leu informations
personnelles depuis son espace privé.
Gérer sportif : une fois connecté, l'administrateur peut gérer les sportifs par l’ajout, la
suppression et la modification de leurs informations personnelles depuis son espace privé.
Gérer propriétaire : l'administrateur peut gérer les propriétaires de salle de sport par
l’ajout, la suppression et la modification de leurs informations personnelles depuis son
espace privé.
Maintenir du site : le système doit permettre à l'administrateur de maintenir le site en
effectuant des opérations telles que la mise à jour du contenu, la résolution des problèmes
techniques et la gestion des erreurs.
Gérer factures : Cette fonction permet à l'administrateur de gérer les factures des
utilisateurs, par la consultation et le téléchargement.
Gérer compte : L'administrateur peut également gérer ses comptes, d'ajouter, de supprimer
et de modifier leurs informations personnelles.
 Propriétaire de salle de sport

Inscriptions : Le propriétaire de salle de sport doit s'inscrire en remplissant un formulaire

pour faire partir de notre plateforme
Authentification : le système doit offrir la possibilité au propriétaire de la salle de sport de
confirmer son identité afin d'accéder à des fonctionnalités exclusives.
Gérer catégories : création, modification et suppression des catégories des cours et de
services proposés de salle est une fonctionnalité le propriétaire a le droit de le faire.
Gérer d’emploi de temps : création, modification et suppression des horaires de cours,
visualisation des emplois du temps sous forme de calendrier.
Gérer entraîneurs : le propriétaire de salle de sport peut ajouter modifier et supprimer les
entraîneurs.
Gérer des paquets : les propriétaires ont le droit de gérer les paquets les en ajouter les
modifier et les supprimer.
Gérer facture :la consultation et le téléchargement des factures sont les rôles liés aux
propriétaires
Gérer compte : Le propriétaire de salle de sport peut également gérer leurs comptes,
d’ajouter, de supprimer et de modifier leurs informations personnelles.
Gérer salle de sport : Pour assurer le bon fonctionnement de la salle de sport et la
satisfaction des membres, il est important de gérer efficacement les salles de sport en fait
l’ajout, la modification et la suppression des salles.
 Sportif
Inscriptions : Le sportif doit s'inscrire en remplissant un formulaire pour faire partir de notre
plateforme.
Authentification : Une fois que le sportif est authentifié, il peut accéder aux fonctionnalités
de l'application spécifique.
Gérer paquet : Le sportif peut consulter les paquets disponibles et leurs tarifs, et peut
également acheter un paquet.
Gérer compte : Le propriétaire de salle de sport peut également gérer leurs comptes,
d’ajouter, de supprimer et de modifier leurs informations personnelles.
Gérer facture : Les sportifs peuvent consulter et télécharger leurs factures.
 Internaute

Consulter salle de sport : Pour en savoir plus sur les équipements, les cours et les
programmes proposés par la salle de sport.

2.3 Besoin non fonctionnels

Les besoins non fonctionnels d'une application sont les objectifs de performance et les
contraintes environnementales qui doivent être respectées pour assurer un fonctionnement
optimal du système. Ces besoins sont souvent exprimés sous forme d'objectifs précis à
atteindre. Dans le contexte de notre application, nous avons identifié plusieurs besoins non
fonctionnels importants, tels que :

 Fiabilité : notre système doit être fiable et offrir un service continu sans
interruptions ni erreurs.
 La disponibilité du système : l'application doit être disponible pour les
utilisateurs à tout moment, sans interruption de service, pour garantir une
expérience utilisateur fluide.
 Les besoins ergonomiques : sont un aspect clé de notre application, étant
donné que les utilisateurs qui vont l'utiliser sont de différents niveaux
d'expérience.
 Interfonctionnel : notre système doit être capable de communiquer avec
d'autres systèmes externes, tels que des services de paiement en ligne, pour
offrir une expérience utilisateur plus complète.
 Évolutivité : le système doit être évolutif et capable de s'adapter aux
changements futurs, tels que l'ajout de nouvelles fonctionnalités ou la prise en
charge de nouveaux types d'utilisateurs.
 Convivialité : l'interface utilisateur doit être conviviale et facile à utiliser pour
tous les utilisateurs, qu'ils soient des administrateurs, des propriétaires de salles
de sport ou des sportifs.
 Sécurité : les données des utilisateurs doivent être protégées contre les accès
non autorisés, les attaques et les tentatives de piratage.
 Les performances : l'application doit être rapide et réactive, pour assurer une
expérience utilisateur agréable et éviter les temps d'attente.
  La compatibilité : l'application doit être compatible avec les différents
navigateurs web, les systèmes d'exploitation et les appareils utilisés par les
utilisateurs.

3) Diagramme de cas d’utilisation global

Dans cette section, nous allons formaliser les besoins du système en utilisant le langage de
modélisation UML et plus précisément le diagramme de cas d'utilisation.
Ce dernier va nous permettre d'avoir une vue d'ensemble sur le comportement fonctionnel de
notre système logiciel. Il est important de souligner que tous les cas d'utilisation de notre
projet nécessitent une authentification préalable. De plus, pour répondre aux besoins
ergonomiques des utilisateurs, toutes les interfaces doivent être conçues de manière à garantir
une utilisation facile et intuitive .
 Figure 2.1 « Diagramme de cas d’utilisation global »

4) Planning du traitement des cas d'utilisation

Après avoir identifié les besoins du client, notre travail consiste à écouter, comprendre et
expliquer le contexte et les objectifs du projet. Nous essayons de nous mettre à la place des
utilisateurs finaux pour mieux comprendre leurs besoins. Ensuite, nous classons les cas
d'utilisation en fonction de leur importance et des risques qu'ils peuvent présenter. Cette
classification nous permet de mieux organiser les priorités. L'objectif est de parvenir à un
résultat clair et accepté par tous les acteurs du projet.
4.1 Priorités
Il est important de classer les cas d'utilisation en fonction de leur priorité afin de déterminer
le chemin le plus important pour atteindre l'objectif global. Si le cas d'utilisation A est crucial
pour la stabilité du système, il aura une priorité plus élevée que le cas d'utilisation B. La
sélection des priorités est basée sur les dépendances entre les fonctions d'application. Par
exemple, avant de pouvoir attribuer une liste d'abonnements, nous devons d'abord gérer les
informations sur les sportifs et les propriétaires de salles de sport. Pour cela, nous avons
défini trois priorités : haute, moyenne et faible, pour mieux organiser les tâches.
4.2 Risques
Dans la gestion d'un projet, il est important d'identifier les risques critiques pour assurer sa
réussite. Cela consiste à évaluer les impacts négatifs possibles d'une tâche mal définie ou mal
calibrée sur l'ensemble du projet.
Les Risques Type Impact sur le Action correctives
projet
Les performances
de mon PC Retard dans
peuvent être Risque acceptable l'achèvement Changement de pc
compromises par
certains facteurs de
risque.
Table 2.1 « Risque du projet »

5) Prototype des interfaces :

Un prototype est un modèle original qui possède tous les attributs techniques et les
capacités fonctionnelles.
Les capacités d'un nouveau produit à fonctionner.
Dans le domaine du développement d'applications, une technique a émergé :
Il s'agit par le développement de prototypes 1.
Cette méthode implique la création de certains composants visuels de l'application.
À l'aide d'un outil de conception de prototype pour valider la préférence du client, cela
facilitera notre projet.
Améliorer et optimiser avant l'actualisation pour éviter d'être pris dans des décisions
erronées qui seraient, il est difficile de modifier une fois l'application créée. Au-delà de
certaines frontières reconnues.
5.1 Une méthode qui consiste à créer un prototype :
 Interface authentification : l’utilisateurs va connecter avec une adresse et mot de passe.
Figure 2.2 : Interface d’authentification

Interface Gérer sportif : l'utilisateur peut accéder à toutes les informations et peut aussi fait une mise à
jour leur compte

Figure 2.3 « Interface Gérer sportif »

 L'interface de la salle de sport : activité et fonctionnalité de la salle de sport et tout ce qui
s'y rapporte.
Figure 2.4 « Interface Gérer salles des sports »

6) Pilotage du projet avec Scrum

Le cadre Scrum est composé de plusieurs composants qui incluent une équipe spécifique,
des délais différents et des artefacts spécifiques.
6.1 Les outils Scrum
La gestion des projets Scrum nécessite une attention particulière pour suivre les idées
fonctionnelles, les progrès réalisés et corriger la dérive éventuelle. Pour cela, les membres de
l'équipe ont recours à différentes techniques, parmi lesquelles la création d'un tableau de Post-
It qu'ils peuvent consulter et modifier collectivement, ou l'utilisation d'un fichier Excel qui
contient toutes les informations nécessaires pour les sprints, les user stories, les estimations,
etc. Ce fichier doit être partagé en lecture-écriture pour une collaboration optimale. Pour notre
projet, nous avons opté pour l'utilisation de Trello, un outil de gestion de projet en ligne, afin
de travailler efficacement sur les user stories et de suivre l'avancement du projet en temps
réel.
6.2 Équipe et rôle
Scrum propose un modèle d'équipe qui vise à maximiser la flexibilité, la créativité et la
productivité. Cette équipe est composée de différents membres.
 Concepteur/développeur
 Élaboration d'un dossier détaillé de gestion de projet.
 Création d'une spécification détaillée de l'application.
 Programmation de l'application.
 Exécution de tests unitaires pour vérifier la conformité de l'application.
 Scrum master
  Valide les spécifications fonctionnelles du dossier.
 Évalue la qualité du codage.
 Approuve les livrables selon les attentes.
 Vérifie que les demandes sont satisfaites.
 Product Owner
 Présente les exigences du projet.
 Articule une vision précise du produit et en définit les caractéristiques.
 Évalue et valide le produit à la fin de chaque sprint.
 S'assure que l'équipe se focalise sur les items les plus importants du back log.
 Indique que la sortie a été acceptée.

Nom et Prénom Type Fonction/Rôles dans le projet

Manel Khzemi & Oumaima Jbeli Stagiaires/Développeurs junior
Ibtissem Cherni Encadrant/Scrum Master
Khalil Driss Responsable société/Product Owner

Table 2.2 « Equipes de réalisation de projet »

6.3 Le back log du produit

Le back log de produit est un élément essentiel de Scrum, car il permet de recueillir
tous les besoins du client que l'équipe projet doit satisfaire. Notre application dispose
également d'un back log, présenté dans le tableau 1, qui résume les éléments clés de
notre produit, tels que les histoires utilisateurs.

Ces histoires sont rédigées en une ou deux phrases décrivant clairement et précisément
les fonctionnalités souhaitées par le client, et suivent généralement la structure « En
tant que X, je veux Y, afin de Z ». Chacune d'entre elles est également identifiée par
un ID, qui correspond à sa priorité dans le back log (décrite dans la section 3 de ce
chapitre).

Nous avons choisi de traiter en premier lieu les cas d'utilisation les plus prioritaires de
notre back log. Chaque histoire utilisateur est également accompagnée d'une
estimation initiale de l'effort nécessaire pour la réaliser, mesurée en points d'histoire
(équivalent à des jours/homme idéaux). Cette estimation nous permet de planifier et de
suivre l'avancement de nos développements de manière précise.

ID Nom Description Priorité Effort

1 Authentification
2 Inscription
L'application requiert une Haut 1
authentification des
utilisateurs avant de leur
permettre d'utiliser ses
fonctionnalités.
En tant qu’utilisateur, je Haut 1
souhaite m'inscrire au
programme pour profiter
 des avantages offerts.
3 Gérer admin En tant qu'administrateur, Haut 1
je veux pouvoir ajouter
des utilisateurs à
l'application afin qu'ils
puissent se connecter.
4 Gérer sportif En tant qu'administrateur, Haut 1
je dois créer deux listes de
sportif : une liste des
sportif acceptés et une
liste des sportif refusés.
5 Maintenir de site En tant qu'administrateur Moyenne 2
de site web, mon travail
consiste à maintenir le
site en bon état de
fonctionnement.
6 Gérer facture En tant qu'administrateur, Haut 1
je suis chargé de gérer les
factures en émettant des
factures précises et en
collectant les paiements
dus.
7 Gérer compte En tant qu'administrateur, Haut 1
la gestion de mon compte
est importante pour
m'assurer que j'ai accès à
toutes les informations
dont j'ai besoin.
8 Gérer propriétaires En tant qu'administrateur, Haut 1
je dois créer deux listes de
propriétaires de salles de
sport : une liste des
propriétaires de salles de
sport acceptés et une liste
des propriétaires de salles
de sport refusés.
9 Gérer paquets En tant que sportif, je suis Haut 1
intéressé à consulter les
différents paquets offerts
pour trouver celui qui
convient le mieux à mes
besoins.
10 Gérer compte En tant que sportif, la Haut 1
gestion de mon compte
est importante pour
m'assurer que j'ai accès à
toutes les informations
dont j'ai besoin pour mes
activités sportives.
11 Gérer facture En tant que sportif, il est Haut 1
 possible que vous soyez
chargé de gérer les
factures liées à votre
activité sportive, telles
que les frais d'inscription
aux compétitions, les
dépenses de voyage pour
les événements sportifs.
12 Gérer catégories En tant que propriétaire Haut 1
de salle de sport, je suis
responsable de la gestion
de différentes catégories
d'équipements et
d'activités proposées dans
ma salle de sport.
13 Gérer d’emploi de En tant que propriétaire Haut 1
temps de salle de sport, je suis
responsable d’organiser le
temps de travail de
personnel pour que ma
salle de sport fonctionne
bien.
14 Gérer facture Tout à fait, en tant que Haut 1
propriétaire de salle de
sport, vous êtes
probablement chargé de
gérer les factures liées à
votre salle de sport.
15 Gérer compte Vous pourrez peut-être Haut 1
ajouter des informations
sur votre salle de sport,
publier des offres
spéciales ou des
promotions, gérer les
abonnements et les
paiements, et
communiquer avec vos
clients.
16 Gérer entraîneurs En tant que propriétaire Haut 1
de salle de sport, la
gestion des entraîneurs est
une partie importante de
mon travail.
17 Gérer paquet En tant que propriétaire Haut 1
de salle de sport, la
gestion de paquet est une
partie importante de mon
travail.
18 Gérer salle de En tant que propriétaire Haut 1
sport de salle de sport, j'ai pour
 mission de classer les
salles de sport en deux
catégories : celles qui sont
acceptées et celles qui
sont rejetées. Pour ce
faire, je dois créer une
liste pour chaque
catégorie.
19 Consulter salle de En tant qu'internaute, il Haut 1
sport est tout à fait possible de
consulter une salle de
sport en ligne pour en
savoir plus sur ses offres,
ses équipements, ses
horaires de cours et
d'autres informations
pertinentes.
Table 2.3 « Back log du produit »
6.4 Planification des sprints
La réunion de planification des sprints est un moment crucial pour tout projet utilisant la
méthodologie Scrum. Elle vise à établir le planning de travail et à définir le back log des
sprints. Lors de cette réunion, nous avons sélectionné une durée de 20 jours pour chaque
sprint, ce qui est adapté à notre projet en termes de complexité et de taille d'équipe. Nous
avons également planifié deux releases pour notre projet, chacune ayant des objectifs
spécifiques : la première portera sur la gestion d'accès et l'administration générale, tandis que
la seconde se concentrera sur d'autres aspects tels que la gestion de la salle de sport et des
sportifs. Pour résumer notre plan de travail, voici un schéma :
 Figure 2.5 « L’organigramme des tache »

7) Architecture de la solution
7.1 Architecture logique
L'architecture logique est un processus qui permet d'identifier les différents
composants logiciels nécessaires à l'implémentation d'une solution. Elle décrit
également les relations et les interactions entre ces composants afin de garantir un
fonctionnement cohérent et efficace du système.

Figure 2.7 « Architecture logique »

7.2 Architecture logicielle

L'architecture logicielle désigne l'identification des différents composants logiciels
nécessaires à la mise en place d'une solution, et la description de leurs interactions.
L'un des motifs les plus populaires pour les interfaces graphiques est le Modèle-Vue-
Contrôleur ou MVC, qui a été lancé en 1978. Ce motif se compose de trois types de
modules ayant chacun une responsabilité particulière : les modèles, les vues et les
contrôleurs. Les modèles contiennent les données à afficher, les vues présentent
l'interface graphique, tandis que les contrôleurs contiennent la logique liée aux actions
de l'utilisateur. De nombreux Framework pour applications web utilisent ce motif,
notamment Ruby on Rails, Grails, ASP.NET MVC, Spring, Struts, Symfony, Apache
Tapestry, Laravel, ou AngularJS.
 Le rôle du modèle : dans l'architecture MVC est de représenter les données et
la logique métier de l'application. Il contient les informations nécessaires pour
interagir avec la base de données ou tout autre système de stockage de données
utilisé par l'application. Le modèle est responsable de garantir la cohérence des
données et d'assurer l'intégrité des informations stockées. Le modèle offre des
méthodes pour insérer, supprimer et modifier les données stockées. Il offre
également des méthodes pour récupérer les données nécessaires à la vue. Le
modèle peut également autoriser plusieurs vues partielles des données, ce qui
permet d'afficher les données sous différentes formes selon les besoins de
l'application. En résumé, le modèle représente la logique métier de l'application
et offre une interface pour manipuler les données stockées.
 la rôle de vue : est également responsable de la présentation graphique des
données et de l'interface utilisateur. Elle doit être facilement compréhensible et
utilisable pour l'utilisateur final. La vue peut également offrir des options de
personnalisation pour l'utilisateur, telles que des réglages de taille, de couleurs
et de thèmes. En résumé, la vue est la partie de l'application qui permet à
l'utilisateur de voir et d'interagir avec les données, en fournissant une interface
conviviale et efficace.
 Le contrôleur : joue un rôle crucial dans la séparation des préoccupations
entre la vue et le modèle. Il est responsable de recevoir tous les événements de
l'utilisateur, d'enclencher les actions appropriées et de synchroniser les
interactions entre la vue et le modèle. Si une action nécessite une modification
des données, le contrôleur demande au modèle de procéder à la modification,
puis informe la vue que les données ont changé pour que celle-ci se mette à
jour. En cas d'événements utilisateur qui ne concerne pas les données, mais
plutôt la vue elle-même, le contrôleur demande à la vue de se modifier en
conséquence. Le contrôleur assure ainsi une coordination efficace entre les
différents composants de l'architecture.
 Figure 2.8 « Architecture logicielle »

8) Conclusion
Ce chapitre a permis de définir clairement les contours du projet en identifiant les besoins
fonctionnels et non fonctionnels, les acteurs impliqués et le Back log du produit. Ensuite, il a
permis de planifier le temps nécessaire à la réalisation du projet en établissant les sprints.
L'architecture et l'environnement matériel et logiciel ont également été définis. La prochaine
étape consistera à lancer la phase d'initialisation du projet.

Chapitre 3
Mise en œuvre de release 1
1. Introduction
Le présent segment se concentre sur l'intégration de la méthode Scrum, une approche Agile,
dans notre projet. Nous prévoyons d'effectuer une analyse approfondie afin de répartir les
différentes fonctionnalités de l'application dans un Backlog. Nous prévoyons également de
planifier les sprints et d'estimer le temps nécessaire pour achever la release. Le Product
Owner, en collaboration avec les autres membres de l'équipe, est chargé de déterminer la
durée des releases. Notre première release se composera de deux sprints, chacun ayant une
durée de 14 jours et une vélocité totale de 28 jours. Le présent chapitre marque le début de
notre premier sprint, durant lequel nous examinerons le Backlog du Sprint afin de détailler les
multiples fonctionnalités à implémenter. Nous envisageons d'y parvenir en concevant et en
effectuant les travaux nécessaires (l’analyse, la conception, la réalisation et les tests
fonctionnels de chaque sprint).

2. Sprint 1
Sprint est un cycle de projet défini par le Framework Agile Scrum, dans lequel une série de
tâches est exécutée pour progresser dans une nouvelle phase de développement d'un produit.
Il s'agit d'une itération agile d'une durée de 1 à 4 semaines, durant laquelle l'équipe du projet
réalise un travail défini et fournit un incrément pour atteindre un objectif spécifique. Le travail
effectué dans ces cycles courts permet une adaptation rapide aux évolutions et facilite la
collecte des commentaires des utilisateurs.

a) Backlog de produit
Au cours de cette section, nous allons présenter le Backlog de produit sous forme d'un
tableau. Le Backlog consiste en une liste de fonctionnalités requises pour le produit. Chaque
fonctionnalité est exprimée sous la forme d'une "User Story", qui est une explication non-
formelle et générale du point de vue de l'utilisateur final. Nous allons spécifier la priorité de
chaque User Story ainsi qu'un nombre appelé "Story Points", qui représente le niveau de
difficulté de la tâche. Ce nombre est estimé en utilisant la suite de Fibonacci.

I Feature User story Priorité Story

D point
1 Authentification En tant qu’administrateur il Haut 1
faut s’authentifier pour
accéder à son espace
administratif.
2 Gérer administrateur :

-Ajouter administrateur L’administrateur a le droit Haut 1

-Modifier administrateur
-consulter administrateur
-supprimer administrateur
2 Gérer propriétaire de la salle
de sport :
-Ajouter propriétaire de la
salle de sport
d’ajouter des utilisateurs.
L’administrateur a le droit de Haut 1
modifier des utilisateurs.
L’administrateur a le droit de Haut 1
consulter les utilisateurs.
L’administrateur a le droit de Haut 1
supprimer les utilisateurs.
L’administrateur a le droit Haut 1
d’ajouter des propriétaires des
salles de sport.

-Modifier propriétaire de la L’administrateur a le droit de Haut 1

salle de sport modifier des propriétaires des
salles de sport.

-consulter propriétaire de la L’administrateur a le droit de Haut 1

salle de sport consulter des propriétaires
des salles de sport.

-supprimer propriétaire de la L’administrateur a le droit de Haut 1

salle de sport supprimer des propriétaires
des salles de sport.
2 Gérer sportif :

-Ajouter sportif L’administrateur a le droit Haut 1

-Modifier sportif
-consulter sportif
-supprimer sportif
d’ajouter des sportifs.
L’administrateur a le droit de Haut 1
modifier des sportifs.
L’administrateur a le droit de Haut 1
consulter sportifs.
L’administrateur a le droit de Haut 1
supprimer sportifs.

Table 3.1 – Backlog du sprint1

b) Tableau des taches

L'outil de gestion de projet appelé tableau des tâches est un moyen efficace de suivre l'état
d'avancement des travaux d'un sprint. Ce tableau est constitué de trois colonnes distinctes :
"A faire", "En cours" et "Réalisé". La première colonne énumère toutes les tâches à
effectuer pour développer une User Story. La deuxième colonne recense toutes les tâches
en cours de développement. Enfin, la troisième colonne répertorie toutes les tâches déjà
achevées avec succès.
c) Analyse
Allons maintenant droit au but et parlons des activités et cycles de développement. Pendant
le sprint, nous identifions les activités clés, à savoir la spécification fonctionnelle, la
conception et les tests, et nous les respectons pour établir notre plan de travail. Cela nous
permet de travailler de manière méthodique et de progresser efficacement dans le
développement de notre projet.
Identification des acteurs et des cas d’utilisation
A la fin de ce sprint, l’administrateur aura la possibilité de :
 S’authentifier pour accéder à l’application.
 Gérer utilisateurs :
Gérer administrateurs :(ajouter, modifier, consulter et supprimer).
Gérer Propriétaire de salle de sport :(ajouter, modifier, consulter et supprimer)
Gérer sportif :(ajouter, modifier, consulter et supprimer)
 Description des cas d’utilisation : fiche de cas d’utilisation
 Authentifier
Avant de commencer les différentes taches de l’application l’administrateur doit
s’authentifier.

Cas Authentification
Acteur Administrateur
Résumé L’administrateur s’authentifié avec son
login et son mot de passe
Pré condition(s) Système opérationnel et paramètres saisis
Post condition(s) Administrateur authentifié

Scénario nominal -Le système affiche la page de connexion.

-L’administrateur saisie son login et mot de
passe.
-Le système vérifie si les champs
obligatoires sont remplis.
-Le système recherche dans la base de
données.
-Le système affiche son espace privé.
Scénario(s)alternatif
A : si un champ manquant :
- 3 Le système affiche un message d’erreur.
B Les données introduites ne correspondent
pas aux informations stockées dans la base
de données.
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide la saisie.

 Gestion des utilisateurs

La responsabilité de la gestion des utilisateurs incombe à l'administrateur, qui détient
les privilèges pour ajouter, modifier, supprimer et consulter les utilisateurs en fonction
des besoins de l'entreprise. Pour faciliter la compréhension de cette procédure, une
illustration du cas d'utilisation de la gestion des utilisateurs est présentée au-dessous.

 Gestion administrateur

 Ajouter administrateur
La gestion des administrateurs est une tâche assignée à l'administrateur qui peut ajouter des
nouveaux comptes. Cependant, ces fonctionnalités ne sont accessibles qu'après une
authentification préalable pour des raisons de sécurité.

Cas Ajouter administrateur

Acteur Administrateur
Résumé C’est une tache ayant le but d’ajouter des
nouveaux administrateurs.
Pré condition(s) Administrateur est authentifié
L’administrateur choisit l’ajout des
nouveaux administrateurs
Post condition(s) L’ajout des administrateurs se fait avec
succès
Scénario nominal 1. L’administrateur clique sur le bouton «
ajouter ».
2. Le système affiche le formulaire d’ajout
du nouvel administrateur.
3. L’administrateur saisit les nouveaux
donnés.
4. L’administrateur valide le remplissage.
5.Le système vérifie les données et les
ajoutées dans la base de données.
Scénario(s)alternatif
A : En cas de champ manquant,
- 3 Le système affiche un message d’erreur.
B : Les informations fournies ne concordent
pas avec celles enregistrées dans la base de
données.
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide le
remplissage.

 Modifier administrateur
 Cas Modifier administrateur
Acteur Administrateur
Résumé Il s'agit d'une tâche qui vise à modifier les
anciennes données enregistrées des
administrateurs.
Pré condition(s) Administrateur est authentifié
Administrateur déjà présent.
Post condition(s) Les données ont été correctement modifiées
Scénario nominal 1. L’administrateur clique sur le bouton «
Modifier ».
2. Le système affiche le formulaire de
modification d’administrateur choisit.
3. L’administrateur modifié les anciennes
données.
4. L’administrateur valide le remplissage.
5.Le système vérifie les données et les
ajoutées dans la base de données.
Scénario(s)alternatif
A : En cas de champ manquant,
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide le
remplissage.

Gérer propriétaire des salles de sport

 Supprimer propriétaire de la salle de sport
Cas Supprimer administrateur
Acteur Administrateur
Résumé En se fondant sur les comptes des
utilisateurs stockées dans la base de
données, l'administrateur a la capacité de
supprimer des propriétaires des salles de
sport.
Pré condition(s) - L’administrateur est authentifié.
-propriétaire déjà présent
Post condition(s) La suppression des propriétaires se fait avec
succès
Scénario nominal 1. L’administrateur clique sur le bouton «
supprimer » après avoir choisir le
propriétaire adéquat à supprimer.
2. Le système affiche un message de
confirmation.
3.L'administrateur confirme sa décision.
4.Le système procède à la suppression de
propriétaire.

Scénario(s)alternatif A : Si l'administrateur décide d'annuler sa

décision
-3 le système annule la suppression de
propriétaire.

 Consulter propriétaire de salle de sport

 Cas Consulter propriétaire de la salle de sport
Acteur Administrateur
Résumé L’administrateur a le droit de lister les
propriétaires.
Pré condition(s) - L’administrateur est authentifié.
-propriétaire déjà présent
Post condition(s) Liste des propriétaires est affichée.
Scénario nominal 1. L’administrateur clique sur le bouton de
propriétaire choisit.
2. Le système affiche les informations de
propriétaire adéquat.

Gérer sportif
 Ajouter sportif

Cas Ajouter sportif

Acteur Administrateur
Résumé C’est une tache ayant le but d’ajouter des
nouveaux sportifs.
Pré condition(s) Administrateur est authentifié
L’administrateur choisit l’ajout des
nouveaux sportifs
Post condition(s) L’ajout des sportifs se fait avec succès
Scénario nominal 1. L’administrateur clique sur le bouton «
ajouter ».
2. Le système affiche le formulaire d’ajout
 du nouvel sportif.
3. L’administrateur saisit les nouveaux
donnés.
4. L’administrateur valide le remplissage.
5.Le système vérifie les données et les
ajoutées dans la base de données.
Scénario(s)alternatif
A : En cas de champ manquant,
- 3 Le système affiche un message d’erreur.
B : Les informations fournies ne concordent
pas avec celles enregistrées dans la base de
données.
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide le
remplissage.

 Modifier sportif

Cas Modifier sportif

Acteur Administrateur
Résumé Il s'agit d'une tâche qui vise à modifier les
anciennes données enregistrées des sportifs.
Pré condition(s) Administrateur est authentifié
Sportif déjà présent.
Post condition(s) Les données ont été correctement modifiées
Scénario nominal 1. L’administrateur clique sur le bouton «
Modifier ».
2. Le système affiche le formulaire de
modification de sportif choisit.
3. L’administrateur modifié les anciennes
données.
4. L’administrateur valide le remplissage.
5.Le système vérifie les données et les
ajoutées dans la base de données.
Scénario(s)alternatif
A : En cas de champ manquant,
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide le
remplissage.

 Supprimer sportif

Cas Supprimer sportif

Acteur Administrateur
Résumé En se fondant sur les comptes des
utilisateurs stockées dans la base de
données, l'administrateur a la capacité de
supprimer les sportifs.
Pré condition(s) - L’administrateur est authentifié.
-sportif déjà présent
Post condition(s) La suppression des sportifs se fait avec
succès
Scénario nominal 1. L’administrateur clique sur le bouton «
supprimer » après avoir choisir le sportif
adéquat à supprimer.
2. Le système affiche un message de
confirmation.
3.L'administrateur confirme sa décision.
4.Le système procède à la suppression de
sportif.

Scénario(s)alternatif A : Si l'administrateur décide d'annuler sa

décision
-3 le système annule la suppression de
propriétaire.

d. conception
 À ce stade, notre approche commence par la conception statique du système en examinant
les différents cas d'utilisation qui ont été présentés en détail dans la section précédente. Nous
cherchons à déterminer les différentes entités impliquées dans chaque cas d'utilisation et les
relations entre ces entités. Cette étape nous permettra de définir les classes du système et leur
hiérarchie, ainsi que les attributs et les méthodes de chaque classe. Cette conception statique
est essentielle pour assurer une implémentation efficace et bien structurée du système.
 Conception statique du sprint
Dans notre approche de conception statique, nous décrivons les différents composants
du système indépendamment de leur évolution dans le temps.
Un élément clé de cette conception est le diagramme de classe, qui exprime la structure
statique du système en décrivant toutes les classes et leurs associations. Chaque classe décrit
un ensemble d'objets, c'est-à-dire les instances de cette classe. En d'autres termes, la classe
représente les caractéristiques communes à un groupe d'objets, en ignorant les différences
individuelles. Lors de l'analyse et de la conception, il est préférable de réfléchir en termes de
classes plutôt que d'objets individuels. Les diagrammes de conception de classes sont
généralement divisés en trois compartiments : le compartiment supérieur contient le nom de la
classe, le compartiment du milieu contient les attributs de la classe, et le compartiment
inférieur contient les méthodes de la classe.

Champs Type Contraintes

Id Int PRIMERY KEY
 Email TEXT UNIQUE
Nom TEXT
Adresse TEXT
Numéro du téléphone TEXT
Sexe TEXT
Date de naissance TEXT
Photo TEXT
Mot de passe TEXT
Type TEXT

 Conception dynamique du sprint

La conception dynamique de notre système vise à décrire comment il réagit face à son
environnement. Pour ce faire, nous utilisons divers diagrammes de séquence.
 Diagramme de séquence
Le diagramme de séquence est un type de diagramme UML qui permet de représenter
la séquence des messages échangés entre les objets d'un système, dans un ordre
chronologique. Il se compose de plusieurs éléments clés : les objets, représentés par des
rectangles avec leur nom, les messages, représentés par des flèches indiquant le sens de la
communication et pouvant être synchrones ou asynchrones, les activations, représentées par
des barres verticales indiquant la durée pendant laquelle l'objet est actif, les fragments, utilisés
pour représenter des parties du diagramme ayant une signification particulière, et les lifelines,
représentées par des lignes verticales passant à travers les activations et indiquant la durée de
vie de l'objet. Le diagramme de séquence permet de visualiser le flux de contrôle et les
interactions entre les différentes parties du système, et peut être utilisé pour modéliser des
interactions entre les utilisateurs et une application, entre les composants logiciels, ou pour
comprendre le comportement d'un système existant.
 Authentification
Pour décrire le processus d'authentification dans le système et permettre à l'utilisateur
d'accéder aux fonctions autorisées, le diagramme de séquence suivant est utilisé. Il montre
comment le système identifie l'utilisateur en utilisant son login et mot de passe, ce qui lui
donne accès à son espace privé s'il dispose d'un profil.
  Gestion des utilisateurs
La page de gestion des utilisateurs offre à l'administrateur plusieurs fonctionnalités, telles
que la possibilité d'ajouter de nouveaux utilisateurs à la base de données et de consulter la
liste complète des utilisateurs ayant accès au compte du service d'application
Gestion de administrateur
 Ajouter administrateur

Lorsque l’administrateur clique sur le bouton d’ajout, le système affiche un formulaire

à remplir. Une fois rempli par l'administrateur, Ce dernier clique sur le bouton "ajouter", puis
le système vérifie les données et envoie la requête pour insérer le nouvel administrateur dans
la table utilisateur de la base de données. Après l'exécution de la requête, le système renvoie
le résultat à l'administrateur, qui peut voir soit l'enregistrement réussi et la liste des
administrateurs mise à jour, soit un message d'erreur en cas d'échec de stockage.
 Modifier administrateur
Cette tache décrit étape par étape le processus de modification d'un administrateur
dans le système. Tout d'abord, l'administrateur doit s'authentifier avec succès et accéder à la
liste des administrateurs. Ensuite, l'administrateur doit sélectionner l'administrateur à modifier
dans la liste. Le système affiche alors un formulaire de modification avec les champs
appropriés pour les informations de l’administrateur. Une fois que l'administrateur a saisi les
nouvelles informations, il doit cliquer sur le bouton de confirmation pour envoyer la requête
de modification au système. Le système vérifie ensuite les champs et envoie une requête à la
table utilisateur de la base de données. Après avoir exécuté la requête, le système renvoie le
résultat et affiche la liste des administrateurs modifiés pour que l'administrateur puisse vérifier
que les modifications ont été appliquées avec succès.
Gestion de propriétaire de salle de sport

 Supprimer propriétaire de salle de sport

Cette étape décrit le processus de suppression d'un propriétaire dans le système. Une fois
que l'administrateur est authentifié et a accédé à la liste des propriétaires, il doit
sélectionner le propriétaire de salle de sport qu'il souhaite supprimer. Le système affiche
alors un message de confirmation pour éviter toute suppression accidentelle. Si
l'administrateur confirme la suppression, le système envoie une demande de suppression
au système de gestion de bases de données, qui exécute la requête de suppression et
renvoie la liste des propriétaire modifiés pour confirmer que la suppression a bien été
effectuée. Si l'administrateur clique sur le bouton d’annulation, toute la demande de
suppression est ignorée et aucun propriétaire n'est supprimé
  Consulter propriétaire de salle de sport
L'administrateur a la possibilité de consulter les utilisateurs. Pour ce faire, il demande
l'interface utilisateur correspondante. Suite à cette demande, le système va traiter la requête et
afficher l'interface exacte correspondante à la demande de l'administrateur.
Gestion de sportif
 Ajouter sportif
Lorsque l'administrateur souhaite ajouter un nouvel sportif, il doit cliquer sur le bouton dédié
à cet effet. Suite à cela, le système affiche un formulaire à remplir. Une fois que
l'administrateur a complété ce formulaire, il peut cliquer sur le bouton "ajouter". À ce
moment, le système procède à la vérification des données et envoie une requête pour insérer
les informations du nouvel sportif dans la table correspondante de la base de données. Une
fois la requête exécutée, le système renvoie le résultat à l'administrateur. Ce dernier peut alors
consulter l'enregistrement réussi ainsi que la liste des sportifs mise à jour, ou un message
d'erreur en cas d'échec de stockage.
  Modifier sportif
Le processus de modification d'un sportif dans le système est constitué de plusieurs étapes
bien définies. Tout d'abord, l'administrateur doit se connecter avec succès et accéder à la liste
des sportifs. Une fois sur cette page, il doit sélectionner le sportif à modifier dans la liste. Le
système affiche alors un formulaire de modification contenant les champs appropriés pour les
informations de sportif. L'administrateur doit alors saisir les nouvelles informations dans les
champs correspondants. Une fois les modifications effectuées, l'administrateur doit cliquer sur
le bouton de confirmation pour envoyer la requête de modification au système. Le système
vérifie ensuite les champs et envoie une requête à la table utilisateur de la base de données
pour mettre à jour les informations du sportif. Après avoir exécuté la requête, le système
renvoie le résultat et affiche la liste des sportifs modifiés pour que l'administrateur puisse
vérifier que les modifications ont été appliquées avec succès.
  Supprimer sportif
La suppression d'un sportif dans le système implique plusieurs étapes. Tout d'abord,
l'administrateur doit être authentifié et accéder à la liste des sportifs. Une fois sur cette page, il
doit sélectionner le sportif qu'il souhaite supprimer. Le système affiche alors un message de
confirmation pour éviter toute suppression accidentelle. Si l'administrateur confirme la
suppression, le système envoie une demande de suppression au système de gestion de bases
de données. Ce dernier exécute ensuite la requête de suppression et renvoie la liste des
sportifs modifiés pour confirmer que la suppression a bien été effectuée. Si l'administrateur
clique sur le bouton d’annulation, toute la demande de suppression est ignorée et aucun sportif
n'est supprimé.
 3. Sprint 2
Ce paragraphe présente l'objectif du deuxième sprint selon la méthode Scrum. Après
avoir discuté avec le Product Owner, l'équipe Scrum a défini comme objectif de "finaliser la
partie de l'administrateur". Ainsi, ce sprint consistera à achever toutes les fonctionnalités
relatives à l'administration du système, tout en respectant les exigences du Product Owner et
les contraintes du projet. Pour atteindre cet objectif, l'équipe Scrum se concentrera sur les
tâches et les fonctionnalités qui contribueront à la finalisation de cette partie, en suivant le
processus itératif de Scrum pour garantir une progression rapide et efficace. À la fin du sprint,
l'équipe présentera les fonctionnalités finalisées au Product Owner afin de vérifier si les
objectifs ont été atteints.

a) Backlog de sprint 2
Après avoir établi l'objectif du sprint, il est temps de sélectionner les histoires à inclure. Ainsi,
le tableau suivant présente le Backlog de notre deuxième sprint.

ID Feature User story Priorité Story


1 Gérer compte :
-Consulter compte
-Modifier compte
2 Maintenance du site
3 Inscription
4 Gérer facture :
-Consulter facture
-Télécharger facture
b. Tableau des tâches
c. Analyse
Identification des acteurs et des cas d’utilisation
point
L’administrateur peut Haut 1
consulter les factures.
L’administrateur peut Haut 1
télécharger les factures.
En tant qu'administrateur, il
est responsable de la Haut 1
maintenance. Cela peut
inclure la mise à jour du
contenu, l'ajout de nouvelles
fonctionnalités, la résolution
de problèmes techniques et la
gestion de la sécurité du site
web.
Le propriétaire de la salle de Haut 1
sport et le sportif ont le droit
de s'inscrire sur le site web.
L’administrateur peut Haut 1
consulter les factures.
L’administrateur peut Haut 1
télécharger les factures.
-Administrateur :
Gérer compte
Maintenance du site
Gérer facture
-propriétaire de salle de sport et sportif :
Inscription

Description des cas d’utilisation : fiche de cas d’utilisation

 Gestion de compte

Consulter compte
Cas Consulter compte
Acteur Administrateur
Résumé L’administrateur peut consulter son compte.

Pré condition(s) Administrateur est authentifié

Post condition(s) Des données affichées
Scénario nominal 1. L’administrateur clique sur son compte.
2. Le système affiche un ensemble des
données.

Modifier compte

Cas Modifier compte

Acteur Administrateur
Résumé Il s'agit d'une tâche qui vise à modifier les
anciennes données.
Pré condition(s) Administrateur est authentifié
Compte affiché
Post condition(s) Les données ont été correctement modifiées
Scénario nominal 1. L’administrateur clique sur le bouton «
Modifier ».
2. Le système affiche le formulaire de
modification de ses données.
3. L’administrateur modifié u ou plusieurs
champs.
4. L’administrateur valide le remplissage.
5.Le système vérifie les données et les
ajoutées dans la base de données.
Scénario(s)alternatif
A : En cas de champ manquant,
- 4 Le système affiche un message d’erreur
- L’administrateur vérifie et valide le
remplissage.

 Maintenir de site
En tant qu'administrateur de site web, la maintenance peut inclure plusieurs tâches,
notamment :
-Mise à jour du contenu - Il est important que le contenu du site web reste à jour pour
assurer que les informations présentées aux utilisateurs sont précises et pertinentes.
-Résolution de problèmes techniques - Lorsqu'un problème technique survient sur le site
web, l'administrateur est responsable de le résoudre pour s'assurer que le site est toujours
accessible aux utilisateurs.
-Ajout de nouvelles fonctionnalités - Si le site web a besoin de nouvelles fonctionnalités
pour améliorer l'expérience utilisateur, l'administrateur peut travailler avec l'équipe de
développement pour les ajouter.
-Gestion de la sécurité - L'administrateur peut mettre en place des mesures de sécurité
pour protéger le site web contre les cyberattaques et surveiller les activités suspectes.
-Optimisation de la vitesse de chargement - L'administrateur peut optimiser la vitesse de
chargement du site web pour garantir une expérience utilisateur rapide et fluide.
-Surveillance de la disponibilité du site web - L'administrateur doit surveiller la
disponibilité du site web et réagir rapidement en cas d'indisponibilité ou de panne du site.
En fin de compte, l'administrateur est responsable de s'assurer que le site web est à jour,
fonctionnel, sécurisé et répond aux besoins des utilisateurs.
 Gestion des factures
 Consulter facture

Cas Consulter facture

Acteur Administrateur
Résumé L’administrateur a le droit de consulter la liste
des factures.
Pré condition(s) - L’administrateur est authentifié.
-Les factures déjà trouvé.
Post condition(s) Liste des factures est affichée.

Scénario nominal 1. L’administrateur clique sur le bouton des

factures.
2. Le système affiche la liste des factures
choisit.

 Télécharger facture
Cas Télécharger facture
Acteur Administrateur
Résumé Cette fonctionnalité permet à
l’administrateur de télécharger la facture
après le paiement de sportif
Pré condition(s) - L’administrateur est authentifié.
-l’administrateur consulter la facture
Post condition(s) Le téléchargement des factures se fait avec
succès
Scénario nominal 1. L’administrateur clique sur le bouton de
téléchargement après avoir choisir la facture
exacte.
2. Le système affiche un message de
confirmation.
3.L'administrateur confirme sa décision.
4.Le système fait le téléchargement.

 Inscription
Pour bénéficier de toutes les fonctionnalités offertes par le site, le sportif et le propriétaire
de salle de sport doivent s'inscrire en remplissant un formulaire d'inscription. Le cas
d'utilisation « s'inscrire » peut être décrit en détail dans un tableau, comme suit :
Cas S’inscrire
Acteur Sportif / Propriétaire de salle de sport
Résumé Le sportif / Propriétaire de salle de sport
doit remplir un formulaire d'inscription
pour accéder à toutes les fonctionnalités du
site.
Pré condition(s) Le sportif / Propriétaire de salle de sport
doit avoir accès à internet et à un navigateur
web.
Post condition(s) Le sportif / Propriétaire de salle de sport est
enregistré sur le site et peut accéder à toutes
les fonctionnalités.

Scénario nominal -Le sportif / Propriétaire de salle de sport

accède à la page d'inscription.
-Le sportif / Propriétaire de salle de sport
remplit le formulaire d'inscription avec ses
informations personnelles (nom, prénom,
adresse email, mot de passe, etc.).
-Le sportif / Propriétaire de salle de sport
soumet le formulaire d'inscription.
-Le système vérifie la validité des
informations fournies et enregistre
l'utilisateur sur la base de données.
-Le système affiche un message de
confirmation indiquant que l'inscription a
été réussie.

Scénario(s)alternatif
A : Si une information obligatoire est
manquante ou invalide :
- 3 le système affiche un message d'erreur et
demande à l'utilisateur de corriger les
informations saisies.
B Si l'adresse email fournie est déjà utilisée
pour un autre compte :
4-le système affiche un message d'erreur
demandant à l'utilisateur d'en choisir une
autre.
 d. Conception
Cette partie commence par aborder la conception statique des différents cas d'utilisation qui
ont été détaillés dans la section précédente.
 Conception statique du sprint

 Digramme de classe

Champs Type Contraintes

Id Int PRIMERY KEY
Email TEXT UNIQUE
 Nom TEXT
Adresse TEXT
Numéro du téléphone TEXT
Sexe TEXT
Date de naissance TEXT
Photo TEXT
Mot de passe TEXT
Type TEXT

Champs Type Contraintes

Email TEXT UNIQUE
Nom TEXT
Adresse TEXT
Numéro du téléphone TEXT
Sexe TEXT
Date de naissance TEXT
Photo TEXT
Mot de passe TEXT

Champs Type Contraintes

Id Int PRIMERY KEY

 Diagramme de séquence
Une fois les cas d'utilisation décrits de manière textuelle, il est possible de les
représenter à l'aide de diagrammes de séquence. Ces diagrammes permettent de visualiser la
chronologie des interactions entre les acteurs et le système, cela permet également de
comprendre le sens et l'importance de ces interactions.

 Gestion compte

Consulter compte

Lorsqu'un administrateur s'authentifie, il peut consulter son compte en exécutant une

demande qui affichera les informations correspondantes.
Modifier compte

Le processus de modification des données d’administrateur est initié lorsque

l'administrateur en fait la demande. Pour ce faire, il doit cliquer sur son compte. Une fois
cela fait, le système affiche un formulaire déjà rempli avec leurs informations.
L'administrateur peut alors effectuer les modifications nécessaires sur les champs
correspondants. Une fois que les modifications sont terminées, le système envoie une
requête de modification à la base de données pour enregistrer les changements effectués.
Une fois que le système a reçu la liste modifiée de la base de données, il l'affiche
automatiquement à l'administrateur pour confirmer que la modification a été effectuée
avec succès.
  Gestion facture

Consulter facture

Afin de clarifier cette fonctionnalité, nous allons nous pencher sur le cas d'utilisation
"consulter facture". Le diagramme fournit un aperçu des différentes étapes nécessaires à cette
opération. Une fois l'authentification effectuée, l'administrateur demande l'affichage de la liste
des factures en envoyant une requête au système de gestion de base de données, qui répond en
conséquence.
 Télécharger facture

Cette étape concerne le processus de téléchargement d'une facture. Après que l'administrateur
s'est authentifié et a accédé à la liste des factures, il doit sélectionner celle qu'il souhaite
télécharger. Le système affiche ensuite un message de confirmation. Si l'administrateur
confirme le téléchargement, le système envoie une demande qui s'exécute et permet de
télécharger la facture. Si l'administrateur annule la demande en cliquant sur le bouton prévu à
cet effet, le processus de téléchargement est alors interrompu.
 Inscription
 Le diagramme de séquence ci-dessous décrit les étapes du processus d'inscription pour
les sportifs et les propriétaires de salle de sport. Lorsque l'utilisateur clique sur le bouton
"Inscrire", le système affiche un formulaire d'inscription. L'utilisateur remplit le
formulaire et clique sur le bouton "Enregistrer". Le système vérifie les données et envoie
une requête d'insertion pour ajouter un nouvel utilisateur à la table d'utilisateurs dans la
base de données. Le SGBD exécute la requête et renvoie le résultat. Si l'enregistrement est
réussi, la page privée de l'utilisateur est affichée. Sinon, le système affiche à nouveau la
page d'inscription avec un message d'erreur

Conclusion :

Le résultat final d'une release est le produit livrable qui est remis au client. Contrairement au
résultat d'un sprint, qui peut être considéré comme un produit potentiellement livrable, une
release doit être un produit totalement fonctionnel et prêt pour une utilisation en production. À
la fin de ce chapitre, nous avons réussi à produire un produit incrémental qui offre une valeur
suffisante aux clients et peut être utilisé en production. Dans le prochain chapitre, nous nous
concentrerons sur la création d'une nouvelle release pour améliorer davantage le produit et
répondre aux besoins changeants des clients.