Académique Documents
Professionnel Documents
Culture Documents
Page 1 sur 80
III.2 Les différents événements ......................................................................................................... 23
III.3 Les artefacts SCRUM ................................................................................................................ 24
Conclusion ............................................................................................................................................. 26
Chapitre 3 : Analyse et spécification des besoins.................................................................................. 27
Introduction ........................................................................................................................................... 27
I Description du langage de modélisation........................................................................................ 27
I.1 Les diagrammes de structure ou diagramme statique ................................................................ 27
I.2 Diagramme de comportement ou d’interaction ......................................................................... 28
II Identification des besoins .............................................................................................................. 29
II.1 Identification des acteurs ........................................................................................................... 29
II.1.1 Les acteurs internes ........................................................................................................... 29
II.1.2 Les acteurs externes ........................................................................................................... 29
II.2 Identification des besoins fonctionnels ..................................................................................... 30
II.2.1 Diagramme de cas d’utilisation globale ............................................................................ 31
II.3 Capture des besoins non fonctionnels ....................................................................................... 32
III Backlog du produit .................................................................................................................... 32
IV Les sprints.................................................................................................................................. 34
V Diagramme de GANTT ................................................................................................................. 36
VI Scénarios et cas d’utilisation ..................................................................................................... 37
VI.1 Scénario et cas d’utilisation « Ajouter plat »............................................................................. 37
VI.2 Scénario et cas d’utilisation « Supprimer plat » ........................................................................ 38
VI.3 Scénario et cas d’utilisation « modifier plat » ........................................................................... 39
VI.4 Scénario et cas d’utilisation « consulter un restaurant » ........................................................... 40
VI.5 Scénario et cas d’utilisation « Rechercher plat »...................................................................... 41
VI.6 Scénario de cas d’utilisation « rechercher un plat par prix »..................................................... 42
VI.7 Scénario et cas d’utilisation « créer commande » ............................................................. 43
VI.8 Scénario et cas d’utilisation « consulter liste des commandes à livrer » ................................... 44
VI.9 Scénario et cas d’utilisation « Géolocaliser client » .................................................................. 45
Scénario et cas d’utilisation « géolocaliser les restaurant à proximité » .................................. 46
VI.10 .................................................................................................................................................. 46
VI.11 Scénario et cas d’utilisation « valider commande » .......................................................... 47
Conclusion ............................................................................................................................................. 48
Chapitre 4 : Conception ......................................................................................................................... 49
Introduction ........................................................................................................................................... 49
I Description de la vue statique........................................................................................................ 49
I.1 Le diagramme de classes ........................................................................................................... 49
I.1.1 Description des attributs de classes .................................................................................. 51
Page 2 sur 80
II Description de la vue dynamique .................................................................................................. 53
II.1 Diagramme de séquence ............................................................................................................ 53
II.1.1 Diagramme de séquence relatif à « s’authentifier » .......................................................... 54
II.1. 2 Digramme de séquence « Ajouter plat » ............................................................................ 55
II.1.3 Diagramme de séquence « Supprimer plat »...................................................................... 56
II.1.4 Diagramme de séquence « Modifier plat » ........................................................................ 57
II.1.5 Diagramme de séquence « Consulter un restaurant » ........................................................ 58
II.1.6 Diagramme de séquence « créer commande » ................................................................... 59
II.1.7 Diagramme de séquence « Consulter la liste des plats à livrer » ....................................... 60
II.1.8 Diagramme de séquence « valider commande » ................................................................ 61
II.1.9 Diagramme de classe « Géolocaliser un client » ............................................................... 62
II.1.10 Diagramme de séquence « Géolocaliser restaurant à proximité » .................................... 63
III Conception graphique................................................................................................................ 64
III.1 Synopsis..................................................................................................................................... 64
III.1.1 Présentation du produit ...................................................................................................... 64
III.2 Scénario maquette ..................................................................................................................... 64
Conclusion ............................................................................................................................................. 67
Chapitre 5 : Réalisation ......................................................................................................................... 68
Introduction ........................................................................................................................................... 68
I Environnement de travail .............................................................................................................. 68
I.1 Environnement matériel ............................................................................................................ 68
I.2 Choix de l’architecture de l’application .................................................................................... 68
I.3 Environnement logiciel ............................................................................................................. 70
I.3.1 Les langages ...................................................................................................................... 70
I.3.1.1 HTML5 et CSS3 ................................................................................................................ 70
I.3.1.2 PHP 7.3.5 ........................................................................................................................... 70
I.3.1.3 JavaScript .......................................................................................................................... 70
I.3.1.4 SQL ................................................................................................................................... 70
I.3.2 La base de données : MySQL ............................................................................................ 70
I.3.3 CMS : WordPress .............................................................................................................. 70
I.3.4 Les outils supplémentaires ................................................................................................ 71
I.3.4.1 Sublime Text 3.2.2 ............................................................................................................ 71
I.3.4.2 MySQL Workbench 8.0.21 ............................................................................................... 71
I.3.4.3 Local by flywheel .............................................................................................................. 71
I.3.4.5 Basalmiq mockups by Adobe 3.5.17 ................................................................................. 72
I.3.5 Technologies utilisées ....................................................................................................... 72
I.3.5.1 Progessive Web App (PWA) ............................................................................................. 72
Page 3 sur 80
II Présentation des interfaces ............................................................................................................ 73
Conclusion générale .............................................................................................................................. 78
Bibliographie ......................................................................................................................................... 79
Webographie ......................................................................................................................................... 79
Page 4 sur 80
Dédicaces
A nos chers parents qui nous ont soutenu durant la réalisation de ce projet et pour tout
le mal qu’ils se sont donnés afin de nous faciliter la tâche, en témoignage de la profonde
affection que nous leurs portons.
A nos chers amis pour leurs présences et encouragements, qu’ils trouvent là toute notre
reconnaissance.
Page 5 sur 80
Remerciements
Nous remercions aussi le corps professoral de l’Université Aube Nouvelle, pour son
enseignement de qualité.
Nous remercions également nos familles et nos proches pour leur aide, conseil et soutien.
Nos remerciements s’adressent à nos amis avec qui nous partageons joies et peines.
Enfin, merci à tous ceux qui, de près ou de loin, nous ont épaulé durant nos études.
Page 6 sur 80
Liste des tableaux
Tableau 1. Comparaison entre les deux grandes familles de méthodes de développement. ................. 19
Tableau 2. Backlog du produit .............................................................................................................. 33
Tableau 3. Backlog du sprint 1 .............................................................................................................. 34
Tableau 4. Backlog du sprint 2 .............................................................................................................. 34
Tableau 5. Backlog du Sprint 3 ............................................................................................................. 35
Tableau 6. Backlog du Sprint 4 ............................................................................................................. 35
Tableau 7. Backlog du Sprint 5 ............................................................................................................. 36
Tableau 8. Backlog du sprint 6 .............................................................................................................. 36
Tableau 9. Description du cas d’utilisation « ajouter plat » .................................................................. 38
Tableau 10. Description du cas d’utilisation « Supprimer plat » .......................................................... 39
Tableau 11. Description du cas d’utilisation « Modifier plat » ............................................................. 39
Tableau 12. Description du cas d’utilisation « Consulter un restaurant » ............................................. 40
Tableau 13. Description du cas d’utilisation « rechercher un plat par nom » ....................................... 41
Tableau 14. Description du cas d’utilisation « rechercher un plat par prix » ........................................ 42
Tableau 15. Description du cas d’utilisation « créer une commande » ................................................. 43
Tableau 16. Description du cas d’utilisation « Consulter la liste des plats à livrer » ............................ 44
Tableau 17. Description du cas d’utilisation « Géolocaliser un client » ............................................... 45
Tableau 18. Description du cas d’utilisation « Géolocaliser les restaurants à proximité » ................... 46
Tableau 19. Description du cas d’utilisation « valider la commande » ................................................. 47
Tableau 20. Description des attributs de la table « Utilisateur » ........................................................... 51
Tableau 21. Description des attributs de la table « Restaurant » ........................................................... 51
Tableau 22. Description des attributs de la table « Plat »...................................................................... 52
Tableau 23. Description des attributs de la table « Commande » ......................................................... 52
Tableau 24. Description des attributs de la table « Gestionnaire_entreprise » ...................................... 53
Tableau 25. Présentation du produit ...................................................................................................... 64
Page 7 sur 80
Liste des figures
Figure 1.Organigramme de FASOSOFT ............................................................................................... 12
Figure 2. Le cycle de l'eXtreme Programming ...................................................................................... 16
Figure 3. Les phases essentielles du Two Tracks Unified Process (2TUP) .......................................... 18
Figure 4.comparaison entre les deux méthodes selon les statistiques de réussite de projets en 2012 ... 20
Figure 5.Taux d’utilisations des méthodes agiles.................................................................................. 21
Figure 6. Architecture générale de SCRUM . ....................................................................................... 22
Figure 7. L’incrément du produit (Product Increment). ........................................................................ 25
Figure 8. La hiérarchie de diagramme UML 2.5 sous forme de diagramme de classe. ........................ 29
Figure 9. Diagramme de cas d’utilisation.............................................................................................. 31
Figure 10. Le diagramme de GANTT ...................................................................................................... 37
Figure 11. Diagramme de cas d’utilisation « Ajouter plat » ................................................................. 37
Figure 12. Diagramme de cas d’utilisation « Supprimer plat » ............................................................. 38
Figure 13. Diagramme de cas d’utilisation « modifier plat » ................................................................ 39
Figure 14. Diagramme de cas d’utilisation « Consulter un restaurant »............................................... 40
Figure 15. Diagramme de cas d’utilisation « rechercher un plat par nom » ......................................... 41
Figure 16. Diagramme de cas d’utilisation « rechercher un plat par prix » .......................................... 42
Figure 17. Diagramme de cas d’utilisation « créer une commande » ................................................... 43
Figure 18. Diagramme de cas d’utilisation « Consulter la liste des plats à livrer » .............................. 44
Figure 19. Diagramme de cas d’utilisation « Géolocaliser un client ».................................................. 45
Figure 20. Diagramme de cas d’utilisation « Géolocaliser les restaurant à proximité » ....................... 46
Figure 21. Diagramme de cas d’utilisation « valider la commande » ................................................... 47
Figure 21. Le diagramme de classe ....................................................................................................... 50
Figure 22. Diagramme de séquence relatif à « authentifier » ................................................................ 54
Figure 23. Diagramme de séquence « Ajouter plat » ............................................................................ 55
Figure 24. Diagramme de séquence « Supprimer plat »....................................................................... 56
Figure 25. Diagramme de séquence « Modifier plat » .......................................................................... 57
Figure 26. Diagramme de séquence « Consulter un restaurant » .......................................................... 58
Figure 27. Diagramme de séquence « Créer commande » .................................................................... 59
Figure 28. Diagramme de séquence « Consulter la liste des plats à livrer » ......................................... 60
Figure 29. Diagramme de séquence « Valider la commande » ............................................................. 61
Figure 30. Diagramme de séquence « Géolocaliser un client » ............................................................ 62
Figure 31. Diagramme de séquence relatif à « Géolocaliser les restaurant à proximité »..................... 63
Figure 32. Gabarit de l’interface d’accueil ............................................................................................ 65
Figure 33. Gabarit de l’interface plat .................................................................................................... 65
Figure 34. Gabarit de l’interface de recherche de plats ......................................................................... 66
Figure 35. Gabarit de l’interface de géolocalisation des restaurants à proximité .................................. 67
Figure 36. Architecture 3-tiers (1er : client, 2ème : serveur web et 3ème : SGBD) ............................. 69
Figure 37. Page d’accueil ...................................................................................................................... 73
Figure 38. Capture d’écran de la page des plats .................................................................................... 74
Figure 39. Capture d’écran de la pages panier. ..................................................................................... 75
Figure 40 Capture d’écran de la page commande. ................................................................................ 76
Figure 41 Capture d’écran de la page de localisation des restaurants à proximité ................................ 77
Page 8 sur 80
Sigle et leur signification
Sigle Définitions
CU Cas d’Utilisation
PU Processus Unifier
XP Extreme Programming
Page 9 sur 80
Introduction générale
Depuis de nombreuses décennies, les systèmes d’informations sont présents dans les
organisations. D’abord sous forme physique ensuite sous forme électronique, ils prennent
quotidiennement une place de choix dans les organisations, d’une part à cause du renforcement
de la concurrence sur les marchés et la masse d’informations à gérer et, d’autre part, grâce au
développement constant des technologies de l’information et de la communication qui apporte
des solutions de plus en plus élaborées. Notre présente étude se porte sur les solutions
qu’apportent ces technologies dans le domaine de la restauration.
Le consommateur a pris l’habitude de se faire livrer de nombreux biens chez lui : vêtement,
livres, courses alimentaires, etc. Aujourd’hui, le client se fait livrer à son domicile tout ce qu’il
désire plutôt que de se rendre dans les magasins. Le client, grâce à son smartphone ou sa tablette
ou son ordinateur, peut contrôler et effectuer tous ses achats depuis son domicile. Ce
phénomène se développe dans plusieurs secteurs comme l’hôtellerie avec l’apparition de site
de réservation, le transport, etc. C’est pour contribuer à renforcer le développement de telles
solutions que nous avons décidé d’apporter une solution dans le domaine de la restauration :
commander un plat et se faire livrer.
Le marché de livraison de repas à domicile est devenu un vrai secteur dans le milieu de la
restauration où un réel enjeu économique se joue vu la journée continue de travail adopté dans
l’administration publique et le dynamisme des jeunes dans le secteur de l’auto-emploi. Depuis
2012, de nombreuses solutions ont commencé à émerger mais la plupart utilisent les réseaux
sociaux et/ou appartiennent à des restaurants. La plupart aussi concernent la ville de
Ouagadougou. Nous voulons proposer aux consommateurs de Bobo-Dioulasso pour
commencer, une application multiplateforme (web et mobile) pouvant agréger plusieurs
restaurants avec les services de commandes, de livraison pour particulier ou pour entreprise et
un système de suivi.
Ce rapport, synthèse de notre travail, s’articulera sur cinq (5) chapitres : dans le premier chapitre
nous présenterons le contexte du projet, ensuite dans le deuxième nous choisirons la
méthodologie de développement. Dans le troisième nous ferons l’analyse et la spécification des
besoins. Le quatrième chapitre se concentrera sur la conception et le cinquième chapitre
exposera la réalisation.
Page 10 sur 80
Chapitre 1 : Contexte du stage
Introduction
Au terme de nos trois (3) années de formation en Licence Informatique à l’université
Aube Nouvelle de Bobo Dioulasso, nous avons effectué un stage de fin de cycle au sein
de l’entreprise FASOSOFT en partenariat avec le restaurant BARAKA. Dans ce
chapitre, nous présenterons d’abord l’université Aube Nouvelle. Ensuite nous
présenterons la structure d’accueil FASOSOFT et le restaurant partenaire BARAKA.
Enfin nous décrirons la problématique de notre étude, ses objectifs et ses résultats
attendus.
I Présentation de l’université
I.1 Historique
L’Université Aube Nouvelle de Bobo-Dioulasso est un établissement d’enseignement supérieur
dont les origines remontent à l’Institut Supérieur d’Informatique de Gestion (ISIG) créé en
octobre 1992 par arrêté N °92-89 et ses modificatifs 2005-244/MESSRS/CAB du 02 décembre
2005.
Page 11 sur 80
❖ Institut Supérieur d'Informatique et de Gestion (ISIG) avec deux départements:
Business School et High Tech. Le département High Tech comprend les filières
Technologie du Génie électrique, Technologie des Réseaux et Système et Technologie
du Génie Informatique dont nous relevons.
II Présentation de FASOSOFT
II.1 Historique
FasoSoft est une Société de Service en Ingénierie Informatique (SSII) créée en 2017. Ils sont
spécialisés dans le Développement de solutions informatiques, l’Intégration des systèmes,
l’Infogérance et la Formation. Ils travaillent à offrir les meilleures solutions (CMS, e-
Commerce, Intranet, ERP, CRM, GED, etc.) aux entreprises et particuliers.
Directeur Général
Responsable
Directeur
Marketing et Directeur Technique
Administratif
Commercial
Page 12 sur 80
III Présentation du restaurant partenaire BARAKA
Le restaurant BARAKA a vu le jour en 2014 à Bobo-Dioulasso. Il est situé sur la voie qui sépare
le lycée mixte d’Accart Ville et le lycée privé d’Accart Ville auquel il fait face. Durant nos trois
mois de stage nous avons travaillé en collaboration avec le restaurant BARAKA qui nous a
fourni beaucoup d’informations sur la gestion du restaurant toute chose qui nous a permis de
concevoir un système qui répond aux besoins des utilisateurs.
IV Présentation du thème
IV.1 Problématique du thème
De plus en plus au Burkina Faso les restaurants ouvrent leurs portes pour satisfaire la demande
qui s’est amplifiée avec l’instauration de la journée continue de travail. La plupart d’entre eux
rencontre néanmoins des difficultés liées à leur gestion telles que :
• Le manque de visibilité ;
• Le problème d’accessibilité ;
• La difficulté de commander un plat et de le faire parvenir chez soi ;
• La difficulté de retrouver un restaurant quand on est nouveau dans une localité.
IV.2 Objectif
L’objectif du projet est de proposer une application multiplateforme (Web et Mobile) qui
permettra aux utilisateurs d’éviter la perte de temps et d’argent à la recherche de restaurants et
de moyens de se faire livrer un plat.
Page 13 sur 80
IV.3 Résultat attendu
Le résultat attendu est de fournir une application multiplateforme (Web et Mobile) qui puisse
faciliter la restauration de la population active. Pour cela, elle disposera :
Conclusion
En somme, le présent chapitre nous a permis de présenter l’université Aube Nouvelle et les
structures d’accueil FASOSOFT et BARAKA qui ont bien voulu nous accompagner pour ce
stage. Par ailleurs, nous avons également fait la présentation du thème. Cette première partie
nous servira de guide pour la suite de notre étude dont l’étape suivante consiste à décrire la
méthodologie de conduite de projet adoptée et les outils afférents.
Page 14 sur 80
Chapitre 2 : Méthode de conduite de projet
Introduction
Une méthode de conduite de projet est un procédé qui a pour objectif de permettre la
formalisation des étapes préliminaires du développement d’un système afin de rendre ce
développement plus fidèle aux besoins du client. Pour choisir la méthodologie à suivre, nous
avons d’abord effectué une étude générale sur ces méthodologies, puis nous avons fait une
comparaison et enfin nous avons choisi celle adaptée pour le développement de notre
application. C’est ce que retrace le présent chapitre de notre document.
Les méthodes agiles reposent sur une structure commune (itérative, incrémentale et adaptative).
Ces itérations sont en fait des mini-projets définis avec le client en détaillant les différentes
fonctionnalités qui seront développées en fonction de leurs priorités. Le chef de projet établît
alors un macro planning correspondant aux tâches nécessaires pour le développement de ces
fonctionnalités.
Page 15 sur 80
● Une phase d'exploration détermine les scénarios client à fournir pendant l’itération ;
● L’équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels ;
● Chaque développeur s'attribue des tâches et les réalise avec un binôme ;
● Lorsque tous les tests fonctionnels passent, le produit est livré.
Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le cycle
de la première livraison se caractérise par sa durée et le volume important de fonctionnalités
embarquées. Après la première mise en production, les itérations peuvent devenir plus courtes
(une semaine par exemple).
I.1.2 SCRUM
Le principe de base de SCRUM est de focaliser l’équipe sur une partie limitée et maitrisable
des fonctionnalités à réaliser. Ces fonctionnalités se réalisent successivement, pendant des
périodes de durée fixe, de durée de 1 à 4 semaines, appelée sprints. Chaque sprint possède un
but à atteindre, définit par le propriétaire du produit, à partir du quelle sont choisies les
fonctionnalités à incrémenter. Un sprint aboutit toujours à la livraison d’un produit partiel
fonctionnel.
Page 16 sur 80
I.2.1 Rational Unified Process (RUP)
RUP est l’une des plus célèbres implémentations de la méthode PU permettant de donner un
cadre au développement logiciel. Elle répond aux exigences fondamentales préconisées par les
fondateurs d’UML :
Il commence par une étude préliminaire qui consiste essentiellement à identifier les acteurs qui
vont interagir avec le système à construire, les messages qu’échangent les acteurs et le système,
puis à produire le cahier des charges et à modéliser le contexte.
• Une branche technique : elle capitalise un savoir-faire technique et/ou des contraintes
techniques. Les techniques développées pour le système le sont indépendamment des
fonctions à réaliser.
• Une branche fonctionnelle : cette branche capitalise la connaissance du métier de
l’entreprise. Elle capture les besoins fonctionnels, ce qui produit un modèle focalisé sur
le métier des utilisateurs finaux.
• Une phase de réalisation : elle consiste à réunir les deux branches, permettant de mener
une conception applicative et enfin la livraison d’une solution adaptée aux besoins.
Page 17 sur 80
Figure 3. Les phases essentielles du Two Tracks Unified Process (2TUP)
Le tableau ci-dessous (Tableau 1) fait une comparaison entre les deux familles de méthodes
étudiées.
Page 18 sur 80
Tableau 1. Comparaison entre les deux familles de méthodes de développement étudiées
Page 19 sur 80
Thème Approche traditionnel Approche agile
Gestion des risques Processus distinct, rigoureux, de gestion Gestion des risques intégrée
des risques. dans le processus global, avec
responsabilisation de chacun
dans l’identification et la
résolution des risques. Pilotage
par les risques.
Mesure du succès Respect des engagements initiaux en Statistique client par la livraison
termes de couts, de budget et de niveau de de valeur ajoutée.
qualité.
Figure 4.comparaison entre les deux méthodes selon les statistiques de réussite de projets en 2012
Suite à cette comparaison entre ces deux familles de méthodes nous réalisons que la méthode
agile est la plus appropriée pour le développement de notre application car elle caractérise un
mode de gestion de projet privilégiant le dialogue entre toutes les parties prenantes avec un
Page 20 sur 80
contrôle de qualité précoce et permanent, ce qui permet d’obtenir un produit qui répond aux
exigences spécifiées par le client.
Cette figure ci-dessous représente une étude du taux d’utilisation des méthodes agiles sur la
gestion des projets informatiques.
Suite à l’étude de cette figure nous constatons que la méthode agile « SCRUM » est la plus
utilisée et celle qui est adaptée au mieux à l’élaboration de notre projet, ce qui nous amène à
porter notre choix sur celle-ci.
Page 21 sur 80
principes de la méthode Agile, c’est-à-dire l’implication et la participation active du client tout
au long du projet.
❖ Des rôles ;
❖ Des évènements ;
❖ Des artéfacts ;
❖ Des règles.
Page 22 sur 80
• Le Product Owner : cet acteur porte la vision du produit à réaliser. Il travaille en
interaction avec l’équipe de développement qui doit suivre ses instructions. C’est lui qui établit
la priorité des fonctionnalités à développer ou à corriger et qui valide les fonctionnalités
terminées. Il est responsable de la gestion du Product backlog (ou carnet de produit en français).
• Le Sprint
Un Sprint est une itération. Il s’agit d’une période de deux à quatre semaines maximums
pendant laquelle une version terminée et utilisable du produit est réalisée. Un nouveau Sprint
commence dès la fin du précédent. Chaque Sprint a un objectif et une liste de fonctionnalités à
réaliser.
• Planification du Sprint
Les tâches à accomplir pendant le Sprint sont déterminées par l’ensemble de l’équipe SCRUM
lors de la réunion de planification de Sprint. La durée de cette réunion est limitée à huit (8)
heures pour les Sprints d’un mois. Cette réunion permet à l’équipe d’établir les éléments qu’elle
traitera au cours de ce Sprint et comment elle procédera.
• Revue du Sprint
Il s’agit du bilan du Sprint réalisé. Une fois le Sprint terminé, l’équipe SCRUM et les parties
prenantes se réunissent pour valider ce qui a été accompli pendant le Sprint. Cette réunion dure
4 heures maximum.
• Rétrospective du Sprint
Cette réunion est interne à l’équipe SCRUM et dure 3 heures pour un Sprint d’un mois. Le but
est l’adaptation aux changements qui peuvent survenir et l’amélioration continue du processus
Page 23 sur 80
de réalisation. L’équipe passe en revue le Sprint terminé afin de déterminer ce qui a bien
fonctionné et ce qu’il faut améliorer.
• Mêlée quotidienne
Cette réunion quotidienne de 15 minutes est très importante. Elle se fait debout et a pour but de
faire un point sur la progression journalière du Sprint. Elle permet à l’équipe de synchroniser
ses activités et de faire un plan pour les prochaines 24 heures.
La mêlée a lieu chaque jour aux mêmes heures. Chaque membre de l’équipe de développement
doit répondre à ces trois questions :
Il s’agit d’une liste hiérarchisée des exigences initiales du client concernant le produit à réaliser.
Ce document évolue sans cesse durant le projet, en fonction des besoins du client. Le Product
owner est responsable du Product backlog.
• L’incrément
C’est un élément très important de la culture Agile. Durant chaque sprint l’équipe de
développement réalise un incrément de produit. Il s’agit de l’ensemble des éléments terminés
du product backlog pour le Sprint en cours, ainsi que ceux des Sprint précédents. L’incrément
doit fonctionner et être utilisable.
Page 24 sur 80
Figure 7. L’incrément du produit (Product Increment).
Ce graphique simple indique l’état d’avancement dans la réalisation des tâches du Sprint. Il
s’agit du tracé de la charge de travail restante en fonction du temps. Le Burndown Chart est
actualisé tous les jours par le SCRUM Master après la mêlée quotidienne.
• La User Story
Une user story est une sorte de carte d’identité qui définit la fonctionnalité ou la tâche à
développer. Une user story se doit de comporter les éléments suivants :
Une estimation est fournie à chaque user story, c’est-à-dire donner un nombre de point (1, 2, 3,
4, etc.) qui va qualifier la complexité de la story. Elle est réalisée en équipe durant l’une des
cérémonies SCRUM. L’importance d’utiliser des chiffres abstraits pour évaluer une user story
est de permettre aux individus ayant des compétences, et des vitesses d’exécutions différentes,
de se mettre d’accord.
Page 25 sur 80
Conclusion
Dans ce chapitre, nous avons défini et énuméré les différents types de méthodes de conduite de
projet. Nous avons cité quelques exemples de méthodes, fait une comparaison qui nous a amené
à choisir la méthode SCRUM que nous allons mettre en œuvre dans les chapitres suivants.
Page 26 sur 80
Chapitre 3 : Analyse et spécification des besoins
Introduction
Après avoir présenté la méthode de conduite de projet, nous procéderons dans ce chapitre à la
détermination des besoins fonctionnels et non fonctionnels auxquels notre application doit
répondre. Dans un second temps nous allons présenter le backlog du produit, suivi par les
sprints à réaliser, et enfin terminer par une conclusion.
Dans notre étude, nous avons utilisé le langage de modélisation unifié UML (Unified Modeling
Langage) pour spécifier les besoins et faire la conception de notre application. UML est utilisé
pour spécifier, visualiser, modifier et construire les documents nécessaires au bon
développement d’une application orienté objet. Il offre un standard de modélisation pour
représenter l’architecture logiciel. UML propose 14 types de diagramme dont 7 sur la structure
de l’application et 7 sur sa dynamique (comportement).
Page 27 sur 80
I.2 Diagramme de comportement ou d’interaction
Les diagrammes de comportement rassemblent :
Ces diagrammes sont présentés dans UML 2.5 sous deux types de vues :
• D’un point de vue statique ou structurel du domaine avec les diagrammes de structure ;
• D’un point de vue dynamique avec les diagrammes de comportement ou d’interactions.
Page 28 sur 80
Figure 8. La hiérarchie de diagramme UML 2.5 sous forme de diagramme de classe.
Page 29 sur 80
II.2 Identification des besoins fonctionnels
Les cas d’utilisations peuvent être décrits comme suit :
• Afficher la carte :
o permet au livreur de voir la position géographique du client afin de lui livrer sa
commande ;
o permet également à un client de géolocaliser les restaurants les plus proches de
sa position.
• Gérer les plats : permet au responsable du restaurant d’afficher l’interface lui
permettant d’ajouter, de supprimer et de modifier les plats de son restaurant ;
• Consulter la liste des commandes à livrer : permet au livreur de consulter la liste des
commandes à livrer ;
• Consulter les plats d’un restaurant : permet à un client de visualiser les plats que
proposent un restaurant ;
• Rechercher un plat : permet à un client de rechercher un plat selon des critères comme
le nom du plat, les ingrédients du menu, la popularité, le tarif croissant ou décroissant ;
• Créer une commande : permet à un client de créer une commande en ajoutant un ou
plusieurs plats dans un panier ;
• Valider la commande : permet à un client de valider sa commande créée et de se faire
livrer ;
• Gérer les informations de l’entreprise : permet au Gestionnaire de l’entreprise de
Page 30 sur 80
II.2.1 Diagramme de cas d’utilisation globale
Rechercher par popularité
Consulter un retaurant
Rechercher par nom
Rechercher un plat
Rechercher par prix
<<include>>
<<extend>> Ajouter quantité
Creér une commande
<<include>>
Geolocaliser les restaurants à proximité Afficher la Carte
<<include>> <<include>>
Consulter la liste des commandes à livrer
Livreur Geolocaliser un client
<<include>>
S'authentifier
Gerer les informations de l'entreprise
<<include>>
Gestionnaire entreprise
<<include>>
gerer plat
Supprimer plat
Responsable du restaurant
Afficher plat
Modifier plat
Ajouter plat
Page 31 sur 80
II.3 Capture des besoins non fonctionnels
Les besoins non fonctionnels représentent les exigences implicites auxquelles le système doit
répondre. Parmi ces besoins on peut citer :
• La sécurité : l’application doit respecter la confidentialité des données.
• La haute disponibilité : l’application doit être opérationnelle tous les jours.
• L’Ergonomie : l’application doit satisfaire les critères ergonomiques que sont la
lisibilité, le guidage et la facilité d’utilisation.
• La Portabilité : l’application doit être accessible via n’importe quel navigateur.
• L’Adaptabilité : l’application doit pouvoir s’adapter à plusieurs terminaux.
• Une description : Pour bien décrire les user story un formalisme est utilisé « En tant que
X, je veux Y, afin de Z ».
− X est l’utilisateur qui va en bénéficier.
− Y est une fonctionnalité.
− Z est le bénéfice de la fonctionnalité.
• Une estimation initiale de l’équipe pour cette story : généralement cette case est vide au
moment où le Product Owner insère la user story dans le backlog ; elle est complétée par la
suite durant le round d’estimation avec l’équipe.
• L’importance de la story : le Product Owner attribut un numéro à chaque user story en
fonction de son niveau d’importance.
Page 32 sur 80
Tableau 2. Backlog du produit
Page 33 sur 80
IV Les sprints
Chaque sprint est constitué d’une liste de fonctionnalités à réaliser. La réalisation de ces sprints
dure deux (2) à quatre (4) semaines maximums et doit permettre d’atteindre un objectif de sprint
défini au début de celui-ci. Les différentes fonctionnalités sont découpées en tâches qui pourront
être réalisées.
Page 34 sur 80
Tableau 5. Backlog du Sprint 3
Page 35 sur 80
Tableau 7. Backlog du Sprint 5
V Diagramme de GANTT
Le diagramme de GANTT offre une représentation permettant de renseigner et situer dans le
temps les phases, les activités, les taches et les ressources du projet. Avant d’entamer les
différents sprints, nous avons tracé un diagramme de GANTT (figure 10) que nous allons suivre
pour réaliser notre projet.
Page 36 sur 80
Figure 10. Le diagramme de GANTT
<<include>>
Ajouter plat S'authentifier
Responsable du restaurant
Page 37 sur 80
Tableau 9. Description du cas d’utilisation « ajouter plat »
SOMMAIRE D’IDENTIFICATION
Retour à l’enchainement 3)
<<include>>
Supprimer plat S'authentifier
Responsable du restaurant
Page 38 sur 80
Tableau 10. Description du cas d’utilisation « Supprimer plat »
SOMMAIRE D’IDENTIFICATION
Alternatif
<<include>>
Modifier plat S'authentifier
Responsable du restaurant
SOMMAIRE D’IDENTIFICATION
Page 39 sur 80
4. Le système envoie un message pour notifier que la modification a été
bien effectuée
Retour à l’enchainement 2)
Consulter un retaurant
Client
SOMMAIE D’IDIENTIFICATION
Acteur Client
Page 40 sur 80
VI.5 Scénario et cas d’utilisation « Rechercher plat »
SOMMAIRE D’IDENTIFICATION
Acteur Client
Page 41 sur 80
VI.6 Scénario de cas d’utilisation « rechercher un plat par prix »
SOMMAIRE D’IDENTIFICATION
But Ce cas d’utilisation permet à un client de filtrer les plats par prix
Acteur Client
Page 42 sur 80
VI.7 Scénario et cas d’utilisation « créer commande »
<<include>>
Ajouter quantité
SOMMAIRE D’IDENTIFICATION
Acteur Client
Alternatif
Page 43 sur 80
VI.8 Scénario et cas d’utilisation « consulter liste des commandes à livrer »
Cas D'utilisation <Consulter la
liste des commandes à livrer>
S'authentifier
Figure 18. Diagramme de cas d’utilisation « Consulter la liste des plats à livrer »
Tableau 16. Description du cas d’utilisation « Consulter la liste des plats à livrer »
SOMMAIRE D’IDENTIFICATION
But Ce cas d’utilisation de visualiser toutes les commandes qui lui sont assignée
Acteur Livreur
Page 44 sur 80
VI.9 Scénario et cas d’utilisation « Géolocaliser client »
Cas d'Utilisation<Geolocaliser un client>
Afficher la Carte
Geolocaliser un client
Livreur
<<i ncl ude>>
SOMMAIRE D’IDENTIFICATION
Acteur Livreur
Page 45 sur 80
VI.10 Scénario et cas d’utilisation « géolocaliser les restaurant à proximité »
<<include>>
SOMMAIRE D’IDENTIFICATION
Acteur Client
Post conditions Le système affiche les restaurants à proximité sur la carte Google Maps
Alternatif
Page 46 sur 80
VI.11 Scénario et cas d’utilisation « valider commande »
<<include>>
Valider la commande
Client
SOMMAIRE D’IDENTIFICATION
Acteur Client
Enchainement 1. Le client confirme la liste des plats choisit avec leurs quantités
2. Le client remplit le formulaire de validation
3. Le système envoie un message pour notifier que la commande a été
bien enregistrée
Page 47 sur 80
Conclusion
Ce troisième chapitre a été consacré à l’identification et la spécification des besoins. Nous avons
détaillé le backlog de produit ainsi que les diagrammes de cas d’utilisation. Nous avons aussi
présenté nos sprints que nous devons respecter tout au long de la réalisation du projet. Dans le
chapitre suivant nous allons entamer la phase de conception de notre application.
Page 48 sur 80
Chapitre 4 : Conception
Introduction
Après avoir énuméré et spécifié les besoins du projet, la phase de conception définit les
composants qui permettront de les mettre en œuvre. Premièrement nous allons entamer la
conception technique en décrivant les vues statiques et dynamiques du système en utilisant les
diagrammes UML appropriés et ensuite présenter la conception graphique de notre projet.
Page 49 sur 80
Utilisateur
- id_ut : int
- nom_ut : String
- prenom_ut : String
- email_ut : String
- telephone-ut : String
- long_ut : String
- lat_ut : String
+ Se_connecter ()
Gestionaire_entreprise
1..*
0..*
Restaurant
- id_resto : int Commande 0..*
- nom_resto : String 0..* - id_comm : int
- long_resto : String - date_comm : Date
- lat_resto : String - statut_comm : boolean
- telephone_resto : String
- email_resto : String 1..1
0..*
1..*
Plat
- id_plat : int
- nom_plat : String
- constutient_plat : String
- prix_plat : double
1..*
Page 50 sur 80
I.1.1 Description relative aux attributs des différentes tables de la base de
données
Le tableau suivant contient une description des différents attributs de la table « Utilisateur »
Attribut Description
Attribut Description
Page 51 sur 80
lat_resto C’est un attribut de type « Varchar2 », il représente la latitude du
restaurant
Attribut Description
Attribut Description
Page 52 sur 80
Le tableau suivant contient la description des attributs de la table « Gestionnaire_entreprise »
Tableau 24. Description des attributs de la table « Gestionnaire_entreprise »
Attribut Description
Dans les lignes suivantes nous présentons les diagrammes de séquence en fonction de notre
diagramme de cas d’utilisation.
Page 53 sur 80
II.1.1 Diagramme de séquence relatif à « s’authentifier »
Authentification de l'utilisateur
Systeme BDD
Utilisateur
Demmander Authentification()
Afficher le formulaire()
Verification
Envoyer resultat()
alt Authentifié
Non Authentifié
Page 54 sur 80
II.1.2 Digramme de séquence « Ajouter plat »
Ajouter plat
Systeme BDD
Responsable_restaurant
ref
Authentification de l'utilisateur()
Remplir formulaire
Envoyer resultat()
Message de confirmation()
Page 55 sur 80
II.1.3 Diagramme de séquence « Supprimer plat »
Supprimer Plat
Systeme BDD
Responsable_restaurant
ref
Authentification de l'utilisateur()
supprimer plat()
Envoyer resultat()
Message de confirmation()
Page 56 sur 80
II.1.4 Diagramme de séquence « Modifier plat »
Modifier Plat
Systeme BDD
Responsable_restaurant
ref
Authentification de l'utilisateur()
Afficher information()
Envoyer resultat()
Message de confirmation()
Page 57 sur 80
II.1.5 Diagramme de séquence « Consulter un restaurant »
Consul ter un restaurant
Systeme BDD
Uti l i sateur
Demarer l 'Appl i cati on()
Envoyer Reponse()
Page 58 sur 80
II.1.6 Diagramme de séquence « créer commande »
Créer une commande
Systeme
Utilisateur
Page 59 sur 80
II.1.7 Diagramme de séquence « Consulter la liste des plats à livrer »
Consul ter l a l i ste des commandes assi gnées
Systeme BDD
Li vreur
ref
Authenti fi cati on de l 'uti l i sateur()
Envoyer reponse()
Page 60 sur 80
II.1.8 Diagramme de séquence « valider commande »
Valider une commande
Systeme BDD
Utilisateur
ref
Créer une commande()
Valider la Commande()
Enregistrement(commande,informations personnels)
Page 61 sur 80
II.1.9 Diagramme de classe « Géolocaliser un client »
Geolocaliser client
Livreur
ref
Consulter la liste des commandes assignées()
Envoyer resultat()
Retourner carte()
Afficher carte()
Page 62 sur 80
II.1.10 Diagramme de séquence « Géolocaliser restaurant à proximité »
Geolocaliser un restaurant à proximité
Utilisateur
Retourner la carte()
Afficher la carte()
Page 63 sur 80
III Conception graphique
III.1 Synopsis
C’est l’une des étapes les plus intéressantes dans la scénarisation puisqu’il contient une
description du projet qui nous aide à avoir une idée du résultat final.
Public cible Cette application est destinée à tous les utilisateurs ayant accès à l’internet.
Page 64 sur 80
Figure 33. Gabarit de l’interface d’accueil
Page 65 sur 80
Interface de recherche de plat : il s’agit de l’interface qui permettra à l’utilisateur de rechercher
un plat afin d’ajouter une quantité dans le panier.
Page 66 sur 80
Interface de géolocalisation des restaurants à proximité : il s’agit de l’interface qui affiche les
restaurants proches de l’utilisateur.
Conclusion
Ce quatrième chapitre a été consacré à la description des vues dynamique et statique. Nous
avons présenté les diagrammes de classe et de séquence. Nous avons aussi présenté nos
maquettes qui reflètent le résultat final de notre futur système. Dans le chapitre suivant nous
allons présenter la phase de réalisation de notre application.
Page 67 sur 80
Chapitre 5 : Réalisation
Introduction
Après avoir détaillé la conception adaptée à notre application, nous allons consacrer le dernier
chapitre de ce rapport à la partie réalisation. De ce fait, nous allons présenter dans un premier
lieu l’environnement matériel et logiciel de développement, par la suite, nous présenterons et
décrirons quelques interfaces de notre application.
I Environnement de travail
I.1 Environnement matériel
Pour la réalisation de notre projet, nous avons utilisé deux ordinateurs :
• Un ordinateur de marque DELL
o Système d’exploitation : Windows 10 ;
o Processeur : Intel(R) Core (TM) i5-2520M CPU @ 2.50GHz ;
o Mémoire vive : 8Go ;
o Disque dure : 500 Go.
➢ Vue ou présentation :
Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle
alors d'Interaction Homme Machine. En informatique, elle peut être réalisée par une application
graphique ou textuelle. Elle peut aussi être représentée en HTML pour être exploitée par un
navigateur Web. La couche présentation relaie les requêtes de l'utilisateur à destination de la
couche métier, et en retour lui présente les informations renvoyées par les traitements de cette
couche.
Page 68 sur 80
requêtes des utilisateurs, effectuées au travers de la couche présentation. Les différentes règles
de gestion et de contrôle du système sont mises en œuvre dans cette couche.
La couche métier offre des services applicatifs et métiers à la couche présentation. Pour fournir
ces services, elle s'appuie, le cas échéant, sur les données du système, accessibles au travers des
services de la couche inférieure. En retour, elle renvoie à la couche présentation les résultats
qu'elle a calculés.
Elle consiste en la partie gérant l'accès aux données du système. Ces données sont pérennes, car
destinées à durer dans le temps, de manière plus ou moins longue ou définitive. Les données
peuvent être stockées indifféremment dans de simples fichiers texte, ou XML, ou encore dans
une base de données. Quel que soit le support de stockage choisi, l'accès aux données doit être
le même. Cette abstraction améliore la maintenance du système.
Pour résumer notre choix en matière d’architecture, on peut résumer et dire que nous
choisissons le Design Pattern MVC pour :
• Avoir les meilleures performances vu le partage des tâches entre les différents serveurs ;
• Avoir une aisance lors de la conception, une conception qu’on veut claire et efficace ;
• Avoir plus de flexibilité dans l’allocation des ressources et dans les requêtes du client
vers le serveur. Le client qui n’a donc que des fonctions d’affichage ne fait que des
requêtes vers le serveur, aucun calcul n’est effectué par le client. Les résultats de ses
requêtes sont ensuite affichés.
Figure 37. Architecture 3-tiers (1er : client, 2ème : serveur web et 3ème : SGBD)
Page 69 sur 80
I.3 Environnement logiciel
I.3.1 Les langages
I.3.1.1 HTML5 et CSS3
HTML est un langage de « structuration » de pages web dont le rôle est
de formaliser l'écriture d'un document avec des balises de formatage. Les
balises permettent d'indiquer la façon dont doit être présenté le document
et les liens qu'il établit avec d'autres documents.
I.3.1.3 JavaScript
JavaScript est un langage de programmation orienté objet, de scripts
principalement employés dans les pages web interactives et à ce titre est
une partie essentielle des applications web.
I.3.1.4 SQL
Le langage SQL (acronyme de Structured Query Language) est un
langage informatique normalisé servant à exploiter des bases de données
relationnelles. La partie langage de manipulation des données de SQL
permet de rechercher, d’ajouter, de modifier ou de supprimer des
données dans la base de données relationnelles.
Page 70 sur 80
WordPress est un système de gestion de contenu gratuit, libre et open-source.
Ce logiciel écrit en PHP repose sur une base de données MySQL et est
distribué par la fondation WordPress.org. Les fonctionnalités de WordPress
lui permettent de créer et gérer différents types de sites web.
Page 71 sur 80
I.3.4.5 Basalmiq mockups by Adobe 3.5.17
Balsamiq Mockups créé par la société Adobe est un outil permettant de créer
facilement des prototypes d’IHM électronique. Avec Balsamiq Mockups, il
est possible de prototyper tout type d’applications (desktop, web,
smartphone, ...).
Page 72 sur 80
II Présentation des interfaces
Page 73 sur 80
Figure 39. Capture d’écran de la page des plats
Page 74 sur 80
Figure 40. Capture d’écran de la pages panier.
Page 75 sur 80
Figure 41 Capture d’écran de la page commande.
Page 76 sur 80
Figure 42 Capture d’écran de la page de localisation des restaurants à proximité
Page 77 sur 80
Conclusion générale
Le travail présenté dans ce rapport a pour objectif la réalisation d’une application
multiplateforme (web et mobile) de commande/livraison de plats de restaurants dans le but
d’éviter la perte de temps et d’argent dans la recherche de restaurants et de moyens de se faire
livrer.
Nous avons analysé la problématique et nous sommes arrivés à concevoir une application
multiplateforme comme solution efficace et bénéfique pour les entreprises, restaurateurs ainsi
que les utilisateurs simples. Pour cela nous avons mené en premier lieu une présentation de
l’organisme d’accueil. Ensuite, nous avons analysé et choisi la méthodologie de développement
à utiliser tout au long du projet, et nous avons décrit le langage de modélisation pour la
conception de notre application qui est le langage UML. Nous avons également recensé les
acteurs qui interagissent avec l’application, et décrit les besoins de chaque acteur sous forme
de cas d’utilisation. Par ailleurs, pour chaque cas d’utilisation, nous avons établi le diagramme
de séquence dont l’objectif est de représenter les interactions entre les objets du système en
indiquant la chronologie des échanges. Après la vue dynamique nous sommes passés à la vue
statique représentée par le diagramme de classe. Enfin, nous avons montré les phases de la
réalisation de notre application tout en spécifiant les outils de développements ainsi que les
langages de programmation utilisés, suivi d’un aperçu des interfaces que comprend celle-ci.
Ce travail nous a permis d’acquérir une expérience personnelle et professionnelle. Il nous a été
très bénéfique car nous avons eu la chance d’améliorer nos connaissances dans le domaine de
la conception que ce soit sur le plan théorique ou pratique.
Page 78 sur 80
Bibliographie
❖ OUEDRAOGO Ibrahim. Réalisation d’une application de livraison de produits
pharmaceutiques. Rapport de stage de fin de cycle Licence. Université Aube nouvelle,
2018.
❖ BAMOUNI Théophile. Réalisation d’un site web institutionnel : cas de U-Auben
Rapport de stage de fin de cycle Licence. Université Aube nouvelle, 2017.
❖ Marwa KESRAOUI. Mémoire de stage de fin d’études de Master professionnel.
Université Virtuelle de Tunis, 2014.
❖ Hirotaka Takeuchi et Ikujiro Nonaka. Description de la nouvelle approche plus
rapide et flexible pour le développement de nouveau produits, 1986.
Webographie
o https://blog-gestion-de-projet.com/definition-des-artefacts-
scrum/#:~:text=Les%20artefacts%20SCRUM
%20sont%20au,L'Incr%C3%A9ment%20Produit. 12 Août 2020
o https://www.supinfo.com/articles/single/3093-comparatif-methodes-agiles. 28 Août
2020
o https://fr.slideshare.net/mobile/doniahammami/rapport-de-projet-de-fin-dtudepfe. 02
Septembre 2020
o https://fr.wikipedia.org/wiki/Hypertext_Markup_Language?wprov=sfla1. 5 Septembre
2020
o https://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade?wprov=sfla1. 12 Octobre
2020
Page 79 sur 80
o www.irit.fr UML et les base de données. 30 Septembre 2020
o https://www.google.com/amp/s/wpmarmite.com/base-donnees-wordpress/amp/. 14
Octobre 2020
o https://www.quanta.co.uk/blog/2012/10/agile-projects-3-times-more-successful-non-
agile-projects 27 Aout 2020
o http://www.oujood.com/php/design-pattern-mvc-php.php 09 Septembre 2020
o https://sites.google.com/site/floriangrisoni/informatique/design-pattern-mvc 02
Octobre 2020
o http://cedric.babault.free.fr/rapport/node4.html 26 Novembre 2020
Page 80 sur 80