Rapport stage pfe

1
Projet de Fin d’Etudes
Pour l’obtention du :
Diplôme de Licence Appliquée en Technologies de l’Information
Réalisé par :
Sondes JAMI
Rimeh MOUSSI
Entreprise d’accueil : LYNA-ICT
Encadré par :
Encadreur Entreprise : Mr. Anass Saïd
Encadreur ISET Radés : Mme. Eya Cheikh
Année Universitaire : 2015/2016
Ministère de l’Enseignement
Supérieur, de la Recherche
Scientifique et des
Technologies de l'Information
et de la Communication
*** * ***
Institut Supérieur des
Etudes
Technologiques de Radés
Conception & Développement d’une
application mobile pour la réservation des
tickets auprès des guichets de service
--------------------------------------------------
--------------------------------------------------
------------------------------------------

Dédicaces
Je dédie ce modeste travail et ma profonde gratitude :
À mon père et ma mère
Autant de phrases aussi expressives soient-elles ne sauraient montrer le
degré d’amour et d’affection que j’éprouve pour eux.
Merci pour tout l'amour et la confiance et pour votre énorme support
pendant la réalisation de mon projet.
"Je vous dois ce que je suis aujourd’hui et ce que je serai demain et je ferai
toujours de mon mieux pour rester votre fierté et ne jamais vous décevoir...»
Qu’ils trouvent dans ce travail un humble témoignage de ma gratitude et de
ma reconnaissance.
A mes frères Moncef, Ramzi et Abd Alwaheb
Pour leur patience, leur amour et leur encouragement.
A mes sœurs Dalila, Bornia et Rahma
Sans leurs conseils et leur amour je serai perdue...
A mes grands-parents Boujema et Zina
Pour leurs encouragements continus et leurs confiances énormes en moi.
À ma grande famille, petite et grande, qui a cru en moi, à mes cousins et
cousines…
A tous mes amis et mes collègues qui m’ont soutenu.
À tous mes professeurs pendant mon parcours de l’école vers l’université.
À toute personne qui a gravé ma vie par un mot qui m’a orienté vers le bon
chemin...
Sondes JAMI

Dédicaces
A Mes Très Chers Parents (AZOUZ & RAFOUKA)
Tous les mots du monde ne sauraient exprimer l’immense amour que je
vous porte, ni la profonde gratitude que je vous témoigne pour tous les
efforts et les sacrifices que vous n’avez jamais cessé de consentir pour
mon instruction et mon bien-être. C’est à travers vos encouragements que
j’ai opté pour ce chemin, et c’est à travers vos critiques que je me suis
réalisé. J’espère avoir répondu aux espoirs que vous avez fondés en moi.
Je vous rends hommage par ce modeste travail en guise de ma
reconnaissance éternelle et de mon infini amour. Que Dieu tout puissant
vous garde et vous procure santé, bonheur et longue vie pour que vous
demeuriez le flambeau illuminant le chemin de vos enfants.
Je dédie aussi ce travail à :
Mon frère(Nazoura) & Mes soeurs (TAssouma , Fatouna & Hallouma
) pour leurs encouragements incessants.
A Tous mes enseignants
et Tous mes amis en souvenir des bons moments que nous avons passés
ensemble, pour leur soutien continu, leur aide précieuse et leur amour.
Rimeh MOUSSI

Remerciements
Nous voudrons avant tout adresser notre gratitude et notre profonde
reconnaissance à tous ceux qui, de près ou de loin, ont contribué à
l’aboutissement de ce travail.
Nous tenons à exprimer nos vifs remerciements en premier lieu à
notre encadreur de LYNA-ICT Anass Saïd.
Nous adressons aussi nos profonds remerciements à Monsieur Mehdi
Metir enseignant au sein de l’institut pour ses conseils et Madame Eya
Cheikh, notre encadreur au sein de l’ISET Rades, pour son
encadrement, son soutien et sa disponibilité qui nous ont guidés tout
au long de notre stage.
Par la même occasion, Nous exprimons nos sincères reconnaissances
à l’égard de tous ceux qui ont contribué à notre formation,
particulièrement les enseignants de l’institut supérieur des études
technologiques de radés.
Finalement, Nous tenons aussi à remercier vivement les membres du
jury qui nous ont fait l’honneur d’évaluer ce travail.
Rimeh & Sondes

Table des matières
Introduction générale........................................................................................................................... 11
Chapitre 1 : Cadre du projet et méthodologie.................................................................................. 12
1. Présentation de l’organisme : LYNA-ICT ............................................................................ 12
2. Etude de l’existant................................................................................................................... 13
2.1. Etat actuel :...................................................................................................................... 13
2.2. Analyse ............................................................................................................................. 15
3. Critique de l’existant............................................................................................................... 16
4. Solution proposée ........................................................................................................................ 17
5. Cahier des charges....................................................................................................................... 17
6. Langage et méthodologie de conception.................................................................................... 18
6.1. Méthodes agiles..................................................................................................................... 18
6.2. SCRUM ................................................................................................................................. 20
6.3. Langage de modélisation UML (Unified Modeling Language)........................................ 24
Chapitre 2 : Planification & architecture ......................................................................................... 25
1. Spécification des besoins......................................................................................................... 25
1.1. Identification des acteurs du système ............................................................................ 25
1.2. Les besoins fonctionnels.................................................................................................. 26
1.3. Les besoins non fonctionnels........................................................................................... 27
2. Structure et découpage du projet : ........................................................................................ 27
2.1. Identification de l’équipe SCRUM................................................................................. 27
2.2. Découpage des sprints..................................................................................................... 28
2.3. Le Backlog du produit..................................................................................................... 29
2.4. Planification des releases ................................................................................................ 30
2.5. Diagramme de cas d’utilisation initial........................................................................... 32
2.6. Diagramme de classe initial ............................................................................................ 32
Chapitre 3 : Sprint 1 - Sprint Gestion du compte ............................................................................ 34
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
affaires
économiques
Service des affaires sociales,
culturelles, de la jeunesse
et des sports
Nombre des
clients par jour
1053 950 1033 965
Tableau 1: Nombre des clients par jour à municipalité Tunis
 Poste : Tunis, Avenue Ferhat Hached - 1060 Tunis
Services abonnements Service de poste
rapide
Payement des factures :
Eau, Téléphone,
Electricité...
L’épargne
Nombre
des clients
par jour
1250 950 1000 820
Tableau 2: Nombre des clients par jour à poste Tunis

Une analyse plus détaillée de la description précédente nous a conduits à dégager
plusieurs anomalies concernant le passage de la réservation des tickets. Ces anomalies
peuvent être résumées comme suit :
- Une obligation de déplacement,
- Une file longue avec perte de temps,
- Un risque d’attente en vain,
- Un stress inévitable.
4. Solution proposée
Actuellement il n’existe aucune application qui gère notre domaine d’études. En effet
ce besoin touche nos vies quotidiennes, on propose alors une solution pour éviter la perte de
temps dans les salles d'attente d'un service public.
Pour ce faire, on propose de réaliser un système composé d’une application web et une
application mobile pour gérer et surtout pour réserver un ticket pour une agence donnée sans
se déplacer.
Ces applications, vont être mises à la disposition de l’administrateur et du client.
La solution proposée est le développement de :
 Une application Front office mobile qui offre aux bénéficiaires de services la
possibilité de réserver sans se déplacer un ticket auprès d’une entreprise abonnée
dans la plateforme, et de le notifier à l’arrivée de son tour.
 Une application Back office web pour le paramétrage, l’administration et les
statistiques sur l’utilisation de l’application.
Les avantages de la solution proposée :
 Améliorer les services ;
 Les clients rejoignent la file d'attente avant d'arriver économisant ainsi un
temps précieux.
5. Cahier des charges
La solution qu’on a proposée consiste à la conception et la réalisation de :
Une application back office web qui nous fournit :
Les Statistiques concernant :
 Les établissements

 Les agences
 Les services
Le paramétrage :
 La gestion des entreprises : permet de gérer les entreprises qui vont
s’inscrire dans la plateforme.
 La gestion des centres de service : permet de gérer les bureaux de chaque
entreprise inscrite dans la plateforme.
 La gestion des services : permet la gestion des services offerts au niveau
des bureaux de chaque entreprise inscrite dans la plateforme.
Et une application front office mobile qui permet :
 La réservation de tickets pour le bénéficiaire de service. L’application
doit tenir compte de l’emplacement géographique du demandeur de
ticket, du ticket en cours de traitement et du dernier ticket imprimé.
 La notification de tour permettant la configuration de la durée avant
laquelle un client va être notifié.
6. Langage et méthodologie de conception
Pour résoudre le problème et trouver des solutions pour gérer tout type de tâche,
chaque personne doit suivre une démarche pour avoir un résultat efficace et bien structuré
selon des méthodes adoptées.
C’est pour cela qu’on doit choisir pour les meilleures solutions et les plus optimales
pour avoir recours à une méthodologie puissante qui permet de gérer un cycle de vie d’un
projet. Il existe plusieurs méthodes dans ce qui suit nous nous intéressons aux méthodes agiles
vues leurs apports pour des projets ou les besoins évoluent.
6.1. Méthodes agiles
« Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion de
projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en
fonction des besoins évolutifs du client. Elles permettent notamment d'impliquer l'ensemble
des collaborateurs ainsi que le client dans le développement du projet. » [1]
Cette la méthode s’agit de la réitération de cycles courts dans le temps en divisant le
projet en de multiples mini-projets et les prioriser selon les besoins.

6.1.1. Les quatre valeurs fondamentales Agiles étaient déclarées être :
 L’interaction entre acteurs plutôt que les processus et les outils.
 Un produit opérationnel plutôt qu’une documentation pléthorique.
 La collaboration avec le client plutôt que la négociation de contrat.
 La réactivité face au changement plutôt que le suivi d'un plan
6.1.2. Les 12 principes de méthodes agiles :
1- Satisfaire le client en
livrant tôt et régulièrement
des logiciels utiles qui
offrent une véritable valeur
ajoutée
5-Bâtir le projet autour de
personnes motivées en leur
fournissant environnement et
support et en leur faisant
confiance
9-Rechercher l’excellence
technique et la qualité de la
conception
2-Accepter le changement
même tard dans le
développement
6-Communiquer par des
conversations en face à face
10-Laisser l’équipe s’auto-
organiser
3-Livrer fréquemment une
application qui fonctionne
7-Mesurer la progression
avec le logiciel qui
fonctionne
11-Rechercher la simplicité
4-Collaborer
quotidiennement entre
clients et développeurs
8-Garder un rythme de
travail durable
12- À intervalles réguliers,
réfléchir aux moyens pour
devenir plus efficace
Tableau 3: Les 12 principes de méthodes agiles
6.1.3. Les principales méthodes agiles :
Nous distinguons surtout :
 SCRUM
 Extreme Programming (XP)
 Rapid Application Development (RAD)
 Crystal clear
Si nous voulons définir l’agilité en quelques mots : c’est l’intelligence organisationnelle et
technologique, associée à de l’énergie de groupe dans le but d’être immédiatement efficients.
Suite à l’étude de plusieurs méthodologies et de leur convenance à notre projet, nous avons
opté pour l’utilisation de la méthode SCRUM.

6.2. SCRUM
La méthode Scrum est une méthode agile, créée en 2002, dont le nom est un terme
emprunté au rugby qui signifie « la mêlée ». Elle s'appuie sur le découpage des projets en
itérations encore nommées « sprints ». [1]
Figure 6 : rugby Scrum
SCRUM correspond plus à une démarche de travail qu’à une méthode. Son avantage
principal est sa capacité à obtenir un résultat final dans un laps de temps court tout en
s’appuyant sur une équipe cohérente. Cette équipe va s’atteler à atteindre un objectif
progressif qui évoluera au cours de cycles successifs et itératifs appelés Sprints. La durée d’un
sprint varie entre 15 et 30 jours, et à sa fin, l’équipe présentera un produit correspondant aux
spécificités énoncées au début du cycle. Parmi les atouts du concept de sprint (court et rapide)
est qu’il permet au propriétaire du produit de changer la priorisation des caractéristiques
demandées au fur et à mesure de l’avancement du développement.
La fin de chaque sprint est une occasion de voir le produit courant fonctionner, et de
prendre la décision de livraison ou du lancement d’un nouveau sprint d’amélioration du
produit.
6.2.1. Pourquoi Scrum ?
Scrum place l’humain au centre de la méthodologie.
L’avantage principal de cette méthode est qu’elle correspond parfaitement à une petite équipe
qui travaille sur un grand projet, elle s’appuie sur la répartition des tâches et la collaboration
entre les membres du groupe. Avec les anciennes méthodes, le client ne voyait le logiciel
qu’au moment de la livraison et n’était pas impliqué au cours des différentes phases de son
développement. En effet, il n’avait accès aux tests que lorsque le produit était fini ou presque.

Par contre en Scrum, l’implication du client a lieu tout au long du processus car il y a
plusieurs livrables qu’il doit valider. Chaque livrable correspond à l’implémentation de
nouvelles fonctionnalités et le client peut facilement apprécier l’avancement du produit et il a
de nombreuses occasions de demander les ajustements nécessaires à la satisfaction de sa
demande.
Grâce à Scrum, nous avons pu réduire les temps de production et répondre au plus près
aux besoins du client. Scrum vise donc essentiellement l’optimisation de la prévisibilité d’un
projet tout en réduisant les risques au minimum.
La figure ci-dessous illustre le processus sur lequel est basé SCRUM :
Figure 7: processus SCRUM
Scrum est :
 Léger
 Simple à comprendre
 Difficile à maîtriser
Durant un développement d’un projet avec la méthode Scrum il y a plusieurs étapes à suivre
avec une démarche spécifique et une interaction avec plusieurs intervenants.

Figure 8: pratique de SCRUM
6.2.2. Les intervenants dans Scrum
La méthode Scrum définit trois rôles pour un projet :
 Le Product Owner :
C’est le propriétaire du produit et le chef d’orchestre qui valide ou décline le produit délivré.
L’une de sa responsabilité principale est la définition des besoins du produit à développer et la
rédaction des spécifications. Il est le seul gérant du Backlog du produit.
 Le Scrum Master :
Il est chargé de veiller au bon déroulement et application de la méthode Scrum et au respect
de ses objectifs. Il veille également à ce que les éventuels obstacles que l’équipe peut
rencontrer soient effacés. Il assure la bonne progression de l’équipe ainsi que sa productivité.
 Team Membres :
Ce sont les membres de l’équipe qui ont à leur charge le développement et la réalisation d’un
produit fiable et utilisables. Ses membres sont soit développeur, soit architectes, soit testeurs.
6.2.3. Les artéfacts dans Scrum
Les principaux artéfacts qu’on peut les générer lors de l’utilisation de la méthode Scrum :
 Le « Product Backlog » : (Carnet de produits)
C’est un outil de collecte des fonctionnalités attendues ou exigées par le client (User Story),
et qui évolue à chaque Sprint. [2]

 Le « Sprint Backlog » : (Carnet d'itération)
Il contient la liste des tâches qui doit être accomplie pour mettre en œuvre les fonctionnalités
prévues pour un Sprint particulier. Idéalement, chaque tâche dans un sprint est relativement
courte et peut-être captée par un membre de l'équipe plutôt que d'être affecté. [3]
 « Burndown charts » : (Graphique d’avancement).
C’est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans sa
globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint. [2]
L’axe vertical présente la quantité de travail à faire et l’axe horizontal les jours de travail.
6.2.4. Planification d’un projet par Scrum
La durée de vie d’un projet en Scrum est rythmée par un ensemble de réunions clairement
définies et strictement limitées dans le temps.
 Planification d'itération « Sprint Planning »
Au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du
« Product Backlog » qu'elle pense pouvoir réaliser au cours du sprint en accord avec le «
Product Owner »
 Mêlée quotidienne « Daily Scrum Meeting »
La mêlée quotidienne (Daily Scrum) est un événement limité à 15 minutes au cours duquel
l’équipe de développement synchronise ses activités et crée un plan pour les prochaines 24
heures. Pour ce faire, l’équipe inspecte le travail effectué depuis la dernière mêlée quotidienne
et envisage le travail qui peut être réalisé d’ici à la prochaine. [4]
Chaque membre de l'équipe répond à trois questions :
 Qu'as-tu accompli depuis la dernière mêlée ?
 Que vas-tu accomplir jusqu'à la prochaine mêlée ?
 Est-ce que des éléments te bloquent dans ton avancement ?
Et si on doit obtenir des informations de la part du client, c’est le Product Owner qui doit
s’assurer de le contacter pour obtenir les réponses.
 Revue d'itération « Sprint Review »
La revue de l’itération est organisée à chaque fin de cycle de développement. C’est une
présentation des différentes fonctionnalités développée durant le cycle. Le propriétaire du
produit aura l’occasion d’évaluer le produit et de le comparer à ce qui a été spécifié lors de la
séance de planification d’itération. Une fois la revue achevée, un nouveau cycle d’itération
démarre et relance ainsi la boucle : planification, développement et revue. Il s’agit là d’un

point de contrôle journalier pour toute l’équipe, limité à 15 min, dans lequel ils alignent et
synchronisent leur travail pour optimiser la planification des prochaines 24 heures.
 Rétrospective de sprint :
La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de
planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois.
Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum
Master s’assure que la réunion a lieu et que les participants en comprennent le but. [4]
Une fois la méthodologie de conception choisie, il convient maintenant de choisir quel
langage de modélisation on a adopté dans notre projet.
6.3. Langage de modélisation UML (Unified Modeling Language)
Une dizaine d'années après le début de son utilisation dans le
cadre de projets de développement orienté objet, UML s'est
imposé comme standard. Ce langage est né de la fusion de
plusieurs méthodes existant auparavant et est devenu désormais la
référence en matière de modélisation objet. La modélisation objet
consiste à créer une représentation informatique des éléments du monde réel auxquels on
s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un
langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs
données et les fonctions qui les utilisent. [5]
Donc, après le choix de la méthodologie, on a opté UML comme un langage de modélisation
qui est utilisé dans tous les projets logiciels comporte un ensemble des diagrammes, il permet
de fournir une représentation informatique d’un ensemble d’objets et de problèmes standards
du monde réel.
Conclusion
Dans ce premier chapitre, nous avons commencé par présenter notre organisme
d’accueil LYNA-ICT. Ensuite, nous avons décrit le contexte du stage, puis nous avons dressé
la problématique de notre projet, le tout en fournissant les critiques et les solutions
envisageables.
Enfin nous avons étayé le choix de la méthodologie de travail utilisée SCRUM, et par la suite
nous nous dirigerons naturellement vers la planification et architecture.

Chapitre 2 : Planification & architecture
Dans le chapitre précédent, nous avons évoqué le choix de la méthode Scrum.
Maintenant nous passerons à la phase la plus intéressante de cette méthodologie appelée phase
de « planification et architecture » ou « Sprint Zéro ».
Le sprint zéro, n’est pas considéré comme un vrai sprint, puisqu’il ne donne pas de version
potentiellement livrable lorsqu’il touche à sa fin : c’est plutôt un échauffement, pour les
sprints réels. Il s’agit en fait d’une phase de planification et architecture qui ne se termine pas
nécessairement par une livraison.
C’est donc dans ce chapitre que nous allons définir notre produit finit (Service sans attente) et
ses différentes fonctionnalités en partant de l’identification des besoins, nous élaborerons les
rôles des utilisateurs et préparerons l’environnement de développement. Nous finirons par
déterminer un plan de Release afin de produire le Product Backlog initial ainsi qu'une
première planification des sprints.
1. Spécification des besoins
L’analyse des besoins est une étape conduite à l’élaboration de spécifications. C’est
nécessaire de définir le projet et de mettre une planification pour bien le piloter et d'atteindre
les objectifs souhaités par le client avant leur démarrage.
1.1. Identification des acteurs du système
« Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositifs
matériels ou autres système) qui interagit directement avec le système étudié. » [5]
Pour élaborer notre projet on a pu identifier les acteurs suivants :

Figure 9: Les acteurs qui représentent notre projet
1.2. Les besoins fonctionnels
Les besoins fonctionnels c’est ce que l’utilisateur attend en matière de fonctionnalités.
Ces besoins présentent une description abstraite des services que le système est censé fournir
pour les utilisateurs et qui convient à leurs attentes et satisfaire leurs exigences.
Donc notre système doit permettre de :
 Le développement d’une application web :
Cette application sera essentiellement utilisée par l’administrateur. Elle doit
permettre de faire :
o Les statistiques concernant :
 Les établissements ;
 Les agences ;
 Les services.
o Le paramétrage :
 Des établissements ;
 Des agences ;
 Des services.
 Le développement d’une application mobile :
Cette application sera essentiellement utilisée par les clients, ces derniers peuvent :
 Réserver des tickets ;
 La notification de leur tour.

1.3. Les besoins non fonctionnels
Les besoins non fonctionnels sont des besoins qui ont un aspect visible pour
l’utilisateur, mais qui ne sont pas reliés directement au comportement du système.
Ils présentent les exigences internes primordiales pour le système tel que les contraintes liées
à l’environnement et à l’implémentation, et les exigences en matière de performances,
d’extensibilité et de fiabilité.
Les besoins non fonctionnels de notre système se décrivent comme suit :
 Le temps de réponse de l'application doit être minimal ;
 La portabilité du système sur n’importe quelle plateforme ;
 La performance, la fiabilité et la flexibilité du système ;
 L’application doit être accessible à plusieurs utilisateurs en même temps ;
 L’architecture de l’application doit être capable de supporter
l’implémentation de services web et mobile ;
 Les interfaces de notre application doivent être claires, concises, conviviales
et facile à manipuler.
2. Structure et découpage du projet :
2.1. Identification de l’équipe SCRUM
L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la productivité et la flexibilité.
Afin de parvenir à ces objectifs, elle doit s’auto organiser et être multi compétente. Elle doit
également avoir un champ d’action suffisant pour la soutenir dans la réalisation de son travail
Dans le contexte de notre projet, on trouve :

Product Owner : les directeurs des
départements
Scrum master : M. Anass Saïd
Team : Sondes JAMI & Rimeh MOUSSI
Figure 10 : Équipes et rôles
2.2. Découpage des sprints
La structuration d'un projet consiste à diviser le projet en différents lots d'activités afin d'avoir
des sous-parties dont la complexité est plus facilement maitrisable.
Voici ci-dessous la structuration de notre projet :

Figure 11: Découpage du projet
2.3. Le Backlog du produit
Comme nous avons déjà mentionné le Backlog du produit est un outil qui sert à
collecter les fonctions essentielles et les raffine progressivement. C’est l’ensemble des
caractéristiques fonctionnelles « user story » ou techniques « technical story » qui constituent
le produit souhaité.
Un user story s’écrit comme suit :
En tant que <rôle>
Je veux < liste de tâches>
Afin de < valeur ajoutée ou résultat>
Pour chaque user story on identifie le rang, l’estimation, l'importance et la description.
Le tableau suivant décrire le Backlog produit de notre application et évoque les User Stories :
ID En tant que Je veux Pour que Importance
1 Administrateur M’authentifier J’accède à l’application en assurant sa
sécurité
+ + +
2 Administrateur Gérer établissement Traiter les informations concernant un
établissement
+ + +
3 Administrateur Gérer agence Traiter les informations concernant une
agence
+ +
4 Administrateur Gérer service Traiter les informations concernant un
service
+ + +
5 Administrateur Gérer profil Je traite mes informations + +

6 Administrateur Afficher les
statistiques
Mettre en évidence les résultats de
l’application.
+++
7 Client Utiliser l’application
mobile front office
Réserver un ticket et faire la notification
de tour.
+++
Tableau 4: tableau de Backlog initial
2.4. Planification des releases
Tous les projets nécessitent des plans, pour essayer de prévoir à peu près ce que va
contenir un produit ou à quelle date il sortira sur le marché. Avec la méthodologie agile
Scrum, la planification de release aux mêmes objectifs puisqu’il donne à l’équipe et aux
parties prenantes des informations sur le contenu des sprints constituant le release.
Un release correspond à la livraison d'une version. Par habitude, on parle de release
pour considérer la période de temps qui va du début du travail sur cette version jusqu'à sa
livraison et qui passe par une série de sprints successifs. [5]
Toute l’équipe Scrum participe à la planification de la release (l’équipe complète, avec le
Scrum Master et le Product Owner) car ceux qui vont exécuter les tâches de réalisation sont
les mieux placés pour en connaître les problèmes et les difficultés.
La planification de Sprint répond aux questions suivantes :
 Qu’est-ce qui peut être terminé au cours de ce Sprint ?
 Comment sera effectué le travail choisi ?
Dans notre projet, on va travailler sur une seule release, il ne contient pas une succession
de sprints, cette démarche a été abandonnée. Chaque feature est fortement liée à d’autres ce
qui a accentué notre choix de structuration en sprints, plutôt qu’en releases.
Schéma Ci-dessous décrit le concept du découpage des Releases en Sprints :
Figure 12 : Exemple de schéma de découpage en Releases

Figure 13 : Découpage le projet en des sprints
Durant la période de stage la figure suivante conclut la planification qu’on suivra pour la
gestion de notre projet :
Figure 14: Planning du déroulement du projet
Remarque :

La date de fin du sprint est fixée au début du sprint (elle est même définie avant). Elle
ne change pas, même si l’équipe ne réalise pas tout ce qu’elle imaginait faire. L’évaluation de
fin de sprint permettra d’inspecter ce qui a été fait et d’en tirer des conséquences pour la suite.
Maintenant, nous allons présenter les différents besoins fonctionnels de notre application
exprimés précédemment d'une manière informelle en utilisant le digramme de cas d'utilisation
d'UML initial. [6]
2.5. Diagramme de cas d’utilisation initial
Les cas d’utilisation sont une technique de description qui sert à présenter les besoins
des utilisateurs par rapport au système.
Figure 15: Diagramme de cas d'utilisation initial d'une application back office web
Figure 16: Diagramme de cas d'utilisation initial d'une application front office mobile
2.6. Diagramme de classe initial
Le diagramme de classe permet de fournir une représentation abstraite des objets du système
qui vont interagir pour réaliser les cas d'utilisation. Il est important de noter qu'un même objet
peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation. [7]

0..*
0..1
1..*
1..*
gérer
réserver
appartenir à
1..1
1..*
1..1
1..1
1..*
1..*
utilisateur
-
-
-
-
-
-
-
-
id_utilisateur
nom
prenom
adresse
adress_mail
telphone
login
mot_passe
: int
: String
: String
: String
: String
: String
: String
: String
+
+
+
+
+
+
+
getAdresse ()
setAdresseMail ()
getAdresseMail ()
setLogin ()
setPwd ()
utililisateur ()
toString ()
: String
: void
: String
: void
: void
: void
: String
établissement
-
-
id_etablissement
libelle
: int
: String
+
+
+
+
getLibelle ()
setLibelle ()
etablissement ()
toString ()
: String
: void
: void
: String
agence
-
-
-
id_agence
libelle
adresse
: String
: String
: String
+
+
+
+
+
+
getLibelle ()
getAdresse ()
setLibelle ()
setAdresse ()
agence ()
toString ()
: String
: String
: void
: void
: void
: String
ticket
-
-
id_ticket
QrCode
: int
: String
+
+
ticket ()
toString ()
: void
: String
client
- adresse_mail : String
+
+
+
+
Client ()
toString ()
setMail ()
getMail ()
: void
: String
: void
: String
service
-
-
id_service
libelle
: int
: String
+
+
+
+
+
getLibelle ()
setLibelle ()
getID ()
service ()
toString ()
: String
: void
: int
: void
: String
Figure 17 : Diagramme de classe initial
Conclusion
Toute au long de ce chapitre, nous avons préparé notre planification de travail pendant
laquelle on a identifié l’équipe de projet ainsi qu’on a construit notre Backlog de produit en se
basant sur les besoins fonctionnels et non fonctionnels. Finalement nous avons mentionné le
découpage de notre release en des sprints.
Dans la partie qui suit, Nous allons enchainer à présenter avec notre premier sprint « gestion
des comptes»

Chapitre 3 : Sprint 1 - Sprint Gestion des comptes
Dans le chapitre précédent, nous avons défini ce qu'est un sprint : une succession de
tâches effectuées par les parties prenantes de la méthodologue Scrum afin d'atteindre l'objectif
prédéfini par l'équipe.
Le chapitre en cours quant à lui traiter les "users stories" de notre sprint en les classant
dans des features qui pourront s'intégrer à une release et repartis en users stories. Une question
s’impose avant même d'initier le premier sprint : « Pourquoi faisons-nous ce sprint ?». La
réponse devra être compréhensible, non pas au sein de l'équipe, mais surtout en dehors.
Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum,
plus précisément, l’analyse, la conception, le développement et on achève les tests.
1.1. Backlog Product
Comme détaillé dans le premier chapitre, le Sprint Backlog est défini au cours de la
réunion de planification : il s’agit de la liste des tâches que l’équipe Scrum doit réaliser durant
le Sprint dans le but de transformer un ensemble d’éléments du carnet de commandes dans
une version préliminaire du produit finit répondant aux exigences prédéfinies.
Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au
sein de ce sprint :
ID « User Story » id Tache Affectation
1 En tant qu’un utilisateur, je
peux créer mon compte et
m’authentifier.
1.1 Ajouter un « user » dans le web API Sondes
Jami
1.2 Ajouter les fonctionnalités de
l’affectation et de l’authentification
dans le contrôleur de l’application
Rimeh
MOUSSI

client.
1.3 Tester l’ajout et l’authentification
d’un utilisateur
Rimeh
Sondes
2 En tant qu’un utilisateur je
peux afficher mon profil.
2.1 Afficher un « user » dans le web API Sondes
2.2 Ajouter la méthode de la récupération
qui consommera le web services
Rimeh
2.3 Tester la récupération de profil
d’utilisateur
Rimeh
Sondes
3 En tant qu’un utilisateur je
peux supprimer mon profil.
3.1 Supprimer un « user » dans le Web
API
Sondes
3.2 Ajouter la méthode de suppression de
mon profil dans le contrôleur de
l’application client
Rimeh
3.3 Tester la suppression de compte Rimeh
Sondes
4 En tant que un utilisateur, je
peux modifier mon profil.
4.1 Modifier un « user » dans le Web API Rimeh
4.2 Ajouter la méthode de modification
de mon profil dans la partie client
Sondes
4.3 Tester la modification du compte Sondes
Rimeh
Tableau 5: Sprint Backlog du sprint 1
1.2. Prototypes d’interface
Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint
pour y mettre en évidence les fonctionnalités et bien les comprendre.

 Prototype de l’interface "s’authentifier"
Figure 18 : prototype de la page d’authentification
 Prototype de l’interface "créer compte" :
Figure 19 : prototype de la page « créer un compte »
2. Diagramme des cas d’utilisation du premier Sprint
La méthodologie basée sur le prototypage consiste à traiter des fonctionnalités. Il s’agira
pour nous de la collecte de différentes « users stories » sous une seule et unique
fonctionnalité.

Au début de chaque itération, on schématise la spécification fonctionnelle par un
diagramme de cas d’utilisation. Celle-ci permettra une vue d’ensemble du système et définira
les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose.
2.1. Classification des cas d’utilisation par acteur
Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur.
ACTEUR
CAS D’UTILISATION
Utilisateur
 Créer compte
 Afficher compte
 Mettre à jour compte
 Supprimer compte
 S’authentifier
Tableau 6 : classification des cas d'utilisation par acteur
La figure 20 illustre le diagramme de cas d’utilisation initiale du premier sprint.
L’utilisateur aura l'accréditation d’accéder à la plateforme en utilisant un login et un mot de
passe. Afin d’y parvenir, doit s’inscrire dans le but d’avoir un compte sur la plateforme.
Figure 20 : cas d’utilisation du premier sprint

2.2. Analyse des cas d’utilisation
Afin de mieux assimiler les cas d’utilisation, nous avons établi leurs raffinements pour
livrer une description sur les différents scénarios possibles.
Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque
user Case qui permet de mettre ensuite la création des diagrammes de séquence système
simple et facile.
2.2.1. Description textuelle du cas d’utilisation « s’authentifier »
Cas d’utilisation S’authentifier
Acteur Utilisateur
Précondition Le login et mot de passe sont corrects
Post condition L’utilisateur est authentifié
Description du scénario principal
1-L’utilisateur saisi son login et son mot de passe
2-Il clique sur le bouton « se connecter »
3-Le système vérifie les informations saisies par
l’utilisateur et affiche l’interface de la plateforme.
Exception Un message d’erreur est affiché si le login et/ou le
mot de passe sont erronés.
Tableau 7 : Description textuelle du cas d’utilisation « s’authentifier »
2.2.2. Diagramme de séquence système du cas « S’authentifier »

Figure 21 : diagramme de séquence système du cas « s'authentifier »
2.3. Analyse Du cas « Créer compte »
2.3.1. Description textuelle du cas d’utilisation « Créer compte »
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
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 »
2- Le système affiche les données dans un formulaire.

Tableau 9: Description textuelle du cas d'utilisation « Mettre à jour compte »
 Diagramme de séquence système du cas « Mettre à jour compte »
Figure 23 : Diagramme de séquence système du cas « Mettre à jour compte »
2.4.1.2. Analyse du cas d’utilisation « supprimer compte »
 Description textuelle du cas d’utilisation « supprimer compte »
3- L’utilisateur modifie les champs et clique sur
<<Modifier>>.
1- Le système enregistre les informations du profil.
Exception Un message d’erreur est affiché si le login existe déjà.
Un message d’erreur est affiché s’il y a des données
incorrectes ou/et manquantes.
Acteur Utilisateur
Précondition L’utilisateur doit être authentifié
Post condition Utilisateur supprimé

Tableau 10 : Description textuelle du cas « supprimer compte »
 Diagramme de séquence système du cas « supprimer compte »
Figure 24 : Diagramme du cas d'utilisation de « supprimer compte »
3. Conception des cas d’utilisation
Dans cette section, nous allons réaliser le diagramme de classes d’objets du premier
sprint.
3.1. Diagramme de classes du premier sprint : Gestion des comptes
La figure 24 illustre le diagramme de classes d’entités globales du premier sprint. Le
classe « utilisateur » est liée à la classe « compte » par une association du type 1, c’est-à-dire
qu’un compte peut n’appartient qu’à un seul utilisateur.
1- L’utilisateur clique sur le bouton « Mon compte »
2- Le système affiche les données dans un formulaire.
3- L’utilisateur clique sur <<Supprimer>>.
4- Le système supprime le compte.
Exception Pas d’exception

1
0..1
possède
utilisateur
-
-
-
-
-
-
-
-
id_utilisateur
nom
prenom
adresse
email
num_telphone
login
mot_de_passe
: String
: string
: String
: String
: String
: int
: String
: String
+
+
+
GetCurrentUser ()
createUser ()
DeleteUser ()
compte
-
-
login
password
: String
: String
+
+
+
GetCurrentUser ()
CreateUser ()
Deleate ()
Figure 25 : Diagramme de classe de premier sprint
3.2. Schéma de la base des données : Gestion du compte
Il n’existe pas encore de mode de représentation comme le diagramme ER pour les bases
documentaires mais on pourrait modéliser notre collection <<users>> de la façon suivante :
4. Implémentation
La phase d’implémentation, plus connue sous le nom de phase de développement
consistera à implémenter les "user stories" résultantes des phases précédentes.
Au cours du premier sprint, nous concevrons la structure de la base de données en se basant
sur les bases documentaires. Notre base du premier sprint est définie comme ci-dessous, Ce
qui nous donne par exemple un document user :
{ "_id" : ObjectId("574aa7f15c70661c06d15fdb"),
"nom" : "moussi",
"prenom" : "azouz",
"adresse" : "tunis",
"email" : "rimeh.moussi@gmail.com",
"numtelph" : "58888555",
"username" : "admin",
_id: String
Nom : String
Prénom : String
…
Document : user
Collection : users

"hash" : "$2a$10$WkCgivFIlxO3CQgMg0LayekJmh3V7Zfz.Em5yn1Cpiaj4.twq9DFi" }
Dans le cadre d’une application web du type Single Page Application (SPA) peut se poser
la problématique de l’authentification. Au-delà de l ‘identification HTTP, pour gérer
l’authentification d’un utilisateur on se basera sur ExpressJs pour le serveur et AngularJS pour
le client. Et pour assurer la sécurité de notre application nous avons utilisé de nouvelles
approches, l’authentification à base sur un jeton signé envoyé au serveur à chaque demande
c’est qu’on appelle le JWT [9] (JSON Web Token) et la fonction bcrypt [10] de node js pour
hacher le mot de passe de l’utilisateur.
5. Test
L’approche Agile considère les tests comme une phase cruciale des projets. Dans la
majorité des autres méthodes, les tests ne se front qu’après la fin du développement. Pour
Scrum et les méthodes agiles en général, les tests sont intégrés dans chacun des sprints
jusqu’à la livraison du produit final.
Donc, chaque sprint doit se terminer par l’indispensable phase de test. Ces tests sont les
seuls garants d’une version de qualité car ils permettent de vérifier les résultats obtenus lors
de l’étape de développement.
On effectuera quelques jeux d’essai pour tester les services web grâce à l’extension
Postman et on testera l’application elle-même.
 Test des services web
La méthode invoque un user.
Figure 26 : Test des services web (un user)

 L’interface de s’authentifier
Figure 27 : Page d'authentification
 L’interface de créer compte
Figure 28 : Page de créer compte

 L’interface de Gestion du compte
Figure 29 : Page de Gestion du Compte
Conclusion
Tout à long de ce chapitre, nous avons réussi à réaliser notre premier sprint « Gestion du
compte» l’analysé et pu développer. Dans le prochain chapitre, notre effort sera focalisé sur la
réalisation de notre deuxième sprint « Gestion des centres des services ».

Chapitre 4 : Sprint 2 - Sprint Gestion des centres des services
Dans ce chapitre, nous allons présenter notre deuxième sprint. A l’issue de ce dernier
nous avons donc obtenu une deuxième version de notre application.
Ce chapitre correspond à la tous ce qui est mise à jour à faire sur les établissements,
les agences et les services.
Nous étudions en premier temps la spécification fonctionnelle. En second temps la
conception détaillée et enfin la réalisation.
Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein
de ce sprint.
1.1.Backlog Product
Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de
ce sprint :
1
En tant qu’un utilisateur, je peux
ajouter un établissement
1.1 Ajouter un « établissement » dans
le web API
Rimeh
l’affectation dans le contrôleur de
l’application client.
Sondes
1.3 Tester l’ajout d’un établissement Rimeh
Sondes
2 2.1 Afficher les « établissements » Sondes

En tant qu’un utilisateur je peux
afficher les établissements.
dans le web API
2.2 Ajouter la méthode de la
récupération qui consommera le
web services
Rimeh
2.3 Tester la récupération des
établissements
Rimeh
Sondes
3
supprimer un établissement.
3.1 Supprimer un « établissement »
dans le Web API
Sondes
3.2 Ajouter la méthode de suppression
d’un établissement dans le
contrôleur de l’application client
Rimeh
3.3 Tester la suppression d’un
établissement
Rimeh
Sondes
4
En tant que un utilisateur, je peux
modifier un établissement.
4.1 Modifier un « établissement » dans
le Web API
Rimeh
4.2 Ajouter la méthode de
modification d’un établissement
dans la partie client
Sondes
4.3 Tester la modification d’un
établissement
Sondes
Rimeh
5
ajouter une agence à un
5.1 Ajouter une « agence » dans le web
API
Sondes
Rimeh

établissement déterminé. 5.3 Tester l’affectation d’une agence. Rimeh
Sondes
6
afficher toutes les agences ou bien
les agences d’un établissement.
6.1 Afficher les « agences » dans le
web API
Sondes
6.2 Ajouter la méthode de la
récupération qui consommera le
web services
Rimeh
6.3 Tester la récupération des agences Sondes
Rimeh
7 En tant qu’un utilisateur je peux
supprimer une agence.
7.1 Supprimer une « agence » dans le
Web API
Sondes
7.2 Ajouter la méthode de suppression
d’une agence dans le contrôleur de
Rimeh
7.3 Tester la suppression d’une agence Sondes
Rimeh
8
modifier une agence
8.1 Modifier une « agence » dans le
Web API
Sondes
8.2 Ajouter la méthode de
modification
d’une agence dans le contrôleur de
Rimeh
8.3 Tester la modification d’une
agence
Rimeh
Sondes

9
ajouter un service à un
établissement et l’affecter à des
agences.
9.1 Ajouter un « service » dans le web
API
Sondes
Rimeh
9.3 Tester l’ajout d’un service Sondes
Rimeh
10 En tant que un utilisateur, je peux
lister tous les services, les services
d’un établissement ou bien d’une
agence donnée.
10.1 Afficher les « services » dans le
web API
Sondes
l’affichage dans le contrôleur de
Sondes
Rimeh
10.3 Tester la récupération des services. Sondes
11
modifier service.
11.1 Modifier le « service » dans le web
API
Rimeh
11.2 Ajouter les fonctionnalités de la
modification dans le contrôleur de
Sondes
11.3 Tester la modification d’un service. Rimeh
Sondes
12
supprimer un service à partir de la
liste des services, d’une agence ou
bien d’un établissement.
12.1 Supprimer le « service » dans le
web API
Sondes
12.2 Ajouter les fonctionnalités de la
suppression dans le contrôleur de
Rimeh

12.3 Tester le cas de la suppression
service.
Rimeh
Sondes
Tableau 11 : Backlog du second sprint
1.2. Prototypes des interfaces
Pour bien assimiler ces « user stories », voici quelques prototypes des interfaces avant de
commencer la phase d’analyse.
 Prototype de l’interface "créer un établissement"
Figure 30 : prototype d'interface ajouter un établissement
 Prototype de l’interface "supprimer une agence"
Figure 31 : prototype d'interface supprimer une agence

 Prototype de l’interface "modifier un service"
Figure 32 : prototype d'interface modifier un service
2. Diagramme de cas d'utilisation du second sprint
Une fois nous avons défini notre Backlog su sprint, on va traiter des fonctionnalités.
Alors on va collecter plusieurs « users stories » en une fonctionnalité bien déterminée.
2.1. Classification des cas d’utilisation par acteurs
ACTEUR
CAS D’UTILISATION
Utilisateur
 Créer un établissement
 Créer une agence
 Créer un service
 Afficher la liste des établissements
 Afficher la liste des agences
 Afficher la liste des services
 Modifier établissement
 Modifier agence
 Modifier service
 Supprimer établissement
 Supprimer agence
 Supprimer service
Tableau 12 tableau de répartition de second sprint
2.2. Diagramme de cas d’utilisation du deuxième sprint

Figure 33 : Diagramme de cas d'utilisation globale de sprint 2
3. Analyse des cas d'utilisation
3.1. Analyse des cas d'utilisation « gérer établissement»
3.1.1. Raffinement du cas d’utilisation «gérer établissement»
Figure 34 : diagramme du cas d'utilisation du cas gérer établissement
3.1.2. Description textuelle du cas « gérer établissement»
Cas d’utilisation Gérer établissement
Acteur Utilisateur
Précondition Utilisateur doit être authentifié et a choisi

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

1..*
1..*
1..1
1..*
établissement
-
-
id_établissement
libelle
: int
: String
+
+
getLibelle ()
setLibelle ()
: String
: void
agence
-
-
-
id_agence
libelle
adresse
: String
: String
: String
+
+
+
+
getLibelle ()
getAdresse ()
setLibelle ()
setAdresse ()
: String
: String
: void
: void
service
-
-
id_service
libelle
: int
: String
+
+
+
getLibelle ()
setLibelle ()
getID ()
: String
: void
: int
Figure 43 : Diagramme de classe globale de sprint 2
5.2. Schéma de la base des données : Gestion des centres des services
On pourrait modéliser notre collection <<établissement>> de la façon suivante :
_id: String
Libellee: String
Agence :{
_id : String
Libellee: String
Addressee: String
Service :{
_id : String
Libellee: String
}
}
….
Document : établissement
Collection : établissements

6. Implémentation
 Schéma de la base de données « Etablissement »
{
"_id" : ObjectId("57547e94cb215c188a69944c"),
"libelleEtb" : "CNAM",
"agence" : [ { "libelleAgn" : "CNAM Tunis 3",
"adresse" : "17 Rue Abderrahmane El Jaziri, Tunis 1002, Tunisie",
"service" : [ "Bulletin de remboursement de frais de soins", "Demande de changement
de filiere", "Demande de choix de médecin de famille" ]
}
7. Test
 Test des services web
Cette méthode invoque la liste des établissements
Figure 44 : Test des services web (la liste des établissements)
 Interface créer établissement

Figure 45 : interface «créer établissement»
 Interface liste établissements
Figure 46 : interface «liste établissements»
 Interface Modifier établissement

Figure 47 : interface «Modifier établissement»
 Interface Supprimer établissement
Figure 48 : interface «Supprimer établissement»
 Interface liste des agences par établissement

Figure 49 : interface «liste des agences par établissement»
 Interface liste des services par agence

Figure 50 : interface «liste des services par agence»
Conclusion
A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment
de valeur pour le client.
Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau sprint couvrant
les fonctionnalités de «Statistiques».

Chapitre 5 : Sprint 3 - Statistiques
Dans le chapitre précédent, nous avant présentait notre deuxième sprint. A l’issue de
ce sprint nous avons donc obtenu une deuxième version de notre application.
Ce chapitre correspond à la tous ce qui est statistiques à faire sur l’application.
Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception
détaillée et enfin la réalisation.
Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein
de ce sprint.
1.1. Backlog Product
Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de
ce sprint :
1
En tant qu’un utilisateur, je
peux consulter le nombre des
agences par établissement.
1.1
Ajouter les fonctionnalités dans le
contrôleur de l’application client.
Rimeh
1.2 Tester l’affichage des graphiques Sondes
En tant qu’un utilisateur je
2.1 Ajouter la méthode dans le contrôleur
de l’application client.
Sondes

2 peux afficher le nombre des
services par établissement.
2.3 Tester la méthode. Rimeh
3
En tant qu’un utilisateur je
peux afficher le nombre des
services par agence.
3.1
3.2
Ajouter la méthode dans le contrôleur
de l’application client
Rimeh
3.3 Tester les fonctionnalités. Sondes
Tableau 16: Backlog du troisième sprint
1.2. Prototypes d’interfaces
Pour bien assimiler ces « user stories », voici quelques prototypes d’interfaces avant de
commencer la phase d’analyse.
 Prototype de l’interface " afficher statistiques"
Figure 51 : prototype d'interface «afficher statistiques »
2. Diagramme de cas d'utilisation du troisième sprint
les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose. Classification
des cas d’utilisation par acteurs.

2.1. Classification des cas d’utilisation par acteurs
ACTEUR
CAS D’UTILISATION
Utilisateur
 Afficher le nombre des agences par
établissement
 Afficher le nombre des services par
établissements
 Afficher le nombre des services par
agence.
Tableau 17: tableau de répartition de troisième sprint
2.2. Diagramme de cas d’utilisation du troisième sprint
Figure 52 : Diagramme de cas d'utilisation globale de sprint 3
2.3. Analyse Du cas «« afficher statistiques» :
Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque
user Case qui permet de mettre ensuite la création des diagrammes de séquence système
simple et facile.
 Description textuelle du cas « afficher statistiques »
Cas d’utilisation afficher nombre des agences par établissement
Acteur Utilisateur
Précondition
Utilisateur doit être authentifié et a choisi
l’option « statistiques»
Post condition Afficher les statistiques

1-L’utilisateur clique sur le bouton statistiques
2-Il choisi un lien
3-Le système affiche la page des statistiques
selon le lien choisi.
Tableau 18 : Description textuelle du cas « afficher statistiques »
 Diagramme de séquence système du cas « afficher statistiques »
Figure 53: Diagramme de séquence système du cas « afficher statistiques »
3. Conception de cas d'utilisation « Afficher statistiques » :
Nous nous intéressons dans cette partie aux diagrammes de classes et aux diagrammes
séquence détaillées du troisième sprint.

3.1. Diagramme de classe
1..*
1..*
1..1
1..*
établissement
-
-
id_établissement
libelle
: int
: String
+
+
getLibelle ()
setLibelle ()
: String
: void
agence
-
-
-
id_agence
libelle
adresse
: String
: String
: String
+
+
+
+
getLibelle ()
getAdresse ()
setLibelle ()
setAdresse ()
: String
: String
: void
: void
service
-
-
id_service
libelle
: int
: String
+
+
+
getLibelle ()
setLibelle ()
getID ()
: String
: void
: int
Figure 54: diagramme de classe de de cas d’utilisation « Afficher statistiques »
3.2. Diagramme de séquence détaillé du cas d'utilisation « Afficher
statistiques »
Figure 55: Diagramme de séquence détaillé du cas d'utilisation « Afficher statistiques »

4. Implémentation
 Schéma de la base des données : Statistiques
On pourrait utiliser notre collection <<établissement>> que nous avons déjà présenté dans le
sprint précédent.
5. Test
 Interface le nombre des agences par établissement
Figure 56: Interface le nombre des agences par établissement
 Interface le nombre des services par établissement

Figure 57: Interface le nombre des services par établissement
 Interface le nombre des services par agence
Figure 58: Interface le nombre des services par agence
Conclusion
Lors de ce sprint, on a analysé, conçu et pu développer les fonctionnalités de troisième
sprint qui nous permet d’étudier les statistiques des établissements, des agences et des
services.
Dans le prochain sprint, on fera le sprint mobile.

Chapitre 6 : Sprint 4 - Sprint Mobile
Dans le chapitre précédent, nous avant présentait notre troisième sprint.
Ce chapitre correspond à la toux ce qui est mise à jour à faire sur l’application mobile.
Nous étudions en premier temps la spécification fonctionnelle. En second temps la conception
détaillée et enfin la réalisation.
Le tableau ci-dessous regroupe toutes les fonctionnalités qui vont être développées au sein de
ce sprint.
1. Spécifications fonctionnelles
Au sein de ce sprint, Les user stories va passer par les quatre étapes du cycle Scrum, plus
précisément, l’analyse, la conception, le développement et on achève les tests.
1.1. Sprint Backlog
Le tableau ci-dessous regroupe toutes les fonctionnalités qui seront développées au sein de ce
sprint :
ID
User story
User Story ID
Tâche
Tâche Affectation
1 En tant que client, je
veux consulter la liste
des établissements.
1.1 Réaliser les diagrammes de cas
d’utilisation, de séquence système, de
classe, de séquence détaillée du cas «
Consulter établissement »
Rimeh MOUSSI
1.2 Développer le cas «Consulter
établissement»
Rimeh MOUSSI
1.3 Tester le cas «Consulter
établissements»
Sondes JAMI

des services d’un
établissement donné.
Consulter service »
Sondes JAMI
1.2 Développer le cas «Consulter service» Sondes JAMI
1.3 Tester le cas «Consulter service» Rimeh MOUSSI
des agences ayant un
service donné et ma
position dans maps.
Consulter agence dans le maps »
Rimeh MOUSSI
1.2 Développer le cas «Consulter agence» Sondes JAMI
1.3 Tester le cas «Consulter agence» Rimeh MOUSSI
veux réserver un ticket
et faire la notification
de tour
classe, de séquence détaillée du cas
«Réservation un ticket »
Sondes JAMI
1.2 Développer le cas «Réserver ticket» Rimeh MOUSSI
1.3 Tester le cas «Réserver ticket» Sondes JAMI
Tableau 19: Backlog du quatrième sprint
1.2. Prototype d’interface
Dans cette section, nous allons illustrer quelques prototypes des interfaces de ce sprint
pour y mettre en évidence les fonctionnalités et bien les comprendre.

Affiche la liste des
établissements,
Puis, le client sélectionne
un parmi cette liste
Affiche la liste des services
d’un établissement
sélectionné
Affiche la liste des
agences les plus
proches dans maps
Affiche le ticket et les
informations avec le
QR Code.
Après la réservation,
remplir le formulaire de
la notification de tour.
Figure 59: prototype des interfaces mobile

2. Diagramme des cas d’utilisation du quatrième Sprint
les liens et interactions entre les utilisateurs et les fonctionnalités qu’il propose.
2.1. Classification des cas d’utilisation par acteur
Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur.
Acteur Cas d’utilisation
Client
Réserver ticket
Tableau 20 : Classification des cas d'utilisation par acteur
2.2. Diagramme de cas d’utilisation du quatrième sprint
Figure 60: Diagramme de cas d'utilisation du quatrième sprint
2.2.1. Analyse Du cas « Réserver ticket» :
Ces descriptions textuelles ont permis de dessiner les scénarios d’exécution de chaque user
Case qui permet de mettre ensuite la création des diagrammes de séquence système simple et
facile.
 Description textuelle du cas «Réserver ticket»

Cas d’utilisation Réserver ticket
Acteur Client
Pré condition Etablissement inscrit dans la plateforme
Post condition Ticket réservé
Description 1. Le client choisi l’établissement
2. Le client choisi un service d’un établissement donné
3. Le client choisi une agence qui existe dans maps.
4. Le client réserve un ticket
5. Le client faire la notification de tour.
Exception Problème de connexion réseau
Tableau 21 : Description textuelle du cas «Réserver ticket»

 Diagramme de séquence système du cas « Réserver ticket »
Figure 61: Diagramme de séquence du cas " réserver ticket"
3. Conception
3.1. Diagramme de classe
réserver
1..1
1..1
ticket
-
-
id_ticket
QrCode
: int
: String
+
+
ticket ()
toString ()
: void
: String
client
- emailClient : String
+
+
+
+
getEmail ()
setEmail ()
client ()
toString ()
: String
: void
: void
: String
Figure 62: diagramme de classe de quatrième sprint

4. Implémentation
Notre base est définie comme ci-dessous, Ce qui nous donne par exemple un
document agence :
{ "_id" : ObjectId("574ad27c3ea0f78f78f2d556"),
"libelleAgn" : "Siège social CNSS",
"adresse" : "49 Avenue Taieb M'Hiri, Tunis 1002, Tunisie",
"IDetablissement" : "5743f48156fa1b72d9dc3d4d",
"ticket_en_cours" : 2,
"der_ticket_reserv" : 14,
"emailClient " : "jamisondes1994@gmail.com"
}
5. Test
 Interface test de service web
 Interface page d’accueil (Android & Ios) :

Figure 63: interface «page d'accueil »

 Interface liste établissement
Figure 66: interface liste établissement
 Interface liste services
Figure 64: interface liste service
 Interface liste des agences dans maps
Figure 58 : interface liste agence
Figure 65: interface liste agence

Les options dans notre application
 Interface météo
Figure 67: interface météo

 Interface information générale de l’application
Figure 68: Interface information générale de l’application

 Interface les détails concernant chaque agence, la réservation

Conclusion
Dans ce chapitre nous avons présenté et détaillé les différentes phases de sprint «
Mobile » tels que la spécification fonctionnelles, les diagrammes, implémentation et test.
A ce stade nous avons réussi à concevoir et développer un produit complet et fonctionnel.

Chapitre 7 : Phase de clôture
Introduction
Dans ce dernier chapitre, nous allons présenter la phase ultime de notre cycle de
développement avec Scrum qui s’intitule : phase de clôture plus connue sous le nom de sprint
de stabilisation. Il s’agira de définir les différents outils technologiques et l’environnement de
développement auxquels nous avons eu recours.
Ensuite, nous présenterons une schématisation des différentes tâches effectuées au cours de
notre stage.
1. Environnement de développement
1.1. Environnement matériel
Voici les caractéristiques techniques des machines que nous avons utilisées :
Ordinateur
Propriétaire Sondes JAMI Rimeh MOUSSI
Processeur Core i3 Core i3
Ram 6 Go 4 Go
Disque Dur 500 Go 500 Go
Système d’exploitation Windows 7 Professional 64-bit Windows 7 Professional 64-bit
Tableau 22: Environnement matériel

1.2. Environnement logiciel
Rédaction du rapport :
Word : est un logiciel de traitement de texte qui permet de taper
des textes, ajouter des images, des graphiques, insérer des tableaux
avec des multiples choix de polices et de conception
Base des données :
MongoDB : est un système de base de données dans la
mouvance No SQL. Il est orienté documents. Son nom vient
de Humongous qui veut dire énorme ou immense. L'objectif est
donc de pouvoir gérer de grandes quantités de données.
Robomongo : est un exemple notable d'application cliente de
gestion de ce système de gestion de base de données NO SQL, et
un client graphique disponible pour toutes les plateformes.
Conception :
PowerAMC : est un logiciel de modélisation (modeleur) de
Sybase. En 2006, il inclut les modélisations de bases de données
(MPD, MCD), UML, modélisation de traitements Merise (MCC,
MOT, MCT) et modélisation de processus métier.
Test :
Postman : C’est un outil puissant de test des services web,
devenu un outil incontournable pour de nombreux développeurs.

Rapport stage pfe

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Rapport stage pfe

Ähnlich wie Rapport stage pfe (20)

Rapport stage pfe