File Attente Finale

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Stage de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National de Licence Appliqué en Sciences et Technologies

Spécialité : Systèmes Informatiques et Logiciels
Par
Ikram YAHMADI et Siwar TLILI
Développement d’un outil de gestion des files

d’attente
Encadrant professionnel : Monsieur Ali TABBABI
Encadrant académique : Monsieur Riadh ZAAFRANI
Réalisé au sein de SFM Technologies
Année Universitaire 2018 - 2019

République Tunisienne
Ministère de l’Enseignement Supérieur

et de la Recherche Scientifique
Université de Tunis El Manar
Institut Supérieur d’Informatique d’El Manar
Rapport de Projet de Fin d’Études
Présenté en vue de l’obtention du
Diplôme National de Licence Appliqué en Sciences et Technologies

Spécialité : Systèmes Informatiques et Logiciels
Par
Ikram YAHMADI et Siwar TLILI
Développement d’un outil de gestion des files

d’attente
Encadrant professionnel : Monsieur Ali TABBABI
Encadrant académique : Monsieur Riadh ZAAFRANI
Réalisé au sein de SFM Technologies
Année Universitaire 2018 - 2019

Dédicaces
Siwar
A mes chers parents qui ont cru en moi et m’ont toujours soutenu dans les périodes les plus
difficiles de ma vie, pour leurs dévouements et leurs amours inconditionné pour faire de moi la
personne que je suis aujourd’hui.
A ma sœur et mon frère qui n’ont cessé de croire en moi et de me soutenir. A toutes les personnes
qui ont croisé mon chemin.
A mes chers amis qui me procurent beaucoup de joie et de sympathie, je tiens à leur dédier cet
humble travail, le fruit de mes efforts et de mes sacrices pendant toutes ces années d’études..
Enfin, merci à tous ceux qui, de près ou de loin, m’ont épaulée durant ma jeunesse et mes études,
aucun mot n’exprimera ma profonde gratitude pour tout l’amour, Le soutien, les sacrifices et la
confiance qu’ils me font.
Ikram
A mes parents, qui m’ont élevée, qui m’ont toujours dirigée vers le chemin de la réussite.
A ma sœur qui m’a soutenue dans toutes mes aventures, qui me donne l’énergie d’avancer dans la
bonne direction. Je ne la remercierai jamais assez pour tous ses efforts quotidiens, que Dieu lui
procure santé et longue vie.
A mes amis et mes collègues Pour leur encouragement et pour tous les bons moments qu’on a
vécus ensemble, j’espère qu’ils puissent trouver dans ce modeste travail un témoignage d’amour et
d’affection envers eux.
i
Remerciements
C’est avec un grand plaisir que nous réservons ces lignes en signe de gratitude et de reconnaissance
à tous ceux qui ont contribué de prés ou de loin à l’élaboration de ce travail.
Nos gratitudes et nos reconnaissances s’adressent à notre encadrant académique Monsieur Riadh
Zaafrani pour son encadrement, son dévouement, son soutien, sa disponibilité et ses conseils qui
nous ont guidés tout au long de ce stage.
Nos remerciements s’adressent également à notre tuteur de stage Monsieur Ali Tababi pour
tout le temps qu’il nous a consacré, ses directives précieuses et pour la qualité de son suivi durant
la période de notre stage.
Enfin une pensée particulière à tous nos enseignants de l’ISI et à tous ceux qui ont participé
à notre formation. Qu’ils trouvent ici l’expression de notre gratitude et de notre profond respect.
ii
Table des matières
Introduction générale 1
1 Planification et spécification des besoins 3

1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Présentation générale de SFM Télécom . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Organigramme fonctionnel de SFM . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.3 Les activités de SFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 principe de la méthodologie agile « Scrum » . . . . . . . . . . . . . . . . . . . 9
1.5.3 Justification de choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Analyse et Spécification des besoins 11

2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 L’équipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Sprint 0 : Mise en place de l’environnement matériel et logiciel 20

3.1 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
iii
3.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.3 Architecture applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 Système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.4 Editeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.5 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.6 Installation et paramétrage général de l’environnement de
développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Sprint 1 : Authentification, création et modification des comptes et gestion des

utilisateurs et des groupes d’utilisateurs 31
4.1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Diagramme du cas d’utilisation raffiné « S’authentifier » . . . . . . . . . . . 33
4.2.2 Diagramme du cas d’utilisation raffiné « Créer Compte » . . . . . . . . . . . 34
4.2.3 Diagramme de cas d’utilisation raffiné « Gérer compte » . . . . . . . . . . . 36
4.2.4 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs et groupes» . . . 37
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1 Digramme d’activité global du premier sprint . . . . . . . . . . . . . . . . . . 40
4.3.2 Diagramme de séquence illustrant le cas d’utilisation «s’authentifier» . . . . . 40
4.3.3 Diagramme de séquence « Modification des comptes » . . . . . . . . . . . . . 41
4.3.4 Diagramme de séquence « Désactiver comptes » . . . . . . . . . . . . . . . . 42
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Sprint2 : Gestion des informations des agences, Consultation des historiques des
réservations et des agences et visualisation des statistiques 51
5.1 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
iv
5.2 Spécication fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Diagramme du cas d’utilisation du deuxième sprint . . . . . . . . . . . . . . . 53
5.2.2 raffinement du sous cas d’utilisation «gérer des nomenclatures» . . . . . . . . 54
5.2.3 Description du sous cas d’utilisation « ajouter type nomenclature» . . . . . . 54
5.2.4 Description du sous cas d’utilisation « consulter historique des réservations» . 56
5.2.5 Description textuelle du cas d’utilisation «consulter des statistiques» . . . . . 56
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.2 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 «sprint3 » Mise en place de la partie mobile 65

6.1 Backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.1 Diagramme du cas d’utilisation détaillé du troisième sprint . . . . . . . . . . 67
6.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.4 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Conclusion générale 84
Bibliographie 85
Annexes 86
v
Table des figures
1.1 Organigramme fonctionnel SFM Telecom . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Groupe SFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Zones d’intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 étude comparative entre les solutions existantes . . . . . . . . . . . . . . . . . . . . . 8
1.5 Le processus Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 logo de Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 logo ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 logo de mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 commande d’installation de symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 création du projet symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 installation et configuration du Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 vérification de l’installation du Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11 Installation d’ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.12 création du projet ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Diagramme du cas d’utilisation raffiné « S’authentifier » . . . . . . . . . . . . . . . . 33

4.2 Diagramme raffinné du cas d’utilisation « Créer Compte » . . . . . . . . . . . . . . 34
4.3 Diagramme raffiné du cas d’utilisation « Gérer Compte » . . . . . . . . . . . . . . . 36
4.4 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs et groupes » . . . . . . . . 37
4.5 diagramme d’activité global du premier sprint . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Diagramme de séquence du cas d’utilisation « S’authentifier » . . . . . . . . . . . . 41
4.7 Diagramme de séquence du cas d’utilisation « Modification des comptes » . . . . . . 42
4.8 Diagramme de séquence du cas d’utilisation « Désactiver compte » . . . . . . . . . . 42
4.9 Formulaire d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
vi
Table des figures
4.10 données invalides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.11 changement de mot de passe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.12 Validation de changement de mot de passe . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 changement de la photo de profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.14 Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.15 Gestion des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.16 interface d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.17 Interface d’authentification : utilisateur existant . . . . . . . . . . . . . . . . . . . . . 47
4.18 Interface d’authentification : utilisateur inexistant . . . . . . . . . . . . . . . . . . . . 47
4.19 Interface de création d’un compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.20 Interface profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.21 Test d’authentification d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Diagramme du cas d’utilisation raffiné du deuxième sprint . . . . . . . . . . . . . . . 53

5.2 raffinement du sous cas d’utilisation «gérer des nomenclatures» . . . . . . . . . . . . 54
5.3 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 Diagramme de séquence du cas d’utilisation « Consulter historique » . . . . . . . . . 59
5.5 création du bundle Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.6 génération de l’entité TypeNomenclature . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.7 gestion des Types nomenclatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.8 gestion des valeurs nomenclatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.9 interface de gestion des adresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.10 interface de gestion des municipalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.11 interface graphique des statistiques visualisées . . . . . . . . . . . . . . . . . . . . . . 62
5.12 interface graphique des statistiques visualisées 2 . . . . . . . . . . . . . . . . . . . . . 62
6.1 Diagramme de cas d’utilisation détaillé du troisième sprint . . . . . . . . . . . . . . 67

6.2 Diagramme de séquence Effectuer reservation . . . . . . . . . . . . . . . . . . . . . . 72
6.3 Diagramme de séquence Réchercher les agences . . . . . . . . . . . . . . . . . . . . . 73
6.4 Interface de page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.5 Interface charger liste agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6 Interface consulter liste agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
vii
6.7 Interface recherche en cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.8 Interface résultat recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.9 Interface information agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.10 Interface choisir horraire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.11 Interface choisir horraire 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.12 Interface de Ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.13 Interface de profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.14 Géolocaliser agence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
viii
Liste des tableaux
2.1 Identication des acteurs et leurs rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Backlog des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 plannification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . 34
4.3 Description textuelle du cas d’utilisation « Créer un compte» . . . . . . . . . . . . . 35
4.4 Description du cas d’utilisation « Modifier compte » . . . . . . . . . . . . . . . . . . 36
4.5 Description du cas d’utilisation « Désactiver compte » . . . . . . . . . . . . . . . . . 37
4.6 Description textuelle du cas d’utilisation «Ajouter des utilisateurs et des groupes » . 38
4.7 Description textuelle du cas d’utilisation «Supprimer des utilisateurs et des groupes » 38
4.8 Description textuelle du cas d’utilisation «Modifier des utilisateurs et des groupes » . 39
4.9 Tableau des scénarios des tests fonctionnels relatifs au Sprint 1 . . . . . . . . . . . . 50
5.1 Backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Description du sous cas d’utilisation « Ajouter type nomenclature» . . . . . . . . . . 54
5.3 Description du sous cas d’utilisation « Modifier type nomenclature» . . . . . . . . . 55
5.4 Description du sous cas d’utilisation « Supprimer type nomenclature» . . . . . . . . 55
5.5 Description textuelle du cas d’utilisation « consulter historique » . . . . . . . . . . . 56
5.6 Description textuelle du cas d’utilisation «consulter des statistiques» . . . . . . . . . 57
5.7 Scénarios de test Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2 Description textuelle du cas d’utilisation « Effectuer une recherche des agences » . . 68
6.3 Description textuelle du cas d’utilisation « Effectuer une reservation » . . . . . . . . 68
6.4 Description textuelle du cas d’utilisation «Annuler une reservation » . . . . . . . . . 69
6.5 Description textuelle du cas d’utilisation « Reporter une reservation » . . . . . . . . 69
6.6 Description textuelle du cas d’utilisation « Géolocaliser agence» . . . . . . . . . . . . 70
6.7 Description textuelle du cas d’utilisation « Consulter des notifications» . . . . . . . . 70
6.8 Description textuelle du cas d’utilisation « Saisir réclamation» . . . . . . . . . . . . . 71
ix
Liste des tableaux
6.9 Tableau des scénarios des tests fonctionnels relatifs au Sprint 3 . . . . . . . . . . . . 82
x
Liste des abréviations
— API = Application Programming Interface
— BD = Base de Données
— CSS = Cascading Style Sheets
— CSS = Modèle Vue Contrôleur
— HTML = HyperText Markup Language
— HTTP = Hypertext TransferProtocol
— IHM = Logiciel et Systèmes d’Information
— MoSCoW= Must Should Could Won’t
— PO = Product Owner
— UML = Unified Modeling Language
xi
Introduction générale
Nous sommes dans un monde de plus en plus connecté, de plus en plus relié aux outils
informatiques. A vrai dire ces outils sont devenus incontournables voir obligatoires dans
certains domaines. Etant donné la forte croissance du marché des applications web et mobiles,
on assiste à un intérêt croissant de la part des utilisateurs à ce genre d’applications et à leur
diversification couvrant tout type de service et tout type de besoin.
C’est dans ce cadre que s’inscrit notre projet au sein de Services for Fixe and Mobile
Télécommunications SFM qui consiste en la conception et l’implémentation d’un outil de gestion
des files d’attente permettant de décharger les administrations de longues files d’attente et de faire
gagner du temps aux usagers .
Ce présent rapport décrit le travail réalisé, il comporte six chapitres structurés comme suit :
le premier chapitre est un chapitre introductif illustrant le contexte général de notre projet :
description du cadre de notre projet, présentation de l’organisme d’accueil, énonciation de la problématique,
le contexte métier de notre projet, une étude de l’existant accompagnée d’une critique pour aboutir
à la définition de la solution proposée.
Dans le deuxième chapitre, nous commençons par la capture des besoins, nous présentons
ensuite la méthodologie Scrum que nous avons adopté, puis nous décrivons le backlog du produit et le
diagramme du cas d’utilisation global de notre futur système, et nous finissons par une planification
des sprints.
Dans le troisième chapitre intitulé « Sprint 0 » décrit l’environnement matériel et logiciel

du projet. Nous détaillons, dans ce chapitre, l’environnement de développement et l’architecture du
système.
Les trois derniers chapitres se focalisent sur l’étude et la réalisation des sprints de notre
projet. Dans chaque sprint, nous commençons par le « Backlog du Sprint »qui décrit les tâches
1
Introduction générale
à faire, ensuite nous présentons le diagramme de classes et les diagrammes de séquences tout en
illustrant l’exécution de notre application par des captures d’écran.
Nous clôturons ce rapport par une conclusion générale dans laquelle nous reviendrons sur
les atouts majeurs de notre application tout en évoquant les perspectives qui peuvent étendre notre
projet.
2
Chapitre 1
Planification et spécification des

besoins
Plan
1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 4
2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 solution envisagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Choix méthodologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1. Planification et spécification des besoins
Introduction
Dans ce chapitre introductif, nous allons présenter l’organisme d’accueil SFM dans lequel nous
avons effectué notre stage de projet de fin d’études. Ensuite, on introduira le sujet et on abordera
la problématique ainsi que la solution proposée. On finira par la présentation de la méthodologie de
travail adoptée lors de la réalisation du projet tout en argumentant notre choix.
1.1 Présentation de l’organisme d’accueil
Nous allons commencer par une présentation de la société d’accueil et de ses secteurs
d’activités
1.1.1 Présentation générale de SFM Télécom
SFM Telecom [1] (Services for Fixe and Mobile Télécommunications Network and System),
membre de I’ITU-D (SFM TECHNOLOGIES, SFM INTERNATIONAL, SFM TELECOM et SFM
CAMEROUN), est un cabinet d’ingénierie et d’expertise en réseaux de télécommunications et
technologies de l’information. Il a été créé en 1995 par un groupe d’ingénieurs, consultants et
spécialistes opérant en Afrique, Asie, Europe, État Unis et Océanie. Ses principaux clients sont le
ministère des télécommunications, les opérateurs des réseaux, les régulateurs des télécommunications
et les agences de fréquences.
1.1.2 Organigramme fonctionnel de SFM
SFM Télécom [1] a une organisation hiérarchique simple et claire. Son Organigramme se
présente comme le montre la figure 1.1 ci-dessous
4
Figure 1.1: Organigramme fonctionnel SFM Telecom
Figure 1.2: Groupe SFM
Figure 1.3: Zones d’intervention
5
1.1.3 Les activités de SFM
Les activités de SFM [1] sont organisées autour de quatre axes :

A. Expertise technique :
SFM apporte et transfère son expertise aux régulateurs, autorités et opérateurs de télécommunications
sous plusieurs formes :
• Audit et Benchmark de qualité de service des réseaux mobiles.
• Planification, Dimensionnement, et Optimisation des réseaux Mobiles.
• Expertise et Ingénierie relative à la Fibre Optique.
• Analyse du trafic.
• Gestion et contrôle du spectre.
• Tarification des services.
B. Conseil Stratégique :
SFM réalise des études stratégiques pour les comptes des Ministères, les Directions Générales
d’Opérateurs et aussi pour les Présidences d’Autorités de Régulation dans le cadre d’actions de
restructuration, de réglementation du secteur, de tarification des ressources rares, de migration vers
des nouvelles architectures ou technologies (2G/ 3G/ 3G+/ LTE, WiMax, NGN, etc.), de vente de
licences, d’ouverture de capital, de prise de participation, etc.
C. Recherche et Développement :
SFM, par son équipe qui intègre des chercheurs universitaires, a engagé des projets, de recherche et
de développement, qui lui permettent de rester à la pointe des nouvelles technologies.
C’est ainsi que les modèles de propagation, les modèles d’interconnexion, les outils d’analyse du
trafic, les techniques d’analyse de la QoS, les outils de mesure terrain de la QoS, sont autant de
domaines faisant l’objet des travaux en partenariat avec l’université et dont bénéficient les clients
de SFM que ce soit pendant les formations ou au cours des missions.
SFM a développé des outils dans le cadre de son laboratoire SFM Lab, dédié à la recherche et au
développement de nouvelles solutions, dont l’objet est de répondre aux besoins évolutifs des clients.
6
D. formation :
SFM propose des formations sur mesure à très forte valeur ajoutée. Dans ses locaux, sur le terrain ou
chez ses clients, elle organise périodiquement des missions de formation sur les techniques de mesure
de la QoS.
1.2 Problématique
L’attente avant d’être servi dans un guichet pour obtenir un service ou un document, constitue
un réel problème récurrent aussi bien pour les administrations que pour les bénéficiaires des services.
Génératrice d’une insatisfaction forte, elle focalise la perception des clients sur l’organisation. À
terme, elle induit également un fort risque commercial face à une clientèle de moins en moins
réceptive, obligée de se mettre dans d’interminables rangées dans des locaux pas forcément aménagés
par un grand nombre de personnes C’est ainsi que la gestion des files d’attentes au sein des administrations
répondrait à un vrai besoin des usagers ,en leur offrant la possibilité d’effectuer une réservation a
distance et de géolocaliser les différentes administrations offrant le service se situant à proximité de
l’emplacement du client.
1.3 Etude et critique de l’existant
Afin d’atteindre les objectifs du projet, l’étude du système existant et des différents moyens
qui seront mis à notre disposition est une étape importante pour le bon déroulement du projet. En
effet elle permet d’abord de décortiquer les fonctionnalités existantes et surtout de mettre en relief
leurs limites. Ensuite, nous pouvons dégager les solutions envisageables qui peuvent faire face aux
problèmes recensés. De ce fait, nous allons présenter dans cette section le système sur lequel porte
le travail réalisé, dégager les faiblesses et les limites qui ont motivé le lancement de ce projet afin et
présenter la solution retenue. Par ailleurs, Il existe pour cela d’innombrables applications capables de
gérer les files d’attentes. La figure 1.4 ci-dessous montre une comparaison de la qualité des services
proposés par quelques-unes de ces applications :
7
Figure 1.4: étude comparative entre les solutions existantes
Afin de fournir une bonne qualité de service et être à la hauteur des attentes de nos clients,
nous proposons de rajouter d’autres fonctionnalités, telles que la possibilité de saisir des réclamations
et des suggestions, la capacité de Géolocaliser les agences à proximité. Nous avons aussi pensé à
fournir des informations sur toutes les agences et effectuer une recherche multicritères.
1.4 solution envisagée
Après avoir fait l’analyse des différents outils de gestion des files d’attente dans le marché
à savoir les applications mobiles et les applications web , et afin de remédier aux problèmes déjà
mentionnés ,nous avons opté pour la conception et le développement d’ une solution de gestion de
la file d’attente permettant :
• D’une part de décharger les administrations des longues files d’attente
• D’autre part, faciliter la gestion du temps aux usagers qui pourront faire d’autres choses pendant
les heures d’attente.
La solution se compose :
A) D’une application mobile offrant les fonctionnalités suivantes :
— Prise de rendez-vous en ligne
— Suivi de l’etat de la file d’attente en temps réel
8
— Informations sur les bureaux
— Itinéraire sur Map vers les différents bureaux
B) D’une plateforme Web de gestion des agences et de visualisation des statistiques sur un Dashboard.
1.5 Choix méthodologique
1.5.1 Méthodologie Scrum
Une méthodologie est un cadre utilisé pour le contrôle et la planification d’un projet afin
d’obtenir un produit final de bonne qualité. Pour notre projet, nous avons choisi de travailler avec la
méthode Scrum, qui est une méthode de développement agile orientée projet informatique dont les
ressources sont régulièrement actualisées. Scrum [2] vise à satisfaire au mieux les besoins du client
tout en maximisant les probabilités de réussite du projet. Scrum suppose que le développement d’un
logiciel n’est pas prévisible et ne peut donc pas suivre de processus défini. Le résultat du projet
dépend des réorientations que lui donne le client en cours de route. Le projet est composé d’une
suite d’itérations courtes de l’ordre de 3 à 6 semaines appelées sprints et il peut être réorienté par le
client à la fin de chaque sprint. La méthode Scrum définit 3 rôles : le «propriétaire du produit» porte
la vision du produit, le «directeur de produit» est le garant de la méthodologie Scrum et l’équipe de
développement du produit..
1.5.2 principe de la méthodologie agile « Scrum »
Le principe de base de Scrum est de dégager dans un premier lieu le maximum des fonctionnalités
à réaliser pour former le backlog du produit. En second lieu , définir les priorités des fonctionnalités
et choisir lesquelles seront réalisées dans chaque itération. Par la suite, focaliser l’équipe de façon
itérative sur l’ensemble des fonctionnalités à réaliser, dans des itérations appelées Sprints.Un Sprint
aboutit toujours sur la livraison d’un produit partiel fonctionnel appelé incrément .La figure 1.6
ci-dessous présente un résumé du processus de la méthodologie Scrum.
9
Figure 1.5: Le processus Scrum
1.5.3 Justification de choix
Le choix de Scrum comme méthodologie de pilotage pour notre projet s’est basé sur les atouts
de ce dernier. Ils se résument comme suit :
• Une architecture souple laisse place à la créativité. En plaçant le cahier des charges en arrière plan,
Scrum évite de frustrer les membres de l’équipe avec un plan et des tâches précises. Etre agile, c’est
être souple et laisser grandir le projet au fil des sprints.
• Une grande capacité d’adaptation au changement grâce à des itérations courtes
• Un gain du temps de développement.
conclusion
Au cours de ce premier chapitre, nous avons présenté le cadre du projet à savoir l’organisme
d’accueil et ses services. De même, nous avons donné un aperçu sur les applications existantes. Nous
avons aussi dévoilé la méthodologie de travail qui sera utilisée dans les prochains chapitres de ce
rapport.
10
Chapitre 2
Analyse et Spécification des besoins
Plan
1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 15

Chapitre 2. Analyse et Spécification des besoins
Introduction
Avant de développer notre application, nous proposons de commencer par la phase de

spécification pour bien organiser et clarifier les tâches de notre projet . Ce chapitre consiste donc à
identifier les acteurs de notre application tout en spécifiant les besoins fonctionnels et
non fonctionnels. Nous détaillerons notre travail avec la méthodologie choisie dans le chapitre
précédent. Enfin, Nous produirons le backlog initial ainsi qu’une première planification des sprints.
2.1 Identification des acteurs
Pour préparer les besoins fonctionnels et non fonctionnels de notre application , nous procédons
ici à l’identification des acteurs de notre système tout en détaillant le rôle de chacun .Un acteur est
une entité externe au système, il présente une personne ou un autre système informatique qui attend
un ou plusieurs services offerts par une interface d’accès qui interagit avec le système par envoi ou
par réception des messages. En se basant sur cette définition, nous avons dégagé la liste des acteurs
de notre système présentée dans le tableau 2.1 ci-dessous :
Acteur Rôle
Administrateur - Gérer les utilisateurs de l’application et les groupes d’utilisateurs.

- Affecter des privilèges et des rôles aux utilisateurs et aux groupes.
- Gérer les nomenclatures
- Consulter, modifier et supprimer les informations sur les agences.
- Consulter l’historique des réservations et des agences.
Utilisateur - Effectuer une réservation.

- Consulter l’historique des réservations.
- Modifier et supprimer une réservation.
- Consulter les notifications
- Saisir des réclamations et des suggestions.
- Géolocaliser les agences à proximité.
- Effectuer une recherche multicritères des agences
Tableau 2.1: Identication des acteurs et leurs rôles
12
2.2 Analyse des besoins
L’analyse du sujet et l’étude des outils existants nous a permis de dégager les fonctionnalités
qui seront offertes par notre application. Les contraintes auxquelles est soumis le système pour sa
réalisation et son bon fonctionnement seront décrites par la suite comme étant des besoins non
fonctionnels.
2.2.1 Besoins fonctionnels
Les besoins fonctionnels doivent répondre aux exigences du système en termes de fonctionnalités.
Ils constituent une sorte de contrat par rapport au comportement du système. Notre application doit
donc permettre de :
• S’authentifier par un login et un mot de passe pour accéder aux différentes fonctionnalités.
• Contrôler l’accès des utilisateurs aux différentes fonctionnalités
• Gérer les utilisateurs et les groupes d’utilisateurs de l’application tout en leur affectant des
privilèges et des rôles.
• Gérer la traçabilité des modifications et des accès au système
• Gérer les bureaux et les agences de l’entreprise à savoir la position géographique, les types de
services fournis, les prérequis des services . . . .
• Valider la prise de ticket
• Gérer les réclamations et les suggestions
• Consulter la cartographie de toutes les agences
• Effectuer une recherche multi critère des agences (adresse, ville, . . . )
• Fournir l’Itinéraire sur Map vers l’agence choisie.
• Notifier l’utilisateur à l’approche de son ticket
• Annuler la réservation
• Fournir des Informations sur l’actualité et les nouveautés de l’agence.
13
2.2.2 Besoins non fonctionnels
Afin d’être conforme aux normes et aux standards des outils informatiques, l’application doit
vérifier quelques propriétés et doit tenir compte de certaines contraintes et exigences :
• Ergonomie et convivialité du produit : il faut assurer la clarté du contenu de toutes les

interfaces développées qui devront offrir une ergonomie permettant des présentations claires pour
que l’utilisateur ait une manipulation aisée.
• Disponibilité : L’application doit être disponible 24h/24h et 7j/7j. Chaque utilisateur peut
consulter l’application à tout moment.
• Modularité : la solution doit être modulaire et bien structurée pour garantir sa souplesse et son
évolutivité.
• La sécurité : la sécurité permet de définir les niveaux d’accès possibles .Un utilisateur non
authentifié ne possède pas le droit d’accès à l’application.
• La performance : la solution doit être performante pour donner un temps de réponse
minimal vu le nombre important des données à traiter.
• Réutilisabilité : possibilité de réutiliser des composants du projet en les intégrant dans d’autres
logiciels à développer. On pourra réutiliser la conception et l’architecture adoptée.
2.3 Conception
La phase de conception s’avère indispensable afin d’obtenir, d’une manière formelle une vue
globale sur les exigences de notre application. Cette partie présente une modélisation des besoins en
faisant recours aux concepts fondamentaux d’UML, à savoir le diagramme de cas d’utilisation et le
diagramme de classes global.
2.3.1 Diagramme des cas d’utilisation global
Les diagrammes de cas d’utilisation permettent de recenser les grandes fonctionnalités du

système. Leur principal objectif est de se focaliser sur les interactions entre le système et le milieu
externe sans pour autant se soucier de la manière dont le système va réellement exécuter les
fonctionnalités décrites
14
La figure 2.1 ci-dessous représente le diagramme de cas d’utilisation global souhaité
Figure 2.1: diagramme de cas d’utilisation global
2.4 Pilotage du projet avec SCRUM
2.4.1 L’équipe Scrum
Scrum est considéré comme un cadre ou « Framework » de gestion de projet. Ce cadre est
constitué d’une défnition des rôles, il s’articule autour des trois rôles qui sont principalement les
suivants :
• Propriétaire du produit (Product Owner) : Il représente à la fois le client et les utilisateurs. C’est
donc lui qui définit les attentes et les besoins du projet. Ainsi, il définit les tâches permettant de
15
répondre à ces besoins et il mettra en place leur priorisation.
• Scrum Master : Le Scrum Master assure globalement le bon déroulement des programmes et
protège l’équipe de tout problème extérieur. Il assure également l’organisation des réunions et la
bonne application de la méthode agile.
• Equipe ou Team Members : Ce sont les personnes chargées de la réalisation du Sprint. Elle
est composée des professionnels et elle est caractérisée par une forte coopération et une haute
communication entre les différents membres.
Dans notre cas, les rôles sont répartis comme suit :
• Product Owner : le propriétaire du produit est Mr Sami Tabbane
• Scrum Master : l’animateur du projet est Mr Ali Tabbabi
• Equipe ou Team Members : dans le cadre de notre projet de fin d’étude, l’équipe est composée de
Tlili Siwar et Yahmadi Ikram.
2.4.2 Backlog de produit
Vu le recours à la méthode agile, nous n’avions pas une documentation faite au début du
projet, qui décrit en détail toutes les spécifications fonctionnelles. Les fonctions essentielles sont
collectées progressivement. Le backlog du produit constitue donc l’ensemble du travail connu sur le
projet à un instant donné. Il est régulièrement remis à jour et les besoins qui le constituent sont
aussi régulièrement définis avec leurs priorités.
Nous présentons le tableau 2.1 qui résume le Backlog du produit relatif à notre application contenant
les champs suivants :
• ID : C’est un nombre unique et auto-incrémenté pour chaque User Story
• Titre : C’est le résumé du User Story
• User Story : C’est une description courte de la tâche à réaliser et qui se dénit de la manière suivante :
En tant que <rôle>, nous souhaitons <faire quelque chose> afin de <obtenir de la valeur>
• Priorité : C’est l’importance attribuée par le Product Owner à cette tâche .La méthode MoSCow
est très pratique et très simple à mettre en œuvre pour fixer les priorités
MoSCow est l’acronyme de :
16
1) M - Must have : Il s’agit des points critiques, ils doivent être traités en priorité. Dans le cas
contraire, le succès du projet en souffrira et mènera à son échec. Ces exigences sont non négociables.
2) S - Should have : Ces points apportent une vraie valeur ajoutée, ce sont les tâches du projet
qui doivent être faites mais dans la mesure du possible, elles sont importantes mais pas vitales. Ces
tâches seront développées une fois que les tâches de la catégorie Must auront été livrées et s’ il reste
assez de temps disponible.
3) C - Could have : C’est bien de les avoir. Généralement, ils font partie des "petits plus" qui
contribuent à la satisfaction client pour un coût très modéré.
4) W - Won ‘t have : Ils sont exclus du projet, mais font partie des points valables pour un traitement
ou une intégration ultérieure.
• Effort : Evaluation initiale de la charge de travail nécessaire pour l’implémentation de cette

tâche. L’unité est en jours
17
Id Titre User case Priorité effort
1 S’authentifier En tant qu’Administrateur/Utilisateur, je dois M 5

m’identifier afin d’accéder à l’application.
2 Créer un compte En tant qu’utilisateur, je peux créer un compte M 7
3 Modifier les comptes En tant qu’administrateur/Utilisateur, je peux M 4

consulter et modifier mon compte afin de faire le
suivie des informations personnelles.
4 Gérer les utilisateurs En tant qu’administrateur, je peux ajouter, modifier M 5

de l’application et les ou supprimer des utilisateurs et des groupes
groupes d’utilisateurs. d’utilisateurs.
5 Gérer les informations En tant qu’administrateur, je peux Consulter, modifier M 7

sur les agences et supprimer des informations relatives aux différentes
agences
6 Gérer les informations En tant qu’administrateur, je peux Consulter, modifier M 7

des agences et supprimer des informations des agences
7 Effectuer une En tant qu’utilisateur, je veux effectuer une M 7

réservation réservation.
8 Consulter l’historique En tant qu’administrateur, je peux consulter M 5

des réservations l’historique des réservations.
9 Consulter les En tant qu’utilisateur, je peux consulter des M 6

notifications notifications.
10 Saisir des réclamations En tant qu’utilisateur, je peux saisir des réclamations S 4

et des suggestions. et des suggestions.
11 Consulter les En tant qu’administrateur, je peux consulter les S 4

statistiques statistiques
exporter une courbe en En tant qu’administrateur, je peux exporter une S 4

12
pdf courbe en pdf
13 Géolocaliser les agences En tant qu’utilisateur, je peux géolocaliser les agences M 5
14 Effectuer une Recherche En tant qu’utilisateur , je peux effectuer une Recherche M 5

multicritères des postes et des municipalités
Tableau 2.2: Backlog des sprints
18
2.4.3 Planification des sprints
La réunion de planification des sprints est l’événement le plus important dans Scrum. Le but
de cette réunion est de préparer le planning de travail et d’identifier le Backlog des sprints. L’un des
produits de cette réunion est le choix de la durée des sprints et qui diffère selon la complexité du
projet et la taille de l’équipe.
numéro sprint Durée Id user story
0 Documentation, Formation et de 04/02 au 01/03 ———-

Préparation du projet
1 Authentification, création et De 2/03 au 01/04 1, 2, 3,4

modification des comptes et gestion
des utilisateurs et des groupes
d’utilisateurs
2 Gestion des informations des Du 01/04 au 20/04 5, 7,10,11

agences, consultation de l’historique
des réservations et visualisation des
statistiques
3 Mise en place de la partie Mobile : Du 20/04 au 20/05 6,8, 9, 12,13

Effectuation des réservations,
géolocalisation des agences
,consultation des notifications, saisie
des réclamations /suggestions.
Tableau 2.3: plannification des sprints
conclusion
Durant ce chapitre, nous avons d’abord spécifié nos besoins ce qui nous a aidé à avoir une
vision plus claire et une compréhension plus profonde du sujet. Ensuite, nous avons détaillé la
première étape de la méthodologie adoptée à savoir le pilotage du projet avec Scrum et l’élaboration
du Backlog du Produit. Enfin, nous avons planifié nos sprints. Dans le chapitre suivant, nous
traiterons le premier Sprint.
19
Chapitre 3
Sprint 0 : Mise en place de

l’environnement matériel et logiciel
Plan
1 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapitre 3. Sprint 0 : Mise en place de l’environnement matériel et logiciel
Introduction
Ce chapitre présente le sprint de démarrage au cours duquel nous produisons le diagramme

de déploiement de notre application. Nous décrivons l’environnement matériel et logiciel utilisés
pour développer notre solution tout en justifiant nos choix technologiques qui vont nous servir pour
l’architecture globale de notre projet.
3.1 Langage de modélisation UML
Pour entamer la conception, nous avons utilisé UML[3], un langage graphique de modélisation
des données et des traitements. Il est adapté à un processus de développement dirigé par les cas
d’utilisation, itératif et incrémental. C’est un formalisme graphique, permettant via la notion de
diagrammes, de représenter le système logiciel à concevoir durant toutes les phases du processus de
développement. UML permet d’exprimer les besoins du système à concevoir, d’analyser, de concevoir,
d’initier la phase de codage et donc aussi de générer une documentation complète de la solution
logicielle finale
• Il a été normalisé par l’Object Management Group, qui est une organisation internationale se
chargeant de la standardisation des technologies objets. Il s’agit donc d’un langage standard
compréhensible par tout le monde.
• UML permet d’utiliser les principes et les concepts objet pour enrichir la phase de la conception
des systèmes.
• Nombre de processeurs :
• UML est indépendant du domaine d’application et des langages d’implémentation. Nous avons
utilisé pour ce fait "StarUML" vu qu’il permet de modéliser des systèmes complexes sous un
format graphique et textuel simplié et normalisé.
3.2 Diagramme de déploiement
Le diagramme de déploiement UML modélise l’architecture d’exécution des systèmes qui

représentent l’affectation (déploiement) des artefacts logiciels à des cibles de déploiement. Il est
utilisé pour visualiser la topologie des composants physiques d’un système dans lequel les composants
logiciels sont déployés. Les diagrammes de déploiement sont très utiles pour décrire les composants
matériels où les composants logiciels sont déployés. Il permet également de modéliser l’aspect
21
physique d’un système du logiciel orienté objet.
Figure 3.1: Diagramme de déploiement
3.3 Environnement matériel
Notre travail a été réalisé avec deux ordinateurs portables qui présentent les caractéristiques
suivantes :
•Marque : Asus, Toshiba
•Processeur : Intel Core(TM) i3-6006U CPU, Intel Core i5
•Mémoire : 4 GO, 16 GO
•Système d’exploitation : Windows 10 (64 bits)
3.3.1 Architecture de l’application
Avant de se lancer dans le développement de tout système informatisé, la préparation de

l’architecture de ce dernier est une étape cruciale puisqu’elle permet de comprendre le fonctionnement
22
du système ainsi que ses différents composants.
3.3.2 Architecture technique
La figure 3.2 présente l’architecture technique de la solution Web/mobile
Figure 3.2: Architecture technique
Il s’agit d’une application web /mobile qui se connecte à un serveur de base de données
distant, via internet, afin de récupérer les données, ce qui nécessite l’intégration d’un serveur web
entre l’application client et le serveur de base de données. D’où l’architecture de notre application
qui est partagée entre :
• Le client mobile : conteneur de l’application et demandeur des ressources.
• Le serveur web : vu que les données seront communiquées entre deux environnements hétérogènes.
Le rôle principal de serveur web est de gérer la communication entre le client mobile (Android/ios)
et le serveur de base de données.
• Le serveur de base de données qui fournit les données au serveur web.
3.3.3 Architecture applicative
Architecture MVC : Le patron d’architecture MVC [4] est un modèle destiné à répondre
aux besoins des applications interactives en séparant les problématiques liées aux différents composants
au sein de leur architecture respective
• Le modèle : cette partie encapsule la logique métier ainsi que l’accès aux données. Il peut s’agir
d’un ensemble de fonctions (Modèle procédural) ou de classes (Modèle orienté objet).
• La vue : Elle s’occupe des interactions avec l’utilisateur : présentation, saisie et validation des
données.
23
• Le contrôleur : La partie Contrôleur gère la dynamique de l’application. Elle fait le lien entre
l’utilisateur et le reste de l’application.
Figure 3.3: Architecture MVC
La figure 3.3 résume les relations entre les composants d’une architecture MVC La demande de
l’utilisateur (exemple : requête HTTP) est reçue et interprétée par le Contrôleur. Celui-ci utilise les
services du Modèle an de préparer les données à afficher. Ensuite, le Contrôleur fournit ces données
à la Vue, qui les présente à l’utilisateur (par exemple sous la forme d’une page HTML).
Web Service : Il s’agit d’une technologie permettant à des applications de dialoguer à distance
via Internet, et ceci indépendamment des plateformes et des langages sur lesquelles elles reposent.
Pour ce faire, les services Web s’appuient sur un ensemble de protocoles Internet très répandus
(XML, HTTP) afin de communiquer. Cette communication est basée sur le principe de demandes
et réponses
L’architecture REST : REST [5] est une API qui utilise les méthodes http [3] pour accéder à des
ressources distantes sur le web. Elle supporte plusieurs formats de données comme JSON7, XML8,
YML9 . Les ressources sont accessibles à travers un nombre limité de requêtes, PUT pour modier
une ressource, GET pour avoir une ressource, POST pour créer une ressource et DELETE pour la
supprimer.
24
3.4 Environnement logiciel
Au cours de cette section, nous présentons les outils et logiciels utilisés tout au long de notre
projet
3.4.1 Système d’exploitation
Nous avons utilisé le système d’exploitation Windows 10.
3.4.2 Outil de conception
StarUML [6] : Il s’agit d’une plateforme OpenSource Utilisée dans le développement logiciel
et dans la conception orientée objet. Grâce à ce logiciel, il vous sera possible de concevoir des classes,
des objets et des acteurs et d’y définir nombre d’attributs. Vous pourrez également créer et ajouter
vos propres plugins, les langages de programmation C++, C et Delphi sont pris en charge.
3.4.3 Outils de développement
PhpStorm [7] : Ce logiciel est un IDE commercial pour PHP très puissant. Il s’intègre
avec les gestionnaires de versions comme Subversion, Git, Mercurial, il supporte le terminal SSH
pour des besoins plus particuliers. Il permet aussi de visualiser l’architecture de bases de données de
différentes sources (MySQL, SQLite, ...).
VisualStudio Code : : Visual Studio Code [8] est un éditeur de code développé par Microsoft pour
linux, OS X et Windows. Il est rapide et performant. Il supporte plusieurs langages et framework
Angular, il comporte ainsi un terminal intégré qui permet de lancer le serveur à partir du logiciel.
VsCode intègre plusieurs outils facilitant la saisie de code par les développeurs comme la coloration
syntaxique ou encore le système d’auto-complétion IntelliSense. En outre, cet outil permet aux
développeurs de corriger leur code et de gérer les différentes versions de leurs fichiers de travail.
WampServer : WampServer [9] propose aux développeurs Web un outil de déploiement local ou
en ligne pour le développement des sites Internet dynamiques. Au sein de l’application, on retrouve
Apache HTTP Server en tant que serveur HTTP, PHP pour le langage de script, MySQL pour le
système de gestion des bases de données (SGBD) ainsi que l’application Web phpMyAdmin pour la
gestion des SGBD MySQL. Pour faciliter la création et le déploiement de sites, WampServer intègre
également des outils, tels que XDebug, XDC, SQLBuddy ou encore webGrind. Le logiciel se loge
discrètement dans la zone de notification de Windows et informe l’utilisateur de la mise hors ligne
25
ou en ligne du site.
Postman : Postman [10] est une application permettant avec un navigateur Web de lancer des
appels d’API et de les tester. Postman permet d’envoyer des requêtes vers l’API de site en lui
ajoutant des en-têtes clés / valeurs puis il permet de formater le résultat sur plusieurs formats tels
que JSON, XML, HTML et autres.
3.4.4 Editeur
ShareLatex : C’est un éditeur Latex en ligne, collaboratif, en temps réel et compilateur

PDF .
3.4.5 Choix technologiques
Avant d’entamer l’implémentation de notre application, une étude technologique a été tout
d’abord réalisée. Nous présentons, dans cette partie, les technologies globales avec lesquelles nous
réalisons notre projet tout en argumentant notre choix
• Choix technologique pour la partie Web :
Symfony : Le Framework que nous avons retenu est Symfony [11] dans sa version 3.4 qui est la
version la plus stable. Symfony est un framework Web PHP open-source. Il fournit une architecture,
des composants et des outils aux développeurs, qui permet de réaliser rapidement des applications
web complexes. Parmi les fonctionnalités phares de ce framework. A noter que Symfony est compatible
avec les ORM (Object-relational mappings) Prope et Doctrine. L’architecture de Symfony se compose
de :
• Vue : son rôle est d’acher les pages.
• Twig : C’est le moteur de templates utilisé par default dans Symfony. Twig dispose d’une syntaxe
concise et claire, il supporte de nombreuses fonctionnalités utiles, telles que la notion d’héritage,
et il sécurise automatiquement les variables.
• Contrôleur : son rôle est de générer la réponse à la requête HTTP demandée par notre visiteur.
Il est la couche qui se charge d’analyser et de traiter la requête de l’utilisateur.
26
Figure 3.4: logo de Symfony
• Choix technologique pour la partie Mobile :

Ionic : ionic [12] Framework est un mélange d’outils et de technologies pour développer des
applications mobiles hybrides rapidement et facilement. Il s’appuie sur AngularJS pour la partie
application web du framework et sur Cordova pour la partie construction des applications natives. Ce
framework open source permet de développer une application déployable sur plusieurs environnements
tels qu’un site web ou une application mobile pour des systèmes tels que Android ou iOS ou Windows
Phone.
Figure 3.5: logo ionic
• Choix technologique pour la gestion de base de données :

Mysql : [13] MySQL est l’un des systèmes de gestion de base de données relationnelles le plus
connu au monde. Les raisons de son succès résident essentiellement sur sa fiabilité et sa robustesse,
ses performances, sa simplicité d’utilisation et son mode de licence : licence gratuite pour les logiciels
libres intégrant cette technologie et payante pour les logiciels propriétaires. MySQL présente l’intérêt
de fonctionner avec la quasi-totalité des systèmes d’exploitation connus et de communiquer aisément
avec les langages de programmation tels que C, C++, VB, C, PHP, Python, Ruby, Java, Perl, Eiffel,
27
etc. Des API sont disponibles pour chaque langage.
Figure 3.6: logo de mysql
3.4.6 Installation et paramétrage général de l’environnement de

développement
3.4.6.1 Installation de Symfony
Nous avons commencé par executer la commande comme l’indique la figure ci-dessous :
Figure 3.7: commande d’installation de symfony
Ensuite nous avons déplacé le fichier symfony téléchargé dans un dossier indiqué dans la
variable d’environnement PATH .
Une fois que nous avons installé Symfony sur notre système local, nous avons crée notre projet
Symfony avec la commande indiquée ci- dessous :
Figure 3.8: création du projet symfony
3.4.6.2 Installation d’Ionic
Avant d’installer Ionic et Cordova, nous allons installer Node.js[17] pour gérer l’installation
de package NPM.
28
Figure 3.9: installation et configuration du Node.js
Figure 3.10: vérification de l’installation du Node.js
Maintenant que Node.js est installé, nous allons installer Ionic en lançant la commande
d’installation de package via NPM.
Figure 3.11: Installation d’ionic
Création du projet
Nous avons exécuté la commande suivante dans notre terminal afin de créer notre projet ionic et
nous avons obtenu les retours suivants :
29
Figure 3.12: création du projet ionic
Conclusion
Dans ce chapitre, nous avons présenté l’environnement matériel et logiciel que nous avons
choisi pour développer notre application. Dans le chapitre suivant, nous entamons le premier sprint.
30
Chapitre 4
Sprint 1 : Authentification,
création et modification des comptes
et gestion des utilisateurs et des
groupes d’utilisateurs
Plan
1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapitre 4. Sprint 1 : Authentification, création et modification des comptes et gestion des
utilisateurs et des groupes d’utilisateurs
Introduction
Tous au long de ce chapitre, nous réalisons la conception et le développement relatifs au

premier Sprint. Nous avons divisé le travail en quatre phases principales qui sont l’analyse, la
conception, la réalisation et le test.
4.1 Backlog Sprint 1
Dans la méthodologie Scrum, tous les sprints ont une durée constante et ne se chevauchent
jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est pas encore termié.
né. Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce
dernier. Ce but doit être défini en termes métiers et non pas en termes techniques pour qu’il
soit compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale « pourquoi faisons-nous ce sprint ? ». Une fois que le but de notre sprint soit défini, on
choisit les histoires qui seront incluses dans le backlog du sprint. Le Tableau 4.1 résume le backlog
de notre premier sprint :
ID User Story Estimation/jours
1 En tant qu’Administrateur/ Utilisateur, je dois 7

m’authentifier afin d’accéder à l’application.
2 En tant qu’utilisateur/administrateur, je peux créer 5

un compte
3 En tant qu’administrateur/Utilisateur, je peux 7

consulter et modifier mon compte afin de faire le suivi
des informations personnelles.
4 En tant qu’administrateur, je peux ajouter, modifier 11

ou supprimer des utilisateurs et des groupes
d’utilisateurs
Tableau 4.1: Backlog sprint 1
32
Passons maintenant au vif de notre sujet : les activités et le cycle de développement. Dans
un sprint, nous pouvons dégager quatre activités principales qui sont la spécification fonctionnelle,
la conception, la réalisation et le test. Tout au long de ce sprint, nous respectons ces activités pour
construire le plan de notre travail.
4.2 Spécification
La spécification dans notre cas se traduit par le raffinement du diagramme des cas d’utilisation
et d’une description détaillée du premier sprint.
4.2.1 Diagramme du cas d’utilisation raffiné « S’authentifier »
Figure 4.1: Diagramme du cas d’utilisation raffiné « S’authentifier »
33
titre s’authentifier
Acteurs Utilisateur
Pré condition Utilisateur inscrit
Post condition Utilisateur connecté
Scénario 1) L’utilisateur accéde à l’application

nominal 2) Le système génère la page d’authentification
3) L’utilisateur saisit son nom d’utilisateur et son mot de passe
4)Le système compare les informations introduites avec la base de
données et les valide
5) Le système ramène l’utilisateur à la page d’acceuil de l’application
Scénario Données invalides :

alternatif lorsque l’utilisateur introduit un login et/ou un mot de passe erroné le
système affiche un message d’erreur lui proposant de ressaisir les données.
Tableau 4.2: Description textuelle du cas d’utilisation « S’authentifier »
4.2.2 Diagramme du cas d’utilisation raffiné « Créer Compte »
Figure 4.2: Diagramme raffinné du cas d’utilisation « Créer Compte »
34
titre Créer un compte
Acteurs Utilisateur
Résumé créer un compte pour un nouvel utilisateur
Pré condition Le nouveau compte sera sauvegardé dans la base de données avec tous les
détails
Post condition Utilisateur connecté
Scénario nominal 1) L’utilisateur demande le formulaire d’inscription.

2) Le système redirigera l’utilisateur vers formulaire de création d’un compte.
3) L’utilisateur remplit les champs
4)Le système compare les informations introduites avec la base de données et
les valide
5) Le système ramène l’utilisateur à la page d’acceuil de l’application
Scénario alternatif 3) L’utilisateur saisit les données manquantes :

3.a. Le système affiche les messages d’erreur.
3.b. Reprise de l’étape 3 du scénario nominal.
4) Le système trouve que l’adresse mail existe déjà :
4.a. le système demande à l’utilisateur de choisir une autre adresse mail.
4.b. reprise de l’étape 3 du scénario nominal.
Tableau 4.3: Description textuelle du cas d’utilisation « Créer un compte»
35
4.2.3 Diagramme de cas d’utilisation raffiné « Gérer compte »
Figure 4.3: Diagramme raffiné du cas d’utilisation « Gérer Compte »
titre Modifier compte
Acteurs Utilisateur/administrateur
Résumé Ce cas d’utilisation permet à

l’utilisateur/l’administrateur de modifier son compte
Pré condition Authentification préalable
Post condition Compte modifié
Scénario nominal 1) L’utilisateur accéde à son compte.

2) L’utilisateur saisit les modifications
3) L’utilisateur valide les modifications effectuées
4) Le système affiche le nouveau compte
Tableau 4.4: Description du cas d’utilisation « Modifier compte »
36
titre Désasactiver compte
Acteurs Utilisateur/administrateur
Résumé Ce cas d’utilisation permet à l’utilisateur/l’administrateur de désactiver son

compte

Compte existant
Post condition Compte désactivé
Scénario 1) L’utilisateur accéde à son compte.

nominal 2) L’utilisateur modifie l’état de compte à désactiver
4) Le système désactive le compte
Tableau 4.5: Description du cas d’utilisation « Désactiver compte »
Gestion des utilisateurs et des groupes d’utilisateurs

L’administrateur possède le droit d’ajouter, modier et supprimer un utilisateur ou un groupe d’utilisateurs
et de leur affecter des rôles et des privilèges précis. Toutes ces fonctionnalités nécessitent une
authentication en premier lieu.
4.2.4 Diagramme de cas d’utilisation raffiné « Gérer utilisateurs et groupes»
Figure 4.4: Diagramme de cas d’utilisation raffiné « Gérer utilisateurs et groupes »
37
titre Ajouter des utilisateurs et des groupes
Acteurs administrateur
Résumé L’administrateur a le droit d’ajouter des utilisateurs et des groupes tout

en leur affectant les rôles et les privilèges adéquats
Post condition L’utilisateur/ groupe ajouté Rôles et privilèges affectés.
Scénario 1)L’administrateur demande la page de gestion des utilisateurs et des

nominal groupes
2) L’administrateur ajoute le groupe/l’utilisateur
3) L’administrateur accorde les rôles et les privilèges aux
utilisateurs/groupes ajoutés
4) L’administrateur valide l’ajout
5) Le système affiche la liste des groupes/utilisateurs ajoutés
Tableau 4.6: Description textuelle du cas d’utilisation «Ajouter des utilisateurs et des groupes »
titre Supprimer des utilisateurs et des groupes
Résumé L’administrateur a le droit de supprimer des utilisateurs et des

groupes
Pré condition Authentification préalable Utilisateur/groupe existant
Post condition L’utilisateur/groupe supprimé
Scénario nominal 1) L’administrateur demande la page de gestion des utilisateurs et

des groupes
2) L’administrateur supprime un groupe/un utilisateur
3) L’administrateur valide la supression
4) Le système affiche la nouvelle liste des groupes/utilisateurs
Tableau 4.7: Description textuelle du cas d’utilisation «Supprimer des utilisateurs et des groupes
»
38
titre Modifier des utilisateurs et des groupes
Résumé L’administrateur a le droit de modifier des utilisateurs et

des groupes tout en leur affectant les rôles et les privilèges
adéquats
Pré condition Authentification préalable Utilisateur/groupe existant
Post condition L’utilisateur/groupe modifié Rôles et privilèges affectés.
Scénario nominal 1) L’administrateur demande la page de gestion des

utilisateurs et des groupes
2) L’administrateur modifie un groupe/un utilisateur
3) L’administrateur accorde les rôles et les privilèges aux
utilisateurs/groupes modifiés
4) L’administrateur valide la modification
5) Le système affiche la liste des groupes/utilisateurs
modifiés
Tableau 4.8: Description textuelle du cas d’utilisation «Modifier des utilisateurs et des groupes »
39
4.3 Conception
4.3.1 Digramme d’activité global du premier sprint
Le diagramme d’activité permet de mettre l’accent sur les traitements. Il permet ainsi de
représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.
Le diagramme dans la gure 4.6, montre le processus du premier sprint de notre application .
Figure 4.5: diagramme d’activité global du premier sprint
4.3.2 Diagramme de séquence illustrant le cas d’utilisation «s’authentifier»
L’authentification est une tâche primordiale en vue de limiter l’accès et sécuriser notre
application, la figure 4.2 présente le diagramme de séquence système qui permet aux utilisateurs
de se connecter. L’utilisateur doit saisir son login et son mot de passe d’une façon correcte.
40
Figure 4.6: Diagramme de séquence du cas d’utilisation « S’authentifier »
4.3.3 Diagramme de séquence « Modification des comptes »
Une fois authentifié, l’utilisateur peut modier son compte, le scénario de modication du
compte est décrit dans le diagramme de séquence de la Figure 4.4 :
41
Figure 4.7: Diagramme de séquence du cas d’utilisation « Modification des comptes »
4.3.4 Diagramme de séquence « Désactiver comptes »
Une fois authentifié, l’utilisateur peut modier son compte, le scénario de désactivation du
compte est décrit dans le diagramme de séquence de la Figure 4.4 :
Figure 4.8: Diagramme de séquence du cas d’utilisation « Désactiver compte »
42
4.4 Réalisation
Après avoir achevé l’étape de la conception, en tenant compte des besoins fixés et des choix
conceptuels effectués précédemment, nous consacrons le reste de ce chapitre à la description du
travail réalisé en exposant quelques scénarios d’exécution à travers des captures d’écran.
cette figure présente l’interface d’authentication.
L’utilisateur doit impérativement remplir les champs correspondants à son login et son mot de passe
comme le montre la figure ci dessous Si les données entrés sont valides, l’utilisateur sera autorisé à
accéder à l’application, sinon un message d’erreur apparaît .
Partie Web :
Figure 4.9: Formulaire d’authentification
43
Figure 4.10: données invalides
Une fois authentifié, l’utilisateur peut visualiser les interfaces de la modification d’un compte.
Il a la possibilité de modifier son mot de passe et sa photo de profil comme le montrent les figures
ci-dessous
Figure 4.11: changement de mot de passe
44
Figure 4.12: Validation de changement de mot de passe
Figure 4.13: changement de la photo de profil
Puis, l’administrateur a la possibilité de gérer des utilisateurs ou des groupes d’utilisateurs

comme l’indique la figure 4.14
45
Figure 4.14: Gestion des utilisateurs
Figure 4.15: Gestion des groupes
46
Partie Mobile
A l’ouverture de l’aplication l’utilisateur est dirigé vers une page d’accueil puis la page d’authentification
Figure 4.16: interface d’acceuil
Figure 4.17: Interface d’authentification : Figure 4.18: Interface d’authentification :

utilisateur existant utilisateur inexistant
47
Pour créer un nouveau compte, l’utilisateur clique sur le bouton "créer un compte" pour pouvoir
saisir les informations liées à l’inscription comme le montre la figure 4.15
Figure 4.19: Interface de création d’un compte
Figure 4.20: Interface profil
48
4.5 Tests
La phase de tests est une étape incontournable de tout développement informatique ayant
pour objectif de vérifier que le livrable répond bien aux besoins exprimés par l’utilisateur.
Parmi les nombreuses solutions pour interroger ou testerles Web services : Postman propose
de nombreuses fonctionnalités, une prise en main rapide et une interface graphique agréable. Il
s’agit d’un client REST proposé par Google. Il est disponible sous la forme d’une extension Chrome
ou bien d’une application stand-alone La gure 4.21 illustre le cas de succès de la fonctionnalité
d’authentification d’un utilisateur.
Figure 4.21: Test d’authentification d’un utilisateur
Tests fonctionnels : Les tests fonctionnels vérifient que le produit assure les fonctionnalités
déjà spécifiées. Ainsi avant la fin de chaque Sprint, nous avons testé les fonctionnalités du module.
Ensuite, nous avons validé toutes les fonctionnalités avec le Product Owner.
Le tableau 4.8 ci-dessous, montre un ensemble de cas de scénarios des tests fonctionnels relatifs au
Sprint 1. Tableau 4.8 : Tableau des scénarios des tests fonctionnels relatifs au Sprint 1
49
Cas de test Démarche Comportement Résultat

attendu
Authentification Introduire les informations Redirection vers la page conforme

nécessaires à la connexion d’accueil
Modification du Introduire les nouvelles informations Modification du compte conforme

compte
Créer un nouveau Introduire les informations relatives Création d’un nouveau conforme
compte au compte compte
Ajouter un demander la page de gestion des Ajout d’un conforme

utilisateur/un utilisateurs et des groupes et ajouter utilisateur/groupe
groupe un nouvel utilisateur/nouveau
groupe
Supprimer un demander la page de gestion Suppression d’un conforme

utilisateur/un des utilisateurs et supprimer des utilisateur/groupe
groupe utilisateurs et des groupes
Modifier un demander la page de gestion Modification d’un conforme

utilisateur/un des utilisateurs et modifier des utilisateur/groupe
groupe utilisateurs et des groupes
Tableau 4.9: Tableau des scénarios des tests fonctionnels relatifs au Sprint 1
Conclusion
Tout au long de ce chapitre, nous avons présenté le premier sprint relatif à l’authentification, la
création et la modification des comptes et gestion des utilisateurs et des groupes d’utilisateurs. Pour
ce faire, nous avons commencé par la spécification puis la conception, la réalisation et finalement les
tests. Dans le chapitre suivant nous entamons le deuxième sprint relatif à la gestion des informations
des agences, Consultation des historiques des réservations et des agences et visualisation des statistiques
50
Chapitre 5
Sprint2 : Gestion des informations

des agences, Consultation des
historiques des réservations et des
agences et visualisation des
statistiques
Plan
1 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2 Spécication fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapitre 5. Sprint2 : Gestion des informations des agences, Consultation des historiques des
réservations et des agences et visualisation des statistiques
Introduction
Après avoir terminé le premier sprint de notre application, nous allons maintenant nous lancer
dans les travaux nécessaires pour produire le second sprint. Tout au long de chapitre ,nous allons
présenter la réalisation de ce sprint réparti en quatre parties à savoir la spécification, la conception,
le codage et les tests .
5.1 Backlog Sprint 2
Le tableau 5.1 ci-dessous dénit les histoires utilisateur du sprint 2
1 En En tant qu’administrateur, je veux gérer des 7

informations relatives aux agences
2 En tant qu’administrateur, je peux consulter 4

l’historique des agences et des réservations effectuées
3 En tant qu’administrateur, je peux consulter des 5

statistiques
4 En tant qu’administrateur, je peux exporter une 4

courbe en pdf
52
5.2 Spécication fonctionnelle
5.2.1 Diagramme du cas d’utilisation du deuxième sprint
Figure 5.1: Diagramme du cas d’utilisation raffiné du deuxième sprint
53
5.2.2 raffinement du sous cas d’utilisation «gérer des nomenclatures»
Figure 5.2: raffinement du sous cas d’utilisation «gérer des nomenclatures»
5.2.3 Description du sous cas d’utilisation « ajouter type nomenclature»
Une nomenclature désigne une instance de classification (code, tableau, liste...). A chaque
type de nomenclature on associe une date et une ou plusieurs valeurs
titre Ajouter type nomenclature
Acteurs Administrateur
Résumé L’administrateur a le droit d’ajouter des types nomenclatures
Post condition Type nomenclature ajouté
Scénario nominal 1) L’administrateur demande la page de gestion des types

nomenclatures
2) L’administrateur supprime le type nomenclature sélectionné
3) L’administrateur valide la suppression
4) Le système affiche la nouvelle liste des types nomenclatures
Tableau 5.2: Description du sous cas d’utilisation « Ajouter type nomenclature»
54
titre Modifier type nomenclature
Résumé L’administrateur a le droit de modifier des types nomenclatures

Type nomenclature existant
Post condition Type nomenclature modifié

nomenclatures
2) L’administrateur modifie le type nomenclature sélectionné
3) L’administrateur valide la modification
4) Le système affiche la liste des types nomenclatures modifiés
Tableau 5.3: Description du sous cas d’utilisation « Modifier type nomenclature»
titre Supprimer type nomenclature
Résumé L’administrateur a le droit de supprimer des types nomenclatures

Type nomenclature existant
Post condition Type nomenclature supprimé

nomenclatures
2) L’administrateur supprime le type nomenclature sélectionné
3) L’administrateur valide la suppression
4) Le système affiche la liste des types nomenclatures
Tableau 5.4: Description du sous cas d’utilisation « Supprimer type nomenclature»
55
5.2.4 Description du sous cas d’utilisation « consulter historique des

réservations»
titre Consulter l’historique des réservations
Résumé l’administrateur consulte l’historique des réservations effectuées
Post condition La consultation est effectuée.
Scénario nominal 1) L’administrateur saisit son login et son mot de passe

2) L’administrateur accéde à son espace personnel
3) L’administrateur clique sur le lien «historique»
4) Le système affiche les informations sur l’historique des
réservations effectuées.
Tableau 5.5: Description textuelle du cas d’utilisation « consulter historique »
5.2.5 Description textuelle du cas d’utilisation «consulter des statistiques»
L’administrateur peut consulter des graphes explicatifs qui incluent des statistiques sur les
réservations effectuées pendant une durée bien déterminée.
56
titre Consulter statistiques
Résumé l’administrateur consulte la courbe de variation des réservations
Post condition Le graphe est affiché.
Scénario nominal 1) L’administrateur choisit une heure de début.

2) L’administrateur choisit une heure de fin.
3) L’administrateur valide son choix.
4) Le système affiche la courbe correspondante
Scénario alternatif 2. L’heure du n est inférieure à celle du début

2.a. Le système affiche un message d’erreur.
2.b. Reprise de l’étape 1 ou 2 du scénario nominal
4) Le système affiche la courbe correspondante
Tableau 5.6: Description textuelle du cas d’utilisation «consulter des statistiques»
5.3 Conception
Dans cette partie, nous allons présenter le diagramme de classes global de notre projet ainsi
que les diagrammes de séquence pour ce sprint.
5.3.1 Diagramme de classes
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie
de la partie statique d’UML car il fait abstraction des aspects temporels et dynamiques.
57
Figure 5.3: Diagramme de classes global
Description du diagramme de classes :
La classe Groupe : c’est une classe qui est constituée des utilisateurs et des administrateurs de
l’application
La classe Administrateur : l’administrateur peut gérer les utilisateurs et leur affecter des rôles,
chaque administrateur est associé à un groupe bien spécifié
La classe TypeNomenclature : C’est une classe qui définit le type de classification des agences
La classe ValeurNomenclature : C’est une classe qui définit la valeur du type nomenclature
choisi, chaque type de nomenclature est associé à une seule valeur
La classe Agence : C’est une classe qui dénit l’emplacement de l’agence choisie ainsi que ses
caractéristiques (disponibilité le samedi ou pas..), elle est associée à une classe Adresse qui permet
à son tour d’accéder à la municipalité et au gouvernorat de l’agence
La classe Réservation : C’est une classe qui définit l’état d’une réservation
La classe HistoriqueAgence :C’est une classe qui définit l’historique de toutes les réservations
relatives à cette agence ainsi que le nombre de tickets réservés quotidiennement
58
5.3.2 Diagramme de séquence
Nous allons maintenant présenter le diagramme de séquence du cas d’utilisation « Consulter

Historique », La gure 5.4 illustre le diagramme de séquence gérant cette consultation
Figure 5.4: Diagramme de séquence du cas d’utilisation « Consulter historique »
5.4 Réalisation
Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures
d’écran.
Génération du bundle Nomenclature Un Bundle est un répertoire dans un projet Symfony qui
intègre une structure bien définie.Ce répertoire permet d’implémenter plusieurs fonctionnalités qui
peuvent être utilisées dans d’autres projets Symfony. Ce framework propose des milliers de Bundles
réutilisables quasiment dans tous les projets Symfony qu’on peut avoir. Pour la création du bundle
Nomenclature nous avons executé la commande illustrée dans la figure 5.5 ci-dessous
Figure 5.5: création du bundle Nomenclature
Génération de l’entité TypeNomenclature :

Une fois le bundle généré, nous avons fait de même avec ses entités. Par exemple pour l’entité
TypeNomenclature, la figure 5.6 montre le résultat de l’exécution de la commande correspondante :
59
Figure 5.6: génération de l’entité TypeNomenclature
La figure 5. présente l’interface graphique de la gestion des types nomenclatures :
Figure 5.7: gestion des Types nomenclatures
La figure 5.8 présente l’interface graphique de la gestion des valeurs nomenclatures :
Figure 5.8: gestion des valeurs nomenclatures
60
Dans notre projet, nous avons retenu deux valeurs et deux types de nomenclatures qui sont
Horaire et Type agence. Chaque type nomenclature nomenclature possède plusieurs valeurs.
Type nomenclature Valeurs correspondantes
Horaire 40 minutes,60 minutes,30minutes
Type agence Municipalité, Poste
L’administrateur peut gérer les informations relatives à chaque agence. Parmi ces informations
on distingue l’adresse de cette dernière, la figure 5. 10 représente l’interface graphique de la gestion
des adresses :
Figure 5.9: interface de gestion des adresses
Figure 5.10: interface de gestion des municipalités
61
L’administrateur a également la possibilité de visualiser des statistiques sur l’état des réservations
effectuées pendant une période donnée comme le montre le graphe de la figure 5.11 ci-dessous :
Figure 5.11: interface graphique des statistiques visualisées
Figure 5.12: interface graphique des statistiques visualisées 2
62
5.5 Tests
Le tableau 5.7 ci-dessous montre un ensemble de scénarios de tests fonctionnels que nous
avons effectué et qui sont relatifs au deuxième sprint

attendu
Ajouter un L’administrateur demande la page Ajout d’un conforme

type/une de gestion des nomenclatures et type/une valeur/date
valeur/date ajoute un nouveau type/nouvelle nomenclature
nomenclature valeur/date nomenclature
Supprimer un L’administrateur demande la page suppression d’un conforme

type/une valeur de gestion des nomenclatures type/une valeur/date
nomenclature et supprime un type/une valeur nomenclature
nomenclature
Modifier un L’administrateur demande la page modification d’un conforme

type/une de gestion des nomenclatures et type/une valeur/date
valeur/date modifie un type/une valeur/date nomenclature
nomenclature nomenclature
Consulter des L’administrateur s’authentifie. Ajout d’un conforme

statistiques Des graphiques apparaissent sur utilisateur/groupe
l’interface d’acceuil indiquant des
statistiques sur les réservations
effectuées
Consulter L’administrateur demande la Affichage de l’historique conforme

l’historique page relative à l’historique des des réservations
réservations
Tableau 5.7: Scénarios de test Sprint 2
63
Conclusion
Au cours de ce chapitre, nous avons présenté le deuxième sprint relatif à la gestion des
informations des agences, consultation des historiques des réservations et des agences et la visualisation
des statistiques . Nous sommes passés par la spécification, la conception, le codage et les tests. Dans
le chapitre suivant nous entamerons le dernier sprint relatif à la Mise en place de la partie mobile .
64
Chapitre 6
«sprint3 » Mise en place de la

partie mobile
Plan
1 Backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapitre 6. «sprint3 » Mise en place de la partie mobile
Introduction
Après la réalisation du deuxième sprint, nous entamons le troisième sprint qui se focalisera
sur la partie web et suivra le même plan que le chapitre précédent.
6.1 Backlog sprint 3
Dans cette partie, nous allons élaborer le backlog du troisième sprint. Le but de ce dernier
est d’effectuer des réservations, géolocaliser l’ agence choisie ,consulter des notifications et saisir des
réclamations et des suggestions. Les estimations des histoires utilisateur sont définies en nombre de
jours. Le tableau 6.1 montre le backlog de notre troisième sprint.
1 En tant qu’utilisateur , je peux effectuer une 7

Recherche multicritères sur des postes et des
municipalités
2 En tant qu’utilisateur, je veux effectuer une 7

réservation
3 En tant qu’utilisateur je peux annuler/reporter ma 4

réservation.
4 En tant qu’utilisateur, je peux géolocaliser une agence 5
5 En tant qu’utilisateur, je veux consulter mes 4

notifications
6 En tant qu’utilisateur, je peux saisir des 7

réclamations et des suggestions
66
6.2 Spécification
Dans cette section nous allons élaborer le raffinement des cas d’utilisation avec une description
détaillée.
6.2.1 Diagramme du cas d’utilisation détaillé du troisième sprint
Figure 6.1: Diagramme de cas d’utilisation détaillé du troisième sprint
67
titre Effectuer une recherche des agences
Acteurs Utilisateur
Résumé L’utilisateur effectue une recherche

multicritères des agences
Pré condition L’utilisateur doit s’authentifier
Post condition Liste des agences affichée
Scénario nominal 1) L’utilisateur demande la page de recherche des agences

2) L’utilisateur saisit des informations pour chercher les agences
3) L’utilisateur valide la recherche
4) Le système affiche la liste des agences
Tableau 6.2: Description textuelle du cas d’utilisation « Effectuer une recherche des agences »
titre Effectuer une réservation
Acteurs Utilisateur
Résumé L’utilisateur effectue une réservation
Pré condition • utilisateur authentifié

• L’utilisateur doit choisir une agence
Post condition • Réservation enregistrée

• Obtention du ticket
Scénario nominal 1) L’utilisateur choisit l’agence à laquelle il veut accéder

2) Le système génère le numéro courant de la file d’attente au sein
de cette agence et affiche des informations relatives à cette dernière
3) L’utilisateur clique sur l’icone de réservation et choisit l’heure
et effectue la réservation
4) La réservation est enregistrée
Tableau 6.3: Description textuelle du cas d’utilisation « Effectuer une reservation »
68
titre Annuler une réservation
Acteurs Utilisateur
Résumé L’utilisateur peut annuler une réservation
Pré condition • L’utilisateur doit s’authentifier

• La réservation doit être déjà effectuée
Post condition Réservation annulée
Scénario nominal 1)l’utilisateur accéde a la page d’accueil et choisit l’option «Ticket»

2) Le système génère un ticket numérique relatif à l’utilisateur
3) L’utilisateur choisit l’option « Annuler »
4) La réservation est annulée
Tableau 6.4: Description textuelle du cas d’utilisation «Annuler une reservation »
titre Reporter une réservation
Acteurs Utilisateur
Résumé L’utilisateur peut reporter une réservation
Pré condition • L’utilisateur doit s’authentifier

• La réservation doit être déjà effectuée
Post condition Réservation reportée
Scénario nominal 1)l’utilisateur accéde a la page d’accueil et choisit l’option «Ticket»

2) Le système génère un ticket numérique relatif à l’utilisateur
3) L’utilisateur choisit l’option « Reporter »
4) La réservation est reportée
Tableau 6.5: Description textuelle du cas d’utilisation « Reporter une reservation »
69
titre Géolocaliser une agence
Acteurs Utilisateur
Résumé L’utilisateur peut géolocaliser l’agence choisie
Post condition Obtenir un itinéraire sur Map vers l’agence choisie
Scénario nominal 1) L’utilisateur choisit l’agence à laquelle il veut accéder

2) Le système génère les informations relatives à cette dernière
3) L’utilisateur clique sur l’icone de géolocalisation
4) La géolocalisation est effectuée
Tableau 6.6: Description textuelle du cas d’utilisation « Géolocaliser agence»
titre Consulter des notifications
Acteurs Utilisateur
Résumé L’utilisateur peut consulter ses notifications
Post condition Notification consultée
Scénario nominal 1) L’utilisateur accède à son espace personnel

2) Le système génère les notifications et les affiche
3) Les notifications sont visualisées à l’utilisateur
Tableau 6.7: Description textuelle du cas d’utilisation « Consulter des notifications»
70
titre Saisir réclamation
Acteurs Utilisateur
Résumé L’utilisateur peut saisir ses réclamations
Post condition Réclamation enregistrée
Scénario nominal 1)l’utilisateur accéde a la page d’accueil et choisit l’option

«Reclamation»
2) l’utilisateur introduit sa réclamation et valide la saisie
3) Le système enregistre la réclamation introduite par l’utilisateur
Tableau 6.8: Description textuelle du cas d’utilisation « Saisir réclamation»
71
6.3 Conception
Nous allons maintenant présenter les interactions de ce sprint sous la forme de diagramme
de séquence
Figure 6.2: Diagramme de séquence Effectuer reservation
72
Figure 6.3: Diagramme de séquence Réchercher les agences
73
6.4 Realisation
Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures
d’écran.
• Aprés l’authentification, l’utilisateur se dirige vers la page d’accueil pour choisir l’option
qu’il souhaite.
Figure 6.4: Interface de page d’accueil
74
• l’utilisateur peut consulter la liste des agences de toute la tunisie
Figure 6.5: Interface charger liste agence Figure 6.6: Interface consulter liste agence
75
• L’utilisateur a la possibilité de chercher une agence par son nom. Pour cela, il suffit de saisir
un nom (on a tester avec le nom Mourouj ) et le système affiche la liste des agences correspondantes.
La figure 6.4 ci-dessous montre l’interface relative à la recherche des agences :
Figure 6.7: Interface recherche en cours Figure 6.8: Interface résultat recherche
76
• Une fois que l’utilisateur choisit une agence, il va avoir des informations sur cette dernière
comme l’indique la figure 6.5
Figure 6.9: Interface information agence
77
• Une fois l’utilisateur a selectionné l’agence à laquelle il va accèder, il peut choisir dans
combien de temps il veut passer
Figure 6.10: Interface choisir horraire Figure 6.11: Interface choisir horraire 2
78
• Aprés la reservation , l’utilisateur peut suivre l’etat de la file et connaitre le temps restant
pour son ticket ainsi il a la possiblité de l’annuler ou la reporter.
Figure 6.12: Interface de Ticket
79
• l’utilisateur peut consulter son profil
Figure 6.13: Interface de profil
80
• La localisation des agences sur la carte est disponible en deux modes : terrain et satellite.
Figure 6.14: Géolocaliser agence
6.5 Tests
Nous avons élaboré dans ce tableau un ensemble des scénarios de tests fonctionnels relatifs
au troisième sprint
81

attendu
Effectuer une • L’utilisateur demande la page de Affichage du résultat de conforme

recherche recherche des agences et introduit recherche
des mots clés Affichage du
résultat de recherche
Effectuer une • L’utilisateur choisit l’agence à Réservation effectuée conforme

réservation laquelle il veut accéder
• L’utilisateur clique sur l’icône
de réservation , choisit l’heure et
effectue la réservation
Reporter • L’utilisateur accède à la page de Réservation reportée conforme

une réservation ticket et choisit l’option
« Reporter »
Annuler une • L’utilisateur accède à la page de Réservation annulée conforme

réservation ticket et choisit l’option
« Annuler »
Consulter • L’administrateur accède à son Notifications consultées conforme

notification espace personnel et consulte ses
notifications
Géolocaliser des • L’administrateur choisit une Obtention d’un conforme

agences agence et clique sur l’icône de Itinéraire sur Map
géolocalisation vers l’agence choisie.
Saisie des • L’administrateur accède à son Réclamation saisie conforme

réclamations espace personnel et saisit ses
réclamations
Tableau 6.9: Tableau des scénarios des tests fonctionnels relatifs au Sprint 3
82
Conclusion
A ce stade, notre projet d’études a atteint sa fin. Tout au long de ce chapitre, nous avons
traité le troisième et dernier sprint relatif à la mise en place de la partie mobile , nous sommes passés
par la spécification, la conception, le réalisation et les tests
83
Conclusion générale
Pour répondre à l’évolution continue du monde de l’informatique, et plus précisément dans

le domaine du developpement, nous avons developpé un outil de gestion de la file d’attente pour
répondre aux besoins de nos clients.
Pour y parvenir, il nous a fallu, dans un premier temps, analyser et comprendre les besoins
fonctionnels et non fonctionnels et les traduire en scénarios applicables dans le contexte des technologies
du monde de développement web et mobile. Nous sommes passés par plusieurs étapes d’analyse, de
recherche, de conception, de réalisation et de tests an de répondre aux exigences du client.
Par ailleurs, plusieurs technologies ont été exploitées durant la période du stage, an d’atteindre
le résultat souhaité. Nous citons par exemple Symfony, ionic..
Ce travail a été très instructif, puisqu’il nous a permis de découvrir des nouvelles technologies ainsi
que de fréquenter le monde professionnel étant entouré par des compétences de SFM Technologies .
Finalement, notre travail dans le projet de gestion de la file d’attente ne s’arrête pas à ce niveau.
En effet, plusieurs perspectives s’offrent à ce projet. Parmi les fonctionnalités que nous pouvons
ajouter, nous citons en particulier le paiement du service à effectuer en ligne,on pourra ainsi intégrer
d’autres technologies comme l’intelligence artificielle et la "machine learning" pour mieux gérer les
files d’attentes.
84
Bibliographie
[1] (2005). A propos de SFM télecom. [Accès le 28-janvier-2019], SFM telecom, adresse : https:
//www.sfmtechnologies.com/.
[2] (2005). A propos de Scrum. [Accès le 28-janvier-2019], scrum, adresse : : https : / / www .
piloter.org/projet/methode/scrum.%20html.
[3] (2007). A propos de UML. [Accès le 27-janvier-2019], uml, adresse : : http : / / www . math -
info.univ-paris5.fr/~bouzy/Doc/%20UML-NotesCours.pdf.
[4] (2007). le patron mvc. [Accès le 27-janvier-2019], mvc, adresse : :http://prof.bpesquet.fr/

cours/modele-mvc/.
[5] M. Rouse. (2016). rest. [Accès le 27-janvier-2019], rest, adresse : https://www.lemagit.fr/

definition/REST.
[6] (2016). staruml. [Accès le 05-janvier-2019], staruml, adresse : https : / / www . clubic . com /
telecharger-fiche384048-staruml.html.
[7] (2019). phpstorm. [Accès le 05-mars-2019], phpstorm, adresse : https://www.clubic.com/

telecharger-fiche430837-phpstorm.html.
[8] (2019). vscode. [Accès le 05-mars-2019], vscode, adresse : https://www.01net.com/telecharger/

windows/Programmation/creation/fiches/130819.html.
[9] (2012). wamp. [Accès le 03-mars-2015], wamp, adresse : https://www.01net.com/telecharger/

windows/Internet/editeur_de_site/fiches/28739.html.
[10] (2016). KM. [Accès le 10-avril-2018], postman, adresse : https://phortail.org/webntic/

Gerer-ses-appel-d-API-avecPostman.html.
[11] F. Potencier. (2013). KM. [Accès le 10-décembre-2018], symfony, adresse : http://gregwar.

com/php/symfony.html.
[12] (2013). [Accès le 10-avril-2018], ionic, adresse : https://fr.wikipedia.org/wiki/Ionic_

(framework).
[13] (2013). [Accès le 10-avril-2018], mysql, adresse : https : / / www . 01net . com / telecharger /
windows/Bureautique/base_de_donne/fiches/3129.html.
85
Annexes
Dans cet annexe, notre objectif est de mettre en valeur l’installation et le paramétrage de
l’environnement de travail, à savoir php Storm, Visual Studio Code et WampServer
Annexe 1. installation de WampServer
86
Annexes
Annexe 1. installation de Visual Studio Code
87
Annexes
88
Annexes
Annexe 3. installation de WampServer
89
Annexes
90
PÌl
¤ Ty®³ S QAOt Ty®³ ¨ TyqybWt EA³ ¨ TynVw AhJ Yl wOl m` @¡ @yfn
@¡ dh ¤ SFM Télécom TrJ §Cdt @¡ q d ISI Ty®² ¨A` dh`m ¨ Ayrb
.CA\t³ Tm¶A C ³ wmm Ah ¤ rt³ TkbJ ¨l ybW ºAK w¡ ¤rKm
Anyb d w C ³ MYSQL ¤ Ionic , Framework Symfony 3 AndtF
MYSQL ,ionic ,Framework Symfony 3, SFM télécom ,ISI : yAf Aml
Résumé
Ce travail a été réalisé pour l’obtention de licence appliqué en systéme informatique et logiciel à
l’Institut Supérieur d’Informatique (ISI).ce stage a été realisé au sein de la société SFM télécom ,
l’objectif de ce projet est la mise en place d’une application web et mobile permettant la gestion
des files d’ attente . nous avons utilisé le framework Symfony 3 , ionic et MYSQL pour la gestion
des bases de données.
Mots clés : ISI, SFM télécom, Symfony3, ionic, MYSQL.
Abstract
This work was done for the obtaining of a license applied in computer system and software at
the Higher Institute of Informatics (ISI). This internship was realized within the company SFM
telecom, the objective of this project is the implementation of a web and mobile application
allowing the management of waiting queues. we used the framework Symfony 3, ionic and MYSQL
for the management of database
Keywords : ISI, SFM télécom, Symfony3, ionic, MYSQL.
isi@isim.rnu.tn : ¨¤rtk¯ d§rb 71 706 698 : HAf 71 706 164 : Ah TA§C 2080 ¨¤CAb A§r w h 2
2, Abou Raihane Bayrouni 2080 l’Ariana Tél : 71 706 164 Fax : 71 706 698 Email : isi@isim.rnu.tn

File Attente Finale

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

File Attente Finale

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Stage de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliqué en Sciences et Technologies

Ikram YAHMADI et Siwar TLILI

Développement d’un outil de gestion des files

Encadrant professionnel : Monsieur Ali TABBABI

Encadrant académique : Monsieur Riadh ZAAFRANI

Réalisé au sein de SFM Technologies

Année Universitaire 2018 - 2019

Ministère de l’Enseignement Supérieur

Université de Tunis El Manar

Institut Supérieur d’Informatique d’El Manar

Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du

Diplôme National de Licence Appliqué en Sciences et Technologies

Ikram YAHMADI et Siwar TLILI

Développement d’un outil de gestion des files

Encadrant professionnel : Monsieur Ali TABBABI

Encadrant académique : Monsieur Riadh ZAAFRANI

Réalisé au sein de SFM Technologies

Année Universitaire 2018 - 2019

1 Planification et spécification des besoins 3

2 Analyse et Spécification des besoins 11

3 Sprint 0 : Mise en place de l’environnement matériel et logiciel 20

4 Sprint 1 : Authentification, création et modification des comptes et gestion des

6 «sprint3 » Mise en place de la partie mobile 65

1.1 Organigramme fonctionnel SFM Telecom . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Diagramme du cas d’utilisation raffiné « S’authentifier » . . . . . . . . . . . . . . . . 33

4.10 données invalides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Diagramme du cas d’utilisation raffiné du deuxième sprint . . . . . . . . . . . . . . . 53

6.1 Diagramme de cas d’utilisation détaillé du troisième sprint . . . . . . . . . . . . . . 67

2.1 Identication des acteurs et leurs rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.9 Tableau des scénarios des tests fonctionnels relatifs au Sprint 3 . . . . . . . . . . . . 82

— API = Application Programming Interface

— CSS = Cascading Style Sheets

— CSS = Modèle Vue Contrôleur

— HTML = HyperText Markup Language

— HTTP = Hypertext TransferProtocol

— IHM = Logiciel et Systèmes d’Information

— MoSCoW= Must Should Could Won’t

— UML = Unified Modeling Language

Dans le troisième chapitre intitulé « Sprint 0 » décrit l’environnement matériel et logiciel

Planification et spécification des

3 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.1 Présentation de l’organisme d’accueil

1.1.1 Présentation générale de SFM Télécom

1.1.2 Organigramme fonctionnel de SFM

Figure 1.1: Organigramme fonctionnel SFM Telecom

Figure 1.2: Groupe SFM

Figure 1.3: Zones d’intervention

1.1.3 Les activités de SFM

Les activités de SFM [1] sont organisées autour de quatre axes :

1.3 Etude et critique de l’existant

Figure 1.4: étude comparative entre les solutions existantes