KR VF

Table des matières
Introduction Générale ........................................................................................................................... 1

Chapitre 1 : Présentation du cadre général du projet ....................................................................... 2
Introduction ........................................................................................................................................... 2
1. Présentation du projet................................................................................................................... 2
1.1 Idée du projet ......................................................................................................................... 2
1.2 Choix du nom et logo de l’application ................................................................................. 2
1.3 Problématique........................................................................................................................ 3
1.4 La mission du projet.............................................................................................................. 3
2. Benchmarking................................................................................................................................ 4
2.1 Analyse des concurrents........................................................................................................ 4
2.2 Critique de l’existant ............................................................................................................. 6
3. Solution proposée et objectifs poursuivis .................................................................................... 7
4. Analyse SOAR ............................................................................................................................... 8
5. Choix de la méthodologie de travail............................................................................................. 8
5.1 Méthodologie prédictive........................................................................................................ 9
5.2 Méthodologie adaptative ..................................................................................................... 10
5.3 Méthodologie hybride ......................................................................................................... 10
6. Méthodologie de travail adoptée : Agile - Scrum ..................................................................... 11
Conclusion ............................................................................................................................................ 13
Chapitre 2 : Spécification des besoins et Backlog produit ............................................................... 14
Introduction ......................................................................................................................................... 14
1. Capture des besoins ..................................................................................................................... 14
1.1 Identification des acteurs .................................................................................................... 14
1.2 Spécification des besoins ..................................................................................................... 15
1.2.1 Exigences fonctionnelles .............................................................................................. 15
1.2.2 Exigences non fonctionnelles ...................................................................................... 16
2. Spécification technique ............................................................................................................... 16
2.1 Outils utilisés ........................................................................................................................ 16
2.2 Pattern Architectural .......................................................................................................... 17
3. Spécification des exigences.......................................................................................................... 18
3.1 Diagramme de classe ........................................................................................................... 18
3.2 Diagramme de cas d’utilisation .......................................................................................... 20
4. Planification du traitement des cas d’utilisation ...................................................................... 20
4.1 Définition .............................................................................................................................. 21
4.2 Tableau Backlog produit du Medina Explorer................................................................. 21
4.3 Définition des rôles du Scrum ............................................................................................ 23
4.4 Structure et découpage du projet ....................................................................................... 23
5. Le business model CANVAS ...................................................................................................... 24
Conclusion ............................................................................................................................................ 25
Chapitre 3 : Sprints 1&2..................................................................................................................... 26
Introduction ......................................................................................................................................... 26
Partie 1 : Premier Sprint .................................................................................................................... 26
1. Présentation du premier sprint .................................................................................................. 26
2. Etude et conception des cas d’utilisation du sprint (1)............................................................. 28
2.1 Cas d’utilisation « S’inscrire » ........................................................................................... 29
2.1.1 Description textuelle des scénarios du cas d'utilisation « S'inscrire » .................... 29
2.1.2 Diagramme de séquence système du cas d'utilisation « S'inscrire » ....................... 29
2.2 Cas d’utilisation « S’authentifier » .................................................................................... 30
2.2.1 Description textuelle des scénarios du cas d'utilisation « S’authentifier » ............. 30
2.2.2 Diagramme de séquence système du cas d’utilisation « S’authentifier » ............... 31
2.3 Cas d’utilisation « Gestion de profil utilisateur » ............................................................. 32
2.3.1 Description textuelle des scénarios du cas d'utilisation « Gestion du profil
utilisateur » ..................................................................................................................................... 32
2.3.2 Diagramme de séquence système du cas d'utilisation « Gestion du profil
utilisateur » ..................................................................................................................................... 33
2.4 Cas d’utilisation « Consultation des espaces publics » ..................................................... 33
2.4.1 Description textuelle des scénarios du cas d'utilisation « Consultation des espaces
publics »…....................................................................................................................................... 33
2.4.2 Diagramme de séquence système du cas d’utilisation « Consultation des espaces
publics »…....................................................................................................................................... 34
3. Réalisation du Sprint (1) ............................................................................................................. 35
4. Rétrospective du Sprint (1) ......................................................................................................... 36
Partie 2 : Deuxième Sprint ................................................................................................................. 37
1. Présentation du deuxième sprint ................................................................................................ 37
2. Analyse et conception des cas d’utilisation du sprint (2) ......................................................... 38
2.1 Cas d’utilisation « Consultation des plans guidés ».......................................................... 38
2.1.1 Description textuelle des scénarios du cas d'utilisation « Consultation des plans
guidés »…. ....................................................................................................................................... 38
2.1.2 Diagramme de séquence système du cas d'utilisation « Consultation des plans
guidés »….. ...................................................................................................................................... 39
2.2 Cas d’utilisation « Donner un avis » .................................................................................. 40
2.2.1 Description textuelle des scénarios du cas d’utilisation « Donner un avis » .......... 40
2.2.2 Diagramme de séquence système du cas d’utilisation « Donner un avis » ............. 40
2.3 Cas d’utilisation « Envoyer un message » ......................................................................... 41
2.3.1 Description textuelle des scénarios du cas d’utilisation « Envoyer un message ».. 41
2.3.2 Diagramme de séquence système du cas d’utilisation « Envoyer un message » .... 42
Conclusion ............................................................................................................................................ 44
Chapitre 4 : Sprints 3&4..................................................................................................................... 45
Introduction ......................................................................................................................................... 45
Partie 1 : Troisième Sprint ................................................................................................................. 45
2. Analyse et conception des cas d’utilisation du sprint (3) ......................................................... 46
2.1 Cas d’utilisation « Supprimer le compte d’un utilisateur »............................................. 47
2.1.1 Descriptions textuelles des scénarios du cas d’utilisation « Supprimer le compte d’un
utilisateur » ..................................................................................................................................... 47
2.1.2 Diagramme de séquence système du cas d’utilisation « Supprimer le compte d’un
utilisateur » ..................................................................................................................................... 47
2.2. Cas d’utilisation « Gestion des mises à jour de l’application » ............................................ 48
2.2.1 Description textuelle des scenarios du cas d’utilisation « Gestion des mises à jour
de l’application » ............................................................................................................................ 48
2.2.2. Diagrammes de séquence système du cas d’utilisation « Gestion des mises à jour
de l’application » ............................................................................................................................ 50
Partie 2 : Quatrième Sprint ................................................................................................................ 52
1. Présentation du troisième sprint ................................................................................................ 52
2. Analyse des cas d’utilisation du sprint (4) ................................................................................. 53
2.1 Cas d’utilisation « Proposer plans » .................................................................................. 53
2.2 Cas d’utilisation « Prédire plans » ..................................................................................... 54
2.2.1 Définition de l’Intelligence Artificielle ................................................................... 54
2.2.2 Définition de l’analyse sentimentale du texte ......................................................... 54
2.2.3 Traitement des sentiments des avis des utilisateurs par l’apprentissage
automatique ................................................................................................................................... 54
2.2.3.1 Catégorisation automatique du texte ......................................................................... 55
2.2.4 Collecte de la base de données ................................................................................. 57
2.2.5 Nettoyage des données de la base de données ........................................................ 57
2.2.6 Prédiction des plans ................................................................................................... 57
Conclusion ............................................................................................................................................ 58
Conclusion Générale ........................................................................................................................... 59
Webographie ........................................................................................................................................ 60
Annexe .................................................................................................................................................. 61
Liste des figures
Figure 1: Guide touristique privé ............................................................................................................ 4
Figure 2: Page d'accueil du site « Guide voyage Tunisie » ..................................................................... 5
Figure 3: Application mobile "Tunis médina guide"............................................................................... 5
Figure 4: Application « Get your guide » ................................................................................................ 6
Figure 5: Analyse SOAR de notre projet ................................................................................................ 8
Figure 6: Mode de fonctionnement du Scrum ....................................................................................... 12
Figure 7: Architecture MVC ................................................................................................................. 18
Figure 8: Diagramme de classe de "Medina Explorer" ......................................................................... 19
Figure 9: Diagramme de Cas d'utilisation de "Medina Explorer" ......................................................... 20
Figure 10: Backlog produit.................................................................................................................... 22
Figure 11:Business Model CANVAS de Médina Explore .................................................................... 25
Figure 12: Diagramme de cas d'utilisation du sprint (1) ....................................................................... 28
Figure 13: Diagramme de séquence système du cas d’utilisation "S'inscrire" ...................................... 30
Figure 14: Diagramme de séquence système du cas d’utilisation "S'authentifier" ............................... 31
Figure 15: Diagramme de séquence système du cas d’utilisation " Gestion du profil utilisateur" ........ 33
Figure 16: Diagramme de séquence système du cas d’utilisation " Consultation des espaces publics" 34
Figure 17:Diagramme de cas d'utilisation du sprint (2) ........................................................................ 38
Figure 18:Diagramme de séquence système du cas d’utilisation " Consultation des plans guidés" ..... 39
Figure 19:Diagramme de séquence système du cas d’utilisation " Donner un avis" ............................ 41
Figure 20:Diagramme de séquence système du cas d’utilisation " Envoyer un message" .................... 42
Figure 21: Le diagramme de cas d'utilisation du sprint (3) ................................................................... 46
Figure 22: Diagramme de séquence système du cas d’utilisation "Supprimer le compte d'un utilisateur"
............................................................................................................................................................... 48
Figure 23:Diagramme de séquence système du cas d’utilisation "Ajouter un espace public" .............. 50
Figure 24:Diagramme de séquence système du cas d’utilisation "Gestion des mises à jour des
descriptions" .......................................................................................................................................... 51
Figure 25:Le diagramme de cas d'utilisation du sprint (4) .................................................................... 53
Figure 26: Logo de l'application Medina Explorer................................................................................ 61
Liste des tableaux
Tableau 1 : Comparative entre les solutions existantes sur le marché .................................................... 7
Tableau 2 : Comparative entre les méthodes en cascade, V et spirale .................................................... 9
Tableau 3:Comparatif entre itérative, incrémentale et agile.................................................................. 10
Tableau 4: Le rôle de chaque acteur du Scrum ..................................................................................... 12
Tableau 5: Les différents outils utilisés dans notre projet ..................................................................... 17
Tableau 6: Les rôles du Scrum .............................................................................................................. 23
Tableau 7: Backlog du sprint (1) ........................................................................................................... 27
Tableau 8: Description textuelle des scénarios du cas d'utilisation "S'inscrire".................................... 29
Tableau 9: Description textuelle des scenarios du cas d'utilisation "S'authentifier" ............................. 31
Tableau 10: Description textuelle des scenarios du cas d'utilisation " Gestion du profil utilisateur" ... 32
Tableau 11: Description textuelle des scenarios du cas d'utilisation "Consultation des espaces publics"
............................................................................................................................................................... 34
Tableau 12:Backlog du sprint (2) .......................................................................................................... 37
Tableau 13:Description textuelle des scenarios du cas d'utilisation "Consultation des plans guidés" .. 39
Tableau 14: Description textuelle des scenarios du cas d'utilisation "Donner un avis" ........................ 40
Tableau 15: Description textuelle des scénarios du cas d'utilisation "Envoyer un message"................ 42
Tableau 16: Backlog du sprint (3) ......................................................................................................... 46
Tableau 17:Description textuelles des scenarios du cas d'utilisation " Supprimer le compte d’un
utilisateur" ............................................................................................................................................. 47
Tableau 18:Description textuelles des scenarios du cas d'utilisation " Ajouter un espace public" ....... 49
Tableau 19:Description textuelles des scenarios du cas d'utilisation "Gestion des mises à jour des
descriptions" .......................................................................................................................................... 49
Tableau 20:Backlog du sprint (4) .......................................................................................................... 52
Tableau 21: Algorithmes de classification ............................................................................................ 56
Introduction Générale
De nos jours, le développement fascinant des nouvelles technologies ne cesse pas à nous
impressionner. Aujourd’hui nous parlons d’une personne hyperconnectée, où l’utilisation des
appareils technologiques a très changé au fil du temps.
Plus largement, ce développement a touché tous les secteurs, notamment celui du tourisme,
qui a passé certainement par des étapes de reformulation très large ; allons du tourisme
traditionnel jusqu’à la convergence vers le tourisme en ligne.
Ainsi, l’usage des technologies est devenu une nécessité, et rares sont les individus qui
n’optent pas à leur téléphone intelligent pour répondre à un de leurs besoins. Parallèlement à
cette utilisation massive, les exigences du consommateur continuent à se développer
rapidement d’où il est devenu indispensable de les satisfaire.
Compte tenu de cela, plusieurs sont ; qui cherchent à pouvoir planifier leurs destinations à
distance, organiser les programmes de leurs journées, comparer les prix, et avoir des plans
guidés, afin de faciliter leurs visites et surtout celles de la première fois.
La Medina de Tunis, est très connus en tant que zone touristique, elle est visée par des
touristes venant partout dans le monde, et même les visiteurs tunisiens eux même, qui ont besoin
de connaitre ; les sites touristiques, les maisons d’hôte disponibles, les restaurants et toutes les
autres services touristiques et leurs localisations.
C’est dans ce cadre que s’installe le présent rapport de notre mini-projet, dans lequel nous
avons choisi de concevoir une application mobile de guide touristique au Medina de Tunis, qui
va d’une part faire découvrir et comprendre l’histoire et le patrimoine de la Medina et d’autre
part proposer les adresses de sorties détaillées, des plans guidés ou simplement de laisser le
visiteur de se guider selon ses envies.
Pour mener à terme notre travail, nous le répartissons de la manière suivante :
Le premier chapitre « Présentation du cadre général du projet », permet de placer le sujet
dans son contexte général en mettant accent sur la problématique, qui sera suivie d’une
étude de l’existant. La solution proposée et le choix de la méthodologie en feront aussi
partie.
Le deuxième chapitre « Spécifications des besoins et backlog produit », est consacré
pour la spécification des besoins fonctionnels, non fonctionnels et techniques, ainsi que
la planification du travail en définissant le backlog produit.
Le troisième chapitre « Sprint 1&2 » et le quatrième chapitre « Sprint 3&4 »,
présenteront l’étude conceptuelles des sprints pour le développement de notre
« release » tout en respectant les principes fondamentaux de Scrum.
Notre rapport sera clôturé par une conclusion générale qui présente une synthèse de
travail et propose des perspectives pour des éventuelles améliorations.
1
Chapitre 1 : Présentation du cadre général du projet
Introduction
Ce chapitre de début vise à situer le présent projet dans son contexte général, à travers la
présentation du sujet, la problématique et l’étude de la concurrence. Ensuit nous allons
mentionner la solution proposée et ses avantages, suivie de la méthodologie choisie pour
pouvoir la mettre en œuvre.
1. Présentation du projet
1.1 Idée du projet
Au fil du temps et avec l’avancement des technologies nous nous trouvons face à une
utilisation massive du téléphone intelligent où il est devenu indispensable chez certains. Cette
nécessité est expliquée par le fait qu’une personne peut se trouver à un moment donné en train
d’utiliser, pour une raison ou une autre, une de ses applications mobiles, déjà installée, afin de
répondre à un besoin spécifique.
En parlant de cela, et concernant le tourisme en Tunisie et spécifiquement la Médina, ou
la Médiane Tunisienne, nous avons pu repérer un besoin qui peut être définie comme suit ;
beaucoup de personnes qui se soient, tunisiens ou étrangers désirent profiter parfois d’une
visite par eux-mêmes, sans être sous l’obligation de suivre un guide ou une agence.
Cependant, ça reste dans l’ambigüité surtout pour ceux qui ne savent pas d’où commencer
ou comment se déplacer dans ses rues complexes pour trouver les références touristiques dont
ils s’intéressent.
Notre projet donc, consiste à concevoir une application mobile, qui aidera ces personnes
afin de pouvoir s’orienter dans la Medina, en proposant des plans guidés, et des adresses
clairement définies des restaurants, cafés et des monuments touristiques avec des vidéos,
photos explicatives qui serviront comme guide dans ce patrimoine architectural.
1.2 Choix du nom et logo de l’application
« Medina Explorer », un nom significatif pour dire l’exploration de la Médina, plus

largement découvrir et parcourir chaque détail. Nous présenterons également la charte
graphique du logo de l’application dans l’annexe A.
2
Chapitre 1 Présentation du cadre général du projet
1.3 Problématique
La Médina de Tunis, étant la destination préférée et le centre d’intérêt non seulement des
Etrangers mais aussi de Tunisiens, ceux-ci cherchent, la majorité du temps, à comment pouvoir
circuler dans ses différentes parties, ou de trouver simplement les bons endroits et d’en profiter
à moindre coût sans perdre beaucoup de temps. Plusieurs sont les difficultés qui se présentent
à un visiteur, nous avons pu repérer quelques-unes lors de notre recherche :
La complexité des trajets, rues, destinations, et des adresses ;
Le payement d’un guide privé peut coûter très cher ;
La disponibilité ou la non disponibilité des restaurants, cafés qui peuvent changer
d’adresse ;
La possibilité de visiter des différents endroits (Les souks, les palais, les mosquées…) ;
L’indépendance, et l’envie de profiter d’une expérience seul sans accompagnement ;
La différence des préférences des personnes.
Et avec l’évolution du l’ère digitale, il est devenu indispensable de s’adapter aux

développements technologiques, à noter l’utilisation accrue des téléphones intelligents qui est
avérer très utile pour tous dans le but de trouver des solutions rapides à nos problèmes.
Dans ce contexte-là, et afin de remédier aux difficultés mentionnées ci-dessus, il demeure
intéressant de proposer une solution sous forme d’une application mobile de guide touristique
adéquate afin de faciliter l’accès aux différentes références de la Médina, ainsi que ses
mystérieux endroits. Certainement, qu’aujourd’hui nous ne pouvons pas parler d’une
application sans considérer fortement l’utilisateur et ses exigences. Et cela en se basant sur des
modèles d’Intelligence Artificielles qui serviront à prédire des plans adéquats à chaque
utilisateur selon deux caractéristiques puissantes que nous avons choisie : son pays d’origine et
les commentaires des autres utilisateurs.
Alors, comment pouvons-nous utiliser les avancées technologiques pour offrir aux
utilisateurs une expérience unique ? tout en tenant compte de leurs préférences, les
contraintes du temps, des adresses et des endroits nombreux à visiter.
1.4 La mission du projet
Notre mission consiste à créer une application mobile dont lequel nous allons citer les
différents services disponibles aux visiteurs de la Médina de Tunis, tels que les services de
restauration, ou d’hôtellerie, ou les espaces historiques (Les palais, les mosquées…), les Souks
ainsi que les services qui peuvent être utiles tel que les banques, les boites de changes ; tout en
mettant l’accent sur la personnalisation des choix... Toutefois, et avant de s'engager dans la
résolution de cette problématique, il est crucial de commencer par une étude des solutions
existantes sur le marché.
3
2. Benchmarking
Le benchmarking ou benchmark est une technique de marketing spécifique destinée à

comparer son entreprise avec d’autres acteurs pour évaluer sa place sur le marché. [1]
Elle consiste à mener une analyse ou comparaison des performances des principaux
concurrents sur le marché en vue d’identifier les bonnes pratiques et de faire ressortir en quoi
ils sont meilleurs. Cette technique est très recommandée lord du lancement d’un nouveau
service ou produit sur le marché.
Plusieurs sont les types du benchmarking :
Interne : Comparaisons par rapport à plusieurs services internes à l’entreprise ;
Fonctionnel : analyse une fonction spécifique du processus ;
Horizontal : Comparaisons par rapport au processus ou méthodes de travail ;
Compétitif : Comparaisons par rapport à des concurrents directs.
Pour notre cas nous avons choisi le Benchmarking compétitif. Il consiste à se comparer (un
produit, services …) avec les meilleurs concurrents présents sur le marché.
2.1 Analyse des concurrents
L’analyse de la concurrence est une phase essentielle, elle permet d’avoir une vision
globale sur les acteurs présents et qui concurrencent notre offre. Nous pouvons alors identifier
leurs forces et faiblesses et d’une maniéré générale comprendre leur stratégie. Par conséquent,
nous allons pouvoir mesurer la viabilité de notre projet et comprendre comment nous pouvons
se différencier d’eux.
Nous avons pu repérer quelques solutions existantes similaires à la nôtre :
• Un guide touristique privé , c’est un choix personnel , lorsque quelqu’un choisi un

professionnel que soit par son propre recherche ou d’un site qui propose des guides, qui va
l’accompagner tout au long du circuit. Celui-ci avait une certaine connaissance du milieu.
La figure ci-dessous montre un exemple d’un guide privé.
Figure 1: Guide touristique privé
4
• Le site ‘Guide voyage Tunisie‘ est le site internet de l’agence de voyages « Depart
Travel Services », qui offre la possibilité de mieux préparer ses vacances et profiter au
maximum de son séjour. C’est un site informationnel.
Figure 2: Page d'accueil du site « Guide voyage Tunisie »
• L’application mobile « Tunis médina guide » permet de naviguer pour découvrir les
lieux et monuments de la Médina, les adresses de restaurants, cafés, maisons d’hôtes,
artisans et concept stores ainsi que plein d’autres fonctionnalités intéressantes.
Figure 3: Application mobile "Tunis médina guide"
5
• « Get your guide » est un site en premier lieu, et aussi une application mobile qui
permettent d’organiser des voyages ou de chercher, trouver et réserver des excursions
selon sa destination.
Figure 4: Application « Get your guide »
2.2 Critique de l’existant
Il est indispensable de critiquer les cas similaires afin de proposer la meilleure solution. Il
s'agit principalement de recenser les points forts et les points faibles de chaque solution trouvée
mentionnée au-dessus. Le tableau ci-dessous contiendra une analyse comparative entre les
différentes applications, sites retenus :
Nom de la Points fortes Point faibles

solution
• Possibilité de poser des • Payement très cher ;
Un guide questions directes ; • L’obligation de suivre un plan
touristique • Faible possibilité de se précis ;
privé perdre ; • De grands groupes de
• Une garantie personnes peuvent donc être
d’expérience, si le guide désorientés.
connait bien
l’environnement.
6
• Riche en • Longs paragraphes

« Guide information (Plan et d’informations ;
voyage quartiers, Monuments • Vidéo en français uniquement
Tunisie » majeurs) ; et sans traduction.
• Disponibilité d’un chat
bot et une carte de la
médina.
• Solution gratuite ; • Application trop chargée

• Application mise à d’informations ;
« Tunis jour et compréhensible ; • Pas possible de faire des
médina guide » • Ergonomie simple ; recommandations (manque
• Informations détaillées. espace d’échange
d’informations) ;
• Textes en langue française
uniquement ;
• La mappe présente des bugs.
« Get your • La réservation en avant • Réservation coûteuse ;
guide » puis le payement plus • Nombre de places limitées ;
trad ; • Durée de visite fixe (4H).
• L’annulation est
gratuite.
Tableau 1 : Comparative entre les solutions existantes sur le marché
3. Solution proposée et objectifs poursuivis
Cette étude approfondie et comparative des différentes solutions existantes a permis de

dégager quelques anomalies qui peuvent gêner l’utilisateur lors de sa visite ou simplement, sur
le plan fonctionnel, elles ne répondent pas à son besoin spécifique. Nous proposons donc, une
solution qui pourra répondre mieux à ses besoins, et nous comptons qu’elle sera plus adéquate
en termes de temps, coût, connexion, interactivité, et personnalisation …
Ce projet consiste à concevoir une application mobile de guide touristique à la médina, qui
a pour but de faciliter les différentes actions que les utilisateurs souhaitent effectuer .
A noter les objectifs suivants que l’application doit répondre :
- La recherche des informations sur les places historiques : partie informative de
l’application ;
- En fonction du budget, de la durée de la visite, du souhait d'espace non-fumeur ou
ouvert... L'application propose des lieux respectant ces restrictions ;
- La facilité à l’accès aux informations : Des vidéos, images, description vocale et
textuelle ;
- L’intégration de la réalité augmentée ;
- La proposition des plans guidés (en utilisant l’Intelligence Artificielle) ;
7
- L’offre d’un espace pour les consommateurs afin de recommander des avis à d’autres ;
- L’offre d’un espace d’échange entre les utilisateurs de l’application.
4. Analyse SOAR
L’SOAR est un outil d’évaluation et d’analyse au service de la planification stratégique,

articulé autour de 4 piliers : les forces et les opportunités actuelles, les aspirations futures et les
résultats correspondants. Il est considéré comme complément de l’analyse SWOT.
Cette démarche se concentre sur les points positifs afin d'en tirer la meilleure partie plutôt
que d'essayer de corriger les faiblesses ou les effacer.
Nous avons décidé de faire l’analyse SOAR plutôt que SOWT, parce qu’elle :
Permet de Générer un maximum d’énergie positive autour d'un même projet ;
Est parfaite pour ceux qui souhaitent introduire un service ou un produit sur le
marché et qui ne connaissent pas encore leurs points faibles ou leurs menaces ;
Aide à développer des objectifs stratégiques.
La figure ci-dessous décrit le modèle SOAR relative à notre projet :
Figure 5: Analyse SOAR de notre projet
5. Choix de la méthodologie de travail
Comme pour tout projet, et afin de garantir son organisation et sa cohérence il est crucial
de bien choisir une méthodologie avec laquelle nous allons travailler durant cette période.
8
Celle-ci est nécessaire pour s’assurer du niveau de qualité du travail, son bon déroulement et
éviter tout débordement au niveau des délais.
Selon notre cas, et pour pouvoir sélectionner la meilleure, il faut mentionner d’abord
l’existence de 3 principaux types de méthodologies pour structurer un projet :
Méthodologie prédictive ;
Méthodologie adaptative ;
Méthodologie hybride.
5.1 Méthodologie prédictive
Les méthodes classiques de gestion de projet, également appelées méthodes traditionnelles,

permettent de faire un découpage linéaire et séquentiel du cycle du projet. Elles reposent sur
une organisation stricte du travail et un fonctionnement par étapes, aucune rétroactivité est faite.
Cette catégorie regroupe trois types de méthodologies :
Modèle du cycle de vie en cascade ;
Le cycle de vie en V ;
Le cycle de vie en Spirale.
Le tableau ci-dessous présente une comparaison entre ces différents modèles citées en avant.
Type du modèle Avantages Inconvénients

Cycle de vie en • Une logique simple ; • Manque de flexibilité
cascade • Les objectifs sont clairs et dans le projet ;
précis dès le début ; • Retour en arrière est
• Adapté à des petits impossible ;
systèmes. • Mal adaptée aux
systèmes complexes.
Cycle de vie en V •
Adaptée aux produits dont • Effet tunnel ;
les spécificités sont claires • Moins de réactivité :
dès le début ; elle est mal adaptée aux
• Validation nécessaire à changements ;
chaque étape ; • Manque de souplesse.
• Processus facile à établir.
Cycle de vie en • Flexible ; • Effort de gestion
Spirale • Coordination entre important ;
l’exigences techniques et • Inadapté aux projets
conception ; avec des risques
• Contrôle périodique ; raisonnables ;
• Les étapes se déroulent • Processus long.
suivant une spiral.
Tableau 2 : Comparative entre les méthodes en cascade, V et spirale
9
5.2 Méthodologie adaptative
Aujourd’hui est avec les évolution technologiques récurrentes les méthodes traditionnelles
paraissent très rigides et lourde en termes d’exécution. De ce fait nous parlons maintenant plus
des méthodes adaptatives. C’est une approche moderne de gestion de projet où la satisfaction
du client et ses besoins sont mis en avance, plutôt que l’importance du process et les termes
contractuels. La coordination entre le client et l'équipe fait donc avancer bien le projet. Elle
regroupe trois principales méthodologies :
La méthodologie itérative ;
La méthodologie incrémentielle ou incrémentale ;
La méthodologie agile.
Afin de mieux comprendre, nous avons effectué une comparaison selon les exigences, la
livraison et l’objectif de chaque méthode, illustrée dans le tableau ci-dessous :
Caractéristiques
Méthodologie itérative Méthodologie incrémentielle Méthodologie agile
• Le périmètre d'un • Les exigences pour • Parfaite pour les
projet déterminé au cette méthode sont projets dont la
début du cycle du dynamiques ; prédiction de leur
travail ;
• Chaque activité est avenir est difficile ;
• Les exigences sont
dynamiques ;
exécutée une fois pour • Plus réactive et
un incrément donné ; permet une
• L’activité est répétée
• Permet de fournir de meilleure
jusqu’à être
petites livraisons adaptation aux
correcte ;
fréquentes ; imprévus liés au
• Elle fournit une
• Son principal objectif projet ;
solution unique ;
est d’être rapide. • Son objectif majeur
• Le but est d’offrir
est de Créer de la
une solution correcte.
valeur pour le
client.
Tableau 3:Comparatif entre itérative, incrémentale et agile
5.3 Méthodologie hybride
L’approche hybride, est une approche qui repose sur une complémentarité étroite entre les
méthodes traditionnelles et agiles. Les projets sont planifiés à l’aide de l’approche en cascade,
ce qui permet une mieux compréhension des tâches impliqués et la portée globale du projet.
Ensuite, ils sont exécutés à l’aide de la méthode Agile afin de réévaluer la charge de travail en
utilisant les sprints de courte durée.
❖ Suite à cette étude comparative des différentes méthodologies, et afin de bien choisir
celle qui va le mieux avec notre projet, nous avons établi cette liste :
10
- Notre projet est assez complexe et long ;

- Il faut un retour régulier d’information ;
- La solution sera faite en suite des cycles ou mini-projets ;
- La difficulté de prévoir la planification totale du projet, l’environnement du projet peut
changer et des imprévus peuvent arriver.
Selon cette liste, la méthodologie Agile sera la meilleure pour notre projet, qui offre en plus
de grande flexibilité, un meilleur contrôle au des contraintes par rapport aux autres
méthodologies.
6. Méthodologie de travail adoptée : Agile - Scrum
Agile est une méthodologie de gestion où le projet est fragmenté en plusieurs sous-parties
par les équipes de développement, en ajustant si nécessaire les objectifs pour répondre le plus
possible aux attentes du client.
Elle permet non seulement de renforcer les relations entre les membres d’une équipe, mais
aussi entre l’équipe et le client ainsi que la priorité est accordée à la satisfaction de ce dernier
plutôt d’aux termes du contrat. La flexibilité et la souplesse sont ses deux piliers forts.
C’est pour cette raison qu’elle est la plus adapté à nos besoins et nous avons opté pour la
méthode Scrum faisant partie des approches agiles. En effet, le terme « Scrum » signifie mêlée
et vient du monde du rugby, au moment où toute l’équipe doit se souder et avancer vers un but
(avancer vers le ballon). Cette méthode repose sur des « sprints » de courte durée, utilisée pour
former un cycle de projet. Tout projet développé avec Scrum doit répondre à certains principes :
✓ Une communication et collaboration accrues (entre les membres de l’équipe et

avec le client) ;
✓ L’adaptation au changement ;
✓ Vérifications régulières ;
✓ Priorisation des besoins et les fonctionnalités du client.
11
Figure 6: Mode de fonctionnement du Scrum

La figure 6 nous présente les différents acteurs et évènement du Scrum :
❖ L’équipe du Scrum
Acteur Rôles
✓ C’est le propriétaire du produit.
✓ Celui qui va partager la vision du produit à réaliser avec l’équipe ;
Product ✓ Il ajuste et règle les fonctionnalités du produit.
Owner ✓ Il est le responsable de l’exécution du projet d’une façon optimale
et donne l’approbation ou le refus du résultat présenté.
✓ Il doit bien assurer le principe du Scrum dans son intégralité ;

Scrum ✓ Il fait sortir le meilleur de chacun de l’équipe ;
master ✓ Il fixe les rôles, les objectifs el les durées.
✓ Une équipe qui doit être capable de conduire un projet avec une
Development autonomie ;
Team ✓ Transforme les besoins en fonctionnalités concrètes ;
✓
Tableau 4: Le rôle de chaque acteur du Scrum
❖ Evènements du Scrum
Les revues de Sprint : C’est une réunion qui se tient à la fin de chaque Sprint et dure au
maximum 1h par semaine de sprint. Elle permet de montrer ce que l’équipe du développement
a fait durant cette période au Product Owner, afin de passer à la prochaine tâche
Rétrospective de sprint : Organisée suite à la fin de chaque sprint après la revue du sprint, et
en interne c’est-à-dire entre les membres de l’équipe et animé par le Scrum Master afin
d’améliorer le processus du développement et le rendement du sprint suivant.
12
Daily Scrum : Un point de contrôle qui due maximum 15 minutes et permet à l’équipe Scrum
de synchroniser et ajuster leur travail pour les prochaines 24 heures.
❖ Les artefacts
Le carnet du produit (Product backlog) : c’est une forme de liste des fonctionnalités du
produit proposées par le client, ordonnées selon la priorité, elle évolue constamment au cours
de la vie du produit.
Carnet de sprint (Sprint backlog) : Afin d’atteindre l’objectif du chaque sprint, l’équipe du
développement liste les tâches à accomplir durant ce sprint, elles correspondent à la réalisation
d’un élément du carnet de produit.
Le graphique d’avancement (Le burndown Chart) : Un graphique qui permet de visualiser
la progression de l’équipe, il est généré au débit de chaque sprint. C’est un indicateur de
rendement pour le Product Owner.
Conclusion
Dans ce chapitre, qui a été dédié à la présentation du cadre générale de travail, nous avons
décrit l’idée du projet en déterminant après la problématique, suivi d’une analyse et critique des
solutions déjà existantes sur le marché pour proposer ensuit une solution qui pourra être plus
adéquate. Nous avons aussi choisi notre méthodologie de travail. Le prochain chapitre, sera
consacré à la présentation des acteurs du système, et à l’analyse des besoins.
13
Chapitre 2 : Spécification des besoins et Backlog produit
Introduction
Dans le chapitre précèdent, nous avons choisi Scrum comme méthodologie à adopter pour
le développement de notre projet. Par conséquence et avant d’entamer le premier sprint, nous
avons besoins de construire les bonnes bases du projet ainsi que notre environnement de
développement. C’est la phase de spécifications des besoins et de planification de l’architecture.
Dans ce chapitre, nous présentons cette phase qui débutera par la partie d’identification des
acteurs, des besoins fonctionnels et non fonctionnels suivies des outils techniques utilisées. La
partie suivante, concerne la planification du backlog produit et le modèle BMC de notre projet.
1. Capture des besoins
Cette étape va tracer le périmètre du projet, elle est donc cruciale pour réussir une
application de qualité. Pour cela il faut déterminer les différents besoins attendus par le système.
1.1 Identification des acteurs
Avant d’énumérer les fonctions, l’identification des acteurs intégrés dans le système
demeure une étape importante, nous pouvons trouver deux types d’acteurs : physique (une
personne) ou abstrait (un système) qui interagissent directement avec le système pour répondre
à un besoin. En UML, un acteur est une entité qui définit le rôle joué par un utilisateur ou par
un système qui interagit avec le système modélisé. [2]
Les acteurs de nos applications sont :
Client : Toute personne qui s’inscrit dans l’application et l’utilise soit pour s’informer,
ou pour avoir un plan guidé selon ses envies.
L’administrateur du système : Tout administrateur qui peut manipuler les fonctions
suivantes :
• Gestion des comptes des utilisateurs ;
• Gestion des informations publiées sur l’application (en relation avec les
restaurants, les cafés, les places touristiques…) ;
• Gestion des droits d’accès.
14
Chapitre 2 Spécification des besoins et Backlog produit
1.2 Spécification des besoins
L’objectif de cette partie est principalement la spécification détaillée et claire des

fonctionnalités attendues de notre application, nous pouvons distinguer deux types
d’exigences : fonctionnels et non fonctionnels.
1.2.1 Exigences fonctionnelles
Les besoins fonctionnels représentent les fonctionnalités de bases attendues d’un système.
Ce qu’une application peut offrir à ses acteurs. Ils nous permettent alors de définir le
comportement de chaque utilisateur en manipulant notre application. Cependant ils diffèrent
d’un acteur à un autre, pour cela nous avons décrit pour chaque acteur les fonctionnalités qui
lui sont associées.
❖ Pour l’administrateur
- La gestion des droits d’accès : L’administrateur seul qui pourra approuver ou refuser les
utilisateurs inscris après vérification de leurs identités.
- La gestion des comptes : Cette fonctionnalité permet à l’administrateur d’ajouter ou
supprimer un compte.
- La gestion des plans : Cette fonctionnalité permet l’administrateur de proposer des plans
selon les contraintes de l’utilisateur.
- La gestion des mises à jour : L’administrateur est le seul qui possède l’accès aux
informations publiés sur l’application, il pouvait ainsi les mettre à jour ou les modifier.
- La saisi des paramètres : Il peut configurer les paramètres de l’application (changer le
langues).
❖ Pour l’utilisateur (client)

- La gestion d’authentification : Cette fonctionnalité permet à un utilisateur de créer un
compte, et de s’authentifier afin d’accéder l’application.
- La gestion de son compte : L’utilisateur aussi peut avoir la possibilité de réinitialiser son mot
de passe et de faire des mises à jour de ses informations personnelles.
- Consulter les espaces publics : L’utilisateur se dispose à une large liste des espaces qui
pouvait visiter, avec des vidéos et images descriptifs.
- Chercher un espace : La recherche spécifique en tapant nom, ou un mot clé référent a cet
espace.
- Choisir les contraintes : Elle offre à l’utilisateur la possibilité de choisir leurs propres envies
(espace non-fumeur, espace avec Terrace …).
15
- Consulter les plans proposés : l’utilisateur peut selon ses contraintes, consulter des plans
que l’application lui propose avec personnalisation.
- Donner un avis : L’utilisateur peut évaluer son expérience en laissant un commentaire, ou en
attribuant une note au service (café, restaurant…).
- Envoyer un message : cette fonctionnalité, permet à l’utilisateur de communiquer avec chat
bot s’il avait besoin d’informations supplémentaires.
1.2.2 Exigences non fonctionnelles
Les besoins non fonctionnels décrivent les contraintes auxquelles sera soumise notre
application pour son bon fonctionnement. Plus précisément ce sont des indicateurs de qualité
et performance pour l’exécution des besoins fonctionnels. Pour plusieurs cas, une exigence
fonctionnelle est alignée avec une exigence non fonctionnelle.
Notre application exige certaines règles à respecter que nous pouvons les résumer dans les
points suivants :
- L’ergonomie des interfaces : Les interfaces de notre application doivent être
ergonomiques, conviviales et logiques.
- L’utilisabilité : l’application doit être accessible, facile à l’exploiter et compréhensible.
- La fiabilité : Les résultats apportés par notre application en termes de plans doivent être
fiables et reflètent effectivement les désirs du client.
- Le rendement : Notre application doit réduire le temps de réponse pour le chargement
de pages, et l’affichage des résultats et d’informations.
- La portabilité : L’application doit être facile à installer.
- La maintenabilité : L’application doit être facile à modifier (en cas de mise à jour des
informations).
2. Spécification technique
Les besoins techniques donne une vision globale sur l'architecture générale de notre projet,
pour cela nous allons identifier les différentes technologies dont nous avons servis lors de notre
travail.
2.1 Outils utilisés
Dans le tableau ci-dessous nous allons présenter les différents outils ou technologies
utilisés en cours de notre projet :
16
Outils Utilité
Pour le logo et la charte graphique
Adobe Illustrator C’est un logiciel de création graphique
vectorielle. Nous l’avons utilisé pour
créer notre logo et sa charte graphique
correspondante.
Pour la conception
StarUML C’est un logiciel de modélisation UML
open source que nous l’avons choisi pour
la conception de l’architecture de notre
application.
UML : Unified Modeling Language, ou

langage de modélisation unifiée, est un
langage de modélisation graphique, qui
fournit une représentation visuelle et
informatique d'un aspect du monde réel,
en offrant une multitude de diagrammes.
Il est utilisé dans les domaines du
développement logiciel et en conception
orienté objet.
Pour le maquettage
Figma C’est est un éditeur de graphiques
vectoriels et un outil de prototypage.
Nous l’avons utilisé pour créer les
interfaces de notre application.
Tableau 5: Les différents outils utilisés dans notre projet
2.2 Pattern Architectural
Nous avons choisi d’utiliser l’architecture MVC afin de concevoir l’architecture de notre
application. Comme spécificités, ce model permet une meilleure organisation du code et la
possibilité de sa réutilisation ainsi qu’il diminue la complexité lors de la conception.
Le modèle MVC, signifiant Model-View-Controller, et un modèle architectural il permet
une séparation logique des interfaces de présentation en trois composants distincts :
17
• Un modèle : Contient les données utilisées par un programme. Il peut s’agir d’une
base de données dans laquelle les informations ‘brutes’ sont organisés pour qu'elles
puissent ensuite être traitées par le contrôleur.
• Vue : utilisée pour présenter et afficher les données du modèle sur l’interface
utilisateur.
• Contrôleur : Contient les fonctionnalités nécessaires pour gérer et contrôler la
couche intermédiaire entre la vue et le modèle. Plus largement, pour traiter toutes
les requêtes entrantes, manipuler les données à l’aide du composant Modèle et
interagir avec les Vues pour rendre le résultat final.
La figure7, ci-dessous illustre la logique de cette architecture.
Figure 7: Architecture MVC
3. Spécification des exigences
Une fois que nous avons spécifiés tous les besoins fonctionnels et non-fonctionnelles, nous
pouvons alors passer à la spécification des exigences de notre projet. Nous allons donc proposer
le diagramme de classe de notre application ainsi que le diagramme des cas d’utilisation
d’UML. Ce dernier servira en suite à la classification et la planification du backlog produit.
3.1 Diagramme de classe
Un diagramme de classe est l’un des types les plus populaire en langage UML. C’est un
type de diagramme de structure car il décrit ce que doit être présent dans le système. Ce
diagramme permet de modéliser les objets du système, d’afficher les relations entre eux et
d’illustre également les attributs de chaque objet et ce qu’il fait : ses opérations. C’est un plan
du système donc il permet de mieux comprendre l’aperçu général de notre application.
18
Figure 8: Diagramme de classe de "Medina Explorer"
La figure ci-dessus monte les différentes classes constituant notre application. Nous allons
détaillés plus clairement les classes principales :
- Classe Personne : C’est la classe qui contient toutes les caractéristiques d’une personne
se trouvant dans le système ainsi que les opérations qu’elle peut fait, une personne peut
être un utilisateur, ou un administrateur ;
- Classe Compte : C’est la classe qui contient les informations en relation avec les
comptes de ceux qui utilisent l’application ;
- Classe plan : Cette classe contient les informations caractérisant les plans proposés par
l’application suite à la demande de l’utilisateur ;
- Classe contrainte : C’est la classe contenant les différentes contraintes proposées par
l’utilisateur ;
- Classe espace publique : Cette classe contient les caractéristiques des différents espaces
publics de la Médina de Tunis ;
- Classe réservation : C’est la classe contenant les informations relatives aux réservations
qu’un utilisateurs pourra effectuées.
- Classe multimédia : Cette classe contient les caractéristiques des images, vidéos ou
vocales utilisés pour décrire un espace public.
19
3.2 Diagramme de cas d’utilisation
Un diagramme de cas d’utilisation est un diagramme UML, qui est utilisé pour modéliser
le comportement fonctionnel d’un système et permet de capturer ses exigences. Cette
représentation décrit les fonctions générales d’un système et également identifie les interactions
entre ce dernier et ses acteurs. La figure ci-dessous illustre le diagramme de cas d’utilisation
de notre système.
Figure 9: Diagramme de Cas d'utilisation de "Medina Explorer"
4. Planification du traitement des cas d’utilisation
L’étape de planification et de structuration est primordiale dans un projet, afin d’assurer sa

réussite il faut bien organiser les tâches ou les fonctionnalités à traiter tout au long du
développement du projet. Pour cela, dans cette partie nous allons définir en premier lieu le
backlog produit ensuite nous allons présenter le tableau du backlog produit relative à notre
application, qui contiendra les fonctionnalités que doivent être implémentés et à la fin nous
proposons les rôles de chaque membre de notre équipe suivant la méthodologie Scrum.
20
4.1 Définition
Le backlog produit est le point central de tout projet Scrum, il permet de représenter une
liste de l’ensemble de fonctionnalités que doivent contenir le produit. En effet, c’est une liste
des User stories ou histoires utilisateurs, ordonnées en priorité selon les exigences du client.
Puisqu’ il y’avait des besoins et des fonctionnalités plus prioritaires que d’autres et leur
réalisation semble être primordiale pour le bon fonctionnement et la clarté de l’application il
est crucial donc d’établir un ordre de travail logique afin de coordonner l’enchaînement de la
réalisation des tâches.
4.2 Tableau Backlog produit du Medina Explorer
Pour le backlog de notre application, nous avons défini les fonctionnalités qui seront
implémentées et la description des user stories avec un ordre de priorité que nous avons choisi
comme suit ; élevée, moyenne et faible tout en se basant sur la relation entre les différentes
fonctions à fin faciliter le travail. Cela est décrit par le tableau ci-dessous.
Id Fonctionnalités User story Estimation Priorité

1 Inscription En tant qu’un utilisateur je veux 7 Jours Élevée
créer un compte dans
l’application Medina Explorer
afin d’y accéder.
2 Authentification En tant qu’un utilisateur de 6 Jours Élevée
l’application Medina Explorer, je
veux m‘authentifier en saisissant
mon login et mot de passe en
toute sécurité.
En tant qu’un administrateur de 5 Jours Élevée

veux m’authentifier afin de
pouvoir la gérer.
3 Gestion du En tant qu’un utilisateur, je veux 4 Jours Faible

profil utilisateur pouvoir gérer mon profil afin de
mettre à jour mes données
personnelles.
4 Consultation En tant qu’un utilisateur, je veux 7 Jours Élevée

des espaces consulter les espaces publics
publics proposés pas l’application afin
d’avoir une idée sur la Médina de
Tunis.
5 Consultation En tant qu’un utilisateur, je veux 7 Jours Élevée
des plans guidés consulter les plans guidés suite à
ma proposition afin de choisir
l’un le plus adéquat pour moi.
21
6 Donner un avis En tant qu’un utilisateur de 5 Jours Moyenne

veux laisser un avis sur un espace
visité afin d’aider les autres
utilisateurs.
7 Envoie d’un En tant qu’utilisateur je veux 6 Jours Moyenne
message envoyer un message à
l’application afin de demander
des informations
supplémentaires.
8 Supprimer En tant qu’un administrateur de 4 Jours Moyenne
compte l’application Medina Explorer, je
utilisateur veux supprimer un compte
utilisateur afin d’assurer le bon
fonctionnement de l’application.
9 Gestion des En tant qu’un administrateur de 7 Jours Élevée

mises à jour de l’application Medina Explorer, je
l’application veux ajouter un espace public.
En tant qu’un administrateur de 6 Jours Élevée

veux gérer les mises à jour des
descriptions relative aux espaces
publics afin d’assurer sa fiabilité.
10 Gestion des En tant qu’un administrateur de 6 Jours Élevée

paramètres de l’application Medina Explorer, je
l’application veux gérer les paramètres de
l’application afin d’assurer sa
transparence.
11 Gestion de En tant qu’un système, il doit 6 Jours Élevée
proposition des pouvoir proposer des plans sur la
plan base des contraintes
sélectionnées par avec
l’utilisateurs afin de proposer un
plan qui répond à ses contraintes.
12 Prédiction des En tant qu’un système, il doit 8 Jours Élevée
plans pouvoir prédire des plans de
visites en utilisant une base de
données afin de proposer un plan
spécifique à un utilisateur.
Figure 10: Backlog produit
22
4.3 Définition des rôles du Scrum
Comme nous avons défini dans la section de la méthodologie adoptée du premier chapitre,
la méthode Scrum est basée sur trois rôles principaux, ce tableau illustre ces rôles en se référant
à notre projet.
Rôles Nom du membre de l’équipe

Le prioritaire du produit Mme Dorsaf Harizi
Le directeur du Scrum Mme Dorsaf Harizi
L’équipe du Scrum Rihab Aissaoui
Kmar Mlayhi
Tableau 6: Les rôles du Scrum
4.4 Structure et découpage du projet
La réunion de planification des sprints est aussi une étape importante dans la méthodologie
Scrum, lors de laquelle nous assurons la structuration et le découpage du projet, pour cela nous
devrons planifier les sprints de notre travail. Par définition, les sprints sont des itérations de
courtes durées qui décomposent un processus de développement, et le sprint planning est
considérée comme la première étape à effectuer dans chaque sprint, il s’agit de l’organisation
du cycle de développement ainsi que l’exposition des objectifs à atteindre d’une manière claire.
La planification des sprints doit répondre aux questions suivantes :
✓ Lors de ce sprint, qu’elles sont les tâches que peuvent être achevées ?
✓ Le travail choisi, comment doit-il être effectué ?
Une release correspond à l’ensemble des sprints qui se sont terminés et constituent le
produit tout en assurant suffisamment de valeurs à l’utilisateur. Suivant notre cas, nous avons
choisi de découper notre projet sur une seule release.
La présentation ci-dessous décrit le plan de release de l’ensemble de fonctionnalités du
backlog produit qui doivent être développées sur l’ensemble des sprints que nous avons
déterminées dans une période définie. Nous avons décidé de découper notre travail en 4 sprints,
pour pouvoir à la fin livrer un produit de valeur à notre client.
23
Release
• Inscription
• Authentification
• Gestion du profil de l’utilisateur
Sprint 1 • Consultation des espaces publics
• Consultation des espace publics
• Consultation des plans guidés

• Donner un avis
Sprint 2 • L’envoie d’un message
• Supprimer le compte d’un utilisateur

• Gestion des mises à jour de l’application
Sprint 3 • Gestion des paramètres de l’application
• Gestion des propositions des plans

Sprint 4 • Prédiction des plans
5. Le business model CANVAS
Le business model d’une entreprise permet de décrire avec une manière claire, la logique
de l’entreprise et de son business, ou plus la façon dont elle crée de la valeur afin d’assurer sa
pérennité. Le business model CANVAS est une méthode qui permet de définir facilement le
modèle économique d’une entreprise ou d’un service, en intégrant toutes les composantes
importantes de coût ou de gain, comme la structure de coût, les partenaires, la proposition de
valeur ou encore les canaux de communication.
Le Business model CANVAS de notre projet est illustré par la figure ci-dessous.
24
Figure 11:Business Model CANVAS de Médina Explore

Chaque partie de ce tableau répond à une spécifié, que nous avons soulignées ci-dessous :
- Segments Clients : l’identification des segments de clientèle que nous souhait toucher ;
- La proposition de valeur : La détermination des bénéfices, que nos prestations apportent
à nos clients ;
- Canaux de distribution : ou canaux de communication et vente que privilégient nos
clients ;
- Relation clients : Les types de relations que nos clients attendent et souhaitent que nous
développons avec eux ;
- Sources de revenus : Notre flux de revenus ;
- Les ressources clés : La liste des ressources nécessaires au bon fonctionnement et
déroulement de l’activité globale ;
- Activité clés : Les activité nécessaires à mettre en œuvre afin de faire tourner notre
business, pour créer de la valeur à nos clients ;
- Partenaires clés : L’identification de nos partenaires externes intervenant dans la mise
en œuvre de l’activité de notre offre ;
- Structure des couts : C’est la liste de l’ensemble des couts liés à la production de notre
offre.
Conclusion
Dans ce chapitre, nous avons capturé les différentes fonctionnalités attendues de notre
application, présenté les spécifications techniques, le pattern architectural que nous prévoyons
l’utiliser, le diagramme de classe, et le diagramme de cas d’utilisation du Médina Explorer.
Nous avons aussi préparé l’organisation des sprints de notre travail, et fini par et notre Business
Model Canvas. Pour le chapitre suivant, nous allons commencer par faire l’étude conceptuelle
du premier et deuxième sprint.
25
Chapitre 3 : Sprints 1&2
Introduction
Dans le chapitre précédent, nous avons procédé à l’analyse des besoins, l’étude technique
et la spécification des exigences pour pouvoir à la fin établir le planning des différentes tâches
du projet. La release dont nous avons parlé précédemment, est constituée d’une suite
d’itérations (sprint) qui se terminent lorsque les incréments de ces derniers représentent un
produit qui contient suffisamment de valeur pour satisfaire les besoins du client et durant une
période définie par le Product Owner avec son équipe Scrum. Notre release est composée de
quatre sprintes.
Dans ce chapitre, nous nous intéressons au traitement des User stories du premier et
deuxième sprint pour pouvoir à la fin de chaque sprint produire un incrément potentiellement
livrable.
Partie 1 : Premier Sprint
1. Présentation du premier sprint
Afin de garder l’esprit Scrum, il est important de savoir que tous les sprints d’une release
ont une durée constante et ne se chevauchent jamais, signifiant qu’un sprint ne peut démarrer
que si le précédent est terminé.
Pour cela et avant se lancer dans le sprint, l’équipe Scrum doit impérativement définir le
but de ce dernier, c’est-à-dire d'indiquer ce ‘il va produire comme incrément de valeur. Il s’agit
de répondre à cette question « Pourquoi faisons-nous ce sprint ? ». Suie à une discussion avec
le Product Owner nous avons décidé le but de notre premier sprint, « Terminer la phase
d’inscription, d’authentification, de gestion ue profil utilisateur et de la consultation des
espaces publics ».
Une fois, nous avons défini le but de notre sprint, nous devrons décider quelles histoires de
notre backlog du produit doivent être inclues dans le backlog du sprint (1) ensuite le diagramme
de cas d’utilisation relative à ce sprint.
Le tableau ci-dessous regroupe l’ensemble des fonctionnalités qui seront développées lors
de ce sprint.
26
Chapitre 3 Sprints 1&2

1 Inscription En tant qu’un utilisateur 7 Jours Élevée
je veux créer un compte
dans l’application Medina
Explorer afin d’y accéder.
2 Authentification En tant qu’un utilisateur 6 Jours Élevée
de l’application Medina
Explorer, je veux
m‘authentifier en
saisissant mon login et
mot de passe en toute
sécurité.
En tant qu’un 5 Jours Élevée
administrateur de
l’application Medina
Explore, je veux
m’authentifier afin de
pouvoir la gérer.
3 Gestion du profil de En tant qu’un utilisateur, 4 Jours Faible

l’utilisateur je veux pouvoir gérer mon
compte afin de mettre à
jour mes données
personnelles.
4 Consultation des En tant qu’un utilisateur, 7 Jours Élevée

espaces publics je veux consulter les
espaces publics proposés
pas l’application afin
d’avoir une idée sur la
Médina de Tunis.
Tableau 7: Backlog du sprint (1)
27
Dans la Figure suivante nous illustrons le diagramme de cas d’utilisation pour ce premier
sprint.
Figure 12: Diagramme de cas d'utilisation du sprint (1)
Le diagramme de cas d’utilisation du premier sprint que nous avons décrit précédemment
présente les différentes fonctions que le système exécute. Cependant, de point de vue des
acteurs donc afin de rendre l’enchainement des actions plus compréhensible pour la conception,
il est évident de proposer une description textuelle du comportement du système, en décrivant
les scénarios qui peuvent se dérouler pour chaque cas d’utilisation.
Ensuite, pour chaque cas d’utilisation nous allons présenter le diagramme de séquence
système relative en se référant à leurs descriptions textuelles.
Et nous terminerons, avec la rétrospective du sprint et la réalisation de cette dernière.
2. Etude et conception des cas d’utilisation du sprint (1)
Pour cette partie, nous présenterons les différents cas d'utilisation de ce sprint, ainsi que
leurs descriptions textuelles et leurs diagrammes de séquence système.
28
2.1 Cas d’utilisation « S’inscrire »
Dans cette partie, nous allons commencer par la présentation de l'analyse textuelle et la
conception du cas d'utilisation « S'inscrire ».
2.1.1 Description textuelle des scénarios du cas d'utilisation « S'inscrire »
Le tableau ci-dessous présente la description textuelle des scénarios liée au cas d’utilisation
« S’inscrire ».
Use case « S’inscrire »

Acteurs Utilisateur de l’application
Objectif Créer un compte dans l’application
Précondition -Connexion à internet
-Application téléchargée
-Interface d’inscription disponible
Postcondition Compte utilisateur crée, l’accès par nom et un mot de passe.
Scénario nominal 1. Accéder à l’application ;
2. Choisir le bouton « Get Started » ;
3. Accéder à l’interface de l’inscription ;
4. Saisir les informations personnelles (Nom, adresse email,
nationalité, mot de passe) ;
5. Cliquer sur le bouton « s’inscrire ».
Scénario 4 : L’utilisateur saisit des données manquantes ou erronées ;

alternatif 4.a.1 : Le système affiche le message d’erreur adéquat ;
4.a.2 : Reprise de l’étape 4 du scénario Nominal.
Tableau 8: Description textuelle des scénarios du cas d'utilisation "S'inscrire"
2.1.2 Diagramme de séquence système du cas d'utilisation « S'inscrire »
La figure ci-dessous illustre le diagramme de séquence système « S’inscrire ». Elle montre

qu’en choisissant « Get Started », l’utilisateur sera dirigé vers l’interface d’inscription où il doit
saisir ses coordonnées nécessaires tel que son nom, sa nationalité, son email et propose un mot
de passe, il termine cette étape en cliquant sur le bouton « S’inscrire »
Arrivant à cette étape, le système doit vérifier les données saisies. Deux cas se présente
alors ; s’il y avait des données erronées, le système donc affichera un message d’erreur afin de
demander à l’utilisateur de ressaisir ses informations, si les données sont correctes, la création
de son compte sera réussite et il est renvoyé vers l’interface d’accueil de l’application.
29
Figure 13: Diagramme de séquence système du cas d’utilisation "S'inscrire"
2.2 Cas d’utilisation « S’authentifier »
Cette section s’intéresse à l’analyse textuelle et la conception du cas d’utilisation

« s’authentifier ».
2.2.1 Description textuelle des scénarios du cas d'utilisation « S’authentifier »
« s’authentifier ».
Use case « S’authentifier »

Acteurs Utilisateur de l’application / administrateur
Objectif Accéder à l’application
Précondition -Connexion à internet
-Nom d’utilisateur et mot de passe (un compte)
-Interface d’authentification disponible
Postcondition Utilisateur ou administrateur authentifiés
Scénario nominal 1. Accéder à l’application ;
2. Choisir le bouton « Log in » ;
30
3. Affichage de l’interface d’authentification ;

4. Remplissage des champs correspondants (login et mot de
passe) ;
5. Cliquer sur le bouton « se connecter » ;
6. Le système vérifie les champs / l’existence du compte ;
7. Redirection de l’utilisateur vers la page d’accueil de
l’application.
Scénario 6.a : L’utilisateur saisit des données manquantes ou erronées
alternatif ou compte inexistant.
6.a.1 : Le système informe l’utilisateur que le nom
d’utilisateur ou le mot de passe sont incorrects.
6.a.2 : Reprise de l’étape 3 du scénario Nominal.
Tableau 9: Description textuelle des scenarios du cas d'utilisation "S'authentifier"
2.2.2 Diagramme de séquence système du cas d’utilisation « S’authentifier »
Figure 14: Diagramme de séquence système du cas d’utilisation "S'authentifier"
Selon la figure ci-dessus, nous remarquons qu’en cliquant sur le bouton « Log In »,
l’utilisateur se trouvera dans la page d’authentification afin d’accéder à son compte.
31
Il saisit ses données personnelles, et le système de son tour va vérifier les différents champs
et l’existence du compte. En cas d’erreur le système notifie l’utilisateur et lui demande de
ressaisir ses informations, si ces coordonnées sont valides alors il sera dirigé vers la page
d’accueil. L’administrateur aura le même process que celui de l’utilisateur sauf il aura d’autre
accès dont l’utilisateur n’en possède pas.
2.3 Cas d’utilisation « Gestion de profil utilisateur »
Pour cette partie nous nous intéressons à l’analyse textuelle et la conception du cas
d’utilisation « Gestion du profil utilisateur ».
2.3.1 Description textuelle des scénarios du cas d'utilisation « Gestion du profil

utilisateur »
« Gestion du profil utilisateur ».
Use case « Gestion du profil utilisateur »

Objectif L’utilisateur va gérer son profil, en modifiant ses données ou
supprimer son compte.
Précondition Authentification préalable
Postcondition Profil mis à jour
Scénario nominal 1. L’utilisateur clique sur le bouton « Settings » ;
2. L’interface des paramètres s’affiche ;
3. L’utilisateur clique sur « Account » pour modifier son
profil ;
4. Affichage du formulaire de modification avec les
anciennes cordonnées de l’utilisateur ;
5. L’utilisateur modifie les champs choisis ou supprime son
compte ;
6. Le système vérifie les nouveaux données saisis ;
7. L’utilisateur valide les modifications ;
8. Modification des données et le système affiche un
message de succès.
Scénario -
alternatif
Tableau 10: Description textuelle des scenarios du cas d'utilisation " Gestion du profil
utilisateur"
32
2.3.2 Diagramme de séquence système du cas d'utilisation « Gestion du profil

utilisateur »
La présente figure, illustre le diagramme de séquence système du cas d’utilisation

« Gestion du profil utilisateur » en montrant l’enchaînement des différentes actions qui se
déroulent, si l’utilisateur va modifier ses informations personnelles ou supprimer de son profil.
Ce diagramme, montre que suite à la demande de l’utilisateur pour éditer son profil, le
formulaire de modification s’affiche avec les anciennes informations. Après avoir valider la
modification de ses données, le système vérifie les champs, si les champs sont valides, un
message de modification s’affiche pour l’utilisateur et ses données seront mis à jour, en cas
d’erreur (données manquantes ou erronées) la demande de modification sera refusée et un
message d’erreur s’affiche pour l’utilisateur.
Figure 15: Diagramme de séquence système du cas d’utilisation " Gestion du profil
utilisateur"
2.4 Cas d’utilisation « Consultation des espaces publics »
Cette partie est consacrée à l’analyse textuelle et la conception du cas d’utilisation

« Consultation des espaces publics ».
2.4.1 Description textuelle des scénarios du cas d'utilisation « Consultation des espaces
publics »
Nous présentons dans le tableau ci- dessous la description textuelle des scénarios du cas
d’utilisation « Gestion du profil utilisateur ».
33
Use case « Consultation des espaces publics »

Objectif L’utilisateur va pouvoir consulter les espaces publics selon
une catégorie choisie
Précondition Authentification préalable
Postcondition Liste des espaces publics présentée à l’utilisateur
Scénario nominal 1. L’utilisateur s’authentification
2. L’utilisateur sera dirigé à l’interface d’accueil ;
3. L’utilisateur choisi une des catégories proposées (To eat,
To shop, To visit …) ;
4. Une interface se lance présentant la liste des espaces
publics spécifiques à une catégorie.
Scénario -
alternatif
Tableau 11: Description textuelle des scenarios du cas d'utilisation "Consultation des espaces
publics"
2.4.2 Diagramme de séquence système du cas d’utilisation « Consultation des espaces

publics »
La figure ci-dessous illustre le diagramme de séquence système du cas d’utilisation

« Consultation des espaces publics ». En effet, l’utilisateur en se présentant dans l’interface
d’accueil, il doit choisir une des catégories proposées (To eat, To shop, To visit …). En cliquant
sur une catégorie, il se trouvera face à une autre interface contenant la liste des espace publics
liés à cette catégorie, il doit donc parcourir cette liste en utilisant un filtre qu’il peut le déterminé.
Par exemple s’il avait choisi, « To eat », dans l’interface représentant la liste il trouvera
(Coffee shops, Restaurant, Fast Food), il peut avoir la liste des coffee shops seulement en
utilisant le filtre « Filter according to Coffee shops »
Figure 16: Diagramme de séquence système du cas d’utilisation " Consultation des espaces
publics"
34
3. Réalisation du Sprint (1)
Dans la phase de la réalisation, nous allons présenter l’ensemble des prototypes relatives
au premier sprint. Ces prototypes représentent les interfaces de différents Use Cases que nous
avons traité lors de ce sprint. Ces interfaces ont été réalisées avec l’outil Figma, dont nous
avons parlé au deuxième chapitre dans la rubrique « outils utilisés ».
Nous allons présenter les différents interface réalisées et relatives aux cas d’utilisation du
sprint (1).
Interface « S’inscrire »
Interface « S’authentifier »
35
Interface « Gestion du profil utilisateur »
Interface « Consultation des espaces publics »
4. Rétrospective du Sprint (1)

La rétrospective du sprint est une réunion importante de la méthodologie Scrum. Elle aura
lieu à la fin de chaque sprint, au cours de laquelle l’équipe du Scrum reviennent sur leurs
réussites et réfléchissent aux différentes améliorations à prendre en compte pour l’efficacité du
prochain sprint. Nous avons eu cette réunion, et nous n’avons rencontré aucun problème. Nous
avons donc atteint l’objectif de ce sprint avec sucées.
Nous allons passer au sprint suivant, qui fera l’objet de la deuxième partie de ce chapitre.
36
Partie 2 : Deuxième Sprint
1. Présentation du deuxième sprint
Pour cette partie, nous allons suivre le même principe du sprint précédent. Donc suit à une
conversation entre l’équipe Scrum et le Product Owner nous avons défini le but de ce deuxième
sprint comme suit : « Réaliser le cas d’utilisation consulter les plans proposés, ainsi que la
gestion des avis et l’envoi d’un message avec des résultats satisfaisants ».
Nous avons présenté alors, dans un premier lieu le tableau ci-dessous des histoires
utilisateurs qui doivent être inclues dans le backlog du sprint (2) suivi du diagramme de cas
d’utilisation relative à ce sprint.
1 Consultation des En tant qu’un utilisateur, 7 Jours Élevée

plans guidés je veux consulter les
plans guidés suite à ma
proposition afin de
choisir l’un le plus
adéquat pour moi.
2 Donner un avis En tant qu’un utilisateur 5 Jours Moyenne
de l’application Medina
Explore, je veux laisser
un avis sur un espace
visité afin d’aider les
autres utilisateurs.
3 Envoie d’un En tant qu’utilisateur je 6 Jours Moyenne
message veux envoyer un
message à l’application
afin de demander des
informations
supplémentaires.
Tableau 12:Backlog du sprint (2)
37
La figure ci-dessous illustre le diagramme de cas d’utilisation relative à ce sprint.
Figure 17:Diagramme de cas d'utilisation du sprint (2)

En se référant à ce diagramme, pour chaque cas d’utilisation nous allons présenter la
description textuelle des différents scénarios qui peuvent se dérouler, suivie due leurs
diagrammes de séquence système relatives. Et nous terminerons, avec la réunion de la
rétrospective du sprint et sa réalisation.
2. Analyse et conception des cas d’utilisation du sprint (2)
En cette partie, nous nous intéresserons aux différents cas d’utilisation du deuxième sprint,
en présentant leurs descriptions textuelles et leurs diagrammes de séquence système.
2.1 Cas d’utilisation « Consultation des plans guidés »
Pour cette partie nous nous allons présenter l’analyse textuelle ainsi que la conception du
cas d’utilisation « Consultation des plans guidés ».
2.1.1 Description textuelle des scénarios du cas d'utilisation « Consultation des plans
guidés »
Le tableau ci- dessous décrit la description textuelle des scénarios du cas d’utilisation
« Consultation des plans guidés ».
Use case « Consultation des plans guidé »

Objectif L’utilisateur va pouvoir consulter des plans guidés afin de
choisir le plus adéquat selon ses contraintes et désirs
38
Précondition - Authentification préalable

- Choisi les contraintes
Postcondition Plans consultés par l’utilisateur suit à sa demande
Scénario nominal 1. L’utilisateur clique sur le bouton « Get a guided plan » qui
se trouve dans l’interface d’accueil ;
2. L’interface des propositions des plans s’affiche ;
3. L’utilisateur clique sur « Insert Constraints » pour insérer
ses contraintes ;
4. L’utilisateur clique sur « Save » ;
5. Le système vérifie la validité des contraintes choisies par
l’utilisateur ;
6. Affichage des plans proposés pour l’utilisateur.
Scénario 5.a : L’utilisateur laisse le champ des contraintes vide.
alternatif 5.a.1 : Le système affiche un message d’erreur.
5.a.2 : Reprise de l’étape 3 du scénario Nominale.
Tableau 13:Description textuelle des scenarios du cas d'utilisation "Consultation des plans
guidés"
2.1.2 Diagramme de séquence système du cas d'utilisation « Consultation des plans
guidés »
Figure 18:Diagramme de séquence système du cas d’utilisation " Consultation des plans
guidés"
39
La figure ci-dessus illustre le diagramme de séquence système du cas d’utilisation

« Consultation des plans guidés ».
2.2 Cas d’utilisation « Donner un avis »
Cette section est relative au cas d’utilisation « Donner un avis », où nous allons présenter
la description textuelle des scénarios de ce dernier ainsi que sa conception.
2.2.1 Description textuelle des scénarios du cas d’utilisation « Donner un avis »
Les différents scénarios du cas d’utilisation « Donner un avis » qui peuvent se dérouler,
sont présentés dans le tableau ci-dessous.
Use case « Donner un avis »

Objectif L’utilisateur va laisser commenter sur un espace qu’il a
visité afin de pouvoir aider les autres utilisateurs.
- Consulter un espace public
Postcondition L’avis de l’utilisateur est enregistré sous la rubrique de la
description de l’espace public correspondant
Scénario nominal 1. L’utilisateur clique sur le bouton « Review the place » ;
2. L’utilisateur saisit son commentaire et valide ;
3. Le système vérifie le commentaire ;
4. Le commentaire s’affiche sous la section de la description
d’un espace public.
Scénario 3.a : L’utilisateur laisse le champ vide, ou saisit un
alternatif commentaire contenant des termes inappropriés.
3.a.1 : Le système affiche le message d’erreur a adéquat.
Tableau 14: Description textuelle des scenarios du cas d'utilisation "Donner un avis"
2.2.2 Diagramme de séquence système du cas d’utilisation « Donner un avis »
Nous proposons dans la figure suivante le diagramme de séquence système du cas

d’utilisation « Donner un avis ».
40
Figure 19:Diagramme de séquence système du cas d’utilisation " Donner un avis"
2.3 Cas d’utilisation « Envoyer un message »
2.3.1 Description textuelle des scénarios du cas d’utilisation « Envoyer un message »
Le tableau ci-dessous représente la description des scénarios du cas d’utilisation « Envoyer

un message »
Use case « Envoyer un message »

Objectif L’utilisateur va pouvoir envoyer un message à l’application,
s’il veut demander des informations supplémentaires.
- Interface d’accueil rechargé
Postcondition L’utilisateur envoie un message à l’application et reçoit une
réponse du système (chat bot).
Scénario nominal 1. L’utilisateur clique sur l’icône de messagerie qui se trouve
dans la barre de navigation prêt de l’icône du profil de
l’utilisateur ;
2. Une nouvelle interface s’affiche ;
3. L’utilisateur saisit ses questions ;
41
4. Le système vérifie la question et cherche une réponse ;

5. Le système envoie un message de réponse à l’utilisateur.
Scénario -
alternatif
Tableau 15: Description textuelle des scénarios du cas d'utilisation "Envoyer un message"
2.3.2 Diagramme de séquence système du cas d’utilisation « Envoyer un message »
La figure ci-dessous illustre le diagramme de séquence système du cas d’utilisation

« Envoyer un message ».
Figure 20:Diagramme de séquence système du cas d’utilisation " Envoyer un message"
Pour la réalisation du sprint 2, nous avons préparé les interfaces relatives au cas
d’utilisations, « Consultation des plans proposés », « Donner un avis » et « Envoyer un
message », avec l’outil Figma et elles sont présentées ci-dessous.
42
Interface « Consultation des plans proposés »
Interface « Envoyer un message » Interface « Donner un avis »
43
Comme nous avons déjà définie auparavant, la réunion de la rétrospective est une des
étapes importantes lors du Scrum. Durant cette réunion, avec le Product Owner et le Scrum
Master nous avons décidé comme amélioration pour le prochain sprint, de respecter plus les
dates limites afin d’être à temps pour plus de vérification. Le principe de Scrum a été respecté
et le travail est accomplis selon les préférences du Product Owner.
Conclusion
Dans le deuxième chapitre, nous avons réalisé les fonctionnalités des deux premiers
sprints, que nous avons pré-décrit en proposant les scénarios qui pourraient se produire, et en
présentant les diagrammes de séquence système des différentes user stories. Nous avons
également créé des interfaces pour les deux sprints et les avons présentées au Product Owner.
Nous avons donc réussi à construire deux incréments de valeur pour notre client.
Dans le chapitre suivant nous décrirons les cas d’utilisations du 3éme sprint qui résume les
fonctionnalités prévues pour l’administrateur et le 4éme et dernier sprint où nous allons parler
de déploiement de l’Intelligence Artificielle pour prédire des plans guidés pour les utilisateurs.
44
Chapitre 4 : Sprints 3&4
Introduction
Dans le chapitre précèdent, nous nous sommes focalisés sur l’étude conceptuelle du
premier et deuxième sprint. Dans ce chapitre, nous nous intéresserons à l’étude conceptuelle du
troisième et quatrième sprint.
Partie 1 : Troisième Sprint
1. Présentation du troisième sprint
Il est nécessaire qu’avant d’entamer le troisième sprint, nous définissons le but de ce

dernier. Pour cela après la discussion avec le Product Owner et Scrum Mater pendant la réunion
de planification du sprint, nous avons décidé que le but sera ; « Réaliser les cas d’utilisation,
de la suppression de compte utilisateur, la gestion des mises à jour du contenu de
l’application et la gestion des paramètres de l’application ». Une fois, le but de sprint est
défini, il est temps de décider quelles histoires de notre backlog du produit doivent être inclues
dans le backlog du sprint (3) ensuite la présentation du diagramme de cas d’utilisation relative
à ce sprint.
Le tableau 21 résume les fonctionnalités à réaliser durant 3ème sprint.

1 Supprimer le En tant qu’un 4 Jours Moyenne
compte d’un administrateur de
utilisateur l’application Medina
Explorer, je veux
supprimer un compte
utilisateur afin d’assurer
le bon fonctionnement de
l’application. (Sécurité)
2 Gestion des mises à En tant qu’un 7 Jours Élevée

jour de administrateur de
l’application l’application Medina
Explorer, je veux ajouter
un espace public.
45
Chapitre 4 Sprint 3&4
2
En tant qu’un 6 Jours Élevée
administrateur de
l’application Medina
Explorer, je veux assurer
les mises à jour des
descriptions relative aux
espaces publics afin
d’assurer sa fiabilité.
3 Gestion des En tant qu’un 6 Jours Élevée
paramètres de administrateur de
l’application l’application Medina
Explorer, je veux gérer
les paramètres de
l’application afin
d’assurer sa
transparence.
Tableau 16: Backlog du sprint (3)
Figure 21: Le diagramme de cas d'utilisation du sprint (3)
Le diagramme de cas d’utilisation relative au 3éme sprint est illustré par la figure ci-dessus.
Ce diagramme décrira les différentes fonctionnalités que l’administrateur pourra utiliser ou bien
modifier dans l’application.
2. Analyse et conception des cas d’utilisation du sprint (3)

En cette partie, nous nous intéresserons aux cas d’utilisation du 3éme sprint, en présentant
leurs descriptions textuelles et les diagrammes de séquence système relatives seulement au cas
46
d’utilisation « Supprimer le compte d’un utilisateur » et « Gestion des mises à jour du contenu
de l’application ».
2.1 Cas d’utilisation « Supprimer le compte d’un utilisateur »
Ce cas d’utilisation, décrit la fonctionnalité « supprimer un compte d’utilisateur » qui sera

faite par l’administrateur. En effet, l’administrateur pourra supprimer un compte d’utilisateur,
si ce dernier demande la suppression de son compte ou lorsqu’il décide de sa part si c’est
nécessaire pour la sécurité et le bon déroulement de l’utilisation de l’application par d’autre
utilisateur.
2.1.1 Descriptions textuelles des scénarios du cas d’utilisation « Supprimer le compte

d’un utilisateur »
Les scénarios que nous envisageons pour le cas d’utilisation « Supprimer le compte
d’utilisateur » sont présentés dans le tableau ci-dessous.
Use case « Supprimer le compte d’un utilisateur »

Acteurs Administrateur de l’application
Objectif L’administrateur va pouvoir supprimer un compte
d’utilisateur (inactif ou pour des raisons de sécurités)
Postcondition Le compte de l’utilisateur sera supprimé de la base de
données de l’application
Scénario nominal 1. L’administrateur demande la suppression d’un compte ;
2. Affichage de la liste des tous les utilisateurs de
l’application ;
3. L’administrateur choisi l’utilisateur ;
4. L’administrateur clique sur le bouton « Delete account » ;
5. Le compte de l’utilisateur est supprimé, un message de
validation est affiché par suite à l’administrateur.
Scénario -
alternatif
Tableau 17:Description textuelles des scenarios du cas d'utilisation " Supprimer le compte
d’un utilisateur"
2.1.2 Diagramme de séquence système du cas d’utilisation « Supprimer le compte d’un

utilisateur »
La figure suivante illustre le diagramme de séquence système du cas

d’utilisation "Supprimer le compte d’un utilisateur"
47
Figure 22: Diagramme de séquence système du cas d’utilisation "Supprimer le compte d'un
utilisateur"
Cette figure décrit la fonctionnalité de suppression d’un compte effectuée par

l’administrateur, il doit commencer par la demande de suppression qui se trouve dans la liste
des fonctionnalités destinées à l’administrateur. Suite à sa demande le système renvoie la liste
des utilisateurs de l’application, l’administrateur de sa part choisit celui à supprimer. La requête
est envoyée au système et ensuite à la base de données. La base de données confirme au système
que le compte est supprimé et un message de validation est affiché à l’administrateur.
2.2. Cas d’utilisation « Gestion des mises à jour de l’application »
Pour le cas d’utilisation « Gestion des mises à jour du contenu de l’application » elle se
divise en deux fonctionnalités ; « Ajouter un espace public » et « Gérer les mises à jour
des descriptions ». Nous allons donc, décrire les scénarios qui se déroulent pour chaque
fonctionnalité ainsi que proposer deux diagrammes de séquence système pour chaque unes.
2.2.1 Description textuelle des scenarios du cas d’utilisation « Gestion des mises à jour
de l’application »
Le tableau 17 présente les différents scénarios du cas d’utilisation « Ajouter un espace

public » qui qui peuvent se dérouler.
48
Use case « Ajouter un espace public »

Objectif L’administrateur va pouvoir ajouter un espace nouveau
public à l’application
Postcondition Un nouvel espace public est ajouté à l’application et visible
par les utilisateurs
Scénario nominal 1. L’administrateur demande l’ajout d’un nouvel espace
public ;
2. Lancement de formulaire d’ajout de l’espace public ;
3. L’administrateur entre tous les informations liées au
l’espace public (Coordonnées, description, images,
vidéo…) ;
4.L’administrateur clique sur le bouton « Add To The List » ;
5. Le système vérifie les données et caractéristiques entrées ;
6. Un message de validation est affiché pour l’administrateur,
et l’espace public s’affichera avec les autres espaces de sa
catégorie.
Scénario 5.a : L’administrateur laisse des champs vides, ou saisit des
alternatif données erronées.
5.a.1 : Le système affiche le message d’erreur a adéquat.
Tableau 18:Description textuelles des scenarios du cas d'utilisation " Ajouter un espace
public"
Le tableau ci-dessous présente les différents scénarios du cas d’utilisation « Gestion des
mises à jour des descriptions » qui qui peuvent se dérouler.
Use case « Gestion des mises à jour des descriptions »

Objectif L’administrateur va pouvoir modifier les informations
(descriptions) d’un espace public
- Accéder à l’interface contenant la liste des espaces publics
Postcondition Description d’espace public modifiée et mise à jour
Scénario nominal 1. L’administrateur demande la modification des
informations d’un espace public ;
2. Lancement de formulaire de modification ;
3. Administrateur saisit les modifications nécessaires ;
4.L’administrateur clique sur le bouton « Confirm » ;
5.Un message de validation est affiché pour l’administrateur,
et l’espace public s’affichera avec nouvelles mises à jour.
Scénario -
alternatif
Tableau 19:Description textuelles des scenarios du cas d'utilisation "Gestion des mises à jour
des descriptions"
49
2.2.2. Diagrammes de séquence système du cas d’utilisation « Gestion des mises à jour
de l’application »
La figure 26 illustre le diagramme de séquence système du cas d’utilisation « Ajouter un

espace public ». L’administrateur pourra ajouter un espace public à l’application. Suite à sa
demande, le système affiche le formulaire d’ajout à celui-ci afin de saisir les informations
nécessaire (description, adresse, images…). Le système vérifie les informations saisies, deux
cas se proposent alors ; le premier si les données sont valides, il les transfère à la base de
données pour les enregistrer et un message de confirmation s’affiche pour l’administrateur. Le
deuxième cas lorsque l’administrateur laisse un des champs obligatoires vides, un message
d’erreur est envoyé à celui-ci et il doit ressaisir de nouveau.
Figure 23:Diagramme de séquence système du cas d’utilisation "Ajouter un espace public"
La figure suivante présente le diagramme de séquence système du cas d’utilisation «

Gestion des mises à jour des descriptions ».
Cette figure décrit le processus suivant, l’administrateur a la possibilité de modifier la

description ou une des informations liées à un espace public donnée. Pour cela suite à sa
50
demande, un formulaire de modification se lance, il saisit les modifications nécessaires et valide

son action. Le système se charge ensuite de la transmission des caractéristiques à la base de
données afin de les sauvegarder. Un message de confirmation est renvoyé au système et ce
dernier s’assure de l’afficher à l’administrateur. La mise à jour est visible par suite à
l’utilisateur.
Figure 24:Diagramme de séquence système du cas d’utilisation "Gestion des mises à jour des
descriptions"
Pour la réalisation du sprint (3) nous avons prévu de préparer les interfaces décrivant les
fonctionnalités nécessaires afin de pouvoir livrer un incrément de valeur et satisfaire la demande
de notre client.
Pour la réunion de rétrospective de ce sprint, nous avons valider les tâches que nous avons
prévu les faire durant la réunion de planification du sprint tout en respectant le processus du
Scurm et les améliorations que nous avons parlé dans le sprint déjà passé.
Nous allons présenter dans le reste du chapitre 4, le dernier sprint qui fera l’objet de la
partie suivante.
51
Partie 2 : Quatrième Sprint
1. Présentation du troisième sprint
Comme tous sprint, ce sprint nécessite la fixation d’un objectif. Durant la réunion de la
planification nous avons décidé l’objectif suivant : « Terminer les fonctionnalités suivantes ;
la proposition des plans pour l’utilisateur selon les contraintes, et la prédiction des plans ».
Une fois, le sprint Goal est défini, il est temps de décider quelles histoires de notre backlog
du produit doivent être inclues dans le backlog du sprint (4) ensuite la présentation du
diagramme de cas d’utilisation relative à ce sprint.
Dans cette partie nous allons se focaliser spécifiquement sur l’intervention de
« l’Intelligence Artificielle » dans notre projet, dont l’idée est de laisser une expérience
utilisateur intéressante et impliquante.
Le tableau suivant écrit le backlog du sprint.

1 Gestion de En tant qu’un système, il doit 6 Jours Élevée
proposition des pouvoir proposer des plans sur la
plan base des contraintes sélectionnées
par avec l’utilisateurs afin de
proposer un plan qui répond à ses
besoins.
2 Prédiction des En tant qu’un système, il doit 8 Jours Élevée
plans pouvoir prédire des plans de
visites en utilisant une base de
données afin de proposer un plan
spécifique à un utilisateur.
Tableau 20:Backlog du sprint (4)
52
Nous allons présenter par la figure ci-dessous le diagramme de cas d’utilisation relative au
sprint 4.
Figure 25:Le diagramme de cas d'utilisation du sprint (4)
2. Analyse des cas d’utilisation du sprint (4)
2.1 Cas d’utilisation « Proposer plans »
La proposition des plans, est une fonctionnalité faite par le système lui-même le processus
est décrit comme suit.
En effet, l’utilisateur va pouvoir sélectionner les contraintes qui lui semblent nécessaire
pour avoir un plan qu’il peut suivre lors de sa visite du Médina du Tunis ; parmi ces contraintes
nous pouvons citer ; Un espace non-fumeur, un espace avec terrasse, un espace ouvert… Le
système de sa part se base sur les données enregistrées dans la base de données de l’application,
spécifiquement les caractéristiques concernant les espaces de la Médina de Tunis, pour pouvoir
générer d’une façon automatique les plans qui paraissent les plus adéquats pour l’utilisateur.
Le plan ou les plans générés seront par suite affichés pour ce dernier et il pourra les consultés
pour trouver plus de détails.
53
2.2 Cas d’utilisation « Prédire plans »
Dans ce deuxième cas d’utilisation, nous allons aborder les notions et les termes que
nous allons ajouter et liés à notre projet en se basant sur des mots clés tel que
l’intelligence artificielle, l’apprentissage automatique, l’analyse sentimentale du texte,
où nous allons les évoqués pour produire un avantage aux utilisateurs de notre application,
ils peuvent maintenant avoir des plans guidés sans la nécessité de sélectionner les
contraintes.
Nous allons décrire dans cette partie le fonctionnement du système intelligent, dont le
rôle est de prédire des plans guidés en se basant sur des caractéristiques ; dont les plus
fortes sont les avis des autres utilisateurs, et la nationalité ou pays d’origine de l’utilisateur
lui-même.
2.2.1 Définition de l’Intelligence Artificielle
L’intelligence artificielle représente les machines ou les systèmes qui reproduisent les
comportements des humains, ou plus imitent l’intelligence humaines tel que le raisonnement
logique. Son but est de permettre à des ordinateurs de penser et d'agir comme des êtres humains.
2.2.2 Définition de l’analyse sentimentale du texte
L’analyse des sentiments qui proviennent d’un texte, est l’interprétation et l’analyse des
émotions (positives, négatives) éprouvées par des données textuelles en utilisant des techniques
ou algorithmes de traitements de texte spécifiques.
L’analyse de sentiment se concentre sur la polarité (positives, négative, neutre), et émotion
(colère, joie, tristesse) et même sur les intentions (intéressé, non intéressé). [3]
Dans notre cas nous allons analyser les commentaires, ou les avis rédigés par l’utilisateur
lorsqu’il visite les espaces publics proposés par notre application. De plus nous nous
concentrons sur la polarité (positive, négative) spécifiquement car cela servira ensuite comme
une base sur laquelle le système va s’appuyer pour prédire des plans les plus adéquat à
l’utilisateur en identifiant son opinion à l’égard des espaces visités.
2.2.3 Traitement des sentiments des avis des utilisateurs par l’apprentissage
automatique
Comme nous avons parlé dans la section précédente, l’analyse de sentiment utilise
plusieurs algorithmes et méthode de NLP (Natural Language Processing).
54
Nous pouvons regrouper ces méthodes en trois catégories de système, pouvant être basés
sur : [3]
- Un ensemble de règles élaborées manuellement ;
- Des techniques d’apprentissage automatique (Machine Learning) ;
- Les deux système précédents (hybride).
Le premier système, se base sur les règles élaborées par l’Homme afin d’aider le système
à identifier la polarité (positive, négative) d’un avis. Pour notre cas, nous avons choisi le
traitement avec des techniques d’apprentissage automatiques (Machine Learning) à partir des
données de la base de données de notre application.
Définition du Machine Learning : C’est une sous-catégorie de l’intelligence
artificielle. Elle fonctionne à partir des algorithmes. Ces derniers sont alimentés par
les données de manière à apprendre à s’améliorer automatiquement, à partir de
l’expérience.
Selon notre cas, ces algorithmes vont apprendre de manière autonome à analyser les
sentiments d’un texte pour que nous puissions après utiliser cette analyse à la prédiction des
plans
Le traitement d’analyse de sentiment peut être effectuer par la classification des termes
du texte en des catégories. Elle est assurée par les modèles. Plus largement le modèle va
apprendre à associer un commentaire ou un avis d’utilisateur à une catégories : positive,
négative, dont nous aurons besoin dans l’étape de prédiction.
2.2.3.1 Catégorisation automatique du texte
La catégorisation ou classification automatique d’un texte, consiste à attribuer à un texte

une catégorie prédéfinies en utilisant des algorithmes d’apprentissage automatique. Pour cela
nous devrons faire apprendre un algorithme avec des caractéristiques spécifiques pour pouvoir
à la fin catégoriser des nouveaux textes.
Pour la suite de la section nous allons décrire le processus de catégorisation.
1. Pour un premier lieu il faut choisir sur quoi la classification va-t-elle se basée, dans
notre cas selon l’analyse des sentiments positives, ou négatives d’un texte
(commentaire) écrit par l’utilisateur.
2. La deuxième étape est la vectorisation du texte afin que les algorithmes d’apprentissage
automatique puissent les comprennent. Il s’agit de transformer un texte en vecteur.
La vectorisation peut être faite par plusieurs méthodes. Nous avons choisi « la méthode de
fréquence » ou « Bag of words » [4]. Plus largement, nous allons transformer un texte selon le
nombre d’apparition de mots d’un vocabulaire prédéfini.
Pour notre cas, nous avons décidé d’attribuer : 0 au mot appartenant à un vocabulaire
négatif par exemple {‘service lent ‘, ‘espace encombré’, ‘non sécurisé’, ‘dégoutante’ …} et
55
attribuer 1 au mot appartenant à un vocabulaire positif par exemple {‘délicieux’, ‘fantastique’,

‘superbe’, ‘service de qualité’, ‘expérience inoubliables’}.
Chaque commentaire sera classé après dans la base de données, (positif ou négatif) par 1 ou 0
selon le nombre de mots positif et le nombre de mots négatifs qui se trouverons dans ce
commentaire. Et cela est fait par des algorithmes bien choisis.
3. La mise en place d’un algorithme de classification ; pour cette étape nous devrons
choisir un algorithme afin de pouvoir classifier les textes.
Par définition, un algorithme est une séquence d'actions qui s'exécutent pour résoudre un
problème [5]. Le tableau ci-dessous présente les algorithmes de classification les plus connus.
Algorithmes Fonctionnement
Méthode des K plus Cet algorithme est également connu sous le nom de
proches voisins KNN ou k-NN, est un discriminant d'apprentissage
supervisé non paramétrique, qui utilise la proximité
pour effectuer des classifications ou des prédictions
sur le regroupement d'un point de données
individuel.
Classification naïve C’est un algorithme d’apprentissage supervisé, qui
bayésiennes se base sur le théorème de Bayes. Ce dernier est un
classique de la théorie des probabilités. Ce théorème
est fondé sur les probabilités conditionnelles.
Arbre de décision C’est un algorithme d’apprentissage qui permet de
faire un classement ou une prédiction. Plus
spécifiquement, c’est un schéma sous la forme d’un
arbre qui présente les Data possibles d’une série de
choix interconnectés.
Séparateurs à vastes Les machines à vecteurs de support ou séparateur à
marges (SVM) vaste marge représentent un ensemble de techniques
d’apprentissage supervisé. Il ont pour but d’assurer
la séparation des données en classes à l’aide d’une
frontière simple. Cette frontière permet de séparer
les différents groupes de données de façon que la
distance entre eux soit la plus maximale.
Foret aléatoires Le random forest est composé de plusieurs arbres de
décision, entrainés de manière indépendante sur des
sous-ensembles du data set d'apprentissage (méthode de
bagging). Chacun produit une estimation, et c'est la
combinaison des résultats qui va donner la prédiction
finale qui se traduit par une variance réduite. [6]
Tableau 21: Algorithmes de classification
56
Dans notre cas, nous avons choisi les séparateurs à vastes marges (SVM), principalement
pour leur grande flexibilité et simplicité d’utilisation mais nous pouvons citer aussi que nous
parlons d’ un modèle de machine Learning très puissant et polyvalent, capable d’effectuer une
classification linéaire ou non linéaire.
2.2.4 Collecte de la base de données
Au niveau de cette étape, nous allons assurer la collecte de la base de données. Cette
dernière est composée des diverses données tel que ; les informations personnelles des
utilisateurs, les contraintes collectées pour chaque utilisateur ayant demandé en avant une
proposition de plan en choisissant des contraintes qui lui conviennent et les catégories
(positives, négatives) extraites du traitement des commentaires ou des avis de chaque
utilisateur.
2.2.5 Nettoyage des données de la base de données
Comme la base de données est formée d’une combinaison de plusieurs sources de données,
il est évident que les données peuvent êtres dupliquées ou incorrectes. De ce fait, nous parlons
alors du nettoyage des données.
En effet, c’est un processus de correction ou de suppression des données erronées, en
double ou incomplètes dans un jeu de données. Dans le cas de données incorrectes, les résultats
des algorithmes ne seront pas fiables et nous ne pouvons pas les utilisés. Pour cela il est crucial
de passer par le processus de nettoyage de données afin d’avoir des résultats de qualité.
Ce processus est constitué de plusieurs étapes, à compter :
• La suppression des données redondantes ou non pertinentes ;

• Correction des erreurs structurelles comme les fautes de frappes ;
• Filtrage des données aberrantes indésirables : dans ce cas d’abord il faut voir si sa
suppression contribuera à la performance des données ou non ;
• Gestion des données manquantes, comme option dans cette étape nous pouvons
entrer les valeurs manquantes en se basant sur les observations des données
similaires. Cette étape est importante car si nous supprimons tous les données
manquantes ça peut faire perdre des informations pertinentes ou biaiser les résultats
des algorithmes.
2.2.6 Prédiction des plans
Par définition la prédiction signifie essentiellement prédire un résultat futur en se basant

sur les données stockées. Nous allons donc prédire une proposition d’un plan qui va avec les
besoins de l’utilisateur.
57
En effet, la prédiction des plans qui peuvent intéresser nos utilisateurs fait référence aux
résultats issu de l’algorithme que nous devrons avoir préformé en utilisant un ensemble de
données historiques, principalement les données personnelles des utilisateurs et le résultat du
traitement de son avis ( le traitement sentimentale : négatif, positif).
Cette prédiction, permettra de prévoir le résultat d’un nouvel ensemble de données.
L’algorithme généré des valeurs probables qui seront dans notre cas les plans, au plus
spécifiquement les contraintes sélectionnées précédemment pas d’autres utilisateurs pour des
variables inconnues qui sont les nouveaux utilisateurs de l’application.
Elle permet également au système de notre application de faire des supposition précises,
ou de prédire l’attrition des clients à un espace publics ou une activité spécifique.
Conclusion
Ce dernier chapitre est composé de deux parties, la première partie est spécifique au 3éme
sprint où nous avons proposé les scénarios qui pourraient se produire pour chaque cas
d’utilisation, et présenté également les diagrammes de séquence système relatives à ces-
derniers. La deuxième partie du chapitre, a été consacrée au 4éme et dernier sprint issue de
notre backlog product. Dans ce sprint nous avons, décris les différents cas d’utilisation du
sprint backlog, notamment l’intégration de l’Intelligence Artificielle pour le cas d’utilisation
« Prédiction des plans ».
58
Conclusion Générale
Le présent rapport nous a permis de tracer les différentes parties de ce projet, au cours
duquel nous avons ressuis à atteindre notre objectif principal ; la conception d’une application
mobile de guide touristique au Médina de Tunis afin de faciliter les visites des touristes en
proposant des plans guidés.
Déterminées de trouver la meilleure solution, nous avons commencé en premier lieu avec
une étude préalable et la compréhension du contexte générale du projet pour pouvoir identifier
après les différentes exigences de notre application. Nous avons préparé par suite les outils et
l’architecture nécessaires pour le bon déroulement du projet ainsi que la planification de travail
tout en respectant les priorités des besoins issues de la discussion entre l’équipe du
développement et le directeur du produit. Cette démarche que nous avons réalisée nous a permis
au bout de notre travail d’atteindre parfaitement notre objectif principal.
Malgré toutes les difficultés rencontrées au niveau du processus du travail, ce projet été
une expérience supplémentaire qui nous a permis d’exploiter nos connaissances ainsi que de
d’acquérir d’autres notamment le pouvoir de gérer plus le temps, l’adaptation aux contraintes
auxquelles nous sommes confrontés ainsi que la bonne gestion des projets en suivant la culture
Agile. Nous avons également utilisé des différents logiciels tel que Star UML pour la
conception, Adobe Illustrator pour la réalisation du logo et Figma pour la présentation des
interfaces graphiques de l’application.
Notre travail ne s’arrête pas à ce niveau, en effet, nous pouvons terminer le développement
de l’application de guide touristique à la Médina de Tunis et assurer son déploiement, aussi
d’autres fonctionnalités peuvent être intégrées tel que la réalité augmentée que nous n’avons
pas pu terminer par faute de temps, ou plus l’ajout d’une partie pour les propriétaires des
espaces publics où ils peuvent proposer plus de leurs offres et envoyer des messages aux
utilisateurs en cas de promotions ou des évènements marquants.
Finalement nous n’avons qu’à exprimer notre satisfaction envers cette expérience
enrichissante qui sera le chemin pour réussir notre projet de fin d’étude.
59
Webographie
[1] : https://blog.hubspot.fr/marketing/benchmarking
[2] : https://fr.wikipedia.org/wiki/Acteur_(UML)#:~:text=En%20g%C3%A9ni
[3] : https://www.headmind.com/fr/text-mining-analyse-de-sentiments/
[4] : https://www.headmind.com/fr/text-mining-classification-automatique-de-
textes/#:~:text=Le%20processus%20de%20classification%20d,Machine%20Learning%20%2
F%20Deep%20Learning
[5] : https://www.talend.com/fr/resources/what-is-machine-
learning/#:~:text=Un%20algorithme%20est%20une%20s%C3%A9quence,'ex%C3%A9cutio
n%20d'une%20op%C3%A9ration
[6] : https://www.journaldunet.fr/web-tech/guide-de-l-intelligence-artificielle/1501905-
random-forest-ou-foret-aleatoire/
60
Annexe
Annexe A : Charte graphique du logo
1. Logo du Medina Explorer
Figure 26: Logo de l'application Medina Explorer
2. Présentation du logo
Il existe trois modèles de présentation du logo : Comme nous avons présenté, respectivement,
centrer, aligné à gauche, et une ligne.
3. Les composantes du logo

Le logo contient deux éléments : le symbole et la signature. Ces deux composantes sont
indissociables pour identifier officiellement toutes les activités de Medina Explorer.
61
4. Couleurs officielles du logo
5. Construction du logo
62
6. Versions du logo
7. Zone de protection
63

KR VF

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

KR VF

Transféré par

Droits d'auteur :

Formats disponibles

Table des matières

Introduction Générale ........................................................................................................................... 1

1.1 Idée du projet

1.2 Choix du nom et logo de l’application

« Medina Explorer », un nom significatif pour dire l’exploration de la Médina, plus

Et avec l’évolution du l’ère digitale, il est devenu indispensable de s’adapter aux

1.4 La mission du projet

Le benchmarking ou benchmark est une technique de marketing spécifique destinée à

2.1 Analyse des concurrents

• Un guide touristique privé , c’est un choix personnel , lorsque quelqu’un choisi un

Figure 1: Guide touristique privé

Figure 2: Page d'accueil du site « Guide voyage Tunisie »

Figure 3: Application mobile "Tunis médina guide"

Figure 4: Application « Get your guide »

2.2 Critique de l’existant

Nom de la Points fortes Point faibles

• Riche en • Longs paragraphes

• Solution gratuite ; • Application trop chargée

3. Solution proposée et objectifs poursuivis

Cette étude approfondie et comparative des différentes solutions existantes a permis de

L’SOAR est un outil d’évaluation et d’analyse au service de la planification stratégique,

Figure 5: Analyse SOAR de notre projet

5. Choix de la méthodologie de travail

5.1 Méthodologie prédictive

Les méthodes classiques de gestion de projet, également appelées méthodes traditionnelles,

Type du modèle Avantages Inconvénients

5.2 Méthodologie adaptative

Tableau 3:Comparatif entre itérative, incrémentale et agile

5.3 Méthodologie hybride

- Notre projet est assez complexe et long ;

6. Méthodologie de travail adoptée : Agile - Scrum

✓ Une communication et collaboration accrues (entre les membres de l’équipe et

Figure 6: Mode de fonctionnement du Scrum

✓ Il doit bien assurer le principe du Scrum dans son intégralité ;

1. Capture des besoins

1.1 Identification des acteurs

1.2 Spécification des besoins

L’objectif de cette partie est principalement la spécification détaillée et claire des

1.2.1 Exigences fonctionnelles

❖ Pour l’utilisateur (client)

1.2.2 Exigences non fonctionnelles

2.1 Outils utilisés

UML : Unified Modeling Language, ou

Tableau 5: Les différents outils utilisés dans notre projet

2.2 Pattern Architectural

Figure 7: Architecture MVC

3. Spécification des exigences

3.1 Diagramme de classe

Figure 8: Diagramme de classe de "Medina Explorer"

3.2 Diagramme de cas d’utilisation

Figure 9: Diagramme de Cas d'utilisation de "Medina Explorer"

4. Planification du traitement des cas d’utilisation

L’étape de planification et de structuration est primordiale dans un projet, afin d’assurer sa

4.2 Tableau Backlog produit du Medina Explorer

Id Fonctionnalités User story Estimation Priorité

En tant qu’un administrateur de 5 Jours Élevée

3 Gestion du En tant qu’un utilisateur, je veux 4 Jours Faible

4 Consultation En tant qu’un utilisateur, je veux 7 Jours Élevée

6 Donner un avis En tant qu’un utilisateur de 5 Jours Moyenne

9 Gestion des En tant qu’un administrateur de 7 Jours Élevée

En tant qu’un administrateur de 6 Jours Élevée

10 Gestion des En tant qu’un administrateur de 6 Jours Élevée

4.3 Définition des rôles du Scrum