SlideShare une entreprise Scribd logo
Année Universitaire:2018/2019Code: 720
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet
Développement d’une application pour la gestion des équipements
de sécurité et de lutte contre les incendies dans les bâtiments
Élaboré par:
Raoua Bennasr
Présenté en vue de l'obtention du diplôme de
Mastère professionnel en Modélisation, Bases de Données et
Intégration des Systèmes
Organisme d'accueil
Première Consulting
Encadré par
ESEN Mme Yamna Ettares
Société Mme Amani Bouaziz
Remerciements
J’aimerais en premier lieu remercier mon dieu Allah qui ma donné le courage pour la
réalisation de ce travail
Je tiens tout d'abord à adresser mes plus vifs remerciements à mon encadreur Madame
Yamna Ettares pour son encadrement ses conseils et ses corrections.
J’adresse mes vifs remerciements à Madame Amani Bouaziz, qui m'a soutenue tout au long
de mon travail
Je tiens également à remercier et exprimer mon profond respect aux membres de jury d’avoir
accepté de juger ce travail
Et en fin j’adresse mes s’incères remerciements à mes parents et mes sœurs.
Table des matières
Introduction générale.............................................................................................................................. 1
Chapitre 1 : Étude du projet.................................................................................................................... 2
Chapitre 1 : Étude du projet.................................................................................................................... 3
Introduction ............................................................................................................................................. 3
I Présentation de l’organisme d’accueil............................................................................................. 3
1. Présentation ..................................................................................................................................... 3
2. Organisation .................................................................................................................................... 3
3. Organigramme................................................................................................................................. 3
4. Activités........................................................................................................................................... 4
II Présentation du projet...................................................................................................................... 5
1. Cadre du projet............................................................................................................................ 5
2. Etude de l’existant....................................................................................................................... 5
2.1. Description de l’existant...................................................................................................... 5
2.2. Critique de l’existant ........................................................................................................... 6
3. Solution proposée........................................................................................................................ 6
III Méthodologie adoptée ................................................................................................................. 7
1. Méthodes agiles........................................................................................................................... 7
2. Méthode agile adoptée: Scrum.................................................................................................... 7
Conclusion ............................................................................................................................................... 9
Chapitre 2 : Planification générale du projet .......................................................................................... 9
Chapitre 2: Planification générale du projet ......................................................................................... 10
Introduction ........................................................................................................................................... 10
I. Analyse des besoins....................................................................................................................... 10
1. Identification des acteurs........................................................................................................... 10
2. Les besoins fonctionnels............................................................................................................ 11
3. Les besoins non fonctionnels..................................................................................................... 13
4. Langage de modélisation adopté ............................................................................................... 13
5. Architecture logiciel.................................................................................................................. 13
II. Diagramme des cas d’utilisation global......................................................................................... 14
III. Prototypage des interfaces de l’application............................................................................... 16
IV. Adaptation du cycle de développement Scrum au projet .......................................................... 18
1. Répartition des rôles.................................................................................................................. 18
2. Product Backlog ........................................................................................................................ 18
3. Planification des sprints du projet ............................................................................................. 22
Conclusion............................................................................................................................................. 22
Chapitre 3 : Release 1 du projet............................................................................................................ 23
Chapitre 3 : Release 1 du projet............................................................................................................ 24
Introduction ........................................................................................................................................... 24
I. Premier Sprint................................................................................................................................ 24
1. Spécification fonctionnelle........................................................................................................ 25
1.1. Diagramme de cas d’utilisation du sprint 1....................................................................... 25
1.2. Raffinement des cas d’utilisation du sprint 1 .................................................................... 26
1.3. Description textuelle des cas d’utilisation......................................................................... 27
Nous traitons uniquement les cas d’utilisation :............................................................................ 27
2. Conception................................................................................................................................. 29
2.1. Diagrammes de séquence système .................................................................................... 29
2.2. Diagrammes des classes participantes............................................................................... 32
2.3. Diagrammes de séquences détaillés .................................................................................. 33
2.4. Diagramme des classes de sprint 1.................................................................................... 35
3. Codage....................................................................................................................................... 35
4. Les interfaces............................................................................................................................. 37
II. Deuxième Sprint............................................................................................................................ 43
1. Spécification fonctionnelle........................................................................................................ 43
1.1. Diagramme de cas d’utilisation du sprint 2....................................................................... 44
1.2. Raffinement des cas d’utilisation du sprint 2 .................................................................... 45
1.3. Description textuelle des cas d’utilisation......................................................................... 46
2. Conception................................................................................................................................. 50
2.1. Diagrammes de séquence système .................................................................................... 50
2.2. Diagrammes des classes participantes............................................................................... 55
2.3. Diagrammes de séquences détaillés .................................................................................. 56
2.4. Diagramme des classes de sprint 2.................................................................................... 58
3. Codage....................................................................................................................................... 59
4. Les interfaces............................................................................................................................. 60
Conclusion ............................................................................................................................................. 66
Chapitre 4 : Release 2 du projet............................................................................................................ 67
Chapitre 4 : Release 2 du projet............................................................................................................ 68
Introduction ........................................................................................................................................... 68
I. Premier Sprint................................................................................................................................ 68
1. Spécification fonctionnelle........................................................................................................ 68
1.1. Diagramme de cas d’utilisation du sprint.......................................................................... 69
1.2. Raffinement des cas d’utilisation du sprint ....................................................................... 69
1.3. Description textuelle des cas d’utilisation......................................................................... 70
2. Conception................................................................................................................................. 72
2.1. Diagrammes de séquence système .................................................................................... 72
2.2. Diagrammes des classes participantes............................................................................... 74
2.3. Diagrammes de séquences détaillés .................................................................................. 75
2.4. Diagramme des classes de sprint 1.................................................................................... 76
3. Codage....................................................................................................................................... 77
4. Les interfaces............................................................................................................................. 77
II. Deuxième Sprint............................................................................................................................ 79
1. Spécification fonctionnelle........................................................................................................ 79
1.1. Diagramme de cas d’utilisation du sprint 2....................................................................... 79
1.2. Raffinement des cas d’utilisation du sprint 2 .................................................................... 80
1.3. Description textuelle des cas d’utilisation......................................................................... 80
2. Conception................................................................................................................................. 82
2.1. Diagrammes de séquence système .................................................................................... 82
2.2. Diagrammes des classes participantes............................................................................... 84
2.3. Diagrammes de séquences détaillés .................................................................................. 85
3. Codage....................................................................................................................................... 86
4. Les interfaces............................................................................................................................. 86
5. Diagramme des classes global................................................................................................... 88
Conclusion ............................................................................................................................................. 88
Chapitre 5 : Phase de clôture ................................................................................................................ 89
Chapitre 5 : Phase de clôture ................................................................................................................ 90
Introduction........................................................................................................................................... 90
I. Environnement de travail .............................................................................................................. 90
1. Environnement matériel ............................................................................................................ 90
2. Environnement logiciel ............................................................................................................. 91
2.1. Outils et logiciels............................................................................................................... 91
2.2. Technologies ..................................................................................................................... 92
3. Déploiement .............................................................................................................................. 93
3.1. Architecture opérationnelle ................................................................................................... 93
3.2. Diagramme de déploiement................................................................................................... 94
Conclusion ............................................................................................................................................. 94
Conclusion générale.............................................................................................................................. 95
Bibliographie.......................................................................................................................................... 96
Liste des figures
Figure 1 : Organigramme Première Consulting....................................................................................... 3
Figure 2: La méthode scrum.................................................................................................................... 8
Figure 3: Logo UML................................................................................................................................ 13
Figure 4: Architecture MVC................................................................................................................... 14
Figure 5: Diagramme des cas d’utilisation global.................................................................................. 15
Figure 6: Logo d'outil balsamiq ............................................................................................................. 16
Figure 7: Interface de l’authentification................................................................................................ 16
Figure 8: Interface de la Gestion des équipements .............................................................................. 16
Figure 9: de la gestion des actions ........................................................................................................ 17
Figure 10: Interface de la gestion des contrôles ................................................................................... 17
Figure 11: Interface Ajout d’action........................................................................................................ 17
Figure 12: Interface Ajout du contrôle................................................................................................. 17
Figure 13: Diagramme de cas d'utilisation global du Sprint 1............................................................... 25
Figure 14: Diagramme de cas d'utilisation détaillé du Sprint 1............................................................. 26
Figure 15: Diagramme de séquence système du cas d'utilisation « Ajouter équipement».................. 30
Figure 16: Diagramme de séquence système du cas d'utilisation « Modifier équipement»................ 30
Figure 17: Diagramme de séquence système du cas d'utilisation « Supprimer équipement»............. 31
Figure 18: Diagramme de séquence système du cas d'utilisation « Consulter liste équipements»..... 31
Figure 19: Diagramme des classes participantes du cas d’utilisation« Gestion Catégorie» ................. 32
Figure 20: Diagramme des classes participantes du cas d’utilisation« Gestion équipement»............. 33
Figure 21 : Diagramme de séquences détaillé « Ajouter équipement ».............................................. 34
Figure 22: Diagramme de séquences détaillé « Consulter la liste des équipements »........................ 34
Figure 23: Diagramme de classe du sprint 1 ......................................................................................... 35
Figure 24: Table «équipement » ........................................................................................................... 36
Figure 25: Table «catégorie »................................................................................................................ 36
Figure 26: Table «CheckListe ».............................................................................................................. 36
Figure 27: Table «équipement » ........................................................................................................... 37
Figure 28: Table «local »........................................................................................................................ 37
Figure 29: Interface « Gestion équipements »..................................................................................... 37
Figure 30: Interface « Ajouter équipement »....................................................................................... 38
Figure 31: Interface « Modifier équipement »..................................................................................... 38
Figure 32: Interface « Gestion catégorie »........................................................................................... 39
Figure 33: Interface « Gestion Check-list »........................................................................................... 39
Figure 34: Interface « Gestion fournisseur»......................................................................................... 40
Figure 35: Interface « Gestion fournisseur»......................................................................................... 40
Figure 36: Interface « Consulter équipements»................................................................................... 41
Figure 37: Interface « équipements» ................................................................................................... 41
Figure 38: Interface « Recherche un équipement par QRCode» ........................................................ 42
Figure 39: Interface « Consulter un seul équipement»....................................................................... 42
Figure 40: diagramme des cas d’utilisation du deuxième sprint........................................................... 44
Figure 41: diagramme des cas d’utilisation détaillé du deuxième sprint.............................................. 45
Figure 42: Diagramme de séquence système du cas d'utilisation « Ajouter action» ........................... 50
Figure 43: Diagramme de séquence système du cas d'utilisation « Modifier action» ......................... 51
Figure 44: Diagramme de séquence système du cas d'utilisation « Supprimer action»....................... 52
Figure 45: Diagramme de séquence système du cas d'utilisation « Consulter les actions»................ 52
Figure 46: Diagramme de séquence système du cas d'utilisation « Ajouter Contrôles»...................... 53
Figure 47: Diagramme de séquence système du cas d'utilisation « Ajouter Planning» ....................... 54
Figure 48: Diagramme des classes participantes du cas d’utilisation« Gestion actions» ..................... 55
Figure 49: Diagramme des classes participantes du cas d’utilisation« Gestion Contrôle»................... 55
Figure 50: Diagramme des classes participantes du cas d’utilisation« Planification» .......................... 56
Figure 51: Diagramme de séquences détaillé « Ajouter action » ......................................................... 57
Figure 52: Diagramme de séquences détaillé « Consulter les actions »............................................... 57
Figure 53: Diagramme de classe du sprint 2 ......................................................................................... 58
Figure 54 : table Contrôle...................................................................................................................... 59
Figure 55 : table Action ......................................................................................................................... 59
Figure 56 : table Planification................................................................................................................ 60
Figure 57 : table Membre...................................................................................................................... 60
Figure 58 : Interface Gestion Contrôles ................................................................................................ 61
Figure 59 : Interface Ajouter Contrôle .................................................................................................. 61
Figure 60 : Interface Gestion Actions.................................................................................................... 62
Figure 61: Interface Ajouter Action....................................................................................................... 62
Figure 62: Interface Planification .......................................................................................................... 63
Figure 63: Interface Ajouter planning ................................................................................................... 63
Figure 64 : Interface Consulter Actions................................................................................................. 64
Figure 65 : Interface Consulter Contrôles ............................................................................................. 64
Figure 66 : Interface Gestion Membre.................................................................................................. 65
Figure 67 : Interface Ajouter Contrôle .................................................................................................. 65
Figure 68 : Interface Liste des Contrôles.............................................................................................. 65
Figure 69: diagramme des cas d’utilisation du sprint 1 ........................................................................ 69
Figure 70: diagramme des cas d’utilisation détaillé du sprint 1............................................................ 69
Figure 71: diagramme de séquence système du cas «Ajouter Site»..................................................... 72
Figure 72: diagramme de séquence système du cas «Modifier Site»................................................... 73
Figure 73: diagramme de séquence système du cas «Supprimer Site»................................................ 73
Figure 74 : Diagramme des classes participantes du cas d’utilisation« Gestion Sites» ........................ 74
Figure 75 : Diagramme des classes participantes du cas d’utilisation« Gestion super user ».............. 74
Figure 76: diagramme de séquence détaillé du cas «Ajouter Site»...................................................... 75
Figure 77: diagramme de séquence détaillé du cas «Ajouter super user»........................................... 76
Figure 78: Diagramme de classe du sprint 2 ......................................................................................... 76
Figure 79: Table site .............................................................................................................................. 77
Figure 80: Table super user................................................................................................................... 77
Figure 81 : Interface Gestion sites......................................................................................................... 78
Figure 82 : Interface Gestion super utilisateur...................................................................................... 78
Figure 83: diagramme des cas d’utilisation du deuxième sprint........................................................... 79
Figure 84: diagramme des cas d’utilisation détaillé du deuxième sprint.............................................. 80
Figure 85: diagramme de séquence système du cas «Authentification» ............................................. 82
Figure 86: diagramme de séquence système du cas «Modifier profil»................................................ 83
Figure 87: diagramme de classes participantes «Gestion profil» ......................................................... 84
Figure 88: diagramme de classes participantes «Authentification»..................................................... 84
Figure 89: Diagramme de séquence détaillé du cas d'utilisation « Modifier profil » ........................... 85
Figure 90: Table Administrateur............................................................................................................ 86
Figure 91: Interface « Authentification»............................................................................................... 86
Figure 92: Interface « Consulter profil» ................................................................................................ 87
Figure 93: Interface « Modifier profil».................................................................................................. 87
Figure 94: Diagramme des classes global.............................................................................................. 88
Figure 95 : l’architecture 3 tiers ............................................................................................................ 93
Figure 96: diagramme de déploiement................................................................................................. 94
Liste des tableaux
Table 1: Backlog du produit................................................................................................................... 21
Table 2: Backlog du premier sprint (release 1) ..................................................................................... 24
Table 3: Description textuelle du cas d’utilisation « Ajouter équipement».......................................... 27
Table 4: Description textuelle du cas d’utilisation « Modifier équipement»........................................ 28
Table 5: Description textuelle du cas d’utilisation « Supprimer équipement»..................................... 28
Table 6: Description textuelle du cas d’utilisation « Consulter la liste des équipements».................. 29
Table 7: Backlog du deuxième sprint (release 1) .................................................................................. 43
Table 8: Description textuelle du cas d’utilisation « Ajouter Action»................................................... 46
Table 9: Description textuelle du cas d’utilisation « Modifier action» ................................................. 47
Table 10: Description textuelle du cas d’utilisation « Supprimer action» ............................................ 47
Table 11: Description textuelle du cas d’utilisation « Ajouter Contrôle» ............................................. 48
Table 12: Description textuelle du cas d’utilisation « Ajouter Planning» ............................................. 49
Table 13: Description textuelle du cas d’utilisation « Consulter les actions»....................................... 49
Table 14: Backlog du premier sprint (release 2) ................................................................................... 68
Table 15: Description textuelle du cas d’utilisation « Ajouter Site» ..................................................... 70
Table 16: Description textuelle du cas d’utilisation « Modifier site».................................................... 71
Table 17: Description textuelle du cas d’utilisation « Supprimer site»................................................. 71
Table 18: Backlog du deuxième sprint (release 2) ................................................................................ 79
Table 19: Description textuelle du cas d’utilisation « Consulter Profil» ............................................... 80
Table 20: Description textuelle du cas d’utilisation « Modifier Profil»................................................. 81
Table 21: Description textuelle du cas d’utilisation «Authentification»............................................... 81
Table 22 : Les caractéristiques d’environnement du travail ................................................................. 90
Page 1
Introduction générale
L’informatique est un domaine d'activité technique et industriel concernant le traitement de
l’information. Il représente l'ensemble des ressources d'une organisation : hommes, matériels
et logiciels, pour collecter, stocker, traiter et diffuser les informations.
De nos jours, beaucoup sont les entreprises qui sont confrontées à des problèmes liés à la
gestion des stocks et à la nécessité d’une application informatique permettent d’éviter ces
problèmes.
La puissance de l’informatique offre toutes les possibilités, l’évolution des logiciels permet
d’automatiser des procédures et de fournir les informations adéquates à temps.
A cet effet, notre projet de fin d’études consiste à développer une application web et mobile
pour la gestion des équipements de sécurité et de lutte contre les incendies dans les bâtiments.
Notre travail consiste donc en deux principales parties, une partie qui s’intéresse au
développement d’une application web permettant aux utilisateurs d’assure la gestion des
équipements, gestion des contrôles, gestion des actions d’intervention et planification des
contrôles. Une deuxième partie qui consiste à développer une application mobile pour la
gestion des actions et gestion des contrôles pour faciliter le travail aux utilisateurs.
Notre rapport est élaboré en adoptant la méthodologie Scrum et il se compose de
cinq chapitres plus une introduction générale et une conclusion :
 Le premier chapitre « Étude du projet » contient la présentation générale du projet à
travers la présentation de l’organisme d’accueil ainsi du projet dans un premier temps et la
méthode du travail adoptée dans un second temps.
 Le deuxième chapitre intitulé « Planification du projet » appelé aussi sprint 0, ce chapitre
sera consacré au recueil des besoins et la planification complète du travail.
 Le troisième et le quatrième chapitre sont nommés respectivement « Release 1 du projet »
et « Release 2 du projet » sont dédié au développent des deux releases.
 Le dernier chapitre intitulé « Phase de clôture » présente les différents outils et
technologies utilisées pour le développement.
Page 2
Chapitre 1 :
Étude du projet
Page 3
Chapitre 1 : Étude du projet
Introduction
Dans ce chapitre, nous présentons l’organisme d’accueil où s’est déroulé le stage par la suite
le cadre du projet, l’étude de l’existant présentant la situation actuelle, la solution proposée et
finalement la méthode du travail adoptée.
I Présentation de l’organisme d’accueil
1. Présentation
Première Consulting SARL est un cabinet d’assistance, de conseil et de formation, fondée en
2008. Elle se situe à 73ter Avenue Habib Bourguiba, Manouba.
2. Organisation
La société est subdivisée comme suit :
 Direction générale : Elle est assistée par un assistant qui transmet les notes aux autres
directions
 Service administratif et financier : Son rôle est de gérer les affaires administratives et de
la comptabilité de la société en analysant la liquidité, la solvabilité et la rentabilité.
 Service de formation : Des formateurs se chargent de la formation des clients sur les
activités de la société.
 Service informatique : Ce service developpe des applications web et desktop pour
faciliter le travail quotidien de ses clients.
3. Organigramme
Figure 1 : Organigramme Première Consulting
Page 4
4. Activités
Dès la création de l’entreprise, la direction générale de « Première Consulting » a fait le choix
essentiel d’offrir à ses clients du conseil et de la formation à forte valeur ajoutée, en se basané
sur une approche pragmatique, fortement orientée résultat.
Première Consulting s'appuie sur un réseau de collaborateurs, d’experts et de consultants
hautement qualifiés bénéficiant d’une expérience significative dans le domaine afin de
répondre efficacement aux besoins des clients.
En effet, les clients attendent de la société des solutions opérationnelles et pragmatiques pour
aller droit au but plutôt que des théories sans résultats.
Parmi les activités de cette société nous pouvons citer :
Mise en place des systèmes de Management de la qualité suivant les normes et les référentiels
ISO 9001 - ISO 14001 - OHSAS 18001 - ISO/TS 16949 - - ISO 17025 - ISO 17020.
 Optimisation de système de management de la qualité, environnement, santé et sécurité
au travail existant.
 Diagnostic de mise à niveau, conseil à la préparation des dossiers, accompagnement dans
la réalisation des dossiers de prise en charge…etc.
 Externalisation de certaines tâches du RMQ pour les entreprises qui le souhaitent.
 Assistance à l’étalonnage et à la vérification des ECME.
 Conduite d’audit interne, seconde et tierce partie.
 Identification des besoins en compétences.
 Réalisation de la formation en inter et intra entreprise.
 Evaluation des formations.
 Veille réglementaire.
Page 5
II Présentation du projet
1. Cadre du projet
Ce projet s’inscrit dans le cadre du projet de fin d’études pour l’obtention d’un diplôme de
mastère professionnel en Modélisation, Base de données et Intégration des Systèmes à l’Ecole
Supérieure d’Economie Numérique.
Ce projet vise à développer une application web et mobile qui sera nommée « Gestion
Equipements » permettant de :
 Assurer la gestion des équipements avec ses catégories et emplacements.
 Contrôler les pièces de ces équipements avec des check-lists de vérification, et si un
contrôle contient des pannes, nous sortirons une action comme une intervention pour
résoudre les problèmes.
 Assurer la gestion des actions de réparation en cas d'un équipement en panne.
 Après la réalisation du contrôle nous devons gérer la mise à jour de calendrier du
programme d’intervention.
2. Etude de l’existant
L’étude de l’existant est une étape primordiale qui permet de définir les forces et les
faiblesses d’un produit afin de déterminer les besoins du client, et de les prendre en
considération lors de la conception et la réalisation de notre application.
2.1.Description de l’existant
La gestion des équipements se fait actuellement d’une façon traditionnelle, manuelle et aucun
traitement ne se fait avec un logiciel ce qui provoque un certain nombre de problèmes.
La gestion des équipements est basée sur des supports papier. Lors de la réception
d’équipements on prépare un dossier pour chaque équipement, les dossiers seront classés
selon les noms des équipements .Chaque équipement aura sa fiche (nom, type, marque, date
mise en service …).
Page 6
Le travail se déroule de la manière suivante :
1. Créer des check-lists à l'aide du manuel technique pour chaque équipement
2. Réaliser des contrôles sur les équipements en utilisant les fiches check-list, cette
opération peur être journalière, mensuelle ou annuelle.
3. Après la réalisation du contrôle, on doit gérer la mise à jour du calendrier du programme
de contrôle pour chaque équipement.
4. Déclenchement d’une action corrective après une défaillance totale ou partielle d’un
équipement ou après détection d’une panne dans l’opération du contrôle.
2.2.Critique de l’existant
 Aucun ficher ne regroupe tous les équipements ce qui provoquent une difficulté dans la
recherche et l’accès aux équipements et le risque de perte d’informations.
 Il existe des nombreux fichiers manuels et des documents répétitifs.
 Insuffisance des informations disponibles pour la gestion des contrôles.
 La redondance des check-lists, chaque équipement à une check-list.
 Problèmes de rentabilités et de qualités.
 Manque de sécurité de l’information et des données.
3. Solution proposée
L'étude de l’existant et les besoins de la société ont montré beaucoup des problèmes voir des
anomalies donc on nous proposons une solution qui pourra se traduire par le développement
d’une application web et mobile pour la gestion des équipements, la gestion des contrôles et la
gestion des actions d’intervention.
Cette application a pour objectif de :
 Faciliter la recherche et l’accès aux documents avec l’outil informatique.
 Annuler les documents répétitifs et éliminer la redondance des check-lists.
 Simplification du travail.
 Amélioration de la fiabilité et de la sécurité des données.
 Minimisation des supports papiers utilisés.
 Garantie une interactivité entre les contrôles et les actions corrective.
 Optimisation du temps de réponse de l’application
Page 7
III Méthodologie adoptée
Le bon choix de la méthodologie conduit à la bonne réalisation du projet, plusieurs méthodes
de conception existent : l'approche traditionnelle en cascade, et différentes approches d'agile
comme principalement Programming (XP), Scrum et autres.
Pour la réalisation du notre application, nous avons adopté pour la méthodologie agile.
1. Méthodes agiles
Une méthode Agile est une approche itérative et collaborative, capable de prendre en compte
les besoins initiaux du client et ceux liés aux évolutions.
La méthode Agile se base sur un cycle de développement qui porte le client au centre pour
l’impliquer dans la réalisation du début à la fin du projet. Cette implication permet à l’équipe
d’obtenir un feedback régulier afin d’appliquer directement les changements nécessaires.
Grâce à la méthode agile le demandeur obtient une meilleure visibilité de la gestion des
travaux qu’avec une méthode classique. Cette méthode vise à accélérer le développement
d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la
durée de sa création. [1]
2. Méthode agile adoptée: Scrum
Pour mener à bien notre projet et de garantir le bon déroulement des différentes phases, nous
avons adopté Scrum comme une méthodologie de gestion de projet.
Aujourd’hui « Scrum » est la méthode agile la plus populaire. Ce terme signifie « mêlée » au
rugby. La méthode scrum s’appuie sur des « sprints » qui sont des espaces temps assez courts
pouvant aller de quelques heures jusqu’à un mois. Généralement et de préférence un sprint
s’étend sur deux semaines. À la fin de chaque sprint, l’équipe présente ce qu’elle a ajouté au
produit.
Page 8
Figure 2: La méthode scrum
Scrum regroupe trois acteurs :
 Le Product Owner (ou « Directeur de produit ») : il communique les objectifs premiers
des clients et utilisateurs finaux, coordonne l’implication des utilisateurs et des parties
prenantes, et se coordonne lui-même avec les autres product owners pour assurer une
cohérence.
 Le Scrum Master : membre de l’équipe, il a pour but d’optimiser la capacité de
production de l’équipe. Pour se faire, le scrum master aide l’équipe à travailler de façon
autonome tout en s’améliorant d’avantage.
 L’équipe opérationnelle (qui regroupe idéalement moins de dix personnes) : la
particularité d’une équipe scrum est qu’elle est dépourvue de toute hiérarchie interne. Une
équipe scrum est auto-organisée.
D’autres termes sont à connaître pour comprendre la méthode scrum:
 Le product backlog (carnet du produit) : ce document contient les exigences initiales
dressées puis hiérarchisées avec le client en début de projet. Néanmoins il va évoluer tout
au long de la durée du projet, en fonction des divers besoins du client.
 Le sprint backlog (carnet de sprint) : en chaque début de sprint, l’équipe définit un but.
Puis lors de la réunion de sprint, l’équipe de développement choisit les éléments du
carnet à réaliser. L’ensemble de ces éléments constitue alors le sprint backlog.
 User story : ce terme désigne les fonctionnalités décrites par le client.
 La mêlée (scrum) : c’est une réunion d’avancement organisée de manière quotidienne
durant le sprint. [2]
Page 9
Conclusion
Ce chapitre a été le point de départ du rapport pour la réalisation de notre projet et le chapitre
suivant sera consacré pour la planification générale du projet.
Page 9
Chapitre 2 :
Planification générale du projet
Page 10
Chapitre 2: Planification générale du projet
Introduction
Ce chapitre sera consacré à la réalisation de la première phase de la méthodologie Scrum
« sprint 0 » qui présente les fonctionnalités de base du projet, le diagramme des cas
d’utilisation global, et le Product Backlog qui va nous permettre de planifier les releases.
Analyse des besoins.
I. Analyse des besoins
Cette section est destinée à la spécification des besoins fonctionnels et non fonctionnels de la
solution ainsi que l’identification des acteurs.
1. Identification des acteurs
Administrateur : Qui s’occupera de gérer son profil, la gestion des super utilisateurs, la
gestion des sites et consulter les statistiques.
Super Utilisateur : A le droit de créer des nouveaux membres et de définir les rôles et les
privilèges des membres du système.
Technicien : Son rôle consiste à assurer la gestion des équipements, les check-lists de
vérification, les locaux, les fournisseurs des équipements ainsi que la consultation de la
planification, les contrôles, les actions réalisées sur les équipements.
Contrôleur : Il a pour rôle de planifier les contrôles, assurer la gestion des actions, la gestion
des contrôles et la consultation la liste des équipements.
Page 11
2. Les besoins fonctionnels
Gestion des catégories équipements
Cette fonctionnalité permettre au technicien de :
 Ajouter, modifier, supprimer des catégories.
Gestion des check-lists de vérification des équipements
Cette fonctionnalité permettre au technicien de :
 Ajouter, modifier, supprimer des check-lists.
Gestion des locaux des équipements
Cette fonctionnalité permettre au technicien de :
 Ajouter, modifier, supprimer des locaux.
Gestion des fournisseurs des équipements
 Cette fonctionnalité permettre au technicien de :
 Ajouter, modifier, supprimer des fournisseurs.
Gestion des équipements
Cette fonctionnalité permettre au technicien de :
 Ajouter, modifier, supprimer des équipements.
 Consulter la liste des équipements.
Planification des contrôles
Cette fonctionnalité permettre au contrôleur de :
 Ajouter modifier supprimer une date de contrôle.
 Consulter les plannings.
Gestion des actions
Cette fonctionnalité permettre au contrôleur de :
 Ajouter, modifier, supprimer des actions.
Page 12
 Consulter la liste des actions.
Gestion des Contrôles
Cette fonctionnalité permettre au contrôleur de :
 Ajouter, modifier, supprimer des contrôles.
 Consulter la liste des contrôles.
Gestion des membres.
Cette fonctionnalité permettre au super utilisateur de :
 Ajouter, modifier et supprimer des membres.
Gestion des super utilisateurs.
Cette fonctionnalité permettre à l’administrateur de :
 Ajouter, modifier et supprimer des super utilisateurs.
Gestion profil Administrateur.
Cette fonctionnalité permettre à l’administrateur de :
 Consulter et modifier son profil.
Gestion des sites.
Cette fonctionnalité permettre à l’administrateur de :
 Ajouter, modifier et supprimer des sites.
Consulter les statistiques
Cette fonctionnalité permettre à l’administrateur de :
 Consulter les statistiques.
Page 13
3. Les besoins non fonctionnels
Rapidité : Nos deux applications doivent répondre aux besoins des utilisateurs dans le plus
court délai.
Fiabilité : Bon fonctionnement des deux applications sans détection de défaillance.
L’extensibilité : Les deux applications devront être extensibles, c'est-à dire qu'il pourra y
avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.
La sécurité : les informations ne devront pas être accessibles à tout le monde.
La performance : le système doit réagir dans un délai précis, quel que soit l'action de
l'utilisateur.
4. Langage de modélisation adopté
Le langage de modélisation adopté pour notre projet est l’UML
UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le traduit par «
Langage de modélisation unifié ». La notation UML est un langage visuel constitué d’un
ensemble de schémas, appelés des diagrammes, qui donnent chacun une vision différente du
projet à traiter.
UML nous fournit donc des diagrammes pour représenter le logiciel
à développer : son fonctionnement, sa mise en route, les actions
susceptibles d’être effectuées par le logiciel, etc. [2] Figure 3: Logo UML
5. Architecture logiciel
Dans cette partie nous expliquons le choix de l’architecture logicielle du notre travail qui se
base sur le modèle MVC.
L’architecture MVC est l’une des architectures logicielles les plus utilisées pour les
applications Web, elle se compose de 3 modules :
Page 14
Figure 4: Architecture MVC
Modèle : noyau de l’application qui gère les données, permet de récupérer les informations de
la base de données, de les organiser pour qu’elles puissent ensuite être traitées par le
contrôleur.
Vue : composant graphique de l’interface qui permet de présenter les données du modèle à
l’utilisateur.
Contrôleur : composant responsable des prises de décision, gère la logique du code qui prend
des décisions, il est l’intermédiaire entre le modèle et la vue. [3]
II. Diagramme des cas d’utilisation global
Pour présenter les fonctionnalités de notre système de manière formelle, nous utilisons le
diagramme de cas d’utilisation du langage de modélisation UML.
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement,
les cas d'utilisation sont plus appropriés. Un cas d'utilisation représente une unité discrète
d'interaction entre un utilisateur (humain ou machine) et un système. [4]
La figure 4 représente le diagramme du cas d’utilisation général de notre application. Ce
diagramme illustre les différents acteurs ainsi que les cas d’utilisations affectés à chacun de
ces acteurs.
Page 15
Figure 5: Diagramme des cas d’utilisation global
Page 16
III. Prototypage des interfaces de l’application
nous avons créé des maquettes pour les interfaces de l’application web et l’application
mobile, pour avoir une idée et une vision graphique et ergonomique dès le début avec l’outil
de prototypage « Balsamiq»
Figure 6: Logo d'outil balsamiq
Nous présentons ci-dessous quelques maquettes prévisionnelles des interfaces de l’application
Prototypage de l'interface d'authentification
Figure 7: Interface de l’authentification
Prototypage de l'interface Gestion des équipements
Figure 8: Interface de la Gestion des équipements
Page 17
Prototypage de l'interface de la gestion des actions
Figure 9: de la gestion des actions
Prototypage de l'interface de la gestion des contrôles
Figure 10: Interface de la gestion des contrôles
Prototypage des interfaces de l’application mobile
Figure 11: Interface Ajout d’action Figure 12: Interface Ajout du contrôle
Page 18
IV. Adaptation du cycle de développement Scrum au projet
1. Répartition des rôles
En suivant la méthodologie Scrum, notre équipe de projet sera réparti en trois rôles :
2. Product Backlog
Le tableau ci-dessous représente le backlog produit. Il présente les fonctionnalités de notre
application.
Dans ce tableau, les fonctionnalités sont classées selon des critères de classification :
La priorité : Représente le degré d’importance entre les cas d’utilisation. Elle dépend du
contexte de différentes fonctionnalités du système
Nous pouvons classer les cas d’utilisation selon leur rang de priorité par rapport au nombre
total de cas d’utilisation.
Il s’agit d’une affectation des priorités de manière relative. Notre choix des priorités s’est basé
sur la dépendance entre les fonctionnalités de l’application. Nous donnons à un cas
d’utilisation A une plus grande priorité qu’un cas d’utilisation B.
L’effort : représente l’estimation initiale de la quantité de travail nécessaire pour la
réalisation d’un cas d’utilisation. Elle est calculée en nombre de jours/homme.
Product Owner
• Première Consulting
Scrum Master
• Amani Bouaziz
L'équipe de développement
• Raoua Bennasr
Page 19
Thème Fonctionnalités Description Effort Priorité
Gestion
catégorie
équipements
Ajouter une catégorie
En tant que Technicien j’ai le droit
d’ajouter une catégorie.
1 1
Modifier une catégorie
En tant que Technicien j’ai le droit
de modifier une catégorie.
1 2
Supprimer une catégorie
En tant que Technicien j’ai le droit
de supprimer une catégorie.
1 3
Gestion Locaux
équipements
Ajouter un local
En tant que Technicien j’ai le droit
d’ajouter un local.
1 4
Modifier un local
En tant que Technicien j’ai le droit
de modifier un local.
1 5
Supprimer un local
En tant que Technicien j’ai le droit
de supprimer un local.
1 6
Gestion des
fournisseurs
équipements
Ajouter un fournisseur
En tant que Technicien, j’ai le droit
d’ajouter un fournisseur.
1 7
Modifier un fournisseur
En tant que Contrôleur, j’ai le droit
de modifier un fournisseur.
1 8
Supprimer un fournisseur
En tant que Technicien, j’ai le droit
de supprimer un fournisseur.
1 9
Gestion
des équipements
Ajouter un équipement
En tant que Technicien j’ai le droit
d’ajouter un équipement.
2 10
Modifier un équipement
En tant que Contrôleur, j’ai le droit
de modifier un équipement.
2 11
Supprimer un équipement
En tant que Technicien, j’ai le droit
de supprimer un équipement.
1 12
Lister les équipements
En tant que Contrôleur j’ai le droit
de consulter les équipements.
1 13
Gestion
Check listes
équipements
Ajouter une check-list
En tant que Technicien, j’ai le droit
d’ajouter une check-list.
3 14
Modifier une check-list
En tant que Technicien, j’ai le droit
de modifier une check-list.
2 15
Supprimer une check-list
En tant que Technicien j’ai le droit
de supprimer une check-list.
1 16
Page 20
Gestion
des Actions
Ajouter une action
En tant que Contrôleur j’ai le droit
d’ajouter une action.
2 20
Modifier une action
En tant que Contrôleur j’ai le droit
de modifier une action.
2 21
Supprimer une action
En tant que Contrôleur j’ai le droit
de supprimer une action.
1 22
Lister les actions
En tant que Technicien j’ai le droit
de consulter les actions.
1 23
Gestion
des contrôles
Ajouter un contrôle
En tant que Contrôleur j’ai le droit
d’ajouter un contrôle.
3 24
Modifier un contrôle
En tant que Contrôleur j’ai le droit
de modifier un contrôle.
2 25
Supprimer un contrôle
En tant que Contrôleur j’ai le droit
de supprimer un contrôle.
1 26
Lister les contrôles
En tant que Technicien j’ai le droit
de consulter les contrôles.
1 27
Planification
des contrôles
Ajouter un planning du
calendrier
En tant que Contrôleur j’ai le droit
d’ajouter un planning.
3 28
Modifier un planning du
calendrier
En tant que Contrôleur j’ai le droit
de modifier un planning.
2 29
Supprimer un planning du
calendrier
En tant que Contrôleur j’ai le droit
de supprimer un planning.
1 30
Consulter calendrier des
plannings
En tant que Technicien j’ai le droit
de calendrier des plannings.
2 31
Gestion profil
administrateur
Consulter profil
En tant qu’administrateur j’ai le
droit de consulter mon profil
1 32
Modifier profil
En tant qu’administrateur j’ai le
droit de modifier mon profil
2 33
Authentification S’authentifier
En tant qu’administrateur je dois
m’authentifier pour accéder a
l’application
1 34
Gestion des sites Ajouter un site
En tant qu’administrateur j’ai le
droit d’ajouter un site.
1 35
Page 21
Table 1: Backlog du produit
Modifier un site
En tant qu’administrateur j’ai le
droit de modifier un site.
1 36
Supprimer un site
En tant qu’administrateur j’ai le
droit de supprimer un site.
1 37
Gestion des
super
Utilisateurs
Ajouter un super
utilisateur
En tant qu’administrateur j’ai le
droit d’ajouter un super utilisateur.
2 38
Modifier un super
utilisateur
En tant qu’administrateur j’ai le
droit de modifier super-utilisateur.
2 39
Supprimer un super
utilisateur
En tant que super utilisateur j’ai le
droit de supprimer un membre.
1 40
Gestion
des membres
Ajouter un membre
En tant que super utilisateur j’ai le
droit d’ajouter un membre.
1 17
Modifier un membre
En tant que super utilisateur, j’ai
le droit de modifier un membre.
1 18
Supprimer un membre
En tant que super utilisateur, j’ai
le droit de supprimer un membre.
1 19
Consulter les
statistiques Consulter les Statistique
En tant qu’administrateur, j’ai le de
consulter les statistiques.
3 41
Page 22
3. Planification des sprints du projet
Le but de la planification des sprints du projet est de préparer le planning de travail et
d’identifier le Backlog des sprints.
La planification des sprints est schématisée dans le graphique suivant :
Conclusion
Durant ce chapitre, nous avons identifié les besoins fonctionnels et les besoins non
fonctionnels, Nous avons également réalisé les maquettes prévisionnelles, le backlog du
produit ainsi que la répartition des sprints à réaliser.
Dans le chapitre suivant nous allons développer le release 1.
RELEASE 1
SPRINT 1
Gestion catégories
Gestion locaux
Gestion fournisseurs
Gestion check-lists
Gestion équipements
De 01-04 à 21/04
Gestion membres
Gestion Actions
Gestion Contrôles
Planification
De 22-04 à 12-05
RELEASE 2
Gestion sites
Gestion super
utilisateurs
De 13-05 à 19-05
Gestion profil
administrateur
Authentification
Consulter des
Statistiques
De 20-05 à 26-05
SPRINT 2 SPRINT 1 SPRINT 2
Page 23
Chapitre 3 :
Release 1 du projet
Page 24
Chapitre 3 : Release 1 du projet
Introduction
Une fois l’analyse des besoins et la spécification des exigences du projet sont élaborées, nous
allons donc dans ce chapitre présenter notre premier release qui comporte 2 sprints dont
chacun a une période de 3 semaines.
I. Premier Sprint
Le sprint est une période qui dure entre une et quatre semaines, au bout de cette période
l’équipe doit réaliser un incrément de produit livrable. Un nouveau sprint démarre lorsque le
précèdent est terminée.
Le tableau ci-dessous présente le backlog de notre premier sprint
Table 2: Backlog du premier sprint (release 1)
Thème Fonctionnalités Estimation
Gestion catégorie équipements
Ajouter une catégorie 1
Modifier une catégorie 1
Supprimer une catégorie 1
Gestion Locaux équipements
Ajouter un local 1
Modifier un local 1
Supprimer un local 1
Gestion des fournisseurs
équipements
Ajouter un fournisseur 1
Modifier un fournisseur 1
Supprimer un fournisseur 1
Gestion
des équipements
Ajouter un équipement 2
Modifier un équipement 2
Supprimer un équipement 1
Lister les équipements 1
Gestion
Check listes équipements
Ajouter une check-list 3
Modifier une check-list 2
Supprimer une check-list 1
Page 25
1. Spécification fonctionnelle
La spécification fonctionnelle se traduit par un diagramme de cas d’utilisation global du sprint
et des diagrammes de cas d’utilisation raffinés ainsi que quelques descriptions textuelle.
1.1.Diagramme de cas d’utilisation du sprint 1
La figure 12 ci-dessous illustre le diagramme des cas d’utilisation du premier sprint.
Figure 13: Diagramme de cas d'utilisation global du Sprint 1
Page 26
1.2.Raffinement des cas d’utilisation du sprint 1
La figure 13 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation
du premier sprint :
Figure 14: Diagramme de cas d'utilisation détaillé du Sprint 1
Page 27
1.3.Description textuelle des cas d’utilisation
Nous traitons uniquement les cas d’utilisation :
 « Ajouter équipement » puisqu’il est similaire aux cas « Ajouter catégorie », «Ajouter
check-list », « Ajouter local », « Ajouter fournisseur ».
 « Modifier équipement » puisqu’il est similaire aux cas « Modifier catégorie», «Modifier
check-list», « Modifier local », «Modifier fournisseur ».
 « Supprimer équipement » puisqu’il est similaire aux cas « Supprimer catégorie»,
«Supprimer check-list », « Supprimer local » », «Supprimer fournisseur ».
 « Consulter la liste des équipements ».
Nous détaillons à travers les tableaux descriptifs suivant, les cas d’utilisation « ajouter
équipement « modifier équipement », « supprimer équipement » et « consulter la liste des
équipements »
 Description textuelle du cas « Ajouter équipement »
Cas d’utilisation Ajouter équipement
Acteurs Technicien
Pré-condition Acteur authentifié.
Post-condition Equipement ajouté.
Scénario principal
1. Le technicien demande le formulaire d’ajout.
2. Le système affiche le formulaire.
3. Le technicien remplit les champs et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre le nouvel équipement.
Scénario alternatif
Le technicien saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 3: Description textuelle du cas d’utilisation « Ajouter équipement»
Page 28
 Description textuelle du cas « Modifier équipement »
Cas d’utilisation Modifier équipement
Acteurs Technicien
Pré-condition Acteur authentifié.
Post-condition Equipement modifié.
Scénario principal
1. Le technicien choisit l’équipement à modifier.
2. Le système affiche le formulaire de modification.
3. Le technicien modifie les informations de l’équipement et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre la modification de l’équipement.
6. Le système redirige le technicien vers la liste des équipements.
Scénario alternatif
Le technicien saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 4: Description textuelle du cas d’utilisation « Modifier équipement»
 Description textuelle du cas « Supprimer équipement »
Cas d’utilisation Supprimer équipement
Acteurs Technicien
Pré-condition Acteur authentifié.
Post-condition Equipement supprimé.
Scénario principal
1. Le technicien choisit l’équipement à supprimer.
2. Le système affiche un message de confirmation.
3. Le technicien valide son choix
4. Le système supprime l’équipement.
5. Le système redirige le technicien vers la liste des équipements.
Scénario alternatif
Le technicien annule son choix
Le système annule la suppression
Table 5: Description textuelle du cas d’utilisation « Supprimer équipement»
Page 29
 Description textuelle du cas « Consulter la liste des équipements »
Cas d’utilisation Consulter la liste des équipements
Acteurs Contrôleur
Pré-condition Acteur authentifié.
Post-condition Liste des équipements affichés.
Scénario principal
1. Le technicien demande la liste des équipements.
2. Le système affiche la liste des équipements.
Table 6: Description textuelle du cas d’utilisation « Consulter la liste des équipements»
2. Conception
La conception est la deuxième partie dans un sprint. Elle se traduit par les diagrammes de
séquence système, de classes participantes, de séquence détaillée et le diagramme de classe du
premier sprint.
2.1. Diagrammes de séquence système
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling
Language. [5]
Nous nous intéressons dans cette partie à présenter les diagrammes de séquence système du
cas d’utilisation « Ajouter équipement » , « Modifier équipement », « Supprimer
équipements» et « consulter la liste des équipements ».
Page 30
 Diagramme de séquence système du cas « ajouter équipement»
La figure15 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Ajouter équipement » décrit par le tableau 3.
Figure 15: Diagramme de séquence système du cas d'utilisation « Ajouter équipement»
 Diagramme de séquence système du cas « Modifier équipement»
La figure 16 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Modifier équipement » décrit par le tableau 4.
Figure 16: Diagramme de séquence système du cas d'utilisation « Modifier équipement»
Page 31
 Diagramme de séquence système du cas « Supprimer équipement»
La figure 17 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Supprimer équipement » décrit par le tableau 5.
Figure 17: Diagramme de séquence système du cas d'utilisation « Supprimer équipement»
 Diagramme de séquence système du cas « Consulter liste des équipements»
La figure 18 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Consulter liste des équipements » décrit par le tableau 6.
Figure 18: Diagramme de séquence système du cas d'utilisation « Consulter liste des équipements»
Page 32
2.2. Diagrammes des classes participantes
Le diagramme de classes participantes est particulièrement important puisqu'il effectue la
jonction entre, d'une part, les cas d'utilisation le modèle du domaine et la maquette et d'autre
part, les diagrammes de conception logicielle que sont les diagrammes d'interaction et le
diagramme de classes de conception. [6]
Dans Notre diagramme des classes participantes, nous avons distingué trois stéréotypes de
classes qui sont :
Classe dialogue : Représente les interfaces IHM de l’application (interface).
Classe contrôle : classe application contenant les actions à effectuer (contrôle).
Classe entité : classe métier contenant les données de chaque modèle (entité).
Dans ce cas, nous présentons quelques diagrammes des classes participantes et nous avons
spécifié les classes dialogues par UI « User Interface » et les classes « contrôle » par C.
 Diagramme des classes participantes du cas d’utilisation « Gestion catégorie
équipement»
La figure ci-dessous décrit le diagramme de la classe participante « Gestion catégorie
équipement ».
Figure 19: Diagramme des classes participantes du cas d’utilisation« Gestion Catégorie équipement»
Page 33
 Diagramme des classes participantes du cas d’utilisation « Gestion équipement»
La figure ci-dessous décrit le diagramme de la classe participante « Gestion équipement ».
Figure 20: Diagramme des classes participantes du cas d’utilisation« Gestion équipement»
2.3. Diagrammes de séquences détaillés
Le diagramme de séquence détaillé est le même que le diagramme de séquence système, sauf
que, nous allons répartir le système à des composants d’interaction pour mieux comprendre le
scénario.
Nous choisissons de présenter les diagrammes de séquence système détaillé « Ajouter
équipement » et « Consulter liste des équipements».
 Diagramme de séquence détaillé du cas d'utilisation « Ajouter équipement »
La figure 21 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Ajouter équipement » illustré par la figure 15.
Page 34
Figure 21 : Diagramme de séquences détaillé « Ajouter équipement »
 Diagramme de séquence détaillé du cas d'utilisation «Consulter la liste des
équipements »
La figure 22 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Consulter la liste des équipements »illustré par la figure
16
Figure 22: Diagramme de séquences détaillé « Consulter la liste des équipements »
Page 35
2.4. Diagramme des classes de sprint 1
La figure 23 représente le diagramme de classe du notre premier sprint. Ce diagramme illustre
Les différentes classes constituant le système, leurs attributs, leurs méthodes ainsi que les
associations entre elles.
Figure 23: Diagramme de classe du sprint 1
3. Codage
Dans cette partie, nous allons présenter le schéma de la base de données de notre sprint
Page 36
Dans ce qui suit, nous présentons le schéma de la base de données.
Figure 24: Table «équipement »
Figure 25: Table «catégorie »
Figure 26: Table «CheckListe »
Page 37
Figure 27: Table «équipement »
Figure 28: Table «local »
4. Les interfaces
Nous allons présenter dans ce qui suit, les imprimes-écran des quelques interfaces réalisées
dans le sprint 1 du release 1.
 Interface « Gestion équipements »
Figure 29: Interface « Gestion équipements »
Page 38
 Interface « Ajouter équipement »
Figure 30: Interface « Ajouter équipement »
 Interface « Modifier équipement »
Figure 31: Interface « Modifier équipement »
Page 39
 Interface « Gestion catégorie »
Figure 32: Interface « Gestion catégorie »
 Interface « Gestion Check-list »
Figure 33: Interface « Gestion Check-list »
Page 40
 Interface « Gestion fournisseur »
Figure 34: Interface « Gestion fournisseur»
 Interface « Gestion Locaux »
Figure 35: Interface « Gestion fournisseur»
Page 41
 Interface « Consulter équipements »
Figure 36: Interface « Consulter équipements»
 Interface « Consulter équipements » de l’application mobile
Figure 37: Interface « équipements»
Page 42
 Interface « rechercher un équipement par un QRCode
Figure 38: Interface « Recherche un équipement par QRCode»
 Interface « Consulter un seul équipement «
Figure 39: Interface « Consulter un seul équipement»
Page 43
II. Deuxième Sprint
Notre deuxième sprint s’intéresse à l’ensemble des fonctionnalités de « Gestion des
membres », « Gestion des actions », « Gestion des Contrôle s» et «Planification».
Par la suite, le backlog du sprint 2 de la release 1 est illustré par le tableau suivant :
Table 7: Backlog du deuxième sprint (release 1)
1. Spécification fonctionnelle
En respectant la même démarche adoptée au cours du premier sprint, la spécification
fonctionnelle du deuxième sprint 2 se traduit par :
La définition du diagramme de cas d’utilisation global du sprint, les diagrammes de cas
d’utilisation raffinés et leurs descriptions textuelles.
Thème Fonctionnalités Estimation
Gestion des Actions
Ajouter une action 2
Modifier une action 2
Supprimer une action 1
Lister les actions 1
Gestion des contrôles
Ajouter un contrôle 3
Modifier un contrôle 2
Supprimer un contrôle 1
Lister les contrôles 1
Planification des
contrôles
Ajouter un planning du calendrier 3
Modifier un planning du calendrier 2
Supprimer un planning du
calendrier
1
Consulter calendrier des
plannings
2
Gestion des membres
Ajouter un membre 1
Modifier un membre 1
Supprimer un membre 1
Page 44
1.1. Diagramme de cas d’utilisation du sprint 2
La figure 40 ci-dessous illustre le diagramme des cas d’utilisation du deuxième sprint.
Figure 40: diagramme des cas d’utilisation du deuxième sprint
Page 45
1.2.Raffinement des cas d’utilisation du sprint 2
La figure 41 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation
du deuxième sprint :
Figure 41: diagramme des cas d’utilisation détaillé du deuxième sprint
Page 46
1.3.Description textuelle des cas d’utilisation
Nous traitons uniquement les cas d’utilisation :
 « Ajouter Action», « Modifier Action », « Supprimer Action » puis qu’il sont similaire
aux cas d’utilisations de la fonctionnalité « Gestion membre ».
 « Ajouter Contrôle » de la fonctionnalité « Gestion Contrôle ».
 « Ajouter planning » de la fonctionnalité « planification des contrôle».
 « Consulter les Actions » puisqu’il est similaire aux cas d’utilisations « Consulter les
Contrôles », «Consulter Planification».
Nous détaillons à travers les tableaux descriptifs suivant, les cas d’utilisation « Ajouter
Action », « Modifier Action », « Supprimer Action », « Ajouter Contrôle », « Ajouter
planning » et « Consulter les Actions »
 Description textuelle du cas « Ajouter Action »
Cas d’utilisation Ajouter Action
Acteurs Contrôleur
Pré-condition Acteur authentifié.
Post-condition Action ajoutée.
Scénario principal
1. Le Contrôleur demande le formulaire d’ajout.
2. Le système affiche le formulaire.
3. Le Contrôleur remplit les champs et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre la nouvelle Action.
Scénario alternatif
Le Contrôleur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 8: Description textuelle du cas d’utilisation « Ajouter Action»
Page 47
 Description textuelle du cas « Modifier Action»
Cas d’utilisation Modifier Action
Acteurs Contrôleur
Pré-condition Acteur authentifié.
Post-condition Action modifiée.
Scénario principal
1. Le contrôleur choisit l’action à modifier.
2. Le système affiche le formulaire de modification.
3. Le contrôleur modifie les informations de l’action et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre la modification de l’action.
6. Le système redirige le contrôleur vers la liste des actions.
Scénario alternatif
Le contrôleur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 9: Description textuelle du cas d’utilisation « Modifier action»
 Description textuelle du cas « Supprimer action »
Cas d’utilisation Supprimer action
Acteurs Contrôleur
Pré-condition Acteur authentifié.
Post-condition action supprimée.
Scénario principal
1. Le contrôleur choisit l’action à supprimer.
2. Le système affiche un message de confirmation.
3. Le contrôleur valide son choix
4. Le système supprime l’action.
5. Le système redirige le contrôleur vers la liste des actions.
Scénario alternatif
Le contrôleur annule son choix
Le système annule la suppression
Table 10: Description textuelle du cas d’utilisation « Supprimer action»
Page 48
 Description textuelle du cas « Ajouter Contrôle »
Cas d’utilisation Ajouter Contrôle
Acteurs Contrôleur
Pré-condition Acteur authentifié.
Post-condition Contrôle ajouté.
Scénario principal
1. Le Contrôleur demande le formulaire d’ajout.
2. Le système affiche le formulaire.
3. Le Contrôleur remplit les champs et contrôler les éléments de
l’équipement avec la check liste puis valide.
4. Le système vérifie les données saisies.
5. Le système enregistre le nouveau contrôle.
Scénario alternatif
 Si le contrôle avec la check liste de vérification inferieur à 50%
le contrôleur cocher bouton « équipement non valide »
Le système affiche un pop-up du formulaire d’ajout action avec les
pannes trouvées dans le contrôle.
 Le Contrôleur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 11: Description textuelle du cas d’utilisation « Ajouter Contrôle»
Page 49
 Description textuelle du cas « Ajouter Planning »
Cas d’utilisation Ajouter Planning
Acteurs Contrôleur
Pré-condition
Acteur authentifié.
Post-condition
Planning ajouté.
Scénario principal
1. Le Contrôleur demande le calendrier.
2. Le Contrôleur choisir une date de contrôle.
3. Le système affiche le formulaire.
4. Le Contrôleur remplit les champs puis valide.
5. Le système vérifie les données saisies.
6. Le système enregistre le nouveau planning.
Scénario alternatif
 Le Contrôleur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 12: Description textuelle du cas d’utilisation « Ajouter Planning»
 Description textuelle du cas « Consulter les actions »
Cas d’utilisation Consulter les Actions
Acteurs Technicien
Pré-condition Acteur authentifié.
Post-condition Liste actions affichés.
Scénario principal
1. Le contrôleur demande la liste des actions.
2. Le système affiche la liste des actions.
Table 13: Description textuelle du cas d’utilisation « Consulter les actions»
Page 50
2. Conception
Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas
d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et
le diagramme de classe du deuxième sprint.
2.1. Diagrammes de séquence système
A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes
de séquences systèmes « Ajouter action », « Modifier action », « Supprimer action »,
« Ajouter Contrôle », « Ajouter planning » et « Consulter les actions »
 Diagramme de séquence système du cas «Ajouter action»
La figure 42 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Ajouter action » décrit par le tableau 8.
Figure 42: Diagramme de séquence système du cas d'utilisation « Ajouter action»
Page 51
 Diagramme de séquence système du cas « Modifier action»
La figure 43 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Modifier action » décrit par le tableau 9.
Figure 43: Diagramme de séquence système du cas d'utilisation « Modifier action»
 Diagramme de séquence système du cas « Supprimer action»
La figure 44 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Supprimer action » décrit par le tableau 10.
Page 52
Figure 44: Diagramme de séquence système du cas d'utilisation « Supprimer action»
 Diagramme de séquence système du cas « Consulter les actions»
La figure 45 illustre le diagramme de séquence système correspondant au cas d’utilisation «
Consulter les actions » décrit par le tableau 13.
Figure 45: Diagramme de séquence système du cas d'utilisation « Consulter les actions»
Page 53
 Diagramme de séquence système du cas « Ajouter Contrôle»
La figure 46 illustre le diagramme de séquence système correspondant au cas
d’utilisation « Ajouter contrôle » décrit par le tableau 11.
Figure 46: Diagramme de séquence système du cas d'utilisation « Ajouter Contrôles»
Page 54
 Diagramme de séquence système du cas « Ajouter Planning»
La figure 47 illustre le diagramme de séquence système correspondant au cas d’utilisation
« Ajouter Planning » décrit par le tableau 12.
Figure 47: Diagramme de séquence système du cas d'utilisation « Ajouter Planning»
Page 55
2.2. Diagrammes des classes participantes
 Diagrammes de classes participantes «Gestion actions »
Figure 48: Diagramme des classes participantes du cas d’utilisation« Gestion actions»
 Diagrammes de classes participantes «Gestion Contrôle »
Figure 49: Diagramme des classes participantes du cas d’utilisation« Gestion Contrôle»
Page 56
 Diagrammes de classes participantes «Planification»
Figure 50: Diagramme des classes participantes du cas d’utilisation« Planification»
2.3. Diagrammes de séquences détaillés
Pour le sprint 2, Nous choisissons de présenter les diagrammes de séquence système
détaillé de cas d’utilisation «Ajouter action » «consulter les actions »
 Diagramme de séquence détaillé du cas d'utilisation « Ajouter action »
La figure 51 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Ajouter action» illustré par la figure 42.
Page 57
Figure 51: Diagramme de séquences détaillé « Ajouter action »
 Diagramme de séquence détaillé du cas d'utilisation « Consulter les actions»
La figure 52 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Consulter les actions » illustré par la figure 43.
Figure 52: Diagramme de séquences détaillé « Consulter les actions »
Page 58
2.4. Diagramme des classes de sprint 2
La figure 53 représente le diagramme de classe du sprint 2 du release 1.
 Pour la classe planification nous avons un champ couleur dédié à la spécification de la
date de contrôle dans le calendrier de l’interface de l’application.
 Dans notre diagramme de classe nous avons une classe catégorie reliée avec la classe
équipement. Une catégorie à un numéro de série et chaque équipement est identifié par
une référence unique.
Figure 53: Diagramme de classe du sprint 2
Page 59
3. Codage
Les figures ci-dessous représentent le schéma de la base de données de ce sprint.
Figure 54 : table Contrôle
Figure 55 : table Action
Page 60
Figure 56 : table Planification
Figure 57 : table Membre
4. Les interfaces
Nous passons à présenter quelques interfaces réalisées lors du notre deuxième sprint release 1.
 Interface de l’application web
Page 61
 Interface « Gestion Contrôles »
Figure 58 : Interface Gestion Contrôles
 Interface « Ajouter Contrôle»
Figure 59 : Interface Ajouter Contrôle
Page 62
 Interface « Gestion Actions »
Figure 60 : Interface Gestion Actions
 Interface « Ajouter Action »
Figure 61: Interface Ajouter Action
Page 63
 Interface «Planification »
Figure 62: Interface Planification
 Interface «Ajouter Planning »
Figure 63: Interface Ajouter planning
Page 64
 Interface «Consulter Actions»
Figure 64 : Interface Consulter Actions
 Interface «Consulter Contrôles»
Figure 65 : Interface Consulter Contrôles
Page 65
 Interface «Gestion Membre»
Figure 66 : Interface Gestion Membre
 Quelques Interfaces de l’application mobile
Figure 67 : Interface Ajouter Contrôle Figure 68 : Interface Liste des Contrôles
Page 66
Figure 69 : Interface Ajouter Action
Conclusion
Nous arrivons à la fin de développement de premier release qui concerne la gestion des
actions, des contrôles, des membres et planification.
Suivant le même plan de travail, nous présenterons dans le chapitre qui suit le deuxième
release de ce projet
Page 67
Chapitre 4 :
Release 2 du projet
Page 68
Chapitre 4 : Release 2 du projet
Introduction
Après avoir terminé le premier release, nous commençons maintenant à produire le deuxième
release qui définit le deuxième incrément du notre projet et qui comporte deux sprints.
I. Premier Sprint
Notre premier sprint pour la deuxième release s’intéresse à l’ensemble des fonctionnalités de
« Gestion des sites » et « Gestion des super utilisateur ».
Le tableau ci-dessous présente le backlog de notre premier sprint
Table 14: Backlog du premier sprint (release 2)
1. Spécification fonctionnelle
Nous présentons dans cette partie les diagrammes de cas d’utilisation et leurs descriptions
textuelles.
Thème Fonctionnalités Estimtion
Gestion des sites
Ajouter un site 1
Modifier un site 1
Supprimer un site 1
Gestion des super
Utilisateurs
Ajouter un super utilisateur 2
Modifier un super utilisateur 2
Supprimer un super utilisateur 1
Page 69
1.1. Diagramme de cas d’utilisation du sprint
La figure 69 ci-dessous illustre le diagramme des cas d’utilisation du sprint 1.
Figure 69: diagramme des cas d’utilisation du sprint 1
1.2.Raffinement des cas d’utilisation du sprint
La figure 70 ci-dessous illustre le diagramme des cas d’utilisation détaillé du sprint 1.
Figure 70: diagramme des cas d’utilisation détaillé du sprint 1
Page 70
1.3.Description textuelle des cas d’utilisation
Nous traitons uniquement les cas d’utilisation :
 « Ajouter Site » puisqu’il est similaire au cas « Ajouter super user».
 « Modifier Site » puisqu’il est similaire au cas « Modifier super user».
 « Supprimer Site » puisqu’il est similaire au cas « Supprimer super user».
 Description textuelle du cas « Ajouter Site »
Cas d’utilisation Ajouter Site
Acteurs Administrateur
Pré-condition Acteur authentifié.
Post-condition Site ajouté.
Scénario principal
1. L’administrateur demande le formulaire d’ajout.
2. Le système affiche le formulaire.
3. L’administrateur remplit les champs et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre le site.
Scénario alternatif
L’administrateur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 2 du scénario principal.
Table 15: Description textuelle du cas d’utilisation « Ajouter Site»
Page 71
 Description textuelle du cas « Modifier Site»
Cas d’utilisation Modifier Site
Acteurs Administrateur
Pré-condition Acteur authentifié.
Post-condition Site modifié.
Scénario principal
1. L’administrateur choisit le site à modifier.
2. Le système affiche le formulaire de modification.
3. L’administrateur modifie les informations du site et valide.
4. Le système vérifie les données saisies.
5. Le système enregistre la modification du site.
6. Le système redirige l’administrateur vers la liste des sites.
Scénario alternatif
L’administrateur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 16: Description textuelle du cas d’utilisation « Modifier site»
 Description textuelle du cas « Supprimer Site »
Cas d’utilisation Supprimer Site
Acteurs Administrateur
Pré-condition Acteur authentifié.
Post-condition site supprimé.
Scénario principal
1. L’administrateur choisit un site à supprimer.
2. Le système affiche un message de confirmation.
3. L’administrateur valide son choix
4. Le système supprime le site.
5. Le système redirige l’administrateur vers la liste des sites.
Scénario alternatif
L’administrateur annule son choix
Le système annule la suppression
Table 17: Description textuelle du cas d’utilisation « Supprimer site»
Page 72
2. Conception
Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas
d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et
le diagramme de classe du sprint 1 du release 2.
2.1. Diagrammes de séquence système
A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes
de séquences systèmes « Ajouter Site », « Modifier Site », « Supprimer Site ».
 Diagramme de séquence système du cas «Ajouter Site»
Figure 71: diagramme de séquence système du cas «Ajouter Site»
Page 73
 Diagramme de séquence système du cas «Modifier Site»
Figure 72: diagramme de séquence système du cas «Modifier Site»
 Diagramme de séquence système du cas «Supprimer Site»
Figure 73: diagramme de séquence système du cas «Supprimer Site»
Page 74
2.2. Diagrammes des classes participantes
 Diagrammes de classes participantes «Gestion Sites »
Figure 74 : Diagramme des classes participantes du cas d’utilisation« Gestion Sites»
 Diagrammes de classes participantes «Gestion super user »
Figure 75 : Diagramme des classes participantes du cas d’utilisation« Gestion super user »
Page 75
2.3. Diagrammes de séquences détaillés
Pour ce sprint, nous choisissons de présenter le diagramme de séquence détaillé de cas
d’utilisation «Ajouter Site ».
 Diagramme de séquence détaillé du cas d'utilisation « Ajouter site »
La figure 76 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Ajouter Site » illustré par la figure 71.
Figure 76: diagramme de séquence détaillé du cas «Ajouter Site»
 Diagramme de séquence détaillé du cas d'utilisation « Ajouter super user »
La figure 77 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Ajouter super user ».
Page 76
Figure 77: diagramme de séquence détaillé du cas «Ajouter super user»
2.4. Diagramme des classes de sprint 1
La figure 78 représente le diagramme de classe du sprint 1 du release 2.
Figure 78: Diagramme de classe du sprint 2
Page 77
3. Codage
Les figures ci-dessous représentent le schéma de la base de données de ce sprint.
Figure 79: Table site
Figure 80: Table super user
4. Les interfaces
Nous passons à présenter quelques interfaces réalisées lors du notre premier sprint release 2.
Page 78
 Interface « Gestion sites»
Figure 81 : Interface Gestion sites
 Interface « Gestion super utilisateur»
Figure 82 : Interface Gestion super utilisateur
Page 79
II. Deuxième Sprint
Notre deuxième sprint s’intéresse à l’ensemble des fonctionnalités de
« Gestion profil», « Authentification » et « Consulter les statistiques ».
Par la suite, le backlog du sprint 2 de la release 2 est illustré par le tableau suivant :
Table 18: Backlog du deuxième sprint (release 2)
1. Spécification fonctionnelle
En respectant la même démarche adoptée au cours du premier sprint, la spécification
fonctionnelle du deuxième sprint 2 se traduit par
La définition du diagramme de cas d’utilisation global du sprint, les diagrammes de cas
d’utilisation raffinés et leurs descriptions textuelles.
1.1. Diagramme de cas d’utilisation du sprint 2
La figure 83 ci-dessous illustre le diagramme des cas d’utilisation du deuxième sprint.
Figure 83: diagramme des cas d’utilisation du deuxième sprint
Thème Fonctionnalités Estimation
Gestion profil administrateur
Consulter profil 1
Modifier profil 2
Authentification S’authentifier 1
Consulter les statistiques
Consulter les Statistiques 3
Page 80
1.2.Raffinement des cas d’utilisation du sprint 2
La figure 84 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation du
deuxième sprint :
Figure 84: diagramme des cas d’utilisation détaillé du deuxième sprint
1.3.Description textuelle des cas d’utilisation
Nous traitons uniquement les cas d’utilisation « Consulter profil », « Modifier profil »,
« Authentification ».
Description textuelle du cas « Consulter profil »
Cas d’utilisation Consulter profil
Acteurs Administrateur
Pré-condition Acteur authentifié.
Post-condition Profile affiché
Scénario principal
1. L’administrateur demande de consulter son profil.
2. Le système affiche le profil
Table 19: Description textuelle du cas d’utilisation « Consulter Profil»
Page 81
 Description textuelle du cas « Modifier profil»
Cas d’utilisation Modifier profil
Acteurs Administrateur
Pré-condition Acteur authentifié.
Post-condition Profil modifié
Scénario principal
L’administrateur demande de modifier son profil.
Le système affiche le formulaire de modification.
L’administrateur modifie les informations et valide.
2-Le système vérifie les données saisies
3-Le système enregistre la modification
4-Le système redirige l’administrateur vers son profil
Scénario alternatif
L’administrateur saisit des données manquantes ou erronées :
Le système affiche un message d’erreur.
Reprise de l’étape 3 du scénario principal.
Table 20: Description textuelle du cas d’utilisation « Modifier Profil»
 Description textuelle du cas «Authentification »
Cas d’utilisation Authentification
Acteurs Administrateur, super user, membre
Post-condition Accès à l’espace personnel
Scénario principal
L’acteur saisie son login et son mot de passe
2. Le système vérifie les informations saisies
3-Le système redirige l’acteur vers son espace
Scénario alternatif
 L’acteur saisit des données manquantes
Le système affiche un message d’erreur
Reprise de l’étape 1 du scénario nominal
 Les données saisies sont invalides
-Le système affiche un message d’erreur
Reprise de l’étape 1 du scénario nominal
Table 21: Description textuelle du cas d’utilisation «Authentification»
Page 82
2. Conception
Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas
d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et
le diagramme de classe du sprint2 du release 2.
2.1. Diagrammes de séquence système
A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes
de séquences systèmes « Authentification», « Modifier profil ».
 Diagramme de séquence système du cas «Authentification»
Figure 85: diagramme de séquence système du cas «Authentification»
Page 83
 Diagramme de séquence système du cas «Modifier profil»
Figure 86: diagramme de séquence système du cas «Modifier profil»
Page 84
2.2. Diagrammes des classes participantes
 Diagrammes de classes participantes «Gestion profil»
Figure 87: diagramme de classes participantes «Gestion profil»
 Diagrammes de classes participantes «Authentification»
Figure 88: diagramme de classes participantes «Authentification»
Page 85
2.3. Diagrammes de séquences détaillés
Pour ce sprint, nous choisissons de présenter le diagramme de séquence détaillé de cas
d’utilisation «Modifier Profil ».
 Diagramme de séquence détaillé du cas d'utilisation « Modifier profil »
La figure 89 représente le diagramme de séquence système détaillé correspondant au
diagramme de séquence système « Modifier profil ».
Figure 89: Diagramme de séquence détaillé du cas d'utilisation « Modifier profil »
Page 86
3. Codage
La figure ci-dessous représente le schéma de la base de données de ce sprint.
Figure 90: Table Administrateur
4. Les interfaces
Nous passons à présenter quelques interfaces réalisées lors du notre deuxième sprint release
 Interface « Authentification»
Figure 91: Interface « Authentification»
Page 87
 Interface « Consulter profil»
Figure 92: Interface « Consulter profil»
 Interface « Modifier profil»
Figure 93: Interface « Modifier profil»
Page 88
5. Diagramme des classes global
La figure 94 représente le diagramme de classe de notre application. Ce diagramme
illustre les différentes entités manipulées par notre système ainsi que les relations
existantes entre elles.
Figure 94: Diagramme des classes global
Conclusion
A la fin de ce chapitre, nous avons réussi à terminer le dernier release de notre projet
Le chapitre suivant portera sur la phase de clôture de notre projet.
Page 89
Chapitre 5 :
Phase de clôture
Page 90
Chapitre 5 : Phase de clôture
Introduction
La phase clôture est la phase final du projet qui contient l’environnement du travail matériel
et logiciel. Par la suite, nous présentons l’architecture opérationnelle de notre projet.
I. Environnement de travail
Dans cette partie nous présentons l’environnement matériel et l’environnement logiciel pour
la réalisation du notre application.
1. Environnement matériel
Pour réaliser le projet, nous avons utilisé comme environnement matériel une machine qui
possède les caractéristiques suivantes :
Processeur Intel(R)Core(TM) i-4005U CPU @ 1.70GHz
Mémoire (RAM) 4GO
Système d’exploitation Windows 10 Pro
Disque dur 500 GB
Table 22 : Les caractéristiques d’environnement du travail
Page 91
2. Environnement logiciel
2.1. Outils et logiciels
 Visual studio 2015 :
Visual Studio est un ensemble complet d'outils de développement permettant
de générer des applications web ASP.NET, des services web XML, des
applications bureautiques et des applications mobiles. Visual Basic, Visual
C++, Visual C# utilisent tous le même environnement de développement
intégré (IDE), qui leur permet de partager des outils et facilite la création de
solutions faisant appel à plusieurs langages. [7]
 Xampp :
XAMPP est un ensemble de logiciels permettant de mettre en place facilement
un serveur Web local, un serveur FTP et un serveur de messagerie électronique.
Il s'agit d'une distribution de logiciels
libres (X (cross) Apache MariaDB Perl PHP) offrant une bonne souplesse
d'utilisation, réputée pour son installation simple et rapide. [8]
 Android studio :
Android Studio est un environnement de développement pour développer des
applications mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de
production Gradle.
 StarUML :
StarUML est un logiciel de modélisation UML, qui a été "cédé comme open
source" par son éditeur", à la fin de son exploitation commerciale (qui
visiblement continue ...), sous une licence modifiée de GNU GPL.[10]
Page 92
2.2. Technologies
 ASP.NET :
ASP.NET est un framework permettant de générer à la demande des pages web, lancée
par Microsoft en juillet 20002, et utilisée pour mettre en œuvre des applications web3. Il s'agit
d'une évolution majeure d'Active Server Pages (ASP, alias Classic ASP), par laquelle cette
technique a été incorporée dans la plateforme Microsoft .NET4.[11]
 HTML :
L’HyperText Markup Language, généralement abrégé HTML, est le langage de
balisage conçu pour représenter les pages web. C’est un langage permettant d’écrire de
l’hypertexte, d’où son nom. HTML permet également de structurer sémantiquement et
logiquement et de mettre en forme le contenu des pages, d’inclure
des ressources multimédias dont des images, des formulaires de saisie et des programmes
informatiques. [12]
 Bootstrap :
Bootstrap est une collection d'outils utiles à la création du design (graphisme, animation et
interactions avec la page dans le navigateur, etc.) de sites et d'applications web. [13]
 Jquery :
jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture
de scripts côté client dans le code HTML des pages web2.[14]
 Json :
JavaScript Object Notation (JSON) est un format de données textuelles dérivé de la notation
des objets du langage JavaScript. Il permet de représenter de l’information structurée comme
le permet XML par exemple. [15]
 Service Web REST :
Les services web REST (REpresentational State Transfer) sont plus un ensemble de bonnes
pratiques à suivre afin de réaliser un service web respectant les principes REST. Ils utilisent le
protocole HTTP afin de communiquer avec les applications clientes. Il sera donc possible
d’insérer, de mettre à jour, de supprimer et de récupérer des informations (POST, PUT,
DELETE, GET). [16]
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile

Contenu connexe

Tendances

RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Ayoub Mkharbach
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
Yahyaoui Mohamed Yosri
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
Belwafi Bilel
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
Madjid Meddah
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Conception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerceConception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerce
AHMEDBELGHITH4
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
BadrElattaoui
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
MehdiOuqas
 
Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...
Ramzi Noumairi
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
Rim ENNOUR
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
Ilef Ben Slima
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
fehmi arbi
 

Tendances (20)

RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Conception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerceConception et réalisation d'une application web et mobile de e-commerce
Conception et réalisation d'une application web et mobile de e-commerce
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Rapport de stage développement informatique
Rapport de stage développement informatique Rapport de stage développement informatique
Rapport de stage développement informatique
 
Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...Présentation PFE (Conception et développement d'une application web && mobile...
Présentation PFE (Conception et développement d'une application web && mobile...
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 

Similaire à Rapport pfe Conceptionet Developpement d'une Application web et Mobile

Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génieCréation de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Dany Rabe
 
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génieCréation de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Dany Rabe
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
Oussama Ben Sghaier
 
Rapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIARapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIA
REDOUANIAbdessamad
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Mohamed Amine Mahmoudi
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
JinenAbdelhak
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
Khadidja BOUKREDIMI
 
Rapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdfRapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdf
AlaChihaoui1
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
OumaimaOuedherfi
 
Application web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment systemApplication web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment system
Sarra ERRREGUI
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
Mohamed Amine Mahmoudi
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
Massimo Russo
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
Massimo Russo
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
Mounir Kaali
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
marwenbencheikhali
 
Rapport_deStage
Rapport_deStageRapport_deStage
Rapport_deStage
Omar TRAI
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack
Ahmed Slim
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Mohammed JAITI
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
Bilel Khaled ☁
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Mohamed Amine Mahmoudi
 

Similaire à Rapport pfe Conceptionet Developpement d'une Application web et Mobile (20)

Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génieCréation de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
 
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génieCréation de-pages-web-pour-les-branches-de-la-faculté-de-génie
Création de-pages-web-pour-les-branches-de-la-faculté-de-génie
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Rapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIARapport de stage - gestion commerciale @REC MEDIA
Rapport de stage - gestion commerciale @REC MEDIA
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
 
Rapport de stage d'été
Rapport de stage d'étéRapport de stage d'été
Rapport de stage d'été
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
 
Rapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdfRapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdf
 
Rapport de projet de fin d’étude
Rapport  de projet de fin d’étudeRapport  de projet de fin d’étude
Rapport de projet de fin d’étude
 
Application web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment systemApplication web de gestion de recrutement- Recruitement managment system
Application web de gestion de recrutement- Recruitement managment system
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
Rapport stage onee-be_2
Rapport stage onee-be_2Rapport stage onee-be_2
Rapport stage onee-be_2
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Rapport_deStage
Rapport_deStageRapport_deStage
Rapport_deStage
 
Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack Mise en place d'une infrastructure basée sur OpenStack
Mise en place d'une infrastructure basée sur OpenStack
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
 
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed AmineRapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
Rapport de stage d'initiation 2015 Mahmoudi Mohamed Amine
 

Rapport pfe Conceptionet Developpement d'une Application web et Mobile

  • 1. Année Universitaire:2018/2019Code: 720 Université de la Manouba École Supérieure d’Économie Numérique Rapport De projet de fin d'études Sujet Développement d’une application pour la gestion des équipements de sécurité et de lutte contre les incendies dans les bâtiments Élaboré par: Raoua Bennasr Présenté en vue de l'obtention du diplôme de Mastère professionnel en Modélisation, Bases de Données et Intégration des Systèmes Organisme d'accueil Première Consulting Encadré par ESEN Mme Yamna Ettares Société Mme Amani Bouaziz
  • 2. Remerciements J’aimerais en premier lieu remercier mon dieu Allah qui ma donné le courage pour la réalisation de ce travail Je tiens tout d'abord à adresser mes plus vifs remerciements à mon encadreur Madame Yamna Ettares pour son encadrement ses conseils et ses corrections. J’adresse mes vifs remerciements à Madame Amani Bouaziz, qui m'a soutenue tout au long de mon travail Je tiens également à remercier et exprimer mon profond respect aux membres de jury d’avoir accepté de juger ce travail Et en fin j’adresse mes s’incères remerciements à mes parents et mes sœurs.
  • 3. Table des matières Introduction générale.............................................................................................................................. 1 Chapitre 1 : Étude du projet.................................................................................................................... 2 Chapitre 1 : Étude du projet.................................................................................................................... 3 Introduction ............................................................................................................................................. 3 I Présentation de l’organisme d’accueil............................................................................................. 3 1. Présentation ..................................................................................................................................... 3 2. Organisation .................................................................................................................................... 3 3. Organigramme................................................................................................................................. 3 4. Activités........................................................................................................................................... 4 II Présentation du projet...................................................................................................................... 5 1. Cadre du projet............................................................................................................................ 5 2. Etude de l’existant....................................................................................................................... 5 2.1. Description de l’existant...................................................................................................... 5 2.2. Critique de l’existant ........................................................................................................... 6 3. Solution proposée........................................................................................................................ 6 III Méthodologie adoptée ................................................................................................................. 7 1. Méthodes agiles........................................................................................................................... 7 2. Méthode agile adoptée: Scrum.................................................................................................... 7 Conclusion ............................................................................................................................................... 9 Chapitre 2 : Planification générale du projet .......................................................................................... 9 Chapitre 2: Planification générale du projet ......................................................................................... 10 Introduction ........................................................................................................................................... 10 I. Analyse des besoins....................................................................................................................... 10 1. Identification des acteurs........................................................................................................... 10 2. Les besoins fonctionnels............................................................................................................ 11 3. Les besoins non fonctionnels..................................................................................................... 13 4. Langage de modélisation adopté ............................................................................................... 13 5. Architecture logiciel.................................................................................................................. 13 II. Diagramme des cas d’utilisation global......................................................................................... 14 III. Prototypage des interfaces de l’application............................................................................... 16
  • 4. IV. Adaptation du cycle de développement Scrum au projet .......................................................... 18 1. Répartition des rôles.................................................................................................................. 18 2. Product Backlog ........................................................................................................................ 18 3. Planification des sprints du projet ............................................................................................. 22 Conclusion............................................................................................................................................. 22 Chapitre 3 : Release 1 du projet............................................................................................................ 23 Chapitre 3 : Release 1 du projet............................................................................................................ 24 Introduction ........................................................................................................................................... 24 I. Premier Sprint................................................................................................................................ 24 1. Spécification fonctionnelle........................................................................................................ 25 1.1. Diagramme de cas d’utilisation du sprint 1....................................................................... 25 1.2. Raffinement des cas d’utilisation du sprint 1 .................................................................... 26 1.3. Description textuelle des cas d’utilisation......................................................................... 27 Nous traitons uniquement les cas d’utilisation :............................................................................ 27 2. Conception................................................................................................................................. 29 2.1. Diagrammes de séquence système .................................................................................... 29 2.2. Diagrammes des classes participantes............................................................................... 32 2.3. Diagrammes de séquences détaillés .................................................................................. 33 2.4. Diagramme des classes de sprint 1.................................................................................... 35 3. Codage....................................................................................................................................... 35 4. Les interfaces............................................................................................................................. 37 II. Deuxième Sprint............................................................................................................................ 43 1. Spécification fonctionnelle........................................................................................................ 43 1.1. Diagramme de cas d’utilisation du sprint 2....................................................................... 44 1.2. Raffinement des cas d’utilisation du sprint 2 .................................................................... 45 1.3. Description textuelle des cas d’utilisation......................................................................... 46 2. Conception................................................................................................................................. 50 2.1. Diagrammes de séquence système .................................................................................... 50 2.2. Diagrammes des classes participantes............................................................................... 55 2.3. Diagrammes de séquences détaillés .................................................................................. 56 2.4. Diagramme des classes de sprint 2.................................................................................... 58 3. Codage....................................................................................................................................... 59 4. Les interfaces............................................................................................................................. 60 Conclusion ............................................................................................................................................. 66
  • 5. Chapitre 4 : Release 2 du projet............................................................................................................ 67 Chapitre 4 : Release 2 du projet............................................................................................................ 68 Introduction ........................................................................................................................................... 68 I. Premier Sprint................................................................................................................................ 68 1. Spécification fonctionnelle........................................................................................................ 68 1.1. Diagramme de cas d’utilisation du sprint.......................................................................... 69 1.2. Raffinement des cas d’utilisation du sprint ....................................................................... 69 1.3. Description textuelle des cas d’utilisation......................................................................... 70 2. Conception................................................................................................................................. 72 2.1. Diagrammes de séquence système .................................................................................... 72 2.2. Diagrammes des classes participantes............................................................................... 74 2.3. Diagrammes de séquences détaillés .................................................................................. 75 2.4. Diagramme des classes de sprint 1.................................................................................... 76 3. Codage....................................................................................................................................... 77 4. Les interfaces............................................................................................................................. 77 II. Deuxième Sprint............................................................................................................................ 79 1. Spécification fonctionnelle........................................................................................................ 79 1.1. Diagramme de cas d’utilisation du sprint 2....................................................................... 79 1.2. Raffinement des cas d’utilisation du sprint 2 .................................................................... 80 1.3. Description textuelle des cas d’utilisation......................................................................... 80 2. Conception................................................................................................................................. 82 2.1. Diagrammes de séquence système .................................................................................... 82 2.2. Diagrammes des classes participantes............................................................................... 84 2.3. Diagrammes de séquences détaillés .................................................................................. 85 3. Codage....................................................................................................................................... 86 4. Les interfaces............................................................................................................................. 86 5. Diagramme des classes global................................................................................................... 88 Conclusion ............................................................................................................................................. 88 Chapitre 5 : Phase de clôture ................................................................................................................ 89 Chapitre 5 : Phase de clôture ................................................................................................................ 90 Introduction........................................................................................................................................... 90 I. Environnement de travail .............................................................................................................. 90 1. Environnement matériel ............................................................................................................ 90 2. Environnement logiciel ............................................................................................................. 91
  • 6. 2.1. Outils et logiciels............................................................................................................... 91 2.2. Technologies ..................................................................................................................... 92 3. Déploiement .............................................................................................................................. 93 3.1. Architecture opérationnelle ................................................................................................... 93 3.2. Diagramme de déploiement................................................................................................... 94 Conclusion ............................................................................................................................................. 94 Conclusion générale.............................................................................................................................. 95 Bibliographie.......................................................................................................................................... 96
  • 7. Liste des figures Figure 1 : Organigramme Première Consulting....................................................................................... 3 Figure 2: La méthode scrum.................................................................................................................... 8 Figure 3: Logo UML................................................................................................................................ 13 Figure 4: Architecture MVC................................................................................................................... 14 Figure 5: Diagramme des cas d’utilisation global.................................................................................. 15 Figure 6: Logo d'outil balsamiq ............................................................................................................. 16 Figure 7: Interface de l’authentification................................................................................................ 16 Figure 8: Interface de la Gestion des équipements .............................................................................. 16 Figure 9: de la gestion des actions ........................................................................................................ 17 Figure 10: Interface de la gestion des contrôles ................................................................................... 17 Figure 11: Interface Ajout d’action........................................................................................................ 17 Figure 12: Interface Ajout du contrôle................................................................................................. 17 Figure 13: Diagramme de cas d'utilisation global du Sprint 1............................................................... 25 Figure 14: Diagramme de cas d'utilisation détaillé du Sprint 1............................................................. 26 Figure 15: Diagramme de séquence système du cas d'utilisation « Ajouter équipement».................. 30 Figure 16: Diagramme de séquence système du cas d'utilisation « Modifier équipement»................ 30 Figure 17: Diagramme de séquence système du cas d'utilisation « Supprimer équipement»............. 31 Figure 18: Diagramme de séquence système du cas d'utilisation « Consulter liste équipements»..... 31 Figure 19: Diagramme des classes participantes du cas d’utilisation« Gestion Catégorie» ................. 32 Figure 20: Diagramme des classes participantes du cas d’utilisation« Gestion équipement»............. 33 Figure 21 : Diagramme de séquences détaillé « Ajouter équipement ».............................................. 34 Figure 22: Diagramme de séquences détaillé « Consulter la liste des équipements »........................ 34 Figure 23: Diagramme de classe du sprint 1 ......................................................................................... 35 Figure 24: Table «équipement » ........................................................................................................... 36 Figure 25: Table «catégorie »................................................................................................................ 36 Figure 26: Table «CheckListe ».............................................................................................................. 36 Figure 27: Table «équipement » ........................................................................................................... 37 Figure 28: Table «local »........................................................................................................................ 37 Figure 29: Interface « Gestion équipements »..................................................................................... 37 Figure 30: Interface « Ajouter équipement »....................................................................................... 38 Figure 31: Interface « Modifier équipement »..................................................................................... 38 Figure 32: Interface « Gestion catégorie »........................................................................................... 39 Figure 33: Interface « Gestion Check-list »........................................................................................... 39 Figure 34: Interface « Gestion fournisseur»......................................................................................... 40 Figure 35: Interface « Gestion fournisseur»......................................................................................... 40 Figure 36: Interface « Consulter équipements»................................................................................... 41 Figure 37: Interface « équipements» ................................................................................................... 41 Figure 38: Interface « Recherche un équipement par QRCode» ........................................................ 42 Figure 39: Interface « Consulter un seul équipement»....................................................................... 42 Figure 40: diagramme des cas d’utilisation du deuxième sprint........................................................... 44 Figure 41: diagramme des cas d’utilisation détaillé du deuxième sprint.............................................. 45 Figure 42: Diagramme de séquence système du cas d'utilisation « Ajouter action» ........................... 50 Figure 43: Diagramme de séquence système du cas d'utilisation « Modifier action» ......................... 51
  • 8. Figure 44: Diagramme de séquence système du cas d'utilisation « Supprimer action»....................... 52 Figure 45: Diagramme de séquence système du cas d'utilisation « Consulter les actions»................ 52 Figure 46: Diagramme de séquence système du cas d'utilisation « Ajouter Contrôles»...................... 53 Figure 47: Diagramme de séquence système du cas d'utilisation « Ajouter Planning» ....................... 54 Figure 48: Diagramme des classes participantes du cas d’utilisation« Gestion actions» ..................... 55 Figure 49: Diagramme des classes participantes du cas d’utilisation« Gestion Contrôle»................... 55 Figure 50: Diagramme des classes participantes du cas d’utilisation« Planification» .......................... 56 Figure 51: Diagramme de séquences détaillé « Ajouter action » ......................................................... 57 Figure 52: Diagramme de séquences détaillé « Consulter les actions »............................................... 57 Figure 53: Diagramme de classe du sprint 2 ......................................................................................... 58 Figure 54 : table Contrôle...................................................................................................................... 59 Figure 55 : table Action ......................................................................................................................... 59 Figure 56 : table Planification................................................................................................................ 60 Figure 57 : table Membre...................................................................................................................... 60 Figure 58 : Interface Gestion Contrôles ................................................................................................ 61 Figure 59 : Interface Ajouter Contrôle .................................................................................................. 61 Figure 60 : Interface Gestion Actions.................................................................................................... 62 Figure 61: Interface Ajouter Action....................................................................................................... 62 Figure 62: Interface Planification .......................................................................................................... 63 Figure 63: Interface Ajouter planning ................................................................................................... 63 Figure 64 : Interface Consulter Actions................................................................................................. 64 Figure 65 : Interface Consulter Contrôles ............................................................................................. 64 Figure 66 : Interface Gestion Membre.................................................................................................. 65 Figure 67 : Interface Ajouter Contrôle .................................................................................................. 65 Figure 68 : Interface Liste des Contrôles.............................................................................................. 65 Figure 69: diagramme des cas d’utilisation du sprint 1 ........................................................................ 69 Figure 70: diagramme des cas d’utilisation détaillé du sprint 1............................................................ 69 Figure 71: diagramme de séquence système du cas «Ajouter Site»..................................................... 72 Figure 72: diagramme de séquence système du cas «Modifier Site»................................................... 73 Figure 73: diagramme de séquence système du cas «Supprimer Site»................................................ 73 Figure 74 : Diagramme des classes participantes du cas d’utilisation« Gestion Sites» ........................ 74 Figure 75 : Diagramme des classes participantes du cas d’utilisation« Gestion super user ».............. 74 Figure 76: diagramme de séquence détaillé du cas «Ajouter Site»...................................................... 75 Figure 77: diagramme de séquence détaillé du cas «Ajouter super user»........................................... 76 Figure 78: Diagramme de classe du sprint 2 ......................................................................................... 76 Figure 79: Table site .............................................................................................................................. 77 Figure 80: Table super user................................................................................................................... 77 Figure 81 : Interface Gestion sites......................................................................................................... 78 Figure 82 : Interface Gestion super utilisateur...................................................................................... 78 Figure 83: diagramme des cas d’utilisation du deuxième sprint........................................................... 79 Figure 84: diagramme des cas d’utilisation détaillé du deuxième sprint.............................................. 80 Figure 85: diagramme de séquence système du cas «Authentification» ............................................. 82 Figure 86: diagramme de séquence système du cas «Modifier profil»................................................ 83 Figure 87: diagramme de classes participantes «Gestion profil» ......................................................... 84 Figure 88: diagramme de classes participantes «Authentification»..................................................... 84
  • 9. Figure 89: Diagramme de séquence détaillé du cas d'utilisation « Modifier profil » ........................... 85 Figure 90: Table Administrateur............................................................................................................ 86 Figure 91: Interface « Authentification»............................................................................................... 86 Figure 92: Interface « Consulter profil» ................................................................................................ 87 Figure 93: Interface « Modifier profil».................................................................................................. 87 Figure 94: Diagramme des classes global.............................................................................................. 88 Figure 95 : l’architecture 3 tiers ............................................................................................................ 93 Figure 96: diagramme de déploiement................................................................................................. 94
  • 10. Liste des tableaux Table 1: Backlog du produit................................................................................................................... 21 Table 2: Backlog du premier sprint (release 1) ..................................................................................... 24 Table 3: Description textuelle du cas d’utilisation « Ajouter équipement».......................................... 27 Table 4: Description textuelle du cas d’utilisation « Modifier équipement»........................................ 28 Table 5: Description textuelle du cas d’utilisation « Supprimer équipement»..................................... 28 Table 6: Description textuelle du cas d’utilisation « Consulter la liste des équipements».................. 29 Table 7: Backlog du deuxième sprint (release 1) .................................................................................. 43 Table 8: Description textuelle du cas d’utilisation « Ajouter Action»................................................... 46 Table 9: Description textuelle du cas d’utilisation « Modifier action» ................................................. 47 Table 10: Description textuelle du cas d’utilisation « Supprimer action» ............................................ 47 Table 11: Description textuelle du cas d’utilisation « Ajouter Contrôle» ............................................. 48 Table 12: Description textuelle du cas d’utilisation « Ajouter Planning» ............................................. 49 Table 13: Description textuelle du cas d’utilisation « Consulter les actions»....................................... 49 Table 14: Backlog du premier sprint (release 2) ................................................................................... 68 Table 15: Description textuelle du cas d’utilisation « Ajouter Site» ..................................................... 70 Table 16: Description textuelle du cas d’utilisation « Modifier site».................................................... 71 Table 17: Description textuelle du cas d’utilisation « Supprimer site»................................................. 71 Table 18: Backlog du deuxième sprint (release 2) ................................................................................ 79 Table 19: Description textuelle du cas d’utilisation « Consulter Profil» ............................................... 80 Table 20: Description textuelle du cas d’utilisation « Modifier Profil»................................................. 81 Table 21: Description textuelle du cas d’utilisation «Authentification»............................................... 81 Table 22 : Les caractéristiques d’environnement du travail ................................................................. 90
  • 11. Page 1 Introduction générale L’informatique est un domaine d'activité technique et industriel concernant le traitement de l’information. Il représente l'ensemble des ressources d'une organisation : hommes, matériels et logiciels, pour collecter, stocker, traiter et diffuser les informations. De nos jours, beaucoup sont les entreprises qui sont confrontées à des problèmes liés à la gestion des stocks et à la nécessité d’une application informatique permettent d’éviter ces problèmes. La puissance de l’informatique offre toutes les possibilités, l’évolution des logiciels permet d’automatiser des procédures et de fournir les informations adéquates à temps. A cet effet, notre projet de fin d’études consiste à développer une application web et mobile pour la gestion des équipements de sécurité et de lutte contre les incendies dans les bâtiments. Notre travail consiste donc en deux principales parties, une partie qui s’intéresse au développement d’une application web permettant aux utilisateurs d’assure la gestion des équipements, gestion des contrôles, gestion des actions d’intervention et planification des contrôles. Une deuxième partie qui consiste à développer une application mobile pour la gestion des actions et gestion des contrôles pour faciliter le travail aux utilisateurs. Notre rapport est élaboré en adoptant la méthodologie Scrum et il se compose de cinq chapitres plus une introduction générale et une conclusion :  Le premier chapitre « Étude du projet » contient la présentation générale du projet à travers la présentation de l’organisme d’accueil ainsi du projet dans un premier temps et la méthode du travail adoptée dans un second temps.  Le deuxième chapitre intitulé « Planification du projet » appelé aussi sprint 0, ce chapitre sera consacré au recueil des besoins et la planification complète du travail.  Le troisième et le quatrième chapitre sont nommés respectivement « Release 1 du projet » et « Release 2 du projet » sont dédié au développent des deux releases.  Le dernier chapitre intitulé « Phase de clôture » présente les différents outils et technologies utilisées pour le développement.
  • 12. Page 2 Chapitre 1 : Étude du projet
  • 13. Page 3 Chapitre 1 : Étude du projet Introduction Dans ce chapitre, nous présentons l’organisme d’accueil où s’est déroulé le stage par la suite le cadre du projet, l’étude de l’existant présentant la situation actuelle, la solution proposée et finalement la méthode du travail adoptée. I Présentation de l’organisme d’accueil 1. Présentation Première Consulting SARL est un cabinet d’assistance, de conseil et de formation, fondée en 2008. Elle se situe à 73ter Avenue Habib Bourguiba, Manouba. 2. Organisation La société est subdivisée comme suit :  Direction générale : Elle est assistée par un assistant qui transmet les notes aux autres directions  Service administratif et financier : Son rôle est de gérer les affaires administratives et de la comptabilité de la société en analysant la liquidité, la solvabilité et la rentabilité.  Service de formation : Des formateurs se chargent de la formation des clients sur les activités de la société.  Service informatique : Ce service developpe des applications web et desktop pour faciliter le travail quotidien de ses clients. 3. Organigramme Figure 1 : Organigramme Première Consulting
  • 14. Page 4 4. Activités Dès la création de l’entreprise, la direction générale de « Première Consulting » a fait le choix essentiel d’offrir à ses clients du conseil et de la formation à forte valeur ajoutée, en se basané sur une approche pragmatique, fortement orientée résultat. Première Consulting s'appuie sur un réseau de collaborateurs, d’experts et de consultants hautement qualifiés bénéficiant d’une expérience significative dans le domaine afin de répondre efficacement aux besoins des clients. En effet, les clients attendent de la société des solutions opérationnelles et pragmatiques pour aller droit au but plutôt que des théories sans résultats. Parmi les activités de cette société nous pouvons citer : Mise en place des systèmes de Management de la qualité suivant les normes et les référentiels ISO 9001 - ISO 14001 - OHSAS 18001 - ISO/TS 16949 - - ISO 17025 - ISO 17020.  Optimisation de système de management de la qualité, environnement, santé et sécurité au travail existant.  Diagnostic de mise à niveau, conseil à la préparation des dossiers, accompagnement dans la réalisation des dossiers de prise en charge…etc.  Externalisation de certaines tâches du RMQ pour les entreprises qui le souhaitent.  Assistance à l’étalonnage et à la vérification des ECME.  Conduite d’audit interne, seconde et tierce partie.  Identification des besoins en compétences.  Réalisation de la formation en inter et intra entreprise.  Evaluation des formations.  Veille réglementaire.
  • 15. Page 5 II Présentation du projet 1. Cadre du projet Ce projet s’inscrit dans le cadre du projet de fin d’études pour l’obtention d’un diplôme de mastère professionnel en Modélisation, Base de données et Intégration des Systèmes à l’Ecole Supérieure d’Economie Numérique. Ce projet vise à développer une application web et mobile qui sera nommée « Gestion Equipements » permettant de :  Assurer la gestion des équipements avec ses catégories et emplacements.  Contrôler les pièces de ces équipements avec des check-lists de vérification, et si un contrôle contient des pannes, nous sortirons une action comme une intervention pour résoudre les problèmes.  Assurer la gestion des actions de réparation en cas d'un équipement en panne.  Après la réalisation du contrôle nous devons gérer la mise à jour de calendrier du programme d’intervention. 2. Etude de l’existant L’étude de l’existant est une étape primordiale qui permet de définir les forces et les faiblesses d’un produit afin de déterminer les besoins du client, et de les prendre en considération lors de la conception et la réalisation de notre application. 2.1.Description de l’existant La gestion des équipements se fait actuellement d’une façon traditionnelle, manuelle et aucun traitement ne se fait avec un logiciel ce qui provoque un certain nombre de problèmes. La gestion des équipements est basée sur des supports papier. Lors de la réception d’équipements on prépare un dossier pour chaque équipement, les dossiers seront classés selon les noms des équipements .Chaque équipement aura sa fiche (nom, type, marque, date mise en service …).
  • 16. Page 6 Le travail se déroule de la manière suivante : 1. Créer des check-lists à l'aide du manuel technique pour chaque équipement 2. Réaliser des contrôles sur les équipements en utilisant les fiches check-list, cette opération peur être journalière, mensuelle ou annuelle. 3. Après la réalisation du contrôle, on doit gérer la mise à jour du calendrier du programme de contrôle pour chaque équipement. 4. Déclenchement d’une action corrective après une défaillance totale ou partielle d’un équipement ou après détection d’une panne dans l’opération du contrôle. 2.2.Critique de l’existant  Aucun ficher ne regroupe tous les équipements ce qui provoquent une difficulté dans la recherche et l’accès aux équipements et le risque de perte d’informations.  Il existe des nombreux fichiers manuels et des documents répétitifs.  Insuffisance des informations disponibles pour la gestion des contrôles.  La redondance des check-lists, chaque équipement à une check-list.  Problèmes de rentabilités et de qualités.  Manque de sécurité de l’information et des données. 3. Solution proposée L'étude de l’existant et les besoins de la société ont montré beaucoup des problèmes voir des anomalies donc on nous proposons une solution qui pourra se traduire par le développement d’une application web et mobile pour la gestion des équipements, la gestion des contrôles et la gestion des actions d’intervention. Cette application a pour objectif de :  Faciliter la recherche et l’accès aux documents avec l’outil informatique.  Annuler les documents répétitifs et éliminer la redondance des check-lists.  Simplification du travail.  Amélioration de la fiabilité et de la sécurité des données.  Minimisation des supports papiers utilisés.  Garantie une interactivité entre les contrôles et les actions corrective.  Optimisation du temps de réponse de l’application
  • 17. Page 7 III Méthodologie adoptée Le bon choix de la méthodologie conduit à la bonne réalisation du projet, plusieurs méthodes de conception existent : l'approche traditionnelle en cascade, et différentes approches d'agile comme principalement Programming (XP), Scrum et autres. Pour la réalisation du notre application, nous avons adopté pour la méthodologie agile. 1. Méthodes agiles Une méthode Agile est une approche itérative et collaborative, capable de prendre en compte les besoins initiaux du client et ceux liés aux évolutions. La méthode Agile se base sur un cycle de développement qui porte le client au centre pour l’impliquer dans la réalisation du début à la fin du projet. Cette implication permet à l’équipe d’obtenir un feedback régulier afin d’appliquer directement les changements nécessaires. Grâce à la méthode agile le demandeur obtient une meilleure visibilité de la gestion des travaux qu’avec une méthode classique. Cette méthode vise à accélérer le développement d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la durée de sa création. [1] 2. Méthode agile adoptée: Scrum Pour mener à bien notre projet et de garantir le bon déroulement des différentes phases, nous avons adopté Scrum comme une méthodologie de gestion de projet. Aujourd’hui « Scrum » est la méthode agile la plus populaire. Ce terme signifie « mêlée » au rugby. La méthode scrum s’appuie sur des « sprints » qui sont des espaces temps assez courts pouvant aller de quelques heures jusqu’à un mois. Généralement et de préférence un sprint s’étend sur deux semaines. À la fin de chaque sprint, l’équipe présente ce qu’elle a ajouté au produit.
  • 18. Page 8 Figure 2: La méthode scrum Scrum regroupe trois acteurs :  Le Product Owner (ou « Directeur de produit ») : il communique les objectifs premiers des clients et utilisateurs finaux, coordonne l’implication des utilisateurs et des parties prenantes, et se coordonne lui-même avec les autres product owners pour assurer une cohérence.  Le Scrum Master : membre de l’équipe, il a pour but d’optimiser la capacité de production de l’équipe. Pour se faire, le scrum master aide l’équipe à travailler de façon autonome tout en s’améliorant d’avantage.  L’équipe opérationnelle (qui regroupe idéalement moins de dix personnes) : la particularité d’une équipe scrum est qu’elle est dépourvue de toute hiérarchie interne. Une équipe scrum est auto-organisée. D’autres termes sont à connaître pour comprendre la méthode scrum:  Le product backlog (carnet du produit) : ce document contient les exigences initiales dressées puis hiérarchisées avec le client en début de projet. Néanmoins il va évoluer tout au long de la durée du projet, en fonction des divers besoins du client.  Le sprint backlog (carnet de sprint) : en chaque début de sprint, l’équipe définit un but. Puis lors de la réunion de sprint, l’équipe de développement choisit les éléments du carnet à réaliser. L’ensemble de ces éléments constitue alors le sprint backlog.  User story : ce terme désigne les fonctionnalités décrites par le client.  La mêlée (scrum) : c’est une réunion d’avancement organisée de manière quotidienne durant le sprint. [2]
  • 19. Page 9 Conclusion Ce chapitre a été le point de départ du rapport pour la réalisation de notre projet et le chapitre suivant sera consacré pour la planification générale du projet.
  • 20. Page 9 Chapitre 2 : Planification générale du projet
  • 21. Page 10 Chapitre 2: Planification générale du projet Introduction Ce chapitre sera consacré à la réalisation de la première phase de la méthodologie Scrum « sprint 0 » qui présente les fonctionnalités de base du projet, le diagramme des cas d’utilisation global, et le Product Backlog qui va nous permettre de planifier les releases. Analyse des besoins. I. Analyse des besoins Cette section est destinée à la spécification des besoins fonctionnels et non fonctionnels de la solution ainsi que l’identification des acteurs. 1. Identification des acteurs Administrateur : Qui s’occupera de gérer son profil, la gestion des super utilisateurs, la gestion des sites et consulter les statistiques. Super Utilisateur : A le droit de créer des nouveaux membres et de définir les rôles et les privilèges des membres du système. Technicien : Son rôle consiste à assurer la gestion des équipements, les check-lists de vérification, les locaux, les fournisseurs des équipements ainsi que la consultation de la planification, les contrôles, les actions réalisées sur les équipements. Contrôleur : Il a pour rôle de planifier les contrôles, assurer la gestion des actions, la gestion des contrôles et la consultation la liste des équipements.
  • 22. Page 11 2. Les besoins fonctionnels Gestion des catégories équipements Cette fonctionnalité permettre au technicien de :  Ajouter, modifier, supprimer des catégories. Gestion des check-lists de vérification des équipements Cette fonctionnalité permettre au technicien de :  Ajouter, modifier, supprimer des check-lists. Gestion des locaux des équipements Cette fonctionnalité permettre au technicien de :  Ajouter, modifier, supprimer des locaux. Gestion des fournisseurs des équipements  Cette fonctionnalité permettre au technicien de :  Ajouter, modifier, supprimer des fournisseurs. Gestion des équipements Cette fonctionnalité permettre au technicien de :  Ajouter, modifier, supprimer des équipements.  Consulter la liste des équipements. Planification des contrôles Cette fonctionnalité permettre au contrôleur de :  Ajouter modifier supprimer une date de contrôle.  Consulter les plannings. Gestion des actions Cette fonctionnalité permettre au contrôleur de :  Ajouter, modifier, supprimer des actions.
  • 23. Page 12  Consulter la liste des actions. Gestion des Contrôles Cette fonctionnalité permettre au contrôleur de :  Ajouter, modifier, supprimer des contrôles.  Consulter la liste des contrôles. Gestion des membres. Cette fonctionnalité permettre au super utilisateur de :  Ajouter, modifier et supprimer des membres. Gestion des super utilisateurs. Cette fonctionnalité permettre à l’administrateur de :  Ajouter, modifier et supprimer des super utilisateurs. Gestion profil Administrateur. Cette fonctionnalité permettre à l’administrateur de :  Consulter et modifier son profil. Gestion des sites. Cette fonctionnalité permettre à l’administrateur de :  Ajouter, modifier et supprimer des sites. Consulter les statistiques Cette fonctionnalité permettre à l’administrateur de :  Consulter les statistiques.
  • 24. Page 13 3. Les besoins non fonctionnels Rapidité : Nos deux applications doivent répondre aux besoins des utilisateurs dans le plus court délai. Fiabilité : Bon fonctionnement des deux applications sans détection de défaillance. L’extensibilité : Les deux applications devront être extensibles, c'est-à dire qu'il pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités. La sécurité : les informations ne devront pas être accessibles à tout le monde. La performance : le système doit réagir dans un délai précis, quel que soit l'action de l'utilisateur. 4. Langage de modélisation adopté Le langage de modélisation adopté pour notre projet est l’UML UML, c’est l’acronyme anglais pour « Unified Modeling Language ». On le traduit par « Langage de modélisation unifié ». La notation UML est un langage visuel constitué d’un ensemble de schémas, appelés des diagrammes, qui donnent chacun une vision différente du projet à traiter. UML nous fournit donc des diagrammes pour représenter le logiciel à développer : son fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel, etc. [2] Figure 3: Logo UML 5. Architecture logiciel Dans cette partie nous expliquons le choix de l’architecture logicielle du notre travail qui se base sur le modèle MVC. L’architecture MVC est l’une des architectures logicielles les plus utilisées pour les applications Web, elle se compose de 3 modules :
  • 25. Page 14 Figure 4: Architecture MVC Modèle : noyau de l’application qui gère les données, permet de récupérer les informations de la base de données, de les organiser pour qu’elles puissent ensuite être traitées par le contrôleur. Vue : composant graphique de l’interface qui permet de présenter les données du modèle à l’utilisateur. Contrôleur : composant responsable des prises de décision, gère la logique du code qui prend des décisions, il est l’intermédiaire entre le modèle et la vue. [3] II. Diagramme des cas d’utilisation global Pour présenter les fonctionnalités de notre système de manière formelle, nous utilisons le diagramme de cas d’utilisation du langage de modélisation UML. Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement, les cas d'utilisation sont plus appropriés. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. [4] La figure 4 représente le diagramme du cas d’utilisation général de notre application. Ce diagramme illustre les différents acteurs ainsi que les cas d’utilisations affectés à chacun de ces acteurs.
  • 26. Page 15 Figure 5: Diagramme des cas d’utilisation global
  • 27. Page 16 III. Prototypage des interfaces de l’application nous avons créé des maquettes pour les interfaces de l’application web et l’application mobile, pour avoir une idée et une vision graphique et ergonomique dès le début avec l’outil de prototypage « Balsamiq» Figure 6: Logo d'outil balsamiq Nous présentons ci-dessous quelques maquettes prévisionnelles des interfaces de l’application Prototypage de l'interface d'authentification Figure 7: Interface de l’authentification Prototypage de l'interface Gestion des équipements Figure 8: Interface de la Gestion des équipements
  • 28. Page 17 Prototypage de l'interface de la gestion des actions Figure 9: de la gestion des actions Prototypage de l'interface de la gestion des contrôles Figure 10: Interface de la gestion des contrôles Prototypage des interfaces de l’application mobile Figure 11: Interface Ajout d’action Figure 12: Interface Ajout du contrôle
  • 29. Page 18 IV. Adaptation du cycle de développement Scrum au projet 1. Répartition des rôles En suivant la méthodologie Scrum, notre équipe de projet sera réparti en trois rôles : 2. Product Backlog Le tableau ci-dessous représente le backlog produit. Il présente les fonctionnalités de notre application. Dans ce tableau, les fonctionnalités sont classées selon des critères de classification : La priorité : Représente le degré d’importance entre les cas d’utilisation. Elle dépend du contexte de différentes fonctionnalités du système Nous pouvons classer les cas d’utilisation selon leur rang de priorité par rapport au nombre total de cas d’utilisation. Il s’agit d’une affectation des priorités de manière relative. Notre choix des priorités s’est basé sur la dépendance entre les fonctionnalités de l’application. Nous donnons à un cas d’utilisation A une plus grande priorité qu’un cas d’utilisation B. L’effort : représente l’estimation initiale de la quantité de travail nécessaire pour la réalisation d’un cas d’utilisation. Elle est calculée en nombre de jours/homme. Product Owner • Première Consulting Scrum Master • Amani Bouaziz L'équipe de développement • Raoua Bennasr
  • 30. Page 19 Thème Fonctionnalités Description Effort Priorité Gestion catégorie équipements Ajouter une catégorie En tant que Technicien j’ai le droit d’ajouter une catégorie. 1 1 Modifier une catégorie En tant que Technicien j’ai le droit de modifier une catégorie. 1 2 Supprimer une catégorie En tant que Technicien j’ai le droit de supprimer une catégorie. 1 3 Gestion Locaux équipements Ajouter un local En tant que Technicien j’ai le droit d’ajouter un local. 1 4 Modifier un local En tant que Technicien j’ai le droit de modifier un local. 1 5 Supprimer un local En tant que Technicien j’ai le droit de supprimer un local. 1 6 Gestion des fournisseurs équipements Ajouter un fournisseur En tant que Technicien, j’ai le droit d’ajouter un fournisseur. 1 7 Modifier un fournisseur En tant que Contrôleur, j’ai le droit de modifier un fournisseur. 1 8 Supprimer un fournisseur En tant que Technicien, j’ai le droit de supprimer un fournisseur. 1 9 Gestion des équipements Ajouter un équipement En tant que Technicien j’ai le droit d’ajouter un équipement. 2 10 Modifier un équipement En tant que Contrôleur, j’ai le droit de modifier un équipement. 2 11 Supprimer un équipement En tant que Technicien, j’ai le droit de supprimer un équipement. 1 12 Lister les équipements En tant que Contrôleur j’ai le droit de consulter les équipements. 1 13 Gestion Check listes équipements Ajouter une check-list En tant que Technicien, j’ai le droit d’ajouter une check-list. 3 14 Modifier une check-list En tant que Technicien, j’ai le droit de modifier une check-list. 2 15 Supprimer une check-list En tant que Technicien j’ai le droit de supprimer une check-list. 1 16
  • 31. Page 20 Gestion des Actions Ajouter une action En tant que Contrôleur j’ai le droit d’ajouter une action. 2 20 Modifier une action En tant que Contrôleur j’ai le droit de modifier une action. 2 21 Supprimer une action En tant que Contrôleur j’ai le droit de supprimer une action. 1 22 Lister les actions En tant que Technicien j’ai le droit de consulter les actions. 1 23 Gestion des contrôles Ajouter un contrôle En tant que Contrôleur j’ai le droit d’ajouter un contrôle. 3 24 Modifier un contrôle En tant que Contrôleur j’ai le droit de modifier un contrôle. 2 25 Supprimer un contrôle En tant que Contrôleur j’ai le droit de supprimer un contrôle. 1 26 Lister les contrôles En tant que Technicien j’ai le droit de consulter les contrôles. 1 27 Planification des contrôles Ajouter un planning du calendrier En tant que Contrôleur j’ai le droit d’ajouter un planning. 3 28 Modifier un planning du calendrier En tant que Contrôleur j’ai le droit de modifier un planning. 2 29 Supprimer un planning du calendrier En tant que Contrôleur j’ai le droit de supprimer un planning. 1 30 Consulter calendrier des plannings En tant que Technicien j’ai le droit de calendrier des plannings. 2 31 Gestion profil administrateur Consulter profil En tant qu’administrateur j’ai le droit de consulter mon profil 1 32 Modifier profil En tant qu’administrateur j’ai le droit de modifier mon profil 2 33 Authentification S’authentifier En tant qu’administrateur je dois m’authentifier pour accéder a l’application 1 34 Gestion des sites Ajouter un site En tant qu’administrateur j’ai le droit d’ajouter un site. 1 35
  • 32. Page 21 Table 1: Backlog du produit Modifier un site En tant qu’administrateur j’ai le droit de modifier un site. 1 36 Supprimer un site En tant qu’administrateur j’ai le droit de supprimer un site. 1 37 Gestion des super Utilisateurs Ajouter un super utilisateur En tant qu’administrateur j’ai le droit d’ajouter un super utilisateur. 2 38 Modifier un super utilisateur En tant qu’administrateur j’ai le droit de modifier super-utilisateur. 2 39 Supprimer un super utilisateur En tant que super utilisateur j’ai le droit de supprimer un membre. 1 40 Gestion des membres Ajouter un membre En tant que super utilisateur j’ai le droit d’ajouter un membre. 1 17 Modifier un membre En tant que super utilisateur, j’ai le droit de modifier un membre. 1 18 Supprimer un membre En tant que super utilisateur, j’ai le droit de supprimer un membre. 1 19 Consulter les statistiques Consulter les Statistique En tant qu’administrateur, j’ai le de consulter les statistiques. 3 41
  • 33. Page 22 3. Planification des sprints du projet Le but de la planification des sprints du projet est de préparer le planning de travail et d’identifier le Backlog des sprints. La planification des sprints est schématisée dans le graphique suivant : Conclusion Durant ce chapitre, nous avons identifié les besoins fonctionnels et les besoins non fonctionnels, Nous avons également réalisé les maquettes prévisionnelles, le backlog du produit ainsi que la répartition des sprints à réaliser. Dans le chapitre suivant nous allons développer le release 1. RELEASE 1 SPRINT 1 Gestion catégories Gestion locaux Gestion fournisseurs Gestion check-lists Gestion équipements De 01-04 à 21/04 Gestion membres Gestion Actions Gestion Contrôles Planification De 22-04 à 12-05 RELEASE 2 Gestion sites Gestion super utilisateurs De 13-05 à 19-05 Gestion profil administrateur Authentification Consulter des Statistiques De 20-05 à 26-05 SPRINT 2 SPRINT 1 SPRINT 2
  • 34. Page 23 Chapitre 3 : Release 1 du projet
  • 35. Page 24 Chapitre 3 : Release 1 du projet Introduction Une fois l’analyse des besoins et la spécification des exigences du projet sont élaborées, nous allons donc dans ce chapitre présenter notre premier release qui comporte 2 sprints dont chacun a une période de 3 semaines. I. Premier Sprint Le sprint est une période qui dure entre une et quatre semaines, au bout de cette période l’équipe doit réaliser un incrément de produit livrable. Un nouveau sprint démarre lorsque le précèdent est terminée. Le tableau ci-dessous présente le backlog de notre premier sprint Table 2: Backlog du premier sprint (release 1) Thème Fonctionnalités Estimation Gestion catégorie équipements Ajouter une catégorie 1 Modifier une catégorie 1 Supprimer une catégorie 1 Gestion Locaux équipements Ajouter un local 1 Modifier un local 1 Supprimer un local 1 Gestion des fournisseurs équipements Ajouter un fournisseur 1 Modifier un fournisseur 1 Supprimer un fournisseur 1 Gestion des équipements Ajouter un équipement 2 Modifier un équipement 2 Supprimer un équipement 1 Lister les équipements 1 Gestion Check listes équipements Ajouter une check-list 3 Modifier une check-list 2 Supprimer une check-list 1
  • 36. Page 25 1. Spécification fonctionnelle La spécification fonctionnelle se traduit par un diagramme de cas d’utilisation global du sprint et des diagrammes de cas d’utilisation raffinés ainsi que quelques descriptions textuelle. 1.1.Diagramme de cas d’utilisation du sprint 1 La figure 12 ci-dessous illustre le diagramme des cas d’utilisation du premier sprint. Figure 13: Diagramme de cas d'utilisation global du Sprint 1
  • 37. Page 26 1.2.Raffinement des cas d’utilisation du sprint 1 La figure 13 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation du premier sprint : Figure 14: Diagramme de cas d'utilisation détaillé du Sprint 1
  • 38. Page 27 1.3.Description textuelle des cas d’utilisation Nous traitons uniquement les cas d’utilisation :  « Ajouter équipement » puisqu’il est similaire aux cas « Ajouter catégorie », «Ajouter check-list », « Ajouter local », « Ajouter fournisseur ».  « Modifier équipement » puisqu’il est similaire aux cas « Modifier catégorie», «Modifier check-list», « Modifier local », «Modifier fournisseur ».  « Supprimer équipement » puisqu’il est similaire aux cas « Supprimer catégorie», «Supprimer check-list », « Supprimer local » », «Supprimer fournisseur ».  « Consulter la liste des équipements ». Nous détaillons à travers les tableaux descriptifs suivant, les cas d’utilisation « ajouter équipement « modifier équipement », « supprimer équipement » et « consulter la liste des équipements »  Description textuelle du cas « Ajouter équipement » Cas d’utilisation Ajouter équipement Acteurs Technicien Pré-condition Acteur authentifié. Post-condition Equipement ajouté. Scénario principal 1. Le technicien demande le formulaire d’ajout. 2. Le système affiche le formulaire. 3. Le technicien remplit les champs et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre le nouvel équipement. Scénario alternatif Le technicien saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 3: Description textuelle du cas d’utilisation « Ajouter équipement»
  • 39. Page 28  Description textuelle du cas « Modifier équipement » Cas d’utilisation Modifier équipement Acteurs Technicien Pré-condition Acteur authentifié. Post-condition Equipement modifié. Scénario principal 1. Le technicien choisit l’équipement à modifier. 2. Le système affiche le formulaire de modification. 3. Le technicien modifie les informations de l’équipement et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre la modification de l’équipement. 6. Le système redirige le technicien vers la liste des équipements. Scénario alternatif Le technicien saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 4: Description textuelle du cas d’utilisation « Modifier équipement»  Description textuelle du cas « Supprimer équipement » Cas d’utilisation Supprimer équipement Acteurs Technicien Pré-condition Acteur authentifié. Post-condition Equipement supprimé. Scénario principal 1. Le technicien choisit l’équipement à supprimer. 2. Le système affiche un message de confirmation. 3. Le technicien valide son choix 4. Le système supprime l’équipement. 5. Le système redirige le technicien vers la liste des équipements. Scénario alternatif Le technicien annule son choix Le système annule la suppression Table 5: Description textuelle du cas d’utilisation « Supprimer équipement»
  • 40. Page 29  Description textuelle du cas « Consulter la liste des équipements » Cas d’utilisation Consulter la liste des équipements Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition Liste des équipements affichés. Scénario principal 1. Le technicien demande la liste des équipements. 2. Le système affiche la liste des équipements. Table 6: Description textuelle du cas d’utilisation « Consulter la liste des équipements» 2. Conception La conception est la deuxième partie dans un sprint. Elle se traduit par les diagrammes de séquence système, de classes participantes, de séquence détaillée et le diagramme de classe du premier sprint. 2.1. Diagrammes de séquence système Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling Language. [5] Nous nous intéressons dans cette partie à présenter les diagrammes de séquence système du cas d’utilisation « Ajouter équipement » , « Modifier équipement », « Supprimer équipements» et « consulter la liste des équipements ».
  • 41. Page 30  Diagramme de séquence système du cas « ajouter équipement» La figure15 illustre le diagramme de séquence système correspondant au cas d’utilisation « Ajouter équipement » décrit par le tableau 3. Figure 15: Diagramme de séquence système du cas d'utilisation « Ajouter équipement»  Diagramme de séquence système du cas « Modifier équipement» La figure 16 illustre le diagramme de séquence système correspondant au cas d’utilisation « Modifier équipement » décrit par le tableau 4. Figure 16: Diagramme de séquence système du cas d'utilisation « Modifier équipement»
  • 42. Page 31  Diagramme de séquence système du cas « Supprimer équipement» La figure 17 illustre le diagramme de séquence système correspondant au cas d’utilisation « Supprimer équipement » décrit par le tableau 5. Figure 17: Diagramme de séquence système du cas d'utilisation « Supprimer équipement»  Diagramme de séquence système du cas « Consulter liste des équipements» La figure 18 illustre le diagramme de séquence système correspondant au cas d’utilisation « Consulter liste des équipements » décrit par le tableau 6. Figure 18: Diagramme de séquence système du cas d'utilisation « Consulter liste des équipements»
  • 43. Page 32 2.2. Diagrammes des classes participantes Le diagramme de classes participantes est particulièrement important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation le modèle du domaine et la maquette et d'autre part, les diagrammes de conception logicielle que sont les diagrammes d'interaction et le diagramme de classes de conception. [6] Dans Notre diagramme des classes participantes, nous avons distingué trois stéréotypes de classes qui sont : Classe dialogue : Représente les interfaces IHM de l’application (interface). Classe contrôle : classe application contenant les actions à effectuer (contrôle). Classe entité : classe métier contenant les données de chaque modèle (entité). Dans ce cas, nous présentons quelques diagrammes des classes participantes et nous avons spécifié les classes dialogues par UI « User Interface » et les classes « contrôle » par C.  Diagramme des classes participantes du cas d’utilisation « Gestion catégorie équipement» La figure ci-dessous décrit le diagramme de la classe participante « Gestion catégorie équipement ». Figure 19: Diagramme des classes participantes du cas d’utilisation« Gestion Catégorie équipement»
  • 44. Page 33  Diagramme des classes participantes du cas d’utilisation « Gestion équipement» La figure ci-dessous décrit le diagramme de la classe participante « Gestion équipement ». Figure 20: Diagramme des classes participantes du cas d’utilisation« Gestion équipement» 2.3. Diagrammes de séquences détaillés Le diagramme de séquence détaillé est le même que le diagramme de séquence système, sauf que, nous allons répartir le système à des composants d’interaction pour mieux comprendre le scénario. Nous choisissons de présenter les diagrammes de séquence système détaillé « Ajouter équipement » et « Consulter liste des équipements».  Diagramme de séquence détaillé du cas d'utilisation « Ajouter équipement » La figure 21 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Ajouter équipement » illustré par la figure 15.
  • 45. Page 34 Figure 21 : Diagramme de séquences détaillé « Ajouter équipement »  Diagramme de séquence détaillé du cas d'utilisation «Consulter la liste des équipements » La figure 22 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Consulter la liste des équipements »illustré par la figure 16 Figure 22: Diagramme de séquences détaillé « Consulter la liste des équipements »
  • 46. Page 35 2.4. Diagramme des classes de sprint 1 La figure 23 représente le diagramme de classe du notre premier sprint. Ce diagramme illustre Les différentes classes constituant le système, leurs attributs, leurs méthodes ainsi que les associations entre elles. Figure 23: Diagramme de classe du sprint 1 3. Codage Dans cette partie, nous allons présenter le schéma de la base de données de notre sprint
  • 47. Page 36 Dans ce qui suit, nous présentons le schéma de la base de données. Figure 24: Table «équipement » Figure 25: Table «catégorie » Figure 26: Table «CheckListe »
  • 48. Page 37 Figure 27: Table «équipement » Figure 28: Table «local » 4. Les interfaces Nous allons présenter dans ce qui suit, les imprimes-écran des quelques interfaces réalisées dans le sprint 1 du release 1.  Interface « Gestion équipements » Figure 29: Interface « Gestion équipements »
  • 49. Page 38  Interface « Ajouter équipement » Figure 30: Interface « Ajouter équipement »  Interface « Modifier équipement » Figure 31: Interface « Modifier équipement »
  • 50. Page 39  Interface « Gestion catégorie » Figure 32: Interface « Gestion catégorie »  Interface « Gestion Check-list » Figure 33: Interface « Gestion Check-list »
  • 51. Page 40  Interface « Gestion fournisseur » Figure 34: Interface « Gestion fournisseur»  Interface « Gestion Locaux » Figure 35: Interface « Gestion fournisseur»
  • 52. Page 41  Interface « Consulter équipements » Figure 36: Interface « Consulter équipements»  Interface « Consulter équipements » de l’application mobile Figure 37: Interface « équipements»
  • 53. Page 42  Interface « rechercher un équipement par un QRCode Figure 38: Interface « Recherche un équipement par QRCode»  Interface « Consulter un seul équipement « Figure 39: Interface « Consulter un seul équipement»
  • 54. Page 43 II. Deuxième Sprint Notre deuxième sprint s’intéresse à l’ensemble des fonctionnalités de « Gestion des membres », « Gestion des actions », « Gestion des Contrôle s» et «Planification». Par la suite, le backlog du sprint 2 de la release 1 est illustré par le tableau suivant : Table 7: Backlog du deuxième sprint (release 1) 1. Spécification fonctionnelle En respectant la même démarche adoptée au cours du premier sprint, la spécification fonctionnelle du deuxième sprint 2 se traduit par : La définition du diagramme de cas d’utilisation global du sprint, les diagrammes de cas d’utilisation raffinés et leurs descriptions textuelles. Thème Fonctionnalités Estimation Gestion des Actions Ajouter une action 2 Modifier une action 2 Supprimer une action 1 Lister les actions 1 Gestion des contrôles Ajouter un contrôle 3 Modifier un contrôle 2 Supprimer un contrôle 1 Lister les contrôles 1 Planification des contrôles Ajouter un planning du calendrier 3 Modifier un planning du calendrier 2 Supprimer un planning du calendrier 1 Consulter calendrier des plannings 2 Gestion des membres Ajouter un membre 1 Modifier un membre 1 Supprimer un membre 1
  • 55. Page 44 1.1. Diagramme de cas d’utilisation du sprint 2 La figure 40 ci-dessous illustre le diagramme des cas d’utilisation du deuxième sprint. Figure 40: diagramme des cas d’utilisation du deuxième sprint
  • 56. Page 45 1.2.Raffinement des cas d’utilisation du sprint 2 La figure 41 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation du deuxième sprint : Figure 41: diagramme des cas d’utilisation détaillé du deuxième sprint
  • 57. Page 46 1.3.Description textuelle des cas d’utilisation Nous traitons uniquement les cas d’utilisation :  « Ajouter Action», « Modifier Action », « Supprimer Action » puis qu’il sont similaire aux cas d’utilisations de la fonctionnalité « Gestion membre ».  « Ajouter Contrôle » de la fonctionnalité « Gestion Contrôle ».  « Ajouter planning » de la fonctionnalité « planification des contrôle».  « Consulter les Actions » puisqu’il est similaire aux cas d’utilisations « Consulter les Contrôles », «Consulter Planification». Nous détaillons à travers les tableaux descriptifs suivant, les cas d’utilisation « Ajouter Action », « Modifier Action », « Supprimer Action », « Ajouter Contrôle », « Ajouter planning » et « Consulter les Actions »  Description textuelle du cas « Ajouter Action » Cas d’utilisation Ajouter Action Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition Action ajoutée. Scénario principal 1. Le Contrôleur demande le formulaire d’ajout. 2. Le système affiche le formulaire. 3. Le Contrôleur remplit les champs et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre la nouvelle Action. Scénario alternatif Le Contrôleur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 8: Description textuelle du cas d’utilisation « Ajouter Action»
  • 58. Page 47  Description textuelle du cas « Modifier Action» Cas d’utilisation Modifier Action Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition Action modifiée. Scénario principal 1. Le contrôleur choisit l’action à modifier. 2. Le système affiche le formulaire de modification. 3. Le contrôleur modifie les informations de l’action et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre la modification de l’action. 6. Le système redirige le contrôleur vers la liste des actions. Scénario alternatif Le contrôleur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 9: Description textuelle du cas d’utilisation « Modifier action»  Description textuelle du cas « Supprimer action » Cas d’utilisation Supprimer action Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition action supprimée. Scénario principal 1. Le contrôleur choisit l’action à supprimer. 2. Le système affiche un message de confirmation. 3. Le contrôleur valide son choix 4. Le système supprime l’action. 5. Le système redirige le contrôleur vers la liste des actions. Scénario alternatif Le contrôleur annule son choix Le système annule la suppression Table 10: Description textuelle du cas d’utilisation « Supprimer action»
  • 59. Page 48  Description textuelle du cas « Ajouter Contrôle » Cas d’utilisation Ajouter Contrôle Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition Contrôle ajouté. Scénario principal 1. Le Contrôleur demande le formulaire d’ajout. 2. Le système affiche le formulaire. 3. Le Contrôleur remplit les champs et contrôler les éléments de l’équipement avec la check liste puis valide. 4. Le système vérifie les données saisies. 5. Le système enregistre le nouveau contrôle. Scénario alternatif  Si le contrôle avec la check liste de vérification inferieur à 50% le contrôleur cocher bouton « équipement non valide » Le système affiche un pop-up du formulaire d’ajout action avec les pannes trouvées dans le contrôle.  Le Contrôleur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 11: Description textuelle du cas d’utilisation « Ajouter Contrôle»
  • 60. Page 49  Description textuelle du cas « Ajouter Planning » Cas d’utilisation Ajouter Planning Acteurs Contrôleur Pré-condition Acteur authentifié. Post-condition Planning ajouté. Scénario principal 1. Le Contrôleur demande le calendrier. 2. Le Contrôleur choisir une date de contrôle. 3. Le système affiche le formulaire. 4. Le Contrôleur remplit les champs puis valide. 5. Le système vérifie les données saisies. 6. Le système enregistre le nouveau planning. Scénario alternatif  Le Contrôleur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 12: Description textuelle du cas d’utilisation « Ajouter Planning»  Description textuelle du cas « Consulter les actions » Cas d’utilisation Consulter les Actions Acteurs Technicien Pré-condition Acteur authentifié. Post-condition Liste actions affichés. Scénario principal 1. Le contrôleur demande la liste des actions. 2. Le système affiche la liste des actions. Table 13: Description textuelle du cas d’utilisation « Consulter les actions»
  • 61. Page 50 2. Conception Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et le diagramme de classe du deuxième sprint. 2.1. Diagrammes de séquence système A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes de séquences systèmes « Ajouter action », « Modifier action », « Supprimer action », « Ajouter Contrôle », « Ajouter planning » et « Consulter les actions »  Diagramme de séquence système du cas «Ajouter action» La figure 42 illustre le diagramme de séquence système correspondant au cas d’utilisation « Ajouter action » décrit par le tableau 8. Figure 42: Diagramme de séquence système du cas d'utilisation « Ajouter action»
  • 62. Page 51  Diagramme de séquence système du cas « Modifier action» La figure 43 illustre le diagramme de séquence système correspondant au cas d’utilisation « Modifier action » décrit par le tableau 9. Figure 43: Diagramme de séquence système du cas d'utilisation « Modifier action»  Diagramme de séquence système du cas « Supprimer action» La figure 44 illustre le diagramme de séquence système correspondant au cas d’utilisation « Supprimer action » décrit par le tableau 10.
  • 63. Page 52 Figure 44: Diagramme de séquence système du cas d'utilisation « Supprimer action»  Diagramme de séquence système du cas « Consulter les actions» La figure 45 illustre le diagramme de séquence système correspondant au cas d’utilisation « Consulter les actions » décrit par le tableau 13. Figure 45: Diagramme de séquence système du cas d'utilisation « Consulter les actions»
  • 64. Page 53  Diagramme de séquence système du cas « Ajouter Contrôle» La figure 46 illustre le diagramme de séquence système correspondant au cas d’utilisation « Ajouter contrôle » décrit par le tableau 11. Figure 46: Diagramme de séquence système du cas d'utilisation « Ajouter Contrôles»
  • 65. Page 54  Diagramme de séquence système du cas « Ajouter Planning» La figure 47 illustre le diagramme de séquence système correspondant au cas d’utilisation « Ajouter Planning » décrit par le tableau 12. Figure 47: Diagramme de séquence système du cas d'utilisation « Ajouter Planning»
  • 66. Page 55 2.2. Diagrammes des classes participantes  Diagrammes de classes participantes «Gestion actions » Figure 48: Diagramme des classes participantes du cas d’utilisation« Gestion actions»  Diagrammes de classes participantes «Gestion Contrôle » Figure 49: Diagramme des classes participantes du cas d’utilisation« Gestion Contrôle»
  • 67. Page 56  Diagrammes de classes participantes «Planification» Figure 50: Diagramme des classes participantes du cas d’utilisation« Planification» 2.3. Diagrammes de séquences détaillés Pour le sprint 2, Nous choisissons de présenter les diagrammes de séquence système détaillé de cas d’utilisation «Ajouter action » «consulter les actions »  Diagramme de séquence détaillé du cas d'utilisation « Ajouter action » La figure 51 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Ajouter action» illustré par la figure 42.
  • 68. Page 57 Figure 51: Diagramme de séquences détaillé « Ajouter action »  Diagramme de séquence détaillé du cas d'utilisation « Consulter les actions» La figure 52 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Consulter les actions » illustré par la figure 43. Figure 52: Diagramme de séquences détaillé « Consulter les actions »
  • 69. Page 58 2.4. Diagramme des classes de sprint 2 La figure 53 représente le diagramme de classe du sprint 2 du release 1.  Pour la classe planification nous avons un champ couleur dédié à la spécification de la date de contrôle dans le calendrier de l’interface de l’application.  Dans notre diagramme de classe nous avons une classe catégorie reliée avec la classe équipement. Une catégorie à un numéro de série et chaque équipement est identifié par une référence unique. Figure 53: Diagramme de classe du sprint 2
  • 70. Page 59 3. Codage Les figures ci-dessous représentent le schéma de la base de données de ce sprint. Figure 54 : table Contrôle Figure 55 : table Action
  • 71. Page 60 Figure 56 : table Planification Figure 57 : table Membre 4. Les interfaces Nous passons à présenter quelques interfaces réalisées lors du notre deuxième sprint release 1.  Interface de l’application web
  • 72. Page 61  Interface « Gestion Contrôles » Figure 58 : Interface Gestion Contrôles  Interface « Ajouter Contrôle» Figure 59 : Interface Ajouter Contrôle
  • 73. Page 62  Interface « Gestion Actions » Figure 60 : Interface Gestion Actions  Interface « Ajouter Action » Figure 61: Interface Ajouter Action
  • 74. Page 63  Interface «Planification » Figure 62: Interface Planification  Interface «Ajouter Planning » Figure 63: Interface Ajouter planning
  • 75. Page 64  Interface «Consulter Actions» Figure 64 : Interface Consulter Actions  Interface «Consulter Contrôles» Figure 65 : Interface Consulter Contrôles
  • 76. Page 65  Interface «Gestion Membre» Figure 66 : Interface Gestion Membre  Quelques Interfaces de l’application mobile Figure 67 : Interface Ajouter Contrôle Figure 68 : Interface Liste des Contrôles
  • 77. Page 66 Figure 69 : Interface Ajouter Action Conclusion Nous arrivons à la fin de développement de premier release qui concerne la gestion des actions, des contrôles, des membres et planification. Suivant le même plan de travail, nous présenterons dans le chapitre qui suit le deuxième release de ce projet
  • 78. Page 67 Chapitre 4 : Release 2 du projet
  • 79. Page 68 Chapitre 4 : Release 2 du projet Introduction Après avoir terminé le premier release, nous commençons maintenant à produire le deuxième release qui définit le deuxième incrément du notre projet et qui comporte deux sprints. I. Premier Sprint Notre premier sprint pour la deuxième release s’intéresse à l’ensemble des fonctionnalités de « Gestion des sites » et « Gestion des super utilisateur ». Le tableau ci-dessous présente le backlog de notre premier sprint Table 14: Backlog du premier sprint (release 2) 1. Spécification fonctionnelle Nous présentons dans cette partie les diagrammes de cas d’utilisation et leurs descriptions textuelles. Thème Fonctionnalités Estimtion Gestion des sites Ajouter un site 1 Modifier un site 1 Supprimer un site 1 Gestion des super Utilisateurs Ajouter un super utilisateur 2 Modifier un super utilisateur 2 Supprimer un super utilisateur 1
  • 80. Page 69 1.1. Diagramme de cas d’utilisation du sprint La figure 69 ci-dessous illustre le diagramme des cas d’utilisation du sprint 1. Figure 69: diagramme des cas d’utilisation du sprint 1 1.2.Raffinement des cas d’utilisation du sprint La figure 70 ci-dessous illustre le diagramme des cas d’utilisation détaillé du sprint 1. Figure 70: diagramme des cas d’utilisation détaillé du sprint 1
  • 81. Page 70 1.3.Description textuelle des cas d’utilisation Nous traitons uniquement les cas d’utilisation :  « Ajouter Site » puisqu’il est similaire au cas « Ajouter super user».  « Modifier Site » puisqu’il est similaire au cas « Modifier super user».  « Supprimer Site » puisqu’il est similaire au cas « Supprimer super user».  Description textuelle du cas « Ajouter Site » Cas d’utilisation Ajouter Site Acteurs Administrateur Pré-condition Acteur authentifié. Post-condition Site ajouté. Scénario principal 1. L’administrateur demande le formulaire d’ajout. 2. Le système affiche le formulaire. 3. L’administrateur remplit les champs et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre le site. Scénario alternatif L’administrateur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 2 du scénario principal. Table 15: Description textuelle du cas d’utilisation « Ajouter Site»
  • 82. Page 71  Description textuelle du cas « Modifier Site» Cas d’utilisation Modifier Site Acteurs Administrateur Pré-condition Acteur authentifié. Post-condition Site modifié. Scénario principal 1. L’administrateur choisit le site à modifier. 2. Le système affiche le formulaire de modification. 3. L’administrateur modifie les informations du site et valide. 4. Le système vérifie les données saisies. 5. Le système enregistre la modification du site. 6. Le système redirige l’administrateur vers la liste des sites. Scénario alternatif L’administrateur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 16: Description textuelle du cas d’utilisation « Modifier site»  Description textuelle du cas « Supprimer Site » Cas d’utilisation Supprimer Site Acteurs Administrateur Pré-condition Acteur authentifié. Post-condition site supprimé. Scénario principal 1. L’administrateur choisit un site à supprimer. 2. Le système affiche un message de confirmation. 3. L’administrateur valide son choix 4. Le système supprime le site. 5. Le système redirige l’administrateur vers la liste des sites. Scénario alternatif L’administrateur annule son choix Le système annule la suppression Table 17: Description textuelle du cas d’utilisation « Supprimer site»
  • 83. Page 72 2. Conception Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et le diagramme de classe du sprint 1 du release 2. 2.1. Diagrammes de séquence système A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes de séquences systèmes « Ajouter Site », « Modifier Site », « Supprimer Site ».  Diagramme de séquence système du cas «Ajouter Site» Figure 71: diagramme de séquence système du cas «Ajouter Site»
  • 84. Page 73  Diagramme de séquence système du cas «Modifier Site» Figure 72: diagramme de séquence système du cas «Modifier Site»  Diagramme de séquence système du cas «Supprimer Site» Figure 73: diagramme de séquence système du cas «Supprimer Site»
  • 85. Page 74 2.2. Diagrammes des classes participantes  Diagrammes de classes participantes «Gestion Sites » Figure 74 : Diagramme des classes participantes du cas d’utilisation« Gestion Sites»  Diagrammes de classes participantes «Gestion super user » Figure 75 : Diagramme des classes participantes du cas d’utilisation« Gestion super user »
  • 86. Page 75 2.3. Diagrammes de séquences détaillés Pour ce sprint, nous choisissons de présenter le diagramme de séquence détaillé de cas d’utilisation «Ajouter Site ».  Diagramme de séquence détaillé du cas d'utilisation « Ajouter site » La figure 76 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Ajouter Site » illustré par la figure 71. Figure 76: diagramme de séquence détaillé du cas «Ajouter Site»  Diagramme de séquence détaillé du cas d'utilisation « Ajouter super user » La figure 77 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Ajouter super user ».
  • 87. Page 76 Figure 77: diagramme de séquence détaillé du cas «Ajouter super user» 2.4. Diagramme des classes de sprint 1 La figure 78 représente le diagramme de classe du sprint 1 du release 2. Figure 78: Diagramme de classe du sprint 2
  • 88. Page 77 3. Codage Les figures ci-dessous représentent le schéma de la base de données de ce sprint. Figure 79: Table site Figure 80: Table super user 4. Les interfaces Nous passons à présenter quelques interfaces réalisées lors du notre premier sprint release 2.
  • 89. Page 78  Interface « Gestion sites» Figure 81 : Interface Gestion sites  Interface « Gestion super utilisateur» Figure 82 : Interface Gestion super utilisateur
  • 90. Page 79 II. Deuxième Sprint Notre deuxième sprint s’intéresse à l’ensemble des fonctionnalités de « Gestion profil», « Authentification » et « Consulter les statistiques ». Par la suite, le backlog du sprint 2 de la release 2 est illustré par le tableau suivant : Table 18: Backlog du deuxième sprint (release 2) 1. Spécification fonctionnelle En respectant la même démarche adoptée au cours du premier sprint, la spécification fonctionnelle du deuxième sprint 2 se traduit par La définition du diagramme de cas d’utilisation global du sprint, les diagrammes de cas d’utilisation raffinés et leurs descriptions textuelles. 1.1. Diagramme de cas d’utilisation du sprint 2 La figure 83 ci-dessous illustre le diagramme des cas d’utilisation du deuxième sprint. Figure 83: diagramme des cas d’utilisation du deuxième sprint Thème Fonctionnalités Estimation Gestion profil administrateur Consulter profil 1 Modifier profil 2 Authentification S’authentifier 1 Consulter les statistiques Consulter les Statistiques 3
  • 91. Page 80 1.2.Raffinement des cas d’utilisation du sprint 2 La figure 84 représente le diagramme du cas d’utilisation détaillé relatif au cas d’utilisation du deuxième sprint : Figure 84: diagramme des cas d’utilisation détaillé du deuxième sprint 1.3.Description textuelle des cas d’utilisation Nous traitons uniquement les cas d’utilisation « Consulter profil », « Modifier profil », « Authentification ». Description textuelle du cas « Consulter profil » Cas d’utilisation Consulter profil Acteurs Administrateur Pré-condition Acteur authentifié. Post-condition Profile affiché Scénario principal 1. L’administrateur demande de consulter son profil. 2. Le système affiche le profil Table 19: Description textuelle du cas d’utilisation « Consulter Profil»
  • 92. Page 81  Description textuelle du cas « Modifier profil» Cas d’utilisation Modifier profil Acteurs Administrateur Pré-condition Acteur authentifié. Post-condition Profil modifié Scénario principal L’administrateur demande de modifier son profil. Le système affiche le formulaire de modification. L’administrateur modifie les informations et valide. 2-Le système vérifie les données saisies 3-Le système enregistre la modification 4-Le système redirige l’administrateur vers son profil Scénario alternatif L’administrateur saisit des données manquantes ou erronées : Le système affiche un message d’erreur. Reprise de l’étape 3 du scénario principal. Table 20: Description textuelle du cas d’utilisation « Modifier Profil»  Description textuelle du cas «Authentification » Cas d’utilisation Authentification Acteurs Administrateur, super user, membre Post-condition Accès à l’espace personnel Scénario principal L’acteur saisie son login et son mot de passe 2. Le système vérifie les informations saisies 3-Le système redirige l’acteur vers son espace Scénario alternatif  L’acteur saisit des données manquantes Le système affiche un message d’erreur Reprise de l’étape 1 du scénario nominal  Les données saisies sont invalides -Le système affiche un message d’erreur Reprise de l’étape 1 du scénario nominal Table 21: Description textuelle du cas d’utilisation «Authentification»
  • 93. Page 82 2. Conception Nous présentons dans ce qui suit, les diagrammes de séquences systèmes des différents cas d’utilisation, les diagrammes de classes participantes, les diagrammes de séquence détaillé et le diagramme de classe du sprint2 du release 2. 2.1. Diagrammes de séquence système A partir de la description textuelle dans la partie précédente, nous présentons les diagrammes de séquences systèmes « Authentification», « Modifier profil ».  Diagramme de séquence système du cas «Authentification» Figure 85: diagramme de séquence système du cas «Authentification»
  • 94. Page 83  Diagramme de séquence système du cas «Modifier profil» Figure 86: diagramme de séquence système du cas «Modifier profil»
  • 95. Page 84 2.2. Diagrammes des classes participantes  Diagrammes de classes participantes «Gestion profil» Figure 87: diagramme de classes participantes «Gestion profil»  Diagrammes de classes participantes «Authentification» Figure 88: diagramme de classes participantes «Authentification»
  • 96. Page 85 2.3. Diagrammes de séquences détaillés Pour ce sprint, nous choisissons de présenter le diagramme de séquence détaillé de cas d’utilisation «Modifier Profil ».  Diagramme de séquence détaillé du cas d'utilisation « Modifier profil » La figure 89 représente le diagramme de séquence système détaillé correspondant au diagramme de séquence système « Modifier profil ». Figure 89: Diagramme de séquence détaillé du cas d'utilisation « Modifier profil »
  • 97. Page 86 3. Codage La figure ci-dessous représente le schéma de la base de données de ce sprint. Figure 90: Table Administrateur 4. Les interfaces Nous passons à présenter quelques interfaces réalisées lors du notre deuxième sprint release  Interface « Authentification» Figure 91: Interface « Authentification»
  • 98. Page 87  Interface « Consulter profil» Figure 92: Interface « Consulter profil»  Interface « Modifier profil» Figure 93: Interface « Modifier profil»
  • 99. Page 88 5. Diagramme des classes global La figure 94 représente le diagramme de classe de notre application. Ce diagramme illustre les différentes entités manipulées par notre système ainsi que les relations existantes entre elles. Figure 94: Diagramme des classes global Conclusion A la fin de ce chapitre, nous avons réussi à terminer le dernier release de notre projet Le chapitre suivant portera sur la phase de clôture de notre projet.
  • 100. Page 89 Chapitre 5 : Phase de clôture
  • 101. Page 90 Chapitre 5 : Phase de clôture Introduction La phase clôture est la phase final du projet qui contient l’environnement du travail matériel et logiciel. Par la suite, nous présentons l’architecture opérationnelle de notre projet. I. Environnement de travail Dans cette partie nous présentons l’environnement matériel et l’environnement logiciel pour la réalisation du notre application. 1. Environnement matériel Pour réaliser le projet, nous avons utilisé comme environnement matériel une machine qui possède les caractéristiques suivantes : Processeur Intel(R)Core(TM) i-4005U CPU @ 1.70GHz Mémoire (RAM) 4GO Système d’exploitation Windows 10 Pro Disque dur 500 GB Table 22 : Les caractéristiques d’environnement du travail
  • 102. Page 91 2. Environnement logiciel 2.1. Outils et logiciels  Visual studio 2015 : Visual Studio est un ensemble complet d'outils de développement permettant de générer des applications web ASP.NET, des services web XML, des applications bureautiques et des applications mobiles. Visual Basic, Visual C++, Visual C# utilisent tous le même environnement de développement intégré (IDE), qui leur permet de partager des outils et facilite la création de solutions faisant appel à plusieurs langages. [7]  Xampp : XAMPP est un ensemble de logiciels permettant de mettre en place facilement un serveur Web local, un serveur FTP et un serveur de messagerie électronique. Il s'agit d'une distribution de logiciels libres (X (cross) Apache MariaDB Perl PHP) offrant une bonne souplesse d'utilisation, réputée pour son installation simple et rapide. [8]  Android studio : Android Studio est un environnement de développement pour développer des applications mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de production Gradle.  StarUML : StarUML est un logiciel de modélisation UML, qui a été "cédé comme open source" par son éditeur", à la fin de son exploitation commerciale (qui visiblement continue ...), sous une licence modifiée de GNU GPL.[10]
  • 103. Page 92 2.2. Technologies  ASP.NET : ASP.NET est un framework permettant de générer à la demande des pages web, lancée par Microsoft en juillet 20002, et utilisée pour mettre en œuvre des applications web3. Il s'agit d'une évolution majeure d'Active Server Pages (ASP, alias Classic ASP), par laquelle cette technique a été incorporée dans la plateforme Microsoft .NET4.[11]  HTML : L’HyperText Markup Language, généralement abrégé HTML, est le langage de balisage conçu pour représenter les pages web. C’est un langage permettant d’écrire de l’hypertexte, d’où son nom. HTML permet également de structurer sémantiquement et logiquement et de mettre en forme le contenu des pages, d’inclure des ressources multimédias dont des images, des formulaires de saisie et des programmes informatiques. [12]  Bootstrap : Bootstrap est une collection d'outils utiles à la création du design (graphisme, animation et interactions avec la page dans le navigateur, etc.) de sites et d'applications web. [13]  Jquery : jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture de scripts côté client dans le code HTML des pages web2.[14]  Json : JavaScript Object Notation (JSON) est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Il permet de représenter de l’information structurée comme le permet XML par exemple. [15]  Service Web REST : Les services web REST (REpresentational State Transfer) sont plus un ensemble de bonnes pratiques à suivre afin de réaliser un service web respectant les principes REST. Ils utilisent le protocole HTTP afin de communiquer avec les applications clientes. Il sera donc possible d’insérer, de mettre à jour, de supprimer et de récupérer des informations (POST, PUT, DELETE, GET). [16]