Remerciements: ATROUSSI, Directeur de L'entreprise GPRO - CONSULTING. Un Grand Merci Pour

Raafa Amri
Remerciements
En premier lieu, je voudrais remercier les membres de jury d’avoir accepté de juger
ce travail, tous mes respects et ma sincère reconnaissance.
Je tiens à remercier mon encadrante académique Mme. SONIA KEFI pour le

grand honneur qu’elle m’a fait durant ce projet de fin d’études. J’ai eu l’honneur et le
privilège de travailler sous son assistance et de profiter de ses qualités humaines,
professionnelles et de sa grande expérience. Elle m’a guidé tout le long de ce travail dont
elle a mis à cœur, l’élaboration avec l’amabilité et le dynamisme qu’elles caractérisent.
Je tiens aussi à remercier mon encadreur professionnel, M. GHAZI

ATROUSSI, directeur de l’entreprise GPRO_CONSULTING. Un grand merci pour
son accueil chaleureux au sein de l’entreprise qu’il dirige, ainsi que pour sa patience et ses
précieux conseils durant la période de stage.
Je profite aussi de ce projet pour exprimer mes remercîments à tous les

professeurs qui m’ont apporté du soutien durant mes études.
Puisse ce modeste travail, puisse satisfaire et témoigner notre gratitude et

connaissance pour l’aide et les conseils qu’ils nous avons prodigués.
Année universitaire : 2019-2020 -i-

Raafa Amri
Dédicaces
Toutes les lettres ne sauraient trouver les mots qu’il faut…
Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la reconnaissance…Aussi,

c’est tout simplement que
Je dédie ce travail
À MES CHERS PARENTS
Aucune dédicace ne saurait exprimer mon respect, Mon amour éternel et ma considération pour les
sacrifices que vous avez consenti pour mon instruction et mon bien être. Je vous remercie pour tout le
soutien et l’amour que vous me portez et j’espère que votre bénédiction m’accompagne toujours.
Que ce modeste travail soit le fruit de vos innombrables sacrifices, Puisse Dieu, le Très Haut, vous
accorder santé, bonheur et longue vie et faire en sorte que jamais je ne vous déçoive.
A Mes sœurs adorées Sana et Ahlem
Vous m’avez remonté le moral lorsque ma détermination flanchait, j’espère que vous appréciez le
fruit de tant d’effort.
A Mes frères adorées Anis, Riadh et aymen
Vous m’avez soutenu, réconforté et encouragé. Puissent nos liens fraternels se consolider et se
pérenniser encore plus.
A LA MEMOIRE DE MES GRAND-PERES ET MA GRAND-MERE
J’aurais tant aimé que vous soyez présents. Que Dieu ait vos âmes dans sa sainte miséricorde
À MES AMIES DE TOUJOURS Asma, Ikram, Dorra, Ameni
Je ne peux trouver les mots justes et sincères pour vous exprimer mon affection et mes pensées, vous
êtes pour moi des sœurs et des amies sur qui je peux compter. En témoignage de l’amitié qui nous unit et des
souvenirs de tous les moments que nous avons passés ensemble, je vous dédie ce travail et je vous souhaite
une vie pleine de santé et de bonheur.
A toutes les personnes qui ont participé à l’élaboration de ce travail à tous ceux que j’ai omis de citer
Année universitaire : 2019-2020 -ii-

Raafa Amri
Table de matières
Introduction Générale ..................................................................................................1
Chapitre 1 : Contexte général ......................................................................................3
Introduction .............................................................................................................3
1. 1 Cadre général du travail..............................................................................3
1. 2 Présentation de l’entreprise.........................................................................3
1. 3 Contexte général et problématique..............................................................4
1. 4 Etude de l’existant ......................................................................................5
1.4.1 CloudHotelErp ......................................................................................5
1.4.2 IT Monteur Hôtel Management Software ..............................................6
1.4.3 HotelFriend ...........................................................................................6
1. 5 Synthèse et critique de l’existant ................................................................7
1. 6 Solution proposée .......................................................................................8
1. 7 Pictogramme de notre solution ...................................................................9
1. 8 Les méthodologies de développement ...................................................... 10
1.8.1 Etude des méthodologies de développement ........................................ 10
1.8.2 La méthodologie adaptée ..................................................................... 11
Conclusion ............................................................................................................ 13
Chapitre 2 : Sprint 0 « Spécification des besoins » ................................................. 15

Introduction ...........................................................................................................15
2. 1 Capture des besoins .................................................................................. 15
2.1.1 Identification des acteurs ..................................................................... 15
2.1.2 Capture des besoins fonctionnels ......................................................... 16
2.1.3 Capture des besoins non fonctionnels .................................................. 17
2.2 Architecture de l’application .................................................................... 18
2.3 Pilotage du projet avec Scrum .................................................................. 19
2.3.1 Backlog du produit .............................................................................. 19
Année universitaire : 2019-2020 -iii-

Raafa Amri
2.3.2 Planification des sprints ....................................................................... 20
2.4 Approche conceptuelle associée aux sprints.............................................. 21
2.5 Environnement de développement ............................................................ 22
2.5.1 Environnement technique .................................................................... 22
2.5.2 Environnement logiciel ....................................................................... 27
Conclusion ............................................................................................................ 27
Chapitre 3 : Release 1 « Gestion d’hébergement » ..................................................... 29

Introduction ...........................................................................................................29
3.1 Premier Sprint .......................................................................................... 29
3.1.1 Spécifications fonctionnelles ............................................................... 30
3.1.2 Diagramme de classes ......................................................................... 32
3.1.3 Diagramme de séquence ......................................................................33
3.1.4 Revue du Sprint ................................................................................... 35
3.1.5 Rétrospective....................................................................................... 38
3.2 Deuxième sprint ....................................................................................... 38
3.2.4 Revue du sprint ................................................................................... 46
3.2.5 Rétrospective....................................................................................... 48
Conclusion ............................................................................................................ 48
Chapitre 4 : Release 2 « Gestion des Réclamations » ................................................. 49

Introduction ...........................................................................................................50
4.1 Premier sprint ............................................................................................... 50
4.1.4 Revue du sprint ................................................................................... 54
Année universitaire : 2019-2020 -iv-

Raafa Amri
4.1.5 Système de notification utilisé ............................................................. 56
4.2 Deuxième sprint ....................................................................................... 58
4.2.1 Revue du sprint ................................................................................... 59
4.2.2 Présentation du Power BI .................................................................... 59
4.2.3 L’architecture de Power BI .................................................................. 60
4.2.4 Les éléments constitutifs de Power BI ................................................. 61
4.2.5 Service Power BI................................................................................. 62
Conclusion ............................................................................................................ 64
Conclusion générale .................................................................................................. 65

Bibliographie ............................................................................................................ 66
Année universitaire : 2019-2020 -v-

Raafa Amri
Liste des figures
Figure 1 : Cloud Hotel ERP ........................................................................................5

Figure 2 : Hôtel Management software .......................................................................6
Figure 3 : HOTELFREIND .........................................................................................7
Figure 4 : Pictogramme de la solution proposée .........................................................9
Figure 5 : La méthodologie agile « Scrum » .............................................................. 12
Figure 6 : Architecture de l'application ..................................................................... 18
Figure 7 : Plan des releases ...................................................................................... 20
Figure 8 : Les vues UML ........................................................................................... 21
Figure 9 : Etude des langages de développement ...................................................... 22
Figure 10 : Diagramme de cas d'utilisation sprint 1 .................................................. 31
Figure 11: Diagramme de classes du Sprint 1 ........................................................... 32
Figure 12 : Digramme de séquence «authentification » ............................................. 34
Figure 13 : Diagramme de séquence "ajouter chambre" ...........................................35
Figure 14: Interface « Authentification »................................................................... 36
Figure 15 : Liste des chambres selon les blocs .......................................................... 36
Figure 16 : Interface d'ajout chambre ....................................................................... 37
Figure 17 : Diagramme de cas d'utilisation du sprint 2 ............................................. 40
Figure 18 : Diagramme de classes sprint 2 ............................................................... 43
Figure 19 : Diagramme de séquence « réserver chambre » ....................................... 44
Figure 20 : Diagramme de séquence « modifier client » ............................................ 45
Figure 21 : Interface de la gestion des réservations .................................................. 46
Figure 22: interface des réservations de la date courante ......................................... 47
Figure 23 : Interface réservation chambre ................................................................ 47
Figure 24 : Diagramme du cas d'utilisation du premier sprint................................... 51
Figure 25 : Diagramme de classes du Sprint 1 ........................................................... 53
Figure 26 : Diagramme de séquence « envoyer réclamation »................................... 54
Figure 27 : Interfaces d’authentification et d’accueil ................................................ 55
Figure 28 : Interface de réclamation avec notification en temps réel ......................... 56
Figure 29 : Architecture technique du FCM .............................................................. 57
Figure 30 : Fonctionnement du FCM ........................................................................ 58
Année universitaire : 2019-2020 -vi-
Raafa Amri
Figure 31 : Le rapport BI .......................................................................................... 59

Figure 32 : Les composants de Power BI .................................................................. 60
Figure 33 : Les composants de Power BI .................................................................. 61
Figure 34 : Comparaison Power BI ...........................................................................63
Année universitaire : 2019-2020 -vii-

Raafa Amri
Liste des tableaux
Tableau 1 : Présentation de la société .........................................................................3

Tableau 2 : Synthèse des applications existantes .........................................................8
Tableau 3 : Comparaison des méthodes de développement ........................................ 10
Tableau 4 : Backlog du produit ................................................................................. 19
Tableau 5 : Tâches du premier sprint ........................................................................ 29
Tableau 6 : Description textuelle du cas «ajouter chambre» ..................................... 31
Tableau 7 : Les tâches du deuxième sprint ................................................................ 38
Tableau 8 : Description textuelle du cas « ajouter réservation » ............................... 41
Tableau 9 : Description textuelle du cas « activer une réservation » ......................... 41
Tableau 10 : Description textuelle du cas « modifier client »..................................... 42
Tableau 11 : Les tâches du premier sprint ................................................................. 50
Tableau 12 : Description textuelle du cas d'utilisation « envoyer réclamation » ........ 51
Tableau 13 : Description textuelle du cas d'utilisation « gérer réclamation » ............ 52
Année universitaire : 2019-2020 -viii-

Raafa Amri
Introduction Générale
De nos jours, savoir gérer de plus en plus les informations, sous contrainte de délai, est
un défi important pour chaque entreprise. Pour relever de tels défis, plusieurs solutions ont été
proposées, la solution la plus intuitive sera de développer des applications autonomes dédiées
à chaque structure de l’entreprise. Cette solution peut être au départ satisfaisante, mais elle
perd vite son efficacité à long terme, ceci est due au besoin de partager l’information entre ces
différents structures. Pour pallier à ce problème, l’usage d’ERP (Entreprise Ressource
Planning), ou PGI (Progiciel de gestion intégré) en français est vite recommandé, car l’ERP
est capable d’intégrer tous les processus de gestion en un système d’information unique et
cohérent.
Pour le secteur d’hôtellerie, la gestion de l’ensemble de ses activités se fait

généralement par le biais des applications informatiques. Un hôtel souhaite gérer la totalité
de ses activités autour d’un même système d’information, à l’aide d’un progiciel de gestion
intégrée.
C’est dans ce contexte que la société Gpro Consulting propose de développer une
solution ERP pour les hôtels. En effet, notre projet consiste à adapter puis intégrer et
personnaliser cette solution pour permettre une gestion efficace des hôtels.
Ce rapport est composé par quatre chapitres délimitant le contour de notre projet dont
le premier présente le contexte général dans lequel nous exposons et analysons les techniques
qui peuvent servir le projet. Ensuite, dans le deuxième chapitre, nous analyserons les besoins
fonctionnels et non fonctionnels de notre application en présentant l’étude préalable du projet.
Le troisième chapitre et le quatrième sont le corps de notre rapport. Ces deux chapitres seront
consacrés pour le développement des deux releases de notre système en respectant les
principes fondamentaux de Scrum. Dans chacun d’eux, nous commençons par la spécification
du sprint, ensuit la phase conceptuelle qui sera matérialisée par l’élaboration des diagrammes
UML, puis nous présentons la phase d’implémentation par des interfaces de l’application et
des rétrospectives. Nous terminerons ce rapport par une conclusion sur l’apport du travail
réalisé et des perspectives futures.
Année universitaire : 2019-2020 -1-

Raafa Amri
Chapitre 1
Contexte Général

Raafa Amri
Chapitre 1 : Contexte général
Introduction
Dans ce chapitre, nous allons présenter notre projet de fin d’étude. La première partie est
dédiée à la présentation de l’organisme d’accueil « Gpro Consulting » et leurs spécialités.
Dans la deuxième partie, nous nous focalisons sur le contexte général de notre projet, la
problématique qui nous amène à réaliser notre projet et on finit par une étude et une critique
de l’existant.
1. 1 Cadre général du travail

Cette étude est inscrite dans le cadre de la préparation de notre projet de fin d’études en
vue de l’obtention du diplôme d’Ingénieur en Informatique à l’Ecole Polytechnique de
Sousse. Notre projet s’est effectué au sein de l’entreprise « Gpro Consulting » où nous avons
été accueillies pour une durée de cinq mois.
1. 2 Présentation de l’entreprise
L’entreprise d’accueil est « Gpro Consulting » est une société multi-facettes créée en
2015, elle permet d’effectuer un ensemble d’études et de consulting dans la mise en place des
systèmes d’informations, des logiciels de gestion industriel et du développement spécifique
adaptés aux besoins de ses clients.
Tableau 1 : Présentation de la société
Raison sociale Gpro Consulting
Nom du gérant Ghazi Atroussi
Adresse Avenue Mohamed Attia Khzema Ouest – Sousse

Email contact@gproconsulting.com
Site web www.gproconsulting.com
Téléphone 58 100 435 / 73 276 175
Compétences Java JEE- Spring MVC Framework- Angular Js-
Intégration ERP- Android et IOS

Raafa Amri
GPRO Consulting est basée à Sousse et comporte une équipe dynamique, des
consultants et un large réseau de partenaires. Elle possède un service informatique de qualité
auprès des PME/PMI, à très forte valeur ajoutée misant sur l’innovation et l’expertise et qui
s’engage à garantir la satisfaction de ses clients.
L’entreprise fournit des solutions dans des domaines diversifier liés aux:
 Système ERP (Entreprise Ressource Planning),
 Solutions logicielles de gestion industrielle et manufacturière,
 Assistance technique dans les différents processus industriels,
 Etude et consulting dans la mise en place des systèmes d’information,
 Expertise en termes de préparation des certifications,
 Infogérance,
 Développement spécifique adapté au besoin des clients,
 Outsourcing pour le marché européen notamment le marché Français,
1. 3 Contexte général et problématique

Vu la complexité de leurs activités, les hôtels connaissent actuellement assez de difficultés
liées à leur mode de gestion entrainant le gaspillage du temps lors du traitement des
opérations des clients à l'hôtel, tels que la réservation des clients, le remplissage du bulletin
d'inscription de l'hôtel, fiche d'identification des clients, etc. En effet, des centaines de
propriétaires de l’hôtellerie contactent les sociétés de logiciels chaque année pour trouver un
logiciel répondant aux besoins de leurs propriétés et qui lui facilite la bonne gestion.
Un propriétaire nécessite un système de gestion d’hôtel, multi-branche et multi-activité,

qui traite toutes les opérations relatives au management hôtelier à savoir les opérations de
réservation, d’accueil et d’hébergement des clients et les différents services fournis pendant le
séjour.

Raafa Amri
1. 4 Etude de l’existant
Chaque année, plusieurs propriétaires des hôtels contactent les sociétés de logiciels pour
trouver un logiciel répondant à leurs besoins. L’exploration de ces interactions, nous permet
de dégager les solutions existantes sur le marché et de comprendre leurs fonctionnements. En
effet, nous avons fait une analyse des principales applications existantes qui vont être présenté
dans la partie suivante.
1.4.1 CloudHotelErp
C’est un logiciel complet de gestion hôtelière basé sur le Cloud qui est fiable, sécurisé et
permet aux hôteliers de gérer leurs opérations de n'importe où (voir figure 1). Les services
offerts par cette solution sont :
 Les services des chambres et de restauration,
 La gestion des clients et de employés,
 Un service de payement,
 La gestion de stock.
Figure 1 : Cloud Hotel ERP

Raafa Amri
1.4.2 IT Monteur Hôtel Management Software
L’IT Monteur Hôtel Management Software est un puissant logiciel de gestion hôtelière
et de réservation en ligne basé sur le Web pour gérer tous les types d'hôtels, appartements de
vacances ou chambres d'hôtes (voir figure 2). Les services présentent dans cette solution
sont :
 Un panneau administratif :
o La gestion des chambres.
o Le service de payement.
o La gestion des chambres, leurs types et leurs états.
o Des statistiques.
 Des comptes pour les clients :
o Gestions des comptes.
o Recherche des chambres disponibles.
Figure 2 : Hôtel Management software
1.4.3 HotelFriend
C’est une solution software de gestion des hôtels composé principalement d’un tableau de
bord de l’hôtel, une gestion de département et des employées, gestion des chambres et
réservations et un mobile application de life chat (voir figure 3). Les services présentent dans
cette solution sont :

Raafa Amri
 La gestion des clients,
 La gestion des réservations,
 La gestion des chambres.
Figure 3 : HOTELFREIND
1. 5 Synthèse et critique de l’existant

Dans cette partie, nous allons présenter sous forme d’un tableau comparatif une synthèse
résultante des solutions existantes, cette synthèse est faite selon des critères d’évaluation de
ces solutions.
 Ergonomie : Est-ce que l'application est-elle facile à utiliser, et est-elle attirante?

 Gestion des interventions : Est-ce que un client peut intervenir pour une réclamation ?
 Notification en temps réel : Est ce qu’il existe dans la solution un système de
notification pour notifier ?
 Tableau de bord intelligent : Est ce qu’il existe dans la solution un tableau de bord qui
permet d’afficher les statistiques de l’hôtel ?

Raafa Amri
Tableau 2 : Synthèse des applications existantes
HotelFriend ITmonteur CloudHotelErp
Ergonomie
Notification en temps réel
Gestion des réclamations

(extension mobile)
Tableau de bord
intelligent
D’après l’étude comparative faite dans le tableau 2, nous avons constaté que les solutions
existantes portent des insuffisances. Ces lacunes se voient surtout au niveau des services
clients et leurs interventions, vu que la plupart des applications citées ci-dessus se limitent
uniquement au système de gestion de différentes particularités de l’hôtel. Elles négligent la
partie d’intervention du client.
1. 6 Solution proposée
La société « Gpro Consulting » cherche toujours à moderniser la réalisation de ses projets,
en adoptant les dernières technologies afin de bien satisfaire ses clients. C’est dans ce cadre
que se propose notre projet, une solution ERP adaptée au secteur d’hôtellerie pour la gestion
de son système d’information.
Cette solution consiste alors à la mise en place d’une solution ERP destinée au secteur
d’hôtellerie qui permet de gérer les particularités d’un système d’information d’un hôtel et qui
permet de traiter toutes les opérations relatives aux managements hôteliers tels que les
opérations de réservation, d’accueil, d’hébergement et les différents services fournis pendant
le séjour afin d’améliorer la qualité du service client en un temps réel très réduit.
En effet, notre solution va remédier aux défaillances qui existent dans les solutions
présentées dans le tableau 2. Elle contient un module de notification en temps réel, une

Raafa Amri
extension mobile pour gérer les réclamations des clients au sein de l’hôtel et finalement, un
tableau de bord intelligent pour gérer les statistiques.
1. 7 Pictogramme de notre solution

Le pictogramme est un dessin figuratif ou une représentation graphique, il est utilisé pour
rendre explicite un objet ou un message dans les langues écrites. C’est également un symbole
d’écriture ou un signe linguistique dans les langues non écrites [1]. La figure 1 représente le
pictogramme de notre projet.
Figure 4 : Pictogramme de la solution proposée
La figure 4 montre le pictogramme de notre solution, en fait il existe une application web
qui communique avec un serveur (Api Rest) via des requêtes http. Ce serveur Rest
communique avec le serveur de base de données pour renvoyer de réponse de type JSON. De
l'autre côté, on trouve une application mobile installée qui facilite aux clients la
communication avec l'administration de l'hôtel. En effet, nous trouvons des requêtes de
réclamation de type http qui sont envoyées au serveur qui les transmet vers le web et ceci se
faire en appelant le service FCM de Google pour notifier la partie web qu’une requête est
entrante.

Raafa Amri
1. 8 Les méthodologies de développement

1.8.1 Etude des méthodologies de développement
La méthodologie est une démarche organisée rationnellement pour aboutir à un résultat.

Parmi les différentes méthodologies existantes, nous pouvons citer les méthodologies
traditionnelles (cascade, en V, etc.) et les méthodologies agiles (Scrum). Selon les approches
traditionnelles tout est planifié avant le début du projet. Une fois le cahier des charges est
créées et le contrat est signé, les développeurs ont la responsabilité de livrer ce qui est prévu.
Au contraire des approches traditionnelles, la gestion de projets Agile propose de vérifier

au fur et à mesure que le projet évolue dans la bonne direction. Son principe est simple: il
s’agit de découper le projet en plusieurs étapes ou petits projets. Chacune de ces étapes doit
aboutir à la création d’un élément fonctionnel de l’ensemble, qui s’inscrit dans les objectifs du
projet. Le tableau 3 montre une étude comparative entre les approches de développement les
plus connus.
Tableau 3 : Comparaison des méthodes de développement
Thème Approche traditionnelle Approche agile
Prédictive, caractérisée par Itératif et incrémental

Cycle de vie des plans plus ou moins
détaillés sur la base d’un
périmètre et d’exigence
définies et stables au début du
projet.
Prédictive, caractérisée par Adaptative avec plusieurs
Planification des plans plus ou moins niveaux de planification avec
détaillés sur la base d’un ajustement si nécessaires au
périmètre et d’exigence fil de l’eau en fonction des
définies et stables au début changements survenus
du projet
Produite en quantité Réduite au strict nécessaire
Documentation importante comme support au profit d’incréments
de communication, de fonctionnels opérationnels
validation et de pour obtenir le feedback du
contractualisation. client.
Une équipe avec des Une équipe responsabilisée
Equipe ressources spécialisées, ou l’initiative et la
dirigées par un chef de communication sont
projet. privilégiées, soutenue par le
chef de projet

Raafa Amri
Contrôle qualité à la fin du Un contrôle qualité précoce

Qualité cycle de développement. le et permanent, au niveau du
client découvre le produit produit et du processus. Le
fini. client visualise les résultats
tôt et fréquemment.
Résistance voire opposition Accueil favorable au
Changement au changement. Processus changement inéluctable,
lourds de gestions des intégré dans le processus.
changements acceptées.
Mesure de la conformité aux Un seul indicateur
Suivi de l’avancement plans initiaux. d’avancement : le nombre de
Analyse des écarts. fonctionnalités implémentées
et le travail restant à faire
Processus distinct, rigoureux, Gestion des risques intégrée
de gestion des risques. dans le processus global,
Gestion des risques avec responsabilisation de
chacun de chacun dans
l’identification et la
résolution des risques.
Pilotage par les risques.
Respect des engagements Satisfaction client par la
Mesure de succès initiaux en termes de couts, livraison de valeur ajoutée.
de budget et de niveau de
qualité.
1.8.2 La méthodologie adaptée
Après avoir étudié les différentes méthodologies de développement logiciel dans le

tableau précédent, nous avons opté pour Scrum en tant que méthodologie de développement
agile (voir la figure 5).
Dans une approche Scrum, le projet est organisé autour de « sprints » de

développement (les itérations) d’une durée allant généralement de deux à quatre semaines.
Le projet débute par le « sprint 0 », dédié à la réalisation de tous les travaux de

préparation et de mise en place : conception et architecture, environnements de
développement, outils de suivi et d’intégration [2].

Raafa Amri
Figure 5 : La méthodologie agile « Scrum »
D’après la figure 5, la méthodologie Scrum possédant trois points clés qui pourraient la
caractériser : les sprints (itérations) et leurs évènements, les 3 rôles clés (Product Owner, Equipe
de Développement et Scrum Master), le backlog avec des demandes fonctionnelles.
Elle est composé de :
 Le Product Owner :
C’est un membre à part entière de l’équipe Scrum représentant des clients et
utilisateurs dans le cadre du projet. Il est en charge de la tenue du backlog produit.
 Equipe de développement :
Transforme un besoin exprimé par le Product Owner en fonctionnalités utilisable.
L’équipe est responsable de délivrer à la fin de chaque sprint les items qui ont été priorisés
pour ce sprint.
 Scrum Master (Maître de mêlée) :
C’est une personne qui maîtrise le Scrum et qui s’assure que ce dernier est
correctement appliqué. Il a un rôle de coach à la fois auprès du Product Owner et auprès de
l’équipe de développement.

Raafa Amri
 Sprint :
C’est la durée des itérations appelées. Cette durée devra être la même pour l’ensemble
des sprints afin de maintenir un rythme régulier propice aux automatismes et pouvoir
construire des indicateurs de pilotage fiables. Un projet démarre généralement par ce qu’on
appelle souvent le « sprint 0 » dédié aux travaux préparatoires du projet.
 Product Backlog:
Le Product Backlog est utilisé par le Product Owner. C’est une liste ordonnée des
exigences fonctionnelles et non fonctionnelles du produit.
La priorité des éléments est définie suivant quatre caractéristiques : leur valeur métier,
leur effort de réalisation, leur risque et la connaissance technique ou métier apportée par leur
mise en œuvre.
 Sprint review (revue de sprint) :
À la fin de chaque sprint, l'équipe Scrum et le client se réunissent pour effectuer la
revue de sprint, ça duré maximal est de quatre heures. L'objectif de la revue de sprint est de
valider l'incrément de produit qui a été réalisé pendant le sprint.
 Sprint Retrospective (Rétrospective du sprint) :
C’est une réunion faite par l’équipe Scrum. Elle a pour but l'adaptation aux
changements qui surviennent au cours du projet et l'amélioration continue du processus de
réalisation. 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.
Conclusion
Dans ce chapitre, nous avons présenté l’organisme d’accueil, par la suite nous avons
présenté le cadre général du projet et la problématique, puis nous avons étudié les
méthodologies de développement afin de dégager la méthodologie adaptée à notre projet.

Raafa Amri
Chapitre 2
Sprint 0 : Spécification des besoins

Raafa Amri
Chapitre 2 : Sprint 0
« Spécification des besoins »
Introduction
Dans ce chapitre, nous allons présenter dans la première partie l’existant afin de
dégager l’insuffisance du système actuelle. Dans une deuxième partie, nous allons présenter
les différentes parties de la méthodologie de développement Scrum adaptée dans notre projet
et on finit ce chapitre par les captures des besoins de différents types.
2. 1 Capture des besoins

Généralement, les besoins de chaque application sont de trois types : les besoins
fonctionnels, les besoins non fonctionnels et les besoins techniques.
2.1.1 Identification des acteurs
Cette section a pour objet de présenter les acteurs et leurs fonctionnalités à laquelle doit
répondre notre application.
On entend par acteur, un humain, une machine, ou un système qui ne fait pas partie de la
solution à réaliser mais qui participe au fonctionnement général de la solution par une
interaction.
Les acteurs principaux de cette application sont :
 Agent administratif : c’est la personne qui possède le privilège le plus haut degré, il
peut accéder à toutes les rubriques de l’application, il peut également gérer les
différentes particularités de l’hôtel.
 Agent de réservation : c’est un acteur principal qui interagit avec notre application.
Cette personne est un agent de l’hôtel. Il peut accéder à l’application à travers son
login et mot de passe et gérer les modules propres à lui tels que la réservation, etc…
 Client : c’est un acteur qui interagit avec notre application pour intervenir ou bien
pour réclamer une anomalie de sa chambre.

Raafa Amri
2.1.2 Capture des besoins fonctionnels
Les besoins fonctionnels d’une application sont ce que l’utilisateur attend en terme de
fonctionnalités, elles sont directement liés aux tâches à réaliser. Les principales
fonctionnalités de notre projet sont :
 Connexion
Un module d’authentification sera intégré dans l’application, chaque acteur doit se

connecter avec son login et mot de passe pour accéder à son espace.
 Gestion des services d’hébergement (Bloc et chambres):
Chaque hôtel est composé de plusieurs blocs, et chaque bloc est composé des chambres.
Une chambre est caractérisée par son type (individuel, couple, suite), une caractéristique de
vue (vue sur mer, vue normal), son QR code qui va être généré lors de la création de la
chambre et téléchargeable pour des futures utilisations.
Dans notre cas, un agent administratif est censé à gérer la liste des blocs et des chambres.
 Gestion de réservation
Il s'agit d'une gestion simplifiée de réservation des chambres d'hôtel qu’elle se diffère
selon les critères. La réservation peut se faire à travers un agent de réservation.
Le module FrontOffice offre les options de sélection de bloc et de chambres ainsi que
le type de client (client, agence de voyage) et des dates. Il permet de créer des réservations,
modifier, chercher, consulter les réservations du jour et activer une réservation ou bien
l’annuler.
 Gestion des réclamations
Il s’agit d’une saisie, diffusion et traitement des réclamations clients sur l’ensemble des
dispositifs de l’hôtel en temps réel et ceci à l’aide d’une application mobile.
Chaque chambre possède un QR code, le client peut réclamer une alerte ou une anomalie
en scannant le QR code et l’envoie d’une réclamation via son mobile. Un agent administratif
sera notifier de cette réclamation, il la traite et la valide.

Raafa Amri
 Gestion des statistiques(BI)
Avec le module statistique, nous avons en temps réel le reflet exact de toutes activités :
réservations, réclamation, nombre de clients, etc.
2.1.3 Capture des besoins non fonctionnels
L’application doit offrir un ensemble de fonctionnalités qui répondent à des besoins non
fonctionnels bien définis tels que :
 Interface homme machine
La navigation doit être rapide, claire et pratique. La mise en page de l’application doit
faciliter le maximum de démarche à l’aide d’une représentation claire, il ne faut pas dépasser
3 ou 4 couleurs maximum. Les icones doit être les mêmes pour toute l’application. La page
doit être organisée selon les règles d’interface homme machine.
 La convivialité
L’application doit fournir une interface conviviale et simple à utiliser pour tout type
d’utilisateur. Elle doit présenter un enchaînement logique entre les différents modules.
 L’efficacité
Le système doit respecter les normes définies au terme de temps de réponse et

d’utilisation des ressources.
 la sécurité
L’application doit être sécurisée contre les attaques et les accès non autorisés. Elle doit
garantir à l’utilisateur connecté la confidentialité de ses données. La sécurité du système est
assurée par l’authentification avec un login et un mot de passe crypté qui est assuré par le
mécanisme du « Json Web Token ».

Raafa Amri
2.2 Architecture de l’application

L'architecture adapté dans notre travail c’est l’architecture des Microservices, en fait elle
correspond à un type d'architecture logicielle dans laquelle les grosses applications sont
conçues à partir de petites unités autonomes qui interagissent via des API indépendantes du
langage logiciel utilisé. Chaque service a une portée limitée, se concentre sur une seule tâche.
L'architecture Microservices est bien plus complexe que les systèmes classiques. En fait,
l'environnement se complexifie car il faut gérer et soutenir une multitude d'éléments en
mouvement [3].
Cette architecture est caractérisé par :
 Le déploiement d'un Microservice indépendamment n'affecte pas le fonctionnement

des autres Microservices.
 La répartition des charges.
 Facile à intégrer avec les outils et les architectures trois tiers.
 Facile à adapter les dernières technologies.
Figure 6 : Architecture de l'application

Raafa Amri
Notre projet est composé principalement de trois couches :
 Couche des interfaces utilisateurs (coté clients).

 Couche métier (coté serveur)
o Couche des contrôleurs
o Couche des services
o Couche DAO (repositories)
o Couche entités
 Couche des données (base de données).
2.3 Pilotage du projet avec Scrum

2.3.1 Backlog du produit
Le backlog contient la liste de toutes les spécificités du projet, classées par importance. Il
faut garder que le backlog n’est jamais complet. Alors que le projet prend forme, de nouveaux
besoins apparaissent sans cesse, ce qui vous oblige à actualiser la liste. Le Product Owner est
le principal responsable de ce processus.
Le tableau 4 présente la liste des scénarios utilisateurs.
Tableau 4 : Backlog du produit
Tâches Description Priorité

Connexion L’administrateur ou les personnels 1
de l’hôtel peuvent se connecter pour
accéder à leurs espaces.
Gestion des Un utilisateur peut ajouter, consulter 2
blocs ou supprimer des blocs.
Gestion des Un utilisateur administratif peut 3
chambres ajouter ou supprimer modifier ou
chercher des chambres.
Gestion des Un utilisateur peut ajouter, modifier, 4
Réservations chercher, activer ou annuler une
réservation.

Raafa Amri
Gestion des Un utilisateur peut modifier, 5

clients chercher ou supprimer un client
Gestion des Un client peut envoyer une 6
réclamations réclamation, l’utilisateur de
l’application web recevoir une
notification et traite cette réclamation
Tableau de Un tableau de bord pour gérer les 7
bord statistiques
2.3.2 Planification des sprints
A partir du backlog, on va choisir les tâches qui doivent être complétées lors du premier
sprint. Puisque, les sprints sont limités dans le temps alors on va définir une durée qui soit
compatible avec le projet et l’équipe, mais chaque sprint ne doit pas dépasser un mois. Lors
de la planification du sprint, l’équipe définit les tâches et leur responsable.
Release 1 Release 2
sprint1 sprint 1
authentification scanner qr-code chambre
gestion des Blocs envoyer reclamation
gestion des chambres notifier administration
gérer reclamation
sprint2 sprint 2
gestion des clients et type des clients tableau de bord (BI)
gestion des reservations
service de mailing
Figure 7 : Plan des releases

Raafa Amri
2.4 Approche conceptuelle associée aux sprints

Dans notre projet, nous allons utiliser le langage UML avec les différents diagrammes qui
sont repartie selon les vues.
 Vue Fonctionnelle: défini les cas d’utilisation comme des ensembles des scénarios. Un
scénario représente une interaction entre un utilisateur et le système. Les diagrammes
de cette vue sont le diagramme de cas d’utilisation et le diagramme de package.
 Vue Logique : décrit le système de façon statique et dynamique en termes de classe et
d’objets.
 Vue de processus : décrit la synchronisation et les interactions entres les taches. Cette
vue présente le diagramme de séquence, le diagramme d’activité et le diagramme de
collaboration
 Vue de composants : permet de visualiser l’organisation des composants, elle présente
les diagrammes de composants et diagramme de structure composite
 Vue de déploiement : représente le système dans son environnement d'exécution.
Cette vue est fort utile pour l'installation et la maintenance régulière du système. Elle
présente le diagramme de déploiement
Figure 8 : Les vues UML

Raafa Amri
2.5 Environnement de développement

On désigne par environnement de développement toutes les plateformes, les technologies
et les logiciels utilisés.
2.5.1 Environnement technique
Dans notre projet, nous avons travaillé sur deux parties : une partie Back-end invisible
pour l’utilisateur de l’application où on trouve un serveur web et la base de données et une
partie Front-end qui contient des interfaces et des éléments que l’utilisateur peut interagir
avec eux.
En effet, nous allons faire une petite étude des langages de programmation pour bien
choisir notre environnement. Le graphe de la figure 9 représente une classification des
langages de programmation pour l’année 2019 [4].
Figure 9 : Etude des langages de développement
D’après le classement précédant, nous allons remarquer l’importance des langages

JavaScript pour des projets Web et le java pour le développement Mobile, Cloud, Desktop et
IoT, etc. En effet, dans notre projet nous avons utilisées l’environnement suivant :

Raafa Amri
 Spring Boot :
C’est l’un des framework les plus répandus dans le monde Java : sa popularité a grandie
au profit de la complexité de Java EE notamment pour ses versions antérieures à la version 5
mais aussi grâce à la qualité et la richesse des fonctionnalités qu'il propose :
Le but de Spring est de faciliter et de rendre productif le développement d'applications,

particulièrement les applications d'entreprises.
Spring propose de nombreuses fonctionnalités de base pour le développement

d'applications :
o un conteneur léger implémentant le design pattern IoC pour la gestion des objets et de
leurs dépendances en offrant des fonctionnalités avancées concernant la configuration
et l'injection automatique. Un de ses points forts est d'être non intrusif dans le code de
l'application tout en permettant l'assemblage d'objets faiblement couplés.
o une gestion des transactions par déclaration offrant une abstraction du gestionnaire de
transactions sous-jacent
o faciliter le développement des DAO de la couche de persistance en utilisant JDBC,
JPA, JDO ou une solution open source comme Hibernate, iBatis, ... et une hiérarchie
d'exceptions
o un support pour un usage interne à Spring (notamment dans les transactions) ou
personnalisé de l'AOP qui peut être mis en oeuvre avec Spring AOP pour les objets
gérés par le conteneur et/ou avec AspectJ
o faciliter la testabilité de l'application [5].
 Spring Security :
Spring Security est un cadre d'authentification et de contrôle d'accès puissant et hautement

personnalisable. Il s'agit de la norme de facto pour la sécurisation des applications basées sur
Spring.
Spring Security est un cadre qui vise à fournir à la fois l'authentification et l'autorisation
aux applications Java. Comme tous les projets Spring, la véritable puissance de Spring
Security réside dans sa facilité d'extension à des exigences personnalisées. Il est caracterisé
par :

Raafa Amri
o Prise en charge complète et extensible pour l'authentification et l'autorisation

o Protection contre les attaques telles que la fixation de session, le détournement de
clics, la falsification de demandes intersites, etc.
o Intégration de l'API Servlet
o Intégration optionnelle avec Spring Web MVC [6].
 Angular :
Angular est un Framework open source écrit en JavaScript qui permet la création
d’applications Web et plus particulièrement de ce qu’on appelle des « Single Page
Applications » : des applications web accessibles via une page web unique qui permet de
fluidifier l’expérience utilisateur et d’éviter les chargements de pages à chaque nouvelle
action. Le Framework est basé sur une architecture du type MVC et permet donc de séparer
les données, le visuel et les actions pour une meilleure gestion des responsabilités. Un type
d’architecture qui a largement fait ses preuves et qui permet une forte maintenabilité et une
amélioration du travail collaboratif.
le Framework s’appuie sur Typescript, une surcouche au JavaScript développé

par Microsoft, qui est un langage typé qui permet de créer des classes, des variables et des
signatures de fonction. Et s’il est parfaitement possible d’utiliser du JavaScript natif avec
Angular, l’utilisation de Typescript permet de mieux gérer les erreurs, d’avoir un code plus
clair et aussi d’assurer une transition plus simple pour les développeurs PHP, Java ou
encore C# [7].
 Ionic :
Ionic Framework est une boîte à outils d'interface utilisateur mobile open source pour la
création d'expériences natives et d'applications Web multiplateformes de haute qualité.
Déplacez-vous plus rapidement avec une seule base de code, en cours d'exécution partout.
Gratuit et open source, Ionic propose une bibliothèque de composants d'interface

utilisateur optimisés pour les mobiles, de gestes et d'outils pour créer des applications rapides
et hautement interactives.
Ionic Framework est un mélange d’outils et de technos pour développer des applications
mobiles hybrides rapidement et facilement. Il s’appuie sur AngularJS pour la partie
application web du framework et sur Cordova pour la partie construction des applications

Raafa Amri
natives. Ce framework open source permet de développer une application déployable sur
plusieurs environnements tel qu’un site web ou une application mobile pour des systèmes tel
que Android ou iOS ou Windows Phone [8].
 Bootstrap :
Bootstrap, un framework CSS, fait partie de ces outils qui accélèrent grandement un projet
web. Il étend les possibilités du langage CSS en ajoutant plein de fonctionnalités et de
composants. Je dirais plutôt, on peut avoir le même résultat que du CSS en utilisant seulement
Bootstrap. Même si c’est un framework CSS, il ajoute également un plus au HTML et au
Javascript. [9]
 Postgresql :
PostgreSQL est un système de gestion de base de données relationnelle orienté objet

puissant et open source qui est capable de prendre en charge en toute sécurité les charges de
travail de données les plus complexes. Alors que MySQL donne la priorité à l'évolutivité et
aux performances, Postgres donne la priorité à la conformité et à l'extensibilité SQL.
Contrairement aux autres bases de données transactionnelles, PostgreSQL est implémenté

sur un seul serveur et n'est généralement pas conçu pour distribuer ses fonctions de stockage
ou de calcul sur plusieurs nœuds. Bien qu'il soit possible d'utiliser des techniques de
regroupement, de réplication et de mutualisation pour faire évoluer votre cluster Postgres en
termes de performances et de capacité supplémentaire, ces solutions sont complexes et peu
courantes. De nombreuses entreprises choisissent d'augmenter la taille de Postgres en adaptant
verticalement la base de données, ce qui implique l'achat d'un serveur plus grand et plus
puissant.
Postgres est classé comme un système de gestion de base de données relationnelle-objet

(ORDBMS). Cela signifie que contrairement aux systèmes traditionnels de gestion de bases
de données relationnelles (SGBDR), Postgres possède une architecture orientée objet [10].
 Business Intelligence (BI) :
Le terme Business Intelligence (BI), ou informatique décisionnelle, désigne les

applications, les infrastructures, les outils et les pratiques offrant l’accès à l’information, et
permettant d’analyser l’information pour améliorer et optimiser les décisions et les

Raafa Amri
performances d’une entreprise. En d’autres termes, la Business Intelligence est le processus

d’analyse de données dirigé par la technologie dans le but de déceler des informations
utilisables pour aider les dirigeants d’entreprises et autres utilisateurs finaux à prendre des
décisions plus informées.
la BI regroupe une large variété d’outils, d’applications et de méthodologies permettant de

collecter des données en provenance de systèmes internes et de sources externes, de les
préparer pour l’analyse, de les développer et de lancer des requêtes au sein de ces ensembles
de données. Ces outils permettent ensuite de créer des rapports, des tableaux de bord et des
visualisations de données pour rendre les résultats des analyses disponibles pour les preneurs
de décisions. Elles sont affichées sous des formes de tableaux ou de graphiques qui apportent
une hiérarchisation [11].
 FireBase :
C’est le nom d’une platforme mobile de Google qui permet de développer rapidement des
applications pour le web et pour le mobile
Firebase est un ensemble de services d'hébergement pour n'importe quel type d'application
(Android, iOS, Javascript, Node.js, Java, Unity, PHP, C++ ...). Il propose d'héberger en
NoSQL et en temps réel des bases de données, du contenu, de l'authentification sociale
(Google, Facebook, Twitter et Github), et des notifications, ou encore des services, tel que par
exemple un serveur de communication temps réel [12].
 Swagger :
C’est un logiciel open source soutenu par un large écosystème d'outils qui aide les
développeurs à concevoir, construire, documenter et consommer des services Web RESTful .
Alors que la plupart des utilisateurs identifient Swagger par l'outil Swagger UI.
L'utilisation des outils open-source de Swagger peut être divisée en différents cas
d'utilisation: développement, interaction avec les API et documentation [13].

Raafa Amri
2.5.2 Environnement logiciel
Nous avons utilisées pour notre projet plusieurs outils et logiciels tels que :
 Gliffy diagram :
C’est un logiciel de création de diagrammes via une application cloud HTML5. Il est
utilisé pour créer des diagrammes UML et d’autres types de diagrammes en ligne. Les
diagrammes Gliffy peuvent être partagés et modifiés par les utilisateurs en temps réel.
 IntelliJ IDEA :
C’est un environnement de développement intégré spécialisé dans le langage Java. Il

fournit une pléthore d'outils vous permettant de développer vos applications Java, et ce, sur
plusieurs plateformes y compris mobiles.
 Visual Studio Code :
C’est un éditeur de code source développé par Microsoft pour Windows, Linux et macOS.
Il inclut la prise en charge du débogage, du contrôle Git intégré et de GitHub, de la mise en
évidence de la syntaxe, de l'achèvement intelligent du code, des extraits de code et de la
refactorisation du code.
Conclusion
Dans ce chapitre, nous avons présenté les besoins fonctionnels de notre projet afin
d’avoir une vision et une démarche plus claire des tâches à réaliser.

Raafa Amri
Chapitre 3
Release 1 : Gestion d’hébergement

Raafa Amri
Chapitre 3 : Release 1 « Gestion

d’hébergement »
Introduction
L’objectif de ce chapitre est de fournir une version livrable de notre premier release
qui sera composée en des sprints, chaque sprint présente un ensemble de fonctionnalités à
traiter pour produire à la fin un incrément livrable.
3.1 Premier Sprint

C’est un bloc de temps ou le livrable du produit sera réalisé. Tous les sprints d’un
release ont une durée constante. Un sprint ne peut pas démarrer que le précédent est déjà
terminé. Avant de commencer un sprint, l’équipe Scrum définit le but de ce dernier. Ce but
doit être défini en terme métier et non pas en terme technique pour qu’il soit compréhensible
par les membres en dehors de l’équipe. Il s’agit de répondre à une question fondamentale
« pourquoi faisons-nous ce sprint ? ».
Suite à une conversation entre le Product Owner et l’équipe Scrum, nous avons décidé
que le but du premier sprint est de réaliser le module d’authentification des utilisateurs et leurs
rôles et le module d’hébergement (gestion des blocs et des chambres). Une fois le but est
définit, il faut donc préciser les tâches du backlog du sprint.
Tableau 5 : Tâches du premier sprint
Numéro Tâches
1 S’authentifier
2 Ajouter bloc
3 Ajouter chambre
4 Générer un qrcode chambre
5 Télécharger qrcode
6 Modifier chambre
7 Rechercher chambre
8 Mettre chambre hors service

Raafa Amri
Dans un sprint, on doit achever les quatre activités principales d’un projet : la
spécification fonctionnelle, la conception, le déploiement et le test.
3.1.1 Spécifications fonctionnelles
Cette section présente une description textuelle des scénarios ainsi que le diagramme de
cas d’utilisation général.
3.1.1.1. Diagramme de cas d’utilisation
Un cas d'utilisation est une unité cohérente représentant une fonctionnalité visible de
l'extérieur. Il réalise un service avec un déclenchement, un déroulement et une fin, pour
l'acteur qui l'initie.
Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le
mode de réalisation de ce service.
La figure 10 présente le diagramme de cas d’utilisation du premier sprint.

Raafa Amri
Figure 10 : Diagramme de cas d'utilisation sprint 1
3.1.1.2. Description textuelle
Pour que notre diagramme soit plus clair, nous avons proposé une description textuelle
de quelques cas d’utilisation. Le tableau 6 présente une description détaillée du cas
d’utilisation « ajouter chambre ».
Tableau 6 : Description textuelle du cas «ajouter chambre»
Cas d’utilisation : Ajouter chambre

Pré condition: L’utilisateur est authentifié
Post condition: La liste des chambres est affichée
Scenario Nominal
1. L’utilisateur remplit le formulaire d’ajout
2. Le système génère un QR code
3. L’utilisateur télécharge le QR code

Raafa Amri
4. L’utilisateur enregistre les données saisies

5. Le système confirme l’ajout
Scénario Alternatif
E1 : Erreur de connexion
E2 : Des données mal saisies
3.1.2 Diagramme de classes
Le diagramme de classes est un schéma utilisé pour présenter les classes et

les interfaces ainsi que les différentes relations entre eux dans un système. C’est un
diagramme de la partie statique de l’UML qui décrit le comportement et le type d'un ensemble
d'objets. La figure 11 présente le diagramme de classes du sprint 1.
Figure 11: Diagramme de classes du Sprint 1

Raafa Amri
3.1.3 Diagramme de séquence
Le diagramme de séquence permet de présenter les interactions entre acteurs et un

système d'un scénario d'un cas d'utilisation. Nous allons présenter dans ce qui suit les
diagrammes de séquence les plus importants du premier sprint.
3.1.3.1 Diagramme de séquence « s’authentifier »
La figure 12 représente le diagramme d’authentification d’un utilisateur qui est un agent

administratif.
Le système affiche le formulaire d’authentification, dans ce cas, l’utilisateur saisie son

login et son mot de passe. Le système valide les champs et les envoie vers le serveur qui se
charge de vérifier les identifiants. Si les champs sont valides, le serveur envoie une requête à
la base de données qui se charge de la vérification des données et renvoie un résultat au
serveur. Si les données sont correctes, l’utilisateur est redirigé vers son espace, sinon un
message d’erreur est affiché

Raafa Amri
Figure 12 : Digramme de séquence «authentification »
3.1.3.2 Diagramme de séquence « Ajouter chambre »
Pour ajouter une nouvelle chambre, il faut accéder à la liste des chambres et cliquer sur le
bouton d’ajout, dans ce cas le système affiche le formulaire d’ajout.
L’utilisateur doit remplir les champs de données en choisissant le bloc ou on veut ajouter
cette chambre. Après la saisie des données, l’utilisateur clique sur le bouton qui permet de
générer un QR code, le système se charge de crypter les données pour générer et afficher le
QR code, puis l’utilisateur peut télécharger le code pour des futures utilisations et à la fin il
enregistre les données.
Si les champs sont valides, le serveur envoie une requête à la base de données qui se
charge d’enregistrer les données et renvoie un résultat de succès.

Raafa Amri
Figure 13 : Diagramme de séquence "ajouter chambre"
3.1.4 Revue du Sprint
Le but de la revue est de présenter le travail réalisé pendant le sprint 1. A travers cette
section, nous allons présenter des interfaces administratives réalisées dans ce Sprint.
La figure 14 montre l’interface d’authentification d’un agent administratif.

Raafa Amri
Figure 14: Interface « Authentification »
La figure 14 représente l’interface d’authentification permettant aux utilisateurs de se

connecter à leurs espaces respectifs. Après la connexion de l’administrateur, il sera redirigé
vers son espace pour gérer les différentes particularités du système. Prenons l’exemple de la
gestion des chambres comme montre la figure ci-dessous.
Figure 15 : Liste des chambres selon les blocs

Raafa Amri
La figure 15 montre la liste des blocs existants, le bouton en haut « ajouter bloc »
permet d’ajouter un nouveau bloc, chaque bloc contient un bouton pour afficher la liste des
chambres propres à lui.
Le tableau des chambres montre deux types de lignes, la ligne en blanc c’est une
chambre vide c’est à dire une chambre non réservée qu’on peut la modifier ou la mettre hors
service. La ligne en gris c’est une chambre réservée qu’on ne peut pas ni la modifier ni la
mettre hors service sauf si quelle rentre à son état non réservé.
Pour ajouter une chambre, on peut accéder à cette interface pour remplir les champs
des données et créer un code et le télécharger.
Figure 16 : Interface d'ajout chambre

Raafa Amri
3.1.5 Rétrospective
Dans cette partie, nous allons citer les différentes rétrospectives dégagées par le Product
Owner.
Ce qui a été validé :
 Authentification
 Ajouter Bloque
 CRUD chambre
 Création de QR Code
 Téléchargement du QR Code
 Trouver les chambres par Bloc avec un état de réservation
Ce qui n’a pas été validé : Rien
Ce qui doit être amélioré : Rien
3.2 Deuxième sprint

Nous commençons à définir le but de deuxième sprint, nous avons décidé de terminer la
partie qui concerne la réservation. Une fois le but est défini, il faut donc définir les histoires
qui sont inclus. Nous présentons les tâches du backlog de notre sprint dans le tableau 7.
Tableau 7 : Les tâches du deuxième sprint
Numéro Tâches
1 Récupérer les chambres non réservées
Récupérer les types des clients
2 Gérer Réservation (réserver, consulter, modifier,
chercher)
3 Envoyer email au client concerné
4 Gérer clients (modifier, chercher)
5 Récupérer les réservation du jour
6 Activer réservation

Raafa Amri
Récupérer les chambres non réservées

1
Récupérer les types des clients existants
2 Gérer Réservation (réserver, consulter, modifier,

chercher)
3 Envoyer email au client concerné
4 Gérer clients (modifier, chercher)
5 Récupérer les réservations de la journée
6 Activer une réservation
3.2.1.1 Diagramme de cas d’utilisation
Dans cette section, nous avons présenté le diagramme de cas d’utilisation du sprint 2
présenté par la figure suivante.

Raafa Amri
Figure 17 : Diagramme de cas d'utilisation du sprint 2
3.2.1.2 Description textuelle
Dans cette section, nous allons présenter quelques descriptions textuelles de quelques
cas d’utilisation.
 Description textuelle du cas d’utilisation « ajouter réservation »
Le tableau 8 présente une description détaillée du cas d’utilisation « ajouter

réservation ».

Raafa Amri
Tableau 8 : Description textuelle du cas « ajouter réservation »
Cas d’utilisation : ajouter réservation

Pré condition : L’utilisateur est authentifié, chambre existante
Post condition :
Réservation effectuée
Email envoyé, client crée, type crée
Scenario Nominal
1. Récupération des chambres vides, et des types de clients
2. L’utilisateur remplit le formulaire de réservation
3. L’utilisateur enregistre la réservation
4. Un client est crée
5. L’email est envoyé
6. Le système confirme la réservation
E1 Erreur de connexion
E2 Des données mal saisies
E3 Toutes les chambres sont réservées
 Description textuelle du cas d’utilisation « activer une réservations »
Le tableau 9 présente une description détaillée du cas d’utilisation « activer une

réservation ».
Tableau 9 : Description textuelle du cas « activer une réservation »
Cas d’utilisation : activer réservation

Pré condition L’utilisateur est authentifié
Post condition Réservation activée
Scenario Nominal
1. L’utilisateur demande la liste des réservations du jour courant

Raafa Amri
2. Le système affiche la liste

3. L’utilisateur choisit la réservation concernée et il l’active
4. La réservation est activée
E2 Des données mal saisies
 Description textuelle du cas d’utilisation « modifier client »
Le tableau 10 présente une description détaillée du cas d’utilisation « modifier client ».
Tableau 10 : Description textuelle du cas « modifier client »
Cas d’utilisation : modifier client

Pré condition : L’utilisateur est authentifié et le client existant
Post condition : Client modifié
Scenario Nominal
1. L’utilisateur demande la liste des clients
2. Le système affiche la liste
3. L’utilisateur choisit l’option modifier
4. Le système affiche un formulaire
5. L’utilisateur saisit les champs à modifier
6. Le système affiche un message de succès
E1 Le système affiche un message d'erreur indiquant qu’un des champs est invalide
La figure 18 présente le diagramme de classes du sprint 2.

Raafa Amri
Figure 18 : Diagramme de classes sprint 2
En se basant aux descriptions textuelles, nous présentons les diagrammes de séquence

suivants.
 Diagramme de séquence « réserver chambre »

Raafa Amri
Figure 19 : Diagramme de séquence « réserver chambre »
Afin de réserver une chambre, l’agent administratif doit se connecter tout d’abord puis il
demande d’ajouter une réservation, dans ce cas le système se charge de récupérer les
chambres non réservées ainsi que les types des clients de sa base de données, le formulaire
d’ajout est donc affiché, l’utilisateur remplit les champs et les envoie. Avec l’ajout de la
réservation, un email qui contient un login et un mot de passe, est envoyé au client concerné
pour qu’il puisse accéder à son espace personnel depuis une application mobile tout au long
de sa période d’hébergement. Si la réservation est effectuée, un message de succès est affiche
à l’utilisateur.
 Diagramme de séquence « modifier client »

Raafa Amri
Figure 20 : Diagramme de séquence « modifier client »
Pour modifier les données d’un client, l’utilisateur demande la liste des clients, la liste
sera affichée depuis le système. Dans ce cas, l’utilisateur cherche le client qu’il veut pour le
modifier, le système lui affiche le formulaire de modification, il faire les modifications
désirées et l’enregistre. Une requête d’enregistrement sera traitée et un message de succès est
affiché.

Raafa Amri
3.2.4 Revue du sprint
Le but cette section est de montrer le travail réalisé pendant le sprint 2. Les figures ci-
dessous présentes des interfaces administratives produites dans ce sprint.
 Interface de gestion des réservations
Figure 21 : Interface de la gestion des réservations
La figure 21 montre la liste des réservations effectuées avec la possibilité de chercher

une réservation, la buttons « réservation du jour » affiche les réservations du courante ou on
peut activer ou annuler une réservation comme la montre la figure 22.
 Interface des réservations de la date courante

Raafa Amri
Figure 22: interface des réservations de la date courante
Pour afficher les réservations du jour, nous pouvons accéder à cette liste en cliquant sur le
bouton « les réservation du jour » ou on peut activer une réservation dans le cas où le client
est présent.
 Interface d’ajout d’une nouvelle réservation
Figure 23 : Interface réservation chambre
Pour ajouter une nouvelle réservation, on peut accéder au formulaire de la figure suivante,
l’enregistrement de ce formulaire créer à la fois une nouvelle réservation et un nouveau client.

Raafa Amri
3.2.5 Rétrospective
Dans cette partie, nous allons va citer les différentes rétrospectives dégagées par le
Product Owner,
Ce qui a été validé :
 CRUD Réservation
 CRUD client
 Service de mailing
 Activer Réservation
 Trouver les réservations de chaque jour
 Ajouter type_client
Ce qui n’a pas été validé : Rien
Ce qui doit être amélioré : Rien
Conclusion
A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de

valeur, cet incrément s’occupe de toutes les particularités liées au module d’hébergement.
Dans le chapitre qui suit, notre travail sera consacré pour produire le deuxième release ou
nous allons trouver l’intervention du client et son interaction avec la partie administration.

Raafa Amri
Chapitre IV
Release 2 : Gestion des Réclamations
Chapitre 4 : Release 2 « Gestion des

Réclamations »

Raafa Amri
Introduction
Une méthodologie Scrum est caractérisée par son rythme régulier, c’est pourquoi nous
pouvons lancer le deuxième release. Durant ce chapitre, nous avons deux sprints à traiter pour
avoir à la fin notre solution complète.
4.1 Premier sprint

C’est le même principe que le release précédent, nous commençons par définir le but du
premier sprint. Après une réunion avec le Product Owner, nous avons décidé de réaliser une
partie mobile qui assure l’intervention d’un client pour les réclamations.
Le tableau 11 résume les tâches de notre sprint.
Tableau 11 : Les tâches du premier sprint
Numéro Tâches
1 Authentification
2 Scanner le qr_code de la
chambre
3 Envoyer une réclamation
4 Lister les réclamations et traiter
les réclamations
5 Recevoir une notification
Nous pouvons traduire les spécifications fonctionnelles de notre sprint à l’aide d’un
diagramme du cas d’utilisation et des descriptions textuelles.
4.1.1.1 Diagrammes du cas d’utilisation
Les fonctionnalités relatives dans ce sprint vont être reparties suivant deux acteurs, un
client et un agent administratif.
La figure 25 présente le diagramme du cas d’utilisation du premier sprint du second

release.

Raafa Amri
Figure 24 : Diagramme du cas d'utilisation du premier sprint
4.1.1.2 Description textuelle
 Description textuelle du cas d’utilisation « envoyer réclamation»
Le tableau 12 représente une description détaillée du cas d’utilisation « envoyer réclamation »
Tableau 12 : Description textuelle du cas d'utilisation « envoyer réclamation »

Raafa Amri
Cas d’utilisation : Envoyer réclamation

Pré condition: Le client est authentifié, le code est scanner
Post condition: La réclamation est envoyée
Scenario Nominal
6. Le client scanne le qr code de la chambre.
7. Le système affiche un formulaire de réclamation qui contient le résultat du scan.
8. Le client remplit le formulaire et l’envoyer.
9. Le système valide l’envoi.
E1: Erreur de connexion.
E2: Problème pendant le scan du code.
 Description textuelle du cas d’utilisation « gérer réclamation»
Le tableau 13 représente une description détaillée du cas d’utilisation « gérer réclamation »
Tableau 13 : Description textuelle du cas d'utilisation « gérer réclamation »
Cas d’utilisation : Gérer réclamation

Pré condition : L’agent administratif est authentifié, réclamation existante
Post condition : Le client est notifié
Scenario Nominal
1. L’agent administratif demande la liste des réclamations
2. Le système affiche la liste des réclamations
3. L’agent administratif sélectionne une réclamation
4. Le système lui affiche les détails
5. L’agent valide la réclamation
E1 : Erreur de connexion
E2 : Aucune réclamation

Raafa Amri
La figure 26 présente le diagramme de classes du premier sprint.
Figure 25 : Diagramme de classes du Sprint 1
La figure 27 présente le diagramme de séquence pour le cas d’utilisation « envoyer

réclamation ».

Raafa Amri
Figure 26 : Diagramme de séquence « envoyer réclamation »
Dans cette section, nous allons présenter quelques interfaces réalisées durant ce sprint.
La figure 28 présente l’interface mobile de l’authentification ainsi que celle du page

d’accueil pour les clients.
 Interfaces d’application mobile

Raafa Amri
Figure 27 : Interfaces d’authentification et d’accueil
Lors d’une réservation, un client reçoit un login et un mot de passe via son email d’où il
peut accéder à l’application mobile pour intervenir en cas de réclamation.
Après avoir connecté, une interface d’accueil est affichée pour scanner un QR code de la
chambre et envoyer une réclamation.
 Interface de gestion des réclamations avec une notification

Raafa Amri
Figure 28 : Interface de réclamation avec notification en temps réel
Suite à l’envoi d’une réclamation de la part du client (application mobile), l’agent

administratif reçoit une notification en temps réel pour lui informer qu’une nouvelle
réclamation vient d’être ajoutée.
4.1.5 Système de notification utilisé
Pour gérer la notification dans notre application, nous avons utilisé le service de Google
FCM (Firebase Cloud Messenging).
4.1.5.1 Définition du FCM
Le Firebase Cloud Messaging (FCM) est un service de Google permettant l’envoi de

notifications Push à des terminaux. Il est supporté par les applications client iOS, Android ou
Web (JavaScript).
Une notification push est un message envoyé à l’utilisateur, ce message est lié à une
application installée. L’avantage de la notification push c’est que le message est reçu par
l’utilisateur même si l’application est fermée.
Pour bénéficier d’un service FCM, il faut tout d’abord enregistrer les appareils pour
recevoir des messages de FCM. Une instance d'une application cliente s'inscrit pour recevoir

Raafa Amri
des messages, en obtenant un jeton d'enregistrement qui identifie de manière unique

l'instance de l’application.
4.1.5.2 Architecture technique
La figure 29 représente l’architecture technique du FCM. En effet, cette architecture se

repose sur quatre phases.
 Création : Le message est composé, soit dans le compositeur de notifications, soit

dans un environnement approuvé, et une demande de message est envoyée au serveur.
 Envoi : Le serveur principal FCM reçoit la demande de message, génère un ID de
message et d'autres métadonnées et l'envoie à la couche de transport spécifique à la
plateforme.
 Transmission : Une couche de transport au niveau de la plateforme, qui achemine le
message vers le périphérique cible, gère la remise des messages et applique la
configuration spécifique à la plateforme
 Réception : Sur l'appareil, l'application cliente reçoit le message ou la notification.
Figure 29 : Architecture technique du FCM
4.1.5.3 Fonctionnement de l’envoi d’une notification avec FCM

Raafa Amri
La figure 30 représente le fonctionnement du service du FCM.
Figure 30 : Fonctionnement du FCM
1. À chaque ouverture de l’application, elle demande un identifiant unique

« TOKEN » à FCM pour identifier l’application sur un appareil,
2. Envoi du TOKEN de FCM à l’application,
3. Transmission du TOKEN au serveur d’envoi qui va être stocké (ou rafraîchi) dans
une base de données,
4. Pour l’envoi d’une notification push, le serveur d’envoi transmet la notification

push à FCM. Pour cela il indique l’identifiant concerné et le message associé,
5. FCM vérifie les paramètres push (autorisations et identité de l’application) et

transmet la notification à l’appareil ciblé,
6. FCM envoie immédiatement un rapport de réception des notifications pour mettre

la base d’identifiants à jour (selon les désinstallations et la désactivation des notifications),
4.2 Deuxième sprint

Raafa Amri
Le but de cette revue est de montrer ce qui a été réalisé pendant le sprint 2 du deuxième
release. Cette partie présente un tableau de bord qui montre quelques statistiques de notre
projet. La figure 31 représente un exemple de ce qui a été réalisé, elle est composée en quatre
parties :
 Une visualisation pour le nombre de réservation en mois de Juillet.

 Une visualisation pour le nombre de chambres réservées en mois de Juillet.
 Une visualisation pour la répartition des clients suivant leurs villes d’origine.
 Une visualisation qui met en évidence le nombre des chambres réservées par rapport
aux chambres vides.
Figure 31 : Le rapport BI
4.2.2 Présentation du Power BI

Raafa Amri
C’est une collection de services logiciels, d'applications et de connecteurs qui fonctionnent

ensemble pour transformer vos sources de données indépendantes en informations cohérentes,
visuellement immersives et interactives.
Power BI permet de se connecter facilement aux sources de données, de visualiser et de

découvrir ce qui est important et de le partager avec quiconque ou tout le monde.
4.2.3 L’architecture de Power BI
Power BI comprend :
 Une application de bureau Windows appelée Power BI Desktop.

 Un service SaaS (Software as a Service) en ligne appelé service Power BI.
 Applications mobiles Power BI pour les appareils Windows, iOS et Android.
Figure 32 : Les composants de Power BI
Ces trois éléments sont conçus pour permettre de créer, partager et utiliser des
informations de la manière qui sert le mieux.
Un quatrième élément, Power BI Report Server, nous permet de publier des rapports
Power BI sur un serveur de rapports local, après les avoir créés dans Power BI Desktop [14].

Raafa Amri
Power BI Report Server est une solution qui permet de déployer derrière nos pare-feu,
puis remettre nos rapports aux bons utilisateurs de différentes manières, que ce soit en les
consultant dans un navigateur Web, sur un appareil mobile ou sous forme d’email
Figure 33 : Les composants de Power BI
Par exemple, on peut utiliser principalement le service Power BI pour voir des rapports et
des tableaux de bord. En revanche, il est préférable d’utiliser Power BI Desktop pour créer
des rapports, avant de les publier sur le service Power BI, où on peut ensuite les consulter. De
l’autre côté, on peut utiliser principalement l’application mobile Power BI pour superviser
l’évolution des ventes et examiner en détail les nouveaux prospects [14].
4.2.4 Les éléments constitutifs de Power BI
Power BI se compose de certains composants clés qui peuvent également être appelés ses
blocs de construction. Les cinq composants clés de Power BI sont les visualisations, les jeux
de données, les rapports, les tableaux de bord et les tuiles.
 Visualisations : La visualisation est la manière graphique de représenter les
données. Power BI offre une large gamme de visualisations attrayantes. Nous pouvons
créer des rapports et des tableaux de bord à l'aide de visualisations simples ou
complexes selon nos besoins. De cette façon, nous représentons graphiquement notre
ensemble de données avec des graphiques, des tableaux et des cartes. Il existe

Raafa Amri
également une bibliothèque disponible dans Power BI pour les visualisations

personnalisées.
 Ensembles de données : un ensemble de données est une collection ou un ensemble de
données collectées à partir de différentes sources de données. Dans Power BI, nous
pouvons nous connecter à différentes sources de données via la fonctionnalité Get Data
et récupérer des données. Il existe de nombreuses sources de données à partir
desquelles nous pouvons obtenir des données et créer un ensemble de données
comme Excel, SQL Server, base de données MySQL, Azure, Text / CSV, Oracle, PDF,
Access, XML, JSON et bien d'autres.
 Rapports : les rapports dans Power BI sont une combinaison ou une collection de
différents types de visualisations pertinentes pour un sujet métier particulier. Un
rapport est une présentation graphique et structurée d'ensembles de données comportant
plusieurs pages. Il a utilisé dans l'analyse. Les rapports sont informatifs et révèlent des
informations importantes à partir des données. Nous pouvons facilement partager et
publier des rapports créés dans Power BI avec d'autres utilisateurs.
 Tableaux de bord : le tableau de bord est une collection de visualisations importantes
extraites d'un rapport. Les tableaux de bord sont une représentation à une seule couche
offrant des informations rapides ou un aperçu des données. Les tableaux de
bord typiques dans Power BI sont composés de plusieurs visualisations sous forme de
tuiles. Ce sont des pages uniques de rapports (donc, une seule couche). Les tableaux de
bord Power BI sont partageables et imprimables.
 Tuiles : une tuile est un bloc unique contenant une visualisation dans un tableau de
bord par rapport Power BI. Les tuiles séparent chaque visualisation informative de
manière distincte pour fournir une vue claire. Ces tuiles peuvent être ajustées ainsi que
sa taille peut être modifiée. De plus, ils peuvent être placés n'importe où sur le tableau
de bord selon la convenance de l'utilisateur [14].
4.2.5 Service Power BI

Raafa Amri
Le service Power BI est un service cloud. Il prend en charge la modification simple de

rapports et la collaboration pour des équipes et des organisations. Vous pouvez vous
connecter également à des sources de données dans le service Power BI, mais la modélisation
est limitée [15].
La plupart des concepteurs de rapports qui travaillent sur des projets d’informatique
décisionnelle utilisent Power BI Desktop pour créer des rapports, puis le service
Power BI pour les distribuer à d’autres personnes.
L’utilisation du service Power BI se fait de la manière suivante, une fois que les rapports
sont créer et enregistrer dans un espace de travail dans le service Power BI, là où vos
collègues peuvent collaborer. Vous générez des tableaux de bord qui s’appuient sur ces
rapports. Vous partagez ensuite ces tableaux de bord et ces rapports avec des consommateurs
de rapports internes et externes à votre organisation. Les consommateurs de vos rapports les
consultent dans le service Power BI en mode Lecture, et non en mode Édition. Ils n’ont pas
accès à toutes les fonctionnalités disponibles pour les auteurs de rapports. Vous pouvez
également partager vos jeux de données et permettre à d’autres utilisateurs de générer leurs
propres rapports à partir de ceux-ci [15].
Figure 34 : Comparaison Power BI

Raafa Amri
Conclusion
Dans ce dernier chapitre, nous avons présenté les deux derniers sprints de notre
application pour arriver à un produit complet et fonctionnel.

Raafa Amri
Conclusion générale
Pour le secteur d’hôtellerie, la gestion de l’ensemble de ses activités se fait

généralement par le biais des applications informatiques. Un hôtel souhaite gérer la totalité
de ses activités autour d’un même système d’information, à l’aide d’un progiciel de gestion
intégrée connu sous l’acronyme ERP.
Pour mettre en œuvre ce projet ERP, nous nous sommes basés sur une étude profonde
sur les différentes solutions existantes dans le domaine d’hôtellerie. Afin de développer notre
solution, qui répond aux exigences des hôtels, nous avons entamé une partie d’analyse afin de
ressortir les besoins des utilisateurs. C’est une étape très importante pour la réussite de tout
projet. C’est pour cela, que nous avons consacré une période importante afin de bien travailler
la spécification et l’analyse des besoins.
Le stage que nous avons effectué au sein de l’entreprise GPRO Consulting est une
occasion pour nous découvrir le monde professionnel, celui de l’entreprise et particulièrement
celui des ERP. En effet, ce projet nous a permis de mettre en pratique les étapes d’un cycle de
vie d’un projet et nous facilite l’intégration dans le domaine professionnel et dans le travail en
groupe.
Nous avons eu l’opportunité de travailler avec de nouveaux logiciels et Framework

tels que SpringBoot, Angular, Ionic, Firebase, Postgresql, Power BI…
Enfin, bien que les objectifs fixés au départ aient été atteints et bien que notre travail
offre plusieurs avantages à l'utilisateur, le projet reste extensible et évolutif et les perspectives
d'amélioration et de développement de ce travail restent multiples. En effet, nous envisageons
d’ajouter des nouvelles fonctionnalités avancées telles que l’intégration d’un module de
facturation et le payement en ligne.

Raafa Amri
Bibliographie
[1] https://www.anthedesign.fr/webdesign-2/pictogramme/ (visité le 02/05/2020)
[3] https://cloud.kapostcontent.net/pub/93f35b9e-ca51-4fc9-8958-ad7cc5ccc289/how-to-
build-and-scal e-with-microservices-french.pdf
[4] https://www.developpez.com/actu/227875/Les-tendances-des-developpeurs-pour-2019-
font-du-Machine-Learning-la-competence-cle-et-du-JavaScript-le-langage-le-plus-populaire-
selon-un-rapport/
[5] https://www.jmdoudoux.fr/java/dej/chap-spring.htm
[6] https://spring.io/projects/spring-security
[7] https://monpetitdev.fr
[8] https://ionicframework.com
[9] https://algocool.fr/bootstrap
[10] https://www.oracle.com/fr/database/definition-postgresql.html
[11] https://www.lebigdata.fr/business-intelligence-definition
[12] https://fr.wikipedia.org/wiki/Firebase
[13] https://en.wikipedia.org/wiki/Swagger_(software)
[14] https://docs.microsoft.com/fr-fr/power-bi/fundamentals/power-bi-overview
[15] https://docs.microsoft.com/fr-fr/power-bi/fundamentals/service-service-vs-desktop

Remerciements: ATROUSSI, Directeur de L'entreprise GPRO - CONSULTING. Un Grand Merci Pour

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Remerciements: ATROUSSI, Directeur de L'entreprise GPRO - CONSULTING. Un Grand Merci Pour

Transféré par

Droits d'auteur :

Formats disponibles

Raafa Amri

Je tiens à remercier mon encadrante académique Mme. SONIA KEFI pour le

Je tiens aussi à remercier mon encadreur professionnel, M. GHAZI

Je profite aussi de ce projet pour exprimer mes remercîments à tous les

Puisse ce modeste travail, puisse satisfaire et témoigner notre gratitude et

Année universitaire : 2019-2020 -i-

Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la reconnaissance…Aussi,

À MES CHERS PARENTS

A Mes sœurs adorées Sana et Ahlem

A Mes frères adorées Anis, Riadh et aymen

A LA MEMOIRE DE MES GRAND-PERES ET MA GRAND-MERE

À MES AMIES DE TOUJOURS Asma, Ikram, Dorra, Ameni

Année universitaire : 2019-2020 -ii-

1. 1 Cadre général du travail..............................................................................3

1. 3 Contexte général et problématique..............................................................4

1. 4 Etude de l’existant ......................................................................................5

1.4.1 CloudHotelErp ......................................................................................5

1.4.2 IT Monteur Hôtel Management Software ..............................................6

1.4.3 HotelFriend ...........................................................................................6

1. 5 Synthèse et critique de l’existant ................................................................7

1. 6 Solution proposée .......................................................................................8

1. 7 Pictogramme de notre solution ...................................................................9

1. 8 Les méthodologies de développement ...................................................... 10

1.8.1 Etude des méthodologies de développement ........................................ 10

1.8.2 La méthodologie adaptée ..................................................................... 11

Chapitre 2 : Sprint 0 « Spécification des besoins » ................................................. 15

2. 1 Capture des besoins .................................................................................. 15

2.1.1 Identification des acteurs ..................................................................... 15

2.1.2 Capture des besoins fonctionnels ......................................................... 16

2.1.3 Capture des besoins non fonctionnels .................................................. 17

2.2 Architecture de l’application .................................................................... 18

2.3 Pilotage du projet avec Scrum .................................................................. 19

2.3.1 Backlog du produit .............................................................................. 19

Année universitaire : 2019-2020 -iii-

2.3.2 Planification des sprints ....................................................................... 20

2.4 Approche conceptuelle associée aux sprints.............................................. 21

2.5 Environnement de développement ............................................................ 22

2.5.1 Environnement technique .................................................................... 22

2.5.2 Environnement logiciel ....................................................................... 27

Chapitre 3 : Release 1 « Gestion d’hébergement » ..................................................... 29

3.1 Premier Sprint .......................................................................................... 29

3.1.1 Spécifications fonctionnelles ............................................................... 30

3.1.2 Diagramme de classes ......................................................................... 32

3.1.3 Diagramme de séquence ......................................................................33

3.1.4 Revue du Sprint ................................................................................... 35

3.2 Deuxième sprint ....................................................................................... 38

3.2.1 Spécifications fonctionnelles ............................................................... 39

3.2.2 Diagramme de classes ......................................................................... 42

3.2.3 Diagramme de séquence ......................................................................43

3.2.4 Revue du sprint ................................................................................... 46

Chapitre 4 : Release 2 « Gestion des Réclamations » ................................................. 49

4.1 Premier sprint ............................................................................................... 50

4.1.1 Spécifications fonctionnelles ............................................................... 50

4.1.2 Diagramme de classes ......................................................................... 52

4.1.3 Diagramme de séquence ......................................................................53

4.1.4 Revue du sprint ................................................................................... 54

Année universitaire : 2019-2020 -iv-

4.1.5 Système de notification utilisé ............................................................. 56

4.2 Deuxième sprint ....................................................................................... 58

4.2.1 Revue du sprint ................................................................................... 59

4.2.2 Présentation du Power BI .................................................................... 59

4.2.3 L’architecture de Power BI .................................................................. 60

4.2.4 Les éléments constitutifs de Power BI ................................................. 61