Ce document présente un rapport de projet de fin d'études sur le développement d'une application pour la gestion des équipements de sécurité et de lutte contre les incendies dans les bâtiments, réalisé par Raoua Bennasr. Il inclut une étude approfondie du projet, la méthodologie agile adoptée (Scrum), les phases de planification et de développement, ainsi que des spécifications fonctionnelles détaillées. Le travail a été encadré par des professionnels et vise à répondre à des besoins spécifiques dans un contexte organisationnel.

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]

104. Page 93
3. Déploiement
3.2. Architecture opérationnelle
Nous avons adopté l’architecture 3 tiers comme architecture d’implémentation de notre
application.
Figure 95 : l’architecture 3 tiers
L'architecture trois tiers aussi appelée architecture à trois niveaux ou architecture à trois
couches, est l'application du modèle plus général qu'est le multi-tiers. L'architecture logique
du système est divisée en trois niveaux ou couches :
 couche de présentation : la présentation des données, correspondant à l'affichage, la
restitution sur le poste de travail, le dialogue avec l'utilisateur ;
 couche de traitement : métier des données, correspondant à la mise en œuvre de
l'ensemble des règles de gestion et de la logique applicative
 couche d'accès aux données : correspondant aux données qui sont destinées à être
conservées sur la durée, voire de manière définitive.

105. Page 94
3.2. Diagramme de déploiement
Le diagramme de déploiement modélise l'architecture physique d'un système.
La Figure en dessous illustre le diagramme de déploiement de notre application :
Figure 96: diagramme de déploiement
Conclusion
Dans ce dernier chapitre nous avons présenté notre l’environnement de notre travail,
l’architecture opérationnelle et le diagramme de déploiement sur laquelle se base notre projet.

106. Page 95
Conclusion générale
Notre projet de fin d'études a été réalisé dans le cadre d'obtention du diplôme du Mastère
professionnel en Modélisation, Bases de Données et intégration des systèmes, effectué au sein
de la société Première consulting. Dans le cadre de ce projet, nous avons développé une
application web et mobile pour la gestion du contrôle des équipements des incendies
Tout au long de ce rapport nous avons détaillé les différentes étapes que nous avons adoptées
pour construire cette application en suivant la méthodologie Scrum. Nous avons commencé
notre rapport par l’étude de l’existant, l’identification des objectifs du projet et proposition de
notre solution.
Ensuite, nous avons effectué une planification du travail en identifiant les différents modules
de notre projet tout en respectant la priorité des besoins. Après, nous avons mis en place les
études spécifiques et conceptuelles de chaque sprint et nous avons terminé notre rapport par la
description de l’environnement de travail matériel et logiciel, les outils utilisés, les
technologies et l’architecture de notre travail.
Finalement au cours de la réalisation de notre projet, nous avons été astreints par quelques
limites notamment, la contrainte du temps qui était relativement un obstacle devant l’ajout de
certaines autres fonctionnalités. Cependant, ce travail était une occasion pour mettre en
évidence et déployer sur le plan pratique nos connaissances en informatique.
Comme perspectives, nous proposons de développer une application mobile Ios pour la
gestion des contrôles, et aussi un système de notifications qui déclenche des alertes de
contrôle envoyés via différents canaux de communication.

107. Page 96
Bibliographie
[1][ Methodes-agiles] https://www.ideematic.com/actualites/2015/01/methodes-agiles-
definition/[Accès le 04-03-2019]
[2][Scrum]https://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-
uml/2035851-uml-c-est-quoi[Accès le 04-03-2019]
[3] [MVC] https://medium.com/@belcaid.mehdi/larchitecture-logicielle-mvc-1a8bbb5cf6dc
[4] [Diagramme cas’utilisattion]
https://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation [Accès le 10-03-2019]
[5] [Diagramme sequence]
https://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence[Accès le 12-03-2019]
[6] [UML] https://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-
uml#L9-3-2[Accès le 13-03-2019]
[7] [Visual_Studio] https://fr.wikipedia.org/wiki/Microsoft_Visual_Studio[Accès le 10-06-
2019]
[8] [AMPP] https://fr.wikipedia.org/wiki/XAMPP[Accès le 10-06-2019]
[9] [Android Studio] https://fr.wikipedia.org/wiki/Android_Studio[Accès le 10-06-2019]
[10] [.Net] https://fr.wikipedia.org/wiki/Microsoft_.NET[Accès le 10-06-2019]
[11] [HTML] https://fr.wikipedia.org/wiki/Hypertext_Markup_Language[Accès le 10-06-
2019]
[12][ Bootstrap] https://fr.wikipedia.org/wiki/Bootstrap_(framework) [Accès le 10-06-2019]
[13] [JQuery] https://fr.wikipedia.org/wiki/JQuery[Accès le 10-06-2019]
[14] [JavaScript] https://fr.wikipedia.org/wiki/JavaScript_Object_Notation[Accès le 10-06-
2019]
[15] [Architecture_trois_tiers ]https://fr.wikipedia.org/wiki/Architecture_trois_tiers[Accès le
10-06-2019]

108. Page 97
[16][ Service Web REST ] https://www.supinfo.com/articles/single/3786-services-web-rest-soap
[Accès le 10-06-2019]