Rapport de Stage

UNIVERSITÉ AUBE NOUVELLE
Institut Supérieur d’Informatique et de Gestion

Département High Tech
RAPPORT DE STAGE DE FIN DE CYCLE DE LICENCE

OPTION : Technologie du Génie Informatique
THEME : Réalisation d’une application

multiplateforme de commande et de
livraison de plats de restaurants.
Présenté et soutenu par : Sous la direction de :

KOURA Yeniwibin Ferdinand Dr J. S. Dimitri OUATTARA, Directeur
KONKOBO Juste Alan Alex Wendpoore M. Toussaint B. KOURA, co-directeur
Année académique 2019-2020
Page 0 sur 78
Table des matières
Dédicaces ................................................................................................................................................ 5
Remerciements ........................................................................................................................................ 6
Liste des tableaux .................................................................................................................................... 7
Liste des figures....................................................................................................................................... 8
Sigle et leur signification ......................................................................................................................... 9
Introduction générale............................................................................................................................. 10
Chapitre 1 : Contexte du stage............................................................................................................... 11
Introduction ........................................................................................................................................... 11
I Présentation de l’université ........................................................................................................... 11
I.1 Historique .................................................................................................................................. 11
I.2 Organisation académique .......................................................................................................... 11
II Présentation de FASOSOFT.......................................................................................................... 12
II.1 Historique .................................................................................................................................. 12
II.2 Missions de l’entreprise............................................................................................................. 12
II.3 Organigramme de l’entreprise ................................................................................................... 12
III Présentation du restaurant partenaire BARAKA ....................................................................... 13
IV Présentation du thème ............................................................................................................... 13
IV.1 Problématique du thème ............................................................................................................ 13
IV.2 Objectif ...................................................................................................................................... 13
IV.3 Résultat attendu ......................................................................................................................... 14
Conclusion ............................................................................................................................................. 14
Chapitre 2 : Méthode de conduite de projet .......................................................................................... 15
Introduction ........................................................................................................................................... 15
I Etude sur les méthodes de conduite de projet................................................................................ 15
I.1 Les méthodes agiles................................................................................................................... 15
I.1.1 Extrem Programming (XP)................................................................................................ 15
I.1.2 SCRUM ............................................................................................................................. 16
I.2 Processus Unifié (PU) ............................................................................................................... 16
I.2.1 Rational Unified Process (RUP) ........................................................................................ 17
I.2.2 Two Tracks Unified Process (2TUP) ................................................................................ 17
II Comparaison des méthodes de conduite de projets ....................................................................... 18
II.1 Comparaison entre les deux grandes familles de méthodes ...................................................... 18
II.1.1 Comparaison entre les méthodologies agiles..................................................................... 21
III Méthode adoptée : SCRUM ...................................................................................................... 21
III.1 Les rôles .................................................................................................................................... 22
Page 1 sur 78
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 »..................................................... 41
VI.7 Scénario et cas d’utilisation « créer commande » ............................................................. 42
VI.8 Scénario et cas d’utilisation « consulter liste des commandes à livrer » ................................... 43
VI.9 Scénario et cas d’utilisation « Géolocaliser client » .................................................................. 44
VI.10 Scénario et cas d’utilisation « géolocaliser les restaurant à proximité » .......................... 45
VI.11 Scénario et cas d’utilisation « valider commande » .......................................................... 46
Conclusion ............................................................................................................................................. 47
Chapitre 4 : Conception ......................................................................................................................... 48
Introduction ........................................................................................................................................... 48
I Description de la vue statique........................................................................................................ 48
I.1 Le diagramme de classes ........................................................................................................... 48
I.1.1 Description des attributs de classes .................................................................................. 49
II Description de la vue dynamique .................................................................................................. 52
Page 2 sur 78
II.1 Diagramme de séquence ............................................................................................................ 52
II.1.1 Diagramme de séquence relatif à « s’authentifier » .......................................................... 53
II.1.2 Digramme de séquence « Ajouter plat » ........................................................................... 54
II.1.3 Diagramme de séquence « Supprimer plat » ..................................................................... 55
II.1.4 Diagramme de séquence « Modifier plat »........................................................................ 56
II.1.5 Diagramme de séquence « Consulter un restaurant »........................................................ 57
II.1.6 Diagramme de séquence « créer commande » .................................................................. 58
II.1.7 Diagramme de séquence « Consulter la liste des plats à livrer »....................................... 59
II.1.8 Diagramme de séquence « valider commande » ............................................................... 60
II.1.9 Diagramme de classe « Géolocaliser un client » ............................................................... 61
II.1.10 Diagramme de séquence « Géolocaliser restaurant à proximité » ..................................... 62
III Conception graphique................................................................................................................ 62
III.1 Synopsis..................................................................................................................................... 62
III.1.1 Présentation du produit ...................................................................................................... 62
III.2 Scénario maquette ..................................................................................................................... 63
Conclusion ............................................................................................................................................. 66
Chapitre 5 : Réalisation ......................................................................................................................... 67
Introduction ........................................................................................................................................... 67
I Environnement de travail .............................................................................................................. 67
I.1 Environnement matériel ............................................................................................................ 67
I.2 Choix de l’architecture de l’application .................................................................................... 67
I.3 Environnement logiciel ............................................................................................................. 69
I.3.1 Les langages ...................................................................................................................... 69
I.3.1.1 HTML5 et CSS3 ................................................................................................................ 69
I.3.1.2 PHP 7.3.5 ........................................................................................................................... 69
I.3.1.3 JavaScript .......................................................................................................................... 69
I.3.1.4 SQL ................................................................................................................................... 69
I.3.2 La base de données : MySQL ............................................................................................ 70
I.3.3 CMS : WordPress .............................................................................................................. 70
I.3.4 Les outils supplémentaires ................................................................................................ 70
I.3.4.1 Sublime Text 3.2.2 ............................................................................................................ 70
I.3.4.2 MySQL Workbench 8.0.21 ............................................................................................... 70
I.3.4.3 Local by flywheel .............................................................................................................. 70
I.3.4.5 Basalmiq mockups by Adobe 3.5.17 ................................................................................. 71
I.3.5 Technologies utilisées ....................................................................................................... 71
I.3.5.1 Progessing Web Application (PWA)................................................................................. 71
II Présentation des interfaces ............................................................................................................ 72
Page 3 sur 78
Conclusion générale .............................................................................................................................. 77
Bibliographie ......................................................................................................................................... 78
Webographie ......................................................................................................................................... 78
Page 4 sur 78
Dédicaces
Nous avons le plaisir de dédier ce modeste travail :
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 frères et sœurs à qui nous souhaitons un avenir prospère.
A toutes nos familles.
A nos chers amis pour leurs présences et encouragements, qu’ils trouvent là toute notre
reconnaissance.
Page 5 sur 78
Remerciements
Nos premiers remerciements vont à nos encadreurs Dr J. S. Dimitri Ouattara et M. Toussaint

B. KOURA pour leur suivi et leur aide.
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 78
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 5. Backlog du Sprint 3 ............................................................................................................. 35
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 » ............................ 43
Tableau 17. Description du cas d’utilisation « Géolocaliser un client » ............................................... 44
Tableau 18. Description du cas d’utilisation « Géolocaliser les restaurants à proximité » ................... 45
Tableau 19. Description du cas d’utilisation « valider la commande » ................................................. 46
Tableau 20. Description des attributs de la table « Utilisateur » ........................................................... 50
Tableau 21. Description des attributs de la table « Restaurant » ........................................................... 50
Tableau 22. Description des attributs de la table « Plat »...................................................................... 51
Tableau 23. Description des attributs de la table « Commande » ......................................................... 51
Tableau 24. Description des attributs de la table « Gestionnaire_entreprise » ...................................... 52
Tableau 25. Présentation du produit ...................................................................................................... 62
Page 7 sur 78
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 » .......................................... 41
Figure 17. Diagramme de cas d’utilisation « créer une commande » ................................................... 42
Figure 18. Diagramme de cas d’utilisation « Consulter la liste des plats à livrer » .............................. 43
Figure 19. Diagramme de cas d’utilisation « Géolocaliser un client ».................................................. 44
Figure 20. Diagramme de cas d’utilisation « Géolocaliser les restaurant à proximité » ....................... 45
Figure 21. Diagramme de cas d’utilisation « valider la commande » ................................................... 46
Figure 21. Le diagramme de classe ....................................................................................................... 49
Figure 22. Diagramme de séquence relatif à « authentifier » ................................................................ 53
Figure 23. Diagramme de séquence « Ajouter plat » ............................................................................ 54
Figure 24. Diagramme de séquence « Supprimer plat »....................................................................... 55
Figure 25. Diagramme de séquence « Modifier plat » .......................................................................... 56
Figure 26. Diagramme de séquence « Consulter un restaurant » .......................................................... 57
Figure 27. Diagramme de séquence « Créer commande » .................................................................... 58
Figure 28. Diagramme de séquence « Consulter la liste des plats à livrer » ......................................... 59
Figure 29. Diagramme de séquence « Valider la commande » ............................................................. 60
Figure 30. Diagramme de séquence « Géolocaliser un client » ............................................................ 61
Figure 31. Diagramme de séquence relatif à « Géolocaliser les restaurant à proximité »..................... 62
Figure 32. Gabarit de l’interface d’accueil ............................................................................................ 63
Figure 33. Gabarit de l’interface plat .................................................................................................... 64
Figure 34. Gabarit de l’interface de recherche de plats ......................................................................... 65
Figure 35. Gabarit de l’interface de géolocalisation des restaurants à proximité .................................. 65
Figure 36. Architecture 3-tiers (1er : client, 2ème : serveur web et 3ème : SGBD) ............................. 69
Figure 37. Page d’accueil ...................................................................................................................... 72
Figure 38. Capture d’écran de la page des plats .................................................................................... 73
Figure 39. Capture d’écran de la pages panier. ..................................................................................... 74
Figure 40 Capture d’écran de la page commande. ................................................................................ 75
Figure 41 Capture d’écran de la page de localisation des restaurants à proximité ................................ 76
Page 8 sur 78
Sigle et leur signification
Sigle Définitions
2TUP Two Tracks Unified Process
CMS Content Management System
CREM Centre de Recherche et d’Etudes en Management
CSS Cascading Style Sheet
CU Cas d’Utilisation
FasoSoft Faso Software
HTML HyperText Markup Language
ISIG Institut Supérieur d’Informatique et de Gestion
ITRI-GEC Institut de Technologie et de Recherche Industrielle et Génie Civil
LSIGEDD Laboratoire de Systèmes d’Information, de Gestion de l’Environnement

et du Développement Durable.
MYSQL My Structured Query Language
PHP Hypertext Preprocessor
PU Processus Unifier
PWA Progessing Web Application
RUP Rational unified process
SQL Structured Query Language
U-AUBEN Université Aube Nouvelle
UFR Unité de Formation et Recherches
UML Unified Modeling Language
XML EXtensible Markup Language
XP Extreme Programming
Page 9 sur 78
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 78
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.
L’ISIG a connu plusieurs évolutions. D’abord il a évolué par arrêté

2010355/MESSRS/ETFP/CAP du 11 octobre 2010 en ISIG International ; puis par arrêté 2010-
356/MESSRS/ETFP/CAP du 11 octobre 2010 portant autorisation d’ouverture de cycles de
filières d’études et de délivrance de diplômes à l’ISIG International, et enfin par arrêté Nº 2012-
396/MESS/SG/DGESR du 17 février 2012 pour devenir Université Aube Nouvelle. Depuis
2005, un campus a été ouvert à Bobo-Dioulasso qui a également évolué en Université Aube
Nouvelle de Bobo-Dioulasso en 2018.
I.2 Organisation académique

L'Université Aube Nouvelle de Bobo-Dioulasso est organisée en Unité de Formation et
Recherche (UFR) et en Instituts :
❖ UFR / Sciences Juridiques et Politiques ;
❖ UFR / Sciences Economiques et de Gestion ;
❖ UFR / Sciences et Techniques ;
Page 11 sur 78
❖ 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.
II.2 Missions de l’entreprise

Ils externalisent leurs compétences en génie informatique. Ils commercialisent, auprès de leurs
partenaires, leurs services numériques et leur savoir-faire afin de leur offrir les meilleures
solutions digitales.
II.3 Organigramme de l’entreprise
Directeur Général
Responsable
Directeur
Marketing et Directeur Technique
Administratif
Commercial
Figure 1.Organigramme de FASOSOFT
Page 12 sur 78
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. 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é.
Face à ces difficultés, beaucoup de citadins et entreprises perdent en temps et en argent à la

recherche de restaurant pour déjeuner surtout avec l’installation du système de journée
continue.
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.
Cette plateforme doit permettre, entre autres :
• La mise en place d’une base de données des restaurants ;

• La possibilité de demander la livraison d’un plat de restaurant ;
• La possibilité de commander des plats de restaurants via le web ou le mobile ;
• La possibilité de mettre en avant des restaurants pour booster leur visibilité ;
• La possibilité de retrouver des restaurants à proximité d’un utilisateur.
Page 13 sur 78
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 :
• D’un tableau de bord dédié au responsable du restaurant qui se chargera de la gestion

des contenus sur les plats ;
• D’un tableau de bord dédié aux livreurs où ils pourront consulter les livraisons de plats
qui leurs sont assignées ;
• D’un tableau de bord dédié aux entreprises pour effectuer et suivre des commandes
groupées ;
• D’un tableau de bord dédié au particulier pour commander et suivre sa commande.
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 78
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.
I Etude sur les méthodes de conduite de projet

Nous allons présenter les deux familles de méthodes que nous avons étudiées :
● Les méthodes agiles ;

● Les méthodes de processus unifié.
I.1 Les méthodes agiles
Une méthode agile est une méthode de développement informatique permettant de concevoir
des logiciels en impliquant au maximum le client.
Les méthodes agiles reposent sur une structure commune (itérative, incrémentale et adaptative).
Elles utilisent un principe de développement itératif qui consiste à découper le projet en

plusieurs étapes qu’on appelle “itérations”.
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.
Parmi les méthodes agiles on peut citer l’Extrem Programming et SCRUM.
I.1.1 Extrem Programming (XP)

Plus particulièrement orienté sur l'aspect réalisation d'une application, XP est adapté aux
équipes réduites avec des besoins changeants. L'Extreme Programming repose sur des cycles
rapides de développement (des itérations de quelques semaines) dont les étapes sont les
suivantes :
Page 15 sur 78
● 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).
Figure 2. Le cycle de l'eXtreme Programming
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.
I.2 Processus Unifié (PU)

Le processus unifié est une famille de méthodes de développement de logiciels orientés objet.
Elle se caractérise par une démarche itérative et incrémentale. On distingue parmi ces
méthodes :
Page 16 sur 78
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 :
• Piloté par les cas d’utilisation ;

• Centré sur l’architecture logicielle ;
• Elle est générique, itérative et incrémentale.
I.2.2 Two Tracks Unified Process (2TUP)

Two Tracks Unified Process (2TUP) est un processus de développement logiciel qui met en
œuvre la méthode du processus unifié. Il propose un cycle de développement en Y, qui dissocie
les aspects techniques des aspects fonctionnels.
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.
Le processus s’articule ensuite autour de trois phases essentielles :
• 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 78
Figure 3. Les phases essentielles du Two Tracks Unified Process (2TUP)
II Comparaison des méthodes de conduite de projets

II.1 Comparaison entre les deux grandes familles de méthodes
Il est très important de bien choisir la méthode qui répond parfaitement à ses besoins, s’adapte
au mieux aux exigences du client et qui fournit l’ouvrage dans les plus brefs délais. Pour cela,
il a fallu effectuer une étude comparative entre les méthodes afin d’en sélectionner celle qui
s’adapte au projet.
Le tableau ci-dessous (Tableau 1) fait une comparaison entre les deux grandes familles de
méthodes.
Page 18 sur 78
Tableau 1. Comparaison entre les deux grandes familles de méthodes de développement.
Thème Approche traditionnel Approche agile
Cycle de vie En cascade ou en V, sans rétroaction Itératif et incrémental.

possible, phases séquentielles.
Planification Productive, caractérisée par des plans Adaptative avec plusieurs

plus ou moins détaillés sur la base d’un niveaux de planification (macro-
périmètre et d’exigences définies et et micro planification) avec
stables au début du projet. ajustement si nécessaires au fil
des années en fonction des
changements survenus.
Documentation Produite en quantité importante comme Réduite au strict nécessaire au

support de communication, de validation profit d’incréments fonctionnels
et de contractualisation. opérationnels pour obtenir le
feedback du client.
Equipe Une équipe avec des ressources Une équipe responsabilisée ou

spécialisées, dirigées par un chef de l’initiative et la communication
projet. sont privilégiées, soutenue par le
chef de projet.
Qualité Contrôle qualité à la fin du cycle de Un contrôle qualité précoce et

développement. Le client découvre le permanent, au niveau du produit
produit fini. et du processus. Le client
visualise les résultats tôt et
fréquemment.
Changement Résistance voire opposition au Accueil favorable au

changement. Processus lourds de gestion changement inéluctable, intégré
des changements acceptés. dans le processus.
Page 19 sur 78
Thème Approche traditionnel Approche agile
Suivi de Mesure de la conformité aux plans Un seul indicateur

l’avancement initiaux. Analyse des écarts. d’avancement : le nombre de
fonctionnalités implémentées et
le travail restant à faire.
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 les deux grandes 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
Page 20 sur 78
prenantes avec un 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.
II.1.1 Comparaison entre les méthodologies agiles

Les méthodes agiles constituent un ensemble de pratiques inhérentes à la gestion de projets.
Elles sont principalement conçues pour le développement informatique, en vue de donner pleine
satisfaction aux clients.
Cette figure ci-dessous représente une étude du taux d’utilisation des méthodes agiles sur la
gestion des projets informatiques.
Figure 5.Taux d’utilisations des méthodes agiles.
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.
III Méthode adoptée : SCRUM

SCRUM est la méthode la plus utilisée parmi les méthodes agiles existantes. Le terme SCRUM
(qui signifie mêlée) apparait pour la première fois en 1986 dans une publication de HIROTOKA
TAKEUCHI et IKUJIRO NONAKA qui décrit une nouvelle approche plus rapide et flexible
pour le développement de nouveau produit. Son principe de base est de permettre à ce que
l’équipe avance ensemble et soit toujours prête à réorienter le projet au fur-et-a-mesure de sa
Page 21 sur 78
progression. Elle suit les principes de la méthode Agile, c’est-à-dire l’implication et la
participation active du client tout au long du projet.
Considérée comme un cadre de gestion de projet, SCRUM se compose de plusieurs éléments

fondamentaux :
❖ Des rôles ;
❖ Des évènements ;
❖ Des artéfacts ;
❖ Des règles.
Figure 6. Architecture générale de SCRUM .
III.1 Les rôles

L’équipe SCRUM est auto-organisée et pluridisciplinaire, c’est-à-dire qu’elle choisit la
meilleure façon d’accomplir son travail et qu’elle possède toutes les compétences nécessaires à
l’accomplissement du projet.
Elle est composée de :
• Un SCRUM Master : il est responsable de la compréhension, l’adhésion et de la

mise en œuvre de la méthode SCRUM qu’il maitrise parfaitement. Il veille à ce que les principes
et les valeurs de la méthodologie soient respectées. Il améliore également la communication au
sein de l’équipe et cherche à maximiser la productivité et le savoir-faire de celle-ci.
Page 22 sur 78
• 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).
• L’équipe de développement : elle est chargée de transformer les besoins définis

par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et possède toutes
les compétences nécessaires pour réaliser le projet, sans faire appel à des prestations externes.
Parmi ses membres on trouve un architecte, un développeur, un testeur, etc.
III.2 Les différents événements

La vie d’un projet SCRUM est rythmée par un ensemble de réunions définies avec précision et
limitées dans le temps.
• 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 78
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 :
- Qu’est-ce qu’il a réalisé la veille ?

- Qu’est-ce qu’il va accomplir aujourd’hui ?
- Quels sont les obstacles qui le retarde ?
III.3 Les artefacts SCRUM

• Le Product Backlog (carnet de produit)
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.
• Le Sprint backlog (ou carnet de Sprint)
C’est le plan détaillé de la réalisation de l’objectif du Sprint, défini lors de la réunion de

planification du Sprint. Le Sprint backlog est mis à jour régulièrement par l’équipe afin d’avoir
une vision précise de la progression du Sprint.
• 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 78
Figure 7. L’incrément du produit (Product Increment).
• Le Burndown Chart (ou graphique d’avancement)
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 :
− L’utilisateur cible ou groupe d’utilisateurs ;

− Ce que souhaite l’utilisateur ;
− Pourquoi la fonctionnalité est-elle requise.
Cela permet de donner toutes les informations utiles à la compréhension de la tâche et à sa

réalisation.
• Les Story Points
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 78
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 78
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.
I Description du langage de modélisation

Un langage de modélisation est tout langage artificiel qui peut être utilisé pour représenter des
informations ou des connaissances ou des systèmes dans une structure qui est définie par un
ensemble cohérent de règles.
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).
I.1 Les diagrammes de structure ou diagramme statique

Il s’agit de :
● Diagramme de classes : représentation des classes intervenantes dans le système ;

● Diagramme d’objet : représentation des instances de classes du système ;
● Diagramme de composants : représentation des composants du système d’un point de
vu physique, tels qu’ils sont mis en œuvre (fichier, bibliothèque, base de données ...) ;
● Diagramme de déploiement : représentation des éléments matériels (ordinateurs,
périphériques, réseaux, systèmes de stockage ...) et la manière dont les composants du
système sont répartis sur ces éléments matériels et interagissent entre eux ;
● Diagramme des paquets : représentation des dépendances entre les paquets, c’est-à-
dire entre les ensembles de définition ;
● Diagramme de profil : spécialisation et personnalisation pour un domaine particulier
d’un méta-modèle de référence d’UML.
Page 27 sur 78
I.2 Diagramme de comportement ou d’interaction
Les diagrammes de comportement rassemblent :
● Diagramme des cas d’utilisation : représentation des possibilités d’interaction entre le

système et les acteurs, c’est-à-dire toutes les fonctionnalités que doit fournir le système ;
● Diagramme états-transitions : représentation sous forme de machine à états finis du
comportement du système ou de ses composants ;
● Diagramme d’activité : représentation sous forme de flux ou d’enchainement
d’activités du comportement du système ou de ses composants ;
● Diagramme de séquence : représentation de façon séquentielle du déroulement des

traitements et des interactions entre les éléments du système et/ou de ses acteurs ;
● Diagramme de communication : représentation de façon simplifiée d’un diagramme
de séquence se concentrant sur les échanges de massages entre les objets ;
● Diagramme global d’interaction : représentation des enchainements possibles entre
les scenarios préalablement identifiés sous forme de diagramme de séquences ;
● Diagrammes de temps : représentation des variations d’une donnée au cours du temps.
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 78
Figure 8. La hiérarchie de diagramme UML 2.5 sous forme de diagramme de classe.
II Identification des besoins

L’identification des besoins est une étape très importante dans un projet de développement de
logiciel informatique, elle permet de déterminer les besoins et les attentes des clients.
II.1 Identification des acteurs

Un acteur est une personne physique ou morale, interne ou externe qui interagit avec le système.
II.1.1 Les acteurs internes

• Responsable de restaurant : il gère les plats du restaurant ;
• Livreur : il consulte et livre les commandes qui lui sont assignées.
II.1.2 Les acteurs externes

• Client : il s’agit du particulier qui accède aux services que propose notre application
soit à travers la plateforme web ou l’application mobile.
Page 29 sur 78
• Gestionnaire de l’entreprise : c’est un client qui accède aux services que propose notre
application pour le compte d’une entreprise.
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
gérer les informations et commandes de son entreprise.
Page 30 sur 78
II.2.1 Diagramme de cas d’utilisation globale
Rechercher par popularité
Consulter un retaurant
Rechercher par nom
Rechercher par restaurant
Rechercher un plat
Rechercher par prix
<<include>>
<<extend>> Ajouter quantité
Creér une commande
<<include>> <<include>> Ajouter un plat au panier

Client
Valider la commande <<include>> Remplir le formulaire de validation
<<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
Figure 9. Diagramme de cas d’utilisation
Page 31 sur 78
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.
III Backlog du produit

C’est une sorte de réservoir regroupant l’ensemble des fonctionnalités du produit. Les taches y
sont ordonnées en fonction de la priorité dans laquelle elles doivent être réalisées. Au sein du
backlog, chaque user story constitue une ligne. Pour chaque story on met généralement dans le
backlog :
• 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 78
Tableau 2. Backlog du produit
Priorité Points estimés En tant que Je veux Afin de
1 3 Responsable Afficher la page dédiée à Pouvoir ajouter, modifier,

du restaurant la gestion de mes plats supprimer des plats.
2 2 Client Consulter les plats d’un Pouvoir visualiser tous les

restaurant plats que contient ce
restaurant.
3 3 Client Rechercher un plat Pouvoir retrouver tous les

plats recherchés à travers
un critère.
4 3 Client Sélectionner un/des plats Pouvoir créer une

commande.
7 2 Client Valider une commande Finaliser ma commande.
8 2 Livreur Consulter la liste des Déterminer les adresses de

commandes qui me sont livraison de ces
assignées commandes.
9 2 Livreur Géolocaliser le client Connaitre le lieu de

livraison sur Google Maps.
11 2 Client Géolocaliser les Pouvoir connaitre la

restaurants position des restaurants à
proximité.
12 3 Gestionnaire Gérer un tableau de bord Pouvoir effectuer les

de dédié à l’entreprise commandes de l’entreprise
l’entreprise et gérer les informations de
celle-ci.
Page 33 sur 78
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.
Tableau 3. Backlog du sprint 1
Elément Tâches Points

estimés
En tant que responsable du restaurant, je veux Création de la base donnée (Tables 3

afficher la page dédiée à la gestion de mes utilisateur, plat, restaurant)
plats afin de pouvoir ajouter, modifier,
Création de l’interface de connexion
supprimer, afficher des plats.
du tableau de bord du responsable
Développement des fonctionnalités

d’ajout, de modification, de
suppression et d’affichage

estimés
En tant que client, je veux Développement de la page d’accueil du client 2

consulter un restaurant afin de
Développement des fonctionnalités d’exploration
voir tous les plats qu’il contient.
des plats proposés par des restaurants
En tant que client, je veux Développement des fonctionnalités de recherche 3

rechercher un plat afin de et d’affichage des plats/restaurants.
pouvoir le retrouver à travers un
critère.
Page 34 sur 78
Tableau 5. Backlog du Sprint 3

estimés
En tant que client, je veux Modification de la base de données (création de la table 3

sélectionner un ou plusieurs plats commande)
pour créer une commande.
Développement des fonctionnalités de gestion de
commande (ajout, modification, suppression,
affichage, validation)

estimés
En tant que Livreur, je veux Modification de la base de données 2

consulter la liste des commandes
Création du tableau de bord du livreur
qui me sont assignées afin de
déterminer les adresses de Développement des fonctionnalités d’assignation des
livraison de celles-ci. commandes, de modification des statuts des
commandes (livrées, en cours de livraison, prêt à être
livré)
En tant que Livreur, je veux Développement des fonctionnalités de géolocalisation 2

géolocaliser le client pour d’un client
connaitre le lieu de livraison sur
Google Maps
Page 35 sur 78

estimés
En tant que client, je veux Développement des fonctionnalités de géolocalisation 2

géolocaliser les restaurants pour d’un restaurant
connaitre la position
géographique des restaurants à
proximité.

estimés
En tant que Gestionnaire de Modification de la base de données (table 3

l’entreprise je veux gérer un entreprise)
tableau de bord dédié à mon
Création du tableau de bord de l’entreprise
entreprise afin de pouvoir
effectuer les commandes de Développement des fonctionnalités de gestion des
l’entreprise et gérer ces commandes de l’entreprise
informations.
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 9) que nous allons suivre
pour réaliser notre projet.
Page 36 sur 78
Figure 10. Le diagramme de GANTT
VI Scénarios et cas d’utilisation

VI.1 Scénario et cas d’utilisation « Ajouter plat »
Cas d'Utilisation <Ajouter Plat>
<<include>>
Ajouter plat S'authentifier
Figure 11. Diagramme de cas d’utilisation « Ajouter plat »
Page 37 sur 78
Tableau 9. Description du cas d’utilisation « ajouter plat »
SOMMAIRE D’IDENTIFICATION
Titre Ajouter plat
But Ce cas d’utilisation permet au responsable du restaurant d’ajouter un plat
Acteur Responsable du restaurant
Pré conditions Connecté à la plateforme
Enchainement 1. Le responsable demande à ajouter un plat

2. Le système affiche le formulaire d’ajout
3. Le responsable remplit le formulaire et valide
4. Le système envoie un message pour notifier que l’ajout a été bien
effectué
Alternatif Erreur dans le formulaire
1. Le système affiche les erreurs du formulaire
Retour à l’enchainement 3)
VI.2 Scénario et cas d’utilisation « Supprimer plat »
Cas d'Utilisation <Suprimer Plat>
<<include>>
Supprimer plat S'authentifier
Figure 12. Diagramme de cas d’utilisation « Supprimer plat »
Page 38 sur 78
Tableau 10. Description du cas d’utilisation « Supprimer plat »
Titre Supprimer plat
But Ce cas d’utilisation permet au responsable du restaurant de supprimer un plat
Enchainement 1. Le responsable demande à supprimer un plat

2. Le système envoie un message pour notifier que la suppression a été
bien effectuée
Alternatif
VI.3 Scénario et cas d’utilisation « modifier plat »

Cas d'Utilisation <Modifier Plat>
<<include>>
Modifier plat S'authentifier
Figure 13. Diagramme de cas d’utilisation « modifier plat »
Tableau 11. Description du cas d’utilisation « Modifier plat »
Titre Modifier plat
But Ce cas d’utilisation permet au responsable du restaurant de modifier un plat
Enchainement 1. Le responsable demande à modifier un plat

2. Le système affiche le formulaire de modification
3. Le responsable modifie et valide
Page 39 sur 78
4. Le système envoie un message pour notifier que la modification a été
bien effectuée
Alternatif Erreur dans le formulaire de modification
Retour à l’enchainement 2)
VI.4 Scénario et cas d’utilisation « consulter un restaurant »
Cas d'Utilisation<Consulter un retaurant>
Consulter un retaurant
Client
Figure 14. Diagramme de cas d’utilisation « Consulter un restaurant »
Tableau 12. Description du cas d’utilisation « Consulter un restaurant »
SOMMAIE D’IDIENTIFICATION
Titre Afficher les plats du restaurant
But Ce cas d’utilisation permet à un client de consulter le contenue d’un restaurant
Acteur Client
Pré condition Connecté à la plateforme
Post conditions Le système affiche les plats du restaurant
Enchainement 1. Le système affiche la page d’accueil contenant la liste des restaurants

2. L’utilisateur choisit un restaurant
3. Le système affiche la liste des plats du restaurant
Alternatif Le restaurant n’a pas encore ajouté de plat sur la plateforme
1. Le système affiche un message d’avertissement

2. Retour à l’enchainement 1)
Page 40 sur 78
VI.5 Scénario et cas d’utilisation « Rechercher plat »
Cas d'Utilisation <Rechercher un plat par nom>
Rechercher un plat par nom

Client
Figure 15. Diagramme de cas d’utilisation « rechercher un plat par nom »
Tableau 13. Description du cas d’utilisation « rechercher un plat par nom »
Titre Rechercher un plat par nom
But Ce cas d’utilisation permet à un client de rechercher un plat par nom
Acteur Client
Post conditions Le système affiche les plats correspondants à la recherche effectué
Enchainement 1. L’utilisateur saisit le nom du plat dans la zone de recherche

2. Le système affiche les plats correspondants
Alternatif Plat inexistant
1. Le système envoie un message d’avertissement
VI.6 Scénario de cas d’utilisation « rechercher un plat par prix »
Cas d'Utilisation <Rechercher un plat par prix>
Rechercher un plat par Prix

Client
Figure 16. Diagramme de cas d’utilisation « rechercher un plat par prix »
Page 41 sur 78
Tableau 14. Description du cas d’utilisation « rechercher un plat par prix »
Titre Rechercher un plat par prix
But Ce cas d’utilisation permet à un client de filtrer les plats par prix
Acteur Client
Post conditions Le système affiche les plats correspondants à la recherche effectué
Enchainement 1. L’utilisateur filtre par prix

2. Le système affiche les plats correspondants
Alternatif Plat inexistant
VI.7 Scénario et cas d’utilisation « créer commande »
Cas d'Utilisation <Créer une commande>
<<include>>
Ajouter quantité
Creér une commande

Client
<<include>> Ajouter un plat au panier
Figure 17. Diagramme de cas d’utilisation « créer une commande »
Page 42 sur 78
Tableau 15. Description du cas d’utilisation « créer une commande »
Titre Créer une commande
But Ce cas d’utilisation permet à un de créer une commande
Acteur Client
Post commande Commande créée
Enchainement 1. L’utilisateur sélectionne un ou plusieurs plats

2. Le système crée la commande
Alternatif
VI.8 Scénario et cas d’utilisation « consulter liste des commandes à livrer »

Cas D'utilisation <Consulter la
liste des commandes à livrer>

Livreur
<<include>>
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 »
Titre Consulter la liste des commandes à livrer
But Ce cas d’utilisation de visualiser toutes les commandes qui lui sont assignée
Acteur Livreur
Pré condition Le livreur est connecté
Page 43 sur 78
Post conditions Le système affiche la liste des commandes à livrer
Enchainement 1. Le livreur demande à consulter la liste des plats à livrer

2. Le système affiche la liste des commandes
Alternatif Aucune commande existante

2. Le système affiche le tableau de bord du livreur
VI.9 Scénario et cas d’utilisation « Géolocaliser client »

Cas d'Utilisation<Geolocaliser un client>
Afficher la Carte
<<i ncl ude>>
Geolocaliser un client
Livreur
<<i ncl ude>>
Figure 19. Diagramme de cas d’utilisation « Géolocaliser un client »
Tableau 17. Description du cas d’utilisation « Géolocaliser un client »
Titre Géolocaliser un client
But Ce cas d’utilisation permet au livreur de géolocaliser un client
Acteur Livreur
Post conditions Le système affiche l’adresse sur la carte Google Maps
Enchainement 1. Le livreur sélectionne une commande

2. Le système affiche les informations de la commande
3. Le livreur sélectionne l’adresse de livraison
4. Le système affiche l’adresse sur la carte Google Maps
Alternatif Adresse mal saisie par le client, problème de géolocalisation
Page 44 sur 78
VI.10 Scénario et cas d’utilisation « géolocaliser les restaurant à proximité »
Cas d'Utilisation <Geolocaliser les restaurants à proximité> Afficher la Carte
<<include>>
Geolocaliser les restaurants à proximité

Client
Figure 20. Diagramme de cas d’utilisation « Géolocaliser les restaurant à proximité »
Tableau 18. Description du cas d’utilisation « Géolocaliser les restaurants à proximité »
Titre Géolocaliser les restaurants à proximité
But Ce cas d’utilisation permet à un client de géolocaliser un restaurant à

proximité
Acteur Client
Post conditions Le système affiche les restaurants à proximité sur la carte Google Maps
Enchainement 1. Le client ouvre l’application

2. Le client demande la localisation des restaurants à proximité
3. Le système lui affiche les restaurants à proximité
Alternatif
Page 45 sur 78
VI.11 Scénario et cas d’utilisation « valider commande »
Cas d'Utilisation <Valider Commande>

Remplir le formulaire de validation
<<include>>
Valider la commande
Client
Figure 21. Diagramme de cas d’utilisation « valider la commande »
Tableau 19. Description du cas d’utilisation « valider la commande »
Titre Valider la commande
But Ce cas d’utilisation permet à un client de valider sa commande
Acteur Client
Pré condition Commande créée
Post conditions Message de confirmation
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
Alternatif Le client annule la commande
1. La commande est abonnée

2. Retour à son tableau de bord
Erreur dans le formulaire

2. Retour à l’enchainement 2)
Page 46 sur 78
Conclusion
Ce troisième chapitre a été consacré à l’identification et la spécification des besoins. Nous avons
détaillé le backlog 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 47 sur 78
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.
I Description de la vue statique
I.1 Le diagramme de classes

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les
interfaces des systèmes ainsi que les différentes relations entre celle-ci. Ce diagramme fait
partie de la partie statique d’UML car il fait abstraction des aspects temporel et dynamique.
Une classe décrit les responsabilités, le comportement et le type d’un ensemble d’objets. Les
éléments de cet ensemble sont les instances de la classe. La figure suivante présente le
diagramme de classe de notre système :
Page 48 sur 78
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
Client - nom_entreprise : String

Responsable_restaurant - adresse_entreprise : String
Livreur + Rechercher_plat ()
+ Rechercher_plat ()
+ Ajouter_plat () + Consulter_restaurant ()
+ Consulter_restaurant ()
+ Modifier_plat () + Creer_commande ()
+ Affiche_liste_commande () + Creer_commande ()
+ Supprimer_plat () + Valider_commande ()
+ Geolocaliser_client () + Valider_commande ()
+ Afficher_plat () + geolocaliser_restaurant ()
+ geolocaliser_restaurant ()
+ Gerer_information_entreprise ()
1..1 1..1 1..1

1..1
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..*
Figure 22. Le diagramme de classe
I.1.1 Description des attributs de classes

Le tableau suivant contient une description des différents attributs de la table « Utilisateur »
Page 49 sur 78
Tableau 20. Description des attributs de la table « Utilisateur »
Attribut Description
id_ut C’est un attribut de type « int », il représente l’identifiant de

l’utilisateur (clé primaire)
nom_ut C’est un attribut de type « Varchar2 », il représente le nom de

l’utilisateur
prenom_ut C’est un attribut de type « Varchar2 », il représente le prénom de

l’utilisateur
email_ut C’est un attribut de type « Varchar2 », il représente l’email de

l’utilisateur
telephone_ut C’est un attribut de type « Varchar2 », il représente le numéro de

téléphone de l’utilisateur
long_ut C’est un attribut de type « Varchar2 » il représente la longitude de

l’utilisateur
lat_ut C’est un attribut de type « Varchar2 », il représente la latitude de

l’utilisateur
Le tableau suivant contient une description des attributs de la table « Restaurant »

Tableau 21. Description des attributs de la table « Restaurant »
id_resto C’est un attribut de type « int », il représente l’identifiant du

restaurant (clé primaire)
nom_resto C’est un attribut de type « Varchar2 » il représente le nom du

restaurant
long_resto C’est un attribut de type « Varchar2 », il représente la longitude du

restaurant
lat_resto C’est un attribut de type « Varchar2 », il représente la latitude du

restaurant
Page 50 sur 78
email_resto C’est un attribut de type « Varchar2 », il représente l’email du
restaurant.
Le tableau suivant contient la description de la table « Plat »

Tableau 22. Description des attributs de la table « Plat »
id_plat C’est un attribut de type « int », il représente l’identifiant du plat (clé

primaire)
nom_plat C’est un attribut de type « Varchar2 », il représente le nom du plat.
constituant_plat C’est un attribut de type « varchar2 », il représente les constituant

du plat
prix_plat C’est un attribut de type « Varchar2 », il représente le prix du plat
Le tableau suivant contient la description des attributs de la table « Commande »

Tableau 23. Description des attributs de la table « Commande »
id_comm C’est un attribut de type « int », il représente l’identifiant de la

commande (clé primaire)
date_comm C’est un attribut de type « date », il représente la date à laquelle la

commande a été effectuée
statut_comm C’est un attribut de type « boolean », il représente l’état de la

commande
Page 51 sur 78
Le tableau suivant contient la description des attributs de la table « Gestionnaire_entreprise »
Tableau 24. Description des attributs de la table « Gestionnaire_entreprise »
nom_entreprise C’est un attribut de type « Varchar2 », il représente le nom de

l’entreprise
adresse_entreprsie C’est un attribut de type « Varchar2 », il représente l’adresse de

l’entreprise
II Description de la vue dynamique

II.1 Diagramme de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation UML.
Dans les lignes suivantes nous présentons les diagrammes de séquence en fonction de notre
diagramme de cas d’utilisation.
Page 52 sur 78
II.1.1 Diagramme de séquence relatif à « s’authentifier »
Authentification de l'utilisateur
Systeme BDD
Utilisateur
Demmander Authentification()
Afficher le formulaire()
Remplire les champs()
Lancer la requete Select(information utilisateur)
Verification
Envoyer resultat()
alt Authentifié
Afficher Tableau Bord()
Non Authentifié
Afficher message d'erreur()
Figure 23. Diagramme de séquence relatif à « authentifier »
Page 53 sur 78
II.1.2 Digramme de séquence « Ajouter plat »
Ajouter plat
Systeme BDD
Responsable_restaurant
ref
Authentification de l'utilisateur()
Demmander l'ajout plat()
Afficher formulaire ajout()
Remplir formulaire
Lancer la requete "insert" ajout plat ()
Envoyer resultat()
Message de confirmation()
Figure 24. Diagramme de séquence « Ajouter plat »
Page 54 sur 78
II.1.3 Diagramme de séquence « Supprimer plat »
Supprimer Plat
Systeme BDD
ref
supprimer plat()
Lancer requete delete(plat)
Envoyer resultat()
Figure 25. Diagramme de séquence « Supprimer plat »
Page 55 sur 78
II.1.4 Diagramme de séquence « Modifier plat »
Modifier Plat
Systeme BDD
ref
Demmander la modification d'un plat()
Lancer la requete select(information plat)
enoie information plat()
Afficher information()
Mettre a jour information()
Lancer la requete update(information plat)
Envoyer resultat()
Figure 26. Diagramme de séquence « Modifier plat »
Page 56 sur 78
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()
Affi cher Page accuei l l e()
Sel ecti onner un restaurant()
Envoyer requete sel ect(restaurant)
Envoyer Reponse()
Affi cher l a l i ste de pl at()
Figure 27. Diagramme de séquence « Consulter un restaurant »
Page 57 sur 78
II.1.6 Diagramme de séquence « créer commande »
Créer une commande
Systeme
Utilisateur
Demander liste des plats()
Afficher liste des plats()
loop [Ajouter nouveau Plats]

Sélectionner pour ajouter(plat)
Afficher notification de l'ajout du plat()
opt [Anuler la commande]

Demmander l'annulation de la commande
Vider la commande en cours()
Afficher la page précédente()
T erminer la préparation de la commande()
Afficher le contenu de la commande()
Figure 28. Diagramme de séquence « Créer commande »
Page 58 sur 78
II.1.7 Diagramme de séquence « Consulter la liste des plats à livrer »
Consulter la liste des commandes assignées
Systeme BDD
Livreur
ref
Demander Liste des commandes assignées()
Evoyer la requete Select(commande assigné)
Envoyer reponse()
Afficher liste des commandes assignées()
Figure 29. Diagramme de séquence « Consulter la liste des plats à livrer »
Page 59 sur 78
II.1.8 Diagramme de séquence « valider commande »
Valider une commande
Systeme BDD
Utilisateur
ref
Créer une commande()
Valider la Commande()
Afficher formulaire de validation()
Remplire formulaire de validation()
verification des informations
Envoyer la requete inserte(commande,informations personnels)
Enregistrement(commande,informations personnels)
Retourner resultat de la requete()
alt Commande enregistrer
Afficher message de succés()
Erreur d'enregistrement de la commande

Afficher message d'erreur()
Figure 30. Diagramme de séquence « Valider la commande »
Page 60 sur 78
II.1.9 Diagramme de classe « Géolocaliser un client »
Geolocaliser client
Systeme BDD API Google Maps
Livreur
ref
Consulter la liste des commandes assignées()
Demander l'adresse du client()
Lancer la requette Select(adresse,client)
Envoyer resultat()
Appeler API(coordonnes client)
Retourner carte()
Afficher carte()
Figure 31. Diagramme de séquence « Géolocaliser un client »
Page 61 sur 78
II.1.10 Diagramme de séquence « Géolocaliser restaurant à proximité »
Geolocaliser un restaurant à proximité
Systeme BDD API Google Maps
Utilisateur
Demmander les restaurants à proximité()
Envoyer la requete select(coordonné restaurant)
Envoyer le resultat de la requete()
Appeler API(coordonnes restaurant)
Retourner la carte()
Afficher la carte()
Figure 32. Diagramme de séquence relatif à « Géolocaliser les restaurant à proximité »
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.
III.1.1 Présentation du produit

Tableau 25. Présentation du produit
Objectifs Conception et développement d’une application multiplateforme (Web et

mobile) de commande et de livraison de plat.
Type d’application Application multiplateforme (Web et mobile).
Support Tous les supports
Public cible Cette application est destinée à tous les utilisateurs ayant accès à l’internet.
Page 62 sur 78
Marché visé Le grand public.
Langage utilisé Français
Description Ce projet consiste à concevoir une application multiplateforme (Web et

mobile) permettant de commander un plat et se faire livrer, de géolocaliser les
restaurants à proximité.
III.2 Scénario maquette

Interface d’accueil : première page de notre application présentant les restaurants partenaires.
Figure 33. Gabarit de l’interface d’accueil
Page 63 sur 78
Interface plat : il s’agit de l’interface présentant tous les plats disponibles.
Figure 34. Gabarit de l’interface plat
Page 64 sur 78
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.
Figure 35. Gabarit de l’interface de recherche de plats
Interface de géolocalisation des restaurants à proximité : il s’agit de l’interface qui affiche les
restaurants proches de l’utilisateur.
Figure 36. Gabarit de l’interface de géolocalisation des restaurants à proximité
Page 65 sur 78
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 66 sur 78
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.
• Un ordinateur de marque TOSHIBA Satelite pro R50-C
o Système d’exploitation : Windows 10 ;
o Processeur : Intel(R) Core (TM) i5-6200U CPU @ 2.30GHz ;
o Mémoire vive : 8Go ;
o Disque dure : 1To.
I.2 Choix de l’architecture de l’application

Le Design Pattern MVC est un modèle logique d'architecture applicative qui vise à séparer très
nettement trois couches logicielles au sein d'une même application ou système, à modéliser et
présenter cette application comme un empilement de trois couches dont le rôle est clairement
défini :
➢ 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
Page 67 sur 78
couche métier, et en retour lui présente les informations renvoyées par les traitements de cette
couche.
➢ Contrôleur ou logique métier :
Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique »,

et qui décrit les opérations que l'application va appliquer sur les données en fonction des
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.
➢ Modèle ou Accès aux données :
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.
Nous proposons également un déploiement sur une architecture physique 3-tiers.
Page 68 sur 78
Figure 37. Architecture 3-tiers (1er : client, 2ème : serveur web et 3ème : SGBD)
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.2 PHP 7.3.5

PHP : Hypertext Preprocessor, est un langage de programmation libre,
principalement utilisé pour produire des pages Web dynamiques via un
serveur HTTP. PHP est un langage impératif orienté objet.
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 69 sur 78
I.3.2 La base de données : MySQL
MySQL est un système de gestion de bases de données relationnelles. Il
est distribué sous une double licence GPL et propriétaire.
I.3.3 CMS : WordPress

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.
Pour l’élaboration de notre application web nous avons créé un thème

« enfant » nommé « resto » qui hérite lui-même du thème « parent » de
WordPress « envo-ecommerce ». Cette approche nous permet d’avoir toutes
les fonctionnalités que peut nous donner le thème parent tout en
implémentant de nouvelles fonctionnalités.
I.3.4 Les outils supplémentaires

I.3.4.1 Sublime Text 3.2.2
Sublime Text est un éditeur de texte générique que nous utilisons pour
ajouter certaines fonctionnalités au projet.
I.3.4.2 MySQL Workbench 8.0.21

MySQL Workbench créé par la société d’ORACLE Corp est un logiciel de
gestion et d’administration de base de données MySQL.
I.3.4.3 Local by flywheel

Local by flywheel est un outil de développement WordPress local. Il est
anciennement connu sous le nom de Pressmatic.
Page 70 sur 78
I.3.4.4 PowerDesigner 16.5 SP05
PowerDesigner est un logiciel de conception créé par la société SAP, qui
permet de modéliser les traitements informatiques et leurs bases de données
associées. Il a été créé par SDP sous le nom AMC*Designor, racheté par
Powersoft qui lui-même a été racheté par Sybase en 1995.
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, ...).
I.3.5 Technologies utilisées

I.3.5.1 Progessing Web Application (PWA)
Une PWA (P W A) est une application web qui consiste en des pages ou
des sites web, et qui peuvent apparaître à l’utilisateur de même manière
que les applications natives ou mobiles. Elle tente de combiner les
fonctionnalités offertes par la plupart des navigateurs modernes avec les
avantages de l’expérience offertes par les appareils mobiles.
Page 71 sur 78
II Présentation des interfaces
Figure 38. Page d’accueil
Page 72 sur 78
Figure 39. Capture d’écran de la page des plats
Page 73 sur 78
Figure 40. Capture d’écran de la pages panier.
Page 74 sur 78
Figure 41 Capture d’écran de la page commande.
Page 75 sur 78
Figure 42 Capture d’écran de la page de localisation des restaurants à proximité
Page 76 sur 78
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 77 sur 78
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.
Webographie
o https://blog-gestion-de-projet.com/definition-des-artefacts-
scrum/#:~:text=Les%20artefacts%20SCRUM
%20sont%20au,L'Incr%C3%A9ment%20Produit. 12 Aout 2020
o https://www.manager-go.com/gestion-de-projet/methodes-agiles.htm. 10 Aout 2020
o https://agiliste.fr/introduction-methodes-agiles/. 04 Aout 2020
o https://fr.wordpress.org/plugins/wpappninja/. 20 Septembre 2020
o https://www.supinfo.com/articles/single/3093-comparatif-methodes-agiles. 28 Aout
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
o https://fr.wikipedia.org/wiki/PHP?wprov=sfla1. 11 Septembre 2020
o https://fr.wikipedia.org/wiki/Processus_unifi%C3%A9?wprov=sfla1. 05 Aout 2020
o https://fr.wikipedia.org/wiki/WordPress?wprov=sfla1. 16 Semptembre 2020

o https://cian.developpez.com/uml2/tutoriel/sequence/. 13 Octobre 2020
o www.irit.fr UML et les base de données. 30 Septembre 2020
https://www.google.com/amp/s/wpmarmite.com/base-donnees-wordpress/amp/. 14 Octobre 2020
Page 78 sur 78

Rapport de Stage

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

Rapport de Stage

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITÉ AUBE NOUVELLE

Institut Supérieur d’Informatique et de Gestion

RAPPORT DE STAGE DE FIN DE CYCLE DE LICENCE

THEME : Réalisation d’une application

Présenté et soutenu par : Sous la direction de :

Année académique 2019-2020

Nous avons le plaisir de dédier ce modeste travail :

A nos frères et sœurs à qui nous souhaitons un avenir prospère.

A toutes nos familles.

Nos premiers remerciements vont à nos encadreurs Dr J. S. Dimitri Ouattara et M. Toussaint

2TUP Two Tracks Unified Process

CMS Content Management System

CREM Centre de Recherche et d’Etudes en Management

CSS Cascading Style Sheet

FasoSoft Faso Software

HTML HyperText Markup Language

ISIG Institut Supérieur d’Informatique et de Gestion

ITRI-GEC Institut de Technologie et de Recherche Industrielle et Génie Civil

LSIGEDD Laboratoire de Systèmes d’Information, de Gestion de l’Environnement

MYSQL My Structured Query Language

PHP Hypertext Preprocessor

PWA Progessing Web Application

RUP Rational unified process

SQL Structured Query Language

U-AUBEN Université Aube Nouvelle

UFR Unité de Formation et Recherches

UML Unified Modeling Language

XML EXtensible Markup Language

L’ISIG a connu plusieurs évolutions. D’abord il a évolué par arrêté

I.2 Organisation académique

❖ UFR / Sciences Juridiques et Politiques ;

❖ UFR / Sciences Economiques et de Gestion ;

❖ UFR / Sciences et Techniques ;

II.2 Missions de l’entreprise

II.3 Organigramme de l’entreprise

Figure 1.Organigramme de FASOSOFT

Face à ces difficultés, beaucoup de citadins et entreprises perdent en temps et en argent à la

Cette plateforme doit permettre, entre autres :

• La mise en place d’une base de données des restaurants ;

• D’un tableau de bord dédié au responsable du restaurant qui se chargera de la gestion

I Etude sur les méthodes de conduite de projet

● Les méthodes agiles ;

Elles utilisent un principe de développement itératif qui consiste à découper le projet en

Parmi les méthodes agiles on peut citer l’Extrem Programming et SCRUM.

I.1.1 Extrem Programming (XP)

Figure 2. Le cycle de l'eXtreme Programming

I.2 Processus Unifié (PU)

• Piloté par les cas d’utilisation ;

I.2.2 Two Tracks Unified Process (2TUP)

Le processus s’articule ensuite autour de trois phases essentielles :

II Comparaison des méthodes de conduite de projets

Thème Approche traditionnel Approche agile

Cycle de vie En cascade ou en V, sans rétroaction Itératif et incrémental.

Planification Productive, caractérisée par des plans Adaptative avec plusieurs

Documentation Produite en quantité importante comme Réduite au strict nécessaire au

Equipe Une équipe avec des ressources Une équipe responsabilisée ou

Qualité Contrôle qualité à la fin du cycle de Un contrôle qualité précoce et

Changement Résistance voire opposition au Accueil favorable au

Suivi de Mesure de la conformité aux plans Un seul indicateur

II.1.1 Comparaison entre les méthodologies agiles

Figure 5.Taux d’utilisations des méthodes agiles.

III Méthode adoptée : SCRUM

Considérée comme un cadre de gestion de projet, SCRUM se compose de plusieurs éléments