RÉPUBLIQUE TUNISIENNE UNIVERSITÉ DE SFAX

FACULTÉ DES SCIENCES DE SFAX

***********
MINISTÈRE DE L'ENSEIGNEMENT ***********
SUPÉRIEUR ET DE LA DÉPARTEMENT D’INFORMATIQUE
RECHERCHE SCIENTIFIQUE ET DES COMMUNICATIONS

MÉMOIRE DE FIN D’ETUDES

Présenté à

La Faculté des Sciences de Sfax

En vue de l’obtention du

DIPLÔME DE LICENCE EN
INGÉNIERIE DES SYSTÈMES INFORMATIQUES
Par

Yasser Rahmani

« Conception/développement d'une plateforme web »

pour la société AHSL Gabes

Soutenu le 06 juin 2023, devant le jury composé de :

M. Hedi TMAR Président

M. Zied WARDA Examinateur

Mme. Faten BEN ALI Encadrante Académique

M. Mohsen CHAABEN Encadrant Industriel

Stage réaliser à « AHSL »

Année Universitaire : 2022/2023 Code :LISI-IRS
 Dédicaces
A Dieu
Qui m’a donné la force, la santé et la patience d’accomplir ce travail. Je dédie le fruit de mes 16
ans d’études.

A mes très chers parents

Aucun mot si sacré soit-il, ne suffira à apprécier à sa juste valeur, le soutien matériel et
spirituel, les sacrifices que vous ne m’avez cessé de déployer.
Je vous offre en guise de reconnaissance, ce modeste travail en vous souhaitant santé,
bonheur et longue vie qu’on puisse combler à nous tour.

A mes très chers frères

Je vous dédie ce travail en témoignage des liens solides et intimes qui nous unissent et pour
votre soutiens, encouragements en vous souhaitant un avenir
rempli de succès et joie.

A ma chère famille

Que ma grande famille aussi trouve ici mes vifs remerciements pour son soutien et son aide
durant toute ma cursus et surtout durant les moments difficiles.
 Remerciements
C’est avec un grand plaisir que je réserve ces lignes en signe de gratitude et de reconnaissance à
tous ceux qui ont contribué de près ou de loin à l’élaboration de ce travail.

Je tiens à exprimer mes remerciements les plus vifs à Mr, CHAABEN Mohsen pour m’avoir
accepté et suivi tout le long de l’avancement de mon travail.

J’adresse mes profondes reconnaissances à Mme. ALYA Hazar, la fondatrice de AHSL, qui
m’a accepté pour passer mon projet de fin d’étude au sein de son organisme.

Je tiens à exprimer ma sincère gratitude envers mon encadrante Mme. BEN ALI Faten, pour
m’avoir incité à mener à bien ce travail, pour son aide, ses efforts pour m’intégrer dans
l’environnement, son dévouement et ses précieux conseils.

Par ailleurs, je remercie les membres de jury d’avoir accepté de juger mon travail tout en
espérant qu’ils trouvent dans ce rapport les qualités de clarté et de motivation qu’ils attendent.
 Sommaire
Dédicaces.....................................................................................................................................................i
Remerciements ...........................................................................................................................................ii
Sommaire.................................................................................................................................................. iii
Liste des tableaux ......................................................................................................................................v
Liste des figures........................................................................................................................................ vi
Introduction Générale ........................................................................................................................... 1
Chapitre 1 : Présentation du cadre de projet....................................................................................... 2
1. Introduction............................................................................................................................................2
2. Présentation de l’entreprise....................................................................................................................2
3. Contexte général du projet ....................................................................................................................3
4. Les Problématiques traitées ..................................................................................................................3
5. Solution proposée..................................................................................................................................3
6. Méthodologie de travail ........................................................................................................................4
7. Conclusion ............................................................................................................................................7
Chapitre 2 : Planification du projet...................................................................................................... 8
1. Introduction............................................................................................................................................8
2. Constitution de l’équipe SCRUM et rôle...............................................................................................8
3. Identification des acteurs.......................................................................................................................9
4. Backlog du produit.................................................................................................................................9
5. Planification des Releases......................................................................................................................12
6. Conclusion.............................................................................................................................................12
Chapitre 3 : Release 1............................................................................................................................. 13
1. Introduction...........................................................................................................................................13
2. Organisation des Sprints........................................................................................................................13
3. Sprint 1 : Intégration de l’interface du site, inscription et authentification ..........................................13
4. Sprint 2 : Gestion des admins ...............................................................................................................13
4.1. Sprint Goal......................................................................................................................................... 13
4.2. Sprint Backlog .................................................................................................................................. 13
4.3 . Analyse des besoins.......................................................................................................................... 14
4.4 . Conception .............................................................................................................................…….. 18
4.5. Réalisation .................................................................................................................................. …..23
5. Conclusion ............................................................................................................................................26
Chapitre 4 : Release 2............................................................................................................................. 27
1. Introduction............................................................................................................................................27
2. Organisation de sprint 3 ........................................................................................................................27
3. Sprint Goal ............................................................................................................................................27
4. Sprint Backlog.......................................................................................................................................27
5. Analyse des besoins...............................................................................................................................28
5.1. Les besoins fonctionnels.....................................................................................................................28
5.2. Diagramme de cas d’utilisation du sprint 3........................................................................................29
5.3. Conception......................................................................................................................................... 34
5.4. Réalisation ......................................................................................................................................... 41
6. Conclusion ............................................................................................................................................44
Chapitre 5 : Release 3..............................................................................................................................45
1. Introduction............................................................................................................................................45
2. Sprints goal............................................................................................................................................45
3. Sprint Backlog ......................................................................................................................................45
4. Analyse des besoins ..............................................................................................................................45
4.1. Les besoins fonctionnels ....................................................................................................................45
4.2. Diagramme de cas d’utilisation .........................................................................................................46
5. Conception............................................................................................................................................ 48
6. Realisation............................................................................................................................................. 48
7. Conclusion.............................................................................................................................................49
6. Conclusion Générale ...........................................................................................................................50

Liste des Figures

Figure 1 : Logo de Société AHSL .............................................................................................................2
Figure 2 : Cycle en V ................................................................................................................................4
Figure 3 : Statistiques sur l’utilisation des méthodes agiles......................................................................5
Figure 4 : Cycle de vie de Scrum ………………………………………………...…………...…………6
Figure 5 : Logo Draw.io…………………………………………………………….…………..………15
Figure 6 : Diagramme de cas d’utilisation du sprint 2 ……………………….…………….……...…...16
Figure 7 : Diagramme de classe du sprint 2 ……………………………………….……….…..………19
Figure 8 : Diagramme de séquence Authentification ………………………………..…………………20
Figure 9 : Diagramme de séquence Consulter un admin………………..…………..……………..……21
Figure 10 : Diagramme de séquence Ajout un administrateur…………………..………..……….……22
Figure 11 : Diagramme de séquence Supression un administrateur……………..…………..…..……...23
Figure 12 : Logo Visual Studio Code ……………………………………………..…………………...24
Figure 13 : Logo XAAMP …………………………………………………………..………….………25
Figure 14 : Page authentification pour les administrateurs ……………………………..………………25
Figure 15 : Interface récupération mot de passe…………..…………………………..………………...26
Figure 16 : Interface administrateur…………...…………..…………………………..………………...26
Figure 17 : Liste des administrateurs………….…………..……………………..……………………...27
Figure 18 : Page ajout administrateurs …………………………………………..……………………...27
Figure 19 : Diagramme de cas d’utilisation du sprint 3………………………..…………………...…...31
Figure 20 : Diagramme de classe du sprint 3…………………………………..………………..………36
Figure 21 : Diagramme de séquence Consulter les services……………………..……………...………37
Figure 22 : Diagramme de séquence Ajout des services………………………..………………………38
Figure 23 : Diagramme de séquence modification des services …………………..……………………39
Figure 24 : Diagramme de séquence suppression des services ……………………..…………..………40
Figure 25 : Diagramme de séquence Ajout une réservation …………………………..……………..…41
Figure 26 : Diagramme de séquence suppression une réservation …………………..………..………42
Figure 27 : Interface des services pour les administrateurs …………………………...………...……...43
Figure 28 : Ajout d’un service …………………………………………………………………......……44
Figure 29 : Modification d’un service …………………………………………………………...…...…44
Figure 30 : Liste des réservations …………...………………………………………………...……...…45
Figure 31 : Ajout d’une réservation ………………………………………………………………..……45
Figure 32 : Erreur d’ajout d’une réservation …………………………………………………….....……45
Figure 33 : Modification d’une réservation …...…………………………………………….…………46
Figure 34 : Diagramme de cas d’utilisation du sprint 4…………………………………….……………48
Figure 35 : Diagramme de classe du sprint 4……………………………………………………….……50
Figure 36 : Consultation des questions……………………………………..……………………....……50

Figure 37 : L’ajout d’une question………….………………………………………………..…….…….51

Figure 38 : Erreur d’ajout…………………..……………………………...……………………….……51

Liste des tableaux

Tableau 1 : Tableau comparatif entre Cycle en V et Scrum .....................................................................7
Tableau 2 : Tableau de l’équipe Scrum .....................................................................................................9
Tableau 3 : Tableau de Backlog du produit ..............................................................................................11
Tableau 4 : Tableau de Planification des releases ………………………………………………………12
Tableau 5 : Tableau de Sprint Backlog de Sprint 2 ………………………………………….………….14
Tableau 6 : Tableau de description textuelle de <authentification> ……………………….……………16
Tableau 7 : Tableau de description textuelle de <ajouter un admin> ………………..……….…………17
Tableau 8 : Tableau de description textuelle de <supprimer un admin> ………………..………………18
Tableau 9 : Tableau de description textuelle de <consulter la liste des admins> …………..…..……….18
Tableau 10 : Tableau des caractéristiques de PC portable ………………………………………………24
Tableau 11 : Tableau de Sprint Backlog de Sprint 3…………………………….……………..………..30
Tableau 12 : Tableau de description textuelle de <consulter les services> ………………..……………32
Tableau 13 : Tableau de description textuelle de <ajouter un service>…..………………...……………32
Tableau 14 : Tableau de description textuelle de <Supprimer un service> ……..………………………33
Tableau 15 : Tableau de description textuelle de <Modifier un service> ………………………………33
Tableau 16 : Tableau de description textuelle de <consulter les réservations> ………...………………34
Tableau 17 : Tableau de description textuelle de <ajouter une réservation> ……………...……………34
Tableau 18 : Tableau de description textuelle de <Confirmer une réservation> ………….……………35
Tableau 19 : Tableau de description textuelle de <Supprimer une réservation> ………….……………35
Tableau 20 : Tableau de description textuelle de <Modifier une réservation> …………………………36
Tableau 21 : Tableau de Sprint Backlog de Sprint 4 ………………………………………...………….47
Tableau 22 : Tableau de description textuelle de <consulter les messages> ……………………………48

Tableau 23 : Tableau de description textuelle de <ajouter un message> ……………………………….49

Tableau 24 Tableau de description textuelle de <Supprimer un message> …………….……………….49

 Introduction Générale
Au début des années 1990, après l'apparition des premiers sites Internet grand public, le monde de
l'entreprise s'est rendu compte que ces relations avec les clients, leur permettant de découvrir de
nouvelles façons de naviguer, comparer, réserver et acheter en un seul clic, étaient des classiques. Ainsi,
le prochain saut et l'évolution commencent à déplacer les transactions vers la voie virtuelle d'Internet.
Transactions en face à face, via la virtualisation, via les biens et services, car cela nous oblige à accorder
plus d'attention à la virtualisation. Au fil des ans, il a été largement recommandé en fonction des ventes
de produits et de services. Ces types de sites offrent aux clients du monde entier des passerelles vers
toutes les informations, produits et services dans le monde à partir d'un portail en ligne unique lié aux
activités de l'entreprise.
Notre challenge était donc de concevoir et développer un site web pour l'entreprise AHSL avec suivi des
réservations et en utilisant les Framework PHP, HTML, JAVASCRIPT, CSS.
Notre projet a été effectué au sein de la société "AHSL" en vue de l’obtention du diplôme de Licence en
Ingénierie des Systèmes Informatique à la Faculté des Sciences de Sfax (FSS).
Le présent rapport s'étale sur quatre chapitres :
Dans le premier chapitre, nous présentons le cadre général du projet : présentation de l’entreprise
d’accueil et du contexte général du projet suivi par les problématiques traitées et la solution proposée et
les méthodologies de travail.
Chapitre 2 intitulé « Planification du projet » sert à présenter l’équipe SCRUM puis l’identification
des acteurs. Ensuite nous élaborons le Backlog du produit et nous finirons par la planification des
releases.
Les trois derniers chapitres « Release 1 », « Release 2 » et « Release 3 » constituent le corps de notre
rapport. Ces trois chapitres seront consacrés pour le développement de notre système en respectant les
principes fondamentaux de SCRUM.
Enfin, nous clôturons notre rapport par une conclusion générale qui résume l’ensemble de nos travaux et
qui leur ouvre des perspectives.

Page 1
 Chapitre 1 : Présentation du cadre de projet

1. Introduction
Dans ce chapitre introductif, nous citons le projet dans son cadre général. Pour ce faire, nous procédons
à la présentation de l’entreprise d’accueil, la méthodologie de travail et le contexte général du projet
suivi par les problématiques traitées et les solutions proposées.

2. Présentation de l’entreprise

Figure 1: Logo de AHSL

Awtar Hazar Sound & Lighting en Tunisie est une société spécialisée dans l'organisation d'événements
et de spectacles en direct : sonorisation, lumière, structure, scènes, écran led géant... Elle offre des
produits de haute qualité et des services professionnels aux clients. Elle utilise la nouvelle technologie
bien exploitée et mise en service pour le client. Dés l'étude à la réalisation. Elle a la charge de :

 L’analyse des besoins des clients.

 Le choix de solution technique de développement de l’application.
 Le développement de toutes les fonctionnalités techniques.
 Le respect des bonnes pratiques de codage.
 Les tests et la validation des fonctionnalités développées.

Page 2
Grâce à une expertise technique, AHSL offre à ses clients une solution adaptée à leurs besoins dans
différents secteurs d’activités, même elle garantit également un service de support de qualité toute
demandes.

3. Contexte général du projet

Durant le deuxième semestre de l’année 3éme LISI au sein de la Faculté des Sciences de Sfax . Ce projet
est réalisé au sein de la société AHSL dans le cadre du stage de fin d’étude durant la période du 01
Février 2023 aux 29 avril 2023, il m’a été confié la conception et le développement d’un site web pour
valoriser et publier les évènements réalisés par la société avec suivi des réservations.

4. Les Problématiques traitées

Aujourd'hui, la plupart des sociétés s'adaptent progressivement aux transactions via les réseaux sociaux,
qu'ils utilisent pour augmenter leurs publicités et promouvoir leur présence sur les marchés locaux de
leur région.

Pour les grandes entreprises disposant de leurs propres plateformes, celles-ci leur permettent de
construire des relations plus interactives avec les clients. C'est ce qui les incite à réserver sur les sites
Web de ces entreprises.

En raison du rythme de vie accéléré, les clients n'ont pas le temps ni la possibilité de se déplacer pour
faire des réservations, même si on utilise l’E-mail. Certains Courriers sont considère comme Spam car le
client ne spécifié pas l’objet.

5. Solution proposée
Pour pallier ces problèmes, nous proposons de concevoir et d'implémenter un site web qui regroupe tous
les services de l’entreprise, donc notre solution permet de/d’:
 Eviter les coûts engendrés par le déplacement
 Eviter la perte du temps
 Faciliter l'utilisation.
 Fonctionnalités nécessaires pour une réservation pour évènement.

Page 3
6. Méthodologie de travail
L'une des suggestions pour obtenir un logiciel satisfaisant est de suivre des méthodes de développement
efficaces. Les méthodes agiles prennent en compte tous les aspects d'un projet informatique et de son
cycle de vie. Il existe plusieurs méthodes agiles et classiques déjà en place :

 Exemples de méthodes classiques : Cycle en V, en cascade…

 Exemples de méthodes agiles : Scrum, XP processus unifié…

6.1 Cycle en V

La première méthode largement utilisée dans le monde est la méthode du « Cycle en V», qui est une
méthode d'organisation de projet conçue pour limiter les problèmes et permettre un retour limité aux
étapes précédentes en cas d'exception. Il est sous forme d'un V dont la première étape contient les étapes
de la conception du projet, et la deuxième étape contient les tests du projet. La pointe du V représente la
phase de mise en œuvre du projet et chaque étape est liée à l'étape précédente. La figure 2 montre le
principe de base du « Cycle en V » [1]

Figure 2 : Cycle en V

Page 4
6.2 Scrum

Scrum est une méthode de gestion de projet agile : des cadences itératives, des rôles et réunions
spécifiques et limités dans le temps, des artefacts (Product Backlog, Sprint Backlog et Schedule) et les
règles du jeu. C'est ce qui est de plus en plus utilisé dans le monde des "méthodes" agiles. Il existe
d'autres méthodologies agiles telles que "SCRUM/XP Hybrid", "CUSTOM Hybrid", etc., mais Scrum
est la plus couramment utilisée (figure 3). Scrum définit trois rôles [2] :

o Le Product Owner [3] : porte la vision du produit à réaliser. Son travail est en interaction avec
l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet.

o L’Équipe de Développement [3] : chargée de transformer les besoins exprimés par le Product
Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler plusieurs
compétences tels que le graphiste, l’architecte web, l’intégrateur, etc.

o Le Scrum Master [3]: qui doit maîtriser la conduite du cadre de processus Scrum et de s’assurer
qu’il est correctement appliqué. Il a donc un rôle de coach entre le Product Owner et l’équipe de
développement

Figure 3: Statistiques sur l’utilisation des méthodes agiles

Les étapes du cadre de processus Scrum sont :

Page 5
 La première étape consiste à définir la vision du produit à réaliser. La vision décrit ensuite les
principaux objectifs, les jalons et le public ciblé.

La deuxième étape consiste à établir toutes les exigences fonctionnelles et non fonctionnelles du produit.
L'équipe de développement estime ensuite chaque exigence à l'aide de la technologie Planning Poker.

Ensuite, convertissez les exigences en fonctions utilisables. Le principe est de convertir d'abord les
besoins qui apportent la plus grande valeur ajoutée au parrain.

Par conséquent, prioriser les exigences fonctionnelles à plus forte valeur ajoutée est un problème. Cette
liste est appelée Product Backlog.

Figure 4 : Cycle de vie de SCRUM

6.3 Tableau comparatif

Page 6
On présente ci-dessous un tableau comparatif (Tableau 1) qui présente selon un ensemble des critères, la
différence entre Cycle en V et SCRUM.

Tableau 1 : Tableau comparatif entre Cycle en V et Scrum

Critères Scrum Cycle en V

Cycle de vie Processus Phase séquentielles

Planification Au début de chaque sprint Au début du projet

Contrôle Qualité Fin de chaque sprint Fin du cycle de développement

Equipe Scrum master / Chef de projet/

Product owner (PO) / Maîtrise d'ouvrage (MOA)/
Equipe de développement Maîtrise d'œuvre (MOE)
(Dev)

6.4 Le choix de la méthodologie

L’une des recommandations permettant d’aboutir à un logiciel satisfaisant est de suivre une
méthodologie de développement efficace. Les méthodes Agiles prennent en compte tous les aspects d’un
projet informatique ainsi que son cycle de vie. Nous conduirons donc notre projet selon l’Agile et
précisément en nous conformant au cadre de processus Scrum.

7. Conclusion
Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil AHSL, sa structure sociale et ses
principales activités et compétences. Par ailleurs, nous avons dégagé la méthodologie de travail et du
développement de notre projet. À la fin, nous avons présenté le contexte général du projet et la
problématique pour énoncer la solution proposée.

Chapitre 2 : Planification du projet

1. Introduction
Page 7
Dans ce chapitre, nous commencerons par présenter notre équipe SCRUM. Nous engagerons par la
suite, l’expression des besoins fonctionnels et non fonctionnels avec une identification des acteurs de
notre solution. Par la suite, nous élaborons le Backlog du produit et nous planifierons les releases.
Pour conclure, nous présenterons notre identification de l’architecture de l’application et la présentation
de l’environnement matériel.

2. Constitution de l’équipe SCRUM et rôle

Avant toute application du cadre de processus SCRUM, il y a lieu de constituer notre équipe, celle-ci est
dressée dans le tableau (tableau 2) :
Une équipe SCRUM est constitué par
Product Owner (PO) :
 1 PO par équipe
 Il est responsable de maximiser la valeur du produit résultant du travail de l’équipe de
développement
 Le PO est le seul responsable de la gestion du Backlog Produit (Product Backlog)
Scrum Master (SM) :
 Scrum Master est expert du cadre méthodologique SCRUM
 Il a pour responsabilité essentielle d’aider l’équipe à appliquer Scrum et à l’adapter au
contexte.
 Il a une grande influence sur la façon de travailler, sur le processus, comme le Product Owner
en a une sur le produit.
 Il guide l’équipe pour mener les développements produit vers le succès.
Équipe de Développement (Dev) :
 Dans Scrum, l’équipe s’organise elle-même et doit avoir toutes les compétences nécessaires au
développement du produit.
 Une équipe Scrum est pluridisciplinaire (Architecte, concepteur, développeur, testeur, )
 Une équipe Scrum est auto-organisée.
Tableau 2 : Tableau de l’équipe Scrum

Page 8
 Product Owner Mohsen Chaaben Encadrant professionnel

Scrum Master Faten Ben Ali Encadrant académique

Equipe de Yasser Rahmani 3éme année Licence en

Développement Ingénierie des Systèmes
Informatique

3. Identification des acteurs

Dans cette partie, nous allons fixer les acteurs clés et les rôles-métiers qu’ils jouent dans notre système.
Un acteur est une entité extérieure au système de modélisation qui interagit directement avec lui, ou au
mieux, un administrateurou master administrateur du système. Un acteur peut être une personne ou un
autre système informatique qui souhaite accéder à un ou plusieurs services fournis par l'interface. Il
interagit avec le système en envoyant ou en recevant des messages. Par ailleurs, notre application va
intervenir les différents acteurs suivants :
 Master Administrateur : C’est le responsable de tous les processus du site (gestion de service,
gestion des réservations, , gestion admin. )
 Administrateur : C’est le deuxième responsable des processus du site (gestion de service,
gestion des réservations)
 Client : C’est le responsable du suivi des services, faire les réservations, poser des questions.

4. Backlog du produit
Le backlog du produit est une liste d’éléments ou de fonctionnalités nécessaires pour atteindre les
objectifs ou définir les attentes au sein d’une équipe, le tout classé par ordre de priorité. Elle permet à
ses membres de suivre leurs tâches. Chaque produit développé a généralement un seul backlog produit,
lui-même attribué à une équipe [4].
Notre Backlog du produit, présenté dans le tableau (tableau 3), est constitué de User Story. Chaque User
Story est caractérisé par les champs suivants :

Page 9
  Id Story : c’est un nombre unique et auto-incrémenté pour chaque story.

 User Story : C’est le résumé du user story.

 Description : Une description d’un User Story.

 Complexité : La complexité est évaluée entre faible, moyenne et élevé,

selon le niveau de complexité

 Priorité : Par rapport au client représentée suivant la méthode "MoSCoW", qui est une
technique possédant un objectif qui s'articule autour d'un accord entre le maître d’œuvre
et le maître d'ouvrage sur l’importance des tâches que nous allons réaliser par rapport aux
délais prévus. MoSCoW a pour signification (le o ne représente rien c’est juste pour
rendre le mot prononçable) :

 M (Must have) : doit être fait (vital).

 S (Should have) : devrait être fait dans la mesure du possible(essentiel).
 C (Could have) : pourrait être fait dans la mesure où cela n'a pas d'impact sur
les autres tâches (confort).
 W (Won ‘t have) : ne sera pas fait cette fois mais sera fait plus tard (c’est la
zone d'optimisation budgétaire). [5]

Page 10
Dans le tableau ci-dessous nous présentons Product Backlog de notre projet :

Tableau 3: Tableau de Backlog du produit

Id User Story Description Complexité Priorité Sprint

Story

Intégration de En tant qu’administrateur je dois

l’interface pouvoir l’accès à l’interface
1 Faible Must
Dashboard admin
admin
1
2 Authentification En tant qu’administrateur je dois
m’authentifier Moyenne Must

3 Gestion des En tant que master admin, je peux

admins consulter, ajouter, modifier et Moyenne Must 2
supprimer un Admin

Gestion des En tant que master admin/admin,

services je peux ajouter, modifier,
4 supprimer et consulter un service Moyenne Must

3
En tant qu’admin/ master admin,
je peux consulter les réservations
Gestion des
5 En tant que client je peux faire Moyenne Must
Réservations
une réservation, annuler ou
confirmer une réservation

En tant que admin/ master admin,

je peux consulter et supprimer des
Gestion des
6 questions, Moyenne Must 4
questions
En tant que Client/Visiteur je
peux poser les questions

Page 11
 5. Planification des Releases
Une fois le bocklog du produit est terminé et ordonnancé, nous établissons, lors de la réunion de
planification des sprints, l’estimation de la durée nécessaire de chaque sprint.

Le tableau suivant montre la planification des releases :

Tableau 4: Tableau de Planification des releases

Release Sprint Date début Date fin

1 Sprint 1 25/02/2023 24/03/2023

Sprint 2

2 Sprint 3 27/03/2023 21/04/2023

3 Sprint 4 22/04/2023 13/05/2023

6. Conclusion
Au terme de ce chapitre, nous commençons par présenter la constitution de notre équipe SCRUM. Nous
avons consacré la deuxième section pour définir l’identification des acteurs, après nous avons présenté
le backlog de produit et enfin la planification des releases. Dans le chapitre suivant nous entamerons le
développement du premier release.

Page 12
 Chapitre 3 : Release 1

1. Introduction
Les étapes de hiérarchisation du backlog produit montrent l'intérêt de commencer avec l’intégration de
l’interface du site et la gestion des admins. Ce chapitre constitue le document de concept et de mise en
œuvre pour les deux premiers Sprints du projet. Par conséquent, son objectif est de fournir un produit
livrable et testé qui sera déployé dans le sprint final.

2. Organisation des Sprints

 Sprint 1 :
 Intégration de l’interface du site.
 Authentification
 Sprint 2 :
 Gestion des admins

3. Sprint 1 : Intégration de l’interface du site et authentification

Lors de ce Sprint, nous devons préparer notre environnement de travail (installation et configuration),
assimiler les concepts de base qui nous permettent de réaliser la mise en place du système et la
préparation des interfaces nécessaires. Puisque l’authentification est une fonctionnalité sur lesquelles se
base la gestion des admins ce sprint va être représenté avec le sprint 2.

4. Sprint 2 : Gestion des admins

4.1. Sprint Goal 1

L'objectif de ce sprint est d'implémenter toutes les fonctionnalités permettant aux admins (admin) de
gérer les comptes.

4.2. Sprint Backlog

Page 13
 Dans ce tableau nous rappelons les users story qui s’imposent pour la réalisation de la Gestion des
admins.

Tableau 5 : Tableau de Sprint Backlog de Sprint 2

Release Sprint User Story Taches Complexité Prior

ité

1 Authentification En tant que master

administrateur je dois Moyenne Must
m’authentifier

Ajouter un admin En tant que master admin,

je peux ajouter un admin Moyenne Must

1 2 Supprimer un En tant que master admin,

admin je peux supprimer un admin Moyenne Must

Consulter les En tant que master admin,

admins je peux consulter les admins Moyenne Must

4.3. Analyse des besoins

Notre système doit non seulement répondre aux exigences fonctionnelles de tous les admins, mais
également à certaines exigences non fonctionnelles. Ces exigences sont divisées en exigences
fonctionnelles et exigences non fonctionnelles, comme suit :
4.3.1 Les besoins fonctionnels
Notre site web va permettre à l'administrateur de faciliter toutes transactions avec les clients.
 Affichage de la liste des admins : l’administrateur peut consulter la liste des admins qui contient leurs
détails (id de l’admin, nom et prénom, date de naissance, numéro de téléphone, adresse mail, rôle).
 Ajout d’un administrateur : l’administrateur peut ajouter un administrateur avec un formulaire
contient les champs concernant les détails du l’admin.

Page 14
 Modification d’un administrateur : le système affiche à l’administrateur un formulaire pour modifier
les détails de cet administrateur
 Suppression d’un administrateur : Après la consultation de la liste des admins, l’administrateur peut
choisir un administrateur pour supprimer.
4.3.2 Les besoins non-fonctionnels
Ce sont les exigences pour les caractéristiques du système. Il s'agit des exigences de performance, du
type de matériel ou du type de conception. Ces exigences peuvent être liées à des contraintes
d'implémentation (langage de programmation, type de SGBD, système d'exploitation, etc.) [6].
 L’ergonomie : Toute interface de notre application doit être convivial et facile à comprendre et à
exploiter par l’admin.
 La portabilité : Le site doit être capable de fonctionner dans un environnement matériel différent de
son environnement initial.
 Sécurité : Notre site devra assurer la sécurité des admins, d’où la nécessité de procéder à
l’authentification des admins tout en assurant la confidentialité de leurs données.
4.3.3. Outil de modélisation et de conception
Draw.io est une application gratuite en ligne, accessible via son navigateur (protocole https) qui permet
de dessiner des diagrammes ou des organigrammes. Cet outil vous propose de concevoir toutes sortes de
diagrammes, de dessins vectoriels, de les enregistrer au format XML puis de les exporter. [7]

Figure 5 : Logo Draw.io

4.3.4. Diagramme de cas d’utilisation du sprint 2

Les diagrammes de cas d'utilisation modélisent le comportement d'un système et permettent de capturer
les exigences du système. Les diagrammes de cas d'utilisation décrivent les fonctions générales et la
portée d'un système. [8]

Page 15
 Figure 6 : Diagramme de cas d’utilisation du sprint 2

Description textuelle de « Authentification » :

Tableau 6 : Tableau de description textuelle de « Authentification »

Administrateur
Acteurs
Les admins doivent ouvrir le site web
Pré condition
Authentification
Post condition
1. L’administrateur clique sur le bouton « Connexion ».
Scénario nominal
2. Un formulaire de connexion s’affiche.
3. L’administrateur doit remplir le formulaire de connexion (E-mail et Mot de
passe)
4.puis l’administrateur clique sur « Connexion ».
5. L’administrateur sera dirigé vers la page d’accueil.

Scénario Erreur 1 : Champs obligatoire vides

Page 16
alternatif  Le système affiche un message d’erreur.
 Le processus reprend à l’étape 3.
Erreur2 : L’e-mail ou mot de passe ne correspond au celles qui sont
sauvegardées dans la base de données.
 Le système affiche un message d’erreur.
 Le processus reprend à l’étape 3.

Description textuelle de « Ajouter un administrateur »

Tableau 7 : Tableau de description textuelle de « Ajouter un administrateur »

Acteurs Master Admin

Pré condition Authentification préalable

Post condition Ajout d’un admin

Scénario 1.Le Master administrateur clique sur bouton Ajouter administrateur

nominal 2. le master administrateur remplit le formulaire puis clique sur « Enregistre ».
3.le système affiche un message de succès
4.le système affiche nouvelle liste des admins

Scénario Erreur 1 : Champs obligatoire non valides ou vides

alternatif Le système affiche un message d’erreur.
Erreur 2 : S’il y a une erreur d’ajout
Le système affiche un message d’erreur

Page 17
Description textuelle de « supprimer un administrateur »

Tableau 8 : Tableau de description textuelle de « Supprimer un administrateur »

Acteurs Master Admin

Pré condition Authentification préalable

Post condition Suppression d’un admin

Scénario 1.Le Master administrateur choisit un administrateur dans la liste.

nominal 2.Le Master administrateur clique sur bouton supprimer admin.
3.Le système affiche un message de succès
4.Le système affiche nouvelle liste des admins

Scénario Erreur : S’il y a une erreur de suppression

alternatif Le système affiche un message d’erreur

Description textuelle de « Consulter la liste des admins »

Tableau 9 : Tableau de description textuelle de « Consulter la liste des admins »

Acteurs Admin

Pré condition Authentification préalable

Post condition Affichage de la liste des admins

Scénario 1. L’administrateur choisit le menu « administrateurs ».

nominal 2. La liste des admins est affichée

4.4. Conception

4.4.1. Diagramme de classe du sprint 2

Le diagramme de classe est un schéma utilisé pour présenter les classes et les interfaces des systèmes
ainsi que les différentes relations entre celles-ci. Une classe est un ensemble de fonctions et données
(attributs) qui sont liées ensemble par un champ sémantique.

Page 18
 Figure 7 : Diagramme de classe du sprint 2

4.4.2. Les diagrammes de séquences

Pour systématiser la vision comportementale du système que nous voulons développer, nous utilisons les
diagrammes de séquence UML et leurs descriptions textuelles

Diagramme de séquence « Authentification » :

Page 19
 Figure 8 : Diagramme de séquence « Authentification »

Diagramme de séquence « Consulter la liste des admins » :

Page 20
 Figure 9 : Diagramme de séquence « Consulter un administrateur »

Page 21
Diagramme de séquence « Ajout des admins » :

Figure 10 : Diagramme de séquence « Ajout un administrateur »

Diagramme de séquence « Suppression des admins » :

Page 22
 Figure 11 : Diagramme de séquence « Suppression un administrateur »

4.5. Réalisation

Page 23
 4.5.1. Technologies et outils de réalisation

Tout au long de ce projet, j’ai utilisé plusieurs outils et technologies pour la réalisation et les tests

a) Environnement matériel

Tableau 10 : Tableau de caractéristiques du PC portable

Nom du Pc Pc ASUS

Processus Intel Core i7 4TH GEN

Mémoire RAM 8GO

Système d’exploitation Windows 10

Carte Graphique NVIDIA GeForce GT 720 M

b) Environnement de développement

Visual Studio Code

Visual Studio Code est l'éditeur de code extensible de Microsoft pour Windows, Linux et MacOs

Figure 12: Logo Visual Studio Co

XAMPP

XAMPP est un ensemble de logiciels permettant de mettre en place facilement un serveur Web et un
serveur FTP. [9]

Page 24
 Figure 13 : Logo XAMPP

4.5.2. Les interfaces

Interface authentification

L’interface de la (figure 14) permet à l’administrateur de s’authentifier suite à la saisie de son adresse
email et son mot de passe.

Figure 14 : Interface authentification

Interface récupération du mot de passe

Dans le cas où l’administrateur a oublié son mot de passe pour l’accès à l’interface admin, il faut qu’il
clique sur « Forgot Password ? ». Pour accéder a une interface de récupération.

Page 25
Dans le cas ou l’administrateur oubli son mot de passe il peut le récupérer en cliquant sur « forgot
password » de la figure 14

Figure 15 : Interface récupération du mot de passe

Page d’acceuil

Suite a l’authentification, la page d’acceuil est affichée

Figure 16 : Interface page d’accueil

Liste des administrateurs

Page 26
Pour consulter la liste des administrateurs (figure 17), il suffit de cliquer sur « services » du menu
LAyouts(figure 16)

Figure 17 : liste des administrateurs

Interface ajouter un admin
Pour ajouter un autre admin, le Master administrateur clique sur « ajouter admin »de la figure 17 ainsi
l’interface de la figure 18 est ajouter. Il suffit donc de saisir les

Figure 18 : Page d'ajout administrateur

5. Conclusion

Page 27
Dans ce chapitre intitulé « Release 1 », nous avons commencé par définir l'objectif du travail grâce au
sprint goal et Backlog Sprint. Ensuite, nous avons fait l'analyse détaillée de ce dernier pour aboutir et
expliquer les techniques utilisées. On termine notre premier release avec une étude conceptuelle et la
réalisation de cette itération. Nous pouvons poursuivre notre travail et passer au release 2 qui fera l'objet
du chapitre suivant.

Chapitre 4 : Release 2
Page 28
1. Introduction
Après avoir détaillé le déroulement des deux premiers sprints, nous allons dans ce chapitre présenter le
deuxième release. Il est composé d’un sprint à savoir le sprint 3. L’étude de ce sprint couvre l’analyse, la
conception et la réalisation.

2. Organisation de sprint 3
Ce sprint contient les user story suivantes :

 Gestion des services

 Consulter les services

 Ajouter un service

 Modifier un service

 Supprimer un service

 Gestion des réservations

 Consulter les réservations

 Ajouter une réservation

 Modifier une réservation

 Supprimer une réservation

 Confirmer une réservation

3. Sprint Goal
L'objectif de ce Sprint consiste à réaliser l'ensemble des fonctionnalités permettant à un administrateur
ou client de gérer les services et les réservations

4. Sprint Backlog
Page 29
 Le Tableau ci-dessous représente le Backlog de notre troisième sprint :
Tableau 11 : Tableau de backlog de sprint 3

User Story Tâche Complexité Priorité

Sprint

Release

Gestion des Consulter les Services Moyenne Must

Service
Ajouter un service

Modifier un service
Sprint 3

Supprimer un service

Gestion des Consulter les réservations Moyenne Must

Release2

réservation
Ajouter une réservation

Modifier une réservation

Supprimer une réservation

5. Analyse des besoins

5.1. Les besoins fonctionnels
 Affichage de la liste des services : l’administrateur peut consulter la liste des service contenant leurs
détails (identifiant de service, nom).
 Ajout d’un service : l’administrateur peut ajouter un service avec un formulaire contenant les champs
concernant les détails du service.
 Modification d’un service : le système affiche à l’administrateur un formulaire pour modifier les
détails de ce service.
 Suppression d’un service : Après la consultation de la liste des service, l’administrateur peut choisit un
service pour supprimer.
 Affichage de la liste des réservations : l’administrateur peut consulter la liste des réservations qui
contient leurs détails (id de réservation, prix total, date, état).

Page 30
 Confirmation d’une réservation : après la consultation de la liste des réservations, l’administrateur peut
confirmer une réservation.
 Ajout une réservation : le client peut remplir le formulaire de réservation et la confirmer
 Modification une réservation : le système affiche au client un formulaire pour modifier les détails de
cette réservation.
 Suppression d’une réservation : Après la consultation de la liste des réservations, l’administrateur peut
choisir une réservation pour supprimer.

5.2. Diagramme de cas d’utilisation du sprint 3

Page 31
 Figure 19 : Diagramme de cas d’utilisation du sprint 3

Description textuelle de « Consulter les services »

Tableau 12 : Tableau de description textuelle de « Consulter les services »

Acteurs Admin/Client

Pré condition Authentification préalable

Page 32
Post condition Affichage de la liste des services

Scénario nominal 1. L’administrateur/le client choisit dans le menu « Les services ».

2. La liste des services est affichée

Scénario alternatif Erreur : S’il y a une erreur d’affichage

 Le système affiche un message d’erreur

Description textuelle de « Ajouter un service »

Tableau 13 : Tableau de description textuelle de « Ajouter un service »

Acteurs Admin

Pré condition Authentification préalable

Post condition Ajout d’un service

Scénario 1. L’administrateur choisit dans le menu « Les services ».

nominal 2. L’administrateur clique Button « Ajouter » un service.
3. L’administrateur remplit le formulaire.
4. L’administrateur clique sur « Enregistrer ».
5. Le système affiche la nouvelle liste des services

Scénario Erreur : Si le service existe déjà

alternatif  Le système affiche un message d’erreur
 Le processus reprend a l’étape 3

Description textuelle de « Supprimer un service »

Tableau 14 : Tableau de description textuelle de « Supprimer un service »

Acteurs Admin

Pré condition Authentification préalable

Page 33
Post condition Suppression d’un service

Scénario 1. L’administrateur choisit un service dans le menu « Les services » pour le

nominal supprimer
2. L’administrateur Clique Button « Supprimer »
3. Le système affiche la nouvelle liste des services

Description textuelle de « Modifier un service »

Tableau 15 : Tableau de description textuelle de « Modifier un service »

Acteurs Admin

Pré condition Authentification préalable

Post condition Modification d’un service

Scénario 1. L’administrateur choisit un service dans le menu « Les services » pour le

nominal modifier
2. L’administrateur Clique Button « Modifier » et remplit les nouveaux données

Scénario Erreur : S’il y a une erreur de modification

alternatif  Le système affiche un message d’erreur

Description textuelle de « Consulter les réservations »

Tableau 16 : Tableau de description textuelle de « Consulter le réservations »

Acteurs Admin

Pré condition Authentification préalable

Post condition Affichage de la liste des réservations

Page 34
Scénario 1. L’administrateur choisit dans le menu « Les réservations ».
2. La liste des réservations est affiché
nominal

Description textuelle de « Ajout d’une réservation »

Tableau 17 : Tableau de description textuelle de « Ajouter une réservation »

Acteurs Client

Pré condition

Post condition Ajout d’une réservation

Scénario 1. Le client choisit dans le menu « Réservation »

2. Le client remplit le formulaire
nominal
3. Le client clique sur le bouton « réserver »
Scénario Erreur : S’il y a une erreur d’ajout
alternatif  Le système affiche un message d’erreur

Description textuelle de « Confirmer une réservation »

Tableau 18 : Tableau de description textuelle de « Confirmer une réservation »

Acteurs Client

Pré condition Réserver sur le site

Post condition Confirmation d’une réservation

Page 35
Scénario 1. le client reçoi le lien de confirmation par Email
nominal 2. Le client clique sur « Confirmer »
3.Le système affiche la réservation a été confirmer

Description textuelle de « Supprimer une réservation »

Tableau 19 : Tableau de description textuelle de « Supprimer une réservation »

Acteurs Admin

Pré condition Authentification préalable

Post condition Suppression d’une réservation

Scénario 1. L’administrateur choisit dans le menu « les réservation » une réservation pour
nominal la supprimer
2. L’administrateur Clique Button « Supprimer »
3. Le système affiche la nouvelle liste des réservations

Description textuelle de « Modifier une réservation »

Tableau 20 : Tableau de description textuelle de « Modifier une réservation »

Acteurs Admin

Pré condition Authentification préalable

Post condition Modification d’une réservation

Page 36
Scénario 1. L’administrateur choisit dans le menu « Les réservations » une réservation
nominal pour la modifier
2. L’administrateur Clique Button « Modifier » et remplit les nouvelles données
3. Le système affiche la nouvelle liste des réservations

Scénario Erreur : Si le nouveau nom est déjà utilisé

alternatif  Le système affiche un message d’erreur

5.3Conception

5.3.1. Diagramme de classe du sprint 3

Figure 20 : Diagramme de classe du sprint 3

5.3.2. Les diagrammes de séquences

Diagramme de séquence « Consulter les services » :

Page 37
 Interface CommandeControlleur Commande

Figure 21 : Diagramme de séquence de Consultation les services

Diagramme de séquence « Ajouter un service » :

Page 38
 Interface CommandeControlleur Commande

Figure 22 : Diagramme de séquence d’ajout les services

Diagramme de séquence « Modifier un service » :

Page 39
 Figure 23 : Diagramme de séquence de modification les services

Diagramme de séquence « Supprimer un service » :

Page 40
 Figure 24 : Diagramme de séquence de suppression de services

Diagramme de séquence « Ajouter une réservation » :

Page 41
 Figure 25 : Diagramme de séquence d’ajout d’une réservation

Diagramme de séquence « Supprimer une réservation » :

Page 42
 Figure 26 : Diagramme de séquence de suppression d’une réservation

5.4 Réalisation

5.4.1 Les interfaces

Page 43
Liste de services :

L’interface de la (figure 26) sert à aider l’administrateur de consulter la liste des services. Où on a les
possibilités d’ajouter, modifier et supprimer un service.

L’administrateur choisie le menu service pour consulter l’interface des services.

Figure 27 : Interface des services pour les administrateurs

Ajout d’un service :

Page 44
En cliquant sur le bouton « ajouter service » de l’interface de la figure 26, le formulaire d’ajout d’un
service s’affiche comme le montre (la figure 27).

Figure 28 : Ajout d’un service

Modification d’un service :

Le fait de cliquer sur le bouton « modifier service » de l’interface de la figure 26, lance un appel au
formulaire de modification du service comme la montre (la figure 28).

Figure 29 : Modification d’un service

Liste des réservations :

Page 45
L’interface de cette figure (figure 29) montre la liste des reservation effectuées.

Figure 30 : Modification d’un service

Ajout d’une réservation :

Pour l’ajout d’une reservation un formulaire sera afficher pour l’utilisateur (figure 30). Si l’utilisateur
oublie de remplir l’un des champs un message d’erreur sera afficher (figure 31).

Figure 31 : Ajout d’une réservation Figure 32 : erreur d’ajout d’une réservation

Modification d’une réservation :

Page 46
 Figure 33 : Modification d’une réservation

6. Conclusion
Le résultat de cette release est de mettre en place un système de gestion des services et des réservations.
À la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de valeur pour le
client. Dans le chapitre qui suit, notre effort sera consacré pour produire une nouvelle release couvrant
les fonctionnalités qui concernent gestion des questions.

Chapitre 5 : Release 3

Page 47
 1. Introduction
Après avoir fini le deuxième release de notre site, nous passons au troisième Et dernier release. Le
release couvre l’analyse, la conception et la réalisation du sprint 4

2. Sprint goal
L'objectif de ce Sprint consiste à réaliser l'ensemble des fonctionnalités permettant à un administrateur
de gérer les messages.

3. Sprint Backlog
Tableau 21 : Tableau backlog de sprint 4 :

Release Sprint User story Tâches Complexité Priorité

Consulter les En tant qu’administrateur je peux Moyenne Must

question consulter les questions
Releases 3

Sprint 4

Ajouter des En tant que client je peux ajouter Moyenne Must

questions une question

Supprimer des En tant qu’administrateur e peux Moyenne Must

questions supprimer les questions

4. Analyse des besoins

4.1 Les besoins fonctionnels
 Affichage des questions : les administrateurs peuvent consulter les messages.
 Ajout une question : le client peut envoyer un message à l’administrateur à travers un formulaire.
 Suppression d’une question : Après la consultation les messages avec l’admin, Ce dernier choisit un
message pour supprimer.

Page 48
 4.2 Diagramme de cas d’utilisation

Figure 34 : Diagramme de cas d’utilisation de sprint 4

Description textuelle de « Consulter les questions »

Tableau 22 : Tableau de description textuelle de « Consulter les questions »

Acteurs Administrateur

Pré condition Authentification préalable

Post condition Affichage des questions

Scénario 1. L’administrateur choisit le menu « Questions ».

nominal 2. La liste des messages est affichée

Description textuelle de « Ajouter les questions »

Tableau 23 : Tableau de description textuelle de « Ajouter une question »

Page 49
 Acteurs Client

Pré condition

Post condition Envoyer un message

Scénario 1. Le client choisit le menu « Contact »,

nominal 2. Le client remplit le formulaire par le message
3. Le client clique sur le bouton « envoyer » pour envoyer le message

Scénario Erreur : Si les champs sont vides

alternatif  Le système affiche un message d’erreur

Description textuelle de « supprimer les questions »

Tableau 24 : Tableau de description textuelle de « Supprimer une question »

Acteurs Administrateur

Pré condition Authentification préalable

Post condition Afficher les messages

Scénario 1.L’administrateur choisit une question dans le menu « questions(quote) » pour le

nominal supprimer
2.L’administrateur clique sur le bouton « supprimer »

Scénario Erreur : Si la question n’est pas encore traitée

alternatif  Le système affiche un message d’erreur

5. Conception : Diagramme de classe

Page 50
 Figure 35 : Diagramme de classe de sprint 4

6. Réalisation
Les interfaces

Liste des questions :

L’administrateur peut consulter les messages envoyés par les utilisateurs sur la page questions de
l’interface administrateur (figure 35)
L’administrateur choisie la menue question pour consulter l’interface les réservations.

Figure 36 : Consultation des questions

Ajouter une question :

Page 51
L’utilisateur doit remplir le formulaire pour envoyer un message (figure 36). L’utilisateur choisie le
menu contact pour pouvoir émettre une question Si l’un des champs est vide une erreur s’affiche (figure37).

Figure 37 : Ajout d’une question Figure 38 : Erreur d’ajout

7. Conclusion
Durant ce chapitre nous avons réalisé les différentes tâches mentionnées dans le backlog Sprint.
D'abord, nous avons fait l'analyse détaillée puis la conception et enfin la réalisation de chaque sprint.
Ce release comme mentionné précédemment se focalisait sur les gestions des messages. C'est le
dernier chapitre de notre projet.

Conclusion Générale
Page 52
 Le travail présenté dans ce rapport a été réalisé au sein de la société AHSL dans le cadre d'un projet
de fin d'études pour l'obtention du diplôme de licence Ingénierie des Systèmes informatique. Le but
de notre projet est de créer un site web pour la société, ceci m’a amené à enrichir mes compétences
en développement web et mon expérience.

Pour aboutir à ce résultat, nous avons tout d'abord commencé par introduire le cadre du projet ainsi
qu'une étude de l'art avec les problématiques traitées et la solution proposée. Ensuite, nous avons
expliqué la mise en place du Framework SCRUM dans notre projet.

Le troisième chapitre « Release 1 » présente les deux premiers sprints portant sur l'intégration de
l'interface, l’inscription, l'authentification et la gestion des admins.

Le quatrième chapitre « Release 2 » dont nous avons pu développer le sprint3, portant sur la gestion
des services et gestion des réservations.

Le cinquième chapitre « Release 3 » consacré pour le dernier sprints 4 qu'il est pour la gestion des
questions. Ce projet a permis de s'adapter, de s'améliorer dans le développement des web, d'enrichir
et d'approfondir mes connaissances techniques.

On peut aussi rendre le projet plus attractif, on rendre la reservation et les proposition des questions
n'est possible que pour les clients qu'ils ont des comptes et ils doivent être connecter pour consulter
la page de réservations ou la page de contact

Page 53
 Bibliographie

[1]: https://blog.dcube.fr/index.php/2014/04/28/scrum-vs-cycle-en-v-2-2/

[2]: https://agiliste.fr/guide-de-demarrage-scrum/

[3]:https://blog-gestion-de-projet.com/roles-et-responsabilites-de scrum/#t1648036339551

[4]: https://asana.com/fr/resources/product-backlog

[5]: en.wikipedia.org/wiki/MoSCoW_method

[6] :Memoire Online - Conception et developpement d'une application de gestion d'une bibliothèque
- wilfried-Erisco MVOU-OSSIALAS

[7] : Draw.io : un outil pour dessiner des diagrammes en ligne (tice-education.fr)

[8]: https://www.ibm.com/docs/fr/rational-soft-arch/9.5?topic=diagrams-use-case

[9]: https://desgeeksetdeslettres.com/web/xampp-plateforme-pour-heberger-sonpropre-site-web

Page 54