Systéme Ticket Attente

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
--------------------------------------------------
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
1
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
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.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.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 Service des affaires sociales,
affaires culturelles, de la jeunesse
économiques et des sports
Nombre des 1053 950 1033 965
clients par jour
Tableau 1: Nombre des clients par jour à municipalité Tunis
 Poste : Tunis, Avenue Ferhat Hached - 1060 Tunis
Services abonnements Service de poste Payement des factures : L’épargne

rapide Eau, Téléphone,
Electricité...
Nombre 1250 950 1000 820
des clients
par jour
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 5-Bâtir le projet autour de 9-Rechercher l’excellence

livrant tôt et régulièrement personnes motivées en leur technique et la qualité de la
des logiciels utiles qui fournissant environnement et conception
offrent une véritable valeur support et en leur faisant
ajoutée confiance
2-Accepter le changement 6-Communiquer par des 10-Laisser l’équipe s’auto-
même tard dans le conversations en face à face organiser
développement
3-Livrer fréquemment une 7-Mesurer la progression 11-Rechercher la simplicité
application qui fonctionne avec le logiciel qui
fonctionne
4-Collaborer 8-Garder un rythme de 12- À intervalles réguliers,
quotidiennement entre travail durable réfléchir aux moyens pour
clients et développeurs 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 Scrum master : M. Anass Saïd
départements
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 Mettre en évidence les résultats de +++
statistiques l’application.
7 Client Utiliser l’application Réserver un ticket et faire la notification +++
mobile front office 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]
utilisateur
- id_utilisateur : int client
- nom : String
- adresse_mail : String
- prenom : String
- adresse : String + Client () : void
1..*
- adress_mail : String + toString () : String
- telphone : String + setMail () : void
- login : String établissement + getMail () : String
- mot_passe : String
- id_etablissement : int
+ getAdresse () : String gérer - libelle : String
+ setAdresseMail () : void 1..1
+ getLibelle () : String
+ getAdresseMail () : String
+ setLibelle () : void
+ setLogin () : void
+ etablissement () : void
+ setPwd () : void
+ toString () : String
+ utililisateur () : void
1..*
1..1
1..1
ticket réserver
- id_ticket : int
- QrCode : String
1..* + ticket () : void
agence
- id_agence : String 0..*
- libelle : String
- adresse : String
1..*
+ getAdresse () : String
+ setLibelle () : void appartenir à
+ setAdresse () : void
1..* + agence () : void 0..1
service
- id_service : int
- libelle : String
+ getID () : int
+ service () : void
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.

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 1.1 Ajouter un « user » dans le web API Sondes
peux créer mon compte et
Jami
m’authentifier.
1.2 Ajouter les fonctionnalités de Rimeh
l’affectation et de l’authentification
MOUSSI
dans le contrôleur de l’application
client.
1.3 Tester l’ajout et l’authentification Rimeh

d’un utilisateur
Sondes
2 En tant qu’un utilisateur je 2.1 Afficher un « user » dans le web API Sondes
peux afficher mon profil.
2.2 Ajouter la méthode de la récupération Rimeh
qui consommera le web services
2.3 Tester la récupération de profil Rimeh

d’utilisateur
Sondes
3 En tant qu’un utilisateur je 3.1 Supprimer un « user » dans le Web Sondes

peux supprimer mon profil. API
3.2 Ajouter la méthode de suppression de Rimeh

mon profil dans le contrôleur de
l’application client
3.3 Tester la suppression de compte Rimeh
Sondes
4 En tant que un utilisateur, je 4.1 Modifier un « user » dans le Web API Rimeh
peux modifier mon profil.
4.2 Ajouter la méthode de modification Sondes
de mon profil dans la partie client
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
 Créer compte
 Afficher compte
 Mettre à jour compte
Utilisateur  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é
1-L’utilisateur saisi son login et son mot de passe
2-Il clique sur le bouton « se connecter »
Description du scénario principal 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 »
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éé
1- L’utilisateur remplit le formulaire d’inscription
Description du scénario principal 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 »
Acteur Utilisateur
Précondition L’utilisateur doit être authentifié
Post condition Utilisateur modifié

1- L’utilisateur clique sur le bouton « Mon compte »
Description du scénario principal 2- Le système affiche les données dans un formulaire.
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.
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 »
Acteur Utilisateur
Précondition L’utilisateur doit être authentifié
Post condition Utilisateur supprimé

1- L’utilisateur clique sur le bouton « Mon compte »
Description du scénario principal 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
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.
utilisateur
- id_utilisateur : String 1
- nom : string
- prenom : String
- adresse : String
- email : String compte
- num_telphone : int - login : String
- login : String possède - password : String
- mot_de_passe : String + GetCurrentUser ()
+ GetCurrentUser () 0..1 + CreateUser ()
+ createUser () + Deleate ()
+ DeleteUser ()
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 :
Collection : users
Document : user
_id: String
Nom : String
Prénom : String
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",
"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.1.Backlog Product
Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de
ce sprint :
1 1.1 Ajouter un « établissement » dans Rimeh

le web API
En tant qu’un utilisateur, je peux 1.2 Ajouter les fonctionnalités de Sondes

ajouter un établissement l’affectation dans le contrôleur de
l’application client.
1.3 Tester l’ajout d’un établissement Rimeh
Sondes
2 2.1 Afficher les « établissements » Sondes

En tant qu’un utilisateur je peux dans le web API
afficher les établissements.
2.2 Ajouter la méthode de la Rimeh
récupération qui consommera le
web services
2.3 Tester la récupération des Rimeh

établissements
Sondes
3 3.1 Supprimer un « établissement » Sondes

dans le Web API
En tant qu’un utilisateur je peux 3.2 Ajouter la méthode de suppression Rimeh

supprimer un établissement. d’un établissement dans le
contrôleur de l’application client
3.3 Tester la suppression d’un Rimeh

établissement
Sondes
4 4.1 Modifier un « établissement » dans Rimeh

le Web API
En tant que un utilisateur, je peux
modifier un établissement. 4.2 Ajouter la méthode de Sondes
modification d’un établissement
dans la partie client
4.3 Tester la modification d’un Sondes

établissement Rimeh
5.1 Ajouter une « agence » dans le web Sondes

5 API
En tant que un utilisateur, je peux 5.2 Ajouter les fonctionnalités de Rimeh

ajouter une agence à un l’affectation dans le contrôleur de
établissement déterminé. 5.3 Tester l’affectation d’une agence. Rimeh
Sondes
6 6.1 Afficher les « agences » dans le Sondes

web API
En tant qu’un utilisateur je peux
afficher toutes les agences ou bien 6.2 Ajouter la méthode de la Rimeh
les agences d’un établissement. récupération qui consommera le
web services
6.3 Tester la récupération des agences Sondes
Rimeh
7 En tant qu’un utilisateur je peux 7.1 Supprimer une « agence » dans le Sondes
supprimer une agence. Web API
7.2 Ajouter la méthode de suppression Rimeh
d’une agence dans le contrôleur de

7.3 Tester la suppression d’une agence Sondes
Rimeh
8 8.1 Modifier une « agence » dans le Sondes

Web API
8.2 Ajouter la méthode de Rimeh

modification
modifier une agence
d’une agence dans le contrôleur de
8.3 Tester la modification d’une Rimeh

agence
Sondes
9 9.1 Ajouter un « service » dans le web Sondes
API

ajouter un service à un 9.2 Ajouter les fonctionnalités de
établissement et l’affecter à des l’affectation dans le contrôleur de
Rimeh
agences. l’application client.
9.3 Tester l’ajout d’un service Sondes
Rimeh
10 En tant que un utilisateur, je peux 10.1 Afficher les « services » dans le Sondes
lister tous les services, les services web API
d’un établissement ou bien d’une
agence donnée.
10.2 Ajouter les fonctionnalités de Sondes
l’affichage dans le contrôleur de
Rimeh
10.3 Tester la récupération des services. Sondes
11 11.1 Modifier le « service » dans le web Rimeh

API
11.2 Ajouter les fonctionnalités de la Sondes

modification dans le contrôleur de
modifier service.
11.3 Tester la modification d’un service. Rimeh
Sondes
12 12.1 Supprimer le « service » dans le Sondes

web API

supprimer un service à partir de la 12.2 Ajouter les fonctionnalités de la
liste des services, d’une agence ou suppression dans le contrôleur de
Rimeh
bien d’un établissement. l’application client.
12.3 Tester le cas de la suppression Rimeh
service.
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
 Créer un établissement
 Créer une agence
 Créer un service
 Afficher la liste des établissements
 Afficher la liste des agences
Utilisateur  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

1-L’utilisateur choisi le lien gestion des
établissements
Description du scénario principal 2-Il clique sur le bouton « créer » ou « liste des
établissements »
3-Le système affiche la page selon le lien choisi
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
l’option « gestion des agences»
Post condition Afficher la page d’accueil

1-L’utilisateur choisi le bouton gestion des
Description du scénario principal agences
2-Il clique sur le lien « créer » ou « liste des
agences »
3-Le système affiche la page selon le lien.
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
l’option « gestion des services»
Post condition Afficher la page d’accueil

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
Description du scénario principal « liste des services par une agence »
3-Le système affiche la page selon le lien.
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.
établissement
- id_établissement : int
- libelle : String
1..1
service 1..*
- id_service : int
- libelle : String agence
+ getLibelle () : String - id_agence : String
1..* - libelle : String
+ getID () : int - adresse : String
1..*
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 :
Collection : établissements
Document : établissement
_id: String
Libellee: String
Agence :{
_id : String
Libellee: String
Addressee: String
Service :{
_id : String
Libellee: String
….
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.1. Backlog Product

Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de
ce sprint :
Rimeh
En tant qu’un utilisateur, je Ajouter les fonctionnalités dans le

peux consulter le nombre des contrôleur de l’application client.
1.1
agences par établissement.
1
1.2 Tester l’affichage des graphiques Sondes
2.1 Ajouter la méthode dans le contrôleur Sondes

de l’application client.
En tant qu’un utilisateur je
2 peux afficher le nombre des 2.3 Tester la méthode. Rimeh
services par établissement.
3 3.1 Ajouter la méthode dans le contrôleur Rimeh

de l’application client
En tant qu’un utilisateur je 3.2
peux afficher le nombre des
3.3 Tester les fonctionnalités. Sondes
services par agence.
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

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
 Afficher le nombre des agences par

établissement
 Afficher le nombre des services par
établissements
 Afficher le nombre des services par
agence.
Utilisateur
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

1-L’utilisateur clique sur le bouton statistiques
Description du scénario principal 2-Il choisi un lien
3-Le système affiche la page des statistiques
selon le lien choisi.
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
établissement
- id_établissement : int
- libelle : String
1..1
service 1..*
- id_service : int
- libelle : String agence
+ getLibelle () : String - id_agence : String
1..* - libelle : String
+ getID () : int - adresse : String
1..*
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 ID Tâche Affectation

User story Tâche
1 En tant que client, je 1.1 Réaliser les diagrammes de cas Rimeh MOUSSI
veux consulter la liste d’utilisation, de séquence système, de
des établissements. classe, de séquence détaillée du cas «
Consulter établissement »
1.2 Développer le cas «Consulter Rimeh MOUSSI

établissement»
1.3 Tester le cas «Consulter Sondes JAMI

établissements»
2 En tant que client, je 1.1 Réaliser les diagrammes de cas Sondes JAMI
d’utilisation, de séquence système, de
veux consulter la liste
classe, de séquence détaillée du cas «
des services d’un Consulter service »
établissement donné. 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 1.1 Réaliser les diagrammes de cas Rimeh MOUSSI
veux consulter la liste
classe, de séquence détaillée du cas «
des agences ayant un Consulter agence dans le maps »
service donné et ma 1.2 Développer le cas «Consulter agence» Sondes JAMI
position dans maps.
1.3 Tester le cas «Consulter agence» Rimeh MOUSSI
4 En tant que client, je 1.1 Réaliser les diagrammes de cas Sondes JAMI
veux réserver un ticket
classe, de séquence détaillée du cas
et faire la notification «Réservation un ticket »
de tour 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 le ticket et les
informations avec le
QR Code.
Après la réservation,
Affiche la liste des remplir le formulaire de
établissements, la notification de tour.
Affiche la liste des
Puis, le client sélectionne agences les plus
un parmi cette liste proches dans maps
Affiche la liste des services

d’un établissement
sélectionné
Figure 59: prototype des interfaces mobile

2. Diagramme des cas d’utilisation du quatrième Sprint
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
Réserver ticket
Client
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
client
- emailClient : String
+ getEmail () : String
+ setEmail () : void
+ client () : void
1..1
1..1 réserver
ticket
- id_ticket : int
- QrCode : String
+ ticket () : void
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  Interface liste des agences dans maps
Figure 64: interface liste service 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
Application mobile
Application web
Front office
Back office
Administrateur
JSON
Client
Service Web
MongoDB
Figure 70: Architecture générale de l'application
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 \data\db
Démarrez MongoDB
Pour démarrer MongoDB, exécutez mongod.exe . Par exemple, à partir de l’invite

de commande : C:\mongodb\bin\mongod.exe
Connectez-vous à MongoDB
Pour se connecter à MongoDB à travers le mongo.exe Shell, ouvrir une autre invite
de commande : C:\mongodb\bin\mongo.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 http://ionicframework.com/
Ionic http://forum.ionicframework.com/
Documentation https://cordova.apache.org/
Apache Cordova 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/

Systéme Ticket Attente

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Systéme Ticket Attente

Titre original :

Transféré par

Droits d'auteur :

Ministère de l’Enseignement

Conception & Développement d’une

Projet de Fin d’Etudes

Année Universitaire : 2015/2016

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.

Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude et de

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

A tous mes amis et mes collègues qui m’ont soutenu.

À tous mes professeurs pendant mon parcours de l’école vers l’université.

A Mes Très Chers Parents (AZOUZ & RAFOUKA)

Je dédie aussi ce travail à :

Nous voudrons avant tout adresser notre gratitude et notre profonde

Rimeh & Sondes

Introduction générale ........................................................................................................................... 11

Figure 1: Principales informations du « LYNA-ICT » ............................................................................ 13

Tableau 1: Nombre des clients par jour à municipalité Tunis ............................................................. 16

1. Présentation de l’organisme : LYNA-ICT

Dans ce cadre, la figure suivante donne quelques informations sur 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 -

Lien web http://lyna-ict.com/

Figure 1: Principales informations du « LYNA-ICT »

2.1. Etat actuel :

Ces solutions modulaires, adaptables à différents secteurs (Distribution, Santé,

Figure 3 : Un gestionnaire d’accueil mono service multi points d’accueil

Les écrans d’appel Les distributeurs

Figure 3: Écran d’appel files d'attente Figure 4 : Distributeur de tickets tactile

 Municipalité Tunis, sidi hessine

Tableau 1: Nombre des clients par jour à municipalité Tunis

 Poste : Tunis, Avenue Ferhat Hached - 1060 Tunis

Services abonnements Service de poste Payement des factures : L’épargne

Tableau 2: Nombre des clients par jour à poste Tunis

Ces applications, vont être mises à la disposition de l’administrateur et du client.

La solution proposée est le développement de :

5. Cahier des charges

Une application back office web qui nous fournit :

Les Statistiques concernant :

6. Langage et méthodologie de conception

6.1. Méthodes agiles

Cette la méthode s’agit de la réitération de cycles courts dans le temps en divisant le

 L’interaction entre acteurs plutôt que les processus et les outils.

6.1.2. Les 12 principes de méthodes agiles :

1- Satisfaire le client en 5-Bâtir le projet autour de 9-Rechercher l’excellence

Tableau 3: Les 12 principes de méthodes agiles

6.1.3. Les principales méthodes agiles :

Nous distinguons surtout :

Figure 6 : rugby Scrum

6.2.1. Pourquoi Scrum ?

Scrum place l’humain au centre de la méthodologie.

La figure ci-dessous illustre le processus sur lequel est basé SCRUM :

Figure 7: processus SCRUM