Vous êtes sur la page 1sur 131

République Tunisienne

Ministère de l'Enseignement Supérieure et de la Recherche Scientifique

Université de Jendouba

Faculté des Sciences Juridiques Économiques et de Gestion de Jendouba

Rapport de Projet de Fin d'Études


Présenté en vue de l'obtention du

Diplôme de Licence Fondamentale en Informatique Appliquée à la Gestion

Par

Soltani Wissal

Conception et développement d’une application Mobile qui


modernise les services municipaux

Encadrant académique :
Mr. Khemiri Nabil

Année Universitaire 2020 - 2021


Dédicace
J’offre ce modeste travail :

À mes chers parents,

Aucune dédicace ne pourra faire témoin de mon profond amour, mon


immense gratitude et plus grand respect à votre égard. On n’oubliera
jamais la tendresse et l’amour dont vous m’avez entourée depuis mon
enfance et l’encouragement dans les moments les plus difficiles de ma
scolarité.

A mes adorables sœurs, qui par les soutiens moraux et les


encouragements, multipliait mes efforts, pour pouvoir
réaliser parfois l'impossible.

À tous mes amis, et à tous ceux qu’on aime et à toutes les personnes
qui m’ont encouragée et se sont données la peine de me soutenir
durant cette formation.
À mes chers enseignants sans exception.
À ceux qui me sont chers.
Soltani Wissal
Remerciement
Nous tenions tout d’abord à remercier DIEU de nous avoir donné le
courage, la force et la volonté pour achever ce travail.

La réalisation de ce projet a été possible grâce au soutiens de


plusieurs personnes à qui je voudrais témoigner toute ma gratitude.

J’adresse mes vifs remerciements à toute personne contribuant de


près ou de loin à la réalisation de ce travail.

Nous tenions à remercie vivement la faculté de sciences juridiques


économiques et de gestion de jendouba(FSJEGJ).

Mes remerciements le plus sincères à Mr. Khemiri Nabil, mon


encadrant à la faculté de sciences juridiques économiques et de
gestion de jendouba, pour son encadrement, ses remarques
constructives tout au long de notre travail.

Enfin, mes remerciements à tous mes professeurs, Ensuite, je remercie


les membres de jury pour avoir accepté d’évaluer le résultat auquel
j’arrivés.
Sommaire

Dédicace.........................................................................................................................................3

Remerciement.................................................................................................................................4

Sommaire........................................................................................................................................5

Introduction générale.....................................................................................................................1
Chapitre1 : Présentation Générale du Projet................................................................................3
1. Introduction........................................................................................................................3
2. Présentation de projet.........................................................................................................3
2.1 Contexte de projet.............................................................................................................3
2.2 Problématique...................................................................................................................4
2.3 Survol sur les applications similaires................................................................................4
2.4 Comparaison et critiques des solutions existantes............................................................9
3 Solution proposé.................................................................................................................9
4 Conclusion........................................................................................................................11
Chapitre 2: Analyse et spécification des besoins..........................................................................12
1. Introduction......................................................................................................................12
2. Besoins du client...............................................................................................................12
3. Identifications des acteurs................................................................................................12
4. Identifications des besoins................................................................................................13
4.1 Les besoins fonctionnels..................................................................................................13
4.2 Les besoins non fonctionnels...........................................................................................14
5. Diagramme de cas d’utilisations principale......................................................................15
6. Le Backlog du produit......................................................................................................16
7. L’organigrammes des taches............................................................................................19
8. Livrables de projet............................................................................................................19
9. Risque de projet................................................................................................................20
10. Conclusion.....................................................................................................................20
Chapitre 3: Démarche du projet..................................................................................................21
1. Introduction......................................................................................................................21
2. Le choix de la méthode de gestion de projet.....................................................................21
2.1 Comparaison entre les méthodes agiles et les méthode classiques...................................21
2.2 Comparaison des méthodes agiles....................................................................................22
2.3 Justification de choix de la méthode Scrum......................................................................24
3. Description des éléments de base de Scrum......................................................................25
3.1 Principe de Scrum...........................................................................................................25
3.2 Description des éléments de base de Scrum....................................................................26
3.4 Présentation des évènements de Scrum...........................................................................27
4. Gestion de projet...............................................................................................................28
4.1 Planification....................................................................................................................28
4.2 Diagramme de Gant........................................................................................................29
4.3 Equipe de réalisation du projet.......................................................................................29
5. Conclusion........................................................................................................................30
Chapitre 4 : Cartographie et architecture du projet....................................................................31
1. Introduction......................................................................................................................31
2. Carte d’identité de projet................................................................................................31
3. Architecture de la solution................................................................................................32
3.1 Architecture logique.......................................................................................................32
3.2 Architecture logicielle.....................................................................................................33
4. Conception détaillée..........................................................................................................34
4. 1 Diagramme de package..................................................................................................34
4.2 Diagramme de déploiement............................................................................................35
4.3 Diagramme de composant...............................................................................................36
5. Environnement du travail.................................................................................................36
5.1 Environnement matériel.................................................................................................36
5.2 Envirement logiciel.........................................................................................................37
5.3 Langages de programmations.........................................................................................39
6. Conclusion........................................................................................................................41
Chapitre 5 : Mise en œuvre du release 1......................................................................................42
1. Introduction......................................................................................................................42
2. Sprint 1.............................................................................................................................42
2.1 Backlog du sprint 1...........................................................................................................42
2.2 Tableau des taches...........................................................................................................43
2.3 Analyse............................................................................................................................43
2.4 Conception......................................................................................................................47
2.5 Réalisation......................................................................................................................53
2.6 Test et validation.............................................................................................................55
2.7 Sprint review...................................................................................................................56
3. Sprint 2................................................................................................................................57
3.1 Backlog du sprint 2.........................................................................................................57
3.2 Tableau des taches..........................................................................................................57
3.3 Analyse............................................................................................................................58
3.4 Conception......................................................................................................................61
3.5 Réalisation......................................................................................................................66
3.6 Test et validation.............................................................................................................66
3.7 Sprint review...................................................................................................................67
4. Sprint 3.................................................................................................................................67
4.1 Backlog produit du sprint 3............................................................................................67
4.2 Tableau des taches..........................................................................................................68
4.3 Analyse............................................................................................................................68
4.4 Conception......................................................................................................................71
4.6 Réalisation......................................................................................................................75
4.7 Test et validation.............................................................................................................76
4.6 Sprint Review..................................................................................................................77
5. conclusion.............................................................................................................................77
Chapitre 6 : Mise en œuvre du release 2......................................................................................78
1. Introduction......................................................................................................................78
2. Sprint 1.............................................................................................................................78
2.1 Backlog du sprint 1.........................................................................................................78
2.2 Tableau des taches..........................................................................................................79
2.3 Analyse............................................................................................................................79
2.4 Conception......................................................................................................................82
2.5 Réalisation......................................................................................................................86
2.6 Test et validation.............................................................................................................87
2.7 Sprint review...................................................................................................................87
3. Sprint 2................................................................................................................................88
3.1 Backlog du sprint 2.........................................................................................................88
3.2 Tableau des taches..........................................................................................................88
3.3 Analyse............................................................................................................................89
3.4 Conception......................................................................................................................92
3.5 Réalisation......................................................................................................................98
3.6 Test et validation.............................................................................................................99
3.7 Sprint review.................................................................................................................100
4. Sprint 3...............................................................................................................................100
4.1 Backlog produit du sprint 3..........................................................................................100
4.2 Tableau des taches........................................................................................................101
4.3 Analyse..........................................................................................................................101
4.4 Conception....................................................................................................................104
4.5 Réalisation.....................................................................................................................109
4.6 Test et validation...........................................................................................................109
4.7 Sprint Review................................................................................................................110
Conclusion générale...................................................................................................................111
Webographie...............................................................................................................................113

Annexes......................................................................................................................................115
Liste des figures
Figure 1: Page d'accueil de l'application «elBaladiya»..................................................................5
Figure 2: Page d'accueil de l'application Baladiyati......................................................................6
Figure 3: Interfaces d'inscription et d'authentification de l'application "CIVITAS"...................7
Figure 4: Interface de connexion et d'inscription de l'application "CIVITAS"............................8
Figure 5: Diagramme de cas d'utilisation globale........................................................................15
Figure 6: L'organigramme des taches:........................................................................................19
Figure 7: Livrable de projet.........................................................................................................19
Figure 8: Méthode Scrum............................................................................................................26
Figure 9: Diagramme de Gant.....................................................................................................29
Figure 10: Carte d'identité de projet...........................................................................................31
Figure 11: Architecture logique...................................................................................................32
Figure 12: Le modèle MVC..........................................................................................................33
Figure 13: Diagramme de paquetage globale...............................................................................34
Figure 14: Diagramme de déploiement........................................................................................35
Figure 15: Diagramme de composant..........................................................................................36
Figure 17: Logo Trello....................................................................................................................37
Figure 18: Logo draw.io.................................................................................................................37
Figure 19: Logo Gant Project..........................................................................................................37
Figure 20: Logo StarUML................................................................................................................37
Figure 21: Logo Notepad++............................................................................................................38
Figure 22: Logo VirtualBox.............................................................................................................38
Figure 23: Logo Vagrant.................................................................................................................38
Figure 24: Logo Git........................................................................................................................38
Figure 25: Logo Android studio......................................................................................................38
Figure 26: Logo MySQL Workbench...............................................................................................39
Figure 27: Logo Xampp..................................................................................................................39
Figure 28: Logo PHP.......................................................................................................................39
Figure 29: Logo HTML5..................................................................................................................39
Figure 30: Logo CSS3......................................................................................................................40
Figure 31: Logo JavaScript.............................................................................................................40
Figure 32: Logo JQuery..................................................................................................................40
Figure 33: Logo Java......................................................................................................................40
Figure 34: Logo XML......................................................................................................................41
Figure 35: tableau des taches du Sprint 1....................................................................................43
Figure 36: Diagramme de cas d'utilisation du Sprint 1................................................................43
Figure 37: Diagramme de cas d'utilisation "S'inscrire"..............................................................44
Figure 38: Diagramme de cas d'utilisation "S'authentifier".......................................................45
Figure 39: Diagramme de cas d'utilisation "Bloquer utilisateur"...............................................46
Figure 40: Diagramme de cas d'utilisation "Mise à jour profil".................................................46
Figure 41: Diagramme de classe du Sprint 1...............................................................................47
Figure 42: Diagramme de package du Sprint 1...........................................................................49
Figure 43: Diagramme de séquence "S'inscrire".........................................................................50
Figure 44: Diagramme de séquence "S'authentifier"..................................................................50
Figure 45: Diagramme de séquence "Bloquer utilisateur"..........................................................51
Figure 46: Diagramme de séquence "Mise à jour profil"............................................................51
Figure 47: Diagramme d'activité "S'inscrire".............................................................................52
Figure 48: Diagramme d'activité "S'authentifier"......................................................................52
Figure 49: Interface" Authentification" version mobile..............................................................53
Figure 50: Interface "Authentification" version web..................................................................53
Figure 51:Interface "Inscription" version web............................................................................54
Figure 52: Interface "Inscription" version mobile......................................................................54
Figure 53: Interface "Gérer utilisateur"......................................................................................55
Figure 54: Sprint Burn-down chart.............................................................................................56
Figure 55: Tableau des taches de Sprint 2...................................................................................57
Figure 56: Diagramme de cas d'utilisation de Sprint 2................................................................58
Figure 57: Diagramme de cas d'utilisation "Supprimer véhicule"..............................................58
Figure 58: Diagramme de cas d'utilisation "Rechercher cité"....................................................59
Figure 59: Diagramme de cas d'utilisation "Modifier rue".........................................................60
Figure 60: Diagramme de classe de Sprint 2................................................................................61
Figure 61: Diagramme de package de Sprint 2............................................................................63
Figure 62: Diagramme de séquence "Supprimer véhicule".........................................................64
Figure 63: Rechercher cité...........................................................................................................64
Figure 64: Diagramme se séquence "Modifier rue"....................................................................65
Figure 65: Diagramme d'activité "Ajouter véhicule"..................................................................65
Figure 66: Interface "Gérer cité"................................................................................................66
Figure 67: Sprint Burn-down chart.............................................................................................67
Figure 68: Tableau des taches de Sprint 3...................................................................................68
Figure 69: Diagramme de cas d'utilisation de Sprint 4................................................................68
Figure 70: Diagramme de cas d'utilisation «modifier chemin"...................................................69
Figure 71: Diagramme de cas d'utilisation «supprimer chemin"................................................70
Figure 72: Diagramme de classe de Sprint 3................................................................................71
Figure 73: Diagramme de package de Sprint 3............................................................................73
Figure 74: Diagramme de séquence «modifier chemin"..............................................................74
Figure 75: Description de cas d'utilisation "Supprimer chemin"................................................75
Figure 76: Interface "Gérer véhicule".........................................................................................75
Figure 77: Interface "tournée véhicule"......................................................................................76
Figure 78: Sprint Burn-down chart.............................................................................................77
Figure 79: Tableau des taches de Sprint 1...................................................................................79
Figure 80: Diagramme de cas d'utilisation de Sprint 1................................................................79
Figure 81: Diagramme de cas d'utilisation "Ajouter produit recyclable"...................................80
Figure 82: Diagramme de cas d'utilisation "suivre commande produit recyclable"...................81
Figure 83: Diagramme de classe se Sprint 1................................................................................82
Figure 84: Diagramme de package de Sprint 1............................................................................83
Figure 85: Diagramme de séquence "Ajouter produit recyclable"..............................................84
Figure 86: Diagramme de séquence "Suivre commande de produit recyclable".........................84
Figure 87: Diagramme d'activité "supprimer véhicule"..............................................................85
Figure 88: Diagramme d'état "Etudier demande"......................................................................85
Figure 89: Interface "Gérer produit recyclage"..........................................................................86
Figure 90: Interface "Gérer demande de produit recyclable".....................................................86
Figure 91: Sprint Burn-down chart.............................................................................................87
Figure 92: Tableau des taches de Sprint 2...................................................................................88
Figure 93: Diagramme de cas d'utilisation de Sprint 2................................................................89
Figure 94: Diagramme de cas d'utilisation "Etudier réclamation".............................................89
Figure 95: Diagramme de cas d'utilisation "Réclamer une faille"...............................................90
Figure 96: Consulter réclamation................................................................................................91
Figure 97: Diagramme de classe de Sprint 2................................................................................92
Figure 98: Diagramme de package de Sprint 2............................................................................94
Figure 99: Diagramme de séquence "Consulter réclamation".....................................................95
Figure 100: Diagramme de séquence "Réclamer une faille".......................................................95
Figure 101: Etudier réclamation..................................................................................................96
Figure 102: Diagramme d'activité "Modifier sondage"...............................................................96
Figure 103: Diagramme d'état de transition « Etudier réclamation"..........................................97
Figure 104: Interface "Gérer réclamation".................................................................................98
Figure 105: Interface "Gérer sondage".......................................................................................98
Figure 106: Sprint Burn-down chart.........................................................................................100
Figure 107: Tableau des taches de Sprint 3................................................................................101
Figure 108: Diagramme de cas d'utilisation de Sprint 3............................................................101
Figure 109: Diagramme de cas d'utilisation " Voter Sondage "................................................102
Figure 110: Diagramme de cas d'utilisation "Consulter évènement"........................................102
Figure 111: Diagramme de cas d'utilisation «Configurer statistique".......................................103
Figure 112: Diagramme de classe globale..................................................................................104
Figure 113: Diagramme de package de sprint 3.........................................................................106
Figure 114: Diagramme de séquence "voter un sondage".........................................................107
Figure 115: Diagramme de séquence "consulter évènement"....................................................107
Figure 116: Diagramme de séquence "Configurer statistique".................................................108
Figure 117: Diagramme d'activité "Supprimer évènement".....................................................108
Figure 118: Interface 'Gérer évènement"..................................................................................109
Figure 119: Test et validation.....................................................................................................109
Figure 120: Sprint Burn-down chart.........................................................................................110
Liste des tableaux
Tableau 1: Analyse ergonomique de l’application"ElBaladiya.tn"...............................................5
Tableau 2: Analyse ergonomique de l’application« Baladiyati »...................................................7
Tableau 3: Analyse ergonomique de l’application "CIVITAS"....................................................8
Tableau 4: Comparaison des solution existantes...........................................................................9
Tableau 5: Liste des acteurs.........................................................................................................12
Tableau 6: Le Backlog du produit..............................................................................................16
Tableau 7: Risque de projet.........................................................................................................20
Tableau 8: Comparaison entre l'approche classique et l'approche agile.....................................22
Tableau 9: Comparaison entre les méthodes agiles......................................................................24
Tableau 10: Equipe de réalisation de projet:...............................................................................29
Tableau 11: Environnement logiciel............................................................................................37
Tableau 12: Langages de programmations..................................................................................39
Tableau 13: Backlog du sprint 1..................................................................................................42
Tableau 14: Description de cas d'utilisation "S'inscrire"............................................................44
Tableau 15: Description de cas d'utilisation "S'authentifier".....................................................45
Tableau 16: Description de cas d'utilisation "Bloquer utilisateur".............................................46
Tableau 17: Description de cas d'utilisation "Mise à jour profil"...............................................47
Tableau 18: Dictionnaire de donné de la table "Utilisateur".......................................................48
Tableau 19: Dictionnaire de donné de la table "Citoyen"...........................................................48
Tableau 20: Dictionnaire de donné de la table "Société de recyclage"........................................48
Tableau 21: Dictionnaire de donné de la table "Agent"..............................................................49
Tableau 22: Test et validation......................................................................................................55
Tableau 23: Backlog de Sprint 2..................................................................................................57
Tableau 24: Description du cas d’utilisation « Supprimer véhicule »..........................................59
Tableau 25: Description du cas d’utilisation «Rechercher cité»..................................................60
Tableau 26: Description du cas d’utilisation «Modifier rue».......................................................61
Tableau 27 : Dictionnaire de donné de la table « véhicule »........................................................62
Tableau 28: Dictionnaire de donné de la table « cité ».................................................................62
Tableau 29: Dictionnaire de donné de la table « rond-point ».....................................................62
Tableau 30: Dictionnaire de donné : table « rue ».......................................................................63
Tableau 31: Test et validation......................................................................................................66
Tableau 32: Backlog du sprint 3..................................................................................................67
Tableau 33: Description des cas d'utilisation "modifier chemin"................................................69
Tableau 34: Description de cas d'utilisation «supprimer chemin"..............................................70
Tableau 35: Dictionnaire de donné de la table « circuit »............................................................72
Tableau 36: Dictionnaire de donné de la table « tournée »..........................................................72
Tableau 37: Dictionnaire de donné de la table « rue_circuit ».....................................................72
Tableau 38: Test et validation......................................................................................................76
Tableau 39: Backlog de Sprint 1..................................................................................................78
Tableau 40: Description de cas d'utilisation "Ajouter produit recyclable".................................80
Tableau 41: Description de cas d'utilisation "Suivre commande de produit recyclable":..........81
Tableau 42: Dictionnaire de donné de la table « produit recyclable ».........................................82
Tableau 43: Dictionnaire de donné de la table « demande ».......................................................83
Tableau 44: Test et validation de Sprint 1...................................................................................87
Tableau 45: Backlog de Sprint 2..................................................................................................88
Tableau 46: Description de cas d'utilisation "Etudier réclamation"...........................................90
Tableau 47: Description de cas d'utilisation "Réclamer une faille"............................................91
Tableau 48: Description de as d'utilisation "Consulter réclamation".........................................92
Tableau 49: Dictionnaire de donné de la table « réclamation »...................................................93
Tableau 50: Dictionnaire de donné de la table « proposition »...................................................93
Tableau 51: Dictionnaire de donné de la table sondage...............................................................93
Tableau 52: Test et validation......................................................................................................99
Tableau 53: Backlog du Sprint 3................................................................................................100
Tableau 54: Description du cas d’utilisation « Voter Sondage».................................................102
Tableau 55: Description du cas d’utilisation « Consulter évènement »......................................103
Tableau 56: Description du cas d’utilisation « Configurer statistique »....................................104
Tableau 57: Dictionnaire de donné de la table « Vote ».............................................................105
Tableau 58: Dictionnaire de donné de la table « Evènement »...................................................105
Introduction générale Wissal SOLTANI
__________________________________________________________________________________
Introduction

Introduction générale

De nos jours, l’informatique peut se trouver partout et fait partie du quotidien de bien
de personnes. Il a effectivement été vu que rien ne fonctionne plus réellement sans elle, les
écoles, les postes, les magasins, toutes les sociétés en font usage. Il a fallu que chaque
personne s’adapte à la notion d’informatique en tous genres. Le domaine étant très développé
rare sont ceux qui peuvent s’en passé car il arrive à toucher efficacement différents domaines
même au sein de la municipalité tel que les payes développées cherchent à impliquer leurs
citoyens à fin d’améliorer leurs services municipaux et dans ce contexte, notre application est
ciblée.

De même, le monde est témoin d’un grand progrès dans les technologies, en particulier
dans le développement web et le développement mobile, qui nous apporte de nombreux
services tels qu’une interface utilisateur conviviale qui le rendent très facile d’interagir avec le
web et de rendre le client satisfait et répondre à ses besoins.

C’est dans ce cadre que se déroule notre projet au sein du Faculté des Sciences
Juridique, Économique et de gestion de Jendouba. Le projet consiste à concevoir et
développer une application Web Mobile qui modernise les services municipaux.
Pour exécuter et réaliser cette application, il est important de suivre une
méthodologie adaptée. C’est la méthode agile à savoir la méthode Scrum qui nous aidons à
réaliser progressivement des projets de la planification à la mise en œuvre pour améliorer
l’efficacité et la rentabilité.
Le présent rapport présentera les différentes étapes de la réalisation de ce projet et se
déroule sur six chapitres :
 Le premier chapitre présentation générale du Projet est un chapitre introductif dans
lequel nous exposons le cadre général du projet, la problématique et les solutions
proposées.

1
Introduction générale Wissal SOLTANI
__________________________________________________________________________________

 Le deuxième chapitre nommé Analyse et Spécification des Besoins où nous


dégageons les besoins fonctionnels et non fonctionnels ainsi que le Backlog de
produit et nous définissons les livrables de projets.
 Le troisième chapitre nommé démarche du projet est dédié pour la justification de
choix de méthodologie de développement, ensuite le planning de travail et affectation
de rôles pour chaque intervenant dans la réalisation de ce projet
 Le chapitre suivant est dédié à 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.
 Les 2 chapitres suivants seront dédiés aux deux 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 enfin test et validation.

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
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________
Chapitre 1

Chapitre1 : Présentation Générale du Projet

1. Introduction
Dans ce chapitre introductif, nous présenterons dans un premier lieu l’organisme d'accueil
et nous passons à identifier le contexte de projet où en définissant la problématique puis la
comparaison et les critique des solutions existantes dans un deuxième lieu et nous clôturerons
par la solution proposée qui sera bien détaillée tout au long du rapport.

2. Présentation de projet
2.1 Contexte de projet
Ce projet rentre dans le cadre du projet de fin d’études qui vient de conclure notre formation
de licence en informatique appliquée à la gestion à la Faculté des Sciences juridiques
économiques et de gestion de Jendouba (FSJEGJ).

Nous avons observé que malgré le développement de technique de l’information et de la


communication, qu’encore notre environnement souffrit de déséquilibre, le manque d’ordre et
de propreté tel qu’aucune interaction, information, participation et l’implication des citoyens
avec la municipalité.

Nous avons décidé de résoudre ce véritable problème en lançant une application web mobile.
Elle a pour objectif la conception et le développement d’une application web mobile. Cette
application est destinée à la municipalité.

La mise en place de « Smart Municipality » 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 (United


Modeling Language) pour développer les axes fonctionnels, statique et dynamique ;

— Axe de développement : utilisation du langage PHP7 et l’utilisation de la plateforme de


développement Vagrant, Git, Android.

3
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

2.2 Problématique
De nos jours, les gens veulent toujours plus de rapidité, de facilité, de l’information, de
participation et de propreté et malgré l’évolution de technologie que notre environnement
encore souffrit de ces derniers.
En se basant sur l’enquête (voir annexes) destiné aux citoyens, nous venons de relever
les différents problèmes au niveau de la municipalité et on résulte que l’attente avant
l’arrivée de véhicule municipale de collecte les déchets représente l’un des principaux
motifs d’insatisfaction citoyens, telle que les poubelles restent dispersée dans les rues
jusqu’à l’arrivée de véhicule de collecte les déchets ,de même ces poubelles contribuent à
la pollution des rues d’une part et de la nature d’autre part, ce qui pose un risque grave , en
effets ces citoyens ne savent plus ce qui ce passe dans la municipalité ce qui les prive de
leur partenaire dans la vie municipale.
Alors, les questions qui se posent sont :
 Comment impliquer les citoyens dans la vie municipale ?
 Comment on peut résoudre les problèmes des horaires des véhicules de collecte les
déchets ?
 Comment on peut résoudre les risques provoqués par les déchets (poubelles) ?
 Quels sont les solutions adéquates pour améliorer et moderniser les services
municipaux?
 Qu’elle est l’approche intégrée pour résoudre ces obstacles ?

2.3 Survol sur les applications similaires


2.3.1 Analyse de l’application « ElBaladiya.tn »
Description de l’application

C’est une plateforme municipale pour la gouvernance participative et la gestion


administrative intelligente.

Analyse fonctionnelle de l’application

Il permet aux citoyens de :

 Suivre les actualités de la municipalité.


 Déposer ses plaintes et demandes.
 Participer à l’entretien et maintenance de la zone municipale.
Analyse ergonomique de l’application [1]

4
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________
Tableau 1: Analyse ergonomique de l’application"ElBaladiya.tn"

Dénotations Description

Logo Il s’agit 2 couleurs (bleu, blanc et noir ) sa position à


droite.

La page d’accueil est disposée Cette disposition donne un sens de lecture qui rend la
Horizontalement. page plus simple.

La gamme de couleurs utilisés est Blanc pour l’arrière-plan.


bleu, blanc , noir et gris. Grise c’est pour l’écriture.
Blanc pour les boutons.
L’assemblage de ces couleurs donne une cohérence aux
différentes pages du site.

Figure 1: Page d'accueil de l'application «elBaladiya»

5
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

Figure 2: Page d'accueil de l'application Baladiyati

2.3.2 Analyse de l’application « Baladiyati »


Description de l’application « Baladiyati » (Ma Municipalité) est une plate-
forme pour toutes les municipalités libanaises existantes.
L’idée est d’énumérer le plus grand nombre de municipalités du Liban dans
l’application Baladiyati pour être en mesure d’accéder aux différents services
et fonctionnalités.
Analyse fonctionnelle de l’application

-Actualités
-Services municipaux / Demandes
-Formulaires de suivi
-Suggestions et plaintes
-Sondages
-Cotisations (taxes municipales)
-Numéros d’urgence
-Appelez directement votre municipalité

Analyse ergonomique de l’application [2]

6
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________
Tableau 2: Analyse ergonomique de l’application« Baladiyati »

Dénotations Description

Logo Il s’agit 3 couleurs (Rouge, vert et marron ) sa position


au centre.

La page d’accueil est disposée Cette disposition donne un sens de lecture qui rend la
verticalement. page plus simple.

Il existe plusieurs couleurs mais le Blanc pour l’arrière-plan.


blanc est le couleur dominant. Noire c’est pour l’écriture.
Plusieurs couleurs pour les boutons.

Les images HD Donne une description pour les différents services


d’application et plus compréhensible aussi bien aux
utilisateurs.

Figure 3: Interfaces d'inscription et d'authentification de l'application "CIVITAS"

2.3.3 Analyse de l’application « CIVITAS Municipalité numérique »


Description de l’application

CIVITAS Municipalité numérique, est une solution qui digitalise les services
municipaux pour vous faciliter l’accès en ligne aux documents et autorisations fournis
par les services communaux. Elle permet un contact direct avec les services concernés

7
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

par votre demande ainsi le traitement rapide de votre quête tout en restant notifier de
tout avancement ou modification.
Analyse fonctionnelle de l’application
CIVITAS comporte aujourd’hui quatre (4) services :
- Rokhsti : pour la demande, le suivi et la réception de permis de bâtir .
- Demande d’accès à l’information .
- Dépôt de réclamation citoyenne .
- Guide pratique et nouveautés municipales.
Analyse ergonomique de l’application [3]

Tableau 3: Analyse ergonomique de l’application "CIVITAS"

Dénotations Description

Logo Il s’agit 2 couleurs (vert et blanc ) sa position au centre.

La page d’accueil est disposée Cette disposition donne un sens de lecture qui rend la
verticalement. page plus simple.

La gamme de couleurs utilisés est Blanc pour l’arrière-plan.


blanc, vert, bleu , noir et gris. Blanc pour l’arrière-plan de menu.
Noire c’est pour l’écriture.
Gris pour les ions.

Langue Arabe

Figure 4: Interface de connexion et d'inscription de l'application "CIVITAS"

8
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

2.4 Comparaison et critiques des solutions existantes


On compare les applications précédentes suivant des précises et on résume leurs
comparaisons dans le tableau suivant :

Tableau 4: Comparaison des solution existantes

Nom de l’application El baladia.tn Baladiyati CIVITAS

Ergonomie +++ ++ ++

Performance +++ ++++ +++

Fonctionnalités +++ ++++ ++++

Facilité d’utilisation +++ +++ ++++

Documentation ++ ++++ +

Sécurité ++++ ++++ ++

3 Solution proposé
En se concentrant sur ce thème et pour remédier aux problèmes précédemment cités,
Notre mission consiste à conceptualiser et développer d’une application web mobile qui
modernise les services municipaux qui a pour objectif de :

 Améliorer la qualité de travail de la municipalité.


 Produire une ville propre.
 Réaliser la motivation et la conscience des citoyens.
 Informer et impliquer les citoyens dans la municipalité (proposition, et prise de
décision à travers les votes).
 Informer chaque citoyen de distance et de temps restent-t-ils pour l’arrivée du véhicule
municipal de collecte de déchets.
 Vise à résoudre le problème des déchets en fournissent aux conteneurs de la
municipalité de différentes couleurs selon le type de produit recyclable (plastique,
verre) à collecter et à vendre à un prix nominal aux entreprises de recyclages pour les
recréant.

9
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

 Pour gagner du temps et la réduire la consommation d’essence, nous intégrons


l’approche de l’intelligence artificielle dans notre application toute en intégrant
l’algorithme de calcul de plus court chemin « Dijkstra » :
L'algorithme de Dijkstra :

En théorie des graphes, l'algorithme de Dijkstra (prononcé [dɛɪkstra]) sert à résoudre le


problème du plus court chemin. Il permet, par exemple, de déterminer un plus court chemin
pour se rendre d'une ville à une autre connaissant le réseau routier d'une région. Plus
précisément, il calcule des plus courts chemins à partir d'une source vers tous les autres
sommets dans un graphe orienté pondéré par des réels positifs. On peut aussi l'utiliser pour
calculer un plus court chemin entre un sommet de départ et un sommet d’arrivée. [4]

 Pour connaitre la distance et l’horaires des véhicules municipaux nous utilisons les
itinéraires :
Les itinéraires :

Google Maps vous permet d'obtenir des itinéraires pour vos trajets en voiture, en
transports en commun, à pied ou à vélo. Chaque fois que vous voyez plusieurs itinéraires vers
votre destination, le meilleur est indiqué en bleu. Les autres sont en gris.

Certains itinéraires dans Google Maps sont en version bêta, et leur disponibilité peut être
limitée. Soyez toujours prudent lorsque vous suivez un itinéraire sur Google Maps. Prêtez
attention à votre environnement à tout moment et faites-en sorte d'assurer votre sécurité ainsi
que celle des personnes qui vous entourent. En cas de doute, respectez la signalisation de la
route ou du chemin que l'itinéraire vous fait emprunter. [5]

 Pour résoudre les problèmes des malvoyants et en même temps pour que le citoyen ne
s’ennuie pas à lire une publication/article publié par la municipalité nous utilisons la
synthèse vocale :
La synthèse vocale :

La synthèse vocale est une technique informatique de synthèse sonore qui permet de créer
de la parole artificielle à partir de n'importe quel texte. Pour obtenir ce résultat, elle s'appuie à
la fois sur des techniques de traitement linguistique, notamment pour transformer le texte
orthographique en une version phonétique prononçable sans ambiguïté, et sur des techniques
de traitement du signal pour transformer cette version phonétique en son numérisé écoutable
sur un hautparleur. Il s'agit, comme la reconnaissance vocale, d'une technologie permettant de

10
Chapitre1 : Présentation générale de projet Wissal SOLTANII
__________________________________________________________________________________

construire des interfaces vocales. Parmi les applications, on peut citer la vocalisation d'écrans
informatiques pour les personnes aveugles ou fortement malvoyantes1 (lecteur d'écran), ainsi
que de nombreuses applications de serveurs vocaux téléphoniques, comme les annuaires
vocaux de grande taille, où la synthèse vocale est la seule technique viable pour permettre la
restitution sonore des noms et des adresses des abonnés. [6]

4 Conclusion
Tout au long de ce chapitre, nous avons présenté le contexte général du projet ainsi qu’a
problématique. Par ailleurs, nous avons pu dégager quelques similaires (en Tunisie et à
l’étranger) puis en fait une petite Comparaison et critique des solutions existantes. Alors que
le chapitre suivant sera consacré à l’analyse et spécification des besoins.

11
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

Chapitre 2

Chapitre 2: Analyse et spécification des besoins

1. Introduction
Dans ce chapitre nous voulons montrer les besoins du client, ainsi que les besoins
fonctionnels et non fonctionnels de la future application, de préciser les livrables et en fin
les risques les plus critiques du projet.

2. Besoins du client
Le client cherche à avoir une application prédictive qui permet de résoudre les problèmes
d’horaires des véhicules municipaux d’une part et d’autre part de réaliser l’implication des
citoyens en contact avec la municipalité aussi d’exploiter les déchets (les poubelles) grâce
à la fourniture des récipients de couleurs différents pour recycler ces produits telle qu’on
mettre les sociétés de recyclage en relation avec la municipalité.

3. Identifications des acteurs


Les acteurs de notre application sont :

Tableau 5: Liste des acteurs

Acteur Rôle

Administrateur C’est la personne responsable de contrôler la totalité du système.

Citoyen C’est la personne bénéficier par les services offerts par l’application .

L’agent municipal C’est la personne responsable de gérer tous les fonctionnalités dans
l’application.

C’est le client de l’application qui a la possibilité de commander un produit


Société de recyclage
recyclable depuis la municipalité et à bas prix.

12
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

4. Identifications des besoins


4.1 Les besoins fonctionnels
Nous présentons dans ce qui suit les différentes fonctionnalités du système. Ces
fonctionnalités doivent répondre aux attentes du client de l’application.

 Notre application assurera à l’administrateur les fonctionnalités suivantes :


L’administrateur a le droit de Controller n’importe quelle action dans
l’application aussi que :
 S’authentifier : il peut accéder à son interface personnelle tout simplement
en saisir son login et son mot de passe.
 Gérer utilisateur : l’administrateur a la possibilité d’ajouter, modifier,
supprimer, bloquer et débloquer un utilisateur.
 Configurer les statistiques
 Notre application assurera à l’agent municipal les fonctionnalités suivantes :
 L’authentification.
 Gestion de véhicules
 Gestion des cités
 Gestion des rues
 Gestion des ronds-points
 Gestion des tournées
 Gestion des circuits (chemins)
 Gestion des sondages
 Gestion des réclamations
 Gestion des évènements
 Gestion de produit recyclable
 Gestion de commande de produit recyclable
 Notre application assurera aux citoyens les fonctionnalités suivantes :
 Inscription et authentification
 Publier des propositions
 Voter des sondages
 Réclamer des failles
 Consulter des événements

13
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

 Se notifier de l’arrivé de véhicule municipal.

 Notre application assurera aux sociétés de recyclages les fonctionnalités


suivantes:
 Inscription et authentification
 Commander un produit recyclable.
 Suivre ses commandes de produit recyclable.

4.2 Les besoins non fonctionnels


Les besoins non fonctionnels consistent à décrier les objectifs liés aux performances
du système et aux contraintes de son environnement. Parmi ces critères on retrouve :.

La sécurité : L’accès à l’application et les données doivent être sécurisés contre


l'accès par des utilisateurs non autorisés.

La fiabilité : l’application doit fonctionner de façon cohérente sans erreurs et doit être
satisfaisante.

L’ergonomie des interfaces : l’application doit offrir des interfaces simples à utiliser
pour tous types d’utilisateurs, elle doit assurer une facilité de navigation et une
compréhensibilité d’écriture.

La maintenance et la réutilisabilité : le code doit être suffisamment clair pour


permettre des éventuelles évolutions, améliorations ou corrections.

L’efficacité : est le degré de réalisation des objectifs. On considère qu'une activité est
efficace si les résultats obtenus sont identiques aux objectifs définis.

Flexibilité : c'est-à-dire facilité avec laquelle des fonctions peuvent être ajoutées,
modifiées ou supprimées dans un programme.

La portabilité : peut s’exécuter sur différente plateformes ou système d’exploitation.

La modularité : L’application doit être composée en des modules indépendants.

La robustesse : une utilisation incorrecte n'entraîne pas de dysfonctionnement.

14
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

La maintenabilité : est, dans le domaine informatique, la capacité pour des


composants ou des applications à être maintenus, de manière cohérente et à moindre
coût, en état de fonctionnement.

5. Diagramme de cas d’utilisations principale

Figure 5: Diagramme de cas d'utilisation globale

15
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

6. Le Backlog du produit
Le Backlog de produit correspond à une liste priorisée des besoins et des exigences du
produit. 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 l’utilisateur, 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 l’utilisateur ;
 Priorité : c’est la valeur métier qui dirige la priorisation du développement
des histoires utilisateurs suivant les attentes et les besoins du produit.
 Story Point : c’est l'effort nécessaire à la réalisation d'une histoire utilisateur.

Tableau 6: Le Backlog du produit

ID Feature USER STORY Priorité STORY


POINT(jr)

1 S’inscrire En tant que citoyen à je veux m’inscrire 1 3


pour bénéficier par les services offerts par
l’application.

2 S’authentifier En tant qu’utilisateur je veux 1 3


m’authentifier afin que l’application doive
être plus sécurisée.

3 Gérer En tant qu’admin je veux gérer les 1 6


utilisateur utilisateurs pour contrôler le bon
comportement de ses derniers et en cas
d’une fausse action je peux bloquer
l’utilisateur et dans des cas pires peut le
supprimer.

4 Mise à jour En tant qu’utilisateur je jeux mise à jour 1 3


profil mon profile.

5 Gérer véhicule En tant qu’Agent je veux gérer les 1 5


véhicules pour mieux suivre leurs
déroulements.
6 Gérer cité En tant qu’Agent à je veux gérer les cités à 1 5
fin d’arriver à notifier chaque citoyen de

16
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________
l’arrivé de véhicule concernant le cité qu’il
appartient.
7 Gérer rue En tant qu’Agent à je veux gérer les rues à 1 3
fin de facilite le calcul de plus court
chemin.
8 Gérer rond- En tant qu’Agent à je veux gérer les ronds- 1 2
point points à fin de facilite le calcul de plus court
chemin.
9 Gérer circuit En tant qu’Agent à je veux gérer les circuits à 2 2
fin de facilite le calcul de plus court chemin.
10 Gérer tournée En tant qu’Agent je veux gérer les tournés 2 3
des véhicules à fin de suivre les véhicules.

11 Gérer chemin En tant qu’Agent je veux gérer les chemins à 2 2


fin de facilite le calcul de plus court chemin.

12 Se notifier de En tant que citoyen je veux me notifier de 2 8


l’arrivé de l’arrivé de véhicule municipal pour
véhicule connaitre ses horaires précises.
municipal
13 Gérer produit En tant qu’Agent je veux gérer les 2 4
recyclable produits recyclables à fin de les vendre au
sociétés de recyclages.
14 Commander un En tant que société de recyclage je veux 2 4
produit recyclable commander un tel produit recyclable à
travers la municipalité pour l’exploiter avec
un bas prix.
15 Gérer des En tant qu’Agent je veux gérer les 2 4
commandes de commandes de produit recyclable pour
produit recyclable assurer son recyclage et son réutilisation.
16 Suivre En tant que société de recyclage je veux 2 3
commande suivre mes commandes de produits
recyclables .

17 Réclamer une En tant que citoyen je peux réclamer une 3 5


faille telle faille pour réduire la détérioration de
l’infrastructure
18 Gérer réclamations En tant qu’Agent je veux gérer les 3 5
réclamations pour résoudre les problèmes
existantes.
19 Publier En tant que citoyen je veux publier mes 3 2

17
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________
propositions propositions pour améliorer la ville et la
moderniser.
20 Gérer sondages En tant qu’agent je veux gérer les sondages 3 3
pour mieux évaluer les avis des clients.
21 Voter un En tant que citoyen 3 4
sondage Je veux voter des sondages pour être actif
et impliqué dans la société.
22 Gérer En tant qu’Agent je veux gérer les 3 4
événements événements pour informer les citoyens des
évènements pour qu’ils participent.
23 Consulter En tant que citoyen je veux consulter la 3 2
événements liste des événements pour être impliqué
dans la société.
24 Configurer des En tant qu’Admin je veux configurer les 3 5
statistiques statistiques pour mieux évaluer le bon
déroulement de l’application.

7. L’organigrammes des taches

Figure 6: L'organigramme des taches:

18
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

8. Livrables de projet
Figure 7: Livrable de projet

Phase Livrable Responsable

Etude des besoins Analyse te spécification des Soltani Wissal


besoins

Analyse et conception Diagrammes UML Soltani Wissal

Code et tests Application Web Mobile Soltani Wissal

Retenu de rapport Rapport du projet Soltani Wissal

19
Chapitre2 : Analyse et spécification des besoins Wissal SOLTANII
__________________________________________________________________________________

9. Risque de projet
Tableau 7: Risque de projet

Les risques Type Impact sur le projet Actions correctives

Performance de mon Risque non Retard de livraison Changement de pc.


pc par rapport à bloquant
l’environnement.

Les applications Risque non absence d’une Essayer de choisir une autre
payantes (Par bloquant fonctionnalité source
exemple : services de
Google distance)

Absence de stage Risque non Retard de livraison Visiter les sites de formation.
bloquant

Environnement de la Risque non Retard de livraison L’utilisation d’une plate-


maladie Corona bloquant forme d’apprentissage.

10.Conclusion
Alors que à la fin de ce chapitre nous avons bien montré les besoins du client, on a
passé aux besoins fonctionnels et non fonctionnels puis les livrables et les risques qui peut
empêcher le bon déroulement de notre projet.

20
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________
Chapitre 3

Chapitre 3: Démarche du projet

1. Introduction
Dans ce chapitre nous voulons décrire le choix de la méthode de gestion de projet
(Agile : scrum) puis le principe de cette démarche, par suite la planification des sprints
et en termine avec l’organisation du projet.

2. Le choix de la méthode de gestion de projet


La gestion du projet nécessite une méthodologie de travail bien précise pour bien
spécifier la démarche, les étapes à suivre pour réaliser le bon déroulement du projet.

2.1 Comparaison entre les méthodes agiles et les méthode


classiques
Pour bien choisir la méthode de gestion de projet convenable, nous avons effectué une
étude comparative entre les méthodes classiques et les méthodes agiles qui sont
présentés dans le tableau suivant :

21
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________
Tableau 8: Comparaison entre l'approche classique et l'approche agile

Thème L’approche L’approche agile


traditionnelle

Cycle de -En cascade ou en V. -Itératif.


vie -Sans rétroaction possible. -Incrémental.

Contrôle -En fin de cycle. -Permanent et précoce.


de Qualité -L’utilisateur découvre le -L’utilisateur visualise le
pro- duit fini. pro- duit tôt et fréquemment.

Equipe Equipe dirigée par un Equipe responsabilisé ou


chef de projet. l’initiative et la
communication sont
privilégiés sou- tenue par
un chef de projet.

Changeme Processus lourds de Accueil favorable au


nt gestion de changement.
changements acceptés.

Mesure de Respect des La satisfaction de client


succès engagements initiaux par la livraison de valeur
en termes de coût, de ajouté. [7]
budget et de niveau de
qualité.

2.2 Comparaison des méthodes agiles


Une fois que nous décidons d’adopter une gestion de développement Agile, il
reste encore à choisir la méthode convenable à notre projet. En effet, nous présentons
une analyse comparative de différentes méthodes agiles dans le tableau Suivant :

« Les méthodes agiles sont des méthodologies essentiellement dédiées à la


gestion de projets informatiques. Elles reposent sur des cycles de développement
itératifs et adaptatifs en fonction des besoins évolutifs du produit. [8]

22
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

Elles permettent notamment d’impliquer l’ensemble des collaborateurs ainsi


que l’utilisateur dans le développement du projet. Ces méthodes permettent
généralement de mieux répondre aux attentes du produit en un temps limité (en partie
grâce à l’implication de celui –ci) tout en faisant monter les collaborateurs en
compétences. Ces méthodes constituent donc un gain en productivité ainsi qu’un
avantage compétitif tant du côté utilisateur que du côté du fournisseur. » (Presse
2015).

Les valeurs fondamentales des méthodes agiles sont :

Personnes et interactions plutôt que processus et outil : la


communication est une notion fondamentale ;
Logiciel fonctionnel plutôt que documentation complète ;
Collaboration avec l’utilisateur plutôt que négociation de contrat ;
Réagir au changement plutôt que suivre un plan : la planification
initiale et la structure du logiciel doivent être flexibles afin de permettre
l’évolution de la demande de l’utilisateur tout au long du projet ;

Les méthodes agiles les plus connues sont :

Extrême Programming (XP)


Two Tracks Unified Process (2 TUP)
Scrum

23
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________
Tableau 9: Comparaison entre les méthodes agiles

Description Points forts Points faibles

S’inscrit autour de -Définit les profils des -Superficiel sur les


l’architecture. intervenants : les phases situées en amont
Two Tracks -Proposer un cycle de prototypes, les livrables, et en aval du
Unified développement en Y. les plannings. développement.
Process -Cible de projet de toutes -Reserve une large place -Ne propose pas des
(2 TUP) tailles. pour la technologie et la documents type.
gestion des risques.
-Itératif.

Processus de -Refactoring : Devoir « -Focalisation sur


Extrême développement complet. faire la conception du l’aspect individuel du
Programming -Premier bouts de code système en continue pour développement.
(XP) délivrés deux à trois améliorer sa performance -La documentation
semaines du démarrage. et sa capacité de réponse ayant moins
-L’utilisateur fait partie de aux changements. d’importance. »
l’équipe.
-Développement itératif
au maximum.

-Sert à développer des Livrer fréquemment une -Faible documentation


Scrum offices, généralement en application qui et donc face à
quelques mois. fonctionne. détourner.
-Une vision est officiée -Besoins évolutifs -L’évolution des
Par une série d’itération -Satisfaire l’utilisateur en besoins amène les
d’un pois appelés des livrant tôt et utilisateurs à exiger de
sprints. régulièrement des plus en plus de
logiciels utiles, qui fonctionnalités.
offrent une véritable -Les propriétaires du
valeur ajoutée. office perdant le
contrôle sur le sujet.

2.3 Justification de choix de la méthode Scrum


 D’après le tableau comparatif ci-dessus, nous observons que parmi les méthodes
agiles, nous citons scrum que nous avons choisi pour les raisons suivantes :

24
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

 Entièrement développée et testée pour de courtes itérations ;

 Amélioration de la productivité ;

 Simplicité du processus ;

 Transparence sur l'avancement ;

 Résultat conforme aux attentes ;

 Pilotage au quotidien ;

 Amélioration de la communication ;

3. Description des éléments de base de Scrum


3.1 Principe de Scrum
Il existe 3 grands principes de Scrum qui sont :

➢ L’équipe :

• Composée des développeurs (dont un scrum master) et du propriétaire (Product


Owner) ;

• Elle est responsable du développement.

➢ Des itérations :

• L’équipe livre périodiquement les versions du logiciel ;

• La progression du projet est calculée sur les itérations.

➢ Basée sur le temps :

• Les itérations sont bornées dans le temps ;

• Toutes les réunions sont bornées dans le temps ;

• Le cout est borné dans le temps.

 La figure 8 illustre à la fois les différents rôles de Scrum que nous venons d'exhiber
et le déroulement du processus :

25
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

Figure 8: Méthode Scrum

3.2 Description des éléments de base de Scrum


Scrum est considéré comme un cadre ou « Framework » de gestion de projet. Ce cadre
est constitué d’une définition des rôles, il s’articule autour des trois rôles qui sont
principalement les suivants

 Product Owner :

Il représente à la fois le client et les utilisateurs. C’est donc lui qui définit les attentes
et les besoins du projet. Ainsi, il définit les tâches permettant de répondre à ces besoins
et il mettra en place leur priorisation.

 Scrum Master :

Le Scrum Master assure globalement le bon déroulement des programmes et protège


l’équipe de tout problème extérieur. Il assure également l’organisation des réunions et
la bonne application de la méthode agile.

 Equipe ou Team Membres :


Ce sont les personnes chargées de la réalisation du Sprint. Elle est composée des
professionnels et caractérisée par une forte coopération et une haute

26
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

communication entre les différents membres. Dans notre cas, les rôles sont répartis
comme suit :
 Product Owner: Mr. Nabil KHEMIRI
 Scrum Master: Mr. Nabil KHEMIRI
 Equipe ou Team Membres : Mlle. Wissal SOLTANI

3.4 Présentation des évènements de Scrum


 Sprint :

Le cœur de Scrum est le Sprint, qui a une boîte de temps (time-box), une durée, d'un
mois ou moins au cours de laquelle un Incrément Produit « Fini » fonctionnel et
potentiellement publiable est créé. Les sprints ont une durée cohérente durant la phase
de développement. Un nouveau Sprint commence immédiatement après la conclusion
du Sprint précédent.

 Sprint Planning :

Le travail à effectuer durant un Sprint est défini durant la réunion de Planification du


Sprint (Sprint Planning). Ce plan est créé de manière collaborative par tous les
membres de l'équipe Scrum.

 Daily Meeting :
La mêlée quotidienne (Daily Scrum) est un événement de 15 minutes (time-boxé)
destiné à l'équipe de développement. La mêlée quotidienne est tenue tous les jours du
Sprint. L’équipe de développement planifie le travail pour les prochaines 24 heures.
 Sprint Review :
Une revue de Sprint (Sprint Review) est tenue à la fin du Sprint pour inspecter
l’incrément réalisé et adapter le Backlog Produit si nécessaire. Pendant la revue de
Sprint, l'équipe Scrum et les parties prenantes échangent sur ce qui a été fait durant le
Sprint. La Revue de sprint comprend les éléments suivants :
 Les participants incluent l'équipe Scrum et les principales parties prenantes
invitées par le Product Owner ;
 Le Product Owner indique quels éléments du Backlog Produit ont été « Finis »
et ceux qui n'ont pas été « Finis » ;

27
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

 L’équipe de développement discute de ce qui s’est bien passé pendant le


Sprint, quels problèmes ont été rencontrés, et comment ces problèmes ont été
résolus ;
 L'équipe de développement démontre le travail « Fini » et répond aux
questions sur l'incrément ;
 Le Product Owner discute de l’état actuel du Backlog Produit tel qu'il est. Il ou
elle projette les dates prévisionnelles et celles de livraison en fonction des
progressions réalisées à ce jour (si nécessaire) [9].
 Sprint Rétrospective :

La rétrospective de Sprint (Sprint Rétrospective) est une opportunité pour l'équipe


Scrum de s’auto-inspecter et de créer un plan d'améliorations à adopter au cours
du prochain Sprint.

Présentation des artefacts de Scrum


 Backlog du produit :
 Tout le travail est encadré par le Backlog. En effet, tout le projet est découpé en
un ensemble de "User Stories" classés par priorité et listés dans le Backlog.
 Backlog du sprint :
 Une sélection de tâches retenues du "Backlog du produit" pour construire
l'objectif du sprint. Incrément :
 L'incrément est constitué des éléments du Backlog produit « Finis » pendant
le sprint ainsi que de la valeur cumulative des incréments livrés dans les
sprints précédents.

4. Gestion de projet
4.1 Planification
Le but étant d’organiser le travail de manière structuré, le projet a été découpé
en tâches afin d’assurer son bon déroulement. Tout d’abord, nous avons effectué une
formation sur le SCRUM, Puis nous avons divisé notre travail en trois releases. La
première et la deuxième release comporte chacune deux sprints et la dernière release
comporte un sprint. Après la planification et l’élaboration du cahier des charges, nous
avons consacré d'implémenter en premier ce qui a le plus de valeur.

28
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

Le travail sera planifié selon des sprints que nous avons définis et nous avons consacré
trois semaines pour chaque sprint.

4.2 Diagramme de Gant

Figure 9: Diagramme de Gant

4.3 Equipe de réalisation du projet


Tableau 10: Equipe de réalisation de projet:

Nom et Prénom Fonction/Rôle dans le projet

Mme. Soltani Wissal concepteur et développeur


Mr. Khemiri Nabil Encadrant/Scrum Master
Mr. Khemiri Nabil Encadrant/ Product Owner

Présentation des acteurs scrum dans la mission :

 Concepteur/Développeur :
• Elaborer le dossier de gestion de projet.
• Réaliser la spécification détaillée.
• développer l’application.
• Effectuer des tests unitaires.
 Scrum Master :

• Valider le dossier des spécifications fonctionnelles.


• Valider le codage.

29
Chapitre 3 : Démarche du projet Wissal SOLTANII
__________________________________________________________________________________

• Valider les livrables.


• Contrôler le respect des demandes.
 Product Owner :
• Présenter les besoins du projet.
• Communiquer une vision claire du produit et défini ses caractéristiques.
• Accepter ou rejette le produit à la fin de chaque Sprint.
• S’assurer que l’équipe se concentre sur les items du Backlog de plus forte valeur
ajoutée.
• Rendre compte de l’acceptation des livrables.

5. Conclusion
A travers ce chapitre, on a organisé notre projet toute en utilisant le choix de sa
démarche qui est la méthode SCRUM et en faisant un planning bien détaillé avec la
définition d’équipe de projet, alors que dans le chapitre suivant, nous essayons de
présenter l’architecture de la solution, la conception détaillée ainsi que l’environnement
du travail.

30
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________
Chapitre 4

Chapitre 4 : Cartographie et architecture du


projet

1. Introduction
Dans ce chapitre, nous avons décidés de faire 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.

2. Carte d’identité de projet

Figure 10: Carte d'identité de projet

31
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

3. Architecture de la solution
Afin de mieux comprendre le fonctionnement des applications web, quelques
notions logique et logicielle sont nécessaires.

3.1 Architecture logique


L’architecture adaptée pour la réalisation de notre solution est une architecture
3-tiers. Une architecture à trois niveaux ou une architecture trois tiers ajoute un niveau
supplémentaire à l'architecture à 2 niveaux, permettant de spécialiser les serveurs dans
une tâche précise, ce qui donne un avantage de flexibilité, de sécurité et de
performance :

 Un utilisateur qui demande une ressource via une interface utilisateur


(généralement un navigateur web) chargée de la présentation de la ressource.
 Un serveur d'application (appelé middleware) qui fournit la ressource, mais
en faisant appel aux ressources d'un autre serveur.
 Un serveur de données qui fournit au serveur d'application les ressources
requises pour répondre au utilisateur. [10]

Figure 11: Architecture logique

32
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

3.2 Architecture logicielle


Modèle-vue-contrôleur ou MVC est un « design pattern » qui a tendance à
multiplier le nombre de classes à définir et semble alourdir la conception d’application
mais le découplage ainsi obtenu assure une maintenance facilitée.

Programmer en utilisant MVC nous aide à comprendre le système, bien


organiser le développement et il favorise la réutilisation (par la normalisation, la
standardisation des composants logiciels). MVC sépare l’application en 3 parties
principales :

 Un modèle (Model) : représente le cœur (algorithmique) de l’application :


traitement des données, interaction avec la base de données, etc. Il décrit les
données manipulées par l’application. Il regroupe la gestion de ces données et
responsable de leur intégrité. La base de données sera l’un de ces composants.
 Une vue (View) : traite ce qu’on voit à l’écran dans le navigateur web. Il s’agira
globalement de code HTML et de ccs. Le but de la vue est de présenter les données
issues du modèle mais sans les modifier, sans interpréter le contenu ;
 Un contrôleur (Controller) : prend en charge la gestion des événements de
synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit
tout l’événement de la vue et enclenche les actions à effectuer. [11]

Figure 12: Le modèle MVC

33
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

4. Conception détaillée
4. 1 Diagramme de package

Figure 13: Diagramme de paquetage globale

34
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

4.2 Diagramme de déploiement

Figure 14: Diagramme de déploiement

35
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

4.3 Diagramme de composant

Figure 15: Diagramme de composant

5. Environnement du travail
5.1 Environnement matériel
Pour la réalisation de notre projet nous avons disposé d’un ordinateur LENOVO
ide pad 320 caractérisé par :

 Processeur : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz 1.80 GHz


 Mémoire : 12 Go de RAM
 Système d’exploitation : Windows10
 Type de système : Système d’exploitation 64 bits, processeur*64

36
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

5.2 Envirement logiciel


Tableau 11: Environnement logiciel

Thème Nom et Logo Version Description


Est un outil d'organisation collaboratif simple et gratuit.
Trello est un outil collaboratif qui organise tous vos projets
en une série de listes partagées. D'un seul coup il Trello
vous renseignera sur tous vos projets, sur leur état
d'avancement et vous dira qui travaille sur quoi dans votre
Trello
équipe. [12]
Figure 16: Logo
Trello

Draw.io : Draw.io pro est une application création de


diagrammes compatible avec Google Drive (TM) et
entièrement gratuite vous permettant de dessiner des
Gestion de organigrammes, des diagrammes UML, des, des
Figure 17: Logo diagrammes ERD, des schémas réseaux, Business Process
projet
draw.io
Models, Org Charts, des circuits électroniques. [13]

Est un logiciel libre de gestion de projet écrit en Java, ce qui


permet de l'utiliser sur divers systèmes
d'exploitation (Windows, Linux, MacOs). Il permet d'éditer
un diagramme de Gantt qui organise le projet selon des
dates fixées.[14]
Gant Project
Figure 18: Logo
Gant Project

Est un logiciel de modélisation UML (Unified Modeling


Language) open source qui peut remplacer dans bien des
situations des logiciels commerciaux et coûteux comme
Rational Rose. Étant simple d’utilisation, nécessitant peu de
5.0.2 ressources système, supportant UML 2, ce logiciel constitue
une excellente option pour une familiarisation à la
StarUML
Conception modélisation. Cependant, seule une version Windows est
Figure 19: Logo
StarUML disponible. [15]

Est un éditeur de texte très léger, très puissant et libre


(licence GPL). Il est parfait pour programmer avec des

37
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

langages ne nécessitant pas d'environnement de


développement (HTML, CSS, JavaScript, PHP…) ou en
7.8.4 ayant un peu pratique (Python, processing…), ou pour du
traitement de données. Il prend en charge par défaut une
Notepad++
cinquantaine de langages différents, et vous laisse libre d'en
Figure 20: Logo
Notepad++ ajouter d'autres.[16]

Est un logiciel libre de virtualisation publié par Oracle.


Virtual Box permet la création d’un ou de plusieurs
6.0.4 ordinateurs virtuels dans lesquels s’installent d’autres
systèmes d’exploitation.
Il fonctionne sous Windows mais aussi sur Mac, Linux.
VirtualBox
Programmat [17]
Figure 21: Logo
ion VirtualBox

Web
Vagrant est un outil en ligne de commande pour créer et
configurer des machines virtuelles. Il encapsule un logiciel
de virtualisation (tel que VirtualBox ou VMware) et un
2.2.3 logiciel de gestion de configuration. [18]

Vagrant
Figure 22: Logo
Vagrant

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
2.20.1 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
Git
de douze millions de personnes.[19]
Figure 23: Logo
Git
Est un environnement de développement pour développer
Programmat des applications mobiles Android. Il est basé sur IntelliJ
ion IDEA et utilise le moteur de production Gradle. Il peut être
mobile 3.4.1 téléchargé sous les systèmes d'exploitation Windows,
Android
MacOs, Chrome OS et Linux. [20]
studio
Figure 24: Logo
Android studio

38
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

Est un logiciel de gestion et d'administration de bases de


données MySQL créé en 2004. Via une interface
graphique intuitive, il permet, entre autres, de créer,
8.0.15 modifier ou supprimer des tables, des comptes utilisateurs,
et d'effectuer toutes les opérations inhérentes à la gestion
MySQL
d'une base de données. Pour ce faire, il doit être connecté à
Workbench
Base de un serveur MySQL. [21]
Figure 25: Logo
données MySQL
Workbench
Est un ensemble de logiciels permettant de mettre en place
facilement un serveur Web et un serveur FTP.
Il s’agit d’une distribution de logiciels libres (X Apache
7.4.16 MySQL Perl PHP) offrant une bonne souplesse
d’utilisation, réputée pour son installation simple et rapide.
Xampp Cette « distribution » se chargera donc d’installer
Figure 26: Logo
Xampp l’ensemble des outils dont vous pourriez avoir besoin lors
de la création d’un site Web. [22]

5.3 Langages de programmations


Tableau 12: Langages de programmations

thème Nom et logo version description

Est un langage de programmation libre, principalement


utilisé pour produire des pages Web dynamiques via un
serveur HTTP4, mais pouvant également fonctionner
7 comme n'importe quel langage interprété de façon
locale. PHP 7est un langage impératif orienté objet.[23]
PHP
Figure 27: Logo
PHP

Est un langage informatique utilisé sur l'internet. Ce


langage est utilisé pour créer des pages web.
L'acronyme signifie HyperText Markup Language, ce
5 qui signifie en français "langage de balisage
d'hypertexte". Cette signification porte bien son nom
HTML
puisqu'effectivement ce langage permet de réaliser de
Figure 28: Logo
HTML5

39
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

l'hypertexte à base d'une structure de balisage. [24]

Est l'acronyme anglais de Cascading Style Sheets


(CSS) qui peut se traduire par "feuilles de style en
3 cascade". Le CSS est un langage informatique utilisé
sur l'internet pour mettre en forme les fichiers HTML
ou XML. Ainsi, les feuilles de style, aussi appelé les
CSS3
fichiers CSS, comprennent du code qui permet de gérer
Figure 29: Logo
CSS3 le design d'une page en hu HTML. [25]

Est un langage de programmation dynamique complet


qui, appliqué à un document HTML, peut fournir une
interactivité dynamique sur les sites Web. Il a été
inventé par Brendan Eich, co-fondateur du projet
Mozilla, de la Mozilla Fondation et de la Mozilla
JavaScript
Corporation[26]
Figure 30: Logo
JavaScript
Est une bibliothèque JavaScript gratuite, libre et
multiplateforme. Compatible avec l'ensemble des
navigateurs Web (Internet Explorer, Safari, Chrome,
Firefox, etc.), elle a été conçue et développée en 2006
web
pour faciliter l'écriture de scripts. Il s'agit du
Framework JavaScript le plus connu et le plus utilisé. Il
JQuery
permet d'agir sur les codes HTML, CSS, JavaScript et
Figure 31: Logo
JQuery AJAX et s'exécute essentiellement côté utilisateur. [27]

mobile Est le langage Android le plus utilisé dans le


développement mobile. L’un de ses plus grands
avantages est que les logiciels créés avec ce langage
peuvent être facilement installés et exécutés sur
différents systèmes d’exploitation, que ce soit
Windows, Mac OS, Linux ou autre. Avec un petit coup
de main de Google, qui vous fournit l’environnement
Java
de développement Android Studio, vous pourrez créer
Figure 32: Logo
Java une application Android bien plus complexe. [28]

40
Chapitre 4 : Cartographie et architecture du projet Wissal SOLTANII
__________________________________________________________________________________

Lors du développement de vos applications avec


Android Studio, vous tomberez très probablement sur
des bouts de code écrits en XML. Ce langage de
balisage est utilisé pour gérer l’affichage des contenus
XML
sur l’écran. Il n’est pas indispensable pour créer une
Figure 33: Logo
XML application Android, mais il facilite le développement
en permettant de séparer l’affichage des algorithmes.
Avec XML, on gagne du temps et on simplifie le code
de l’application, ce qui permet d’éviter des erreurs. [29]

6. Conclusion
Dans ce chapitre nous avons procéder à l’initialisation du projet et la mise en place de
l’environnement 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.

41
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Chapitre 5

Chapitre 5 : Mise en œuvre du release 1

1. Introduction
Dans ce chapitre, nous présentons la réalisation du premier release, en
organisant le travail sur trois phases principales qui sont l’analyse, la conception, et la
réalisation.

2. Sprint 1
2.1 Backlog du sprint 1
Tableau 13: Backlog du sprint 1

ID Feature USER STORY Priorité STORY


POINT(jr
)

1 S’inscrire En tant que citoyen à je veux m’inscrire 1 3


pour bénéficier par les services offerts
par l’application.
2 S’authentifier En tant qu’utilisateur je veux 1 3
m’authentifier afin que l’application
doive être plus sécurisée.

3 Gérer En tant qu’admin je veux gérer les 1 6


utilisateur utilisateurs pour contrôler le bon
comportement de ses derniers et en cas
d’une fausse action je peux bloquer
l’utilisateur et dans des cas pires peut le
supprimer.
4 Mise à jour En tant qu’utilisateur je jeux mise à jour 1 3
profil mon profile.

42
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.2 Tableau des taches

Figure 34: tableau des taches du Sprint 1

2.3 Analyse
2.3.1 Identification des acteurs et des cas d’utilisation

Figure 35: Diagramme de cas d'utilisation du Sprint 1

43
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « s’inscrire »

Figure 36: Diagramme de cas d'utilisation "S'inscrire"

Tableau 14: Description de cas d'utilisation "S'inscrire"

Acteur Citoyen/Société de recyclage

Objectif Le Citoyen/Société de recyclage remplit le formulaire d’inscription


pour effectuer son inscription.

Pré-condition(s) L’application doit être lancer.

Post-condition(s) Le citoyen/société de recyclage avoir un compte et peux accéder à


son espace personnel.

Scénario-Nominal 1. Le citoyen/société de recyclage demande la page


d’inscription.
2. Le système lui affiche la page demandée.
3. Le citoyen/société de recyclage remplit le formulaire
d’inscription.
4. Le système vérifie les données saisies.
5. Le système ajoute Le citoyen/société de recyclage dans la
base de données.
6. Le système affiche le message de succès.

4. a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

5. a/ erreur : email déjà existe

44
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Description du cas d’utilisation « s’authentifier »

Figure 37: Diagramme de cas d'utilisation "S'authentifier"

Tableau 15: Description de cas d'utilisation "S'authentifier"

Acteur L’utilisateur

Objectif Lors de l’accès au site, l’utilisateur doit s’authentifier pour accéder aux
différentes fonctionnalités du site.

Préconditions(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 1. L’utilisateur remplit le formulaire


2. Le système vérifie les champs
3. Le système exécute les requêtes de connexion.
4. La base de donnée collecte les données
5. La base de donnée renvoi des résultats.
6. Le système redirige l’utilisateur vers espace privé.

3. a /Le système renvoie un message d’erreur


Scénario(s) alternatif(s)
6. a / Le système renvoie un message d’erreur
et d’exception :

45
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Description du cas d’utilisation « Bloquer utilisateur »

Figure 38: Diagramme de cas d'utilisation "Bloquer utilisateur"

Tableau 16: Description de cas d'utilisation "Bloquer utilisateur"

Nom du cas Bloquer utilisateur

Acteur -Administrateur

Objectif - Bloquer utilisateur

Pré condition - La liste des utilisateurs est affichée Il y a au moins un utilisateur


dans la base de données.

Post condition(s) - utilisateur est bloqué.

Scenario Nominal 1- l’admin clique sur le bouton « Bloquer ».


2- Le système demande la confirmation du blocage.
3- l’admin confirme le blocage
4- Le système bloque l’utilisateur et affiche la liste des utilisateurs
avec MAJ.

Scénario(s) alternatif 3-1-l’administrateur annule le blocage.

Remarque : le tableau descriptif de sous cas d’utilisation « débloquer


utilisateur » a le même concept que « bloquer utilisateur ».
• Description du cas d’utilisation « Mise à jour profil »

Figure 39: Diagramme de cas d'utilisation "Mise à jour profil"

46
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 17: Description de cas d'utilisation "Mise à jour profil"

Acteur Utilisateur

Objectif Modifier les données de profil.

Pré condition Le système doit être lancé

L’utilisateur a un profil, il accède à son espace privée.

Post condition Mise à jour avec succès.

Scénario nominal 1. L’utilisateur demande l’accès à son profil.


2. Le système affiche le formulaire.
3. L’utilisateur saisi ses nouvelles informations.
4. Le système vérifie les données saisies.
5. Le système fait la mise à jour.

Scénario alternatif 4.a/ Le système affiche un message d’erreur.

2.4 Conception
2.4.1 Conception statique du sprint
 Diagramme de classe

Figure 40: Diagramme de classe du Sprint 1

 Dictionnaire de donné : table « utilisateur »

47
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 18: Dictionnaire de donné de la table "Utilisateur"
Nom de la colonne Signification Type de données

id L’identifiant unique de l’utilisateur INT


nom Nom de l’utilisateur TEXT
adresse Adresse de l’utilisateur TEXT
login Pseudo de l’utilisateur VARCHAR(20)
password Mot de passe de l’utilisateur TEXT
email Email de l’utilisateur TEXT
tel Numéro de téléphone de l’utilisateur INT
code_postal Code postal de l’utilisateur TEXT
profil Profil de l’utilisateur INT
permissions Permissions de l’utilisateur INT
photo Photo de l’utilisateur TEXT
etat L’état de l’utilisateur INT
date_ins Date d’insertion de l’utilisateur TEXT

 Dictionnaire de donné : table « citoyen »

Tableau 19: Dictionnaire de donné de la table "Citoyen"

Nom de la colonne Signification Type de données

iduser Clé étranger de la table utilisateur INT


prenom Prénom de citoyen INT
Profession Profession de citoyen TEXT

 Dictionnaire de donné : table « société de recyclage »

Tableau 20: Dictionnaire de donné de la table "Société de recyclage"

Nom de la colonne Signification Type de données

iduser Clé étranger de la table utilisateur INT


Immatriculation Immatriculation de société de recyclage TEXT
mf Matricule fiscale de société de recyclage TEXT
domaine Le domaine précise de société de recyclage TEXT

48
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Dictionnaire de donné : table « agent »

Tableau 21: Dictionnaire de donné de la table "Agent"

Nom de la colonne Signification Type de données

iduser Clé étranger de la table utilisateur INT


prenom Prénom de l’agent INT
fonction fonction de l’agent dans la municipalité TEXT
grade grade de l’agent dans la municipalité TEXT

2.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 41: Diagramme de package du Sprint 1

49
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagramme de séquences

Figure 42: Diagramme de séquence "S'inscrire"

Figure 43: Diagramme de séquence "S'authentifier"

50
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 44: Diagramme de séquence "Bloquer utilisateur"

Figure 45: Diagramme de séquence "Mise à jour profil"

51
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagramme d’activité

Figure 46: Diagramme d'activité "S'inscrire"

Figure 47: Diagramme d'activité "S'authentifier"

52
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.5 Réalisation

Figure 48: Interface" Authentification" version mobile

Figure 49: Interface "Authentification" version web

53
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 50:Interface "Inscription" version web

Figure 51: Interface "Inscription" version mobile

54
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 52: Interface "Gérer utilisateur"

2.6 Test et validation


Tableau 22: Test et validation

Cas de test Démarche de test Compartiment attendu Résultat

S’inscrire Le client de l’application Message d’erreur s’il y’a une Conforme


va remplir un formulaire information obligatoire
d’inscription. manquante
S’authentifier Le client de l’application L’espace personnel est affiché. Conforme
va remplir un formulaire
d’authentification.
Ajouter L’administrateur remplie Message d’erreur s’il y’a une Conforme
utilisateur un formulaire d’ajout. information obligatoire
manquante
Modifier L’administrateur modifie Message d’erreur s’il y’a une Conforme
utilisateur l’information. information obligatoire
manquante
Supprimer L’administrateur demande Message de confirmation affiché Conforme
utilisateur la suppression.

Bloquer L’administrateur bloque Message de confirmation affiché Conforme


utilisateur un utilisateur

55
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Débloquer L’administrateur Message de confirmation affiché Conforme


Utilisateur débloque un utilisateur

Rechercher L’administrateur lance Résultat de recherche est affiché. Conforme


utilisateur une recherche rapide à
partir de mots-clés
Mise à jour L’utilisateur rempli à Message d’erreur s’il y’a une Conforme
profil nouveau le information obligatoire
Formulaire afin de mettre manquante.
à jour son
profil

2.7 Sprint review

7
6 6
5 5 5 4
4
3 3
2 2
1
0

evaluation de temps et fonctionnalitées evaluation de temps/quantité de travail

Figure 53: Sprint Burn-down chart

56
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3. Sprint 2
3.1 Backlog du sprint 2
Tableau 23: Backlog de Sprint 2

ID Feature USER STORY Priori STORY


té POINT(jr
)

5 Gérer En tant qu’Agent je veux gérer les véhicules 1 5


véhicule pour mieux suivre leurs déroulements.

6 Gérer cité En tant qu’Agent à je veux gérer les cités à 1 5


fin d’arriver à notifier chaque citoyen de
l’arrivé de véhicule concernant le cité qu’il
appartient.

7 Gérer rue En tant qu’Agent à je veux gérer les rues à 1 3


fin de facilite le calcul de plus court chemin.

8 Gérer En tant qu’Agent à je veux gérer les ronds-points 1 2


rond-point à fin de facilite le calcul de plus court chemin.

3.2 Tableau des taches

Figure 54: Tableau des taches de Sprint 2

57
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.3 Analyse
3.3.1 Identification des acteurs et des cas d’utilisation

Figure 55: Diagramme de cas d'utilisation de Sprint 2

3.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « Supprimer véhicule »

Figure 56: Diagramme de cas d'utilisation "Supprimer véhicule"

58
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 24: Description du cas d’utilisation « Supprimer véhicule »

Acteur L’Agent municipal

Objectif L’Agent municipal supprime un véhicule

Pré-condition(s) - L’Agent municipal doit être authentifié.


- L’Agent municipal doit accéder à la liste des véhicules.

Post-condition(s) véhicule supprimé avec succès

Scénario-Nominal 1. L’Agent municipal sélectionner un véhicule.


2. L’Agent municipal demande de supprimer le véhicule sélectionné.
3. Le système demande une confirmation de suppression.
4. L’Agent municipal confirme la suppression de véhicule.
5. Le système supprime véhicule de la base de données.

4. a/ L’Agent municipal annule la suppression de véhicule.


Scénario(s)
alternatif(s)

• Description du cas d’utilisation « Rechercher cité »

Figure 57: Diagramme de cas d'utilisation "Rechercher cité"

59
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 25: Description du cas d’utilisation «Rechercher cité»

Nom du cas Rechercher cité

Acteur -Agent
Objectif - Rechercher une cité
Pré condition - L’agent doit être authentifié.
Post condition(s) - L’agent a trouvé la cité précise qu’il cherchait
Scenario Nominal 1. L’agent clique lance une recherche rapide à partir de mots-clés
2. Le système Le système affiche une page de résultat.
3. Le Système lui présente les données concernant cette cité
Scénario(s) alternatif 2-a- le système n’affiche aucune cité.

• Description du cas d’utilisation « Modifier rue »

Figure 58: Diagramme de cas d'utilisation "Modifier rue"

60
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 26: Description du cas d’utilisation «Modifier rue»

Acteur L’agent municipal

Objectif L’agent municipal modifie une rue.

Pré-condition(s) - L’agent municipal doit être authentifié.


- L’agent municipal doit accéder à la liste des rues

Post-condition(s) Rue est modifiée avec succès

Scénario-Nominal 1. L’agent municipal choisi la rue à modifier.


2. Le système affiche formulaire contenant les anciennes
données.
3. L’agent municipal modifie les informations.
4. L’agent municipal valide la saisie.
5. Le système vérifie les données.
6. Le système enregistre les données.
7. Modification avec sucées

5. a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

3.4 Conception
3.4.1 Conception statique du sprint
 Diagramme de classe

Figure 59: Diagramme de classe de Sprint 2

61
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Dictionnaire de donné : table « véhicule »

Tableau 27 : Dictionnaire de donné de la table « véhicule »

Nom de la colonne Signification Type de données

id L’identifiant unique de véhicule municipal INT


matricule Matricule de véhicule municipal INT
vitesse La vitesse de véhicule municipal INT
modele Le modèle de véhicule municipal TEXT

longitude Longitude de véhicule municipal TEXT

latitude latitude de véhicule municipal TEXT

Date_ins La date d’insertion de véhicule municipal TEXT

• Dictionnaire de donné : table « cité »

Tableau 28: Dictionnaire de donné de la table « cité »

Nom de la colonne Signification Type de données

id L’identifiant unique de cité INT


nom Nom de cité INT
Date_ins La date d’insertion de cité TEXT

• Dictionnaire de donné : table « rond-point »

Tableau 29: Dictionnaire de donné de la table « rond-point »

Nom de la colonne Signification Type de données

id L’identifiant unique du rond-point INT


titre Le titre du rond-point TEXT
longitude Longitude du rond-point TEXT
latitude latitude du rond-point TEXT
Rue1,rue2,rue3 et Les rues du rond-point TEXT
rue4
Date_ins La date d’insertion de véhicule municipal TEXT

62
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Dictionnaire de donné : table « rue »

Tableau 30: Dictionnaire de donné : table « rue »

Nom de la colonne Signification Type de données

id L’identifiant unique de rue INT


nom Nom de rue INT
rue_deb Rue de début TEXT
rue_fin Rue de fin TEXT
Date_ins La date d’insertion de rue TEXT

3.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 60: Diagramme de package de Sprint 2

63
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagrammes de séquences

Figure 61: Diagramme de séquence "Supprimer véhicule"

Figure 62: Rechercher cité

64
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 63: Diagramme se séquence "Modifier rue"

 Diagramme d’activité

Figure 64: Diagramme d'activité "Ajouter véhicule"

65
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.5 Réalisation

Figure 65: Interface "Gérer cité"

3.6 Test et validation


Tableau 31: Test et validation

Cas de test Démarche de test Compartiment attendu Résultat

Rechercher cité L’agent lance une Résultat de recherche est Conforme


recherche rapide à partir affiché.
de mots-clés
Ajouter L’agent remplie un Message d’erreur s’il y’a Conforme
véhicule/cité/rue/ formulaire d’ajout. une information
rond-point obligatoire manquante

Modifier L’agent modifie Message d’erreur s’il y’a Conforme


cité/rue/rond-point l’information. une information
obligatoire manquante

Supprimer rue/ L’agent demande la Message de confirmation Conforme


véhicule suppression. affiché

66
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.7 Sprint review

Remarque : Sprint review : L’évaluation de temps sera par nombre


de jour.

Figure 66: Sprint Burn-down chart

4. Sprint 3
4.1 Backlog produit du sprint 3
Tableau 32: Backlog du sprint 3

ID Feature USER STORY Priorité STORY


POINT(jr
)

9 Gérer circuits En tant qu’Agent à je veux gérer les 2 2


circuits à fin de facilite le calcul de plus
court chemin.

10 Gérer En tant qu’Agent je veux gérer les 2 3


tournées tournés des véhicules à fin d’arriver de
notifier le citoyen de l’arrivé de véhicule.

11 Gérer En tant qu’Agent je veux gérer les 2 2


chemins chemins à fin de facilite le calcul de plus
court chemin.

12 Se notifier de En tant que citoyen je veux me notifier de 2 8


l’arrivé de l’arrivé de véhicule municipal pour connaitre
véhicule ses horaires précises.
municipal

67
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.2 Tableau des taches

Figure 67: Tableau des taches de Sprint 3

4.3 Analyse
4.3.1 Identification des acteurs et des cas d’utilisation

Figure 68: Diagramme de cas d'utilisation de Sprint 4

68
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « Modifier chemin »

Figure 69: Diagramme de cas d'utilisation «modifier chemin"

Tableau 33: Description des cas d'utilisation "modifier chemin"

Acteur L’agent municipal

Objectif L’agent municipal modifie un chemin.

Pré-condition(s) - L’agent municipal doit être authentifié.


- L’agent municipal doit accéder à la liste des chemins

Post-condition(s) chemin est modifiée avec succès

Scénario-Nominal 1. L’agent municipal choisi le chemin à modifier.


2. Le système affiche formulaire contenant les anciennes
données.
3. L’agent municipal modifie les informations.
4. L’agent municipal valide la saisie.
5. Le système vérifie les données.
6. Le système enregistre les données.
7. Modification avec sucées

5. a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

69
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Description du cas d’utilisation « Modifier chemin »

Figure 70: Diagramme de cas d'utilisation «supprimer chemin"

Tableau 34: Description de cas d'utilisation «supprimer chemin"

Acteur L’Agent municipal

Objectif L’Agent municipal supprime un chemin bien déterminé.

Pré-condition(s) - L’Agent municipal doit être authentifié.


- L’Agent municipal doit accéder à la liste des chemins.

Post-condition(s) chemin supprimé avec succès

Scénario-Nominal 1. L’Agent municipal sélectionner un chemin bien déterminé.


2. L’Agent municipal demande de supprimer le chemin sélectionné.
3. Le système demande une confirmation de suppression.
4. L’Agent municipal confirme la suppression de chemin.
5. Le système supprime chemin de la base de données

4. a/ L’Agent municipal annule la suppression de chemin.


Scénario(s)
alternatif(s)

70
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.4 Conception
4.4.1 Conception statique du sprint
 Diagramme de classe

Figure 71: Diagramme de classe de Sprint 3

71
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

•Dictionnaire de donné : table « circuit »

Tableau 35: Dictionnaire de donné de la table « circuit »

Nom de la colonne Signification Type de données

id L’identifiant unique de circuit INT


titre Titre de circuit INT
lieu_deb Lieu de début de circuit TEXT
lieu_fin Lieu de fin de circuit TEXT
Date_ins La date d’insertion de circuit TEXT

•Dictionnaire de donné : table « tournée »

Tableau 36: Dictionnaire de donné de la table « tournée »

Nom de la Signification Type de données


colonne
id L’identifiant unique de tournée de véhicule municipal INT
Date_deb La date de début de tournée de véhicule municipal INT
Date_fin La date de fin de tournée de véhicule municipal TEXT

•Dictionnaire de donné : table « rue_circuit »

Tableau 37: Dictionnaire de donné de la table « rue_circuit »

Nom de la Signification Type de données


colonne
id L’identifiant unique de chemin suivi par le véhicule municipal INT
chemin Le chemin suivi par le véhicule municipal INT
Date_ins La date d’insertion de chemin suivi par le véhicule municipal TEXT

72
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 72: Diagramme de package de Sprint 3

73
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagrammes de séquences

Figure 73: Diagramme de séquence «modifier chemin"

74
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 74: Description de cas d'utilisation "Supprimer chemin"

4.6 Réalisation

Figure 75: Interface "Gérer véhicule"

75
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 76: Interface "tournée véhicule"

4.7 Test et validation


Tableau 38: Test et validation

Cas de test Démarche de test Compartiment attendu Résultat

Ajouter chemin L’agent remplie un Message d’erreur s’il y’a Conforme


formulaire d’ajout. une information obligatoire
manquante
Modifier chemin L’agent modifie Message d’erreur s’il y’a Conforme
l’information. une information obligatoire
manquante.
Supprimer L’agent demande la Message de confirmation Conforme
chemin suppression. affiché

Se notifier de l’arrivé Le citoyen attend une Notification est bien reçue. Conforme
de véhicule notification de l’arrivée
de véhicule.
Lancer tournée Lancement du tournée Tournée est bien lancée Conforme
des véhicules
Arrêter tournée L’arrêt du tournée des Tournée est arrêtée Conforme
véhicules

76
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.6 Sprint Review

Figure 77: Sprint Burn-down chart

5. conclusion
Au cours de ce chapitre, nous avons présenté les trois premiers sprints. Pour ce faire,
nous avons passé par l’analyse, la conception. Dans le chapitre suivant nous entamons les
trois derniers sprints de release suivante.

77
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Chapitre 6

Chapitre 6 : Mise en œuvre du release 2

1. Introduction
Dans ce chapitre, nous présentons la réalisation du deuxième release, en
organisant le travail sur trois phases principales qui sont l’analyse, la conception, et la
réalisation.

2. Sprint 1
2.1 Backlog du sprint 1
Tableau 39: Backlog de Sprint 1

ID Feature USER STORY Priori STORY


té POINT

13 Gérer produit En tant qu’Agent je veux gérer les 2 4


recyclable produits recyclables à fin de les vendre au
sociétés de recyclages.

14 Commander un En tant que société de recyclage je veux 2 4


produit recyclable commander un tel produit recyclable à
travers la municipalité pour l’exploiter avec
un bas prix.

15 Gérer des En tant qu’Agent je veux gérer les 2 4


commandes commandes de produit recyclable pour
de produit assurer son recyclage et son réutilisation.
recyclable

16 Suivre En tant que société de recyclage je veux suivre 2 3


commande mes commandes de produits recyclables .

78
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.2 Tableau des taches

Figure 78: Tableau des taches de Sprint 1

2.3 Analyse
2.3.1 Identification des acteurs et des cas d’utilisation

Figure 79: Diagramme de cas d'utilisation de Sprint 1

79
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « Ajouter produit recyclable »

Figure 80: Diagramme de cas d'utilisation "Ajouter produit recyclable"

Tableau 40: Description de cas d'utilisation "Ajouter produit recyclable"

Acteur L’Agent municipal

Objectif L’Agent municipal ajoute un produit recyclable.

Pré-condition(s) - L’Agent municipal doit être authentifié.


- L’Agent municipal doit accéder à l’interface « Gérer produit ».
- L’Agent municipal choisit d’ajouter un produit recyclable.

Post-condition(s) Produit recyclable est ajouté avec succès.

Scénario-Nominal 1. L’Agent municipal rempli le formulaire d’ajout.


2. L’Agent municipal valide la saisie
3. Le système vérifie les champs.
4. Le système ajoute les données à la base de donnés.
5. Le système doit afficher message sucées.
6. Le système réaffiche la liste des produits recyclables.

3.a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

80
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Description du cas d’utilisation « Suivre commande produit recyclable »

Figure 81: Diagramme de cas d'utilisation "suivre commande produit recyclable"

Tableau 41: Description de cas d'utilisation "Suivre commande de produit recyclable":

Nom du cas Suivre commande produit recyclable

Objectif La société de recyclage doit suivre la liste des commandes de produit


recyclable.
Acteur Société de recyclage
Précondition La société de recyclage doit être authentique
Post Liste des commandes de produit recyclable affichée.
Scénario Nominal 1- La société de recyclage demande liste des commandes de produit
recyclable.
2-systéme afficher la liste
3-Base de donnée collecte les informations
4-Base de donnée renvoi résultat.
5-Systéme afficher liste des commandes de produits recyclables.
Scénario 4)a)- Le système renvoi table vide
Alternatif

Remarque : le tableau descriptif de sous cas d’utilisation « étudier


commande produit recyclable » a le même concept que « étudier réclamation »
qui sera traité dans le sprint suivant.

81
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.4 Conception
2.4.1 Conception statique du sprint
 Diagramme de classe

Figure 82: Diagramme de classe se Sprint 1

• Dictionnaire de donné : table « produit recyclable »

Tableau 42: Dictionnaire de donné de la table « produit recyclable »

Nom de la colonne Signification Type de données

id L’identifiant unique de produit recyclable INT


type Type de produit recyclable TEXT
stock La quantité de produit recyclable dans le stock. INT
Date_ins La date d’insertion de produit recyclable TEXT

82
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Dictionnaire de donné : table « demande »

Tableau 43: Dictionnaire de donné de la table « demande »

Nom de la colonne Signification Type de données

id L’identifiant unique de demande de produit INT


recyclable
quantite Quantité produit recyclable INT
Date_ins La date d’insertion de produit recyclable TEXT
etat L’état de demande de produit recyclable INT

2.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 83: Diagramme de package de Sprint 1

83
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagrammes de séquences

Figure 84: Diagramme de séquence "Ajouter produit recyclable"

Figure 85: Diagramme de séquence "Suivre commande de produit recyclable"

84
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagramme d’activité

Figure 86: Diagramme d'activité "supprimer véhicule"

 Diagramme d’état de transition

Figure 87: Diagramme d'état "Etudier demande"

85
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.5 Réalisation

Figure 88: Interface "Gérer produit recyclage"

Figure 89: Interface "Gérer demande de produit recyclable"

86
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

2.6 Test et validation


Tableau 44: Test et validation de Sprint 1

Cas de test Démarche de test Compartiment attendu Résultat

Ajouter L’agent / La société de Message d’erreur s’il y’a Conforme


produit/commande recyclage remplie un formulaire une information obligatoire
produit recyclable d’ajout. manquante
Modifier produit/ L’agent / La société de Message d’erreur s’il y’a Conforme
commande produit recyclage modifie l’information. une information obligatoire
recyclable manquante
Supprimer L’agent / La société de Message de confirmation Conforme
Produit/ commande recyclage demande la affiché .
produit recyclable suppression.
Changer état de L’agent modifie l’état de l’état de commande produit Conforme
commande commande produit recyclable. recyclable est bien
changée.
Suivre commande La société de recyclage Liste des demandes est Conforme
produit demande la liste de demandes bien affichée.
de produit recyclable.

2.7 Sprint review

Figure 90: Sprint Burn-down chart

87
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3. Sprint 2
3.1 Backlog du sprint 2
Tableau 45: Backlog de Sprint 2

ID Feature USER STORY Priori STORY


té POINT(jr
)

13 Réclamer une En tant que citoyen je peux réclamer une 3 5


faille telle faille pour réduire la détérioration
de l’infrastructure

18 Gérer En tant qu’Agent je veux gérer les 3 5


réclamations réclamations pour résoudre les
problèmes existantes.

19 Publier En tant que citoyen je veux publier mes 3 2


propositions propositions pour améliorer la ville et la
moderniser.

20 Gérer sondages En tant qu’agent je veux gérer les sondages 3 3


pour mieux évaluer les avis des clients.

3.2 Tableau des taches

Figure 91: Tableau des taches de Sprint 2

88
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.3 Analyse
3.3.1 Identification des acteurs et des cas d’utilisation

Figure 92: Diagramme de cas d'utilisation de Sprint 2

3.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « Etudier réclamation »

Figure 93: Diagramme de cas d'utilisation "Etudier réclamation"

89
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 46: Description de cas d'utilisation "Etudier réclamation"

Acteur L’agent municipal

Objectif L’agent municipal modifie l’état de la réclamation de citoyen.

Pré-condition(s) - L’agent municipal doit être authentifié.


- L’agent municipal doit accéder à la liste des réclamations.

Post-condition(s) L’état de réclamation est modifié avec succès

Scénario-Nominal 1. L’agent municipal choisi l’état de réclamation à modifier.


2. Le système affiche formulaire contenant les anciennes données.
3. L’agent municipal modifie les informations.
4. L’agent municipal valide la saisie.
5. Le système vérifie les données.
6. Le système enregistre les données.
7. Modification avec sucées

5. a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

• Description du cas d’utilisation « Réclamer une faille »

Figure 94: Diagramme de cas d'utilisation "Réclamer une faille"

90
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 47: Description de cas d'utilisation "Réclamer une faille"

Acteur Le citoyen

Objectif Le citoyen envoie une réclamation avec succès.

Pré-condition(s) - Le citoyen doit être authentifié.


- Le citoyen doit accéder à l’interface
« Réclamation ».

Post-condition(s) Réclamation envoyer avec succès.

Scénario-Nominal 1. Le citoyen rempli le formulaire de réclamation.


2. Le système vérifie les champs.
3. Le système ajoute les données à la base de donnés.
4. Le système doit afficher message sucées.
5. Le système réaffiche la liste des réclamation.

2.a/ message d’erreur.


Scénario(s) alternatif(s)

Remarque : le tableau descriptif de sous cas d’utilisation « Publier


proposition » a le même concept que « Réclamer une faille ».
• Description du cas d’utilisation « Consulter réclamation »

Figure 95: Consulter réclamation

91
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 48: Description de as d'utilisation "Consulter réclamation"

Nom du cas Consulter réclamation

Objectif L’Agent municipal doit consulter la liste des réclamations .

Acteur L’Agent municipal


Précondition ’Agent municipal doit être authentique
Post Liste des réclamations affichée.
Scénario Nominal 1-’Agent municipal demande liste des réclamations.
2-systéme afficher la liste
3-Base de donnée collecte les informations
4-Base de donnée renvoi résultat.
5-Systéme afficher liste des réclamations.
Scénario 4)a)- Le système renvoi table vide
Alternatif

3.4 Conception
3.4.1 Conception statique du sprint
 Diagramme de classe

Figure 96: Diagramme de classe de Sprint 2

92
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Dictionnaire de donné : table « réclamation »


Tableau 49: Dictionnaire de donné de la table « réclamation »

Nom de la colonne Signification Type de données

id L’identifiant unique de réclamation INT


titre Titre de réclamation INT
Date_ins La date d’insertion de réclamation TEXT
etat L’état de réclamation INT
heure L’heure de réclamation TEXT
contenu Le contenu de réclamation TEXT
image L’image de réclamation TEXT
longitude longitude de réclamation TEXT
latitude latitude de réclamation TEXT

• Dictionnaire de donné : table « proposition »


Tableau 50: Dictionnaire de donné de la table « proposition »

Nom de la colonne Signification Type de données

id L’identifiant unique de proposition INT


proposition La proposition de citoyen TEXT
Date_ins La date d’insertion de proposition TEXT

• Dictionnaire de donné : table sondage


Tableau 51: Dictionnaire de donné de la table sondage

Nom de la colonne Signification Type de données

id L’identifiant unique de sondage INT


titre Titre de sondage TEXT
objet Objet de sondage TEXT
Option1 Premier option de sondage TEXT
Option2 Deuxième option de sondage TEXT
Option3 Troisième option de sondage TEXT
Date_ins La date d’insertion de sondage TEXT

93
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 97: Diagramme de package de Sprint 2

 Diagrammes des séquences

94
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 98: Diagramme de séquence "Consulter réclamation"

Figure 99: Diagramme de séquence "Réclamer une faille"

95
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 100: Etudier réclamation

 Diagramme d’activité

Figure 101: Diagramme d'activité "Modifier sondage"

96
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagramme d’état de transition

Figure 102: Diagramme d'état de transition « Etudier réclamation"

97
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.5 Réalisation

Figure 103: Interface "Gérer réclamation"

Figure 104: Interface "Gérer sondage"

98
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.6 Test et validation


Tableau 52: Test et validation

Cas de test Démarche de test Compartiment attendu Résultat

Etudier réclamation L’Agent demande la liste Liste des réclamations est Conforme
des réclamations. affichée.
Changer l’état de L’agent modifie Message d’erreur s’il y’a Conforme
réclamation l’information. une information
obligatoire manquante
Supprimer L’agent demande la Message de confirmation Conforme
réclamation suppression. affiché
Ajouter sondage L’agent remplie un Message d’erreur s’il y’a Conforme
formulaire d’ajout. une information
obligatoire manquante
Modifier sondage L’agent modifie Message d’erreur s’il y’a Conforme
l’information. une information
obligatoire manquante
Supprimer sondage L’agent demande la Message de confirmation Conforme
suppression. affiché
Réclamer une faille Le citoyen remplie un Message d’erreur s’il y’a Conforme
formulaire d’ajout d’une une information
réclamation. obligatoire manquante
Publier proposition Le citoyen remplie un Message d’erreur s’il y’a Conforme
formulaire d’ajout d’une une information
proposition. obligatoire manquante

99
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

3.7 Sprint review

Figure 105: Sprint Burn-down chart

4. Sprint 3
4.1 Backlog produit du sprint 3
Tableau 53: Backlog du Sprint 3

ID Feature USER STORY Priori STORY


té POINT

21 Voter un En tant que citoyen 3 4


sondage Je veux voter des sondages pour être
actif et impliqué dans la société

22 Gérer En tant qu’Agent je veux gérer les 3 4


événements événements pour informer les citoyens
des évènements pour qu’ils participent.

23 Consulter En tant que citoyen je veux consulter la 3 2


événements liste des événements pour participer.

24 Configurer des En tant qu’Admin je veux configurer les 3 5


statistiques statistiques pour mieux évaluer
l’avancement global du travail.

100
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.2 Tableau des taches

Figure 106: Tableau des taches de Sprint 3

4.3 Analyse
4.3.1 Identification des acteurs et des cas d’utilisation

Figure 107: Diagramme de cas d'utilisation de Sprint 3

101
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.3.2 Description des cas d’utilisations : fiche de cas d’utilisation


• Description du cas d’utilisation « Voter Sondage »

Figure 108: Diagramme de cas d'utilisation " Voter Sondage "

Tableau 54: Description du cas d’utilisation « Voter Sondage»

Acteur Citoyen

Objectif Le citoyen vote un sondage

Pré-condition(s) - Le citoyen doit être authentifié.


- Le citoyen doit accéder à l’interface « vote ».
- Le citoyen choisit une option parmi les options de sondage..

Post-condition(s) Vote est ajouté avec succès.

Scénario-Nominal 1. Le citoyen rempli le formulaire d’ajout d’un vote.


2. Le citoyen valide la saisie
3. Le système vérifie les champs.
4. Le système ajoute les données à la base de donnés.
5. Le système doit afficher message sucées.
6. Le système réaffiche la liste des sondages.

3.a/ Le système affiche un message d’erreur.


Scénario(s) alternatif(s)

• Description du cas d’utilisation « Consulter évènement »

Figure 109: Diagramme de cas d'utilisation "Consulter évènement"

102
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 55: Description du cas d’utilisation « Consulter évènement »

Nom du cas Consulter événement

Objectif Le citoyen doit consulter la liste des évènements .

Acteur Citoyen
Précondition Le citoyen doit être authentique
Post Liste des événements affichée.
Scénario Nominal 1-le citoyen demande liste des événements.
2-systéme afficher la liste
3-Base de donnée collecte les informations
4-Base de donnée renvoi résultat.
5-Systéme afficher liste des événements.
Scénario 4)a)- Le système renvoi table vide
Alternatif

• Description du cas d’utilisation « Configurer statistique »

Figure 110: Diagramme de cas d'utilisation «Configurer statistique"

103
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________
Tableau 56: Description du cas d’utilisation « Configurer statistique »

Nom du cas Configurer les statistiques.

Acteur Admin
Objectif Configurer les statistiques.
Pré condition L’administrateur doit être authentifié.

Pos condition Les statistiques sont configurées.


Scénario nominal 1-L’utilisateur demande au système de configurer les statistiques.

2-Le système affiche l’interface de configuration.

3-L’utilisateur configure les statistiques.

4- Le système affiche les statistiques.


Scénario alternatif 4-1-Le système affiche message erreur.

4.4 Conception
4.4.1 Conception statique du sprint
 Diagramme de classe globale

Figure 111: Diagramme de classe globale

104
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

• Dictionnaire de donné : table « vote »

Tableau 57: Dictionnaire de donné de la table « Vote »

Nom de la colonne Signification Type de données

id L’identifiant unique de vote de sondage INT


reponse Réponse (choix) de sondage TEXT
Date_ins La date d’insertion de vote de sondage TEXT

• Dictionnaire de donné : table « évènement »

Tableau 58: Dictionnaire de donné de la table « Evènement »

Nom de la colonne Signification Type de données

id L’identifiant unique d’évènement INT


titre Titre de sondage d’évènement TEXT
description description d’évènement TEXT
lieu Le lieu d’évènement TEXT
Type Le type d’évènement TEXT
Date_ins La date d’insertion d’évènement TEXT

105
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.4.2 Conception dynamique du sprint


 Diagramme de package

Figure 112: Diagramme de package de sprint 3

106
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

 Diagrammes de séquences

Figure 113: Diagramme de séquence "voter un sondage"

Figure 114: Diagramme de séquence "consulter évènement"

107
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

Figure 115: Diagramme de séquence "Configurer statistique"

 Diagramme d’activité

Figure 116: Diagramme d'activité "Supprimer évènement"

108
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.5 Réalisation

Figure 117: Interface 'Gérer évènement"

4.6 Test et validation


Figure 118: Test et validation

Cas de test Démarche de test Compartiment attendu Résultat


Voter sondage Le citoyen choisie une Réponse envoyée avec Conforme
option de sondage succès.

Consulter évènement L’Agent demande la liste La liste est affichée. Conforme


des évènements.
Ajouter évènement L’agent remplie un Message d’erreur s’il y’a Conforme
formulaire d’ajout. une information
obligatoire manquante.
Modifier évènement L’agent modifie Message d’erreur s’il y’a Conforme
l’information. une information
obligatoire manquante.
Supprimer L’agent demande la Message de confirmation Conforme
évènement suppression. affiché .
Configurer statistique L’Admin évalue le Statistiques sont affichés. Conforme
déroulement de
l’application.

109
Chapitre 5 : Mise en œuvre du release 1 Wissal SOLTANII
__________________________________________________________________________________

4.7 Sprint Review

Figure 119: Sprint Burn-down chart

5. conclusion

Au cours de ce chapitre, nous avons présenté les trois derniers premiers sprints. Pour ce
faire, nous avons passé par l’analyse, la conception et enfin la réalisation.

110
Conclusion

Conclusion générale

Ce travail représente le fruit pour les années des études, c’est une véritable occasion de
mettre en pratique les connaissances acquises durant mes études universitaires et j’ai
essayé de raffiner mes compétences de conception, de développement et de bien
choisir la méthode de travail.

Dans ce cadre, nous avons conçu et développé une application de gestion de


l’environnement de la municipalité de jendouba. Nous avons essayé tout au long de
notre travail de construire notre application incrément par incrément en utilisant la
méthodologie Scrum.

Pour cela, notre travail a été décomposé en quatre étapes majeures :

La première avait pour but d’étudier le cadre général de notre application et


d’identifier les différentes exigences de notre futur système.

Le second travail consistait à dégager les besoins fonctionnels et non fonctionnels qui
doivent satisfaire notre application puis par préciser les livrables et les risques les plus
critiques de notre projet.

La troisième et la quatrième étape consistaient au choix de la démarche du projet


qui est la méthode Scrum la plus adaptable de notre projet puis d’expliquer les
principes et les rôles du scrum et enfin l’organigramme du projet tel que la
planification et le diagramme de Gantt. Après nous avons effectué l’étape de
cartographie et architecture du projet qui incluse la carte d’identité et
l’architecture de la solution ainsi que la conception détaillée et l’environnement
du travail.

Finalement on a effectué la mise en œuvre des releases 1 et 2 d’où chaque release


contient deux sprints et chaque sprint contient le Backlog du produit, le tableau

111
des taches ainsi que l’analyse et la conception et terminant par la réalisation, test
et validation et finalement le sprint review.

Ce projet a été l’occasion d’apprendre de nouvelles technologies telles que

PHP7, Android, HTML5, CSS3, JavaScript.

Nous intégrons l’approche de l’intelligence artificielle et nous exploitant l’algorithme


« Dijkstra »de calcul de plus court chemin, les itinéraires et la synthèse vocale.

Comme perspective, nous espérons que cette application est un outil vraiment utile et
qu’elle évolue pour couvrir d’autre besoins.

112
Webographie

Lien Consulté le :

[1] https://www.elbaladiya.tn/Grombalia 15/03/2021

[2] https://play.google.com/store/apps/details? 15/03/2021


id=mobi.foo.baladiyati&hl=fr&gl=US

[3] https://play.google.com/store/apps/details? 15/03/2021


id=com.devtweaks.rokhsti

[4] https://fr.wikipedia.org/wiki/Algorithme_de_Dijkstra 01/06/2021

[5] https://support.google.com/maps/answer/144339? 25/05/2021


co=GENIE.Platform%3DDesktop&hl=fr

[6] https://fr.wikipedia.org/wiki/Synthèse_vocale 05/05/2021

[7] https://www.journaldunet.fr/web-tech/guide-de-l-entreprise- 07/03/2021


digitale/1443838-methode-agile-definition-comparatif-et-
avantages/

[8] https://agiliste.fr/introduction-methodes-agiles 08/03/2021

[9] :https://agiliste.fr/introduction-methodes-agiles/(Méthodes agile) 09/03/2021

[10] https://stph.scenaricommunity.org/bdd/lap2/co/ 02/04/2021


webUC003archi.html

[11] http://orm.bdpedia.fr/mvc.htmlMVC 04/04/2021

[12] https://fr.wikipedia.org/wiki/Trello 20/04/2021

[13] :https://www.tice-education.fr/tous-les-articles-er-ressources/ 05/02/2021

articles-internet/819-draw-io (Draw.io

[14] https://fr.wikipedia.org/wiki/GanttProject 20/04/2021

[15] https://fr.wikipedia.org/wiki/StarUML 20/04/2021

[16] https://fr.wikipedia.org/wiki/Notepad%2B%2B#:~:text=Notepad 20/04/2021


%2B%2B%20est%20un%20éditeur,%2C%20art%20ASCII%2C

113
%20doxygen%2C%20.

[17] https://fr.wikipedia.org/wiki/Oracle_VM_VirtualBox 20/04/2021

[18] https://fr.wikipedia.org/wiki/Vagrant 20/04/2021

[19] https://fr.wikipedia.org/wiki/Git 20/04/2021

[20] https://fr.wikipedia.org/wiki/Android_Studio 20/04/2021

[21] https://fr.wikipedia.org/wiki/MySQL_Workbench 20/04/2021

[22] https://desgeeksetdeslettres.com/web/xampp-plateforme-pour- 20/04/2021


heberger-son-propre-site-web

[23] https://www.journaldunet.com/web-tech/developpeur/1152109- 20/04/2021


php-7-la-future-version-majeure-de-php-au-crible/

[24] https://www.journaldunet.fr/web-tech/dictionnaire-du- 20/04/2021


webmastering/1203257-html5-hypertext-markup-langage5-
definition-traduction/

[25] https://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade 20/04/2021

[26] https://www.journaldunet.fr/web-tech/dictionnaire-du- 20/04/2021


webmastering/1203585-javascript/

[27] https://fr.wikipedia.org/wiki/JQuery 20/04/2021

[28] https://fr.yeeply.com/blog/langages-de-programmation-creer-une- 20/04/2021


application-android/

[29] https://fr.yeeply.com/blog/langages-de-programmation-creer-une- 20/04/2021


application-android/

114
Annexes
L’enquête :

Voilà les résultats de l’enquête que je propose en collaboration avec Mr, Khemiri Nabil :

115
116
Algorithme Dijkstra :

117
118

Vous aimerez peut-être aussi