rimeh moussi, profile picture
Téléchargé parrimeh moussi
60,089 vues

Rapport stage pfe

Ce document présente un projet de fin d'études pour l'obtention d'un diplôme de licence appliquée en technologies de l'information, qui consiste en la conception et le développement d'une application mobile pour la réservation de tickets. Il détaille la méthodologie suivie, les différents sprints de développement, l'architecture du système, ainsi que les tests effectués et les résultats obtenus. Les remerciements et dédicaces des auteurs soulignent l'importance du soutien de leur famille et de mentors tout au long de cette réalisation.

Intégrer la présentation

Téléchargé 437 fois
1 / 111
2 / 111
3 / 111
4 / 111
5 / 111
6 / 111
7 / 111
8 / 111
9 / 111
10 / 111
11 / 111
12 / 111
Plus lue
13 / 111
14 / 111
15 / 111
16 / 111
17 / 111
18 / 111
Plus lue
19 / 111
20 / 111
21 / 111
22 / 111
23 / 111
24 / 111
25 / 111
26 / 111
27 / 111
28 / 111
29 / 111
30 / 111
31 / 111
32 / 111
33 / 111
34 / 111
35 / 111
36 / 111
37 / 111
38 / 111
39 / 111
40 / 111
41 / 111
42 / 111
43 / 111
44 / 111
45 / 111
46 / 111
47 / 111
48 / 111
49 / 111
50 / 111
51 / 111
52 / 111
53 / 111
54 / 111
55 / 111
56 / 111
57 / 111
58 / 111
59 / 111
60 / 111
61 / 111
62 / 111
63 / 111
64 / 111
65 / 111
66 / 111
67 / 111
68 / 111
69 / 111
70 / 111
71 / 111
72 / 111
73 / 111
74 / 111
75 / 111
76 / 111
77 / 111
78 / 111
79 / 111
80 / 111
81 / 111
82 / 111
83 / 111
84 / 111
85 / 111
86 / 111
87 / 111
88 / 111
89 / 111
90 / 111
91 / 111
92 / 111
93 / 111
94 / 111
95 / 111
96 / 111
97 / 111
98 / 111
99 / 111
Plus lue
100 / 111
101 / 111
102 / 111
103 / 111
104 / 111
105 / 111
106 / 111
107 / 111
108 / 111
109 / 111
110 / 111
111 / 111
1 Projet de Fin d’Etudes Pour l’obtention du : Diplôme de Licence Appliquée en Technologies de l’Information Réalisé par : Sondes JAMI Rimeh MOUSSI Entreprise d’accueil : LYNA-ICT Encadré par : Encadreur Entreprise : Mr. Anass Saïd Encadreur ISET Radés : Mme. Eya Cheikh Année Universitaire : 2015/2016 Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et des Technologies de l'Information et de la Communication *** * *** Institut Supérieur des Etudes Technologiques de Radés Conception & Développement d’une application mobile pour la réservation des tickets auprès des guichets de service -------------------------------------------------- -------------------------------------------------- ------------------------------------------
Dédicaces Je dédie ce modeste travail et ma profonde gratitude : À mon père et ma mère Autant de phrases aussi expressives soient-elles ne sauraient montrer le degré d’amour et d’affection que j’éprouve pour eux. Merci pour tout l'amour et la confiance et pour votre énorme support pendant la réalisation de mon projet. "Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai toujours de mon mieux pour rester votre fierté et ne jamais vous décevoir...» Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude et de ma reconnaissance. A mes frères Moncef, Ramzi et Abd Alwaheb Pour leur patience, leur amour et leur encouragement. A mes sœurs Dalila, Bornia et Rahma Sans leurs conseils et leur amour je serai perdue... A mes grands-parents Boujema et Zina Pour leurs encouragements continus et leurs confiances énormes en moi. À ma grande famille, petite et grande, qui a cru en moi, à mes cousins et cousines… A tous mes amis et mes collègues qui m’ont soutenu. À tous mes professeurs pendant mon parcours de l’école vers l’université. À toute personne qui a gravé ma vie par un mot qui m’a orienté vers le bon chemin... Sondes JAMI
Dédicaces A Mes Très Chers Parents (AZOUZ & RAFOUKA) Tous les mots du monde ne sauraient exprimer l’immense amour que je vous porte, ni la profonde gratitude que je vous témoigne pour tous les efforts et les sacrifices que vous n’avez jamais cessé de consentir pour mon instruction et mon bien-être. C’est à travers vos encouragements que j’ai opté pour ce chemin, et c’est à travers vos critiques que je me suis réalisé. J’espère avoir répondu aux espoirs que vous avez fondés en moi. Je vous rends hommage par ce modeste travail en guise de ma reconnaissance éternelle et de mon infini amour. Que Dieu tout puissant vous garde et vous procure santé, bonheur et longue vie pour que vous demeuriez le flambeau illuminant le chemin de vos enfants. Je dédie aussi ce travail à : Mon frère(Nazoura) & Mes soeurs (TAssouma , Fatouna & Hallouma ) pour leurs encouragements incessants. A Tous mes enseignants et Tous mes amis en souvenir des bons moments que nous avons passés ensemble, pour leur soutien continu, leur aide précieuse et leur amour. Rimeh MOUSSI
Remerciements Nous voudrons avant tout adresser notre gratitude et notre profonde reconnaissance à tous ceux qui, de près ou de loin, ont contribué à l’aboutissement de ce travail. Nous tenons à exprimer nos vifs remerciements en premier lieu à notre encadreur de LYNA-ICT Anass Saïd. Nous adressons aussi nos profonds remerciements à Monsieur Mehdi Metir enseignant au sein de l’institut pour ses conseils et Madame Eya Cheikh, notre encadreur au sein de l’ISET Rades, pour son encadrement, son soutien et sa disponibilité qui nous ont guidés tout au long de notre stage. Par la même occasion, Nous exprimons nos sincères reconnaissances à l’égard de tous ceux qui ont contribué à notre formation, particulièrement les enseignants de l’institut supérieur des études technologiques de radés. Finalement, Nous tenons aussi à remercier vivement les membres du jury qui nous ont fait l’honneur d’évaluer ce travail. Rimeh & Sondes
Table des matières Introduction générale........................................................................................................................... 11 Chapitre 1 : Cadre du projet et méthodologie.................................................................................. 12 1. Présentation de l’organisme : LYNA-ICT ............................................................................ 12 2. Etude de l’existant................................................................................................................... 13 2.1. Etat actuel :...................................................................................................................... 13 2.2. Analyse ............................................................................................................................. 15 3. Critique de l’existant............................................................................................................... 16 4. Solution proposée ........................................................................................................................ 17 5. Cahier des charges....................................................................................................................... 17 6. Langage et méthodologie de conception.................................................................................... 18 6.1. Méthodes agiles..................................................................................................................... 18 6.2. SCRUM ................................................................................................................................. 20 6.3. Langage de modélisation UML (Unified Modeling Language)........................................ 24 Chapitre 2 : Planification & architecture ......................................................................................... 25 1. Spécification des besoins......................................................................................................... 25 1.1. Identification des acteurs du système ............................................................................ 25 1.2. Les besoins fonctionnels.................................................................................................. 26 1.3. Les besoins non fonctionnels........................................................................................... 27 2. Structure et découpage du projet : ........................................................................................ 27 2.1. Identification de l’équipe SCRUM................................................................................. 27 2.2. Découpage des sprints..................................................................................................... 28 2.3. Le Backlog du produit..................................................................................................... 29 2.4. Planification des releases ................................................................................................ 30 2.5. Diagramme de cas d’utilisation initial........................................................................... 32 2.6. Diagramme de classe initial ............................................................................................ 32 Chapitre 3 : Sprint 1 - Sprint Gestion du compte ............................................................................ 34 1. Spécification des besoins......................................................................................................... 34 2. Diagramme des cas d’utilisation du premier Sprint ............................................................ 36 2.1. Classification des cas d’utilisation par acteur............................................................... 37 2.2. Analyse des cas d’utilisation........................................................................................... 38 2.3. Analyse Du cas « Créer compte »................................................................................... 39 2.4. Analyse Du cas « Gérer compte »................................................................................... 40
3. Conception des cas d’utilisation............................................................................................. 42 3.1. Diagramme de classes du premier sprint : Gestion du compte................................... 42 3.2. Schéma de la base des données : Gestion du compte.................................................... 43 4. Implémentation........................................................................................................................ 43 5. Test............................................................................................................................................ 44 Chapitre 4 : Sprint 2 - Sprint Gestion des centres des services....................................................... 47 1. Spécification des besoins......................................................................................................... 47 1.1. Backlog Product ................................................................................................................ 47 1.2. Prototypes des interfaces ................................................................................................ 51 2. Diagramme de cas d'utilisation du second sprint................................................................. 52 2.1. Classification des cas d’utilisation par acteurs ............................................................. 52 2.2. Diagramme de cas d’utilisation du deuxième sprint .................................................... 52 3. Analyse des cas d'utilisation ................................................................................................... 53 3.1. Analyse des cas d'utilisation « gérer établissement» .................................................... 53 3.2. Analyse des cas d'utilisation « gérer agence»................................................................ 55 4.2. Analyse des cas d'utilisation « gérer service» ............................................................... 58 5. Conception de cas d'utilisation............................................................................................... 60 5.1. Diagramme de classe global de cas d’utilisation « Gérer les centres des services» ... 60 5.2. Schéma de la base des données : Gestion des centres des services.............................. 61 6. Implémentation........................................................................................................................ 62 7. Test............................................................................................................................................ 62 Chapitre 5 : Sprint 3 - Statistiques .................................................................................................... 67 1. Spécification des besoins......................................................................................................... 67 1.1. Backlog Product ................................................................................................................ 67 1.2. Prototypes d’interfaces .................................................................................................... 68 2. Diagramme de cas d'utilisation du troisième sprint............................................................. 68 2.1. Classification des cas d’utilisation par acteurs ............................................................. 69 2.2. Diagramme de cas d’utilisation du troisième sprint ....................................................... 69 2.3. Analyse Du cas «« afficher statistiques» : ..................................................................... 69 3. Conception de cas d'utilisation « Afficher statistiques » : .................................................. 70 3.1. Diagramme de classe....................................................................................................... 71 3.2. Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques ».......... 71 4. Implémentation........................................................................................................................ 72 5. Test............................................................................................................................................ 72 Chapitre 6 : Sprint 4 - Sprint Mobile ................................................................................................ 74 1. Spécifications fonctionnelles................................................................................................... 74
1.1. Sprint Backlog ................................................................................................................. 74 1.2. Prototype d’interface....................................................................................................... 75 2. Diagramme des cas d’utilisation du quatrième Sprint......................................................... 77 2.1. Classification des cas d’utilisation par acteur............................................................... 77 2.2. Diagramme de cas d’utilisation du quatrième sprint................................................... 77 3. Conception ............................................................................................................................... 79 3.1. Diagramme de classe....................................................................................................... 79 4. Implémentation........................................................................................................................ 80 5. Test............................................................................................................................................ 80 Conclusion............................................................................................................................................ 86 Chapitre 7 : Phase de clôture ............................................................................................................. 87 Introduction ..................................................................................................................................... 87 1. Environnement de développement......................................................................................... 87 1.1. Environnement matériel ................................................................................................. 87 1.2. Environnement logiciel ................................................................................................... 88 1.3. Technologies et Langages de programmation utilisés.................................................. 90 2. Style architectural..................................................................................................................... 93 2.1. Architecture du système.................................................................................................. 93 2.2. Le patron de conception MVC ....................................................................................... 95 3. Gestion de projets.................................................................................................................... 96 3.1. Planning des histoires...................................................................................................... 96 3.2. Diagramme de Gantt....................................................................................................... 98 Conclusion générale & perspective.................................................................................................... 99 Annexe................................................................................................................................................ 101 ANNEXE 1 : Etude approfondie sur les méthodes agiles et la méthode « Scrum »................ 101 ANNEXE 2 : IONIC..................................................................................................................... 102 ANNEXE 2 : MongoDB ............................................................................................................... 106 ANNEXE 3 : Node js..................................................................................................................... 108
Table des figures Figure 1: Principales informations du « LYNA-ICT »............................................................................ 13 Figure 2: file d'attente aux services des douanes des grands aéroports............................................ 14 Figure 3: Écran d’appel files d'attente Figure 4 : Distributeur de tickets tactile............... 15 Figure 5: Queue Mobile........................................................................................................................ 16 Figure 6 : rugby Scrum.......................................................................................................................... 20 Figure 7: processus SCRUM .................................................................................................................. 21 Figure 8: pratique de SCRUM ............................................................................................................... 22 Figure 9: Les acteurs qui représentent notre projet............................................................................ 26 Figure 10 : Équipes et rôles................................................................................................................... 28 Figure 11: Découpage du projet........................................................................................................... 29 Figure 12 : Exemple de schéma de découpage en Releases................................................................ 30 Figure 13 : Découpage le projet en des sprints.................................................................................... 31 Figure 14: Planning du déroulement du projet ................................................................................... 31 Figure 15: Diagramme de cas d'utilisation initial d'une application back office web........................ 32 Figure 16: Diagramme de cas d'utilisation initial d'une application front office mobile................... 32 Figure 17 : Diagramme de classe initial................................................................................................ 33 Figure 18 : prototype de la page d’authentification............................................................................ 36 Figure 19 : prototype de la page « créer un compte » ........................................................................ 36 Figure 20 : cas d’utilisation du premier sprint..................................................................................... 37 Figure 21 : diagramme de séquence système du cas « s'authentifier » ............................................. 39 Figure 22 : diagramme de séquence du cas d'utilisation « créer compte » ....................................... 40 Figure 23 : Diagramme de séquence système du cas « Mettre à jour compte » ............................... 41 Figure 24 : Diagramme du cas d'utilisation de « supprimer compte »............................................... 42 Figure 25 : Diagramme de classe de premier sprint............................................................................ 43 Figure 26 : Test des services web (un user) ......................................................................................... 44 Figure 27 : Page d'authentification ...................................................................................................... 45 Figure 28 : Page de créer compte......................................................................................................... 45 Figure 29 : Page de Gestion du Compte............................................................................................... 46 Figure 30 : prototype d'interface ajouter un établissement............................................................... 51 Figure 31 : prototype d'interface supprimer une agence ................................................................... 51 Figure 32 : prototype d'interface modifier un service......................................................................... 52 Figure 33 : Diagramme de cas d'utilisation globale de sprint 2.......................................................... 53 Figure 34 : diagramme du cas d'utilisation du cas gérer établissement............................................. 53 Figure 35 : Diagramme de séquence du cas ajouter établissement ................................................... 54 Figure 36 : Diagramme de séquence détaillé du cas modifier établissement.................................... 55 Figure 37 : Diagramme du cas d'utilisation du cas gérer agence........................................................ 55 Figure 38 : Diagramme de séquence détaillé du cas chercher agences.............................................. 57 Figure 39 : Diagramme de séquence détaillé du cas supprimer agence............................................ 58 Figure 40 : Diagramme du cas d'utilisation du cas gérer service ........................................................ 58 Figure 41 : Diagramme de séquence détaillé du cas affecter un service à une agence ..................... 59 Figure 42 : Diagramme de séquence du cas afficher les services d’une agence................................. 60 Figure 43 : Diagramme de classe globale de sprint 2 .......................................................................... 61 Figure 44 : Test des services web (la liste des établissements) .......................................................... 62
Figure 45 : interface «créer établissement»........................................................................................ 63 Figure 46 : interface «liste établissements»........................................................................................ 63 Figure 47 : interface «Modifier établissement».................................................................................. 64 Figure 48 : interface «Supprimer établissement»............................................................................... 64 Figure 49 : interface «liste des agences par établissement» .............................................................. 65 Figure 50 : interface «liste des services par agence» .......................................................................... 66 Figure 51 : prototype d'interface «afficher statistiques » .................................................................. 68 Figure 52 : Diagramme de cas d'utilisation globale de sprint 3 .......................................................... 69 Figure 53: Diagramme de séquence système du cas « afficher statistiques » ................................... 70 Figure 54: diagramme de classe de de cas d’utilisation « Afficher statistiques ».............................. 71 Figure 55: Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques » ............... 71 Figure 56: Interface le nombre des agences par établissement ......................................................... 72 Figure 57: Interface le nombre des services par établissement ......................................................... 73 Figure 58: Interface le nombre des services par agence ..................................................................... 73 Figure 59: prototype des interfaces mobile........................................................................................ 76 Figure 60: Diagramme de cas d'utilisation du quatrième sprint......................................................... 77 Figure 61: Diagramme de séquence du cas " réserver ticket" ............................................................ 79 Figure 62: diagramme de classe de quatrième sprint ......................................................................... 79 Figure 63: interface «page d'accueil » ................................................................................................. 81 Figure 66: interface liste établissement................................................................................................ 82 Figure 64: interface liste service............................................................................................................ 82 Figure 65: interface liste agence ........................................................................................................... 82 Figure 67: interface météo ................................................................................................................... 83 Figure 68: Interface information générale de l’application ................................................................ 84 Figure 69: Technologies & Langage de programmation utilisé........................................................... 90 Figure 70: Architecture générale de l'application ............................................................................... 93 Figure 71: Architecture du service web REST ...................................................................................... 95 Figure 72: Architecture du patron MVC............................................................................................... 96 Figure 73: tableau « répartition des tâches de premier sprint » ........................................................ 96 Figure 74: tableau « tâches du deuxième sprint » .............................................................................. 97 Figure 75: tableau « tâches du troisième sprint »............................................................................... 97 Figure 76: tableau « tâches du quatrième sprint » ............................................................................. 97 Figure 77 : Diagramme de Gant............................................................................................................ 98 Figure 78: Les 3 vies de JavaScript...................................................................................................... 108 Figure 79: Le schéma classique : PHP sur le serveur, JavaScript chez le client................................. 109 Figure 80: Avec Node.js, on peut aussi utiliser du JavaScript sur le serveur.................................... 109 Figure 81: Le logo du moteur JavaScript V8 de Google..................................................................... 110
Table des tableaux Tableau 1: Nombre des clients par jour à municipalité Tunis............................................................. 16 Tableau 2: Nombre des clients par jour à poste Tunis ........................................................................ 16 Tableau 3: Les 12 principes de méthodes agiles.................................................................................. 19 Tableau 4: tableau de Backlog initial ................................................................................................... 30 Tableau 5: Sprint Backlog du sprint 1................................................................................................... 35 Tableau 6 : classification des cas d'utilisation par acteur ................................................................... 37 Tableau 7 : Description textuelle du cas d’utilisation « s’authentifier »............................................ 38 Tableau 8: description du cas d'utilisation « Créer compte »............................................................. 39 Tableau 9: Description textuelle du cas d'utilisation « Mettre à jour compte »................................ 41 Tableau 10 : Description textuelle du cas « supprimer compte » ...................................................... 42 Tableau 11 : Backlog du second sprint................................................................................................. 51 Tableau 12 tableau de répartition de second sprint ........................................................................... 52 Tableau 13: description du cas d'utilisation « Créer compte »........................................................... 54 Tableau 14: Description du cas d'utilisation « Gérer agence »........................................................... 56 Tableau 15: Description du cas d'utilisation « Gérer service »........................................................... 59 Tableau 16: Backlog du troisième sprint.............................................................................................. 68 Tableau 17: tableau de répartition de troisième sprint...................................................................... 69 Tableau 18 : Description textuelle du cas « afficher statistiques » .................................................... 70 Tableau 19: Backlog du quatrième sprint............................................................................................ 75 Tableau 20 : Classification des cas d'utilisation par acteur................................................................. 77 Tableau 21 : Description textuelle du cas «Réserver ticket».............................................................. 78 Tableau 22: Environnement matériel .................................................................................................. 87
Introduction générale La révolution mobile transformera la plupart des activités des entreprises au cours des dix prochaines années. Elle sera le déclencheur d'une transformation encore plus radicale vers les systèmes d'engagement. La raison clé de ce phénomène est que l'engagement mobile habilite les personnes à entreprendre l'action prochaine la plus probable dans leur contexte immédiat et au moment où ils en ont besoin. Avec la multiplication des plateformes mobiles, la question du développement multiplateforme s’est rapidement posée, afin de tenter de réduire les couts de développement. Ces technologies permettant aux utilisateurs un accès rapide et facile à l’information, c’est dans cette optique qu’intervient notre projet de fin d’études, nous allons donc concevoir et développer deux applications, une application web et une autre mobile qui doivent permettre de gérer et de contrôler la réservation des tickets. Finalement, on peut dire que notre projet est constitué : D’une part, une application mobile qui doit offrir aux bénéficiaires la possibilité de réserver un ticket sans se déplacer auprès de l’entreprise qui doit être abonnée dans la plateforme, et de les notifier à l’arrivée de leur tour. D’autre part une application web qui permet à l’utilisateur de faire le paramétrage, l’administration et les statistiques sur l’utilisation de l’application.
Chapitre 1 : Cadre du projet et méthodologie L'étude préliminaire est la première phase de tout projet réussi ; Ainsi, ce chapitre va servir dans un premier temps à la présentation de l'organisme d'accueil LYNA ICT. Nous définissons dans un deuxième temps le sujet et l'objectif principal du projet. La deuxième partie sera consacrée à la définition de la méthodologie et le formalisme adoptée lors de la réalisation de ce projet. 1. Présentation de l’organisme : LYNA-ICT Lyna-ICT (Information and Communication Technologies) est une startup fondée en Juin 2015 par des Ingénieurs hautement motivés pour le domaine du TIC. Spécialisée dans les solutions de TIC, LYNA-ICT vient décorer le tissu des fournisseurs de services informatiques. Elle offre des solutions de transformation et d’accompagnement des métiers des entreprises dans tous les niveaux et les domaines. LYNA-ICT est dimensionnée comme STARTUP vue son excellence dans les solutions technologiques à effet de levier et de services axés sur la clientèle. Le portefeuille d'activités de LYNA-ICT comprend des solutions TIC qui offre aux entreprises de télécommunication et des fournisseurs de VoIP des solutions logicielles mobiles et VoIP personnalisés. LYNA-ICT propose des services autour des axes suivants : Développement spécifique Solution open source Etude et conseils Consulting Ingénierie logicielle Infogérance Outsourcing Assistance Dans ce cadre, la figure suivante donne quelques informations sur LYNA-ICT :
LYNA-ICT Secteur d'activité informatique / télécoms Taille de l'entreprise Moins de 20 employés Catégorie Société privée étrangère Année de fondation 2015 Adresse PB Techno park Elghazela 2088 Ariana - Tunisia, Ariana , Ariana, 2088 Tunisie Lien web http://lyna-ict.com/ Figure 1: Principales informations du « LYNA-ICT » 2. Etude de l’existant L'étude de l'existant est une phase importante pour bien comprendre le système actuel. Il a pour objectif d’étudier et de dégager les lacunes du système existant et de proposer les solutions adéquates et définir les objectifs à atteindre au titre de perfectionnement. Il existe deux cas lorsque l’on procède à l’étude de l’existant :  Soit le produit existe déjà, alors il faut l’améliorer.  Soit le produit n’existe pas, il faudra donc le créer. Nous allons procéder par une approche mixte associant les deux procédés. Dans la première partie, nous nous focaliserons sur l’analyse de l'existant : Critique et solutions. 2.1. Etat actuel : Les files d'attente sont un phénomène récurrent dans les sociétés développées. L'afflux de personnes peut être géré de différentes manières. En général, on fait attendre les personnes selon leur ordre d'arrivée.
Lors de la phase d’observation, nous avons remarqué que, pour occuper plus rationnellement l'espace, la file d'attente peut suivre un tracé en serpentin (file d'attente aux services des douanes des grands aéroports). Figure 2: file d'attente aux services des douanes des grands aéroports Les files d'attente peuvent aussi ne pas ordonner les individus dans l'espace, mais instaurer un ordre par le biais de tickets numérotés. Ce peut être le cas dans la salle d'attente d'un service public (bureaux de poste, sécurité sociale,…). Ces solutions modulaires, adaptables à différents secteurs (Distribution, Santé, Télécommunications, Finance, Transport, Secteur public,…) permettent la gestion d’une simple file d’attente. Figure 3 : Un gestionnaire d’accueil mono service multi points d’accueil
2.2. Analyse Le système de gestion des files d'attente est un service qui, contrôle l’ensemble du processus : la distribution des tickets avec un distributeur tactile, l’édition des numéros d’appel, leur visualisation sur écran grand format, la liste des agences les plus proches et les plus dégagées avec une application mobile cross Platform, l’état d’avancement et la synthèse du traitement et l'élaboration de statistiques. Les écrans d’appel Les distributeurs Figure 3: Écran d’appel files d'attente Figure 4 : Distributeur de tickets tactile
Figure 5: Queue Mobile 3. Critique de l’existant La critique du système constitue une étape utile et importante. Elle a pour but de porter un jugement objectif afin de déceler les insuffisances éventuelles rencontrées au cours de l'étude de l'existant en vue de proposer un système plus fiable que le système ancien. Pour cela, lister les établissements servant un nombre important de tickets (Municipalité, Bureau de poste, CNAM…) :  Municipalité Tunis, sidi hessine Services L'état civil légalisation Service des affaires économiques Service des affaires sociales, culturelles, de la jeunesse et des sports Nombre des clients par jour 1053 950 1033 965 Tableau 1: Nombre des clients par jour à municipalité Tunis  Poste : Tunis, Avenue Ferhat Hached - 1060 Tunis Services abonnements Service de poste rapide Payement des factures : Eau, Téléphone, Electricité... L’épargne Nombre des clients par jour 1250 950 1000 820 Tableau 2: Nombre des clients par jour à poste Tunis
Une analyse plus détaillée de la description précédente nous a conduits à dégager plusieurs anomalies concernant le passage de la réservation des tickets. Ces anomalies peuvent être résumées comme suit : - Une obligation de déplacement, - Une file longue avec perte de temps, - Un risque d’attente en vain, - Un stress inévitable. 4. Solution proposée Actuellement il n’existe aucune application qui gère notre domaine d’études. En effet ce besoin touche nos vies quotidiennes, on propose alors une solution pour éviter la perte de temps dans les salles d'attente d'un service public. Pour ce faire, on propose de réaliser un système composé d’une application web et une application mobile pour gérer et surtout pour réserver un ticket pour une agence donnée sans se déplacer. Ces applications, vont être mises à la disposition de l’administrateur et du client. La solution proposée est le développement de :  Une application Front office mobile qui offre aux bénéficiaires de services la possibilité de réserver sans se déplacer un ticket auprès d’une entreprise abonnée dans la plateforme, et de le notifier à l’arrivée de son tour.  Une application Back office web pour le paramétrage, l’administration et les statistiques sur l’utilisation de l’application. Les avantages de la solution proposée :  Améliorer les services ;  Les clients rejoignent la file d'attente avant d'arriver économisant ainsi un temps précieux. 5. Cahier des charges La solution qu’on a proposée consiste à la conception et la réalisation de : Une application back office web qui nous fournit : Les Statistiques concernant :  Les établissements
 Les agences  Les services Le paramétrage :  La gestion des entreprises : permet de gérer les entreprises qui vont s’inscrire dans la plateforme.  La gestion des centres de service : permet de gérer les bureaux de chaque entreprise inscrite dans la plateforme.  La gestion des services : permet la gestion des services offerts au niveau des bureaux de chaque entreprise inscrite dans la plateforme. Et une application front office mobile qui permet :  La réservation de tickets pour le bénéficiaire de service. L’application doit tenir compte de l’emplacement géographique du demandeur de ticket, du ticket en cours de traitement et du dernier ticket imprimé.  La notification de tour permettant la configuration de la durée avant laquelle un client va être notifié. 6. Langage et méthodologie de conception Pour résoudre le problème et trouver des solutions pour gérer tout type de tâche, chaque personne doit suivre une démarche pour avoir un résultat efficace et bien structuré selon des méthodes adoptées. C’est pour cela qu’on doit choisir pour les meilleures solutions et les plus optimales pour avoir recours à une méthodologie puissante qui permet de gérer un cycle de vie d’un projet. Il existe plusieurs méthodes dans ce qui suit nous nous intéressons aux méthodes agiles vues leurs apports pour des projets ou les besoins évoluent. 6.1. Méthodes agiles « Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion de projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du projet. » [1] Cette la méthode s’agit de la réitération de cycles courts dans le temps en divisant le projet en de multiples mini-projets et les prioriser selon les besoins.
6.1.1. Les quatre valeurs fondamentales Agiles étaient déclarées être :  L’interaction entre acteurs plutôt que les processus et les outils.  Un produit opérationnel plutôt qu’une documentation pléthorique.  La collaboration avec le client plutôt que la négociation de contrat.  La réactivité face au changement plutôt que le suivi d'un plan 6.1.2. Les 12 principes de méthodes agiles : 1- Satisfaire le client en livrant tôt et régulièrement des logiciels utiles qui offrent une véritable valeur ajoutée 5-Bâtir le projet autour de personnes motivées en leur fournissant environnement et support et en leur faisant confiance 9-Rechercher l’excellence technique et la qualité de la conception 2-Accepter le changement même tard dans le développement 6-Communiquer par des conversations en face à face 10-Laisser l’équipe s’auto- organiser 3-Livrer fréquemment une application qui fonctionne 7-Mesurer la progression avec le logiciel qui fonctionne 11-Rechercher la simplicité 4-Collaborer quotidiennement entre clients et développeurs 8-Garder un rythme de travail durable 12- À intervalles réguliers, réfléchir aux moyens pour devenir plus efficace Tableau 3: Les 12 principes de méthodes agiles 6.1.3. Les principales méthodes agiles : Nous distinguons surtout :  SCRUM  Extreme Programming (XP)  Rapid Application Development (RAD)  Crystal clear Si nous voulons définir l’agilité en quelques mots : c’est l’intelligence organisationnelle et technologique, associée à de l’énergie de groupe dans le but d’être immédiatement efficients. Suite à l’étude de plusieurs méthodologies et de leur convenance à notre projet, nous avons opté pour l’utilisation de la méthode SCRUM.
6.2. SCRUM La méthode Scrum est une méthode agile, créée en 2002, dont le nom est un terme emprunté au rugby qui signifie « la mêlée ». Elle s'appuie sur le découpage des projets en itérations encore nommées « sprints ». [1] Figure 6 : rugby Scrum SCRUM correspond plus à une démarche de travail qu’à une méthode. Son avantage principal est sa capacité à obtenir un résultat final dans un laps de temps court tout en s’appuyant sur une équipe cohérente. Cette équipe va s’atteler à atteindre un objectif progressif qui évoluera au cours de cycles successifs et itératifs appelés Sprints. La durée d’un sprint varie entre 15 et 30 jours, et à sa fin, l’équipe présentera un produit correspondant aux spécificités énoncées au début du cycle. Parmi les atouts du concept de sprint (court et rapide) est qu’il permet au propriétaire du produit de changer la priorisation des caractéristiques demandées au fur et à mesure de l’avancement du développement. La fin de chaque sprint est une occasion de voir le produit courant fonctionner, et de prendre la décision de livraison ou du lancement d’un nouveau sprint d’amélioration du produit. 6.2.1. Pourquoi Scrum ? Scrum place l’humain au centre de la méthodologie. L’avantage principal de cette méthode est qu’elle correspond parfaitement à une petite équipe qui travaille sur un grand projet, elle s’appuie sur la répartition des tâches et la collaboration entre les membres du groupe. Avec les anciennes méthodes, le client ne voyait le logiciel qu’au moment de la livraison et n’était pas impliqué au cours des différentes phases de son développement. En effet, il n’avait accès aux tests que lorsque le produit était fini ou presque.
Par contre en Scrum, l’implication du client a lieu tout au long du processus car il y a plusieurs livrables qu’il doit valider. Chaque livrable correspond à l’implémentation de nouvelles fonctionnalités et le client peut facilement apprécier l’avancement du produit et il a de nombreuses occasions de demander les ajustements nécessaires à la satisfaction de sa demande. Grâce à Scrum, nous avons pu réduire les temps de production et répondre au plus près aux besoins du client. Scrum vise donc essentiellement l’optimisation de la prévisibilité d’un projet tout en réduisant les risques au minimum. La figure ci-dessous illustre le processus sur lequel est basé SCRUM : Figure 7: processus SCRUM Scrum est :  Léger  Simple à comprendre  Difficile à maîtriser Durant un développement d’un projet avec la méthode Scrum il y a plusieurs étapes à suivre avec une démarche spécifique et une interaction avec plusieurs intervenants.
Figure 8: pratique de SCRUM 6.2.2. Les intervenants dans Scrum La méthode Scrum définit trois rôles pour un projet :  Le Product Owner : C’est le propriétaire du produit et le chef d’orchestre qui valide ou décline le produit délivré. L’une de sa responsabilité principale est la définition des besoins du produit à développer et la rédaction des spécifications. Il est le seul gérant du Backlog du produit.  Le Scrum Master : Il est chargé de veiller au bon déroulement et application de la méthode Scrum et au respect de ses objectifs. Il veille également à ce que les éventuels obstacles que l’équipe peut rencontrer soient effacés. Il assure la bonne progression de l’équipe ainsi que sa productivité.  Team Membres : Ce sont les membres de l’équipe qui ont à leur charge le développement et la réalisation d’un produit fiable et utilisables. Ses membres sont soit développeur, soit architectes, soit testeurs. 6.2.3. Les artéfacts dans Scrum Les principaux artéfacts qu’on peut les générer lors de l’utilisation de la méthode Scrum :  Le « Product Backlog » : (Carnet de produits) C’est un outil de collecte des fonctionnalités attendues ou exigées par le client (User Story), et qui évolue à chaque Sprint. [2]
 Le « Sprint Backlog » : (Carnet d'itération) Il contient la liste des tâches qui doit être accomplie pour mettre en œuvre les fonctionnalités prévues pour un Sprint particulier. Idéalement, chaque tâche dans un sprint est relativement courte et peut-être captée par un membre de l'équipe plutôt que d'être affecté. [3]  « Burndown charts » : (Graphique d’avancement). C’est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint. [2] L’axe vertical présente la quantité de travail à faire et l’axe horizontal les jours de travail. 6.2.4. Planification d’un projet par Scrum La durée de vie d’un projet en Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps.  Planification d'itération « Sprint Planning » Au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du « Product Backlog » qu'elle pense pouvoir réaliser au cours du sprint en accord avec le « Product Owner »  Mêlée quotidienne « Daily Scrum Meeting » La mêlée quotidienne (Daily Scrum) est un événement limité à 15 minutes au cours duquel l’équipe de développement synchronise ses activités et crée un plan pour les prochaines 24 heures. Pour ce faire, l’équipe inspecte le travail effectué depuis la dernière mêlée quotidienne et envisage le travail qui peut être réalisé d’ici à la prochaine. [4] Chaque membre de l'équipe répond à trois questions :  Qu'as-tu accompli depuis la dernière mêlée ?  Que vas-tu accomplir jusqu'à la prochaine mêlée ?  Est-ce que des éléments te bloquent dans ton avancement ? Et si on doit obtenir des informations de la part du client, c’est le Product Owner qui doit s’assurer de le contacter pour obtenir les réponses.  Revue d'itération « Sprint Review » La revue de l’itération est organisée à chaque fin de cycle de développement. C’est une présentation des différentes fonctionnalités développée durant le cycle. Le propriétaire du produit aura l’occasion d’évaluer le produit et de le comparer à ce qui a été spécifié lors de la séance de planification d’itération. Une fois la revue achevée, un nouveau cycle d’itération démarre et relance ainsi la boucle : planification, développement et revue. Il s’agit là d’un
point de contrôle journalier pour toute l’équipe, limité à 15 min, dans lequel ils alignent et synchronisent leur travail pour optimiser la planification des prochaines 24 heures.  Rétrospective de sprint : La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois. Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum Master s’assure que la réunion a lieu et que les participants en comprennent le but. [4] Une fois la méthodologie de conception choisie, il convient maintenant de choisir quel langage de modélisation on a adopté dans notre projet. 6.3. Langage de modélisation UML (Unified Modeling Language) Une dizaine d'années après le début de son utilisation dans le cadre de projets de développement orienté objet, UML s'est imposé comme standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant et est devenu désormais la référence en matière de modélisation objet. La modélisation objet consiste à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. [5] Donc, après le choix de la méthodologie, on a opté UML comme un langage de modélisation qui est utilisé dans tous les projets logiciels comporte un ensemble des diagrammes, il permet de fournir une représentation informatique d’un ensemble d’objets et de problèmes standards du monde réel. Conclusion Dans ce premier chapitre, nous avons commencé par présenter notre organisme d’accueil LYNA-ICT. Ensuite, nous avons décrit le contexte du stage, puis nous avons dressé la problématique de notre projet, le tout en fournissant les critiques et les solutions envisageables. Enfin nous avons étayé le choix de la méthodologie de travail utilisée SCRUM, et par la suite nous nous dirigerons naturellement vers la planification et architecture.
Chapitre 2 : Planification & architecture Dans le chapitre précédent, nous avons évoqué le choix de la méthode Scrum. Maintenant nous passerons à la phase la plus intéressante de cette méthodologie appelée phase de « planification et architecture » ou « Sprint Zéro ». Le sprint zéro, n’est pas considéré comme un vrai sprint, puisqu’il ne donne pas de version potentiellement livrable lorsqu’il touche à sa fin : c’est plutôt un échauffement, pour les sprints réels. Il s’agit en fait d’une phase de planification et architecture qui ne se termine pas nécessairement par une livraison. C’est donc dans ce chapitre que nous allons définir notre produit finit (Service sans attente) et ses différentes fonctionnalités en partant de l’identification des besoins, nous élaborerons les rôles des utilisateurs et préparerons l’environnement de développement. Nous finirons par déterminer un plan de Release afin de produire le Product Backlog initial ainsi qu'une première planification des sprints. 1. Spécification des besoins L’analyse des besoins est une étape conduite à l’élaboration de spécifications. C’est nécessaire de définir le projet et de mettre une planification pour bien le piloter et d'atteindre les objectifs souhaités par le client avant leur démarrage. 1.1. Identification des acteurs du système « Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositifs matériels ou autres système) qui interagit directement avec le système étudié. » [5] Pour élaborer notre projet on a pu identifier les acteurs suivants :
Figure 9: Les acteurs qui représentent notre projet 1.2. Les besoins fonctionnels Les besoins fonctionnels c’est ce que l’utilisateur attend en matière de fonctionnalités. Ces besoins présentent une description abstraite des services que le système est censé fournir pour les utilisateurs et qui convient à leurs attentes et satisfaire leurs exigences. Donc notre système doit permettre de :  Le développement d’une application web : Cette application sera essentiellement utilisée par l’administrateur. Elle doit permettre de faire : o Les statistiques concernant :  Les établissements ;  Les agences ;  Les services. o Le paramétrage :  Des établissements ;  Des agences ;  Des services.  Le développement d’une application mobile : Cette application sera essentiellement utilisée par les clients, ces derniers peuvent :  Réserver des tickets ;  La notification de leur tour.
1.3. Les besoins non fonctionnels Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour l’utilisateur, mais qui ne sont pas reliés directement au comportement du système. Ils présentent les exigences internes primordiales pour le système tel que les contraintes liées à l’environnement et à l’implémentation, et les exigences en matière de performances, d’extensibilité et de fiabilité. Les besoins non fonctionnels de notre système se décrivent comme suit :  Le temps de réponse de l'application doit être minimal ;  La portabilité du système sur n’importe quelle plateforme ;  La performance, la fiabilité et la flexibilité du système ;  L’application doit être accessible à plusieurs utilisateurs en même temps ;  L’architecture de l’application doit être capable de supporter l’implémentation de services web et mobile ;  Les interfaces de notre application doivent être claires, concises, conviviales et facile à manipuler. 2. Structure et découpage du projet : 2.1. Identification de l’équipe SCRUM L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la productivité et la flexibilité. Afin de parvenir à ces objectifs, elle doit s’auto organiser et être multi compétente. Elle doit également avoir un champ d’action suffisant pour la soutenir dans la réalisation de son travail Dans le contexte de notre projet, on trouve :
Product Owner : les directeurs des départements Scrum master : M. Anass Saïd Team : Sondes JAMI & Rimeh MOUSSI Figure 10 : Équipes et rôles 2.2. Découpage des sprints La structuration d'un projet consiste à diviser le projet en différents lots d'activités afin d'avoir des sous-parties dont la complexité est plus facilement maitrisable. Voici ci-dessous la structuration de notre projet :
Figure 11: Découpage du projet 2.3. Le Backlog du produit Comme nous avons déjà mentionné le Backlog du produit est un outil qui sert à collecter les fonctions essentielles et les raffine progressivement. C’est l’ensemble des caractéristiques fonctionnelles « user story » ou techniques « technical story » qui constituent le produit souhaité. Un user story s’écrit comme suit : En tant que <rôle> Je veux < liste de tâches> Afin de < valeur ajoutée ou résultat> Pour chaque user story on identifie le rang, l’estimation, l'importance et la description. Le tableau suivant décrire le Backlog produit de notre application et évoque les User Stories : ID En tant que Je veux Pour que Importance 1 Administrateur M’authentifier J’accède à l’application en assurant sa sécurité + + + 2 Administrateur Gérer établissement Traiter les informations concernant un établissement + + + 3 Administrateur Gérer agence Traiter les informations concernant une agence + + 4 Administrateur Gérer service Traiter les informations concernant un service + + + 5 Administrateur Gérer profil Je traite mes informations + +
6 Administrateur Afficher les statistiques Mettre en évidence les résultats de l’application. +++ 7 Client Utiliser l’application mobile front office Réserver un ticket et faire la notification de tour. +++ Tableau 4: tableau de Backlog initial 2.4. Planification des releases Tous les projets nécessitent des plans, pour essayer de prévoir à peu près ce que va contenir un produit ou à quelle date il sortira sur le marché. Avec la méthodologie agile Scrum, la planification de release aux mêmes objectifs puisqu’il donne à l’équipe et aux parties prenantes des informations sur le contenu des sprints constituant le release. Un release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs. [5] Toute l’équipe Scrum participe à la planification de la release (l’équipe complète, avec le Scrum Master et le Product Owner) car ceux qui vont exécuter les tâches de réalisation sont les mieux placés pour en connaître les problèmes et les difficultés. La planification de Sprint répond aux questions suivantes :  Qu’est-ce qui peut être terminé au cours de ce Sprint ?  Comment sera effectué le travail choisi ? Dans notre projet, on va travailler sur une seule release, il ne contient pas une succession de sprints, cette démarche a été abandonnée. Chaque feature est fortement liée à d’autres ce qui a accentué notre choix de structuration en sprints, plutôt qu’en releases. Schéma Ci-dessous décrit le concept du découpage des Releases en Sprints : Figure 12 : Exemple de schéma de découpage en Releases
Figure 13 : Découpage le projet en des sprints Durant la période de stage la figure suivante conclut la planification qu’on suivra pour la gestion de notre projet : Figure 14: Planning du déroulement du projet Remarque :
La date de fin du sprint est fixée au début du sprint (elle est même définie avant). Elle ne change pas, même si l’équipe ne réalise pas tout ce qu’elle imaginait faire. L’évaluation de fin de sprint permettra d’inspecter ce qui a été fait et d’en tirer des conséquences pour la suite. Maintenant, nous allons présenter les différents besoins fonctionnels de notre application exprimés précédemment d'une manière informelle en utilisant le digramme de cas d'utilisation d'UML initial. [6] 2.5. Diagramme de cas d’utilisation initial Les cas d’utilisation sont une technique de description qui sert à présenter les besoins des utilisateurs par rapport au système. Figure 15: Diagramme de cas d'utilisation initial d'une application back office web Figure 16: Diagramme de cas d'utilisation initial d'une application front office mobile 2.6. Diagramme de classe initial Le diagramme de classe permet de fournir une représentation abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. [7]
0..* 0..1 1..* 1..* gérer réserver appartenir à 1..1 1..* 1..1 1..1 1..* 1..* utilisateur - - - - - - - - id_utilisateur nom prenom adresse adress_mail telphone login mot_passe : int : String : String : String : String : String : String : String + + + + + + + getAdresse () setAdresseMail () getAdresseMail () setLogin () setPwd () utililisateur () toString () : String : void : String : void : void : void : String établissement - - id_etablissement libelle : int : String + + + + getLibelle () setLibelle () etablissement () toString () : String : void : void : String agence - - - id_agence libelle adresse : String : String : String + + + + + + getLibelle () getAdresse () setLibelle () setAdresse () agence () toString () : String : String : void : void : void : String ticket - - id_ticket QrCode : int : String + + ticket () toString () : void : String client - adresse_mail : String + + + + Client () toString () setMail () getMail () : void : String : void : String service - - id_service libelle : int : String + + + + + getLibelle () setLibelle () getID () service () toString () : String : void : int : void : String Figure 17 : Diagramme de classe initial Conclusion Toute au long de ce chapitre, nous avons préparé notre planification de travail pendant laquelle on a identifié l’équipe de projet ainsi qu’on a construit notre Backlog de produit en se basant sur les besoins fonctionnels et non fonctionnels. Finalement nous avons mentionné le découpage de notre release en des sprints. Dans la partie qui suit, Nous allons enchainer à présenter avec notre premier sprint « gestion des comptes»
Chapitre 3 : Sprint 1 - Sprint Gestion des comptes Dans le chapitre précédent, nous avons défini ce qu'est un sprint : une succession de tâches effectuées par les parties prenantes de la méthodologue Scrum afin d'atteindre l'objectif prédéfini par l'équipe. Le chapitre en cours quant à lui traiter les "users stories" de notre sprint en les classant dans des features qui pourront s'intégrer à une release et repartis en users stories. Une question s’impose avant même d'initier le premier sprint : « Pourquoi faisons-nous ce sprint ?». La réponse devra être compréhensible, non pas au sein de l'équipe, mais surtout en dehors. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Backlog Product Comme détaillé dans le premier chapitre, le Sprint Backlog est défini au cours de la réunion de planification : il s’agit de la liste des tâches que l’équipe Scrum doit réaliser durant le Sprint dans le but de transformer un ensemble d’éléments du carnet de commandes dans une version préliminaire du produit finit répondant aux exigences prédéfinies. Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux créer mon compte et m’authentifier. 1.1 Ajouter un « user » dans le web API Sondes Jami 1.2 Ajouter les fonctionnalités de l’affectation et de l’authentification dans le contrôleur de l’application Rimeh MOUSSI
client. 1.3 Tester l’ajout et l’authentification d’un utilisateur Rimeh Sondes 2 En tant qu’un utilisateur je peux afficher mon profil. 2.1 Afficher un « user » dans le web API Sondes 2.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 2.3 Tester la récupération de profil d’utilisateur Rimeh Sondes 3 En tant qu’un utilisateur je peux supprimer mon profil. 3.1 Supprimer un « user » dans le Web API Sondes 3.2 Ajouter la méthode de suppression de mon profil dans le contrôleur de l’application client Rimeh 3.3 Tester la suppression de compte Rimeh Sondes 4 En tant que un utilisateur, je peux modifier mon profil. 4.1 Modifier un « user » dans le Web API Rimeh 4.2 Ajouter la méthode de modification de mon profil dans la partie client Sondes 4.3 Tester la modification du compte Sondes Rimeh Tableau 5: Sprint Backlog du sprint 1 1.2. Prototypes d’interface Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint pour y mettre en évidence les fonctionnalités et bien les comprendre.
 Prototype de l’interface "s’authentifier" Figure 18 : prototype de la page d’authentification  Prototype de l’interface "créer compte" : Figure 19 : prototype de la page « créer un compte » 2. Diagramme des cas d’utilisation du premier Sprint La méthodologie basée sur le prototypage consiste à traiter des fonctionnalités. Il s’agira pour nous de la collecte de différentes « users stories » sous une seule et unique fonctionnalité.
Au début de chaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. 2.1. Classification des cas d’utilisation par acteur Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur. ACTEUR CAS D’UTILISATION Utilisateur  Créer compte  Afficher compte  Mettre à jour compte  Supprimer compte  S’authentifier Tableau 6 : classification des cas d'utilisation par acteur La figure 20 illustre le diagramme de cas d’utilisation initiale du premier sprint. L’utilisateur aura l'accréditation d’accéder à la plateforme en utilisant un login et un mot de passe. Afin d’y parvenir, doit s’inscrire dans le but d’avoir un compte sur la plateforme. Figure 20 : cas d’utilisation du premier sprint
2.2. Analyse des cas d’utilisation Afin de mieux assimiler les cas d’utilisation, nous avons établi leurs raffinements pour livrer une description sur les différents scénarios possibles. Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile. 2.2.1. Description textuelle du cas d’utilisation « s’authentifier » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition Le login et mot de passe sont corrects Post condition L’utilisateur est authentifié Description du scénario principal 1-L’utilisateur saisi son login et son mot de passe 2-Il clique sur le bouton « se connecter » 3-Le système vérifie les informations saisies par l’utilisateur et affiche l’interface de la plateforme. Exception Un message d’erreur est affiché si le login et/ou le mot de passe sont erronés. Tableau 7 : Description textuelle du cas d’utilisation « s’authentifier » 2.2.2. Diagramme de séquence système du cas « S’authentifier »
Figure 21 : diagramme de séquence système du cas « s'authentifier » 2.3. Analyse Du cas « Créer compte » 2.3.1. Description textuelle du cas d’utilisation « Créer compte » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur n’a pas de compte et a choisi l’option « créer compte » Post condition Le compte est créé Description du scénario principal 1- L’utilisateur remplit le formulaire d’inscription 2- Il clique sur le bouton « créer » 3- Le système affiche un message «compte est créé» Exception Un message d’erreur est affiché si le login existe déjà. Un message d’erreur est affiché s’il y a des données incorrectes ou/et manquantes. Tableau 8: description du cas d'utilisation « Créer compte » 2.3.2. Diagramme de séquence système du cas « Créer compte »
Figure 22 : diagramme de séquence du cas d'utilisation « créer compte » 2.4. Analyse Du cas « Gérer compte » 2.4.1. Raffinement du cas d’utilisation « Gérer compte » L’utilisateur clique sur le bouton « Mon compte ». Par la suite, le système affiche le profil. Ce qui permettra à choisir l’une des deux options « modifier » où « supprimer » le compte. 2.4.1.1. Analyse du cas d’utilisation « Mettre à jour compte »  Description textuelle du cas d’utilisation «Mettre à jour Compte » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur doit être authentifié Post condition Utilisateur modifié Description du scénario principal 1- L’utilisateur clique sur le bouton « Mon compte » 2- Le système affiche les données dans un formulaire.
Tableau 9: Description textuelle du cas d'utilisation « Mettre à jour compte »  Diagramme de séquence système du cas « Mettre à jour compte » Figure 23 : Diagramme de séquence système du cas « Mettre à jour compte » 2.4.1.2. Analyse du cas d’utilisation « supprimer compte »  Description textuelle du cas d’utilisation « supprimer compte » 3- L’utilisateur modifie les champs et clique sur <<Modifier>>. 1- Le système enregistre les informations du profil. Exception Un message d’erreur est affiché si le login existe déjà. Un message d’erreur est affiché s’il y a des données incorrectes ou/et manquantes. Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur doit être authentifié Post condition Utilisateur supprimé
Tableau 10 : Description textuelle du cas « supprimer compte »  Diagramme de séquence système du cas « supprimer compte » Figure 24 : Diagramme du cas d'utilisation de « supprimer compte » 3. Conception des cas d’utilisation Dans cette section, nous allons réaliser le diagramme de classes d’objets du premier sprint. 3.1. Diagramme de classes du premier sprint : Gestion des comptes La figure 24 illustre le diagramme de classes d’entités globales du premier sprint. Le classe « utilisateur » est liée à la classe « compte » par une association du type 1, c’est-à-dire qu’un compte peut n’appartient qu’à un seul utilisateur. Description du scénario principal 1- L’utilisateur clique sur le bouton « Mon compte » 2- Le système affiche les données dans un formulaire. 3- L’utilisateur clique sur <<Supprimer>>. 4- Le système supprime le compte. Exception Pas d’exception
1 0..1 possède utilisateur - - - - - - - - id_utilisateur nom prenom adresse email num_telphone login mot_de_passe : String : string : String : String : String : int : String : String + + + GetCurrentUser () createUser () DeleteUser () compte - - login password : String : String + + + GetCurrentUser () CreateUser () Deleate () Figure 25 : Diagramme de classe de premier sprint 3.2. Schéma de la base des données : Gestion du compte Il n’existe pas encore de mode de représentation comme le diagramme ER pour les bases documentaires mais on pourrait modéliser notre collection <<users>> de la façon suivante : 4. Implémentation La phase d’implémentation, plus connue sous le nom de phase de développement consistera à implémenter les "user stories" résultantes des phases précédentes. Au cours du premier sprint, nous concevrons la structure de la base de données en se basant sur les bases documentaires. Notre base du premier sprint est définie comme ci-dessous, Ce qui nous donne par exemple un document user : { "_id" : ObjectId("574aa7f15c70661c06d15fdb"), "nom" : "moussi", "prenom" : "azouz", "adresse" : "tunis", "email" : "rimeh.moussi@gmail.com", "numtelph" : "58888555", "username" : "admin", _id: String Nom : String Prénom : String … Document : user Collection : users
"hash" : "$2a$10$WkCgivFIlxO3CQgMg0LayekJmh3V7Zfz.Em5yn1Cpiaj4.twq9DFi" } Dans le cadre d’une application web du type Single Page Application (SPA) peut se poser la problématique de l’authentification. Au-delà de l ‘identification HTTP, pour gérer l’authentification d’un utilisateur on se basera sur ExpressJs pour le serveur et AngularJS pour le client. Et pour assurer la sécurité de notre application nous avons utilisé de nouvelles approches, l’authentification à base sur un jeton signé envoyé au serveur à chaque demande c’est qu’on appelle le JWT [9] (JSON Web Token) et la fonction bcrypt [10] de node js pour hacher le mot de passe de l’utilisateur. 5. Test L’approche Agile considère les tests comme une phase cruciale des projets. Dans la majorité des autres méthodes, les tests ne se front qu’après la fin du développement. Pour Scrum et les méthodes agiles en général, les tests sont intégrés dans chacun des sprints jusqu’à la livraison du produit final. Donc, chaque sprint doit se terminer par l’indispensable phase de test. Ces tests sont les seuls garants d’une version de qualité car ils permettent de vérifier les résultats obtenus lors de l’étape de développement. On effectuera quelques jeux d’essai pour tester les services web grâce à l’extension Postman et on testera l’application elle-même.  Test des services web La méthode invoque un user. Figure 26 : Test des services web (un user)
 L’interface de s’authentifier Figure 27 : Page d'authentification  L’interface de créer compte Figure 28 : Page de créer compte
 L’interface de Gestion du compte Figure 29 : Page de Gestion du Compte Conclusion Tout à long de ce chapitre, nous avons réussi à réaliser notre premier sprint « Gestion du compte» l’analysé et pu développer. Dans le prochain chapitre, notre effort sera focalisé sur la réalisation de notre deuxième sprint « Gestion des centres des services ».
Chapitre 4 : Sprint 2 - Sprint Gestion des centres des services Dans ce chapitre, nous allons présenter notre deuxième sprint. A l’issue de ce dernier nous avons donc obtenu une deuxième version de notre application. Ce chapitre correspond à la tous ce qui est mise à jour à faire sur les établissements, les agences et les services. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1.Backlog Product Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux ajouter un établissement 1.1 Ajouter un « établissement » dans le web API Rimeh 1.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Sondes 1.3 Tester l’ajout d’un établissement Rimeh Sondes 2 2.1 Afficher les « établissements » Sondes
En tant qu’un utilisateur je peux afficher les établissements. dans le web API 2.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 2.3 Tester la récupération des établissements Rimeh Sondes 3 En tant qu’un utilisateur je peux supprimer un établissement. 3.1 Supprimer un « établissement » dans le Web API Sondes 3.2 Ajouter la méthode de suppression d’un établissement dans le contrôleur de l’application client Rimeh 3.3 Tester la suppression d’un établissement Rimeh Sondes 4 En tant que un utilisateur, je peux modifier un établissement. 4.1 Modifier un « établissement » dans le Web API Rimeh 4.2 Ajouter la méthode de modification d’un établissement dans la partie client Sondes 4.3 Tester la modification d’un établissement Sondes Rimeh 5 En tant que un utilisateur, je peux ajouter une agence à un 5.1 Ajouter une « agence » dans le web API Sondes 5.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Rimeh
établissement déterminé. 5.3 Tester l’affectation d’une agence. Rimeh Sondes 6 En tant qu’un utilisateur je peux afficher toutes les agences ou bien les agences d’un établissement. 6.1 Afficher les « agences » dans le web API Sondes 6.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 6.3 Tester la récupération des agences Sondes Rimeh 7 En tant qu’un utilisateur je peux supprimer une agence. 7.1 Supprimer une « agence » dans le Web API Sondes 7.2 Ajouter la méthode de suppression d’une agence dans le contrôleur de l’application client Rimeh 7.3 Tester la suppression d’une agence Sondes Rimeh 8 En tant que un utilisateur, je peux modifier une agence 8.1 Modifier une « agence » dans le Web API Sondes 8.2 Ajouter la méthode de modification d’une agence dans le contrôleur de l’application client Rimeh 8.3 Tester la modification d’une agence Rimeh Sondes
9 En tant que un utilisateur, je peux ajouter un service à un établissement et l’affecter à des agences. 9.1 Ajouter un « service » dans le web API Sondes 9.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Rimeh 9.3 Tester l’ajout d’un service Sondes Rimeh 10 En tant que un utilisateur, je peux lister tous les services, les services d’un établissement ou bien d’une agence donnée. 10.1 Afficher les « services » dans le web API Sondes 10.2 Ajouter les fonctionnalités de l’affichage dans le contrôleur de l’application client. Sondes Rimeh 10.3 Tester la récupération des services. Sondes 11 En tant que un utilisateur, je peux modifier service. 11.1 Modifier le « service » dans le web API Rimeh 11.2 Ajouter les fonctionnalités de la modification dans le contrôleur de l’application client. Sondes 11.3 Tester la modification d’un service. Rimeh Sondes 12 En tant que un utilisateur, je peux supprimer un service à partir de la liste des services, d’une agence ou bien d’un établissement. 12.1 Supprimer le « service » dans le web API Sondes 12.2 Ajouter les fonctionnalités de la suppression dans le contrôleur de l’application client. Rimeh
12.3 Tester le cas de la suppression service. Rimeh Sondes Tableau 11 : Backlog du second sprint 1.2. Prototypes des interfaces Pour bien assimiler ces « user stories », voici quelques prototypes des interfaces avant de commencer la phase d’analyse.  Prototype de l’interface "créer un établissement" Figure 30 : prototype d'interface ajouter un établissement  Prototype de l’interface "supprimer une agence" Figure 31 : prototype d'interface supprimer une agence
 Prototype de l’interface "modifier un service" Figure 32 : prototype d'interface modifier un service 2. Diagramme de cas d'utilisation du second sprint Une fois nous avons défini notre Backlog su sprint, on va traiter des fonctionnalités. Alors on va collecter plusieurs « users stories » en une fonctionnalité bien déterminée. 2.1. Classification des cas d’utilisation par acteurs ACTEUR CAS D’UTILISATION Utilisateur  Créer un établissement  Créer une agence  Créer un service  Afficher la liste des établissements  Afficher la liste des agences  Afficher la liste des services  Modifier établissement  Modifier agence  Modifier service  Supprimer établissement  Supprimer agence  Supprimer service Tableau 12 tableau de répartition de second sprint 2.2. Diagramme de cas d’utilisation du deuxième sprint
Figure 33 : Diagramme de cas d'utilisation globale de sprint 2 3. Analyse des cas d'utilisation 3.1. Analyse des cas d'utilisation « gérer établissement» 3.1.1. Raffinement du cas d’utilisation «gérer établissement» Figure 34 : diagramme du cas d'utilisation du cas gérer établissement 3.1.2. Description textuelle du cas « gérer établissement» Cas d’utilisation Gérer établissement Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi
l’option « gestion des établissements» Post condition Page d’accueil affichée Description du scénario principal 1-L’utilisateur choisi le lien gestion des établissements 2-Il clique sur le bouton « créer » ou « liste des établissements » 3-Le système affiche la page selon le lien choisi Exception Pas d’exception Tableau 13: description du cas d'utilisation « Créer compte » 3.1.1. Diagrammes de séquence système « gérer établissement »  Ajouter établissement Figure 35 : Diagramme de séquence du cas ajouter établissement  Modifier établissement
Figure 36 : Diagramme de séquence détaillé du cas modifier établissement 3.2. Analyse des cas d'utilisation « gérer agence» 4. Raffinement du cas d’utilisation «gérer agence» Figure 37 : Diagramme du cas d'utilisation du cas gérer agence
4.1.1. Description textuelle du cas « gérer agence» Cas d’utilisation Gérer agence Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « gestion des agences» Post condition Afficher la page d’accueil Description du scénario principal 1-L’utilisateur choisi le bouton gestion des agences 2-Il clique sur le lien « créer » ou « liste des agences » 3-Le système affiche la page selon le lien. Exception Pas d’exception Tableau 14: Description du cas d'utilisation « Gérer agence » 3.2.3. Diagrammes de séquence système « gérer agence »  Afficher agences
Figure 38 : Diagramme de séquence détaillé du cas chercher agences  Supprimer agence
Figure 39 : Diagramme de séquence détaillé du cas supprimer agence 4.2. Analyse des cas d'utilisation « gérer service» 4.2.1. Raffinement du cas d’utilisation «gérer service» Figure 40 : Diagramme du cas d'utilisation du cas gérer service
4.2.2. Description textuelle du cas « gérer service» Cas d’utilisation Gérer service Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « gestion des services» Post condition Afficher la page d’accueil Description du scénario principal 1-L’utilisateur choisi le bouton gestion des services 2-Il clique sur le lien « créer », « liste des services », « ajouter un service a une agence» ou « liste des services par une agence » 3-Le système affiche la page selon le lien. Exception Pas d’exception Tableau 15: Description du cas d'utilisation « Gérer service » 4.2.3. Diagrammes de séquence système « gérer services »  Affecter un service à une agence Figure 41 : Diagramme de séquence détaillé du cas affecter un service à une agence  Afficher la liste des services d’une agence
Figure 42 : Diagramme de séquence du cas afficher les services d’une agence 5. Conception de cas d'utilisation Nous nous intéressons dans cette partie aux diagrammes de classes. Par la suite, nous présenterons le Schéma de la base de données du deuxième sprint. 5.1. Diagramme de classe global de cas d’utilisation « Gérer les centres des services» Après tous le travail de spécification et de conception, nous pouvons maintenant construire le nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir des activités précédentes.
1..* 1..* 1..1 1..* établissement - - id_établissement libelle : int : String + + getLibelle () setLibelle () : String : void agence - - - id_agence libelle adresse : String : String : String + + + + getLibelle () getAdresse () setLibelle () setAdresse () : String : String : void : void service - - id_service libelle : int : String + + + getLibelle () setLibelle () getID () : String : void : int Figure 43 : Diagramme de classe globale de sprint 2 5.2. Schéma de la base des données : Gestion des centres des services On pourrait modéliser notre collection <<établissement>> de la façon suivante : _id: String Libellee: String Agence :{ _id : String Libellee: String Addressee: String Service :{ _id : String Libellee: String } } …. Document : établissement Collection : établissements
6. Implémentation  Schéma de la base de données « Etablissement » { "_id" : ObjectId("57547e94cb215c188a69944c"), "libelleEtb" : "CNAM", "agence" : [ { "libelleAgn" : "CNAM Tunis 3", "adresse" : "17 Rue Abderrahmane El Jaziri, Tunis 1002, Tunisie", "service" : [ "Bulletin de remboursement de frais de soins", "Demande de changement de filiere", "Demande de choix de médecin de famille" ] } 7. Test  Test des services web Cette méthode invoque la liste des établissements Figure 44 : Test des services web (la liste des établissements)  Interface créer établissement
Figure 45 : interface «créer établissement»  Interface liste établissements Figure 46 : interface «liste établissements»  Interface Modifier établissement
Figure 47 : interface «Modifier établissement»  Interface Supprimer établissement Figure 48 : interface «Supprimer établissement»  Interface liste des agences par établissement
Figure 49 : interface «liste des agences par établissement»  Interface liste des services par agence
Figure 50 : interface «liste des services par agence» Conclusion A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de valeur pour le client. Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau sprint couvrant les fonctionnalités de «Statistiques».
Chapitre 5 : Sprint 3 - Statistiques Dans le chapitre précédent, nous avant présentait notre deuxième sprint. A l’issue de ce sprint nous avons donc obtenu une deuxième version de notre application. Ce chapitre correspond à la tous ce qui est statistiques à faire sur l’application. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Backlog Product Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux consulter le nombre des agences par établissement. 1.1 Ajouter les fonctionnalités dans le contrôleur de l’application client. Rimeh 1.2 Tester l’affichage des graphiques Sondes En tant qu’un utilisateur je 2.1 Ajouter la méthode dans le contrôleur de l’application client. Sondes
2 peux afficher le nombre des services par établissement. 2.3 Tester la méthode. Rimeh 3 En tant qu’un utilisateur je peux afficher le nombre des services par agence. 3.1 3.2 Ajouter la méthode dans le contrôleur de l’application client Rimeh 3.3 Tester les fonctionnalités. Sondes Tableau 16: Backlog du troisième sprint 1.2. Prototypes d’interfaces Pour bien assimiler ces « user stories », voici quelques prototypes d’interfaces avant de commencer la phase d’analyse.  Prototype de l’interface " afficher statistiques" Figure 51 : prototype d'interface «afficher statistiques » 2. Diagramme de cas d'utilisation du troisième sprint Au début de chaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. Classification des cas d’utilisation par acteurs.
2.1. Classification des cas d’utilisation par acteurs ACTEUR CAS D’UTILISATION Utilisateur  Afficher le nombre des agences par établissement  Afficher le nombre des services par établissements  Afficher le nombre des services par agence. Tableau 17: tableau de répartition de troisième sprint 2.2. Diagramme de cas d’utilisation du troisième sprint Figure 52 : Diagramme de cas d'utilisation globale de sprint 3 2.3. Analyse Du cas «« afficher statistiques» : Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile.  Description textuelle du cas « afficher statistiques » Cas d’utilisation afficher nombre des agences par établissement Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « statistiques» Post condition Afficher les statistiques
Description du scénario principal 1-L’utilisateur clique sur le bouton statistiques 2-Il choisi un lien 3-Le système affiche la page des statistiques selon le lien choisi. Exception Pas d’exception Tableau 18 : Description textuelle du cas « afficher statistiques »  Diagramme de séquence système du cas « afficher statistiques » Figure 53: Diagramme de séquence système du cas « afficher statistiques » 3. Conception de cas d'utilisation « Afficher statistiques » : Nous nous intéressons dans cette partie aux diagrammes de classes et aux diagrammes séquence détaillées du troisième sprint.
3.1. Diagramme de classe 1..* 1..* 1..1 1..* établissement - - id_établissement libelle : int : String + + getLibelle () setLibelle () : String : void agence - - - id_agence libelle adresse : String : String : String + + + + getLibelle () getAdresse () setLibelle () setAdresse () : String : String : void : void service - - id_service libelle : int : String + + + getLibelle () setLibelle () getID () : String : void : int Figure 54: diagramme de classe de de cas d’utilisation « Afficher statistiques » 3.2. Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques » Figure 55: Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques »
4. Implémentation  Schéma de la base des données : Statistiques On pourrait utiliser notre collection <<établissement>> que nous avons déjà présenté dans le sprint précédent. 5. Test  Interface le nombre des agences par établissement Figure 56: Interface le nombre des agences par établissement  Interface le nombre des services par établissement
Figure 57: Interface le nombre des services par établissement  Interface le nombre des services par agence Figure 58: Interface le nombre des services par agence Conclusion Lors de ce sprint, on a analysé, conçu et pu développer les fonctionnalités de troisième sprint qui nous permet d’étudier les statistiques des établissements, des agences et des services. Dans le prochain sprint, on fera le sprint mobile.
Chapitre 6 : Sprint 4 - Sprint Mobile Dans le chapitre précédent, nous avant présentait notre troisième sprint. Ce chapitre correspond à la toux ce qui est mise à jour à faire sur l’application mobile. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécifications fonctionnelles Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Sprint Backlog Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID User story User Story ID Tâche Tâche Affectation 1 En tant que client, je veux consulter la liste des établissements. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter établissement » Rimeh MOUSSI 1.2 Développer le cas «Consulter établissement» Rimeh MOUSSI 1.3 Tester le cas «Consulter établissements» Sondes JAMI
2 En tant que client, je veux consulter la liste des services d’un établissement donné. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter service » Sondes JAMI 1.2 Développer le cas «Consulter service» Sondes JAMI 1.3 Tester le cas «Consulter service» Rimeh MOUSSI 3 En tant que client, je veux consulter la liste des agences ayant un service donné et ma position dans maps. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter agence dans le maps » Rimeh MOUSSI 1.2 Développer le cas «Consulter agence» Sondes JAMI 1.3 Tester le cas «Consulter agence» Rimeh MOUSSI 4 En tant que client, je veux réserver un ticket et faire la notification de tour 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas «Réservation un ticket » Sondes JAMI 1.2 Développer le cas «Réserver ticket» Rimeh MOUSSI 1.3 Tester le cas «Réserver ticket» Sondes JAMI Tableau 19: Backlog du quatrième sprint 1.2. Prototype d’interface Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint pour y mettre en évidence les fonctionnalités et bien les comprendre.
Affiche la liste des établissements, Puis, le client sélectionne un parmi cette liste Affiche la liste des services d’un établissement sélectionné Affiche la liste des agences les plus proches dans maps Affiche le ticket et les informations avec le QR Code. Après la réservation, remplir le formulaire de la notification de tour. Figure 59: prototype des interfaces mobile
2. Diagramme des cas d’utilisation du quatrième Sprint Au début de chaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. 2.1. Classification des cas d’utilisation par acteur Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur. Acteur Cas d’utilisation Client Réserver ticket Tableau 20 : Classification des cas d'utilisation par acteur 2.2. Diagramme de cas d’utilisation du quatrième sprint Figure 60: Diagramme de cas d'utilisation du quatrième sprint 2.2.1. Analyse Du cas « Réserver ticket» : Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile.  Description textuelle du cas «Réserver ticket»
Cas d’utilisation Réserver ticket Acteur Client Pré condition Etablissement inscrit dans la plateforme Post condition Ticket réservé Description 1. Le client choisi l’établissement 2. Le client choisi un service d’un établissement donné 3. Le client choisi une agence qui existe dans maps. 4. Le client réserve un ticket 5. Le client faire la notification de tour. Exception Problème de connexion réseau Tableau 21 : Description textuelle du cas «Réserver ticket»
 Diagramme de séquence système du cas « Réserver ticket » Figure 61: Diagramme de séquence du cas " réserver ticket" 3. Conception 3.1. Diagramme de classe réserver 1..1 1..1 ticket - - id_ticket QrCode : int : String + + ticket () toString () : void : String client - emailClient : String + + + + getEmail () setEmail () client () toString () : String : void : void : String Figure 62: diagramme de classe de quatrième sprint
4. Implémentation Notre base est définie comme ci-dessous, Ce qui nous donne par exemple un document agence : { "_id" : ObjectId("574ad27c3ea0f78f78f2d556"), "libelleAgn" : "Siège social CNSS", "adresse" : "49 Avenue Taieb M'Hiri, Tunis 1002, Tunisie", "IDetablissement" : "5743f48156fa1b72d9dc3d4d", "ticket_en_cours" : 2, "der_ticket_reserv" : 14, "emailClient " : "jamisondes1994@gmail.com" } 5. Test  Interface test de service web  Interface page d’accueil (Android & Ios) :
Figure 63: interface «page d'accueil »
 Interface liste établissement Figure 66: interface liste établissement  Interface liste services Figure 64: interface liste service  Interface liste des agences dans maps Figure 58 : interface liste agence Figure 65: interface liste agence
Les options dans notre application  Interface météo Figure 67: interface météo
 Interface information générale de l’application Figure 68: Interface information générale de l’application
 Interface les détails concernant chaque agence, la réservation
Conclusion Dans ce chapitre nous avons présenté et détaillé les différentes phases de sprint « Mobile » tels que la spécification fonctionnelles, les diagrammes, implémentation et test. A ce stade nous avons réussi à concevoir et développer un produit complet et fonctionnel.
Chapitre 7 : Phase de clôture Introduction Dans ce dernier chapitre, nous allons présenter la phase ultime de notre cycle de développement avec Scrum qui s’intitule : phase de clôture plus connue sous le nom de sprint de stabilisation. Il s’agira de définir les différents outils technologiques et l’environnement de développement auxquels nous avons eu recours. Ensuite, nous présenterons une schématisation des différentes tâches effectuées au cours de notre stage. 1. Environnement de développement 1.1. Environnement matériel Voici les caractéristiques techniques des machines que nous avons utilisées : Ordinateur Propriétaire Sondes JAMI Rimeh MOUSSI Processeur Core i3 Core i3 Ram 6 Go 4 Go Disque Dur 500 Go 500 Go Système d’exploitation Windows 7 Professional 64-bit Windows 7 Professional 64-bit Tableau 22: Environnement matériel
1.2. Environnement logiciel Rédaction du rapport : Word : est un logiciel de traitement de texte qui permet de taper des textes, ajouter des images, des graphiques, insérer des tableaux avec des multiples choix de polices et de conception Base des données : MongoDB : est un système de base de données dans la mouvance No SQL. Il est orienté documents. Son nom vient de Humongous qui veut dire énorme ou immense. L'objectif est donc de pouvoir gérer de grandes quantités de données. Robomongo : est un exemple notable d'application cliente de gestion de ce système de gestion de base de données NO SQL, et un client graphique disponible pour toutes les plateformes. Conception : PowerAMC : est un logiciel de modélisation (modeleur) de Sybase. En 2006, il inclut les modélisations de bases de données (MPD, MCD), UML, modélisation de traitements Merise (MCC, MOT, MCT) et modélisation de processus métier. Test : Postman : C’est un outil puissant de test des services web, devenu un outil incontournable pour de nombreux développeurs.
Google chrome : C’est un navigateur internet développé par Google. Ce navigateur est sur le marché depuis 2008 et fonctionne sur différentes plateformes (PC, tablettes, smartphone ...) et sous différents OS (Windows, mac, Linux, Android). Présentation : PowerPoint est un logiciel de Présentation Assistée par Ordinateur. Il permet de préparer des présentations contenant du texte, des images, des effets visuels, du son. Le mode Normal, que vous utilisez pour écrire et concevoir vos présentations, est le principal mode de modification. Implémentation : Sublime Text3 : est un éditeur de texte générique codé en C++ et Python, disponible sur Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension pour Vim (est un éditeur de texte), riche en fonctionnalités Interpréteurs de commandes : Node.js est une plateforme basée sur le moteur JavaScript V8, créée par Google pour Chrome qui s'exécute indifféremment côté client ou côté serveur. git : est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. Prototype :
Pencil : est un logiciel de création de maquettes typographiques libre et gratuit développé par Evolution Solutions (Evolus). Il est utilisé afin de créer des diagrammes et des maquettes d'interface graphique de logiciels. Gestion du projet : Gantt Project est un logiciel libre de gestion de projet écrit en Java, ce qui permet de l'utiliser sur de nombreux OS tel que Windows, Linux, MacOS. Ce projet a été lancé par un étudiant de l'université de Marne La Vallée en janvier 2003 et est maintenant proposé sous licence libre (GNU GPL). Microsoft Project (ou MS Project ou MSP) est un logiciel de gestion de projets édité par Microsoft. Il permet aux chefs de projet et aux planificateurs de planifier et piloter les projets, de gérer les ressources et le budget, ainsi que d'analyser et communiquer les données des projets. 1.3. Technologies et Langages de programmation utilisés MEAN JS Figure 69: Technologies & Langage de programmation utilisé
Express est un Framework MVC basé sur node.js, C'est de fait le Framework standard pour le développement de serveur en Node.js JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs. Ce langage, créé en 1995 par Brendan Eich AngularJS est une plateforme de développement pour créer des applications en utilisant les standards du web modernes. Angular comprend une foule de caractéristiques essentielles telles que les gestures mobiles, les animations, le filtrage, le routage, la liaison de données, la sécurité, l'internationalisation, et de belles composants d'interface utilisateur. Il est extrêmement modulaire, léger et facile à apprendre. Bootsrap : Il s’agit d’un éventail d’outils dédiés à la création de sites et applications web. Il se compose à la fois de HTML, ainsi que des modèles de conception à base de CSS pour la typographie, des formes, des boutons, la navigation et d'autres composants de l'interface et des extensions optionnelles JavaScript.
HTML5 désigne la dernière version du langage de développement web HTML. Il est généralement appris en parallèle du CSS et plus précisément dans notre cas avec le CSS3, ce dernier permet en effet d’animer des éléments HTML tout en effectuant des rotations, des transitions ou des changements. JSON (JavaScript Object Notation) est un format léger d'échange de données. Il est facile à lire ou à écrire pour des humains. Il est aisément analysable ou générale par des machines. Il est basé sur un sous-ensemble du langage de programmation JavaScript (JavaScript Programming Language, Standard ECMA-262 3rd Edition - Décembre 1999). Ionic est un puissant SDK HTML5 permettant de développer des applications mobiles en langage WEB (HTML / CSS / JS). Le but primaire de ce tout nouveau SDK est de permettre un développement plus court et efficace sur différentes plateformes mobiles tout en gardant la même interaction et design qu'une application native.
2. Style architectural 2.1. Architecture du système Figure 70: Architecture générale de l'application Administrateur Service Web MongoDB Client JSON Application web Back office a Application mobile Front office
Le processus de l’application qui admet une architecture orientée service se fait comme suit : L'échange de données entre la partie back office (Application web sous le patron MVC) et le web API se fait grâce au protocole moderne http, même chose pour la partie front office (Application mobile hybride), les données sont sous format JSON. Les systèmes qui suivent les principes de l'architecture REST sont souvent appelés RESTful. Les web services de type REST consistent à des méthodes de type GET, POST, PUT ou bien DELTE.  Les web services sont des composants distribués qui offrent des fonctionnalités aux applications au travers du réseau en utilisant des standards ouverts. Ils peuvent donc être utilisés par des applications écrites dans différents langages et exécutées dans différentes plateformes sur différents systèmes. Les services web utilisent une architecture distribuée composée de plusieurs sites ou systèmes différents qui communiquent sur le réseau. Ils mettent en œuvre un ensemble de normes et standards ouverts qui permettent aux développeurs d’implémenter des applications distribuées internes ou externes en utilisant des outils différents. Un service web permet généralement de proposer une ou plusieurs fonctionnalités métiers qui seront invoqué par un ou plusieurs consommateurs. Il existe deux grandes familles de service web : • Les services web de type SOAP (Simple Object Access Protocol). • Les services web de type REST (Representational State Transfer).  L’architecture REST n’est pas un protocole en soi, ni une technologie, mais une "philosophie" de l’utilisation du Web. Le protocole utilisé ici est simplement HTTP avec ses méthodes (GET, POST et les autres...). Cette philosophie estime qu’il n’est, dans bien des cas, pas nécessaires de faire appel aux couches d’abstraction proposées par SOAP et que les méthodes de HTTP, combinées avec de bonnes URIs (Uniform Resource Identifier), suffisent amplement dans la majorité des cas. Il est facile de voir que la méthode la plus simple est REST, qui a l’avantage énorme de ne pas ajouter une couche d’abstraction des données qui n’en ont pas forcément besoin. Cette méthode été retenu pour la réalisation de notre application.
Enfin, l’utilisateur aura la possibilité d’utiliser l'application à travers un navigateur. Figure 71: Architecture du service web REST 2.2. Le patron de conception MVC Le système a été développé sous le patron de conception MVC (Model View Controller)  Modèle : Il s’agit des données et de l’état de votre application web. En général, ces données sont représentées par un ensemble de classes qui permettent d’accéder à une base de données, mais les données pourraient tout aussi bien être stockées dans des fichiers ou utiliser des services.  Vue : C’est l’interface qui affichera les données, Il s’agira globalement de code HTML et de CSS. Le but de la vue est de présenter les données issues du modèle mais sans les modifier, sans en interpréter le contenu.  Contrôleur : il fait le lien entre la vue et le modèle. Le contrôleur gère les interactions avec l’utilisateur et détermine quels traitements doivent être effectués pour une action données.
Figure 72: Architecture du patron MVC 3. Gestion de projets 3.1. Planning des histoires Les figures suivantes présentent les tableaux de la répartition des tâches pour les membres de l’équipe de développement pour les quatre sprints : Figure 73: tableau « répartition des tâches de premier sprint »
Figure 74: tableau « tâches du deuxième sprint » Figure 75: tableau « tâches du troisième sprint » Figure 76: tableau « tâches du quatrième sprint »
3.2. Diagramme de Gantt « Le diagramme de Gantt, couramment utilisé en gestion de projet, est l'un des outils les plus efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches) qui constituent un projet » [8] Figure 77 : Diagramme de Gant Conclusion Au cours de ce dernier chapitre, nous avons essayé de présenter les différents travaux qui contribuent du bon déroulement de notre projet. Ce chapitre engendre la fin de cycle de développement Scrum, en effet on obtient le fruit du travail exécutable avec la présentation de technologies adoptées et diagramme de Gantt.
Conclusion générale & perspective Ce projet représente le fruit du travail effectué au sein de LYNA-ICT (Information and Communication Technologies) dans le cadre du projet de fin d’études pour l’obtention du Licence Appliqué en développement de système d’information à l’ISET Rades (Institut supérieure des études technologique). Ce stage nous a permis d’apprendre comment définir des objectifs et mettre en place les moyens pour les atteindre. Bien entendu, cela n’aurait jamais été possible sans l’aide inestimable de nos encadreurs. Le projet consistait à concevoir et réaliser une application mobile pour la réservation des tickets auprès des guichets de service. Ce projet nous a permis de mettre en application les connaissances théoriques que nous avons pu acquérir au cours des trois années d’études à l’ISET. Ce fut également une opportunité de nous confronter aux difficultés du monde du développement et de la gestion d’un projet. En introduction du présent rapport, nous avons présenté le contexte général de notre stage, qui s’est déroulé au sein de la société. Nous avons poursuivi par l’étude de l’existant grâce à laquelle nous avons déterminé les exigences et besoin du projet. Nous avons employé les méthodes Agiles dans la gestion et suivi du projet et nous avons opté pour la méthode SCRUM qui se base sur le principe des sprints, dans le cas de notre projet on a eu recours à 4 sprints. Les sprints se répartissent comme suit : on a commencé par les users Stories et leurs spécificités, on a enchaîné par la schématisation en diagrammes des cas d’utilisation liées aux fonctionnalités, puis on a décrit le déroulement des scénarios ; nous avons terminé par la conception et l’implémentation des bouclée par des tests. Cet application sera complète en matière de fonctionnalités et donnera pleine réponse à leurs besoins avec plus de liberté, de transparence et d’efficacité. Durant la réalisation de cette application, nous avons pu nous imprégner de l’architecture trois tiers et apprendre à manipuler l’éditeur Sublime et à développer avec plusieurs technologie comme (Node JS, AngularJS, Ionic, …) et à conçu avec base de donnée NO SQL MongoDB qui nous a posé quelques difficultés tout au début. La richesse de ce sujet était une opportunité pour profiter tant dans l'acquisition des connaissances que sur l’aspect travaille en équipe. Et surtout ce projet lié au stage, était une découverte du monde professionnel, ses réalités, notamment des aspects adaptation et difficultés. Perspectives :
 Le client peut annuler le ticket après la réservation.  Le client peut faire la notification de tours avec e-mail.  L’utilisateur de back office peut afficher les statistiques des tickets.
Annexe ANNEXE 1 : Etude approfondie sur les méthodes agiles et la méthode « Scrum » Au cours de ce rapport nous avons utilisé le mot Scrum une centaine de fois. Nous avons également présenté la théorie, la définition, les méthodologies Scrum… Dans la réalité de notre projet, Scrum était en fait une expérience unique. Nous avons organisé des réunions quotidiennes pour faire le suivi de notre Backlog, sous la baguette du Maitre du Scrum à savoir : Monsieur Anass Saïd. Il a vraiment orchestré le travail de toute l'équipe comme un chef d'orchestre : répartition des tâches, suivi des actions, priorisation des actions. La présence des différents « Product Owner », à savoir les directeurs de département, a été d’une aide précieuse pour avancer efficacement dans nos travaux et aller droit au but. Les figures ci-dessous où l’on peut voir le « Backlog produit » et le suivit des actions selon leurs statuts : A faire, en cours, terminé.
ANNEXE 2 : IONIC Ionic Framework est un mélange d’outils et de technos pour développer des applications mobiles hybrides rapidement et facilement. Il s’appuie sur AngularJS pour la partie application web du Framework et sur Cordova pour la partie construction des applications natives. Ce Framework open source permet de développer une application déployable sur plusieurs environnements tels qu’un site web ou une application mobile pour des systèmes tels qu’Android ou iOS ou Windows Phone… Historique Ionic va vous permettre de développer une application web qui aura l'air d'une application native. Elle en partagera également certaines capacités comme l'accès aux éléments systèmes. C'est ce qu'on appelle une application hybride. La majeure partie de son code est en technologie du web (JavaScript/html/css) et pour tout le reste, il y a des plugins qui font l'interface entre le smartphone et votre application. Ionic 1 est basé sur Cordova et Angular 1. Il fournit des briques qui vous permettront de créer une application proche du natif. Les équipes de Drifty ont mis tout en œuvre pour faciliter la vie du développeur mobile hybride en lui fournissant un environnement simple et un Framework pratique. Leur Framework a tellement fait sensation qu'ils ont levé un million de dollars en 2014, alors que la startup n'avait que 2 ans d’existence. Cela a permis à leurs équipes de repenser leur création, en apprenant de leurs erreurs, des demandes de la communauté et en mettant à jour les briques sur lesquelles repose le Framework. Ionic 2 est notamment passé de Angular1 à Angular2 et utilise désormais web pack en lieu et place de bower et gulp. Ionic 2 permet également d'utiliser les évolutions de JavaScript avec les syntaxes d'ES6/ES2015 et d'ES7. Une présentation a été faite à l'Angular
Connect qui a fait bonne impression tant les performances ont été améliorées, surtout concernant les animations. La version 2 est encore en version alpha, nous nous concentrerons dans la suite de cette présentation à Ionic 1 qui est la version stable actuellement. Installer Ionic Pour commencer, Ionic Framework s’appuie sur la plateforme Node JS et plus précisément NPM (Node Package Manager) pour installer les nouveaux modules développés par la communauté et gérer les dépendances entre les modules, donc il vous faudra l’installer (si vous ne l’avez pas déjà fait). Ensuite, pour générer une application mobile hybride, il vous faut le SDK Java et le SDK Android (si on veut faire une application Android ou tout autre SDK pour la plateforme visée), qui serviront à la compilation et à la construction de l’application. Commençons par installer notre environnement de travail.  Installer node.js (https://nodejs.org/en/ ) ;  Et les outils en ligne de commande (CLI) pour Cordova et Ionic : $ npm install -g ionic cordova Créer un projet Ionic Pour commencer une application avec Ionic, il suffit d'utiliser la CLI. Essayons la commande suivante : $ ionic templates Pour avoir un bon aperçu de ce que propose le Framework, nous allons partir d'un Template assez complet : $ ionic start myApp tabs $ ionic start myApp blank $ ionic start myApp tabs $ ionic start myApp sidemenu À ce stade, nous avons un répertoire contenant le patron minimum de notre future application.
Ajouter des plugins avec Ionic $ ionic plugin cordova-plugin-console 1.0.1 "Console" cordova-plugin-device 1.0.1 "Device" cordova-plugin-splashscreen 2.1.0 "Splashscreen" cordova-plugin-statusbar 1.0.1 "StatusBar" cordova-plugin-whitelist 1.0.0 "Whitelist" ionic-plugin-keyboard 1.0.8 "Keyboard" Déployer une application Ionic Ici et comme sur les smartphones, il y a deux mondes : Android et Ios. Pour chacun de ces deux mondes, il faut installer les outils de développement spécifiques à chacun avant de pouvoir émuler ou compiler l'application.
Pour installer les outils Ios, il faut être dans la sphère Apple et donc posséder une machine avec OSX et XCode. Pour installer les outils Android, c'est un peu plus ouvert car basé sur java, et nous avons donc la possibilité d'utiliser au choix, Windows, OSX ou une distribution Linux. Une fois l'environnement prêt, nous pouvons générer les fichiers nécessaires à la plateforme désirée : $ ionic platform add android $ ionic platform add ios Vous pouvez alors packager votre application pour la tester soit sur un émulateur, soit sur un périphérique réel. De manière générale il est toujours préférable de tester sur de vrais smartphones et tablettes, notamment à cause de la lenteur et l'imperfection des émulateurs fournis. Pour packager: $ ionic build android $ ionic build ios Pour émuler : $ ionic emulate android $ ionic emulate ios Pour déployer sur un périphérique de test, cela diffère selon la plateforme : Pour Android : $ ionic run android Pour Ios, vous avez deux solutions :  Ouvrir le fichier XCode généré dans le dossier Platform/Ios avec XCode lui- même, puis sélectionner le périphérique souhaité via l'interface et cliquer sur le bouton Play.  Installer le packet npm ios-deploy en global afin de pouvoir lancer directement l'application sur le périphérique via la commande : ionic run ios --device
ANNEXE 2 : MongoDB MongoDB (venant du terme « Humongous » = « énorme ») est la première base de données, permettant aux sociétés d'être plus rapides et évolutives. Les entreprises de toutes tailles utilisent MongoDB pour créer de nouveaux types d'applications, améliorer la façon de travailler avec ses clients, accélérer les temps de mise sur le marché et faire baisser les coûts. Elle est une base de données rapide, permettant aux référentiels d'évoluer aussi rapidement que les applications, tout en procurant aux concepteurs les fonctionnalités attendues des bases de données usuelles, notamment des indexes secondaires, un langage complet de requêtes et une stricte cohérence et stabilité. MongoDB est conçue pour l'évolution, les performances et la haute disponibilité, passant de l'installation sur de simples serveurs, à des architectures complexes déployées sur plusieurs sites. En tirant profit du calcul en mémoire, MongoDB permet de lire et d'écrire très rapidement. La réplication intégrée à MongoDB et le basculement automatique, permettent une souplesse opérationnelle et une fiabilité de classe « entreprise ». Les souscriptions MongoDB permettent de profiter d’un support professionnel, d’une licence commerciale, ainsi que des fonctionnalités de MongoDB Enterprise. Les souscriptions aident nos clients à construire non seulement une infrastructure informatique sûre, évolutive et stable, mais également à atteindre des objectifs commerciaux plus importants, notamment en termes de réduction des coûts, d'accélération du temps de mise sur le marché, et d'atténuation des risques. MongoDB Enterprise permet de profiter de fonctionnalités de sécurité, de surveillance, du support SNMP, de certifications et bien plus encore. MongoDB Management Service (MMS) permet de profiter d’outils de surveillance et de sauvegarde, proposés soit dans Cloud soit dans votre Datacenter avec MongoDB Enterprise. Pour le moment, lorsque nous faisons une requête, nous récupérer les documents dans leur ensemble. Si les documents sont volumineux, il peut être intéressant de ne récupérer que les valeurs qui nous intéressent. MongoDB limite la taille des documents à 16MB, ce qui est une taille important pour un document JSON. Si vos documents sont plus importants, vous pouvez les découper en plusieurs collections (et vous l'aurez probablement fait avant d'approcher cette limite).
Comme dans une base relationnelle, on utilise les _id pour faire les liens entre plusieurs collections. La différence est qu'il n'y a pas de jointure. Il vous faudra alors faire 2 requêtes. Installer MongoDB pour Windows: http://www.mongodb.org/downloads Mettre en phase l’environnement MongoDB : MongoDB nécessite un répertoire de données pour stocker toutes les données. Le chemin du répertoire de données par défaut de MongoDB est data db. Créer ce dossier en utilisant les commandes suivantes à partir d’une invite de commande : md datadb Démarrez MongoDB Pour démarrer MongoDB, exécutez mongod.exe . Par exemple, à partir de l’invite de commande : C:mongodbbinmongod.exe Connectez-vous à MongoDB Pour se connecter à MongoDB à travers le mongo.exe Shell, ouvrir une autre invite de commande : C:mongodbbinmongo.exe
ANNEXE 3 : Node js  Présentation Node.js Figure 78: Les 3 vies de JavaScript JQuery n'est pas mort et ça ne veut pas dire qu'il faut cesser de l'utiliser (par contre DHTML et Netscape sont bel et bien morts eux). Les nouveaux outils JavaScript comme Node.js font des choses très différentes de jQuery et consorts. Les deux peuvent tout à fait se compléter. Node.js nous permet d'utiliser le langage JavaScript sur le serveur... Il nous permet donc de faire du JavaScript en dehors du navigateur ! Node.js bénéficie de la puissance de JavaScript pour proposer une toute nouvelle façon de développer des sites web dynamiques. Node.js : le JavaScript côté serveur JavaScript avait toujours été utilisé du côté du client, c'est-à-dire du côté du visiteur qui navigue sur notre site. Le navigateur web du visiteur (Firefox, Chrome, IE...) exécute le code JavaScript et effectue des actions sur la page web.
Figure 79: Le schéma classique : PHP sur le serveur, JavaScript chez le client Node.js offre un environnement côté serveur qui nous permet aussi d'utiliser le langage JavaScript pour générer des pages web. En gros, il vient en remplacement de langages serveur comme PHP, Java EE, etc. Figure 80: Avec Node.js, on peut aussi utiliser du JavaScript sur le serveur  Node.js est rapide Si Node.js est rapide, cela tient principalement à deux choses : le moteur V8 et son fonctionnement non bloquant. Node.js utilise le moteur d'exécution ultrarapide V8 de Google Chrome. Ce moteur V8 avait fait beaucoup parler de lui à la sortie de Google Chrome, car c'est un outil open source créé par Google qui analyse et exécute du code JavaScript très rapidement.
Figure 81: Le logo du moteur JavaScript V8 de Google  Installation Pour installer Node.js sous Windows, il suffit de télécharger l'installeur qui est proposé sur le site de Node.js(https://nodejs.org/en/ ).  Node.js : c'est l'interpréteur de commandes de Node.js (dont nous parlerons à la fin de ce chapitre). Nous l'utiliserons assez peu en pratique. Il sert à tester des commandes JavaScript.  Node.js command prompt : c'est une console de Windows configurée pour reconnaître Node.js. C'est par là que vous passerez pour lancer vos programmes Node.js, c'est donc ce que nous utiliserons le plus souvent. NPM (nœud gestionnaire de paquet) : Depuis les versions les plus récentes de Node.js, il faut savoir que NPM est installé en même temps automatiquement. NPM est le gestionnaire de paquets de Node.js (c'est un peu l'équivalent de apt, mais pour les extensions Node.js). NPM est vraiment un outil formidable qui nous permet d'étendre les possibilités de Node.js à l'infini, nous le découvrirons un peu plus tard. Bower : Bower est un système de gestion des paquets pour la programmation côté client sur le World Wide Web, il nous permet d’installer des bibliothèques. Cela dépend de Node.js et NPM. Il fonctionne avec git et dépôts GitHub. Il a été initialement développé sur Twitter par Jacob Thornton, Co-créateur du cadre Bootsrap avec succès, qui a contribué à Bower gagné rapidement adoption. Installer Bower Ouvrez une console Windows ou l’invite de commande et exécutez la commande suivante : npm install -g bower
Bibliographie [4] Ken Schwaber .Jeff Stherland, le guide Scrum, edition creative commons, 2013. [5] F. V. Pascal Roques, UML2 en action de l'analyse des besoins à la conception, edition Eyrolles, 2007. [6] Claude Aubry, le guide pratique de la méthode agile la plus populaire. Neto graphie [1] http://ineumann.developpez.com/tutoriels/alm/agile_scrum/ [2] http://geekandmore.fr/tag/scrum/ [3] https://confluence.atlassian.com/agile/glossary/sprint-backlog [7] http://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-classes [8] http://www.gantt.com/fr/index.htm [9] https://amethyste16.wordpress.com/2014/08/30/les-jetons-jwt-ce-quun-developpeur- doit-connaitre/ [10] https://fr.wikipedia.org/wiki/Bcrypt Documentation Ionic http://ionicframework.com/ http://forum.ionicframework.com/ Documentation Apache Cordova https://cordova.apache.org/ http://ngcordova.com/ Documentation AngularJS https://angularjs.org/ https://openclassrooms.com/courses/developpez Documentation AngularJS https://angularjs.org/ https://openclassrooms.com/courses/developpez Recherches de solutions https://github.com/ http://stackoverflow.com/ Documentation MongoDB https://docs.mongodb.com/ Développement avec MEAN http://mean.io/#!/ https://blog.udemy.com/node-js-tutorial/#7_1 Documentation Bootsrap http://getbootstrap.com/

Contenu connexe

PDF
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
parRiadh K.
 
PDF
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
PDF
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
PDF
Rapport de stage du fin d'étude
parYahyaoui Mohamed Yosri
 
PDF
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
PDF
Pfe conception et réalisation d'une application de gestion des processus d'ac...
parAhmed Makni
 
PDF
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
PDF
Rapport pfe
parAhmed rebai
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
parRiadh K.
 
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
Rapport de stage du fin d'étude
parYahyaoui Mohamed Yosri
 
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
parAhmed Makni
 
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
Rapport pfe
parAhmed rebai
 

Tendances

PDF
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
parSofien Benrhouma
 
PDF
Rapport De PFE
parNadir Haouari
 
PDF
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
PPT
présentation soutenance PFE.ppt
parMohamed Ben Bouzid
 
PDF
Rapport Projet Fin d'Études PFE
parMohamed Amine Mahmoudi
 
PPTX
Présentation PFE
parSemah Mhamdi
 
PPTX
Présentation projet de fin d'étude
parDonia Hammami
 
PDF
Rapport de projet de fin d'année
parkaies Labiedh
 
PDF
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
PDF
Rapport- Conception et réalisation d'une plateforme social learning
parRouâa Ben Hammouda
 
PDF
Rapport du projet fin d'etudes
parTahani RIAHI
 
PDF
Pfe conception et développement d'une application web GMAO JEE
parOussama Djerba
 
PDF
Rapport PFE Ahmed BEN JEMIA
parAhmed BEN JEMIA
 
PDF
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
parMohamed Cherkaoui
 
PDF
Conception et Réalisation Application Web Laravel PFE BTS
parFaissoilMkavavo
 
PDF
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
PDF
Rapport de projet de conception et de développement
parDonia Hammami
 
PDF
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
PDF
Rapport de stage développement informatique
parMehdiOuqas
 
PDF
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
parMohamed Amine Mahmoudi
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
parSofien Benrhouma
 
Rapport De PFE
parNadir Haouari
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
présentation soutenance PFE.ppt
parMohamed Ben Bouzid
 
Rapport Projet Fin d'Études PFE
parMohamed Amine Mahmoudi
 
Présentation PFE
parSemah Mhamdi
 
Présentation projet de fin d'étude
parDonia Hammami
 
Rapport de projet de fin d'année
parkaies Labiedh
 
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
Rapport- Conception et réalisation d'une plateforme social learning
parRouâa Ben Hammouda
 
Rapport du projet fin d'etudes
parTahani RIAHI
 
Pfe conception et développement d'une application web GMAO JEE
parOussama Djerba
 
Rapport PFE Ahmed BEN JEMIA
parAhmed BEN JEMIA
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
parMohamed Cherkaoui
 
Conception et Réalisation Application Web Laravel PFE BTS
parFaissoilMkavavo
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
Rapport de projet de conception et de développement
parDonia Hammami
 
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
Rapport de stage développement informatique
parMehdiOuqas
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
parMohamed Amine Mahmoudi
 

Similaire à Rapport stage pfe

PDF
Rapport_pfe_licence_ISAMM
parEya TAYARI
 
DOCX
Rapport de projet de fin d’étude
parOumaimaOuedherfi
 
PDF
Conception et développement d’une plateforme d'import-export avec paiement en...
parKarim Ben Alaya
 
PDF
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
parYasmine Tounsi
 
PDF
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
parIbtihel El Bache
 
PDF
Conception et développement d’un système d’alerte et notification d’une tou...
parBilel Khaled ☁
 
PDF
Front office back office caisse
parBen Sassi Mohamed Ridha
 
PDF
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
parElAzzabAbdeSsamad
 
PDF
Rapport pfe-ayoub mkharbach
parAyoub Mkharbach
 
PDF
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
parRamzi Noumairi
 
PDF
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
PDF
Rapport PFE réalisation d’un Framework Kinect
parAmine MEGDICHE
 
PDF
Projet Fin D'étude Application Mobile
parRim ENNOUR
 
PDF
Rapport de Stage Fin D’étude - Développement Web et Multimédia
parYassineMyara
 
PDF
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
parSarra LAOUINI
 
PDF
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
parGHITAMASROUR
 
PDF
Rapport de PFE : Conception et développement d’un ERP module gestion commerci...
parAyoub BANANI
 
PDF
Application web de la gestion mabrouki soukayna 3026(1)
parMohamed Tcatvtg
 
PDF
458008733-Rapport-de-projet-de-fin-d-etudes.pdf
parsoyedmohamed
 
PDF
Rapport PFE
parIbtissemSlimeni
 
Rapport_pfe_licence_ISAMM
parEya TAYARI
 
Rapport de projet de fin d’étude
parOumaimaOuedherfi
 
Conception et développement d’une plateforme d'import-export avec paiement en...
parKarim Ben Alaya
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
parYasmine Tounsi
 
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
parIbtihel El Bache
 
Conception et développement d’un système d’alerte et notification d’une tou...
parBilel Khaled ☁
 
Front office back office caisse
parBen Sassi Mohamed Ridha
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
parElAzzabAbdeSsamad
 
Rapport pfe-ayoub mkharbach
parAyoub Mkharbach
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
parRamzi Noumairi
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
Rapport PFE réalisation d’un Framework Kinect
parAmine MEGDICHE
 
Projet Fin D'étude Application Mobile
parRim ENNOUR
 
Rapport de Stage Fin D’étude - Développement Web et Multimédia
parYassineMyara
 
Rapport de PFE du Diplôme de Mastère pro en Modélisation, Bases de Données et...
parSarra LAOUINI
 
117607486-Application-Web-de-Gestion-de-stock-du-magasin-de-Faculte-de-Medeci...
parGHITAMASROUR
 
Rapport de PFE : Conception et développement d’un ERP module gestion commerci...
parAyoub BANANI
 
Application web de la gestion mabrouki soukayna 3026(1)
parMohamed Tcatvtg
 
458008733-Rapport-de-projet-de-fin-d-etudes.pdf
parsoyedmohamed
 
Rapport PFE
parIbtissemSlimeni
 

Rapport stage pfe

  • 1.
    1 Projet de Find’Etudes Pour l’obtention du : Diplôme de Licence Appliquée en Technologies de l’Information Réalisé par : Sondes JAMI Rimeh MOUSSI Entreprise d’accueil : LYNA-ICT Encadré par : Encadreur Entreprise : Mr. Anass Saïd Encadreur ISET Radés : Mme. Eya Cheikh Année Universitaire : 2015/2016 Ministère de l’Enseignement Supérieur, de la Recherche Scientifique et des Technologies de l'Information et de la Communication *** * *** Institut Supérieur des Etudes Technologiques de Radés Conception & Développement d’une application mobile pour la réservation des tickets auprès des guichets de service -------------------------------------------------- -------------------------------------------------- ------------------------------------------
  • 2.
    Dédicaces Je dédie cemodeste travail et ma profonde gratitude : À mon père et ma mère Autant de phrases aussi expressives soient-elles ne sauraient montrer le degré d’amour et d’affection que j’éprouve pour eux. Merci pour tout l'amour et la confiance et pour votre énorme support pendant la réalisation de mon projet. "Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai toujours de mon mieux pour rester votre fierté et ne jamais vous décevoir...» Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude et de ma reconnaissance. A mes frères Moncef, Ramzi et Abd Alwaheb Pour leur patience, leur amour et leur encouragement. A mes sœurs Dalila, Bornia et Rahma Sans leurs conseils et leur amour je serai perdue... A mes grands-parents Boujema et Zina Pour leurs encouragements continus et leurs confiances énormes en moi. À ma grande famille, petite et grande, qui a cru en moi, à mes cousins et cousines… A tous mes amis et mes collègues qui m’ont soutenu. À tous mes professeurs pendant mon parcours de l’école vers l’université. À toute personne qui a gravé ma vie par un mot qui m’a orienté vers le bon chemin... Sondes JAMI
  • 3.
    Dédicaces A Mes TrèsChers Parents (AZOUZ & RAFOUKA) Tous les mots du monde ne sauraient exprimer l’immense amour que je vous porte, ni la profonde gratitude que je vous témoigne pour tous les efforts et les sacrifices que vous n’avez jamais cessé de consentir pour mon instruction et mon bien-être. C’est à travers vos encouragements que j’ai opté pour ce chemin, et c’est à travers vos critiques que je me suis réalisé. J’espère avoir répondu aux espoirs que vous avez fondés en moi. Je vous rends hommage par ce modeste travail en guise de ma reconnaissance éternelle et de mon infini amour. Que Dieu tout puissant vous garde et vous procure santé, bonheur et longue vie pour que vous demeuriez le flambeau illuminant le chemin de vos enfants. Je dédie aussi ce travail à : Mon frère(Nazoura) & Mes soeurs (TAssouma , Fatouna & Hallouma ) pour leurs encouragements incessants. A Tous mes enseignants et Tous mes amis en souvenir des bons moments que nous avons passés ensemble, pour leur soutien continu, leur aide précieuse et leur amour. Rimeh MOUSSI
  • 4.
    Remerciements Nous voudrons avanttout adresser notre gratitude et notre profonde reconnaissance à tous ceux qui, de près ou de loin, ont contribué à l’aboutissement de ce travail. Nous tenons à exprimer nos vifs remerciements en premier lieu à notre encadreur de LYNA-ICT Anass Saïd. Nous adressons aussi nos profonds remerciements à Monsieur Mehdi Metir enseignant au sein de l’institut pour ses conseils et Madame Eya Cheikh, notre encadreur au sein de l’ISET Rades, pour son encadrement, son soutien et sa disponibilité qui nous ont guidés tout au long de notre stage. Par la même occasion, Nous exprimons nos sincères reconnaissances à l’égard de tous ceux qui ont contribué à notre formation, particulièrement les enseignants de l’institut supérieur des études technologiques de radés. Finalement, Nous tenons aussi à remercier vivement les membres du jury qui nous ont fait l’honneur d’évaluer ce travail. Rimeh & Sondes
  • 5.
    Table des matières Introductiongénérale........................................................................................................................... 11 Chapitre 1 : Cadre du projet et méthodologie.................................................................................. 12 1. Présentation de l’organisme : LYNA-ICT ............................................................................ 12 2. Etude de l’existant................................................................................................................... 13 2.1. Etat actuel :...................................................................................................................... 13 2.2. Analyse ............................................................................................................................. 15 3. Critique de l’existant............................................................................................................... 16 4. Solution proposée ........................................................................................................................ 17 5. Cahier des charges....................................................................................................................... 17 6. Langage et méthodologie de conception.................................................................................... 18 6.1. Méthodes agiles..................................................................................................................... 18 6.2. SCRUM ................................................................................................................................. 20 6.3. Langage de modélisation UML (Unified Modeling Language)........................................ 24 Chapitre 2 : Planification & architecture ......................................................................................... 25 1. Spécification des besoins......................................................................................................... 25 1.1. Identification des acteurs du système ............................................................................ 25 1.2. Les besoins fonctionnels.................................................................................................. 26 1.3. Les besoins non fonctionnels........................................................................................... 27 2. Structure et découpage du projet : ........................................................................................ 27 2.1. Identification de l’équipe SCRUM................................................................................. 27 2.2. Découpage des sprints..................................................................................................... 28 2.3. Le Backlog du produit..................................................................................................... 29 2.4. Planification des releases ................................................................................................ 30 2.5. Diagramme de cas d’utilisation initial........................................................................... 32 2.6. Diagramme de classe initial ............................................................................................ 32 Chapitre 3 : Sprint 1 - Sprint Gestion du compte ............................................................................ 34 1. Spécification des besoins......................................................................................................... 34 2. Diagramme des cas d’utilisation du premier Sprint ............................................................ 36 2.1. Classification des cas d’utilisation par acteur............................................................... 37 2.2. Analyse des cas d’utilisation........................................................................................... 38 2.3. Analyse Du cas « Créer compte »................................................................................... 39 2.4. Analyse Du cas « Gérer compte »................................................................................... 40
  • 6.
    3. Conception descas d’utilisation............................................................................................. 42 3.1. Diagramme de classes du premier sprint : Gestion du compte................................... 42 3.2. Schéma de la base des données : Gestion du compte.................................................... 43 4. Implémentation........................................................................................................................ 43 5. Test............................................................................................................................................ 44 Chapitre 4 : Sprint 2 - Sprint Gestion des centres des services....................................................... 47 1. Spécification des besoins......................................................................................................... 47 1.1. Backlog Product ................................................................................................................ 47 1.2. Prototypes des interfaces ................................................................................................ 51 2. Diagramme de cas d'utilisation du second sprint................................................................. 52 2.1. Classification des cas d’utilisation par acteurs ............................................................. 52 2.2. Diagramme de cas d’utilisation du deuxième sprint .................................................... 52 3. Analyse des cas d'utilisation ................................................................................................... 53 3.1. Analyse des cas d'utilisation « gérer établissement» .................................................... 53 3.2. Analyse des cas d'utilisation « gérer agence»................................................................ 55 4.2. Analyse des cas d'utilisation « gérer service» ............................................................... 58 5. Conception de cas d'utilisation............................................................................................... 60 5.1. Diagramme de classe global de cas d’utilisation « Gérer les centres des services» ... 60 5.2. Schéma de la base des données : Gestion des centres des services.............................. 61 6. Implémentation........................................................................................................................ 62 7. Test............................................................................................................................................ 62 Chapitre 5 : Sprint 3 - Statistiques .................................................................................................... 67 1. Spécification des besoins......................................................................................................... 67 1.1. Backlog Product ................................................................................................................ 67 1.2. Prototypes d’interfaces .................................................................................................... 68 2. Diagramme de cas d'utilisation du troisième sprint............................................................. 68 2.1. Classification des cas d’utilisation par acteurs ............................................................. 69 2.2. Diagramme de cas d’utilisation du troisième sprint ....................................................... 69 2.3. Analyse Du cas «« afficher statistiques» : ..................................................................... 69 3. Conception de cas d'utilisation « Afficher statistiques » : .................................................. 70 3.1. Diagramme de classe....................................................................................................... 71 3.2. Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques ».......... 71 4. Implémentation........................................................................................................................ 72 5. Test............................................................................................................................................ 72 Chapitre 6 : Sprint 4 - Sprint Mobile ................................................................................................ 74 1. Spécifications fonctionnelles................................................................................................... 74
  • 7.
    1.1. Sprint Backlog................................................................................................................. 74 1.2. Prototype d’interface....................................................................................................... 75 2. Diagramme des cas d’utilisation du quatrième Sprint......................................................... 77 2.1. Classification des cas d’utilisation par acteur............................................................... 77 2.2. Diagramme de cas d’utilisation du quatrième sprint................................................... 77 3. Conception ............................................................................................................................... 79 3.1. Diagramme de classe....................................................................................................... 79 4. Implémentation........................................................................................................................ 80 5. Test............................................................................................................................................ 80 Conclusion............................................................................................................................................ 86 Chapitre 7 : Phase de clôture ............................................................................................................. 87 Introduction ..................................................................................................................................... 87 1. Environnement de développement......................................................................................... 87 1.1. Environnement matériel ................................................................................................. 87 1.2. Environnement logiciel ................................................................................................... 88 1.3. Technologies et Langages de programmation utilisés.................................................. 90 2. Style architectural..................................................................................................................... 93 2.1. Architecture du système.................................................................................................. 93 2.2. Le patron de conception MVC ....................................................................................... 95 3. Gestion de projets.................................................................................................................... 96 3.1. Planning des histoires...................................................................................................... 96 3.2. Diagramme de Gantt....................................................................................................... 98 Conclusion générale & perspective.................................................................................................... 99 Annexe................................................................................................................................................ 101 ANNEXE 1 : Etude approfondie sur les méthodes agiles et la méthode « Scrum »................ 101 ANNEXE 2 : IONIC..................................................................................................................... 102 ANNEXE 2 : MongoDB ............................................................................................................... 106 ANNEXE 3 : Node js..................................................................................................................... 108
  • 8.
    Table des figures Figure1: Principales informations du « LYNA-ICT »............................................................................ 13 Figure 2: file d'attente aux services des douanes des grands aéroports............................................ 14 Figure 3: Écran d’appel files d'attente Figure 4 : Distributeur de tickets tactile............... 15 Figure 5: Queue Mobile........................................................................................................................ 16 Figure 6 : rugby Scrum.......................................................................................................................... 20 Figure 7: processus SCRUM .................................................................................................................. 21 Figure 8: pratique de SCRUM ............................................................................................................... 22 Figure 9: Les acteurs qui représentent notre projet............................................................................ 26 Figure 10 : Équipes et rôles................................................................................................................... 28 Figure 11: Découpage du projet........................................................................................................... 29 Figure 12 : Exemple de schéma de découpage en Releases................................................................ 30 Figure 13 : Découpage le projet en des sprints.................................................................................... 31 Figure 14: Planning du déroulement du projet ................................................................................... 31 Figure 15: Diagramme de cas d'utilisation initial d'une application back office web........................ 32 Figure 16: Diagramme de cas d'utilisation initial d'une application front office mobile................... 32 Figure 17 : Diagramme de classe initial................................................................................................ 33 Figure 18 : prototype de la page d’authentification............................................................................ 36 Figure 19 : prototype de la page « créer un compte » ........................................................................ 36 Figure 20 : cas d’utilisation du premier sprint..................................................................................... 37 Figure 21 : diagramme de séquence système du cas « s'authentifier » ............................................. 39 Figure 22 : diagramme de séquence du cas d'utilisation « créer compte » ....................................... 40 Figure 23 : Diagramme de séquence système du cas « Mettre à jour compte » ............................... 41 Figure 24 : Diagramme du cas d'utilisation de « supprimer compte »............................................... 42 Figure 25 : Diagramme de classe de premier sprint............................................................................ 43 Figure 26 : Test des services web (un user) ......................................................................................... 44 Figure 27 : Page d'authentification ...................................................................................................... 45 Figure 28 : Page de créer compte......................................................................................................... 45 Figure 29 : Page de Gestion du Compte............................................................................................... 46 Figure 30 : prototype d'interface ajouter un établissement............................................................... 51 Figure 31 : prototype d'interface supprimer une agence ................................................................... 51 Figure 32 : prototype d'interface modifier un service......................................................................... 52 Figure 33 : Diagramme de cas d'utilisation globale de sprint 2.......................................................... 53 Figure 34 : diagramme du cas d'utilisation du cas gérer établissement............................................. 53 Figure 35 : Diagramme de séquence du cas ajouter établissement ................................................... 54 Figure 36 : Diagramme de séquence détaillé du cas modifier établissement.................................... 55 Figure 37 : Diagramme du cas d'utilisation du cas gérer agence........................................................ 55 Figure 38 : Diagramme de séquence détaillé du cas chercher agences.............................................. 57 Figure 39 : Diagramme de séquence détaillé du cas supprimer agence............................................ 58 Figure 40 : Diagramme du cas d'utilisation du cas gérer service ........................................................ 58 Figure 41 : Diagramme de séquence détaillé du cas affecter un service à une agence ..................... 59 Figure 42 : Diagramme de séquence du cas afficher les services d’une agence................................. 60 Figure 43 : Diagramme de classe globale de sprint 2 .......................................................................... 61 Figure 44 : Test des services web (la liste des établissements) .......................................................... 62
  • 9.
    Figure 45 :interface «créer établissement»........................................................................................ 63 Figure 46 : interface «liste établissements»........................................................................................ 63 Figure 47 : interface «Modifier établissement».................................................................................. 64 Figure 48 : interface «Supprimer établissement»............................................................................... 64 Figure 49 : interface «liste des agences par établissement» .............................................................. 65 Figure 50 : interface «liste des services par agence» .......................................................................... 66 Figure 51 : prototype d'interface «afficher statistiques » .................................................................. 68 Figure 52 : Diagramme de cas d'utilisation globale de sprint 3 .......................................................... 69 Figure 53: Diagramme de séquence système du cas « afficher statistiques » ................................... 70 Figure 54: diagramme de classe de de cas d’utilisation « Afficher statistiques ».............................. 71 Figure 55: Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques » ............... 71 Figure 56: Interface le nombre des agences par établissement ......................................................... 72 Figure 57: Interface le nombre des services par établissement ......................................................... 73 Figure 58: Interface le nombre des services par agence ..................................................................... 73 Figure 59: prototype des interfaces mobile........................................................................................ 76 Figure 60: Diagramme de cas d'utilisation du quatrième sprint......................................................... 77 Figure 61: Diagramme de séquence du cas " réserver ticket" ............................................................ 79 Figure 62: diagramme de classe de quatrième sprint ......................................................................... 79 Figure 63: interface «page d'accueil » ................................................................................................. 81 Figure 66: interface liste établissement................................................................................................ 82 Figure 64: interface liste service............................................................................................................ 82 Figure 65: interface liste agence ........................................................................................................... 82 Figure 67: interface météo ................................................................................................................... 83 Figure 68: Interface information générale de l’application ................................................................ 84 Figure 69: Technologies & Langage de programmation utilisé........................................................... 90 Figure 70: Architecture générale de l'application ............................................................................... 93 Figure 71: Architecture du service web REST ...................................................................................... 95 Figure 72: Architecture du patron MVC............................................................................................... 96 Figure 73: tableau « répartition des tâches de premier sprint » ........................................................ 96 Figure 74: tableau « tâches du deuxième sprint » .............................................................................. 97 Figure 75: tableau « tâches du troisième sprint »............................................................................... 97 Figure 76: tableau « tâches du quatrième sprint » ............................................................................. 97 Figure 77 : Diagramme de Gant............................................................................................................ 98 Figure 78: Les 3 vies de JavaScript...................................................................................................... 108 Figure 79: Le schéma classique : PHP sur le serveur, JavaScript chez le client................................. 109 Figure 80: Avec Node.js, on peut aussi utiliser du JavaScript sur le serveur.................................... 109 Figure 81: Le logo du moteur JavaScript V8 de Google..................................................................... 110
  • 10.
    Table des tableaux Tableau1: Nombre des clients par jour à municipalité Tunis............................................................. 16 Tableau 2: Nombre des clients par jour à poste Tunis ........................................................................ 16 Tableau 3: Les 12 principes de méthodes agiles.................................................................................. 19 Tableau 4: tableau de Backlog initial ................................................................................................... 30 Tableau 5: Sprint Backlog du sprint 1................................................................................................... 35 Tableau 6 : classification des cas d'utilisation par acteur ................................................................... 37 Tableau 7 : Description textuelle du cas d’utilisation « s’authentifier »............................................ 38 Tableau 8: description du cas d'utilisation « Créer compte »............................................................. 39 Tableau 9: Description textuelle du cas d'utilisation « Mettre à jour compte »................................ 41 Tableau 10 : Description textuelle du cas « supprimer compte » ...................................................... 42 Tableau 11 : Backlog du second sprint................................................................................................. 51 Tableau 12 tableau de répartition de second sprint ........................................................................... 52 Tableau 13: description du cas d'utilisation « Créer compte »........................................................... 54 Tableau 14: Description du cas d'utilisation « Gérer agence »........................................................... 56 Tableau 15: Description du cas d'utilisation « Gérer service »........................................................... 59 Tableau 16: Backlog du troisième sprint.............................................................................................. 68 Tableau 17: tableau de répartition de troisième sprint...................................................................... 69 Tableau 18 : Description textuelle du cas « afficher statistiques » .................................................... 70 Tableau 19: Backlog du quatrième sprint............................................................................................ 75 Tableau 20 : Classification des cas d'utilisation par acteur................................................................. 77 Tableau 21 : Description textuelle du cas «Réserver ticket».............................................................. 78 Tableau 22: Environnement matériel .................................................................................................. 87
  • 11.
    Introduction générale La révolutionmobile transformera la plupart des activités des entreprises au cours des dix prochaines années. Elle sera le déclencheur d'une transformation encore plus radicale vers les systèmes d'engagement. La raison clé de ce phénomène est que l'engagement mobile habilite les personnes à entreprendre l'action prochaine la plus probable dans leur contexte immédiat et au moment où ils en ont besoin. Avec la multiplication des plateformes mobiles, la question du développement multiplateforme s’est rapidement posée, afin de tenter de réduire les couts de développement. Ces technologies permettant aux utilisateurs un accès rapide et facile à l’information, c’est dans cette optique qu’intervient notre projet de fin d’études, nous allons donc concevoir et développer deux applications, une application web et une autre mobile qui doivent permettre de gérer et de contrôler la réservation des tickets. Finalement, on peut dire que notre projet est constitué : D’une part, une application mobile qui doit offrir aux bénéficiaires la possibilité de réserver un ticket sans se déplacer auprès de l’entreprise qui doit être abonnée dans la plateforme, et de les notifier à l’arrivée de leur tour. D’autre part une application web qui permet à l’utilisateur de faire le paramétrage, l’administration et les statistiques sur l’utilisation de l’application.
  • 12.
    Chapitre 1 :Cadre du projet et méthodologie L'étude préliminaire est la première phase de tout projet réussi ; Ainsi, ce chapitre va servir dans un premier temps à la présentation de l'organisme d'accueil LYNA ICT. Nous définissons dans un deuxième temps le sujet et l'objectif principal du projet. La deuxième partie sera consacrée à la définition de la méthodologie et le formalisme adoptée lors de la réalisation de ce projet. 1. Présentation de l’organisme : LYNA-ICT Lyna-ICT (Information and Communication Technologies) est une startup fondée en Juin 2015 par des Ingénieurs hautement motivés pour le domaine du TIC. Spécialisée dans les solutions de TIC, LYNA-ICT vient décorer le tissu des fournisseurs de services informatiques. Elle offre des solutions de transformation et d’accompagnement des métiers des entreprises dans tous les niveaux et les domaines. LYNA-ICT est dimensionnée comme STARTUP vue son excellence dans les solutions technologiques à effet de levier et de services axés sur la clientèle. Le portefeuille d'activités de LYNA-ICT comprend des solutions TIC qui offre aux entreprises de télécommunication et des fournisseurs de VoIP des solutions logicielles mobiles et VoIP personnalisés. LYNA-ICT propose des services autour des axes suivants : Développement spécifique Solution open source Etude et conseils Consulting Ingénierie logicielle Infogérance Outsourcing Assistance Dans ce cadre, la figure suivante donne quelques informations sur LYNA-ICT :
  • 13.
    LYNA-ICT Secteur d'activité informatique/ télécoms Taille de l'entreprise Moins de 20 employés Catégorie Société privée étrangère Année de fondation 2015 Adresse PB Techno park Elghazela 2088 Ariana - Tunisia, Ariana , Ariana, 2088 Tunisie Lien web http://lyna-ict.com/ Figure 1: Principales informations du « LYNA-ICT » 2. Etude de l’existant L'étude de l'existant est une phase importante pour bien comprendre le système actuel. Il a pour objectif d’étudier et de dégager les lacunes du système existant et de proposer les solutions adéquates et définir les objectifs à atteindre au titre de perfectionnement. Il existe deux cas lorsque l’on procède à l’étude de l’existant :  Soit le produit existe déjà, alors il faut l’améliorer.  Soit le produit n’existe pas, il faudra donc le créer. Nous allons procéder par une approche mixte associant les deux procédés. Dans la première partie, nous nous focaliserons sur l’analyse de l'existant : Critique et solutions. 2.1. Etat actuel : Les files d'attente sont un phénomène récurrent dans les sociétés développées. L'afflux de personnes peut être géré de différentes manières. En général, on fait attendre les personnes selon leur ordre d'arrivée.
  • 14.
    Lors de laphase d’observation, nous avons remarqué que, pour occuper plus rationnellement l'espace, la file d'attente peut suivre un tracé en serpentin (file d'attente aux services des douanes des grands aéroports). Figure 2: file d'attente aux services des douanes des grands aéroports Les files d'attente peuvent aussi ne pas ordonner les individus dans l'espace, mais instaurer un ordre par le biais de tickets numérotés. Ce peut être le cas dans la salle d'attente d'un service public (bureaux de poste, sécurité sociale,…). Ces solutions modulaires, adaptables à différents secteurs (Distribution, Santé, Télécommunications, Finance, Transport, Secteur public,…) permettent la gestion d’une simple file d’attente. Figure 3 : Un gestionnaire d’accueil mono service multi points d’accueil
  • 15.
    2.2. Analyse Le systèmede gestion des files d'attente est un service qui, contrôle l’ensemble du processus : la distribution des tickets avec un distributeur tactile, l’édition des numéros d’appel, leur visualisation sur écran grand format, la liste des agences les plus proches et les plus dégagées avec une application mobile cross Platform, l’état d’avancement et la synthèse du traitement et l'élaboration de statistiques. Les écrans d’appel Les distributeurs Figure 3: Écran d’appel files d'attente Figure 4 : Distributeur de tickets tactile
  • 16.
    Figure 5: QueueMobile 3. Critique de l’existant La critique du système constitue une étape utile et importante. Elle a pour but de porter un jugement objectif afin de déceler les insuffisances éventuelles rencontrées au cours de l'étude de l'existant en vue de proposer un système plus fiable que le système ancien. Pour cela, lister les établissements servant un nombre important de tickets (Municipalité, Bureau de poste, CNAM…) :  Municipalité Tunis, sidi hessine Services L'état civil légalisation Service des affaires économiques Service des affaires sociales, culturelles, de la jeunesse et des sports Nombre des clients par jour 1053 950 1033 965 Tableau 1: Nombre des clients par jour à municipalité Tunis  Poste : Tunis, Avenue Ferhat Hached - 1060 Tunis Services abonnements Service de poste rapide Payement des factures : Eau, Téléphone, Electricité... L’épargne Nombre des clients par jour 1250 950 1000 820 Tableau 2: Nombre des clients par jour à poste Tunis
  • 17.
    Une analyse plusdétaillée de la description précédente nous a conduits à dégager plusieurs anomalies concernant le passage de la réservation des tickets. Ces anomalies peuvent être résumées comme suit : - Une obligation de déplacement, - Une file longue avec perte de temps, - Un risque d’attente en vain, - Un stress inévitable. 4. Solution proposée Actuellement il n’existe aucune application qui gère notre domaine d’études. En effet ce besoin touche nos vies quotidiennes, on propose alors une solution pour éviter la perte de temps dans les salles d'attente d'un service public. Pour ce faire, on propose de réaliser un système composé d’une application web et une application mobile pour gérer et surtout pour réserver un ticket pour une agence donnée sans se déplacer. Ces applications, vont être mises à la disposition de l’administrateur et du client. La solution proposée est le développement de :  Une application Front office mobile qui offre aux bénéficiaires de services la possibilité de réserver sans se déplacer un ticket auprès d’une entreprise abonnée dans la plateforme, et de le notifier à l’arrivée de son tour.  Une application Back office web pour le paramétrage, l’administration et les statistiques sur l’utilisation de l’application. Les avantages de la solution proposée :  Améliorer les services ;  Les clients rejoignent la file d'attente avant d'arriver économisant ainsi un temps précieux. 5. Cahier des charges La solution qu’on a proposée consiste à la conception et la réalisation de : Une application back office web qui nous fournit : Les Statistiques concernant :  Les établissements
  • 18.
     Les agences Les services Le paramétrage :  La gestion des entreprises : permet de gérer les entreprises qui vont s’inscrire dans la plateforme.  La gestion des centres de service : permet de gérer les bureaux de chaque entreprise inscrite dans la plateforme.  La gestion des services : permet la gestion des services offerts au niveau des bureaux de chaque entreprise inscrite dans la plateforme. Et une application front office mobile qui permet :  La réservation de tickets pour le bénéficiaire de service. L’application doit tenir compte de l’emplacement géographique du demandeur de ticket, du ticket en cours de traitement et du dernier ticket imprimé.  La notification de tour permettant la configuration de la durée avant laquelle un client va être notifié. 6. Langage et méthodologie de conception Pour résoudre le problème et trouver des solutions pour gérer tout type de tâche, chaque personne doit suivre une démarche pour avoir un résultat efficace et bien structuré selon des méthodes adoptées. C’est pour cela qu’on doit choisir pour les meilleures solutions et les plus optimales pour avoir recours à une méthodologie puissante qui permet de gérer un cycle de vie d’un projet. Il existe plusieurs méthodes dans ce qui suit nous nous intéressons aux méthodes agiles vues leurs apports pour des projets ou les besoins évoluent. 6.1. Méthodes agiles « Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion de projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du projet. » [1] Cette la méthode s’agit de la réitération de cycles courts dans le temps en divisant le projet en de multiples mini-projets et les prioriser selon les besoins.
  • 19.
    6.1.1. Les quatrevaleurs fondamentales Agiles étaient déclarées être :  L’interaction entre acteurs plutôt que les processus et les outils.  Un produit opérationnel plutôt qu’une documentation pléthorique.  La collaboration avec le client plutôt que la négociation de contrat.  La réactivité face au changement plutôt que le suivi d'un plan 6.1.2. Les 12 principes de méthodes agiles : 1- Satisfaire le client en livrant tôt et régulièrement des logiciels utiles qui offrent une véritable valeur ajoutée 5-Bâtir le projet autour de personnes motivées en leur fournissant environnement et support et en leur faisant confiance 9-Rechercher l’excellence technique et la qualité de la conception 2-Accepter le changement même tard dans le développement 6-Communiquer par des conversations en face à face 10-Laisser l’équipe s’auto- organiser 3-Livrer fréquemment une application qui fonctionne 7-Mesurer la progression avec le logiciel qui fonctionne 11-Rechercher la simplicité 4-Collaborer quotidiennement entre clients et développeurs 8-Garder un rythme de travail durable 12- À intervalles réguliers, réfléchir aux moyens pour devenir plus efficace Tableau 3: Les 12 principes de méthodes agiles 6.1.3. Les principales méthodes agiles : Nous distinguons surtout :  SCRUM  Extreme Programming (XP)  Rapid Application Development (RAD)  Crystal clear Si nous voulons définir l’agilité en quelques mots : c’est l’intelligence organisationnelle et technologique, associée à de l’énergie de groupe dans le but d’être immédiatement efficients. Suite à l’étude de plusieurs méthodologies et de leur convenance à notre projet, nous avons opté pour l’utilisation de la méthode SCRUM.
  • 20.
    6.2. SCRUM La méthodeScrum est une méthode agile, créée en 2002, dont le nom est un terme emprunté au rugby qui signifie « la mêlée ». Elle s'appuie sur le découpage des projets en itérations encore nommées « sprints ». [1] Figure 6 : rugby Scrum SCRUM correspond plus à une démarche de travail qu’à une méthode. Son avantage principal est sa capacité à obtenir un résultat final dans un laps de temps court tout en s’appuyant sur une équipe cohérente. Cette équipe va s’atteler à atteindre un objectif progressif qui évoluera au cours de cycles successifs et itératifs appelés Sprints. La durée d’un sprint varie entre 15 et 30 jours, et à sa fin, l’équipe présentera un produit correspondant aux spécificités énoncées au début du cycle. Parmi les atouts du concept de sprint (court et rapide) est qu’il permet au propriétaire du produit de changer la priorisation des caractéristiques demandées au fur et à mesure de l’avancement du développement. La fin de chaque sprint est une occasion de voir le produit courant fonctionner, et de prendre la décision de livraison ou du lancement d’un nouveau sprint d’amélioration du produit. 6.2.1. Pourquoi Scrum ? Scrum place l’humain au centre de la méthodologie. L’avantage principal de cette méthode est qu’elle correspond parfaitement à une petite équipe qui travaille sur un grand projet, elle s’appuie sur la répartition des tâches et la collaboration entre les membres du groupe. Avec les anciennes méthodes, le client ne voyait le logiciel qu’au moment de la livraison et n’était pas impliqué au cours des différentes phases de son développement. En effet, il n’avait accès aux tests que lorsque le produit était fini ou presque.
  • 21.
    Par contre enScrum, l’implication du client a lieu tout au long du processus car il y a plusieurs livrables qu’il doit valider. Chaque livrable correspond à l’implémentation de nouvelles fonctionnalités et le client peut facilement apprécier l’avancement du produit et il a de nombreuses occasions de demander les ajustements nécessaires à la satisfaction de sa demande. Grâce à Scrum, nous avons pu réduire les temps de production et répondre au plus près aux besoins du client. Scrum vise donc essentiellement l’optimisation de la prévisibilité d’un projet tout en réduisant les risques au minimum. La figure ci-dessous illustre le processus sur lequel est basé SCRUM : Figure 7: processus SCRUM Scrum est :  Léger  Simple à comprendre  Difficile à maîtriser Durant un développement d’un projet avec la méthode Scrum il y a plusieurs étapes à suivre avec une démarche spécifique et une interaction avec plusieurs intervenants.
  • 22.
    Figure 8: pratiquede SCRUM 6.2.2. Les intervenants dans Scrum La méthode Scrum définit trois rôles pour un projet :  Le Product Owner : C’est le propriétaire du produit et le chef d’orchestre qui valide ou décline le produit délivré. L’une de sa responsabilité principale est la définition des besoins du produit à développer et la rédaction des spécifications. Il est le seul gérant du Backlog du produit.  Le Scrum Master : Il est chargé de veiller au bon déroulement et application de la méthode Scrum et au respect de ses objectifs. Il veille également à ce que les éventuels obstacles que l’équipe peut rencontrer soient effacés. Il assure la bonne progression de l’équipe ainsi que sa productivité.  Team Membres : Ce sont les membres de l’équipe qui ont à leur charge le développement et la réalisation d’un produit fiable et utilisables. Ses membres sont soit développeur, soit architectes, soit testeurs. 6.2.3. Les artéfacts dans Scrum Les principaux artéfacts qu’on peut les générer lors de l’utilisation de la méthode Scrum :  Le « Product Backlog » : (Carnet de produits) C’est un outil de collecte des fonctionnalités attendues ou exigées par le client (User Story), et qui évolue à chaque Sprint. [2]
  • 23.
     Le «Sprint Backlog » : (Carnet d'itération) Il contient la liste des tâches qui doit être accomplie pour mettre en œuvre les fonctionnalités prévues pour un Sprint particulier. Idéalement, chaque tâche dans un sprint est relativement courte et peut-être captée par un membre de l'équipe plutôt que d'être affecté. [3]  « Burndown charts » : (Graphique d’avancement). C’est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint. [2] L’axe vertical présente la quantité de travail à faire et l’axe horizontal les jours de travail. 6.2.4. Planification d’un projet par Scrum La durée de vie d’un projet en Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps.  Planification d'itération « Sprint Planning » Au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du « Product Backlog » qu'elle pense pouvoir réaliser au cours du sprint en accord avec le « Product Owner »  Mêlée quotidienne « Daily Scrum Meeting » La mêlée quotidienne (Daily Scrum) est un événement limité à 15 minutes au cours duquel l’équipe de développement synchronise ses activités et crée un plan pour les prochaines 24 heures. Pour ce faire, l’équipe inspecte le travail effectué depuis la dernière mêlée quotidienne et envisage le travail qui peut être réalisé d’ici à la prochaine. [4] Chaque membre de l'équipe répond à trois questions :  Qu'as-tu accompli depuis la dernière mêlée ?  Que vas-tu accomplir jusqu'à la prochaine mêlée ?  Est-ce que des éléments te bloquent dans ton avancement ? Et si on doit obtenir des informations de la part du client, c’est le Product Owner qui doit s’assurer de le contacter pour obtenir les réponses.  Revue d'itération « Sprint Review » La revue de l’itération est organisée à chaque fin de cycle de développement. C’est une présentation des différentes fonctionnalités développée durant le cycle. Le propriétaire du produit aura l’occasion d’évaluer le produit et de le comparer à ce qui a été spécifié lors de la séance de planification d’itération. Une fois la revue achevée, un nouveau cycle d’itération démarre et relance ainsi la boucle : planification, développement et revue. Il s’agit là d’un
  • 24.
    point de contrôlejournalier pour toute l’équipe, limité à 15 min, dans lequel ils alignent et synchronisent leur travail pour optimiser la planification des prochaines 24 heures.  Rétrospective de sprint : La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois. Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum Master s’assure que la réunion a lieu et que les participants en comprennent le but. [4] Une fois la méthodologie de conception choisie, il convient maintenant de choisir quel langage de modélisation on a adopté dans notre projet. 6.3. Langage de modélisation UML (Unified Modeling Language) Une dizaine d'années après le début de son utilisation dans le cadre de projets de développement orienté objet, UML s'est imposé comme standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant et est devenu désormais la référence en matière de modélisation objet. La modélisation objet consiste à créer une représentation informatique des éléments du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. [5] Donc, après le choix de la méthodologie, on a opté UML comme un langage de modélisation qui est utilisé dans tous les projets logiciels comporte un ensemble des diagrammes, il permet de fournir une représentation informatique d’un ensemble d’objets et de problèmes standards du monde réel. Conclusion Dans ce premier chapitre, nous avons commencé par présenter notre organisme d’accueil LYNA-ICT. Ensuite, nous avons décrit le contexte du stage, puis nous avons dressé la problématique de notre projet, le tout en fournissant les critiques et les solutions envisageables. Enfin nous avons étayé le choix de la méthodologie de travail utilisée SCRUM, et par la suite nous nous dirigerons naturellement vers la planification et architecture.
  • 25.
    Chapitre 2 :Planification & architecture Dans le chapitre précédent, nous avons évoqué le choix de la méthode Scrum. Maintenant nous passerons à la phase la plus intéressante de cette méthodologie appelée phase de « planification et architecture » ou « Sprint Zéro ». Le sprint zéro, n’est pas considéré comme un vrai sprint, puisqu’il ne donne pas de version potentiellement livrable lorsqu’il touche à sa fin : c’est plutôt un échauffement, pour les sprints réels. Il s’agit en fait d’une phase de planification et architecture qui ne se termine pas nécessairement par une livraison. C’est donc dans ce chapitre que nous allons définir notre produit finit (Service sans attente) et ses différentes fonctionnalités en partant de l’identification des besoins, nous élaborerons les rôles des utilisateurs et préparerons l’environnement de développement. Nous finirons par déterminer un plan de Release afin de produire le Product Backlog initial ainsi qu'une première planification des sprints. 1. Spécification des besoins L’analyse des besoins est une étape conduite à l’élaboration de spécifications. C’est nécessaire de définir le projet et de mettre une planification pour bien le piloter et d'atteindre les objectifs souhaités par le client avant leur démarrage. 1.1. Identification des acteurs du système « Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositifs matériels ou autres système) qui interagit directement avec le système étudié. » [5] Pour élaborer notre projet on a pu identifier les acteurs suivants :
  • 26.
    Figure 9: Lesacteurs qui représentent notre projet 1.2. Les besoins fonctionnels Les besoins fonctionnels c’est ce que l’utilisateur attend en matière de fonctionnalités. Ces besoins présentent une description abstraite des services que le système est censé fournir pour les utilisateurs et qui convient à leurs attentes et satisfaire leurs exigences. Donc notre système doit permettre de :  Le développement d’une application web : Cette application sera essentiellement utilisée par l’administrateur. Elle doit permettre de faire : o Les statistiques concernant :  Les établissements ;  Les agences ;  Les services. o Le paramétrage :  Des établissements ;  Des agences ;  Des services.  Le développement d’une application mobile : Cette application sera essentiellement utilisée par les clients, ces derniers peuvent :  Réserver des tickets ;  La notification de leur tour.
  • 27.
    1.3. Les besoinsnon fonctionnels Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour l’utilisateur, mais qui ne sont pas reliés directement au comportement du système. Ils présentent les exigences internes primordiales pour le système tel que les contraintes liées à l’environnement et à l’implémentation, et les exigences en matière de performances, d’extensibilité et de fiabilité. Les besoins non fonctionnels de notre système se décrivent comme suit :  Le temps de réponse de l'application doit être minimal ;  La portabilité du système sur n’importe quelle plateforme ;  La performance, la fiabilité et la flexibilité du système ;  L’application doit être accessible à plusieurs utilisateurs en même temps ;  L’architecture de l’application doit être capable de supporter l’implémentation de services web et mobile ;  Les interfaces de notre application doivent être claires, concises, conviviales et facile à manipuler. 2. Structure et découpage du projet : 2.1. Identification de l’équipe SCRUM L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la productivité et la flexibilité. Afin de parvenir à ces objectifs, elle doit s’auto organiser et être multi compétente. Elle doit également avoir un champ d’action suffisant pour la soutenir dans la réalisation de son travail Dans le contexte de notre projet, on trouve :
  • 28.
    Product Owner :les directeurs des départements Scrum master : M. Anass Saïd Team : Sondes JAMI & Rimeh MOUSSI Figure 10 : Équipes et rôles 2.2. Découpage des sprints La structuration d'un projet consiste à diviser le projet en différents lots d'activités afin d'avoir des sous-parties dont la complexité est plus facilement maitrisable. Voici ci-dessous la structuration de notre projet :
  • 29.
    Figure 11: Découpagedu projet 2.3. Le Backlog du produit Comme nous avons déjà mentionné le Backlog du produit est un outil qui sert à collecter les fonctions essentielles et les raffine progressivement. C’est l’ensemble des caractéristiques fonctionnelles « user story » ou techniques « technical story » qui constituent le produit souhaité. Un user story s’écrit comme suit : En tant que <rôle> Je veux < liste de tâches> Afin de < valeur ajoutée ou résultat> Pour chaque user story on identifie le rang, l’estimation, l'importance et la description. Le tableau suivant décrire le Backlog produit de notre application et évoque les User Stories : ID En tant que Je veux Pour que Importance 1 Administrateur M’authentifier J’accède à l’application en assurant sa sécurité + + + 2 Administrateur Gérer établissement Traiter les informations concernant un établissement + + + 3 Administrateur Gérer agence Traiter les informations concernant une agence + + 4 Administrateur Gérer service Traiter les informations concernant un service + + + 5 Administrateur Gérer profil Je traite mes informations + +
  • 30.
    6 Administrateur Afficherles statistiques Mettre en évidence les résultats de l’application. +++ 7 Client Utiliser l’application mobile front office Réserver un ticket et faire la notification de tour. +++ Tableau 4: tableau de Backlog initial 2.4. Planification des releases Tous les projets nécessitent des plans, pour essayer de prévoir à peu près ce que va contenir un produit ou à quelle date il sortira sur le marché. Avec la méthodologie agile Scrum, la planification de release aux mêmes objectifs puisqu’il donne à l’équipe et aux parties prenantes des informations sur le contenu des sprints constituant le release. Un release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période de temps qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs. [5] Toute l’équipe Scrum participe à la planification de la release (l’équipe complète, avec le Scrum Master et le Product Owner) car ceux qui vont exécuter les tâches de réalisation sont les mieux placés pour en connaître les problèmes et les difficultés. La planification de Sprint répond aux questions suivantes :  Qu’est-ce qui peut être terminé au cours de ce Sprint ?  Comment sera effectué le travail choisi ? Dans notre projet, on va travailler sur une seule release, il ne contient pas une succession de sprints, cette démarche a été abandonnée. Chaque feature est fortement liée à d’autres ce qui a accentué notre choix de structuration en sprints, plutôt qu’en releases. Schéma Ci-dessous décrit le concept du découpage des Releases en Sprints : Figure 12 : Exemple de schéma de découpage en Releases
  • 31.
    Figure 13 :Découpage le projet en des sprints Durant la période de stage la figure suivante conclut la planification qu’on suivra pour la gestion de notre projet : Figure 14: Planning du déroulement du projet Remarque :
  • 32.
    La date defin du sprint est fixée au début du sprint (elle est même définie avant). Elle ne change pas, même si l’équipe ne réalise pas tout ce qu’elle imaginait faire. L’évaluation de fin de sprint permettra d’inspecter ce qui a été fait et d’en tirer des conséquences pour la suite. Maintenant, nous allons présenter les différents besoins fonctionnels de notre application exprimés précédemment d'une manière informelle en utilisant le digramme de cas d'utilisation d'UML initial. [6] 2.5. Diagramme de cas d’utilisation initial Les cas d’utilisation sont une technique de description qui sert à présenter les besoins des utilisateurs par rapport au système. Figure 15: Diagramme de cas d'utilisation initial d'une application back office web Figure 16: Diagramme de cas d'utilisation initial d'une application front office mobile 2.6. Diagramme de classe initial Le diagramme de classe permet de fournir une représentation abstraite des objets du système qui vont interagir pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. [7]
  • 33.
    0..* 0..1 1..* 1..* gérer réserver appartenir à 1..1 1..* 1..1 1..1 1..* 1..* utilisateur - - - - - - - - id_utilisateur nom prenom adresse adress_mail telphone login mot_passe : int :String : String : String : String : String : String : String + + + + + + + getAdresse () setAdresseMail () getAdresseMail () setLogin () setPwd () utililisateur () toString () : String : void : String : void : void : void : String établissement - - id_etablissement libelle : int : String + + + + getLibelle () setLibelle () etablissement () toString () : String : void : void : String agence - - - id_agence libelle adresse : String : String : String + + + + + + getLibelle () getAdresse () setLibelle () setAdresse () agence () toString () : String : String : void : void : void : String ticket - - id_ticket QrCode : int : String + + ticket () toString () : void : String client - adresse_mail : String + + + + Client () toString () setMail () getMail () : void : String : void : String service - - id_service libelle : int : String + + + + + getLibelle () setLibelle () getID () service () toString () : String : void : int : void : String Figure 17 : Diagramme de classe initial Conclusion Toute au long de ce chapitre, nous avons préparé notre planification de travail pendant laquelle on a identifié l’équipe de projet ainsi qu’on a construit notre Backlog de produit en se basant sur les besoins fonctionnels et non fonctionnels. Finalement nous avons mentionné le découpage de notre release en des sprints. Dans la partie qui suit, Nous allons enchainer à présenter avec notre premier sprint « gestion des comptes»
  • 34.
    Chapitre 3 :Sprint 1 - Sprint Gestion des comptes Dans le chapitre précédent, nous avons défini ce qu'est un sprint : une succession de tâches effectuées par les parties prenantes de la méthodologue Scrum afin d'atteindre l'objectif prédéfini par l'équipe. Le chapitre en cours quant à lui traiter les "users stories" de notre sprint en les classant dans des features qui pourront s'intégrer à une release et repartis en users stories. Une question s’impose avant même d'initier le premier sprint : « Pourquoi faisons-nous ce sprint ?». La réponse devra être compréhensible, non pas au sein de l'équipe, mais surtout en dehors. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Backlog Product Comme détaillé dans le premier chapitre, le Sprint Backlog est défini au cours de la réunion de planification : il s’agit de la liste des tâches que l’équipe Scrum doit réaliser durant le Sprint dans le but de transformer un ensemble d’éléments du carnet de commandes dans une version préliminaire du produit finit répondant aux exigences prédéfinies. Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux créer mon compte et m’authentifier. 1.1 Ajouter un « user » dans le web API Sondes Jami 1.2 Ajouter les fonctionnalités de l’affectation et de l’authentification dans le contrôleur de l’application Rimeh MOUSSI
  • 35.
    client. 1.3 Tester l’ajoutet l’authentification d’un utilisateur Rimeh Sondes 2 En tant qu’un utilisateur je peux afficher mon profil. 2.1 Afficher un « user » dans le web API Sondes 2.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 2.3 Tester la récupération de profil d’utilisateur Rimeh Sondes 3 En tant qu’un utilisateur je peux supprimer mon profil. 3.1 Supprimer un « user » dans le Web API Sondes 3.2 Ajouter la méthode de suppression de mon profil dans le contrôleur de l’application client Rimeh 3.3 Tester la suppression de compte Rimeh Sondes 4 En tant que un utilisateur, je peux modifier mon profil. 4.1 Modifier un « user » dans le Web API Rimeh 4.2 Ajouter la méthode de modification de mon profil dans la partie client Sondes 4.3 Tester la modification du compte Sondes Rimeh Tableau 5: Sprint Backlog du sprint 1 1.2. Prototypes d’interface Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint pour y mettre en évidence les fonctionnalités et bien les comprendre.
  • 36.
     Prototype del’interface "s’authentifier" Figure 18 : prototype de la page d’authentification  Prototype de l’interface "créer compte" : Figure 19 : prototype de la page « créer un compte » 2. Diagramme des cas d’utilisation du premier Sprint La méthodologie basée sur le prototypage consiste à traiter des fonctionnalités. Il s’agira pour nous de la collecte de différentes « users stories » sous une seule et unique fonctionnalité.
  • 37.
    Au début dechaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. 2.1. Classification des cas d’utilisation par acteur Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur. ACTEUR CAS D’UTILISATION Utilisateur  Créer compte  Afficher compte  Mettre à jour compte  Supprimer compte  S’authentifier Tableau 6 : classification des cas d'utilisation par acteur La figure 20 illustre le diagramme de cas d’utilisation initiale du premier sprint. L’utilisateur aura l'accréditation d’accéder à la plateforme en utilisant un login et un mot de passe. Afin d’y parvenir, doit s’inscrire dans le but d’avoir un compte sur la plateforme. Figure 20 : cas d’utilisation du premier sprint
  • 38.
    2.2. Analyse descas d’utilisation Afin de mieux assimiler les cas d’utilisation, nous avons établi leurs raffinements pour livrer une description sur les différents scénarios possibles. Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile. 2.2.1. Description textuelle du cas d’utilisation « s’authentifier » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition Le login et mot de passe sont corrects Post condition L’utilisateur est authentifié Description du scénario principal 1-L’utilisateur saisi son login et son mot de passe 2-Il clique sur le bouton « se connecter » 3-Le système vérifie les informations saisies par l’utilisateur et affiche l’interface de la plateforme. Exception Un message d’erreur est affiché si le login et/ou le mot de passe sont erronés. Tableau 7 : Description textuelle du cas d’utilisation « s’authentifier » 2.2.2. Diagramme de séquence système du cas « S’authentifier »
  • 39.
    Figure 21 :diagramme de séquence système du cas « s'authentifier » 2.3. Analyse Du cas « Créer compte » 2.3.1. Description textuelle du cas d’utilisation « Créer compte » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur n’a pas de compte et a choisi l’option « créer compte » Post condition Le compte est créé Description du scénario principal 1- L’utilisateur remplit le formulaire d’inscription 2- Il clique sur le bouton « créer » 3- Le système affiche un message «compte est créé» Exception Un message d’erreur est affiché si le login existe déjà. Un message d’erreur est affiché s’il y a des données incorrectes ou/et manquantes. Tableau 8: description du cas d'utilisation « Créer compte » 2.3.2. Diagramme de séquence système du cas « Créer compte »
  • 40.
    Figure 22 :diagramme de séquence du cas d'utilisation « créer compte » 2.4. Analyse Du cas « Gérer compte » 2.4.1. Raffinement du cas d’utilisation « Gérer compte » L’utilisateur clique sur le bouton « Mon compte ». Par la suite, le système affiche le profil. Ce qui permettra à choisir l’une des deux options « modifier » où « supprimer » le compte. 2.4.1.1. Analyse du cas d’utilisation « Mettre à jour compte »  Description textuelle du cas d’utilisation «Mettre à jour Compte » Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur doit être authentifié Post condition Utilisateur modifié Description du scénario principal 1- L’utilisateur clique sur le bouton « Mon compte » 2- Le système affiche les données dans un formulaire.
  • 41.
    Tableau 9: Descriptiontextuelle du cas d'utilisation « Mettre à jour compte »  Diagramme de séquence système du cas « Mettre à jour compte » Figure 23 : Diagramme de séquence système du cas « Mettre à jour compte » 2.4.1.2. Analyse du cas d’utilisation « supprimer compte »  Description textuelle du cas d’utilisation « supprimer compte » 3- L’utilisateur modifie les champs et clique sur <<Modifier>>. 1- Le système enregistre les informations du profil. Exception Un message d’erreur est affiché si le login existe déjà. Un message d’erreur est affiché s’il y a des données incorrectes ou/et manquantes. Cas d’utilisation S’authentifier Acteur Utilisateur Précondition L’utilisateur doit être authentifié Post condition Utilisateur supprimé
  • 42.
    Tableau 10 :Description textuelle du cas « supprimer compte »  Diagramme de séquence système du cas « supprimer compte » Figure 24 : Diagramme du cas d'utilisation de « supprimer compte » 3. Conception des cas d’utilisation Dans cette section, nous allons réaliser le diagramme de classes d’objets du premier sprint. 3.1. Diagramme de classes du premier sprint : Gestion des comptes La figure 24 illustre le diagramme de classes d’entités globales du premier sprint. Le classe « utilisateur » est liée à la classe « compte » par une association du type 1, c’est-à-dire qu’un compte peut n’appartient qu’à un seul utilisateur. Description du scénario principal 1- L’utilisateur clique sur le bouton « Mon compte » 2- Le système affiche les données dans un formulaire. 3- L’utilisateur clique sur <<Supprimer>>. 4- Le système supprime le compte. Exception Pas d’exception
  • 43.
    1 0..1 possède utilisateur - - - - - - - - id_utilisateur nom prenom adresse email num_telphone login mot_de_passe : String : string :String : String : String : int : String : String + + + GetCurrentUser () createUser () DeleteUser () compte - - login password : String : String + + + GetCurrentUser () CreateUser () Deleate () Figure 25 : Diagramme de classe de premier sprint 3.2. Schéma de la base des données : Gestion du compte Il n’existe pas encore de mode de représentation comme le diagramme ER pour les bases documentaires mais on pourrait modéliser notre collection <<users>> de la façon suivante : 4. Implémentation La phase d’implémentation, plus connue sous le nom de phase de développement consistera à implémenter les "user stories" résultantes des phases précédentes. Au cours du premier sprint, nous concevrons la structure de la base de données en se basant sur les bases documentaires. Notre base du premier sprint est définie comme ci-dessous, Ce qui nous donne par exemple un document user : { "_id" : ObjectId("574aa7f15c70661c06d15fdb"), "nom" : "moussi", "prenom" : "azouz", "adresse" : "tunis", "email" : "rimeh.moussi@gmail.com", "numtelph" : "58888555", "username" : "admin", _id: String Nom : String Prénom : String … Document : user Collection : users
  • 44.
    "hash" : "$2a$10$WkCgivFIlxO3CQgMg0LayekJmh3V7Zfz.Em5yn1Cpiaj4.twq9DFi"} Dans le cadre d’une application web du type Single Page Application (SPA) peut se poser la problématique de l’authentification. Au-delà de l ‘identification HTTP, pour gérer l’authentification d’un utilisateur on se basera sur ExpressJs pour le serveur et AngularJS pour le client. Et pour assurer la sécurité de notre application nous avons utilisé de nouvelles approches, l’authentification à base sur un jeton signé envoyé au serveur à chaque demande c’est qu’on appelle le JWT [9] (JSON Web Token) et la fonction bcrypt [10] de node js pour hacher le mot de passe de l’utilisateur. 5. Test L’approche Agile considère les tests comme une phase cruciale des projets. Dans la majorité des autres méthodes, les tests ne se front qu’après la fin du développement. Pour Scrum et les méthodes agiles en général, les tests sont intégrés dans chacun des sprints jusqu’à la livraison du produit final. Donc, chaque sprint doit se terminer par l’indispensable phase de test. Ces tests sont les seuls garants d’une version de qualité car ils permettent de vérifier les résultats obtenus lors de l’étape de développement. On effectuera quelques jeux d’essai pour tester les services web grâce à l’extension Postman et on testera l’application elle-même.  Test des services web La méthode invoque un user. Figure 26 : Test des services web (un user)
  • 45.
     L’interface des’authentifier Figure 27 : Page d'authentification  L’interface de créer compte Figure 28 : Page de créer compte
  • 46.
     L’interface deGestion du compte Figure 29 : Page de Gestion du Compte Conclusion Tout à long de ce chapitre, nous avons réussi à réaliser notre premier sprint « Gestion du compte» l’analysé et pu développer. Dans le prochain chapitre, notre effort sera focalisé sur la réalisation de notre deuxième sprint « Gestion des centres des services ».
  • 47.
    Chapitre 4 :Sprint 2 - Sprint Gestion des centres des services Dans ce chapitre, nous allons présenter notre deuxième sprint. A l’issue de ce dernier nous avons donc obtenu une deuxième version de notre application. Ce chapitre correspond à la tous ce qui est mise à jour à faire sur les établissements, les agences et les services. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1.Backlog Product Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux ajouter un établissement 1.1 Ajouter un « établissement » dans le web API Rimeh 1.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Sondes 1.3 Tester l’ajout d’un établissement Rimeh Sondes 2 2.1 Afficher les « établissements » Sondes
  • 48.
    En tant qu’unutilisateur je peux afficher les établissements. dans le web API 2.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 2.3 Tester la récupération des établissements Rimeh Sondes 3 En tant qu’un utilisateur je peux supprimer un établissement. 3.1 Supprimer un « établissement » dans le Web API Sondes 3.2 Ajouter la méthode de suppression d’un établissement dans le contrôleur de l’application client Rimeh 3.3 Tester la suppression d’un établissement Rimeh Sondes 4 En tant que un utilisateur, je peux modifier un établissement. 4.1 Modifier un « établissement » dans le Web API Rimeh 4.2 Ajouter la méthode de modification d’un établissement dans la partie client Sondes 4.3 Tester la modification d’un établissement Sondes Rimeh 5 En tant que un utilisateur, je peux ajouter une agence à un 5.1 Ajouter une « agence » dans le web API Sondes 5.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Rimeh
  • 49.
    établissement déterminé. 5.3Tester l’affectation d’une agence. Rimeh Sondes 6 En tant qu’un utilisateur je peux afficher toutes les agences ou bien les agences d’un établissement. 6.1 Afficher les « agences » dans le web API Sondes 6.2 Ajouter la méthode de la récupération qui consommera le web services Rimeh 6.3 Tester la récupération des agences Sondes Rimeh 7 En tant qu’un utilisateur je peux supprimer une agence. 7.1 Supprimer une « agence » dans le Web API Sondes 7.2 Ajouter la méthode de suppression d’une agence dans le contrôleur de l’application client Rimeh 7.3 Tester la suppression d’une agence Sondes Rimeh 8 En tant que un utilisateur, je peux modifier une agence 8.1 Modifier une « agence » dans le Web API Sondes 8.2 Ajouter la méthode de modification d’une agence dans le contrôleur de l’application client Rimeh 8.3 Tester la modification d’une agence Rimeh Sondes
  • 50.
    9 En tant queun utilisateur, je peux ajouter un service à un établissement et l’affecter à des agences. 9.1 Ajouter un « service » dans le web API Sondes 9.2 Ajouter les fonctionnalités de l’affectation dans le contrôleur de l’application client. Rimeh 9.3 Tester l’ajout d’un service Sondes Rimeh 10 En tant que un utilisateur, je peux lister tous les services, les services d’un établissement ou bien d’une agence donnée. 10.1 Afficher les « services » dans le web API Sondes 10.2 Ajouter les fonctionnalités de l’affichage dans le contrôleur de l’application client. Sondes Rimeh 10.3 Tester la récupération des services. Sondes 11 En tant que un utilisateur, je peux modifier service. 11.1 Modifier le « service » dans le web API Rimeh 11.2 Ajouter les fonctionnalités de la modification dans le contrôleur de l’application client. Sondes 11.3 Tester la modification d’un service. Rimeh Sondes 12 En tant que un utilisateur, je peux supprimer un service à partir de la liste des services, d’une agence ou bien d’un établissement. 12.1 Supprimer le « service » dans le web API Sondes 12.2 Ajouter les fonctionnalités de la suppression dans le contrôleur de l’application client. Rimeh
  • 51.
    12.3 Tester lecas de la suppression service. Rimeh Sondes Tableau 11 : Backlog du second sprint 1.2. Prototypes des interfaces Pour bien assimiler ces « user stories », voici quelques prototypes des interfaces avant de commencer la phase d’analyse.  Prototype de l’interface "créer un établissement" Figure 30 : prototype d'interface ajouter un établissement  Prototype de l’interface "supprimer une agence" Figure 31 : prototype d'interface supprimer une agence
  • 52.
     Prototype del’interface "modifier un service" Figure 32 : prototype d'interface modifier un service 2. Diagramme de cas d'utilisation du second sprint Une fois nous avons défini notre Backlog su sprint, on va traiter des fonctionnalités. Alors on va collecter plusieurs « users stories » en une fonctionnalité bien déterminée. 2.1. Classification des cas d’utilisation par acteurs ACTEUR CAS D’UTILISATION Utilisateur  Créer un établissement  Créer une agence  Créer un service  Afficher la liste des établissements  Afficher la liste des agences  Afficher la liste des services  Modifier établissement  Modifier agence  Modifier service  Supprimer établissement  Supprimer agence  Supprimer service Tableau 12 tableau de répartition de second sprint 2.2. Diagramme de cas d’utilisation du deuxième sprint
  • 53.
    Figure 33 :Diagramme de cas d'utilisation globale de sprint 2 3. Analyse des cas d'utilisation 3.1. Analyse des cas d'utilisation « gérer établissement» 3.1.1. Raffinement du cas d’utilisation «gérer établissement» Figure 34 : diagramme du cas d'utilisation du cas gérer établissement 3.1.2. Description textuelle du cas « gérer établissement» Cas d’utilisation Gérer établissement Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi
  • 54.
    l’option « gestiondes établissements» Post condition Page d’accueil affichée Description du scénario principal 1-L’utilisateur choisi le lien gestion des établissements 2-Il clique sur le bouton « créer » ou « liste des établissements » 3-Le système affiche la page selon le lien choisi Exception Pas d’exception Tableau 13: description du cas d'utilisation « Créer compte » 3.1.1. Diagrammes de séquence système « gérer établissement »  Ajouter établissement Figure 35 : Diagramme de séquence du cas ajouter établissement  Modifier établissement
  • 55.
    Figure 36 :Diagramme de séquence détaillé du cas modifier établissement 3.2. Analyse des cas d'utilisation « gérer agence» 4. Raffinement du cas d’utilisation «gérer agence» Figure 37 : Diagramme du cas d'utilisation du cas gérer agence
  • 56.
    4.1.1. Description textuelledu cas « gérer agence» Cas d’utilisation Gérer agence Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « gestion des agences» Post condition Afficher la page d’accueil Description du scénario principal 1-L’utilisateur choisi le bouton gestion des agences 2-Il clique sur le lien « créer » ou « liste des agences » 3-Le système affiche la page selon le lien. Exception Pas d’exception Tableau 14: Description du cas d'utilisation « Gérer agence » 3.2.3. Diagrammes de séquence système « gérer agence »  Afficher agences
  • 57.
    Figure 38 :Diagramme de séquence détaillé du cas chercher agences  Supprimer agence
  • 58.
    Figure 39 :Diagramme de séquence détaillé du cas supprimer agence 4.2. Analyse des cas d'utilisation « gérer service» 4.2.1. Raffinement du cas d’utilisation «gérer service» Figure 40 : Diagramme du cas d'utilisation du cas gérer service
  • 59.
    4.2.2. Description textuelledu cas « gérer service» Cas d’utilisation Gérer service Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « gestion des services» Post condition Afficher la page d’accueil Description du scénario principal 1-L’utilisateur choisi le bouton gestion des services 2-Il clique sur le lien « créer », « liste des services », « ajouter un service a une agence» ou « liste des services par une agence » 3-Le système affiche la page selon le lien. Exception Pas d’exception Tableau 15: Description du cas d'utilisation « Gérer service » 4.2.3. Diagrammes de séquence système « gérer services »  Affecter un service à une agence Figure 41 : Diagramme de séquence détaillé du cas affecter un service à une agence  Afficher la liste des services d’une agence
  • 60.
    Figure 42 :Diagramme de séquence du cas afficher les services d’une agence 5. Conception de cas d'utilisation Nous nous intéressons dans cette partie aux diagrammes de classes. Par la suite, nous présenterons le Schéma de la base de données du deuxième sprint. 5.1. Diagramme de classe global de cas d’utilisation « Gérer les centres des services» Après tous le travail de spécification et de conception, nous pouvons maintenant construire le nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir des activités précédentes.
  • 61.
    1..* 1..* 1..1 1..* établissement - - id_établissement libelle : int : String + + getLibelle() setLibelle () : String : void agence - - - id_agence libelle adresse : String : String : String + + + + getLibelle () getAdresse () setLibelle () setAdresse () : String : String : void : void service - - id_service libelle : int : String + + + getLibelle () setLibelle () getID () : String : void : int Figure 43 : Diagramme de classe globale de sprint 2 5.2. Schéma de la base des données : Gestion des centres des services On pourrait modéliser notre collection <<établissement>> de la façon suivante : _id: String Libellee: String Agence :{ _id : String Libellee: String Addressee: String Service :{ _id : String Libellee: String } } …. Document : établissement Collection : établissements
  • 62.
    6. Implémentation  Schémade la base de données « Etablissement » { "_id" : ObjectId("57547e94cb215c188a69944c"), "libelleEtb" : "CNAM", "agence" : [ { "libelleAgn" : "CNAM Tunis 3", "adresse" : "17 Rue Abderrahmane El Jaziri, Tunis 1002, Tunisie", "service" : [ "Bulletin de remboursement de frais de soins", "Demande de changement de filiere", "Demande de choix de médecin de famille" ] } 7. Test  Test des services web Cette méthode invoque la liste des établissements Figure 44 : Test des services web (la liste des établissements)  Interface créer établissement
  • 63.
    Figure 45 :interface «créer établissement»  Interface liste établissements Figure 46 : interface «liste établissements»  Interface Modifier établissement
  • 64.
    Figure 47 :interface «Modifier établissement»  Interface Supprimer établissement Figure 48 : interface «Supprimer établissement»  Interface liste des agences par établissement
  • 65.
    Figure 49 :interface «liste des agences par établissement»  Interface liste des services par agence
  • 66.
    Figure 50 :interface «liste des services par agence» Conclusion A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de valeur pour le client. Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau sprint couvrant les fonctionnalités de «Statistiques».
  • 67.
    Chapitre 5 :Sprint 3 - Statistiques Dans le chapitre précédent, nous avant présentait notre deuxième sprint. A l’issue de ce sprint nous avons donc obtenu une deuxième version de notre application. Ce chapitre correspond à la tous ce qui est statistiques à faire sur l’application. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécification des besoins Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Backlog Product Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID « User Story » id Tache Affectation 1 En tant qu’un utilisateur, je peux consulter le nombre des agences par établissement. 1.1 Ajouter les fonctionnalités dans le contrôleur de l’application client. Rimeh 1.2 Tester l’affichage des graphiques Sondes En tant qu’un utilisateur je 2.1 Ajouter la méthode dans le contrôleur de l’application client. Sondes
  • 68.
    2 peux afficherle nombre des services par établissement. 2.3 Tester la méthode. Rimeh 3 En tant qu’un utilisateur je peux afficher le nombre des services par agence. 3.1 3.2 Ajouter la méthode dans le contrôleur de l’application client Rimeh 3.3 Tester les fonctionnalités. Sondes Tableau 16: Backlog du troisième sprint 1.2. Prototypes d’interfaces Pour bien assimiler ces « user stories », voici quelques prototypes d’interfaces avant de commencer la phase d’analyse.  Prototype de l’interface " afficher statistiques" Figure 51 : prototype d'interface «afficher statistiques » 2. Diagramme de cas d'utilisation du troisième sprint Au début de chaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. Classification des cas d’utilisation par acteurs.
  • 69.
    2.1. Classification descas d’utilisation par acteurs ACTEUR CAS D’UTILISATION Utilisateur  Afficher le nombre des agences par établissement  Afficher le nombre des services par établissements  Afficher le nombre des services par agence. Tableau 17: tableau de répartition de troisième sprint 2.2. Diagramme de cas d’utilisation du troisième sprint Figure 52 : Diagramme de cas d'utilisation globale de sprint 3 2.3. Analyse Du cas «« afficher statistiques» : Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile.  Description textuelle du cas « afficher statistiques » Cas d’utilisation afficher nombre des agences par établissement Acteur Utilisateur Précondition Utilisateur doit être authentifié et a choisi l’option « statistiques» Post condition Afficher les statistiques
  • 70.
    Description du scénarioprincipal 1-L’utilisateur clique sur le bouton statistiques 2-Il choisi un lien 3-Le système affiche la page des statistiques selon le lien choisi. Exception Pas d’exception Tableau 18 : Description textuelle du cas « afficher statistiques »  Diagramme de séquence système du cas « afficher statistiques » Figure 53: Diagramme de séquence système du cas « afficher statistiques » 3. Conception de cas d'utilisation « Afficher statistiques » : Nous nous intéressons dans cette partie aux diagrammes de classes et aux diagrammes séquence détaillées du troisième sprint.
  • 71.
    3.1. Diagramme declasse 1..* 1..* 1..1 1..* établissement - - id_établissement libelle : int : String + + getLibelle () setLibelle () : String : void agence - - - id_agence libelle adresse : String : String : String + + + + getLibelle () getAdresse () setLibelle () setAdresse () : String : String : void : void service - - id_service libelle : int : String + + + getLibelle () setLibelle () getID () : String : void : int Figure 54: diagramme de classe de de cas d’utilisation « Afficher statistiques » 3.2. Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques » Figure 55: Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques »
  • 72.
    4. Implémentation  Schémade la base des données : Statistiques On pourrait utiliser notre collection <<établissement>> que nous avons déjà présenté dans le sprint précédent. 5. Test  Interface le nombre des agences par établissement Figure 56: Interface le nombre des agences par établissement  Interface le nombre des services par établissement
  • 73.
    Figure 57: Interfacele nombre des services par établissement  Interface le nombre des services par agence Figure 58: Interface le nombre des services par agence Conclusion Lors de ce sprint, on a analysé, conçu et pu développer les fonctionnalités de troisième sprint qui nous permet d’étudier les statistiques des établissements, des agences et des services. Dans le prochain sprint, on fera le sprint mobile.
  • 74.
    Chapitre 6 :Sprint 4 - Sprint Mobile Dans le chapitre précédent, nous avant présentait notre troisième sprint. Ce chapitre correspond à la toux ce qui est mise à jour à faire sur l’application mobile. Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception détaillée et enfin la réalisation. Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de ce sprint. 1. Spécifications fonctionnelles Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus précisément, l’analyse, la conception, le développement et on achève les tests. 1.1. Sprint Backlog Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce sprint : ID User story User Story ID Tâche Tâche Affectation 1 En tant que client, je veux consulter la liste des établissements. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter établissement » Rimeh MOUSSI 1.2 Développer le cas «Consulter établissement» Rimeh MOUSSI 1.3 Tester le cas «Consulter établissements» Sondes JAMI
  • 75.
    2 En tantque client, je veux consulter la liste des services d’un établissement donné. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter service » Sondes JAMI 1.2 Développer le cas «Consulter service» Sondes JAMI 1.3 Tester le cas «Consulter service» Rimeh MOUSSI 3 En tant que client, je veux consulter la liste des agences ayant un service donné et ma position dans maps. 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas « Consulter agence dans le maps » Rimeh MOUSSI 1.2 Développer le cas «Consulter agence» Sondes JAMI 1.3 Tester le cas «Consulter agence» Rimeh MOUSSI 4 En tant que client, je veux réserver un ticket et faire la notification de tour 1.1 Réaliser les diagrammes de cas d’utilisation, de séquence système, de classe, de séquence détaillée du cas «Réservation un ticket » Sondes JAMI 1.2 Développer le cas «Réserver ticket» Rimeh MOUSSI 1.3 Tester le cas «Réserver ticket» Sondes JAMI Tableau 19: Backlog du quatrième sprint 1.2. Prototype d’interface Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint pour y mettre en évidence les fonctionnalités et bien les comprendre.
  • 76.
    Affiche la listedes établissements, Puis, le client sélectionne un parmi cette liste Affiche la liste des services d’un établissement sélectionné Affiche la liste des agences les plus proches dans maps Affiche le ticket et les informations avec le QR Code. Après la réservation, remplir le formulaire de la notification de tour. Figure 59: prototype des interfaces mobile
  • 77.
    2. Diagramme descas d’utilisation du quatrième Sprint Au début de chaque itération, on schématise la spécification fonctionnelle par un diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. 2.1. Classification des cas d’utilisation par acteur Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur. Acteur Cas d’utilisation Client Réserver ticket Tableau 20 : Classification des cas d'utilisation par acteur 2.2. Diagramme de cas d’utilisation du quatrième sprint Figure 60: Diagramme de cas d'utilisation du quatrième sprint 2.2.1. Analyse Du cas « Réserver ticket» : Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et facile.  Description textuelle du cas «Réserver ticket»
  • 78.
    Cas d’utilisation Réserverticket Acteur Client Pré condition Etablissement inscrit dans la plateforme Post condition Ticket réservé Description 1. Le client choisi l’établissement 2. Le client choisi un service d’un établissement donné 3. Le client choisi une agence qui existe dans maps. 4. Le client réserve un ticket 5. Le client faire la notification de tour. Exception Problème de connexion réseau Tableau 21 : Description textuelle du cas «Réserver ticket»
  • 79.
     Diagramme deséquence système du cas « Réserver ticket » Figure 61: Diagramme de séquence du cas " réserver ticket" 3. Conception 3.1. Diagramme de classe réserver 1..1 1..1 ticket - - id_ticket QrCode : int : String + + ticket () toString () : void : String client - emailClient : String + + + + getEmail () setEmail () client () toString () : String : void : void : String Figure 62: diagramme de classe de quatrième sprint
  • 80.
    4. Implémentation Notre baseest définie comme ci-dessous, Ce qui nous donne par exemple un document agence : { "_id" : ObjectId("574ad27c3ea0f78f78f2d556"), "libelleAgn" : "Siège social CNSS", "adresse" : "49 Avenue Taieb M'Hiri, Tunis 1002, Tunisie", "IDetablissement" : "5743f48156fa1b72d9dc3d4d", "ticket_en_cours" : 2, "der_ticket_reserv" : 14, "emailClient " : "jamisondes1994@gmail.com" } 5. Test  Interface test de service web  Interface page d’accueil (Android & Ios) :
  • 81.
    Figure 63: interface«page d'accueil »
  • 82.
     Interface listeétablissement Figure 66: interface liste établissement  Interface liste services Figure 64: interface liste service  Interface liste des agences dans maps Figure 58 : interface liste agence Figure 65: interface liste agence
  • 83.
    Les options dansnotre application  Interface météo Figure 67: interface météo
  • 84.
     Interface informationgénérale de l’application Figure 68: Interface information générale de l’application
  • 85.
     Interface lesdétails concernant chaque agence, la réservation
  • 86.
    Conclusion Dans ce chapitrenous avons présenté et détaillé les différentes phases de sprint « Mobile » tels que la spécification fonctionnelles, les diagrammes, implémentation et test. A ce stade nous avons réussi à concevoir et développer un produit complet et fonctionnel.
  • 87.
    Chapitre 7 :Phase de clôture Introduction Dans ce dernier chapitre, nous allons présenter la phase ultime de notre cycle de développement avec Scrum qui s’intitule : phase de clôture plus connue sous le nom de sprint de stabilisation. Il s’agira de définir les différents outils technologiques et l’environnement de développement auxquels nous avons eu recours. Ensuite, nous présenterons une schématisation des différentes tâches effectuées au cours de notre stage. 1. Environnement de développement 1.1. Environnement matériel Voici les caractéristiques techniques des machines que nous avons utilisées : Ordinateur Propriétaire Sondes JAMI Rimeh MOUSSI Processeur Core i3 Core i3 Ram 6 Go 4 Go Disque Dur 500 Go 500 Go Système d’exploitation Windows 7 Professional 64-bit Windows 7 Professional 64-bit Tableau 22: Environnement matériel
  • 88.
    1.2. Environnement logiciel Rédactiondu rapport : Word : est un logiciel de traitement de texte qui permet de taper des textes, ajouter des images, des graphiques, insérer des tableaux avec des multiples choix de polices et de conception Base des données : MongoDB : est un système de base de données dans la mouvance No SQL. Il est orienté documents. Son nom vient de Humongous qui veut dire énorme ou immense. L'objectif est donc de pouvoir gérer de grandes quantités de données. Robomongo : est un exemple notable d'application cliente de gestion de ce système de gestion de base de données NO SQL, et un client graphique disponible pour toutes les plateformes. Conception : PowerAMC : est un logiciel de modélisation (modeleur) de Sybase. En 2006, il inclut les modélisations de bases de données (MPD, MCD), UML, modélisation de traitements Merise (MCC, MOT, MCT) et modélisation de processus métier. Test : Postman : C’est un outil puissant de test des services web, devenu un outil incontournable pour de nombreux développeurs.
  • 89.
    Google chrome :C’est un navigateur internet développé par Google. Ce navigateur est sur le marché depuis 2008 et fonctionne sur différentes plateformes (PC, tablettes, smartphone ...) et sous différents OS (Windows, mac, Linux, Android). Présentation : PowerPoint est un logiciel de Présentation Assistée par Ordinateur. Il permet de préparer des présentations contenant du texte, des images, des effets visuels, du son. Le mode Normal, que vous utilisez pour écrire et concevoir vos présentations, est le principal mode de modification. Implémentation : Sublime Text3 : est un éditeur de texte générique codé en C++ et Python, disponible sur Windows, Mac et Linux. Le logiciel a été conçu tout d'abord comme une extension pour Vim (est un éditeur de texte), riche en fonctionnalités Interpréteurs de commandes : Node.js est une plateforme basée sur le moteur JavaScript V8, créée par Google pour Chrome qui s'exécute indifféremment côté client ou côté serveur. git : est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. Prototype :
  • 90.
    Pencil : estun logiciel de création de maquettes typographiques libre et gratuit développé par Evolution Solutions (Evolus). Il est utilisé afin de créer des diagrammes et des maquettes d'interface graphique de logiciels. Gestion du projet : Gantt Project est un logiciel libre de gestion de projet écrit en Java, ce qui permet de l'utiliser sur de nombreux OS tel que Windows, Linux, MacOS. Ce projet a été lancé par un étudiant de l'université de Marne La Vallée en janvier 2003 et est maintenant proposé sous licence libre (GNU GPL). Microsoft Project (ou MS Project ou MSP) est un logiciel de gestion de projets édité par Microsoft. Il permet aux chefs de projet et aux planificateurs de planifier et piloter les projets, de gérer les ressources et le budget, ainsi que d'analyser et communiquer les données des projets. 1.3. Technologies et Langages de programmation utilisés MEAN JS Figure 69: Technologies & Langage de programmation utilisé
  • 91.
    Express est unFramework MVC basé sur node.js, C'est de fait le Framework standard pour le développement de serveur en Node.js JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs. Ce langage, créé en 1995 par Brendan Eich AngularJS est une plateforme de développement pour créer des applications en utilisant les standards du web modernes. Angular comprend une foule de caractéristiques essentielles telles que les gestures mobiles, les animations, le filtrage, le routage, la liaison de données, la sécurité, l'internationalisation, et de belles composants d'interface utilisateur. Il est extrêmement modulaire, léger et facile à apprendre. Bootsrap : Il s’agit d’un éventail d’outils dédiés à la création de sites et applications web. Il se compose à la fois de HTML, ainsi que des modèles de conception à base de CSS pour la typographie, des formes, des boutons, la navigation et d'autres composants de l'interface et des extensions optionnelles JavaScript.
  • 92.
    HTML5 désigne ladernière version du langage de développement web HTML. Il est généralement appris en parallèle du CSS et plus précisément dans notre cas avec le CSS3, ce dernier permet en effet d’animer des éléments HTML tout en effectuant des rotations, des transitions ou des changements. JSON (JavaScript Object Notation) est un format léger d'échange de données. Il est facile à lire ou à écrire pour des humains. Il est aisément analysable ou générale par des machines. Il est basé sur un sous-ensemble du langage de programmation JavaScript (JavaScript Programming Language, Standard ECMA-262 3rd Edition - Décembre 1999). Ionic est un puissant SDK HTML5 permettant de développer des applications mobiles en langage WEB (HTML / CSS / JS). Le but primaire de ce tout nouveau SDK est de permettre un développement plus court et efficace sur différentes plateformes mobiles tout en gardant la même interaction et design qu'une application native.
  • 93.
    2. Style architectural 2.1.Architecture du système Figure 70: Architecture générale de l'application Administrateur Service Web MongoDB Client JSON Application web Back office a Application mobile Front office
  • 94.
    Le processus del’application qui admet une architecture orientée service se fait comme suit : L'échange de données entre la partie back office (Application web sous le patron MVC) et le web API se fait grâce au protocole moderne http, même chose pour la partie front office (Application mobile hybride), les données sont sous format JSON. Les systèmes qui suivent les principes de l'architecture REST sont souvent appelés RESTful. Les web services de type REST consistent à des méthodes de type GET, POST, PUT ou bien DELTE.  Les web services sont des composants distribués qui offrent des fonctionnalités aux applications au travers du réseau en utilisant des standards ouverts. Ils peuvent donc être utilisés par des applications écrites dans différents langages et exécutées dans différentes plateformes sur différents systèmes. Les services web utilisent une architecture distribuée composée de plusieurs sites ou systèmes différents qui communiquent sur le réseau. Ils mettent en œuvre un ensemble de normes et standards ouverts qui permettent aux développeurs d’implémenter des applications distribuées internes ou externes en utilisant des outils différents. Un service web permet généralement de proposer une ou plusieurs fonctionnalités métiers qui seront invoqué par un ou plusieurs consommateurs. Il existe deux grandes familles de service web : • Les services web de type SOAP (Simple Object Access Protocol). • Les services web de type REST (Representational State Transfer).  L’architecture REST n’est pas un protocole en soi, ni une technologie, mais une "philosophie" de l’utilisation du Web. Le protocole utilisé ici est simplement HTTP avec ses méthodes (GET, POST et les autres...). Cette philosophie estime qu’il n’est, dans bien des cas, pas nécessaires de faire appel aux couches d’abstraction proposées par SOAP et que les méthodes de HTTP, combinées avec de bonnes URIs (Uniform Resource Identifier), suffisent amplement dans la majorité des cas. Il est facile de voir que la méthode la plus simple est REST, qui a l’avantage énorme de ne pas ajouter une couche d’abstraction des données qui n’en ont pas forcément besoin. Cette méthode été retenu pour la réalisation de notre application.
  • 95.
    Enfin, l’utilisateur aurala possibilité d’utiliser l'application à travers un navigateur. Figure 71: Architecture du service web REST 2.2. Le patron de conception MVC Le système a été développé sous le patron de conception MVC (Model View Controller)  Modèle : Il s’agit des données et de l’état de votre application web. En général, ces données sont représentées par un ensemble de classes qui permettent d’accéder à une base de données, mais les données pourraient tout aussi bien être stockées dans des fichiers ou utiliser des services.  Vue : C’est l’interface qui affichera les données, Il s’agira globalement de code HTML et de CSS. Le but de la vue est de présenter les données issues du modèle mais sans les modifier, sans en interpréter le contenu.  Contrôleur : il fait le lien entre la vue et le modèle. Le contrôleur gère les interactions avec l’utilisateur et détermine quels traitements doivent être effectués pour une action données.
  • 96.
    Figure 72: Architecturedu patron MVC 3. Gestion de projets 3.1. Planning des histoires Les figures suivantes présentent les tableaux de la répartition des tâches pour les membres de l’équipe de développement pour les quatre sprints : Figure 73: tableau « répartition des tâches de premier sprint »
  • 97.
    Figure 74: tableau« tâches du deuxième sprint » Figure 75: tableau « tâches du troisième sprint » Figure 76: tableau « tâches du quatrième sprint »
  • 98.
    3.2. Diagramme deGantt « Le diagramme de Gantt, couramment utilisé en gestion de projet, est l'un des outils les plus efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches) qui constituent un projet » [8] Figure 77 : Diagramme de Gant Conclusion Au cours de ce dernier chapitre, nous avons essayé de présenter les différents travaux qui contribuent du bon déroulement de notre projet. Ce chapitre engendre la fin de cycle de développement Scrum, en effet on obtient le fruit du travail exécutable avec la présentation de technologies adoptées et diagramme de Gantt.
  • 99.
    Conclusion générale &perspective Ce projet représente le fruit du travail effectué au sein de LYNA-ICT (Information and Communication Technologies) dans le cadre du projet de fin d’études pour l’obtention du Licence Appliqué en développement de système d’information à l’ISET Rades (Institut supérieure des études technologique). Ce stage nous a permis d’apprendre comment définir des objectifs et mettre en place les moyens pour les atteindre. Bien entendu, cela n’aurait jamais été possible sans l’aide inestimable de nos encadreurs. Le projet consistait à concevoir et réaliser une application mobile pour la réservation des tickets auprès des guichets de service. Ce projet nous a permis de mettre en application les connaissances théoriques que nous avons pu acquérir au cours des trois années d’études à l’ISET. Ce fut également une opportunité de nous confronter aux difficultés du monde du développement et de la gestion d’un projet. En introduction du présent rapport, nous avons présenté le contexte général de notre stage, qui s’est déroulé au sein de la société. Nous avons poursuivi par l’étude de l’existant grâce à laquelle nous avons déterminé les exigences et besoin du projet. Nous avons employé les méthodes Agiles dans la gestion et suivi du projet et nous avons opté pour la méthode SCRUM qui se base sur le principe des sprints, dans le cas de notre projet on a eu recours à 4 sprints. Les sprints se répartissent comme suit : on a commencé par les users Stories et leurs spécificités, on a enchaîné par la schématisation en diagrammes des cas d’utilisation liées aux fonctionnalités, puis on a décrit le déroulement des scénarios ; nous avons terminé par la conception et l’implémentation des bouclée par des tests. Cet application sera complète en matière de fonctionnalités et donnera pleine réponse à leurs besoins avec plus de liberté, de transparence et d’efficacité. Durant la réalisation de cette application, nous avons pu nous imprégner de l’architecture trois tiers et apprendre à manipuler l’éditeur Sublime et à développer avec plusieurs technologie comme (Node JS, AngularJS, Ionic, …) et à conçu avec base de donnée NO SQL MongoDB qui nous a posé quelques difficultés tout au début. La richesse de ce sujet était une opportunité pour profiter tant dans l'acquisition des connaissances que sur l’aspect travaille en équipe. Et surtout ce projet lié au stage, était une découverte du monde professionnel, ses réalités, notamment des aspects adaptation et difficultés. Perspectives :
  • 100.
     Le clientpeut annuler le ticket après la réservation.  Le client peut faire la notification de tours avec e-mail.  L’utilisateur de back office peut afficher les statistiques des tickets.
  • 101.
    Annexe ANNEXE 1 :Etude approfondie sur les méthodes agiles et la méthode « Scrum » Au cours de ce rapport nous avons utilisé le mot Scrum une centaine de fois. Nous avons également présenté la théorie, la définition, les méthodologies Scrum… Dans la réalité de notre projet, Scrum était en fait une expérience unique. Nous avons organisé des réunions quotidiennes pour faire le suivi de notre Backlog, sous la baguette du Maitre du Scrum à savoir : Monsieur Anass Saïd. Il a vraiment orchestré le travail de toute l'équipe comme un chef d'orchestre : répartition des tâches, suivi des actions, priorisation des actions. La présence des différents « Product Owner », à savoir les directeurs de département, a été d’une aide précieuse pour avancer efficacement dans nos travaux et aller droit au but. Les figures ci-dessous où l’on peut voir le « Backlog produit » et le suivit des actions selon leurs statuts : A faire, en cours, terminé.
  • 102.
    ANNEXE 2 :IONIC Ionic Framework est un mélange d’outils et de technos pour développer des applications mobiles hybrides rapidement et facilement. Il s’appuie sur AngularJS pour la partie application web du Framework et sur Cordova pour la partie construction des applications natives. Ce Framework open source permet de développer une application déployable sur plusieurs environnements tels qu’un site web ou une application mobile pour des systèmes tels qu’Android ou iOS ou Windows Phone… Historique Ionic va vous permettre de développer une application web qui aura l'air d'une application native. Elle en partagera également certaines capacités comme l'accès aux éléments systèmes. C'est ce qu'on appelle une application hybride. La majeure partie de son code est en technologie du web (JavaScript/html/css) et pour tout le reste, il y a des plugins qui font l'interface entre le smartphone et votre application. Ionic 1 est basé sur Cordova et Angular 1. Il fournit des briques qui vous permettront de créer une application proche du natif. Les équipes de Drifty ont mis tout en œuvre pour faciliter la vie du développeur mobile hybride en lui fournissant un environnement simple et un Framework pratique. Leur Framework a tellement fait sensation qu'ils ont levé un million de dollars en 2014, alors que la startup n'avait que 2 ans d’existence. Cela a permis à leurs équipes de repenser leur création, en apprenant de leurs erreurs, des demandes de la communauté et en mettant à jour les briques sur lesquelles repose le Framework. Ionic 2 est notamment passé de Angular1 à Angular2 et utilise désormais web pack en lieu et place de bower et gulp. Ionic 2 permet également d'utiliser les évolutions de JavaScript avec les syntaxes d'ES6/ES2015 et d'ES7. Une présentation a été faite à l'Angular
  • 103.
    Connect qui afait bonne impression tant les performances ont été améliorées, surtout concernant les animations. La version 2 est encore en version alpha, nous nous concentrerons dans la suite de cette présentation à Ionic 1 qui est la version stable actuellement. Installer Ionic Pour commencer, Ionic Framework s’appuie sur la plateforme Node JS et plus précisément NPM (Node Package Manager) pour installer les nouveaux modules développés par la communauté et gérer les dépendances entre les modules, donc il vous faudra l’installer (si vous ne l’avez pas déjà fait). Ensuite, pour générer une application mobile hybride, il vous faut le SDK Java et le SDK Android (si on veut faire une application Android ou tout autre SDK pour la plateforme visée), qui serviront à la compilation et à la construction de l’application. Commençons par installer notre environnement de travail.  Installer node.js (https://nodejs.org/en/ ) ;  Et les outils en ligne de commande (CLI) pour Cordova et Ionic : $ npm install -g ionic cordova Créer un projet Ionic Pour commencer une application avec Ionic, il suffit d'utiliser la CLI. Essayons la commande suivante : $ ionic templates Pour avoir un bon aperçu de ce que propose le Framework, nous allons partir d'un Template assez complet : $ ionic start myApp tabs $ ionic start myApp blank $ ionic start myApp tabs $ ionic start myApp sidemenu À ce stade, nous avons un répertoire contenant le patron minimum de notre future application.
  • 104.
    Ajouter des pluginsavec Ionic $ ionic plugin cordova-plugin-console 1.0.1 "Console" cordova-plugin-device 1.0.1 "Device" cordova-plugin-splashscreen 2.1.0 "Splashscreen" cordova-plugin-statusbar 1.0.1 "StatusBar" cordova-plugin-whitelist 1.0.0 "Whitelist" ionic-plugin-keyboard 1.0.8 "Keyboard" Déployer une application Ionic Ici et comme sur les smartphones, il y a deux mondes : Android et Ios. Pour chacun de ces deux mondes, il faut installer les outils de développement spécifiques à chacun avant de pouvoir émuler ou compiler l'application.
  • 105.
    Pour installer lesoutils Ios, il faut être dans la sphère Apple et donc posséder une machine avec OSX et XCode. Pour installer les outils Android, c'est un peu plus ouvert car basé sur java, et nous avons donc la possibilité d'utiliser au choix, Windows, OSX ou une distribution Linux. Une fois l'environnement prêt, nous pouvons générer les fichiers nécessaires à la plateforme désirée : $ ionic platform add android $ ionic platform add ios Vous pouvez alors packager votre application pour la tester soit sur un émulateur, soit sur un périphérique réel. De manière générale il est toujours préférable de tester sur de vrais smartphones et tablettes, notamment à cause de la lenteur et l'imperfection des émulateurs fournis. Pour packager: $ ionic build android $ ionic build ios Pour émuler : $ ionic emulate android $ ionic emulate ios Pour déployer sur un périphérique de test, cela diffère selon la plateforme : Pour Android : $ ionic run android Pour Ios, vous avez deux solutions :  Ouvrir le fichier XCode généré dans le dossier Platform/Ios avec XCode lui- même, puis sélectionner le périphérique souhaité via l'interface et cliquer sur le bouton Play.  Installer le packet npm ios-deploy en global afin de pouvoir lancer directement l'application sur le périphérique via la commande : ionic run ios --device
  • 106.
    ANNEXE 2 :MongoDB MongoDB (venant du terme « Humongous » = « énorme ») est la première base de données, permettant aux sociétés d'être plus rapides et évolutives. Les entreprises de toutes tailles utilisent MongoDB pour créer de nouveaux types d'applications, améliorer la façon de travailler avec ses clients, accélérer les temps de mise sur le marché et faire baisser les coûts. Elle est une base de données rapide, permettant aux référentiels d'évoluer aussi rapidement que les applications, tout en procurant aux concepteurs les fonctionnalités attendues des bases de données usuelles, notamment des indexes secondaires, un langage complet de requêtes et une stricte cohérence et stabilité. MongoDB est conçue pour l'évolution, les performances et la haute disponibilité, passant de l'installation sur de simples serveurs, à des architectures complexes déployées sur plusieurs sites. En tirant profit du calcul en mémoire, MongoDB permet de lire et d'écrire très rapidement. La réplication intégrée à MongoDB et le basculement automatique, permettent une souplesse opérationnelle et une fiabilité de classe « entreprise ». Les souscriptions MongoDB permettent de profiter d’un support professionnel, d’une licence commerciale, ainsi que des fonctionnalités de MongoDB Enterprise. Les souscriptions aident nos clients à construire non seulement une infrastructure informatique sûre, évolutive et stable, mais également à atteindre des objectifs commerciaux plus importants, notamment en termes de réduction des coûts, d'accélération du temps de mise sur le marché, et d'atténuation des risques. MongoDB Enterprise permet de profiter de fonctionnalités de sécurité, de surveillance, du support SNMP, de certifications et bien plus encore. MongoDB Management Service (MMS) permet de profiter d’outils de surveillance et de sauvegarde, proposés soit dans Cloud soit dans votre Datacenter avec MongoDB Enterprise. Pour le moment, lorsque nous faisons une requête, nous récupérer les documents dans leur ensemble. Si les documents sont volumineux, il peut être intéressant de ne récupérer que les valeurs qui nous intéressent. MongoDB limite la taille des documents à 16MB, ce qui est une taille important pour un document JSON. Si vos documents sont plus importants, vous pouvez les découper en plusieurs collections (et vous l'aurez probablement fait avant d'approcher cette limite).
  • 107.
    Comme dans unebase relationnelle, on utilise les _id pour faire les liens entre plusieurs collections. La différence est qu'il n'y a pas de jointure. Il vous faudra alors faire 2 requêtes. Installer MongoDB pour Windows: http://www.mongodb.org/downloads Mettre en phase l’environnement MongoDB : MongoDB nécessite un répertoire de données pour stocker toutes les données. Le chemin du répertoire de données par défaut de MongoDB est data db. Créer ce dossier en utilisant les commandes suivantes à partir d’une invite de commande : md datadb Démarrez MongoDB Pour démarrer MongoDB, exécutez mongod.exe . Par exemple, à partir de l’invite de commande : C:mongodbbinmongod.exe Connectez-vous à MongoDB Pour se connecter à MongoDB à travers le mongo.exe Shell, ouvrir une autre invite de commande : C:mongodbbinmongo.exe
  • 108.
    ANNEXE 3 :Node js  Présentation Node.js Figure 78: Les 3 vies de JavaScript JQuery n'est pas mort et ça ne veut pas dire qu'il faut cesser de l'utiliser (par contre DHTML et Netscape sont bel et bien morts eux). Les nouveaux outils JavaScript comme Node.js font des choses très différentes de jQuery et consorts. Les deux peuvent tout à fait se compléter. Node.js nous permet d'utiliser le langage JavaScript sur le serveur... Il nous permet donc de faire du JavaScript en dehors du navigateur ! Node.js bénéficie de la puissance de JavaScript pour proposer une toute nouvelle façon de développer des sites web dynamiques. Node.js : le JavaScript côté serveur JavaScript avait toujours été utilisé du côté du client, c'est-à-dire du côté du visiteur qui navigue sur notre site. Le navigateur web du visiteur (Firefox, Chrome, IE...) exécute le code JavaScript et effectue des actions sur la page web.
  • 109.
    Figure 79: Leschéma classique : PHP sur le serveur, JavaScript chez le client Node.js offre un environnement côté serveur qui nous permet aussi d'utiliser le langage JavaScript pour générer des pages web. En gros, il vient en remplacement de langages serveur comme PHP, Java EE, etc. Figure 80: Avec Node.js, on peut aussi utiliser du JavaScript sur le serveur  Node.js est rapide Si Node.js est rapide, cela tient principalement à deux choses : le moteur V8 et son fonctionnement non bloquant. Node.js utilise le moteur d'exécution ultrarapide V8 de Google Chrome. Ce moteur V8 avait fait beaucoup parler de lui à la sortie de Google Chrome, car c'est un outil open source créé par Google qui analyse et exécute du code JavaScript très rapidement.
  • 110.
    Figure 81: Lelogo du moteur JavaScript V8 de Google  Installation Pour installer Node.js sous Windows, il suffit de télécharger l'installeur qui est proposé sur le site de Node.js(https://nodejs.org/en/ ).  Node.js : c'est l'interpréteur de commandes de Node.js (dont nous parlerons à la fin de ce chapitre). Nous l'utiliserons assez peu en pratique. Il sert à tester des commandes JavaScript.  Node.js command prompt : c'est une console de Windows configurée pour reconnaître Node.js. C'est par là que vous passerez pour lancer vos programmes Node.js, c'est donc ce que nous utiliserons le plus souvent. NPM (nœud gestionnaire de paquet) : Depuis les versions les plus récentes de Node.js, il faut savoir que NPM est installé en même temps automatiquement. NPM est le gestionnaire de paquets de Node.js (c'est un peu l'équivalent de apt, mais pour les extensions Node.js). NPM est vraiment un outil formidable qui nous permet d'étendre les possibilités de Node.js à l'infini, nous le découvrirons un peu plus tard. Bower : Bower est un système de gestion des paquets pour la programmation côté client sur le World Wide Web, il nous permet d’installer des bibliothèques. Cela dépend de Node.js et NPM. Il fonctionne avec git et dépôts GitHub. Il a été initialement développé sur Twitter par Jacob Thornton, Co-créateur du cadre Bootsrap avec succès, qui a contribué à Bower gagné rapidement adoption. Installer Bower Ouvrez une console Windows ou l’invite de commande et exécutez la commande suivante : npm install -g bower
  • 111.
    Bibliographie [4] Ken Schwaber.Jeff Stherland, le guide Scrum, edition creative commons, 2013. [5] F. V. Pascal Roques, UML2 en action de l'analyse des besoins à la conception, edition Eyrolles, 2007. [6] Claude Aubry, le guide pratique de la méthode agile la plus populaire. Neto graphie [1] http://ineumann.developpez.com/tutoriels/alm/agile_scrum/ [2] http://geekandmore.fr/tag/scrum/ [3] https://confluence.atlassian.com/agile/glossary/sprint-backlog [7] http://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-classes [8] http://www.gantt.com/fr/index.htm [9] https://amethyste16.wordpress.com/2014/08/30/les-jetons-jwt-ce-quun-developpeur- doit-connaitre/ [10] https://fr.wikipedia.org/wiki/Bcrypt Documentation Ionic http://ionicframework.com/ http://forum.ionicframework.com/ Documentation Apache Cordova https://cordova.apache.org/ http://ngcordova.com/ Documentation AngularJS https://angularjs.org/ https://openclassrooms.com/courses/developpez Documentation AngularJS https://angularjs.org/ https://openclassrooms.com/courses/developpez Recherches de solutions https://github.com/ http://stackoverflow.com/ Documentation MongoDB https://docs.mongodb.com/ Développement avec MEAN http://mean.io/#!/ https://blog.udemy.com/node-js-tutorial/#7_1 Documentation Bootsrap http://getbootstrap.com/