Feten

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

Université de Jendouba
Faculté des Sciences Juridiques, Économiques et de Gestion de Jendouba
(FSJEGJ)
Rapport de Projet de Fin d’Études

Présenté en vue de l’obtention du
Diplôme en Licence Fondamentale en Informatique Appliquée à la Gestion
Conception et développement d’une

application de gestion des parkings
intelligents
Encadré par : Mouna Jouini
Réalisé par : Feten Abidi
Année universitaire : 2020/2021

Remerciements
Je tiens à exprimer toute ma reconnaissance à mon encadreur Madame Jouini

Mouna. Je la remercie de m’avoir encadré, orienté, aidé et conseillé. J’adresse mes
sincères remerciements à les membres de jury et à tous les professeurs, intervenants
et toutes les personnes qui par leurs paroles, leurs écrits, leurs conseils et leurs cri-
tiques ont guidé mes réflexions et ont accepté à me rencontrer et répondre à mes
questions durant mes recherches.
...
Dédicaces
A mes chers parents, pour tous leurs sacrifices, leurs amours, leurs tendresses, leurs
soutiens et leurs prières tout au long de mes études.
A ma sœur pour leur encouragement permanent, et leur soutien moral.
A mon cher frère pour leur appui et leur encouragement.
A toute ma famille pour leurs soutiens tout au long de mon parcours universitaire.
A mes chers amis pour leurs aides, compréhension, encouragements et leurs
amours.
Merci d’être toujours là pour moi.
...
Table des matières
Introduction Générale 1
1 Cadre générale du projet 3

1.1 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Applications similaires . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Présentation de Zen Park . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Présentation d’OPnGO . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 Présentation de One Park . . . . . . . . . . . . . . . . . . . . 8
1.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Méthode de conception adoptée . . . . . . . . . . . . . . . . . . . . . 10
1.5.1 La méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2 La méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . 11
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Préparation du projet 13
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 14
2.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Pilotage de projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . 19
2.7 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 20
i
TABLE DES MATIÈRES
2.7.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . 21

2.8 Conception global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . 25
2.8.2 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . 26
2.8.3 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . 27
2.8.4 Modèle de déploiement . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Étude et réalisation du Release 1 29

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Étude de sprint 1 : Gestion d’utilisateurs . . . . . . . . . . . . . . . . 29
3.2.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Tableau des tâches . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . 31
3.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5 Réalisation et tests . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Etude de sprint 2 : Gestion des parcs . . . . . . . . . . . . . . . . . . 49
3.3.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Etude de sprint 1 : Recherche parking . . . . . . . . . . . . . . . . . . 71
4.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3 Etude de sprint 2 : Gestion des abonnements . . . . . . . . . . . . . . 78
4.3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2 Étude de sprint 1 du release 3 : Configuration des parcs . . . . . . . . 92
ii
TABLE DES MATIÈRES

5.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.3 Etude de sprint 1 : Gestion des statistiques . . . . . . . . . . . . . . . 100
5.3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.3.5 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Conclusion Générale 109
Bibliographie 110
A Annexe 112
iii
Table des figures
1.1 capture d’écran du site « Zen Park »[7] . . . . . . . . . . . . . . . . . 6

1.2 capture d’écran du site « OPnGO »[8] . . . . . . . . . . . . . . . . . 7
1.3 capture d’écran du site « One Park »[6] . . . . . . . . . . . . . . . . . 9
1.4 Cycle de vie de la méthode Scrum[9] . . . . . . . . . . . . . . . . . . 12
2.1 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . 20
2.3 vagrant[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 git[28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Virtual box[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 android[21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 apache[15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 notepad++[24] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 java script[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10 php 7[18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.11 html5[25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.12 css[26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.13 xml[27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.14 StarUML[18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.15 Overleaf[22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.16 Trello[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.17 architecture logicielle MVC[17] . . . . . . . . . . . . . . . . . . . . . . 26
2.18 architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.19 diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . . 27
2.20 diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 Tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 diagramme de cas d’utilisation détaillé du sprint 1 du release 1 . . . 31
3.3 Diagramme de séquence du cas d’utilisation « s’authentifier » . . . . 39
3.4 Diagramme de séquence du cas d’utilisation « S’inscrire » . . . . . . . 40
iv
TABLE DES FIGURES
3.5 Diagramme de séquence du cas d’utilisation « Bloquer des conduc-

teurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Diagramme de séquence du cas d’utilisation « Débloquer des conduc-
teurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 Diagramme de séquence du cas d’utilisation « Ajouter des techniciens » 43
3.8 Diagramme de séquence du cas d’utilisation « Modifier des analystes » 44
3.9 diagramme de classe détaillé du sprint 1 . . . . . . . . . . . . . . . . 45
3.10 diagramme d’activité du cas d’utilisation s’authentifier . . . . . . . . 47
3.11 Interface d’authentification : partie web . . . . . . . . . . . . . . . . . 48
3.12 tache du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.13 Diagramme de cas d’utilisation détaillée du release 1 du sprint 2 . . . 51
3.14 Diagramme de séquence du cas d’utilisation « Supprimer parc » . . . 59
3.15 Diagramme de séquence du cas d’utilisation « Ajouter emplacement » 60
3.16 Diagramme de séquence du cas d’utilisation « Supprimer emplace-
ment » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.17 Diagramme de séquence du cas d’utilisation « Ajouter service supplé-
mentaire» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.18 Diagramme de séquence du cas d’utilisation « Supprimer service sup-
plémentaire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.19 Diagramme de séquence du cas d’utilisation « Ajouter abonnement » 64
3.20 Diagramme de séquence du cas d’utilisation « Supprimer abonnement » 65
3.21 Diagramme de classe détaillée du sprint 2 . . . . . . . . . . . . . . . . 66
3.22 diagramme d’activité du cas d’utilisation ajouter parc . . . . . . . . . 68
3.23 Interface : Ajouter parking . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1 tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2 Diagramme de cas d’utilisation détaillée du sprint 1 du release 2 . . 72
4.3 Diagramme de séquence du cas d’utilisation « Localiser emplacement » 74
4.4 Diagramme de séquence du cas d’utilisation « Localiser parking » . . 75
4.5 Diagramme de classe détaillée du sprint 1 . . . . . . . . . . . . . . . . 75
4.6 Diagramme d’avtivité du sprint 1 du cas localiser parking . . . . . . . 77
4.7 Interface : Consulter parking . . . . . . . . . . . . . . . . . . . . . . . 77
4.8 tache du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.9 Diagramme de cas d’utilisation détaillé sprint 2 du release 2 . . . . . 79
4.10 Diagramme de séquence du cas d’utilisation « Réserver des places » . 85
4.11 Diagramme de séquence du cas d’utilisation « Abonner » . . . . . . . 86
4.12 Diagramme de séquence du cas d’utilisation « Commander » . . . . . 86
4.13 Diagramme de séquence du cas d’utilisation « Consulter commande » 87
4.14 Diagramme de classe détailée du sprint 2 du release 2 . . . . . . . . . 88
4.15 diagramme d’activité du cas d’utilisation modifier service . . . . . . . 90
4.16 Interface : Réservation d’une place . . . . . . . . . . . . . . . . . . . 90
5.1 tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2 Diagramme de cas d’utilisation détaillée du sprint 1 du release 3 . . . 93
v
TABLE DES FIGURES
5.3 Diagramme de séquence du cas d’utilisation « Configuration » . . . . 96

5.4 Diagramme de séquence du cas d’utilisation « Noter » . . . . . . . . . 96
5.5 Diagramme de classe détaillée du sprint 1 du release 3 . . . . . . . . . 97
5.6 Diagramme d’activité du sprint 1 cas configuration les paramètres de
parking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.7 Interface Vérification E/S . . . . . . . . . . . . . . . . . . . . . . . . 99
5.8 tache du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.9 Diagramme de cas d’utilisation détaillée du sprint 2 du release 3 . . . 101
5.10 Diagramme de séquence du cas d’utilisation « Supprimer des recom-
mandations » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.11 Diagramme de classe détaillée du sprint 2 du release 3 . . . . . . . . 104
5.12 Diagramme de classes global . . . . . . . . . . . . . . . . . . . . . . . 105
5.13 Diagramme d’avtivité du cas supprimer recommandation . . . . . . . 106
5.14 Interface statistique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.15 Interface ajouter recommandation . . . . . . . . . . . . . . . . . . . . 107
A.1 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

A.2 Question 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.3 Question 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
vi
Liste des tableaux
1.1 Analyse technique de site OPnGO . . . . . . . . . . . . . . . . . . . . 5

1.2 Analyse technique de site Zen Park . . . . . . . . . . . . . . . . . . . 7
1.3 Analyse technique de site One Park . . . . . . . . . . . . . . . . . . . 8
1.4 Tableau de comparaison et critique des solutions existantes . . . . . 9
2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Backlog du sprint 1 : Gestion d’utilisateurs . . . . . . . . . . . . . . . 29

3.2 Description textuelle du cas d’utilisation « s’authentifier » . . . . . . 32
3.3 Description textuelle du cas d’utilisation « s’inscrire » . . . . . . . . . 33
3.4 Description textuelle du cas d’utilisation «Bloquer des conducteurs» . 34
3.5 Description textuelle du cas d’utilisation «Débloquer des conducteurs» 35
3.6 Description textuelle du cas d’utilisation «Ajouter des techniciens» . 36
3.7 Description textuelle du cas d’utilisation «Modifier des analystes» . . 37
3.8 la description des classes participantes dans le premier sprint du pre-
mier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.9 Fiche de test de l’interface du connexion . . . . . . . . . . . . . . . . 49
3.10 test fonctionnel du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 49
3.11 Backlog du sprint 2 : Gestion des parcs . . . . . . . . . . . . . . . . . 49
3.12 Description textuelle du cas d’utilisation « Supprimer des parcs » . . 52
3.13 Description textuelle du cas d’utilisation « Ajouter emplacement» . . 53
3.14 Description textuelle du cas d’utilisation « Supprimer emplacement» 54
3.15 Description textuelle du cas d’utilisation « Ajouter service supplé-
mentaire» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.16 Description textuelle du cas d’utilisation « Supprimer service supplé-
mentaire» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.17 Description textuelle du cas d’utilisation « Ajouter abonnement » . . 57
3.18 Description textuelle du cas d’utilisation « Supprimer abonnement » . 58
3.19 la description des classes participantes dans le deuxième sprint du
premier release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.20 test fonctionnel du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 69
vii
LISTE DES TABLEAUX
4.1 Backlog du sprint 1 : Recherche parking . . . . . . . . . . . . . . . . 71

4.2 Description textuelle du cas d’utilisation «Localiser parking . . . . . 73
4.3 Description textuelle du cas d’utilisation «Localiser emplacement» . . 73
4.4 la description des classes participantes dans le premier sprint du
deuxième release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.5 Fiche de test de l’interface localiser parking . . . . . . . . . . . . . . 78
4.6 Backlog du sprint 2 : Gestion des abonnements . . . . . . . . . . . . 78
4.7 Description textuelle du cas d’utilisation « Réserver des places » . . 80
4.8 Description textuelle du cas d’utilisation « Abonner » . . . . . . . . 81
4.9 Description textuelle du cas d’utilisation « Commander » . . . . . . . 82
4.10 Description textuelle du cas d’utilisation « Payer » . . . . . . . . . . 83
4.11 Description textuelle du cas d’utilisation « Consulter des commandes
» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
deuxième release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.13 test fonctionnel du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1 Backlog du sprint 1 : Configuration des parcs . . . . . . . . . . . . . 92

5.2 Description textuelle du cas d’utilisation « Configuration » . . . . . . 94
5.3 Description textuelle du cas d’utilisation « Noter parking » . . . . . 95
5.4 la description des classes participantes dans le premier sprint du troi-
sième release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.5 test fonctionnel du sprint 1 du release 3 . . . . . . . . . . . . . . . . . 99
5.6 Backlog du sprint 2 : Gestion des statistiques . . . . . . . . . . . . . 100
5.7 Description textuelle du cas d’utilisation « Pré visualiser des statis-
tiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.8 Description textuelle du cas d’utilisation « Supprimer des recomman-
dations » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.9 la description des classes participantes dans le premier sprint du pre-
mier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
viii
Introduction Générale
Depuis la naissance de la voiture jusqu’à aujourd’hui, il y a une augmentation im-

portante de sa production vue qu’elle rend beaucoup de service, cette augmentation
provoque le problème de manque des places de stationnement dans les parkings.
Les villes ont remarqué que les conducteurs avaient des problèmes pour trouver
une place de stationnement facilement.
Les automobilistes qui tournent dans la Ville pour chercher une place de parking.
Ce qui entraine des embouteillages, l’encombrement des rues et la pollution de la
ville et plus de ça la perte de temps.
La gestion du parking est un ensemble de stratégies visant à accroître l’efficacité
de l’offre de stationnement actuelle dans une vile. Ces stratégies incluent la mise en
place de règles de bon usage mais aussi de systèmes de priorisation ou de lieux parta-
gés entre utilisateurs. Un logiciel de parking management peut aider les utilisateurs
à travailler de manière plus efficace et efficiente.
Notre objectif est de sécuriser les voitures et les biens des conducteurs de conduc-
teurs et de réduire les embouteillages. En effet, on vise développer un système de
gestion des parkings qui aidera à un gain financier, mais c’est aussi un gain pour
l’environnement.
Le présent rapport présentera les différentes étapes de la réalisation de ce projet
et s’étalera sur cinq chapitres :
— Le premier chapitre cadre générale du projet est un chapitre introductif dans
lequel nous effectuons une brève présentation du projet. Ensuite, nous expo-
sons l’étude de l’existant du projet et la solution proposée et la méthode de
conception adoptée.
— Le deuxième chapitre nommé préparation du projet définit la réalisation de
ce travail avec la méthodologie Scrum. Nous dégageons également les besoins
fonctionnels dans un Backlog de produit et nous définissons le planning des
sprints. Par la suite, nous spécifions les besoins fonctionnels illustrés par des
diagrammes de cas d’utilisation avec quelques scénarios suivis d’une spécifi-
cation des besoins non fonctionnels de notre application et l’initialisation du
projet et la mise en place de l’environnement de développement, l’architecture
ainsi que l’environnement matériel et logicielle.
1
CHAPITRE 0. INTRODUCTION GÉNÉRALE
— Le chapitre suivant sera dédié aux trois releases de notre application où nous
nous intéressons à la réalisation des sprints répartis chacun en quatre modules,
analyse, conception, réalisation et test.
Nous clôturons, finalement, ce rapport par une conclusion générale dans laquelle
nous évaluerons les résultats atteints et nous exposerons les perspectives éventuelles
du présent projet.
2
Chapitre 1
Cadre générale du projet
Dans ce chapitre, nous allons définir le cadre du projet en déterminant tout

d’abord la problématique. Ensuite, on va la critiquer et proposer les solutions ap-
portées à ces problèmes. L’analyse et le critique de l’existant nous ont permis de
cerner nos objectifs afin de développer un système de qualité dans le futur. Par la
suite, nous expliquons le choix de la méthode de conception la plus adéquate à notre
projet.
1.1 Présentation du Projet

1.1.1 Problématique
De nos jours, la majorité des entreprises tunisiennes ont déjà installé un logiciel
de gestion parc automobile qui leur permet de gérer les parcs, les véhicules, les
emplacements, gérer les réservations.
La gestion d’un parc automobile consiste à superviser, coordonner et faciliter les
activités relatives au transport et à la logistique. Elle sous-tend ces activités par la
gestion des actifs utilisés.
Dans une entreprise, le parc auto est considéré comme un centre de coût, sa
gestion est un métier complexe qui doit s’exercer indépendamment des loueurs. Il
est donc primordial d’avoir une gestion précise de toutes les opérations liées à votre
flotte auto. iParc réduit le temps d’immobilisation des véhicules et augmente la
productivité des utilisateurs (qu’il s’agisse de véhicules commerciaux, d’après-vente
ou de transport).
Quel que soit le mode de gestion choisi par l’entreprise (gestion interne ou par-
tiellement externalisée), l’acquisition d’un progiciel de gestion de parc se traduit par
des gains de productivité et par des économies sensibles, à travers :
— L’optimisation des choix de gestion
— La maîtrise des coûts
3
CHAPITRE 1. CADRE GÉNÉRALE DU PROJET
— Une gestion administrative rapide et facile

Avec le développement des nouvelles technologies et la stabilisation des moyens de
paiement sur le net beaucoup de ces entreprises voudraient être présentes activement
sur le net, à travers un site web ou même une application mobile pour gérer les
ressources de leurs parcs.
Or, un des freins qui se pose pour ces entreprises est le traitement manuel qui
n’est pas fiable, l’absence d’une base de données et le non archivage des documents
utilisés pour les différentes tâches rendent quasiment impossible l’établissement de
statistiques fiables, et la sauvegarde des réparations sur papier implique la perte
de temps pour la prise des décisions. D’autre part, on a beaucoup de problèmes
d’encombrement et de difficulté pour trouver une place vide. Spécifiquement les
conducteurs rencontrent des obstacles suivants :
— Manque de places de stationnement
— Risque de vol
— Trop de véhicules mal garés encombrant nos rues
— La collision
Au cours de ce projet de fin d’étude, nous avons eu comme objectif de réussir à
établir une application intelligente de réservation de parking intelligent. Cette ap-
plication est destinée aux conducteurs pour sécuriser leurs voitures et pour réduire
les embouteillages. Cette application permet de réserver une place en ligne.
1.1.2 Objectif du projet

En plus des objectifs classiques que n’importe qu’elle entreprise cherche à réaliser
à savoir :
— Améliorer la sécurité d’accès aux données.
— Réduction de temps de traitement, de recherche et de diffusion des informa-
tions.
— Réduction des coûts et de l’espace de stockage et de classement des données.
— La maitrise, la rationalisation et la réduction des dépenses en matière de car-
burants et de pièce de rechange
— Garder un historique des opérations réalisées facile à consulter à temps réel
Nous avons voulu également atteindre les objectifs suivants :
— Une meilleure répartition des véhicules dans les parcs
— Un suivi efficace de l’entretien des véhicules du parc.
— Une bonne gestion du personnel du Parc Automobile.
— La rapidité, la fiabilité et la facilité des traitements.
— L’archivage, la sécurité et la confidentialité des données.
4
1.2 Étude de l’existant

L’étude de l’existant permet de déterminer les points faibles et les points forts
d’un produit actuel pour pouvoir déterminer les besoins du client, en vue d’en
prendre en considération lors de la conception et la réalisation de produit infor-
matique. Dans cette section, nous présentons une analyse de quelques exemples
d’applications marchands. Ensuite, nous formulerons une solution de la probléma-
tique.
1.2.1 Applications similaires

1.2.2 Présentation de Zen Park
1.2.2.1 Description de Zen Park
Zen Park est une application mobile qui propose des solutions de parking adap-
tées aux entreprises possédant déjà un parking ou non.
1.2.2.2 Analyse fonctionnelle de Zen Park

Cette application permet aux conducteurs de :
* Localiser les parkings du réseau
* Connaître le détail de chaque parking et réserver
* Me faire guider vers le parking de mon choix
* Ouvrir les portes du parking et stationner grâce à la fonction Zenpass.
1.2.2.3 Analyse technique de ce site
Table 1.1 – Analyse technique de site OPnGO
Dénotations Description
Logo Il s’agit de 3 couleurs (rose, vert, blanc). Il se situe à la
droite de la page.
La page d’accueil est Cette disposition donne un sens de lecture qui rend la
disposée verticalement page plus simple
Liste de menu Menu est non organisé et ne facilite pas aux utilisateurs
la cherche au sein d’application.
La gamme de couleurs Le Blanc est pour l’utilisation dans l’arrière-plan. Le
utilisés est le rose, le Rose est utilisé pour le menu à droite. Le Bleu est uti-
bleu, et le blanc. lisé dans la liste des menus au haut. L’assemblage de
ces couleurs donne une cohérence aux différentes pages
d’application.
5
Figure 1.1 – capture d’écran du site « Zen Park »[7]
1.2.3 Présentation d’OPnGO

1.2.3.1 Description d’OPnGO
OPnGO, filiale digitale du Groupe INDIGO, a été créée afin de rendre la vie et
l’expérience de stationnement plus agréables dans les villes.
1.2.3.2 Analyse fonctionnelle du site

Cette application permet aux conducteurs de
— Choisir le parking qui correspond à vos critères et à vos besoins de stationne-
ment
— Ajouter plusieurs véhicules à votre compte
— Gérer vos factures de stationnement ou notes de frais à partir de votre histo-
rique
— Gérer tous vos stationnements depuis une seule et même application
6
Table 1.2 – Analyse technique de site Zen Park
Logo Il s’agit de 3 couleurs (noir, jaune, blanc), et il se situe
au bas de la page.
Liste de menu Mieux organisé et facilite aux utilisateurs la recherche
au sein d’application.
La gamme de couleurs Le noir est utilisé pour l’arrière-plan Et le jaune est uti-
utilisés est blanc, noir lisé au bas de l’arrière-plan. Le blanc est utilisé pour
et jaune le menu au milieu. Le noir est utilisé pour la liste des
menus en haut. L’assemblage de ces couleurs donne une
cohérence aux différentes d’application.
Figure 1.2 – capture d’écran du site « OPnGO »[8]
7
1.2.4 Présentation de One Park

1.2.4.1 Description de One Park
Onepark est une plateforme de réservation de parking sur internet et sur une
application mobile permettant de comparer, réserver et payer une place de parking.
1.2.4.2 Analyse fonctionnelle du site

Cette application permet aux conducteurs de
— Trouvez le parking idéal
— Réserver votre place
— Garez-vous sereinement
Table 1.3 – Analyse technique de site One Park
Logo Il s’agit de 2 couleurs (bleu, blanc), et il est situé au
milieu de la page.
Liste de menu Il est organisé et facilite la cherche aux utilisateurs de
au sein d’application.
La gamme de couleurs Le blanc est utilisé dans l’arrière-plan. Le bleu est utilisé
utilisés est le blanc, et pour le menu à droite. Le noir est utilisé pour la liste
le bleu des menus en haut. L’assemblage de ces couleurs donne
une cohérence aux différentes pages du site.
8
Figure 1.3 – capture d’écran du site « One Park »[6]
1.3 Critique de l’existant

Les systèmes de gestion du parc automobile permettant de faciliter la vie des
conducteurs. Mais, ces systèmes restent toujours limités à utiliser à cause de certains
problèmes à savoir
— Elles sont très cher plus que d’autres
— Problème de connexion
— La localisation fonctionne moyennement
— Application lente
— L’application ne gère pas toujours les heures
— Problème lors de paiement
Voilà un tableau de comparaison et critique des solutions existantes
Table 1.4 – Tableau de comparaison et critique des solutions existantes
Critère Zen Park OPnGO One Park

L’ergonomie Oui Non Non
Sécurité Non Oui Oui
Fiabilité Oui Oui Non
Disponibilité Oui Non Oui
S’inscrire Oui Oui Oui
9
1.4 Solution proposée

Nous proposons, par le biais de cette application, de faire réservation en ligne.
L’outil réalisé permettra de réserver une place pour garer la voiture plus facilement.
De plus, ce projet répond à un besoin très important qui a comme but de réduit
l’encombrement.
Le stationnement intelligent, ou smart parking, se définit comme suit : une ap-
plication de technologies avancées pour améliorer la rapidité et l’efficacité avec les-
quelles un automobiliste peut localiser, réserver et payer pour obtenir un espace de
stationnement.
Ce projet rentre dans le cadre du projet de plusieurs études qui vient de conclure
notre formation de licence au Faculté des Sciences Juridiques Économiques et de
Gestion de Jendouba. L’application demandée s’intitule smart parking.
Elle a pour objectif de la conception et le développement de gestion des parkings
intelligents.
Cette application est destinée aux conducteurs pour
— Réduire les embouteillages
— Guidage à la place
— Sécuriser les voitures et les biens des conducteurs
— Réserver des places pour les handicaps
— Ajouter des services supplémentaires
— Réduction du temps de recherche d’une place de parking
— Optimiser le taux d’occupation
La mise en place de réservation de parking intelligent nécessite le développement de
trois axes à savoir :
• Axe Gestion du projet : Utilisation de la méthode agile Scrum
• Axe modélisation conceptuelle : Utilisation du langage de modélisation UML
(Unied Modeling Language) pour développer les axes fonctionnel, statique et dyna-
mique
• Axe de développement : utilisation du langage PHP7 et l’utilisation de la
plateforme de développement vagrant et Git.
1.5 Méthode de conception adoptée

La réalisation du projet dans les délais de livraison est le souci majeur de chaque
équipe de développement d’un logiciel. L’un des problèmes les plus fréquemment lors
de la construction du logiciel est la mauvaise spécification et le changement brusque
des besoins. Cela peut influencer non seulement l’équipe de développement en créant
10
un environnement de stress, mais aussi le temps consacré pour la réalisation du projet

et donc des délais de livraison dépassées.
An d’éviter ces situations critiques, nous adoptons la méthodologie agile pour la
gestion de notre projet. Les méthodes agiles ont permis de pouvoir faciliter l’orga-
nisation de projet et la gestion des différentes tâches. Ce sont des approches incré-
mentales et itératives, menées dans un esprit collaboratif, avec juste ce qu’il faut de
formalisme.
1.5.1 La méthode Scrum

La méthode SCRUM définit un cadre de travail permettant la réalisation de pro-
jets complexes. Initialement prévu pour le développement de projets type « Software
», cette méthode peut être appliquée à tout type de projet, du plus simple au plus
innovant, et ce de manière très simple.
Les projets qui suivent la méthode Agile « SCRUM » sont divisés en plusieurs
cycles de travail relativement court que l’on appelle « sprints ». Ces derniers per-
mettent aux membres de l’équipe d’évaluer régulièrement les progrès liés au projet
et de planifier les prochaines étapes de développement. Mais cela permet surtout de
réajuster ou réorienter la direction prise par le projet si besoin est, à partir d’une
base de travail déjà achevée et validée (sprint).
Chaque projet utilisant la méthode SCRUM s’organise autour d’une équipe auto-
organisée car il n’y a pas de chef d’équipe qui décide des rôles de chacun, ou de la
manière dont un problème est résolu, puisque ces problématiques sont traitées par
l’équipe dans son ensemble ; et multifonctionnelle car chaque membre de l’équipe est
parti prenant dans le développement de chaque fonctionnalité, de l’idée à l’implé-
mentation finale. [ref3].
1.5.2 La méthodologie Scrum

Scrum est la méthodologie suivie par la société Sopra HR Software pour la gestion
de ses projets. C’est une méthodologie agile itérative basée sur des itérations de
courtes durées appelées Sprints. Lorsqu’on dit Scrum, il faut comprendre les artefacts
suivants : [ref3]
• Responsable Produit : le représentant des clients et des utilisateurs. Il déter-
mine ce qui doit être réalisé.
• Scrum Master : le responsable du déroulement du processus. Il garantit la
motivation de l’équipe et la capacité de la collaboration entre les membres.
• Équipe projet : Les développeurs chargés de la construction du logiciel et d’en
faire une démonstration.
• Backlog du produit : tout le travail est encadré par le Backlog. En met, tout
le projet est découpé en un ensemble de "User Stories" classés par priorité et listés
dans le backlog.
11
• Backlog du sprint : une sélection de tâches retenues du "backlog du produit"

pour construire l’objectif du sprint.
• Daily Meeting : c’est un point quotidien qui permet de mettre le point sur ce
qui a été réalisé, les problèmes rencontrés et les objectifs de la journée.
Démonstration du sprint : on la nomme aussi "Sprint Review". C’est une réunion
programmée à la n de chaque sprint durant laquelle l’équipe projet peut présenter
son travail. Sur la base d0e cette démonstration, le responsable produit valide ce qui
a été réalisé et détermine le nouvel objectif en se basant sur le Backlog du produit
et si jamais n’il y a un ajout ou bien une modification dans ce dernier.
Figure 1.4 – Cycle de vie de la méthode Scrum[9]
1.6 Conclusion
Tout au long de ce chapitre nous avons pu dégager le contexte général du projet
et présenter le choix de la méthodologie de développement. Le chapitre suivant sera
consacré à l’analyse des besoins.
12
Chapitre 2
Préparation du projet
2.1 Introduction
Ce chapitre présente l’étude des besoins qui constitue une phase d’analyse du
projet. Nous allons présenter tous d’abord les acteurs principaux de l’application
et le Backlog de produit. Ensuite, nous allons identifier les besoins fonctionnels et
non fonctionnels de l’application et le diagramme de cas d’utilisation global et la
planification des sprints. En fin, nous donnons un bref aperçu sur le matériel de base,
les technologies et les langages de programmation utilisés pour la mise en place de
l’environnement de travail.
2.2 Capture des besoins

L’identification des besoins consiste à traduire les objectifs du projet en un en-
semble de fonctionnalités ciblées par l’outil à réaliser. Ceci procurera une compré-
hension plus approfondie des tâches à mettre en œuvre.
2.2.1 Identification des acteurs

Un acteur représente une entité externe qui interagit avec le système. En réponse
à l’action d’un acteur, le système fournit un service qui répond à ses besoins [1]
.Notre application présente principalement deux acteurs identifiés dans les acteurs
suivants :
— Responsable de parking qui gère le paramétrage et les services supplémentaires
de parking, il est responsable de paramétrage de l’application. Son rôle est de
gérer les environnements et les utilisateurs.
— Les conducteurs qui font la réservation des places et la commande des services
supplémentaires.
— Les techniciens qui gèrent les commandes demandées par les conducteurs.
13
CHAPITRE 2. PRÉPARATION DU PROJET
— L’analyste qui va gérer les recommandations et prévisualiser les statistiques.
2.2.2 Besoins fonctionnels

Les besoins fonctionnels doivent expliciter ceux du client. Dans notre cas, des
besoins exprimés par les acteurs de notre application ont permis d’établir le cahier
des charges suivant : Cette solution devra entre autres assurer les attentes suivantes :
— Responsable :
• Gestion des parcs
• Gestion d’emplacement
• Gestion des types d’abonnements
• Gestion des conducteurs
• Gestion des techniciens
• Gestion des analystes
• Configuration de paramètres de parking
• Vérification d’entrée/sortie
• Gérer les services supplémentaires
— Analyste :
• Prévisualisation des statistiques
• Gestion des recommandations
— Techniciens :
• Gérer les commandes demandées par les conducteurs.
— Conducteurs :
• S’inscrire
• Localiser parking
• Localiser emplacement
• Réservation des places
• S’abonner
• Payer
• Commander des services supplémentaires
• Noter parking
2.2.3 Besoins non fonctionnels

Pour compléter les besoins fonctionnels, notre projet devra respecter un ensemble
de propriétés contribuant à une meilleure qualité de la solution obtenue. Parmi ces
critères on retrouve :
* L’ergonomie : Etant donné que notre application va être utilisé par acteur 1 les
interfaces doivent être réalisées de telle façon que l’utilisateur s’y trouve facilement
et ceci en respectant la charte graphique demandé par le client.
14
* Performance : il s’agit d’optimiser le temps de chargements des donnés depuis

deux environnements différents ainsi que par l’utilisation des bonnes pratiques du
développement.
* L’évolutivité : l’application peut avoir des extensions, en intégrant des nouveaux
modules pour répondre aux nouveaux besoins fonctionnels et ceci sans modifier les
modules déjà existants.
* Portabilité : doit être facile à utiliser et doit être accessible par pc, tablette ou
téléphone.
* La sécurité : L’accès à l’application et les données doit être sécurisé. Pour gérer
les autorisations aux différents modules de l’application on a utilisé Spring Security,
L’affectation des droits d’accès est réalisée à travers des écrans d’administration.
2.3 Backlog produit

Le Backlog de produit correspond à une liste priorisée des besoins et des exigences
du client. Les éléments du Backlog de produit, appelé aussi les histoires utilisateurs,
sont formulés en une ou deux phrases décrivant de manière claire et précises la
fonctionnalité désirée par le client, généralement, écrit sous la forme suivante En
tant que X, je veux Y, afin de Z.
Le Backlog de produit présenté dans le tableau 1 comprend les champs suivants :
ID : C’est un nombre unique et auto-incrémenté pour chaque histoire utilisateur.
User Story : C’est une phrase décrivant la fonctionnalité désirée par le client.
Priorité : C’est la valeur métier qui dirige la priorisation du développement des
histoires utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100.
Story Point : C’est l’effort nécessaire à la réalisation d’une histoire utilisateur.
Nous avons pu établir une étude afin de répartir ces stories par priorité.
Les normes sur lesquelles nous nous sommes basés, sont :
• Complexité
• Priorité : par rapport au client (Entreprise) représentée suivant la méthode
"MoSCoW" qui est Une technique possédant un objectif qui s’articule autour d’un
accord entre le maître d’œuvre (MOE) et le maître d’ouvrage (MOA) sur l’impor-
tance des tâches que l’on va réaliser par rapport aux délais prévus. MoSCoW a pour
signification :
M : doit être fait (vital).
S : devrait être fait dans la mesure du possible (essentiel).
C : pourrait être fait dans la mesure où cela n’a pas d’impact sur les autres
tâches(confort).
W : ne sera pas fait cette fois mais sera fait plus tard (luxe, c’est la zone d’opti-
misation budgétaire).
Dans le tableau suivant, nous présentons la liste des histoires utilisateurs ainsi
que leurs estimations. Nous avons listé les besoins et les exigences du client selon
l’ordre croissant de priorité :
15
Table 2.1 – Backlog produit
ID Feature User Story Complexité Priorité
1 Se connecter En tant que conducteur,je veux M 1

connecter
2 s’inscrire En tant que conducteur,je veux M 1

m’inscrire
3 Réservation de En tant que conducteur je veux M 1

places réserver une place pour garer ma
voiture
4 Commandes de je veux commander des services S 2

services supplémentaires pour améliorerl’état
supplémentaires de ma voiture
5 Gérer des En tant que responsable je veux gérer S 1

conducteurs des conducteurs

techniciens des techniciens
7 Gérer des parcs En tant que responsable je veux gérer S 1

des parcs
16

emplacements des emplacements
9 Gérer les En tant que responsable je veux gérer S 1

services les service supplémentaires
supplémentaires
Localiser En tant que conducteur je veux S 2

10 emplacement localiser un emplacement
Localiser En tant que conducteur je veux S 2

11 parking localiser un parking
Gérer des types En tant que responsable je veux gérer S 1

12 d’abonnements des types d’abonnements
Abonner En tant que conducteur je veux W 2

13 abonner
Configuration En tant que responsable je veux M 3

14 du paramètres configurer les paramètres de parking
de parking
Vérification E/S En tant que responsable je veux M 3

15 vérifier E/S
17
Noter parking En tant que conducteur je veux noter W 3

16 parking
Prévisualisation En tant que analyste je veux contrôler M 3

17 des statistiques le parking
Gestion de re- En tant que analyste je veux faire des M 3

18 commandations recommandations
Gestion des En tant que responsable je veux gérer S 1

19 analystes des analystes
Gérer les En tant que technicien je veux gérer S 1

20 commandes les commandes demandées par les
conducteurs
2.4 Pilotage de projet avec Scrum

L’équipe Scrum est constituée d’un propriétaire de produit, de l’équipe de déve-
loppement et d’un Scrum Master. Nous présentons dans cette partie l’ensemble des
acteurs participants au déroulement des différentes phases du projet et d’élaboration
du rapport du stage. Dans notre cas, l’équipe de développement est constituée :
* Product Owner (PO) : Madame Jouini Mouna Son rôle est d’assurer la pré-
sentation des caractéristiques et des fonctionnalités du produit à développer et ap-
probation du produit à livrer.
* Scrum Master (SM) : Madame Jouini Mouna Le Scrum Master assure globale-
ment la Supervision de l’avancement du projet et des activités de l’équipe. Il assure
également l’organisation des réunions et la bonne application de la méthode AGILE
de par ce biais.
* L’équipe de développement : Mme Abidi Feten comporte une ou plusieurs
personnes qui se chargent de la réalisation des histoires utilisateurs et élaboration
18
des sprints.
2.5 Planification des sprints

Les "User stories" précédemment dénis dans le Backlog du produit sont triés par
ordre de priorités et de valeurs métiers. Le but étant d’implémenter en premier ce
qui a le plus de valeur. Le travail sera planifié selon des sprints que nous avons définis
et chacun dure deux semaines. Après une réunion avec l’équipe, on a identifié cinq
sprints et trois releases. Dans le tableau 3.2, nous présentons la planification des
sprints
Figure 2.1 – Planification des Sprints
Cette planification est préliminaire, les Backlogs de sprints seront définis au fur
et à mesure là fin de chaque sprint et ceci dépendra de la vélocité et de la capacité
de l’équipe par lesquelles on entend la rapidité de l’équipe dans la finalisation des
tâches.
2.6 Diagramme de cas d’utilisation global

Nous commençons par offrir une vue d’ensemble des différentes fonctionnalités
offertes par notre application, à l’aide d’un diagramme de cas d’utilisation global. En
19
effet, le diagramme de cas d’utilisation a pour but de donner une vision globale sur
les fonctionnalités les plus importants de futur système. Ils permettent de représenter
l’ensemble d’actions réalisées par le système en réponse à une action d’un acteur [1,
2, 3] . Nous allons maintenant présenter le diagramme global des cas d’utilisation
afin de décrire le comportement de notre système de point de vue utilisateur.
La figure 1 illustre le diagramme de cas d’utilisation général.
Figure 2.2 – diagramme de cas d’utilisation général
2.7 Environnement de travail

2.7.1 Environnement matériel
Tout au long de notre projet, nous avons eu à notre disposition un ordinateur
portable ASUS qui dispose de la configuration suivante :
Processeur : Intel(R) Core(TM) i3-7020U CPU @ (2.30 GHz, 2.30 GHz)
20
Mémoire : 8 GO de RAM
Système d’exploitation : Windows 10
Type de système : Système d’exploitation 64 bits,processeur x64
2.7.2 Environnement logiciel

Cette section sert à définir les langages et outils utilisées pour le développement
de mon application.
a) Environnement vagrant :
* vagrant : Vagrant est un logiciel libre et open-source pour la création et la
configuration des environnements de développement virtuel. Il peut être considéré
comme un wrapper autour de logiciels de virtualisation comme Virtual Box.
Figure 2.3 – vagrant[20]
* Git : Git est un logiciel de gestion de versions décentralisé. C’est un logiciel

libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de
la licence publique générale GNU version 2. En 2016, il s’agit du logiciel de gestion
de versions le plus populaire qui est utilisé par plus de douze millions de personnes.
Figure 2.4 – git[28]
* Virtual box : Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel

libre de virtualisation publié par Oracle.
Figure 2.5 – Virtual box[23]
* MySQL : MySQL est un serveur de bases de données relationnelles Open

Source.
21
b) Environnement mobile :
* Android studio : Android Studio est un environnement de développement pour
développer des applications mobiles Android. Il est basé sur IntelliJ IDEA et utilise le
moteur de production Gradle. Il peut être téléchargé sous les systèmes d’exploitation
Windows, macOS, Chrome OS et Linux.
Figure 2.6 – android[21]
* Apache : Le logiciel libre Apache HTTP Server (Apache) est un serveur HTTP
créé et maintenu au sein de la fondation Apache. Jusqu’en avril 20193, ce fut le
serveur HTTP le plus populaire du World Wide Web. Il est distribué selon les termes
de la licence Apache.
Figure 2.7 – apache[15]
e) Environnement framework : * Notepad++ : Notepad++ est un éditeur de

texte libre générique, fonctionnant sous Windows, codé en C++, qui intègre la colo-
ration syntaxique de code source pour les langages et fichiers C, C++, Java, C, XML,
HTML, PHP, JavaScript, makefile, art ASCII, doxygen, .bat, MS fichier ini, ASP,
Visual Basic/VBScript, SQL, Objective-C, CSS, Pascal, Perl, Python, R, MATLAB,
Lua, TCL, Assembleur, Ruby, Lisp, Scheme, Properties, Diff, Smalltalk, PostScript
et VHDL ainsi que pour tout autre langage informatique, car ce logiciel propose la
possibilité de créer ses propres colorations syntaxiques pour un langage quelconque.
Figure 2.8 – notepad++[24]
• Langage de programmation :
* JavaScript : JavaScript est un langage de programmation de scripts principale-
ment employé dans les pages web interactives et à ce titre est une partie essentielle
22
des applications web. Avec les technologies HTML et CSS, JavaScript est parfois
considéré comme l’une des technologies cœur du World Wide Web.
Figure 2.9 – java script[23]
* Php7 : Hypertext Preprocessor19, plus connu sous son sigle PHP (sigle auto-
référentiel), est un langage de programmation libre20, principalement utilisé pour
produire des pages Web dynamiques via un serveur HTTP19, mais pouvant égale-
ment fonctionner comme n’importe quel langage interprété de façon locale. PHP est
un langage impératif orienté objet.
Figure 2.10 – php 7[18]
* Java : Java est un langage de programmation orienté objet créé par James
Gosling et Patrick Naughton, employés de Sun Microsystems, avec le soutien de Bill
Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23 mai
1995 au SunWorld.
* SQL : SQL (sigle de Structured Query Language, en français langage de re-
quête structurée) est un langage informatique normalisé servant à exploiter des bases
de données relationnelles. La partie langage de manipulation des données de SQL
permet de rechercher, d’ajouter, de modifier ou de supprimer des données dans les
bases de données relationnelles.
• Création des interfaces :
* HTML : Le HyperText Markup Language, généralement abrégé HTML ou dans
sa dernière version HTML5, est le langage de balisage conçu pour représenter les
pages web.
Figure 2.11 – html5[25]
23
* CSS : Cascading Style Sheets (feuilles de styles en cascade), servent à mettre

en forme des documents web, type page HTML ou XML. Par l’intermédiaire de
propriétés d’apparence (couleurs, bordures, polices, etc.) et de placement (largeur,
hauteur, côte à côte, dessus-dessous, etc.), le rendu d’une page web peut être inté-
gralement modifié sans aucun code supplémentaire dans la page web. Les feuilles de
styles ont d’ailleurs pour objectif principal de dissocier le contenu de la page de son
apparence visuelle.
Figure 2.12 – css[26]
*XML : L’Extensible Markup Language, généralement appelé XMLnote 1, «

langage de balisage extensible1 » en français, est un métalangage informatique de
balisage générique qui est un sous-ensemble du Standard Generalized Markup Lan-
guage (SGML).
Figure 2.13 – xml[27]
StarUML : est un logiciel de modélisation UML, qui a été « cédé comme open
source » par son éditeur, à la fin de son exploitation commerciale (qui visiblement
continue ...), sous une licence modifiée de GNU GPL.
Figure 2.14 – StarUML[18]
• Editeur de texte :
Overleaf : est un éditeur LaTeX en ligne, collaboratif en temps réel.
24
Figure 2.15 – Overleaf[22]
• Outil de gestion de projet :

Trello : est un outil de gestion de projet en ligne.Il repose sur une organisation
des projets en planches listant des cartes, chacune représentant des tâches. Les cartes
sont assignables à des utilisateurs et sont mobiles d’une planche à l’autre, traduisant
leur avancement.
Figure 2.16 – Trello[19]
2.8 Conception global

Avant de se lancer dans la conception et le développement, nous allons préparer
notre architecture. Dans cette partie, nous nous intéressons à l’architecture opéra-
tionnelle et logicielle de notre application.
2.8.1 Architecture logicielle

L’architecture logicielle de notre application est l’architecture Modèle-vue-contrôleur
ou MVC. C’est un motif d’architecture logicielle destiné aux interfaces graphiques
lancé en 1978 et très populaire pour les applications web. Le motif est composé
de trois types de modules ayant trois responsabilités différentes : les modèles, les
vues et les contrôleurs. Un modèle (Model) contient les données à afficher. Une vue
(View) contient la présentation de l’interface graphique. Et un contrôleur (Control-
ler) contient la logique concernant les actions effectuées par l’utilisateur.
25
Figure 2.17 – architecture logicielle MVC[17]
2.8.2 Architecture matérielle

L’architecture matérielle décrit l’agencement interne de composants électroniques
ainsi que leurs interactions. L’architecture trois tiers, aussi appelée architecture à
trois niveaux ou architecture à trois couches, est l’application adoptée par notre ap-
plication. L’architecture logique du système est divisée en trois niveaux ou couches :
• La présentation des données, correspondant à l’affichage, la restitution sur le
poste de travail, le dialogue avec l’utilisateur.
• Le traitement métier des données, correspondant à la mise en œuvre de l’en-
semble des règles de gestion et de la logique applicative. • l’accès aux données
persistantes : correspondant aux données qui sont destinées à être conservées sur la
durée, voire de manière définitive.
Figure 2.18 – architecture matérielle
26
2.8.3 Diagramme de paquetages

Un diagramme de packages est un diagramme fait partie des diagrammes UML
qui fournit une représentation graphique de haut niveau de l’organisation d’une
application. Il permet d’identifier les liens de généralisation et de dépendance entre
les packages. En effet, cette figure présente les différents paquetages qui composant
notre système et les relations qui lient ces différents paquetages.
Figure 2.19 – diagramme de paquetages
2.8.4 Modèle de déploiement

En UML, un diagramme de déploiement est une vue statique qui sert à repré-
senter l’utilisation de l’infrastructure physique par le système et la manière dont les
composants du système sont répartis ainsi que leurs relations entre eux. Les éléments
utilisés par un diagramme de déploiement sont principalement les nœuds, les compo-
sants, les associations et les artefacts. Les caractéristiques des ressources matérielles
physiques et des supports de communication peuvent être précisées par stéréotype.
La figure ci-dessous illustre le diagramme de déploiement
27
Figure 2.20 – diagramme de déploiement
2.9 Conclusion
Ce chapitre nous a permis de bien délimiter le projet et d’avoir une vision plus
claire du sujet. Nous avons décrit les besoins fonctionnels, non fonctionnels, les
acteurs et le Backlog produit. Par la suite, il nous a permis de planifier et organiser
le temps consacré à la réalisation du projet en identifiant les sprints. Puis, nous avons
décrit les cas d’utilisation qui sont nécessaires ainsi leurs descriptions textuelles.
Nous avons procédé à l’initialisation du projet et la mise en place de l’envi-
ronnement de développement. L’architecture ainsi que l’environnement matériel et
logiciel.
Dans le chapitre suivant, nous allons faire une présentation du release 1.
28
Chapitre 3
Étude et réalisation du Release 1
3.1 Introduction
Dans ce chapitre, nous allons détailler le travail réalisé durant le premier release.
En effet, chaque release, qui est l’ensemble d’itérations (sprint), représente une vision
distribuée de la période de la production du livrable. Ce premier Release comprend
deux sprints :
Sprint 1 « Authentification Inscription, Gestion des profils, Gestion des techni-
ciens, Gestion des analystes et Gestion des conducteurs »
Sprint 2 « Gestion des parcs, Gestion d’emplacements, Gestion de types d’ abon-
nements et Gestion des services supplémentaires »
3.2 Étude de sprint 1 : Gestion d’utilisateurs

3.2.1 Backlog du sprint 1
Le sprint est un bloc de temps durant lequel un incrément du produit sera réa-
lisé. Tous les sprints d’une release (ou version) 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 terminé. Avant de se lancer dans un sprint, l’équipe Scrum
doit obligatoirement définir le but de ce dernier qui doit être un tableau descriptif
qui précise la charge du travail pour chaque tâche en nombre de jours.
Table 3.1 – Backlog du sprint 1 : Gestion d’utilisateurs
ID Histoire Uses story Estimation
1 Se connecter En tant que utilisateur je veux 3 jrs

authentifier
29
CHAPITRE 3. ÉTUDE ET RÉALISATION DU RELEASE 1
2 S’inscrire En tant que conducteur je veux 4 jrs

s’inscrire
3 Gestion des En tant que responsable je veux gérer 3 jrs

analystes des analystes

techniciens des techniciens

conducteurs des conducteurs
3.2.2 Tableau des tâches

Le tableau des tâches est une présentation physique du backlog du sprint per-
mettant à tout le monde de connaître l’avancement des développements du sprint.
Il est composé de 3 colonnes :
• À réaliser : liste des tâches à traiter (une tâche est un élément de développement
d’une User Story)
• En cours : liste des tâches en cours de développement
• Terminée : liste des tâches terminées
Figure 3.1 – Tache du sprint 1
30
3.2.3 Spécification fonctionnelle

Dans cette partie nous présentons la phase d’analyse qui répond à la question
« que fait le système ». La réponse de cette question se traduit par la présentation
du diagramme des cas d’utilisation puis la description textuelle de chacun d’entre
eux. subsubsectionDiagramme de cas d’utilisation détaillé du release 1 du sprint 1
La figure 3.1 décrit le diagramme de cas d’utilisation détaillé du release 1 du premier
sprint.
Figure 3.2 – diagramme de cas d’utilisation détaillé du sprint 1 du release 1
31
3.2.3.1 Descriptions textuelles des cas d’utilisations
Table 3.2 – Description textuelle du cas d’utilisation « s’authentifier »
Titre Se connecter
Acteur Utilisateur : conducteur ,analyste, responsable, technicien
Pré-condition(s)
— L’utilisateur doit être inscrit
— L’utilisateur doit connaitre ses identifiants
— L’utilisateur doit accéder à la page d’accueil
Post-condition(s) L’utilisateur accède à son espace personnel

Scénario Nominal Se cas d’utilisation commence lorsque l’utilisateur accéder
notre site :
1. L’utilisateur demande la page d’authentification .
2. Le system lui affiche la page demandée.
3. L’utilisateur saisit son pseudo et son mot de passe.
4. L’utilisateur valide l’authentification.
5. Le système vérifie les données saisies.
6. Le système affiche l’espace personnel du client.
Scénario Alternatif 1. l’utilisateur quitte (annule) la page d’authentification :

1. Le cas d’utilisation se termine avec échec.
2. Le membre n’a pas saisi les bons identifiants (contrôle de
saisie) :
1. Le système affiche un message d’erreur et signale au utili-
sateur de recommencer la saisie.
2. Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
3. Les identifiants saisis n’existent pas dans la base de don-
nées :
1. Le système affiche le message d’erreur suivant « vous devez
saisir des identifiants valides ou s’inscrire » et signale au client
de recommencer la saisie.
32
Table 3.3 – Description textuelle du cas d’utilisation « s’inscrire »
Titre S’inscrire
Acteur Utilisateur : conducteur
Pré-condition(s)
— Le conducteur doit accéder à la page d’accueil.
Post-condition(s) L’utilisateur accède à son espace personnel

Scénario Nominal
1. Le conducteur demande la page d’inscription.
2. Le système lui affiche la page demandée.
3. Le conducteur choisit le type de compte qui veut créer.
5. Le conducteur remplit le formulaire d’inscription.
7. Le système ajoute l’utilisateur dans la base de données
et affiche le message suivant : « Vous êtes déjà inscrit.
Merci de votre confiance ».
8. Redirection vers espace privé
Scénario Alternatif
1. Le conducteur quitte la page d’inscription :
2. Les données saisies sont incorrectes ou manquantes :
i. Le système affiche un message d’erreur et signale au
visiteur de recommencer la saisie.
ii. Le cas d’utilisation reprend à l’étape 3 du scénario
nominal.
3. identifiants déjà existant dans la base de données :
33
Table 3.4 – Description textuelle du cas d’utilisation «Bloquer des conducteurs»
Titre Bloquer
Acteur Responsable
Pré-condition(s) Le liste des conducteurs est affichées.
Il y a au moins un conducteur
Post-condition(s) Conducteur est bloqué.
Scénario Nominal
1. Le responsable clique sur le bouton « bloqué ».
2. Le système demande la confirmation de blocage.
3. Le responsable confirme le blocage.
4. Le système envoie la requête de blocage au base de don-
nées.
5. Mise à jour de la base.
6. La bd envoie la réponse de la requête de mise à jour au
système.
7. Le système affiche la liste des conducteurs modifiés.
Scénario Alternatif 3. 1 Le responsable annule le blocage.
34
Table 3.5 – Description textuelle du cas d’utilisation «Débloquer des conducteurs»
Titre Débloquer
Acteur Responsable
Pré-condition(s) - La liste des conducteurs est affichées.
- Il y a au moins un conducteur.
Post-condition(s) Conducteur est débloqué.
Scénario Nominal
1. Le responsable clique sur le bouton « débloquer ».
2. Le système affiche l’interface alerte de confirmation.
3. Le responsable confirme le déblocage.
4. Le système envoie la requête de déblocage au base de
données.
5. Mise à jour de la base.
6. La bd envoie la réponse de la requête de mise à jour au
système.
7. Le système affiche la liste des conducteurs modifiés.
Scénario Alternatif 3. 1 Le responsable annule le déblocage.
35
Table 3.6 – Description textuelle du cas d’utilisation «Ajouter des techniciens»
Titre Ajout
Acteur Responsable
Pré-condition(s) - Le responsable doit être authentifié. - Le responsable doit
accéder à l’interface gérer technicien .
Post-condition(s) Technicien ajouté avec succès
Scénario Nominal
1. Le responsable demande l’interface «Ajouter techni-
cien»
2. Le système affiche l’interface demandée
3. Le responsable remplit le formulaire d’ajout d’un tech-
nicien
4. Le système vérifie les données saisies
5. Le système ajoute le conducteur dans la base de données
et affiche le message suivant : « technicien ajouté avec
succès ».
Scénario Alternatif 3. a. le responsable quitte la page d’ajout d’un technicien :

4. a. Les données saisies sont incorrectes ou manquantes :
1. Le système affiche le message d’erreur et signale au res-
ponsable de corriger les erreurs mentionnées dans le
message.
2. Le cas d’utilisation reprend à l’étape 3 du scénario no-
minal.
36
Table 3.7 – Description textuelle du cas d’utilisation «Modifier des analystes»
Titre Modification
Acteur Responsable
Pré-condition(s) - Le responsable doit être authentifié.
- Le responsable doit accéder à la liste des analystes à partir
du catalogue ou du moteur de recherche interne.
Post-condition(s) Analyste est modifié
Scénario Nominal
1. Le responsable sélectionne un analyste et demande l’in-
terface «Modifier analyste»
2. Le système affiche l’interface demandée avec les infor-
mations d’analyste sélectionné
3. Le responsable saisit les nouvelles données
5. Le système met à jour les informations d’analyste dans
la base de données et affiche le message suivant : « ana-
lyste modifié avec succès ».
Scénario Alternatif 3. a. Le responsable quitte la page de modification d’un ana-

lyste :
1. Le système affiche un message d’erreur et signale au
responsable de corriger les erreurs mentionnées dans le
message.
minal
3.2.4 Conception
Dans cette section, nous présentons les différents diagrammes de séquence dé-
taillés ainsi que le diagramme de classe pour le sprint 1 du release 1.
3.2.4.1 Diagrammes des séquences détaillés

Le diagramme de séquence permet de modéliser les échanges de messages entre
les différents objets dans le contexte d’un scénario précis, il s’utilise essentiellement
pour décrire les scénarios d’un cas d’utilisation (les entités sont les acteurs et le
système) ou décrire des échanges entre objets.
37
Les diagrammes de séquences s’utilisent de deux manières différentes, selon la

phase du cycle de vie et le niveau de détail, la première utilisation correspond à
la documentation des cas d’utilisation et la deuxième correspond à un usage plus
informatique et permet la représentation du flot de contrôle.
Dans cette partie nous ferons appel à un ensemble de diagrammes de séquences
chacun correspondant à une sous fonction du système afin de dégager les différents
types d’objet qui peuvent présenter dans un diagramme de séquence parmi lesquels
on cite :
• « Boundary » : appelé aussi les vues ou encore frontières ce sont des classes qui
servent à modéliser les interactions entre un utilisateur ou un système externe avec
le système modélisé. Ces classes sont souvent identifiées lors de la spécification des
interfaces utilisateurs.
• « Control » : les contrôles se sont des classes utilisées pour représenter la coor-
dination entre les classe boundary et les classe entity, l’enchaînement et le contrôle
d’autres objets.
• « Entity » : ce sont des classes qui servent à modéliser des informations durables
et souvent persistantes ils permettent aussi de représenter les concepts métier ou
classes du domaine.
Diagramme de séquence du cas d’utilisation « s’authentifier »
38
Figure 3.3 – Diagramme de séquence du cas d’utilisation « s’authentifier »
* Diagramme de séquence du cas d’utilisation « S’inscrire »
39
Figure 3.4 – Diagramme de séquence du cas d’utilisation « S’inscrire »
* Diagramme de séquence du cas d’utilisation « Bloquer des conducteurs »
40
Figure 3.5 – Diagramme de séquence du cas d’utilisation « Bloquer des conducteurs

»
* Diagramme de séquence du cas d’utilisation « Débloquer des conducteurs »
41
Figure 3.6 – Diagramme de séquence du cas d’utilisation « Débloquer des conduc-

teurs »
* Diagramme de séquence du cas d’utilisation « Ajouter des techniciens »
42
Figure 3.7 – Diagramme de séquence du cas d’utilisation « Ajouter des techniciens

»
* Diagramme de séquence du cas d’utilisation « Modifier des analystes »
43
Figure 3.8 – Diagramme de séquence du cas d’utilisation « Modifier des analystes

»
3.2.4.2 Diagramme de Classes

Le diagramme de classe est une représentation statique des éléments qui com-
posent un système et de leurs relations. C’est le seul diagramme obligatoire lors de
la modélisation orientée objet. Le diagramme de classe est une description de la base
des données.
Ce diagramme est caractérisé par :
• Une Classe : Elle est représentée par un rectangle séparé en trois parties :
La première partie contient le nom de la classe.
La seconde contient les attributs de la classe.
La dernière contient les méthodes de la classe.
• Une Association : C’est une relation entre deux classes, qui décrit un ensemble de
liens entre instances. Une association est bidirectionnelle
• Multiplicité : le nombre d’objets (min. Max) qui peuvent participer à une relation
avec un autre objet dans le cadre d’une association. Multiplicités fréquentes :
0..1 = optionnel (mais pas multiple)
44
= exactement 1
0.. * = * = quelconque
1.. * = au moins 1
Figure 3.9 – diagramme de classe détaillé du sprint 1
3.2.4.3 Dictionnaire de données

Tableau 1 présente le dictionnaire des données de la table « utilisateur », «
conducteur », « technicien », « analyste ». Ce tableau décrit la description des
classes participantes dans le premier sprint du premier sprint.
45
Table 3.8 – la description des classes participantes dans le premier sprint du premier
sprint
Attributs Signification Type

Utilisateur
id L’identifiant unique de l’utilisateur INT
nom Nom de l’utilisateur TEXT
prenom Prénom de l’utilisateur TEXT
tel téléphone de l’utilisateur INT
email email de l’utilisateur TEXT
pseudo Pseudo de l’utilisateur VARCHAR(32)
password Password de l’utilisateur TEXT
profil Profil de l’utilisateur INT
avatar Avatar de l’utilisateur TEXT
date_ins Date d’insertion de l’utilisateur TEXT
etat Etat de l’utilisateur INT
Conducteur
cin Carte d’identité national du conducteur INT
date_ins Date d’insertion du conducteur TEXT
Analyste
cin Carte d’identité national d’analyste INT
email email d’analyste TEXT
date_ins Date d’insertion d’analyste TEXT
Technicien
poste Poste du technicien TEXT
email email du technicien TEXT
date_ins Date d’insertion du technicien TEXT
3.2.4.4 Modèle relationnel

La base de données relationnelle est une base de donnés comprenant des relations
dynamiques entre les différents objets contenus dans les tables :
Utilisateur(id,nom,prenom,tel,email,adresse,code_postal,pseudo
,password,profil,avatar,date_ins,etat) ;
Conducteur(id,nom,prenom,tel,email,pseudo,password,profil,avatar, cin, date_ins) ;
Analyste(id,nom,prenom,tel,email,pseudo,password,profil,avatar,cin, date_ins) ;
Technicien(id,nom,prenom,tel,email,pseudo,password,profil,avatar,poste,date_ins,
#id_tb_responsable) ;
46
3.2.4.5 Diagrammes d’activité

Le diagramme d’état est un diagramme UML qui appartient aux diagrammes de
la conception dynamique. Il présente les différents états possibles de la table et on
présente dans les diagrammes suivants les différents états de chaque table.
Figure 3.10 – diagramme d’activité du cas d’utilisation s’authentifier
3.2.5 Réalisation et tests

Cette partie est consacrée à l’exposition du travail achevé à travers des captures
d’écrans de différentes interfaces développées pendant ce premier sprint.
47
3.2.5.1 Interface d’authentification
Figure 3.11 – Interface d’authentification : partie web
3.2.5.2 Tests et validation

Le test d’un produit logiciel est un processus consistant qui vise à garantir le bon
fonctionnement du système à travers une comparaison des comportements attendu
et des résultats obtenus. Avant la fin de chaque Sprint nous, avons testé les fonc-
tionnalités du module. Ensuite, nous avons validé toutes les fonctionnalités avec le
Product Owner.
— Tests d’acceptation
Ce genre de test nous permet de mieux détecter les erreurs ainsi que les exceptions
que le développeur ne les prévoit pas. Ces tests se font en présence de l’utilisateur
final. Par exemple lors de la conception de la première interface d’authentification,
nous avons modifié la mise en forme de l’interface.
— Tests fonctionnels
Ces tests visent à couvrir les différentes fonctionnalités du système. Ils ont été validés
par l’encadreur de la société au fur et à mesure du développement. Nous avons
préparé un manuel des tests contenant un certain nombre de fiches.
Les tableaux suivants illustrent deux exemples de ces fiches de test.
Le tableau suivant montre quelques tests fonctionnels de sprint 1
48
Table 3.9 – Fiche de test de l’interface du connexion
Projet : Smart parking Crée-le : 26/05/2021

Description : cette fiche décrit les étapes pour Testeur :Feten Abidi
demande de connexion au système. Fiche de test : test1
Module testé : demande la connexion
Etapes Actions Résultats attendus
1 Sélectionner dans le bouton Lancement du « formulaire
connexion. « connexion »
2 Saisir pseudo Pseudo validé.
3 Saisir mot de passe Mot de passe validé
4 Lancer la connexion de parent Afficher la page d’accueil
Résultat du test : la demande de connexion est sera avec sucées.
Action à prendre : Aucune.
Table 3.10 – test fonctionnel du sprint 1
Cas de test Démarche de test Comportement attendu Résultat

Se connecter L’utilisateur doit entrer un Affichage de message d’erreur Conforme
pseudo et mot de passe pour en cas de fausses informa-
accéder à son espace tions sinon affichage de l’es-
pace privé
Ajouter Le responsable doit choisir Afficher message d’erreur en Conforme
un formulaire pour ajouter cas de faux remplis
un utilisateur
Modifier Le responsable doit modifier Affichage de message d’erreur Conforme
les formulaires en cas de fausses remplies
Supprimer Le responsable doit suppri- La suppression annulée quand Conforme
mer un utilisateur le responsable annule la de-
mande
3.3 Etude de sprint 2 : Gestion des parcs

3.3.1 Backlog du sprint
Table 3.11 – Backlog du sprint 2 : Gestion des parcs
49

parcs des parcs
2 Gestion En tant que responsable je veux gérer 3 jrs

d’emplacements des emplacements
3 Gestion de types En tant que responsable je veux gérer 3 jrs

d’ abonnements des abonnements

services des services supplémentaires
supplémentaires
Figure 3.12 – tache du sprint 2
50

3.3.3.1 Diagramme de cas d’utilisation détaillée du release 1 du sprint
2
Figure 3.13 – Diagramme de cas d’utilisation détaillée du release 1 du sprint 2
51
3.3.3.2 Description textuelle des cas d’utilisations
Table 3.12 – Description textuelle du cas d’utilisation « Supprimer des parcs »
Titre Suppression
Acteur Responsable
Pré-condition(s) -Le responsable doit être authentifié. -Le responsable doit ac-
céder à l’interface gérer parcs .
Post-condition(s) Parc supprimé avec sucées
Scénario Nominal
1. Le responsable sélectionne un parc
2. Le responsable demande de supprimer le parc sélec-
tionné
3. Le système demande une confirmation de suppression
4. Le responsable confirme la suppression du parc
5. Le système supprime le parc de la base de données et
affiche le message suivant : « parc supprimé avec succès
».
Scénario Alternatif 1. Le responsable annule la mise à jour d’espace parc :

i. Le cas d’utilisation se termine avec échec.
2. Les données saisies sont incorrecte :
i. Le système affiche un message d’erreur « vérifier vos don-
nées.
ii. Le cas d’utilisation se termine avec échec.
52
Table 3.13 – Description textuelle du cas d’utilisation « Ajouter emplacement»
Titre Ajout
Acteur Responsable
Pré-condition(s) Le responsable doit être authentifié. Le responsable doit ac-
céder à l’interface gérer emplacement .
Post-condition(s) Emplacement ajouté avec succès
Scénario Nominal
1. Le responsable demande l’interface « Ajouter emplace-
ment »
3. Le responsable remplit le formulaire d’ajout d’un em-
placement
5. Le système ajoute l’emplacement dans la base de don-
nées et affiche le message suivant : « emplacement ajouté
avec succès ».
Scénario Alternatif 3. a. Le responsable quitte la page d’ajout emplacement

message.
minal
53
Table 3.14 – Description textuelle du cas d’utilisation « Supprimer emplacement»
Titre Suppression
Acteur Responsable
céder à l’interface gérer emplacement.
Post-condition(s) Emplacement supprimé avec sucées

Scénario Nominal
1. Le responsable sélectionne un emplacement
2. Le responsable demande de supprimer l’emplacement
sélectionné
4. Le responsable confirme la suppression d’emplacement
5. Le système supprime l’emplacement de la base de don-
nées et affiche le message suivant : « emplacement sup-
primé avec succès ».
Scénario Alternatif 1. Le responsable annule la mise à jour d’espace emplacement :

nées.
54
Table 3.15 – Description textuelle du cas d’utilisation « Ajouter service supplé-

mentaire»
Titre Ajout
Acteur Responsable
céder à l’interface gérer service .
Post-condition(s) Service ajouté avec succès
Scénario Nominal
1. Le responsable demande l’interface « Ajouter Service »
3. Le responsable remplit le formulaire d’ajout un Service
5. Le système ajoute l’emplacement dans la base de don-
nées et affiche le message suivant : « Service ajouté avec
succès ».
Scénario Alternatif 3. a. Le responsable quitte la page d’ajout service

message.
minal
55
Table 3.16 – Description textuelle du cas d’utilisation « Supprimer service supplé-

mentaire»
Titre Suppression
Acteur Responsable
céder à l’interface gérer service .
Post-condition(s) service supprimé avec sucées

Scénario Nominal
1. Le responsable sélectionne un service
2. Le responsable demande de supprimer le service sélec-
tionné
4. Le responsable confirme la suppression du service
5. Le système supprime le service de la base de données
et affiche le message suivant : « service supprimé avec
succès ».
Scénario Alternatif 1. Le responsable annule la mise à jour d’espace service :

nées.
56
Table 3.17 – Description textuelle du cas d’utilisation « Ajouter abonnement »
Titre Ajout
Acteur Responsable
céder à l’interface gérer abonnement .
Post-condition(s) Abonnement ajouté avec succès
Scénario Nominal
1. Le responsable demande l’interface « Ajouter abonne-
ment »
3. Le responsable remplit le formulaire d’ajout un abonne-
ment
5. Le système ajoute l’abonnement dans la base de données
et affiche le message suivant : « abonnement ajouté avec
succès ».
Scénario Alternatif 3. a. Le responsable quitte la page d’ajout abonnement

message.
minal
57
Table 3.18 – Description textuelle du cas d’utilisation « Supprimer abonnement »
Titre Suppression
Acteur Responsable
céder à l’interface gérer abonnement .
Post-condition(s) abonnement supprimé avec sucées

Scénario Nominal
1. Le responsable sélectionne un abonnement
2. Le responsable demande de supprimer l’abonnement sé-
lectionné
4. Le responsable confirme la suppression d’abonnement
5. Le système supprime l’abonnement de la base de don-
nées et affiche le message suivant : « abonnement sup-
primé avec succès ».
Scénario Alternatif 1. Le responsable annule la mise à jour d’espace abonnement :

nées.
3.3.4 Conception
taillés ainsi que le diagramme de classe pour ce sprint.

* Diagramme de séquence du cas d’utilisation « Supprimer parc »
58
Figure 3.14 – Diagramme de séquence du cas d’utilisation « Supprimer parc »
* Diagramme de séquence du cas d’utilisation « Ajouter emplacement »
59
Figure 3.15 – Diagramme de séquence du cas d’utilisation « Ajouter emplacement

»
* Diagramme de séquence du cas d’utilisation « Supprimer emplacement »
60
Figure 3.16 – Diagramme de séquence du cas d’utilisation « Supprimer emplace-

ment »
* Diagramme de séquence du cas d’utilisation « Ajouter service supplémentaire»
61
Figure 3.17 – Diagramme de séquence du cas d’utilisation « Ajouter service sup-

plémentaire»
* Diagramme de séquence du cas d’utilisation « Supprimer service supplémentaire

»
62
Figure 3.18 – Diagramme de séquence du cas d’utilisation « Supprimer service

supplémentaire »
* Diagramme de séquence du cas d’utilisation « Ajouter abonnement »
63
Figure 3.19 – Diagramme de séquence du cas d’utilisation « Ajouter abonnement

»
* Diagramme de séquence du cas d’utilisation « Supprimer abonnement »
64
Figure 3.20 – Diagramme de séquence du cas d’utilisation « Supprimer abonnement

»
65
Figure 3.21 – Diagramme de classe détaillée du sprint 2

Tableau 1 présente le dictionnaire des données des tables « Parc », « Service »,
« Emplacement ». Ce tableau décrit la description des classes participantes dans le
deuxième sprint du premier release.
66
Table 3.19 – la description des classes participantes dans le deuxième sprint du

premier release

Parc
id L’identifiant unique du parc INT
nom Nom du parking TEXT
type Type du parking TEXT
longitude Longitude du parking TEXT
latitude Latitude du parking TEXT
capacite Capacité du parking TEXT
image Image du parking TEXT
date_ins Date d’insertion du parking TEXT
Service
id L’identifiant unique du service INT
nom Nom du service TEXT
date_ins Date d’insertion du service TEXT
Emplacement
id L’identifiant unique d’emplacement INT
num Numéro d’emplacement INT
bloc Bloc d’emplacement TEXT
porte_entree Porte d’entrée d’emplacement TEXT
porte_sortie Porte de sortie d’emplacement TEXT
image_entree Image d’entree d’emplacement TEXT
image_sortie image de sortie d’emplacement TEXT
date_ins Date d’insertion d’emplacement TEXT
Abonnement
id L’identifiant unique d’abonnement INT
type Type d’abonnement INT
prix Prix d’abonnement TEXT
delai Delai d’abonnement TEXT
date_ins Date d’insertion d’abonnement TEXT

Utilisateur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins) ;
Parc (id,nom,type,localisation,longitude,latitude,capacite,image,date_ins,
67
#id_tb_responsable) ;
Service(id,cin, date_ins,#id_tb_responsable) ;
Emplacement(id,num,bloc,porte_entree,porte_sortie,image_entree,image_sortie
,date_ins,#id_tb_parcs) ;
Abonnement(id,type,prix,delai,date_ins,#id_tb_parcs) ;

Dans cette section, on va présenter les diagrammes d’activités du Sprint 2.
Figure 3.22 – diagramme d’activité du cas d’utilisation ajouter parc
68
3.3.5 Réalisation
3.3.5.1 Interface : Ajouter parking
Figure 3.23 – Interface : Ajouter parking
3.3.5.2 Test et validation

— Test fonctionnel

Ajouter Le responsable doit choisir Afficher message d’erreur en Conforme
un formulaire pour ajouter cas de faux remplis
un parc
Modifier Le responsable doit modifier Affichage de message d’erreur Conforme
les formulaires en cas de fausses remplies
Supprimer Le responsable doit suppri- La suppression annulée quand Conforme
mer un parc le responsable annule la de-
mande
— Test unitaire
Pour montrer que chaque module effectue toute la fonction prévue, nous avons
testé les différents composants des différents modules à part. Ce type de test consiste
à des tests de logique (recherche d’erreurs, vérification de l’enchaînement).
Nous avons testé chaque interface séparément.
69
3.4 Conclusion
Dans ce chapitre, on a fait la présentation du premier release du projet. Il est
composé de deux sprints. L’étude de chaque sprint couvre l’analyse, la conception, la
réalisation et les différents tests. Dans le chapitre suivant, on va faire une présentation
de release 2.
70
Chapitre 4
4.1 Introduction
deux sprints :
Sprint 1 « Localiser emplacement et Localiser parking »
Sprint 2 « Réservation de places, Gestion d’abonnements, Commander des services
supplémentaires, Gestion des commandes et Gestion de paiement »
4.2 Etude de sprint 1 : Recherche parking

Table 4.1 – Backlog du sprint 1 : Recherche parking
1 Localiser En tant que conducteur je veux 5 jrs

emplacement localiser des emplacements
2 Localiser En tant que conducteur je veux 5 jrs

parking localiser des parkings
71

4.2.3.1 Diagramme de cas d’utilisation détaillée du sprint 1 du release
2
Figure 4.2 – Diagramme de cas d’utilisation détaillée du sprint 1 du release 2
72
Table 4.2 – Description textuelle du cas d’utilisation «Localiser parking
Titre Localiser
Acteur Conducteur
Pré-condition(s) - Le conducteur doit être authentifié.
- Le conducteur doit accéder à l’interface gérer parking.
Post-condition(s) Parking est localisé avec succès
Scénario Nominal Se cas d’utilisation commence lorsque le conducteur demande
au système de localiser un parking :
1. Le conducteur consulte ses listes de parking.
2. Le système affiche les parkings publiés.
Scénario Alternatif 1. Le conducteur annule la publication de parking :

2. Les données saisies sont incorrectes :
i. Le système affiche un message d’erreur « vérifier vos données
»
Table 4.3 – Description textuelle du cas d’utilisation «Localiser emplacement»
Titre Localiser
Acteur Conducteur
Pré-condition(s) - Le conducteur doit être authentifié.
- Le conducteur doit accéder à l’interface gérer emplacement.
Post-condition(s) Emplacement est localisé avec succès
Scénario Nominal Se cas d’utilisation commence lorsque le conducteur demande
au système de localiser un emplacement :
1. Le conducteur consulte ses listes de emplacements.
2. Le système affiche les emplacements publiés.
Scénario Alternatif 1. Le conducteur annule la publication d’emplacement :

2. Les données saisies sont incorrectes :
»
73
4.2.4 Conception
taillés ainsi que le diagramme de classe pour le premier sprint du deuxième release.

* Diagramme de séquence du cas d’utilisation « Localiser emplacement »
Figure 4.3 – Diagramme de séquence du cas d’utilisation « Localiser emplacement

»
* Diagramme de séquence du cas d’utilisation « Localiser parking »
74
Figure 4.4 – Diagramme de séquence du cas d’utilisation « Localiser parking »
Figure 4.5 – Diagramme de classe détaillée du sprint 1

Tableau 1 présente le dictionnaire des données de la table « conducteur ». Ce
tableau décrit la description des classes participantes dans le premier sprint du
deuxième release.
75
Table 4.4 – la description des classes participantes dans le premier sprint du

deuxième release

Utilisateur
nom Nom de l’utilisateur TEXT
prenom Prénom de l’utilisateur TEXT
tel téléphone de l’utilisateur INT
email email de l’utilisateur TEXT
pseudo Pseudo de l’utilisateur VARCHAR(32)
password Password de l’utilisateur TEXT
profil Profil de l’utilisateur INT
avatar Avatar de l’utilisateur TEXT
date_ins Date d’insertion de l’utilisateur TEXT
etat Etat de l’utilisateur INT
Conducteur
id L’identifiant unique de conducteur INT
cin Carte d’identité national du conducteur INT
date_ins Date d’insertion du conducteur TEXT

Utilisateur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins,etat) ;
Conducteur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins) ;
Parc (id,nom,type,localisation,longitude,latitude,capacite,image,date_ins
,#id_tb_responsable) ;
Emplacement(id,num,bloc,porte_entree,porte_sortie,image_entree,image_sortie,
date_ins,#id_tb_parcs)

Dans cette section, on va présenter les diagrammes d’activités du Sprint 1 du
deuxième release.
76
Figure 4.6 – Diagramme d’avtivité du sprint 1 du cas localiser parking
4.2.5 Réalisation
4.2.5.1 Interface : Consulter parking
Figure 4.7 – Interface : Consulter parking

77
Table 4.5 – Fiche de test de l’interface localiser parking
Projet : Smart parking Crée-le : 01/06/2021

Description : cette fiche décrit les étapes Testeur :Feten Abidi
pour localiser un parking dans notre système Fiche de test : test2
Module testé : localiser un parking
Etapes Actions Résultats attendus
1 Sélectionner l’interface « parking » Rechercher un parking
2 Lancer la recherche du parking La recherche est faite.
Résultat du test : la recherche du parking est sera avec sucées.
Action à prendre : Aucune.
4.3 Etude de sprint 2 : Gestion des abonnements

Table 4.6 – Backlog du sprint 2 : Gestion des abonnements
1 Réservation de En tant que conducteur je veux 5 jrs

places réserver une place
2 Gestion de types En tant que conducteur je veux gérer 3 jrs

d’abonnements des abonnements
3 commander des En tant que conducteur je veux 4 jrs

services commander des services
supplémentaires supplémentaires
4 Gestion des En tant que technicien je veux gérer 4 jrs

commandes des commandes
78
5 Gestion de En tant que conducteur je veux payer 4 jrs

paiements

4.3.3.1 Diagramme de cas d’utilisation détaillé sprint 2 du release 2 :
Figure 4.9 – Diagramme de cas d’utilisation détaillé sprint 2 du release 2
79
4.3.3.2 Description textuelle des cas d’utilisations :
Table 4.7 – Description textuelle du cas d’utilisation « Réserver des places »
Titre Réserver
Acteur Conducteur
Pré-condition(s) Le conducteur doit être authentifié.
Le conducteur doit accéder à l’interface gérer place .
Post-condition(s) Place ajouté avec succès
Scénario Nominal Ce cas d’utilisation commence lorsque le conducteur accéder
l’interface réservation.
1. Le conducteur accède page de réservation.
2. Remplir le formulaire de réservation.
3. Le conducteur clique sur le bouton réserver
5. Le système ajoute les réservations dans la base de don-
nées et affiche le message suivant : « réservation ajouté
avec succès ».
Scénario Alternatif 3. le conducteur quitte la page de réservation :

4. le conducteur annule la réservation.
80
Table 4.8 – Description textuelle du cas d’utilisation « Abonner »
Titre Abonner
Acteur Conducteur
Le conducteur doit accéder à l’interface gérer abonnement .
Post-condition(s) Abonnement ajouté avec succès
l’interface d’abonnement.
1. Le conducteur accède page d’abonnement.
2. Choisir le type d’abonnement.
3. Le conducteur clique sur le bouton abonner
5. Le système ajoute l’abonnement dans la base de données
et affiche le message suivant : « vous êtes abonné avec
succès ».
Scénario Alternatif 3. le conducteur quitte la page d’abonnements :

4. le conducteur annule l’abonnement.
81
Table 4.9 – Description textuelle du cas d’utilisation « Commander »
Titre Commander
Acteur Conducteur
Le conducteur doit accéder à l’interface gérer commande.
Post-condition(s) Commande ajouté avec succès
l’interface de réservation de commandes.
1. Le conducteur accède page de réservation de com-
mandes.
2. Choisir le service à commander.
3. Le conducteur clique sur le bouton réserver
5. Le système ajoute les commandes dans la base de don-
nées et affiche le message suivant : « commande ajouté
avec succès ».
Scénario Alternatif 3. le conducteur quitte la page de réservation de commandes :

4. le conducteur annule la réservation.
82
Table 4.10 – Description textuelle du cas d’utilisation « Payer »
Titre Payer
Acteur Conducteur
Post-condition(s) Payement fait avec succès
Scénario Nominal Se cas d’utilisation commence lorsque le conducteur accéder
l’interface de paiement
1. Le conducteur accède page de paiement
2. Choisir type de payement
3. Si en ligne : un formulaire de saisir leur carte bancaire
4. Si préliminaire : un message affiche pour informe que on
a un nombre d’heures limites pour rembourser sinon la
réservation sera annulée
5. Le conducteur clique sur le bouton payer
7. Le système ajoute le paiement dans la base de données
et affiche le message suivant : « vous êtes payer avec
succès ».
Scénario Alternatif 1. Le conducteur ne choisit pas type de paiement :

2. Le code de carte bancaire saisie est incorrect :
»
83
Table 4.11 – Description textuelle du cas d’utilisation « Consulter des commandes

»
Titre Consulter
Acteur Technicien
Pré-condition(s) Le technicien doit être authentifier.
Le technicien doit accéder à l’interface gérer commande
Post-condition(s) Liste des commande affichées.

Scénario Nominal
1. Le technicien demande liste des commandes.
2. Le système affiche la liste des commandes.
3. La base de donnée collecte les informations.
4. La base de donnée renvoi le résultat.
5. Le système affiche la liste des commandes
Scénario Alternatif 4)a)- Le système renvoi table vide
4.3.4 Conception
taillés ainsi que le diagramme de classe pour le deuxième sprint du deuxième release.

* Diagramme de séquence du cas d’utilisation « Réserver des places »
84
Figure 4.10 – Diagramme de séquence du cas d’utilisation « Réserver des places »
* Diagramme de séquence du cas d’utilisation « Abonner »
85
Figure 4.11 – Diagramme de séquence du cas d’utilisation « Abonner »
* Diagramme de séquence du cas d’utilisation « Commander »
Figure 4.12 – Diagramme de séquence du cas d’utilisation « Commander »
86
* Diagramme de séquence du cas d’utilisation « Consulter commande »
Figure 4.13 – Diagramme de séquence du cas d’utilisation « Consulter commande

»
87
Figure 4.14 – Diagramme de classe détailée du sprint 2 du release 2

Tableau 1 présente le dictionnaire des données de la table « Commande », «
Réservation ». Ce tableau décrit la description des classes participantes dans le
deuxième sprint du deuxième release.
88

deuxième release

Commande
id L’identifiant unique du commande INT
nom Nom du commande TEXT
date_ins Date d’insertion du commande de l’utilisa- TEXT
teur
Réservation
id L’identifiant unique de réservation INT
date date de réservation INT
heure heure de réservation INT
date_ins Date d’insertion de réservation TEXT
Paiement
id L’identifiant unique de paiement INT
num_carte Numéro de carte du paiement TEXT
date_exp Date d’expiration du paiement TEXT

Utilisateur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins,etat) ;
Conducteur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins) ;
Technicien(id,nom,prenom,tel,email,pseudo,password,profil,avatar,poste,
date_ins,#id_tb_responsable) ;
Commande (id, nom, date_ins, #id_tb_services,#id_tb_conducteurs,
#id_tb_techniciens) ;
Reservation(id,date,heure,date_ins,#id_tb_emplacements) ;
Abonnement(id,type,prix,delai,date_ins,#id_tb_parcs) ;
Paiement (id,num_carte,date_exp) ;

Dans cette section, on va présenter les diagrammes d’activités du Sprint 2 du
deuxième release.
89
Figure 4.15 – diagramme d’activité du cas d’utilisation modifier service
4.3.5 Réalisation
4.3.5.1 Interface Réservation d’une place
Figure 4.16 – Interface : Réservation d’une place
90


Réserver Le conducteur doit remplir Afficher message d’erreur en Conforme
un formulaire pour réserver cas de faux remplis
une place
Commander Le conducteur doit remplir Affichage de message d’er- Conforme
un formulaire pour com- reur en cas de fausses rem-
mander des services plies
4.3.6 Conclusion
Dans ce chapitre, on a fait la présentation du deuxième release du projet. Il est
composé de deux sprints. L’étude de chaque sprint couvre l’analyse, la conception, la
réalisation et les différents tests. Dans le chapitre suivant, on va faire une présentation
de release 3.
91
Chapitre 5
5.1 Introduction
deux sprints :
Sprint 1 « Configuration de paramètres de parking, Vérification d’entrée /sortie »
Sprint 2 « Prévisualisation des statistiques, Gestion des recommandations »
5.2 Étude de sprint 1 du release 3 : Configuration

des parcs
Table 5.1 – Backlog du sprint 1 : Configuration des parcs
1 Configuration En tant que responsable je veux 5 jrs

de paramètres Configurer les paramètres de parking
de parking
2 Vérification En tant que responsable je veux 10 jrs

d’entrée /sortie vérifier d’entrée /sortie
92
3 Noter parking En tant que conducteur je veux noter 5 jrs

parking

5.2.3.1 Diagramme de cas d’utilisation détaillée du sprint 1 du release
3
93
Table 5.2 – Description textuelle du cas d’utilisation « Configuration »
Titre Configuration
Acteur Responsable
Pré-condition(s) Le responsable doit accéder à la page d’e configuration.
Post-condition(s) Le responsable accède à son espace personnel.
Scénario Nominal
1. Le responsable demande la page de configuration.
3. Le responsable remplir le formulaire qui va le configurer.
5. Le système ajoute les informations dans la base de don-
nées et affiche le message suivant : « La configuration
fait avec succès ».
Scénario Alternatif 1. Le responsable quitte la page de configuration :

i. Le système affiche un message d’erreur et signale au respon-
sable de recommencer la saisie.
94
Table 5.3 – Description textuelle du cas d’utilisation « Noter parking »
Titre Noter
Acteur Conducteur
Pré-condition(s) Le conducteur doit accéder à l’interface noter parking.
Post-condition(s) Le conducteur accède à son espace personnel.
Scénario Nominal
1. Le conducteur demande l’interface noter parking.
2. Le système lui affiche l’interface demandée.
3. Le conducteur remplir le formulaire qui va le noter.
5. Le système ajoute les informations dans la base de don-
nées
Scénario Alternatif 1. Le conducteur quitte l’interface noter parking :

i. Le système affiche un message d’erreur et signale au conduc-
teur de recommencer la saisie.
5.2.4 Conception
* Diagramme de séquence du cas d’utilisation « Configuration »
95
Figure 5.3 – Diagramme de séquence du cas d’utilisation « Configuration »
* Diagramme de séquence du cas d’utilisation « Noter »
Figure 5.4 – Diagramme de séquence du cas d’utilisation « Noter »
96
Figure 5.5 – Diagramme de classe détaillée du sprint 1 du release 3

Tableau 1 présente le dictionnaire des données des tables « Parc ». Ce tableau
décrit la description des classes participantes dans le deuxième sprint du premier
release.
Table 5.4 – la description des classes participantes dans le premier sprint du troi-
sième release

Note
id L’identifiant unique du note INT
email Email du note INT
description Description du note TEXT
objet Objet du note TEXT
date_ins Date d’insertion du note TEXT
97

Utilisateur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins) ;
Responsable(id,nom,prenom,tel,email,pseudo,password,profil,avatar code, date_ins) ;
Parc (id, nom,type,localisation,longitude,latitude,capacite,image,date_ins,
# id_tb_responsable) ;
Note(id,email,description,objet,date_ins)
Figure 5.6 – Diagramme d’activité du sprint 1 cas configuration les paramètres de

parking
98
5.2.5 Réalisation
5.2.5.1 Interface de Vérification E/s
Figure 5.7 – Interface Vérification E/S

Table 5.5 – test fonctionnel du sprint 1 du release 3

configurer Le responsable doit choisir Afficher message d’erreur en Conforme
un formulaire pour confi- cas de fausses remplis
gure un parc
Modifier Le responsable doit modifier Affichage de message d’er- Conforme
les formulaires reur en cas de fausses rem-
plies
Supprimer Le responsable doit suppri- La suppression annulée Conforme
mer un formulaire quand le responsable
annule la demande
— Test unitaire
99
Pour montrer que chaque module effectue toute la fonction prévue, nous avons
testé les différents composants des différents modules à part. Ce type de test consiste
à des tests de logique (recherche d’erreurs, vérification de l’enchaînement).
5.3 Etude de sprint 1 : Gestion des statistiques

Table 5.6 – Backlog du sprint 2 : Gestion des statistiques
1 Prévisualisation En tant que analyste je veux pré 5 jrs

des statistiques visualiser des statistiques
2 Gestion des re- En tant que analyste je veux faire des 5 jrs
commandations recommandations
100

5.3.3.1 Diagramme de cas d’utilisation
Table 5.7 – Description textuelle du cas d’utilisation « Pré visualiser des statistiques
Titre Pré visualiser

Acteur Analyste
Pré-condition(s) L’analyste doit être authentifier.
L’analyste doit accéder à l’interface gérer statistique
Post-condition(s) Liste des statistiques affichées.
Scénario Nominal
1. L’analyste demande la liste des statistiques.
2. Le système afficher la liste des statistiques.
3. La base de donnée collecte les informations nécessaires.
4. La base de donnée renvoi le résultat.
5. Le système affiche la liste des statistiques
Scénario Alternatif 4.a)- Le système renvoi table vide
101
Table 5.8 – Description textuelle du cas d’utilisation « Supprimer des recomman-

dations »
Titre Suppression
Acteur Analyste
Pré-condition(s) L’analyste doit être authentifier.
- L’analyste doit accéder à l’interface gérer recommandation.
Post-condition(s) Recommandation supprimé avec sucées
Scénario Nominal
1. Le responsable sélectionne une recommandation
2. Le responsable demande de supprimer la recommanda-
tion sélectionnée
4. Le responsable confirme la suppression de la recomman-
dation
5. Le système supprime la recommandation de la base de
données et affiche le message suivant : « recommanda-
tion supprimé avec succès ».
Scénario Alternatif 1 L’analyste annule la mise à jour d’espace recommandation :

nées.
ii. Le cas d’utilisation se termine avec échec
102
5.3.4 Conception
Figure 5.10 – Diagramme de séquence du cas d’utilisation « Supprimer des recom-

mandations »
103
Figure 5.11 – Diagramme de classe détaillée du sprint 2 du release 3
104
5.3.4.3 Diagramme de classes global
Figure 5.12 – Diagramme de classes global

Tableau 1 présente le dictionnaire des données des tables « Recommandation ».
Ce tableau décrit la description des classes participantes dans le deuxième sprint du
premier release.
105
Table 5.9 – la description des classes participantes dans le premier sprint du premier
sprint

Recommandation
id L’identifiant unique de recommandation INT
titre Titre de recommandation TEXT
description Description de recommandation TEXT
domaine Domaine de recommandation TEXT
specification Spécification de recommandation TEXT
retenu Retenu de recommandation TEXT
date_ins Date d’insertion de recommandation TEXT

Utlisateur(id,nom,prenom,tel,email,pseudo,password,profil,avatar,date_ins,etat) ;
Analyste(id,nom,prenom,tel,email,pseudo,password, ,profil,avatar,cin ,date_ins) ;
Recommandation (id,titre, desc,domaine,spec,retenu,date_ins) ;
Figure 5.13 – Diagramme d’avtivité du cas supprimer recommandation
106
5.3.5 Réalisation
5.3.5.1 Interface de statistique
Figure 5.14 – Interface statistique
Figure 5.15 – Interface ajouter recommandation


troisième sprint

Ajouter L’analyste doit choisir un Afficher message d’erreur en Conforme
formulaire pour ajouter une cas de fausses remplis
recommandation
Modifier L’analyste doit modifier les Affichage de message d’er- Conforme
formulaires reur en cas de fausses rem-
plies
Supprimer L’analyste doit supprimer La suppression annulée Conforme
une recommandation quand le responsable
annule la demande
107
— Test d’intégration
Ces tests correspondent à la phase d’intégration progressive des différents com-
posants élémentaires qui ont déjà passés avec succès l’épreuve des tests unitaires.
L’objectif est de mettre en évidence les dysfonctionnements engendrés par leur as-
semblage.
5.4 Conclusion
Au cours de ce chapitre, on a fait la présentation du troisième release du projet. Il
est composé de deux sprints. L’étude de chaque sprint couvre l’analyse, la conception,
la réalisation et les différents tests.
108
Conclusion Générale
Au cours de ce travail on a cherché à apprendre la majorité des attentes profes-

sionnelles pour les type d’applications informatiques est récemment posé aux éta-
blissements publics et entreprises avec l’évolution de leurs systèmes d’informations.
À la fin de ce projet, nous tenons à préciser que l’application Mobile que nous
avons réalisée sous le titre "Smart parking » ,l’idée est motivante sert à résolue un
besoin commercial pour résoudre les problèmes d’encombrement, ceci en automa-
tisant certaines tâches à travers l’implémentation d’une base de données adéquate
comportant des interfaces conviviales et facile à manipuler.
Pour mieux réaliser notre application, nous avons choisi la méthodologie " Scrum
" en suivant ces différentes phases (analyse,conception,réalisation et test).
Nous proposons de développer seulement afin d’aboutir à une vision plus avan-
cée pour laquelle on prend en plus des considérations stratégiques pour lesquelles
l’environnement interne et externe des clients est le plus intéressent.
Nous souhaitons que cette application soit d’une certaine utilité, elle peut être
améliorée par la possibilité d’ajouter d’autres fonctionnalités et on peut déployer des
capteurs et des caméras de surveillance.
109
Bibliographie
[1] M. Fowler.UML 2.0, édition CampusPress, 2005.

[2] P. Roques, UML 2. Modéliser une application web, édition Eyrolles,
[3] P. Roques, UML 2.0 par la pratique, édition Eyrolles, 2006.
[4] https://www.futura-sciences.com/tech/definitions/
internet-mysql-4640/
[5] http://blog.evolya.fr/index.php?post/04/12/2011/
JavaScript-Geolocation-API-HTML-5
[6] https://www.onepark.fr
[7] https://zenpark.com
[8] https://www.opngo.com/fr/
[9] https://www.beagile.tn/blog-post/lapproche-agile-entre-scrum-et-kanban/
[10] https://themeforest.net/category/site-templates/admin-templates
[11] https://www.flaticon.com
[12] https://stackoverflow.com/questions/6205827/
how-to-open-standard-google-map-application-from-my-application
[13] https://www.w3schools.com/tags/att_input_pattern.asp
[14] https://www.apachefriends.org/fr/download.html
[15] https://www.apachefriends.org/fr/download.html
[16] https://www.canva.com/fr_fr/
[17] https://adventy.org/fr/mvc?fbclid=IwAR1Xi4ne08WW89mXa3sxN7JEOUVGH98AL_
z2FZ9aHsx1dK831qbJm-pyiDw
[18] https://www.scriptcase.net/?gclid=CjwKCAjw2ZaGBhBoEiwA8pfP_
r1GzsRfdeyRHXhvYvlPAjIdK51pmByluHb6mxMqMYFEkb-Fm6oYTBoC8_UQAvD_
BwE
[19] https://staruml.io/download
[20] https://trello.com/fr
110
BIBLIOGRAPHIE
[21] https://www.vagrantup.com
[22] https://developer.android.com/
[23] https://fr.overleaf.com/project/60b634759d9751e612d86b8d
[24] https://developer.mozilla.org/fr/docs/Web/JavaScript
[25] https://www.01net.com/telecharger/windows/Internet/editeur_de_
site/fiches/29119.html
[26] https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/
1203257-html5-hypertext-markup-langage5-definition-traduction/
[27] https://developer.mozilla.org/fr/docs/Web/CSS
[28] https://www.commentcamarche.net/contents/
1332-xml-introduction-a-xml
[29] https://git-scm.com/downloads
111
Annexe A
Annexe
L’enquête par questionnaire est un outil méthodologique d’observation qui com-

prend un ensemble de questions s’enchaînant de manière structurée et logique. Ce
type d’enquête vise à obtenir des données statistiques quantifiables et comparables
sur une population précise. Pour cela, le questionnaire est administré à un échan-
tillon représentatif de la population visée, c’est-à-dire à un groupe dont la taille est
suffisante, en termes de nombre d’individus, pour que les réponses données soient
représentatives de l’avis global de cette population.
Figure A.1 – Question 1
112
ANNEXE A. ANNEXE
113
ANNEXE A. ANNEXE
114

Feten

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

Feten

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur de la Recherche Scientifique

Rapport de Projet de Fin d’Études

Conception et développement d’une

Encadré par : Mouna Jouini

Réalisé par : Feten Abidi

Année universitaire : 2020/2021

Je tiens à exprimer toute ma reconnaissance à mon encadreur Madame Jouini

1 Cadre générale du projet 3

2.7.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . 21

3 Étude et réalisation du Release 1 29

4 Étude et réalisation du Release 2 71

5 Étude et réalisation du Release 3 92

5.2.1 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . 92

Conclusion Générale 109

1.1 capture d’écran du site « Zen Park »[7] . . . . . . . . . . . . . . . . . 6

2.1 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Diagramme de séquence du cas d’utilisation « Bloquer des conduc-

4.1 tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.1 tache du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3 Diagramme de séquence du cas d’utilisation « Configuration » . . . . 96

A.1 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

1.1 Analyse technique de site OPnGO . . . . . . . . . . . . . . . . . . . . 5

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Backlog du sprint 1 : Gestion d’utilisateurs . . . . . . . . . . . . . . . 29

4.1 Backlog du sprint 1 : Recherche parking . . . . . . . . . . . . . . . . 71

5.1 Backlog du sprint 1 : Configuration des parcs . . . . . . . . . . . . . 92

Depuis la naissance de la voiture jusqu’à aujourd’hui, il y a une augmentation im-

Dans ce chapitre, nous allons définir le cadre du projet en déterminant tout

1.1 Présentation du Projet

— Une gestion administrative rapide et facile

1.1.2 Objectif du projet

1.2 Étude de l’existant

1.2.1 Applications similaires

1.2.2.2 Analyse fonctionnelle de Zen Park

1.2.2.3 Analyse technique de ce site

Table 1.1 – Analyse technique de site OPnGO

Figure 1.1 – capture d’écran du site « Zen Park »[7]

1.2.3 Présentation d’OPnGO

1.2.3.2 Analyse fonctionnelle du site

1.2.3.3 Analyse technique de ce site

Table 1.2 – Analyse technique de site Zen Park

Figure 1.2 – capture d’écran du site « OPnGO »[8]

1.2.4 Présentation de One Park

1.2.4.2 Analyse fonctionnelle du site

1.2.4.3 Analyse technique de ce site

Table 1.3 – Analyse technique de site One Park

Figure 1.3 – capture d’écran du site « One Park »[6]

1.3 Critique de l’existant

Table 1.4 – Tableau de comparaison et critique des solutions existantes

Critère Zen Park OPnGO One Park

1.4 Solution proposée

1.5 Méthode de conception adoptée

un environnement de stress, mais aussi le temps consacré pour la réalisation du projet

1.5.1 La méthode Scrum

1.5.2 La méthodologie Scrum

• Backlog du sprint : une sélection de tâches retenues du "backlog du produit"

Figure 1.4 – Cycle de vie de la méthode Scrum[9]

2.2 Capture des besoins

2.2.1 Identification des acteurs

— L’analyste qui va gérer les recommandations et prévisualiser les statistiques.

2.2.2 Besoins fonctionnels