Rapport Maha

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

et de la Recherche Scientifique
Université de Carthage
Institut Supérieur des Technologies de
l’Information et de la Communication
Rapport de stage de fin d’étude

Présenté en vue de l’obtention de la
Licence Fondamentale en Informatique et
Télécommunications
Mention : Informatique et télécommunications
Spécialité : Informatique et télécommunications
Système de Gestion des Reclamations et des

Interventions Clients
Réalisé Par
Mohamed Mselmi
Beya Godhbane
au sein de groupe Adaming
Encadrant académique : Mme Maha Sliti

Encadrant professionnel : Mr Marwen Mselmi
Période : Du 21/01/2019 Au 30/04/2019
Année Universitaire : 2018-2019

APPRÉCIATIONS DES ENCADRANTS
Autorisation de dépot du rapport de Projet de Fin d’Etudes :
Encadrant académique :
Le :
Signature :
Autorisation de dépot du rapport de Projet de Fin d’Etudes :
Encadrant professionnel :
Le :
Signature :
i
DÉDICACES
Mes remerciements s’adressent en premier lieu vers Dieu le tout puissant.

Je dédie ce travail :
A mes chers parents Hedi et Madiha, que ce travail soit le symbole de

ma reconnaissance pour toutes ces années de sacrifice que vous avez consenti
pour mon éducation.
A mes chers frères et soeurs qu’ils ont étaient toujours à mes côtés et qu’ils m’ont toujours
souhaité de la chance.
A mes professeurs, ce travail est le fruit de vos efforts.
A mes amis, je vous remercie pour vos encouragements.
Beya Godhbane
ii
DÉDICACES
Avec les vrais mots d’amour et de respect je dédie ce travail :
A mes parents Hedi et Malika pour leurs soutient et leurs sacrifices ainsi que les
efforts qu’ils ont faits pour mon éducation que dieu vous protèges
A mes frères pour leurs affections, patience et leurs encouragements durant cette
période importante de ma formation
A mes amis pour les agréables moments vécus ensemble trouvent dans ce travail
l’expression de mon profond attachement
A Tous ceux que j’aime et à tous ceux qui veulent partager ma joie
Mohamed Mselmi
iii
REMERCIEMENTS
Avec un grand plaisir que nous tenons à exprimer nos remerciements et nos immenses
reconnaissances et gratitudes à tous ceux qui nous ont aidés, de près ou de loin, à élaborer
notre projet de fin d’études.
Nous adressons nos sincères remerciements à nos encadreurs :
Mm. Maha Sliti

&
M. Marwen Mselmi
Pour leurs soutiens, leurs précieuses collaborations, leurs patiences et leurs disponibilités
tout au long du projet en nous fournissant toutes les conditions favorables et adéquates
afin d’aboutir à bien réaliser notre application.
Mes vifs remerciements vont également aux membres du jury d’avoir accepté de juger
notre travail.
iv
LISTE DES ACRONYMES
— JSON = JavaScript Object Notation
— PFE = Projet Fin d’Etude
— RUP = Rational Unified Process
— XP = eXtreme Programming
— UML = Unified Modeling Language
— XML = Extensible Markup Language
— GRIC : Gestion Réclamation et Intervention Client
v
TABLE DES MATIÈRES
Introduction Générale 1
1 Présentation générale 2
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 2
1.2 Domaine d’activités de la société . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Activités d’ingénierie . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Activités des conseils . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Activités de formation . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Solutions proposées . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Les principes des méthodes agiles . . . . . . . . . . . . . . . . . . . 6
1.4.2 Comparatif des méthodes agiles . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.4 Présentation de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.5 Les 3 rôles du Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.6 Le Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.7 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Sprint 0 :Analyse et spécification des besoins 10

2.1 Etude préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Définitions des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Le backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Choix Technique et Infrastructure . . . . . . . . . . . . . . . . . . . . . . 17
2.6.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6.3 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
vi
TABLE DES MATIÈRES TABLE DES MATIÈRES
2.7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 structure de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.1 Structure Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.2 Structure Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Sprint 1 :Gestion Des Menues et des Utilisateurs 34

3.1 Le backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Diagramme du cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Description textuelle du cas d’utilisation «S’authentifier» . . . . . 37
3.3.2 Diagramme de séquence système du cas «S’authentifier» . . . . . . 37
3.3.3 raffinement du cas d’utilisation «Gérer les menus» . . . . . . . . . . 38
3.3.4 Description textuelle du cas d’utilisation « Gérer les
menus» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.5 Diagramme de séquence du cas d’utilisation «Gérer les menus» . . . 40
3.3.6 Raffinement du cas d’utilisation «Gérer les rôles» . . . . . . . . . . 41
3.3.7 Description textuelle du sous cas d’utilisation « Gérer les rôles » . . 41
3.3.8 Diagramme de séquence de sous cas d’utilisation «Gérer rôles» . . 42
3.3.9 Raffinement du cas d’utilisation «Gérer les utilisateurs» . . . . . . . 43
3.3.10 Description textuelle du sous cas d’utilisation «Gérer les utilisateurs» 43
3.3.11 Diagramme de séquence du sous cas d’utilisation «Gérer utilisateurs» 44
3.4 Diagramme du cas d’utilisation globale du
premier sprint : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Diagramme de classe global du premier sprint . . . . . . . . . . . . . . . . 46
3.6 Réalisation du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.1 L’interface de l’authentification . . . . . . . . . . . . . . . . . . . . 47
3.6.2 L’interface de « Gérer les menus » . . . . . . . . . . . . . . . . . . 47
3.6.3 L’interface de « Gérer les rôles » . . . . . . . . . . . . . . . . . . . 48
3.6.4 L’interface de « Gérer les utilisateurs » . . . . . . . . . . . . . . . 48
3.6.5 L’interface de client . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.6 L’interface de dashboard . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7 Revue du premier Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8 Rétrospective du premier Sprint . . . . . . . . . . . . . . . . . . . . . . . 50
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 sprint 2 la Gestion des contrats et des produits 51

4.1 Planification du deuxiéme Sprint . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Le backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Spécification fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Diagramme du cas d’utilisation . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Raffinement du cas d’utilisation « Gérer les entreprises » . . . . . . 54
4.2.3 Descriptif textuel du cas d’utilisation « Gérer
les entreprises » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.4 Diagramme de séquence du sous cas d’utilisation «Gérer les entre-
prises» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.5 Raffinement du cas d’utilisation « Gérer les départements » . . . . 56
4.2.6 Descriptif textuel du cas d’utilisation « Gérer les départements» . 57
vii
4.2.7 Diagramme de séquence du sous cas d’utilisation «Gérer les dépar-

tements» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.8 Raffinement du cas d’utilisation « Gérer les produits » . . . . . . . 59
4.2.9 Descriptif textuel du cas d’utilisation « Gérer les
produits» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.10 Diagramme de séquence du sous cas d’utilisation «Gérer les produits» 61
4.2.11 Raffinement du cas d’utilisation « Gérer les contrats » . . . . . . . 62
4.2.12 Descriptif textuel du cas d’utilisation « Gérer les contrats» . . . . . 63
4.2.13 Diagramme de séquence du sous cas d’utilisation«Gérer contrat» . . 64
4.2.14 Diagramme du cas d’utilisation globale du deuxième Sprint . . . . 65
4.3 Diagramme de classe global du deuxième Sprint . . . . . . . . . . . . . . . 66
4.4 Réalisation du deuxième Sprint . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4.1 L’interface de « ajouter menu Gestion entreprise » . . . . . . . . . . 67
4.4.2 L’interface de « Gérer les entreprises » . . . . . . . . . . . . . . . . 68
4.4.3 L’interface de « ajouter menu Gestion département » . . . . . . . . 69
4.4.4 L’interface de « Gérer les départements » . . . . . . . . . . . . . . 69
4.4.5 L’interface de « ajouter menu Gestion produits . . . . . . . . . . . 70
4.4.6 L’interface de « Gérer les produits » . . . . . . . . . . . . . . . . . 71
4.4.7 L’interface de « ajouter menu Gestion Contrats » . . . . . . . . . . 71
4.4.8 L’interface de « Gérer les contrats » . . . . . . . . . . . . . . . . . 72
4.4.9 L’interface de « Ajouter un contrat » . . . . . . . . . . . . . . . . . 72
4.5 Revue du deuxième Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.6 Rétrospective du deuxième Sprint . . . . . . . . . . . . . . . . . . . . . . 73
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5 sprint3 : Gestion des réclamations et des interventions 74

5.1 planification du deuxiéme Sprint . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1.1 Le backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 Spécification fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.1 Diagramme du cas d’utilisation du Sprint 3 . . . . . . . . . . . . . 76
5.2.2 Raffinement du sous cas d’utilisation "Consulter les produits" . . . . 77
5.2.3 Description textuelle du sous cas d’utilisation "Consulter les pro-
duits" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.4 Diagramme de séquence de sous cas d’utilisation
«Consulter les produits» . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.5 Raffinement du sous cas d’utilisation "Consulter les contrats" . . . . 79
5.2.6 Description textuelle du sous cas d’utilisation "Consulter les contrats" 79
«Consulter les contrats» . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.8 Raffinement du cas d’utilisation "Gérer réclamations " . . . . . . . . 81
5.2.9 Description textuelle du cas d’utilisation « Gestion
de réclamations » . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.10 Diagramme de séquence de cas d’utilisation «Gérer réclamations» . 82
5.2.11 Raffinement du cas d’utilisation "Gérer interventions " . . . . . . . . 83
d’intervention » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.13 Diagramme de séquence du cas d’utilisation «Gérer interventions» . 84
viii
5.2.14 Raffinement du sous cas d’utilisation "Administrer

réclamations" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.15 description textuel du sous cas d’utilisation "Administrer
Reclamations" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.16 Diagramme de séquence du sous cas d’utilisation
«Administrer réclamations» . . . . . . . . . . . . . . . . . . . . . . 86
5.2.17 Raffinement du cas d’utilisation "Administrer interventions" . . . . 87
5.2.18 description textuel du cas d’utilisation "Administrer
interventions" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
«Administrer interventions» . . . . . . . . . . . . . . . . . . . . . . 88
5.2.20 Diagramme de classe global du troisiéme sprint . . . . . . . . . . . 89
5.2.21 Diagramme de classe global de l’application . . . . . . . . . . . . . 89
5.2.22 Diagramme de cas d’utilisation global de l’application . . . . . . . . 90
5.3 réalisation du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.1 Interface« Ajouter menu Mes produits» . . . . . . . . . . . . . . . . 92
5.3.2 L’interface de « Mes produits » . . . . . . . . . . . . . . . . . . . . 92
5.3.3 L’interface de « Ajouter menu Mes contrats » . . . . . . . . . . . . 93
5.3.4 L’interface de « Mes contrats » . . . . . . . . . . . . . . . . . . . . 94
5.3.5 Interface« Ajouter menu réclamer un produit» . . . . . . . . . . . . 94
5.3.6 L’interface de « réclamer un produit » . . . . . . . . . . . . . . . . 95
5.3.7 L’interface de intervention . . . . . . . . . . . . . . . . . . . . . . . 95
5.4 Revue du troisième Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5 Rétrospective du troisième Sprint . . . . . . . . . . . . . . . . . . . . . . . 96
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Conclusion Générale et Perspectives 97
ix
TABLE DES FIGURES
1.1 Méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 l’équipe scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Structure Back-end du projet . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Usermanager.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 UserRepository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7 UserService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 UserServiceImp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9 UserController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10 Structure Front-end du projet . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 User model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.12 User service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.13 User view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.14 Users.component.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.15 Users.component.ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.16 Users.component.scss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . 36

3.2 Diagramme de séquence système du " s’authentifier " . . . . . . . . . . . . 38
3.3 Raffinement du « Gérer les menus » . . . . . . . . . . . . . . . . . . . . . 39
3.4 Diagramme de séquence « « Gérer les menus » » . . . . . . . . . . . . . . . 40
3.5 Raffinement du « Gérer les rôles » . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Diagramme de séquence « « Gérer rôles » » . . . . . . . . . . . . . . . . . 42
3.7 Raffinement du « Gérer les utilisateurs » . . . . . . . . . . . . . . . . . . . 43
3.8 Diagramme de séquence « « Gérer utilisateurs » » . . . . . . . . . . . . . . 44
3.9 Diagramme de cas d’utilisation global du première Sprint . . . . . . . . . . 45
3.10 Diagramme de class globale du premier sprint . . . . . . . . . . . . . . . . 46
3.11 Page login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.12 L’interface "Gestion des Menus" . . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 L’interface "Gestion des Roles " . . . . . . . . . . . . . . . . . . . . . . . . 48
3.14 L’interface "Gestion utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . 48
3.15 Page login pour client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
x
Table des figures Table des figures
3.16 : Page «Dashboard» pour le client . . . . . . . . . . . . . . . . . . . . . . 49
4.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . 54

4.2 Raffinement du « Gérer les entreprises » . . . . . . . . . . . . . . . . . . . 54
4.3 Diagramme de séquence « Gérer les entreprises » . . . . . . . . . . . . . . 56
4.4 Raffinement du « Gérer les départements » . . . . . . . . . . . . . . . . . . 57
4.5 Diagramme de séquence « Gérer les départements » . . . . . . . . . . . . . 59
4.6 Raffinement du « Gérer les produits » . . . . . . . . . . . . . . . . . . . . . 60
4.7 Diagramme de séquence «Gérer produits » . . . . . . . . . . . . . . . . . . 62
4.8 Raffinement du « Gérer les contrats » . . . . . . . . . . . . . . . . . . . . . 63
4.9 Diagramme de séquence« Gérer contrats » . . . . . . . . . . . . . . . . . . 65
4.10 Diagramme de cas d’utilisation globale du deuxième Sprint . . . . . . . . . 66
4.11 Diagramme de classe du deuxième sprint. . . . . . . . . . . . . . . . . . . . 67
4.12 L’interface «Ajouter Menu» pour l’ajout du menu Gestion entreprises . . . 68
4.13 L’interface «Gestion entreprise» . . . . . . . . . . . . . . . . . . . . . . . . 68
4.14 L’interface «Ajouter Menu» pour l’ajout du menu Gestion départements . 69
4.15 L’interface «Gestion départements» . . . . . . . . . . . . . . . . . . . . . . 70
4.16 L’interface «Ajouter Menu» pour l’ajout du menu Gestion produits . . . . 70
4.17 L’interface «Gestion produits» . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.18 L’interface «Ajouter Menu» pour l’ajout du menu Gestion contrats . . . . 72
4.19 L’interface «Gestion contrats» . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.20 L’interface «Ajouter Contrats» . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1 Diagramme du cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . 76

5.2 Raffinement du « Consulter les produits » . . . . . . . . . . . . . . . . . . 77
5.3 diagramme de séquence du « Consulter les produits » . . . . . . . . . . . . 78
5.4 Raffinement du « Consulter les contrats » . . . . . . . . . . . . . . . . . . 79
5.5 diagramme de séquence « Consulter contrats » . . . . . . . . . . . . . . . . 80
5.6 Raffinement du « Gestion Réclamations » . . . . . . . . . . . . . . . . . . 81
5.7 diagramme de séquence « Gérer les réclamations » . . . . . . . . . . . . . . 82
5.8 Raffinement du « Gestion Interventions » . . . . . . . . . . . . . . . . . . . 83
5.9 diagramme de séquence « Gérer les interventions » . . . . . . . . . . . . . 84
5.10 Raffinement du « Administrer les réclamations » . . . . . . . . . . . . . . 85
5.11 diagramme de séquence « Administrer réclamation » . . . . . . . . . . . . 86
5.12 Raffinement du « Administrer interventions » . . . . . . . . . . . . . . . . 87
5.13 diagramme de séquence
« Administrer interventions » . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.14 Diagramme de class globale de troisiéme sprint. . . . . . . . . . . . . . . . 89
5.15 Diagramme de class globale de l’application . . . . . . . . . . . . . . . . . 90
5.16 Diagramme de class globale de l’application . . . . . . . . . . . . . . . . . 91
5.17 L’interface « Ajouter menu Mes produits» . . . . . . . . . . . . . . . . . . 92
5.18 L’interface « Mes produits» . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.19 L’interface« Ajouter menu Mes contrats » . . . . . . . . . . . . . . . . . . 93
5.20 L’interface« Mes contrats » . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.21 L’interface« Ajouter menu réclamer un produit » . . . . . . . . . . . . . . 94
5.22 L’interface« réclamer un produit » . . . . . . . . . . . . . . . . . . . . . . 95
5.23 L’interface de l’intervention & PV-intervention . . . . . . . . . . . . . . . . 95
xi
LISTE DES TABLEAUX
1.1 Tableau comparatif des méthodologies agiles . . . . . . . . . . . . . . . . . 6
2.1 le backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Description textuelle du cas d’utilisation "s’authentifier" . . . . . . . . . . . 37
3.3 tableau descriptif du cas d’utilisation « Gérer les menus » . . . . . . . . . . 40
3.4 tableau descriptif du cas d’utilisation « Gérer les roles » . . . . . . . . . . 42
3.5 tableau descriptif du cas d’utilisation « Gérer les utilisateurs » . . . . . . . 44
4.1 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Description textuelle du cas d’utilisation " Gérer les entreprises " . . . . . . 55
4.3 Description textuelle du cas d’utilisation " Gérer les entreprises " . . . . . . 58
4.4 Description textuelle du cas d’utilisation " Gérer les produits " . . . . . . . 61
4.5 Description textuelle du sous cas d’utilisation " Gérer les contrats " . . . . 64
5.1 Backlog Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2 Description textuelle du sous cas d’utilisation " Consulter les produits " . . 78
5.3 Description textuelle du sous cas d’utilisation " Consulter les contrats " . . 80
5.4 Description textuelle du cas d’utilisation " Gestion reclamations " . . . . . 82
5.5 Description textuelle du cas d’utilisation " Gestion d’interventions " . . . . 84
5.6 Description textuelle du sous cas d’utilisation "Administrer réclamations " . 86
5.7 Description textuelle du cas d’utilisation "Administrer Interventions " . . . 88
xii
INTRODUCTION GÉNÉRALE
Au cours du dernier siècle on a assisté à une grande avancée technologique dans le

domaine du développement web. Ce qui a donné un impact profond sur tous les niveaux.
En effet, les services web sont rapidement devenus essentiels dans la vie de chaque
personne ce qui implique l’augmentation rapide du nombre d’entreprise spécialisées dans
ce domaine.
Dans ce contexte de concurrence, la qualité des services offerts et la satisfaction des

clients deviennent primordiales pour l’entreprise. Dans ce contexte s’inscrit notre projet
de fin d’étude intitulé « Système de Gestion des réclamations et des interventions clients
» réalisé au sein de l’entreprise Groupe Adaming.
Le présent rapport est réparti en cinq chapitres :
Dans le premier chapitre « Présentation générale » , nous présentons le cadre de notre

stage de projet de fin d’étude à savoir l’organisme d’accueil Group ADAMING. Par la
suite, nous analysons l’existant ainsi que ses limites et nous proposons notre solution.
Enfin, nous présentons la méthodologie adoptée pour le développement de notre projet.
Dans le deuxième chapitre intitulé «Analyse et Specification de besoin», nous définis-

sons les différents besoins fonctionnels, les besoins non fonctionnels, ainsi que l’identifi-
cation des sprints du projet, le Backlog du produit ainsi que les choix technologiques et
logiciels adoptés.
Dans le reste du rapport (troisième, quatrième, cinquième chapitre), nous déployons

les différentes phases du projet en gardant la même planification et tout en respectant les
principes fondamentaux de notre méthodologie de développement des projets Scrum.
1
CHAPITRE 1
PRÉSENTATION GÉNÉRALE
Introduction
Dans ce chapitre, nous allons présenter l’organisme d’accueil Group Adaming
TUNISIE . Ensuite, nous procédons à une description ainsi qu’une critique de l’existant et
nous proposons notre solution. Enfin, nous présentons la méthodologie adoptée au cours
de développement du projet.
1.1 Présentation de l’organisme d’accueil

Créé en 2010, par des professionnels des services et de l’informatique, Groupe Adaming
est devenu un acteur majeur de l’externalisation. Il fait partie des outsourceurs
francophones leaders dans l’externalisation des services.
Le Groupe emploie plus de 350 collaborateurs répartis sur 4 agences en France (Paris,
Lyon, Lille, Nantes), en Espagne, au Maroc, en Algérie et un centre de service en Tunisie
qui compte plus de 50 Consultants.
Groupe Adaming dispose d’une expertise diversifiée et propose à ses clients des réponses
complètes dans le domaine du Web, de la mobilité, de l’entreprise collaborative et des
développements logiciels métiers. Groupe Adaming met à disposition son expertise et ses
connaissances métiers pour ses clients .
Aujourd’hui, le groupe est engagé auprès d’une trentaine d’entreprises prestigieuses,

opérant dans différents secteurs (banques, assurances, services, média, industrie, etc...)
A travers ses différentes entités spécialisées, ils proposent à leurs clients un

accompagnement global et sur mesure qui s’articule autour de trois pôles de
compétences : l’ingénierie, le conseil et la formation, tout en alliant :
-Des prestations personnalisées : Audit, Conseil, Développement Assistance...

-La maitrise des technologies et environnements.
-Objet : Java, J2EE, .NET, UML...
2
Chapitre 1. Présentation générale 1.2. Domaine d’activités de la société
-Mainframe : MVS, COBOL, PACBASE, CICS, DB2.

-Qualification logicielle : Qaulity Center, Quick Test Pro.
-La fourniture de ressources
1.2 Domaine d’activités de la société

1.2.1 Activités d’ingénierie
Group Adaming a pour mission d’accompagner leurs clients dans la réussite de leurs
projets en proposant des solutions technologiques innovantes et sur mesure à forte valeur
ajoutée.
Les ingénieurs assistent les clients dans le développement de leurs projets informatiques
tant en engagement de résultat (forfait, TMA, TRA) qu’en engagement de moyens
(assistance technique).
Group Adaming les accompagne tout au long de leurs projets, depuis la mise en oeuvre
jusqu’à l’optimisation à travers : la conception, le Développement, l’Intégration,
la Recette et la Maintenance Applicative.
Ils mettent à leur disposition leur expérience, expertise et maitrise des nouvelles
technologies et architectures pour leur fournir des solutions qui répondent à leurs objectifs
et stratégies.
1.2.2 Activités des conseils

Group Adaming met à la disposition de ses clients son expertise en maitrise d’ouvrage
acquise dans la gestion des projets de ces clients Grands Comptes.
La pluralité des domaines de compétences de ses Consultants, Directeurs de projets,

Experts Métier et Architectes Techniques, leur permet de proposer un accompagnement
de qualité à chaque étape du projet de ses clients :
-Audit du système d’information
-Assistance dans la définition des objectifs et stratégies,
-Schémas directeurs, études de faisabilité du projet,
-Elaboration du cahier des charges,
-Aide au choix d’architectures et d’outils
1.2.3 Activités de formation

Group ADAMING dispose de ses propres centres de formations (Paris, Nantes, Lille)
et propose des filières techniques et métiers :
3
Chapitre 1. Présentation générale 1.3. Etude de l’existant
-Filière Mainframe (Cobol, Db2, Cics, Mvs, Pacbase,Cobos).
-Filière Java J2EE.
-Filière Test/Recette( Quality center ,Quick Test Pro..)
1.3 Etude de l’existant

1.3.1 Description de l’existant
D’habitude, pour formuler une réclamation concernant un produit logiciel ou matériel,
le client doit se déplacer pour résoudre son problème. Il peut également envoyer un mail,
un fax ou appeler l’équipe technique concernée. Ce sont les seuls moyens disponibles qu’un
client peut utiliser pour faire parvenir sa réclamation.
On a deux types de réclamations
soit une réclamation logicielle :
- Réclamation d’une panne logicielle : s’il ya un problème lors de l’utilisation d’un produit
logiciel.
- Demande d’une formation pour maitriser l’utilisation d’un logiciel ; si le client

n’arrive pas à comprendre l’utilisation du produit logiciel.
- Demande d’information :si le client veut savoir plus d’informations sur le produit
logiciel concernée.
- Demande d’une mise à jour : pour avoir une version update du produit logiciel.
- Demande de prolongation du contrat : dans le cas où le contrat du produit logiciel

est expiré.
Soit une réclamation matérielle :
- Réclamation d’une panne matérielle : s’il y a un problème dans le fonctionnement du

matériel.
- Demande d’une maintenance : pour vérifier le bon fonctionnement du produit

matériel.
- Demande d’information :si le client veut savoir plus d’informations sur le produit
matériel concernée.
- Demande de prolongation du contrat : dans le cas où le contrat du produit

matériel est expiré.
4
Chapitre 1. Présentation générale 1.4. Choix de la méthodologie
1.3.2 Critique de l’existant

L’étude de l’existant nous révèle plusieurs insuffisances :
-Il n’ya aucun support informatisé pour gérer les réclamations des Clients.
-L’augmentation du nombre des clients rend la situation plus difficile de sorte que la
fidélisation des clients n’est pas garantie.
-Il n’ya pas de suivi de l’état de la réclamation (en attente, au cours de traitement ou
résolue).
-La sécurité n’est pas assurée ce qui entraine un risque de perte de données comme les
contrats et les fiches d’informations.
-Le nombre de formulaires d’intervention restera très élevé si on garde le même système
d’organisation des tâches.
-une perte de temps énorme causée par la dépendance entre les tâches.
-Pas d’historique : Les solutions aux problèmes les plus fréquents ne sont pas gardées.
1.3.3 Solutions proposées

Il s’avère que le développement d’une application web qui regroupe toutes ces pro-
cédures est primordiale. Ce qui facilite la bonne propagation de toutes les informations
utiles dont les clients et les employés auront besoins. De cette façon, on évite la répétition
des tâches et on gagne le temps et l’argent Cette application web permettra de :
- Faciliter la communication avec le client, en lui offrant un service après-vente à tra-

vers une application web.
- L’automatisation de l’opération permet au personnel de l’entreprise d’accéder rapide-

ment aux contrats des clients, sans aucun risque de perte de données.
- Informatiser la gestion des réclamations et interventions clients
- Classifier les réclamations selon leur type (logiciel ou matériel).
- Consulter et suivre l’état des réclamations par les deux côtés : clients et personnels.
1.4 Choix de la méthodologie

Le choix de la méthodologie de travail ressemble plus à joindre un culte qu’à faire un
choix technologique approprié. Aujourd’hui beaucoup d’entreprises n’essaient même pas
d’évaluer ces méthodes de travail, mais choisissent les plus populaires.
5
1.4.1 Les principes des méthodes agiles

• La valorisation des personnes par rapport aux processus ou aux outils.
• le logiciel qui fonctionne plutôt que la documentation complète.
• la collaboration avec le client plutôt que la négociation du contrat.
• répondre au changement plutôt que suivre un plan.
Il y a plusieurs méthodologies de développement de projets. Certaines sont plus adaptées
aux petites équipes (Crystal, XP, Scrum), tandis que d’autres sont prévues pour des
groupes conséquents (RAD, RUP, ASD).
1.4.2 Comparatif des méthodes agiles

Dans l’intention de mieux assimiler les méthodes agiles nous avons élaboré une brève
comparaison de quelques méthodes de développement, jugées les plus connues,dans le
tableau 1.1 :
Méthode Principales caractéristiques Inconvénients
XP Pilotage par les besoins (client for- Réclame beaucoup de discipline et de

tement impliqué dans le projet) communication Risque de manque de
Légère et souple Communication contrôle et de structuration en laissant
entre tous les acteurs Boucles feed- les développeurs trop libres de dériver,
back dans le but de réduire les par rapport aux fonctions de l’applica-
risques tion Ne peut s’adresser qu’à des projets
petits ou moyens
UP Itératif et incrémental Centré sur Méthode lourde Peu flexible Couts éle-
l’architecture Piloté par les cas vés Nécessite une documentation en
d’utilisation Focus sur la qualité masse
Scrum Réunions journalières Itérations La mise en oeuvre du développement

d’au maximum 3 semaines Ta- n’est pas précisée, seule compte la ges-
bleaux de bords et graphiques tion des ressources humaines Peu, voire
(Burdown chart) permettant de pas, de documentation écrite
suivre l’avancement du projet
Table 1.1 – Tableau comparatif des méthodologies agiles
6
1.4.3 Méthodologie adoptée

Parmi les méthodes agiles, nous avons choisi la méthodologie Scrum pour les raisons
suivantes :
• Scrum est la méthodologie suivie par l’entreprise GROUP ADAMING TUNISIE

pour la gestion de ses projets,
• Scrum est entièrement développée et testée pour de courtes itérations
• Scrum permet de simplifier les processus
• Scrum permet l’augmentation de productivité
• Scrum permet d’adapter le logiciel crée suivant l’évolution du projet
1.4.4 Présentation de Scrum
Scrum permet de s’adapter aux changements qui peuvent arriver au cours du pro-
jet, il est ainsi possible de modifier ou de donner plus de précisions aux spécifications. Des
ajustements peuvent être effectués régulièrement, notamment à la fin de chaque itération,
appelée « Sprint ».
La méthode Scrum, qui tire son nom du terme anglais « Mêlée », en référence à la mêlée
du rugby, met l’accent sur l’esprit d’équipe et sur le fait que tous les acteurs doivent
avancer dans la même direction pour atteindre un même objectif. Scrum repose sur une
intense collaboration de l’équipe qui se focalise sur une partie limitée et maîtrisable des
fonctionnalités à réaliser.
1.4.5 Les 3 rôles du Scrum

- Le Product Owner : c’est le responsable du produit, il représente les clients et les
utilisateurs en transcrivant leurs besoins, définit et priorise les demandes produit.
- Le Scrum Master : qui n’est pas le chef de projet mais il a pour charge de
faciliter l’application de Scrum, sa mission est de tout mettre en oeuvre pour que l’équipe
travaille dans de bonnes conditions et se concentre sur l’objectif du projet. Il porte
également une attention particulière au respect des différentes phases de Scrum.
- L’équipe Scrum : L’équipe se gère en toute autonomie et elle est en charge du

développement du produit. Il n’y a pas de notion de hiérarchie, toutes les décisions sont
prises ensemble. Elle regroupe les rôles habituellement nécessaires à un projet (architecte,
concepteur, développeur, etc.).
1.4.6 Le Backlog
La méthode Scrum repose sur deux journaux ou « backlog » :
- Backlog de produit : liste les fonctionnalités pour le produit qui sont estimées par
l’équipe. Il est géré par le Product Owner mais partagé avec l’ensemble de l’équipe. Les
fonctionnalités sont priorisées et associées à des critères d’acceptation qui permettent de
déterminer si le besoin est couvert.
7
- Backlog de Sprint : liste l’ensemble des tâches nécessaires pour répondre à l’ob-
jectif du Sprint. C’est la propriété de l’équipe, cette dernière le met régulièrement à jour
et choisit les tâches sur lesquelles elle souhaite travailler.
Un projet utilisant la méthodologie Scrum se base sur des itérations appelées Sprints
qui se succèdent. Un sprint dure de 2 à 4 semaines (Figure 1.1). Chaque Sprint commence
par une réunion de planification appelée « Sprint planning » (appelée aussi planning po-
ker). C’est à l’issue de cette réunion, que l’équipe découvre l’objectif du Sprint et chaque
besoin qui est décomposé en plusieurs tâches.
Figure 1.1 – Méthodologie Scrum
La figure 1.1 représente les différentes phases de Scrum, la phase initiale qui est consa-
crée à préparer le travail à faire qui comporte le Product Backlog, la définition de l’équipe
Scrum et Spring Planning, et par la suite les phases de sprints, ce sont des phases itéra-
tives qui réalisent les éléments qui composent le produit, et enfin la phase de livraison.
Durant un Sprint, des réunions quotidiennes appelées « Daily meetings » (ou Stand ups)
de moins de 15 mn permettent à chaque membre de prendre la parole et de faire le point
sur ce qu’il a fait, ce qu’il compte faire et les difficultés rencontrées.
Pendant ce Sprint, l’équipe développe l’ensemble des besoins embarqués dans ce sprint
en analysant, concevant, développant, testant et intégrant les fonctionnalités.
Chaque Sprint se termine par une revue du Sprint appelée « Démonstration » durant
laquelle les besoins réalisés sont évalués par le Product Owner en présence du client qui
valide ou pas le produit partiel et modifie par la suite le backlog de produit.
Une réunion « Rétrospective » se fait généralement après la démonstration. Elle a pour
but d’examiner ce qui a bien fonctionné, ce qui ne l’a pas été et ce qui peut être amélioré.
8
Chapitre 1. Présentation générale 1.5. Conclusion
1.4.7 Langage de modélisation

Nous avons utilisé UML (Unified Modeling Langage) ou langage de modélisation objet
unifié afin de modéliser notre système. Ce langage est couramment utilisé dans tous les
projets logiciels, offrant une multitude de diagrammes qui permettent de donner une re-
présentation informatique d’un ensemble d’éléments et de problèmes standards du monde
réel.
1.5 Conclusion
Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil GROUP
ADAMING TUNISIE et ses principales activités. Par ailleurs, nous avons pu dégager le
contexte général du projet et présenter le choix de la méthodologie de développement. Le
chapitre suivant sera consacré au sprint 0.
9
CHAPITRE 2
SPRINT 0 :ANALYSE ET
SPÉCIFICATION DES BESOINS
Introduction
Dans ce chapitre, nous allons présenter une étude préliminaire sur notre application
pour identifier les fonctionnalités attendues du système de gestion développé. Par la suite,
nous allons présenter l’architecture de l’application développée.
2.1 Etude préliminaire

2.1.1 Identification des acteurs
Notre application est composée de deux types d’acteurs : client et personnel.
Client , qui a acheté des produits de la société, est un utilisateur de l’application, il

a pour tâches de : consulter ses produits et ses contrats, d’envoyer, suivre ou annuler les
réclamations et aussi d’ajouter/fermer les interventions.
Un personnel est un utilisateur de l’application qui a une visibilité totale sur la

base de données, il a pour tâches : gérer les menus, gérer les rôles, gérer les utilisateurs,
gérer les entreprises, gérer les départements, gérer les produits, gérer les contrats, gérer
les réclamations et gérer les interventions.
Le type personnel se compose de : Directeur projet(admin), Chef produit, Responsable
technique, Intervenant logiciel, Intervenant matériel.
2.2 Besoins fonctionnels

La spécification des besoins fonctionnels permet de définir les différents besoins afin
de satisfaire les attentes des utilisateurs.
L’application doit assurer les fonctionnalités suivantes :
10
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.3. Besoins non fonctionnels
-Passage de réclamation logicielle / matérielle :
La réclamation du client sera reçue par le personnel. Dans ce cas il y a un saisi d’un
PV d’intervention qui sera envoyé au client. Finalement, le client valide ce
PV d’intervention afin de fermer la réclamation(résolu) ou la renouveler (ajoute une
intervention).
-Un bon suivi des contrats et des réclamations clients.
-Du bon suivi des réclamations clients, ce dernier est le résultat de changement du
statut de réclamation :
« En attente » statut par défaut.
« En cours de traitement » si le personnel ouvre la réclamation et le personnel saisit un
PV-intervention.
« Résolu » si le client est satisfait. (Valide le PV-intervention)
-Archivage des réclamations et des PV-interventions.
-Trouver facilement l’ancienne réclamation avec ses différents statuts.
-La répartition des différentes tâches entre les personnels.
-Différencier les réclamations selon leur types.
2.3 Besoins non fonctionnels

La spécification des besoins non fonctionnels définit la qualité du produit livré, on
cite :
La performance : Le temps de chargement des pages est un facteur essentiel dans
le logiciel, pour réduire le temps de réponse il faut éviter d’utiliser plusieurs images ou
animations.
La sécurité : Interdire l’accès aux interfaces de l’application via URL pour les
utilisateurs non connectés à l’application
Les contraintes esthétiques : Le Dashboard doit être présenté de manière très

simple avec un contenu clair avec lequel on peut attirer l’attention de l’utilisateur. Les
polices doivent être lisibles et adaptés à l’information, les structures de mise en page
doivent être unifées dans tous les pages.
2.4 Définitions des rôles

L’équipe Scrum se compose de trois rôles spécifiques comme il est décrit dans la figure
2.1 : Product Owner(responsable produit), Scrum Master (l’encadrent) et Delivery Team
(l’équipe de développement). Dans ce projet les membres de l’équipe de développement
sont Beya et Mohamed.
11
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.5. Le backlog produit
Figure 2.1 – l’équipe scrum
2.5 Le backlog produit

Un Backlog est une liste de tâches, jugées nécessaires et suffisantes pour la réalisation
du projet.
Les éléments du Backlog sont appelés User Stories. Chacune de ces User Stories doit avoir
un but métier bien déterminé, son ajout au Backlog doit généralement justifier une valeur
ajoutée.
Dans ce contexte, nous dressons le Backlog de notre application illustrée par le tableau
2.1. ci-dessous.
Après avoir la mise en point sur l’ensemble des fonctionnalités attendues par le système,
nous devons repartir le travail selon des Sprints.
Nous avons décidé de diviser le travail en trois Sprints :
• Sprint 1 : à la fin de ce sprint, les services « Gérer les menus », « Gérer les rôles
», « Gérer les utilisateurs » seront prêts à l’exploitation et le personnel a le pouvoir
d’ajouter, modifier, afficher, chercher et supprimer dans ces services.
• Sprint 2 : à la fin de ce sprint, les services « Gérer les entreprises », « Gérer les
départements », « Gérer les produits »et « Gérer les contrats » seront prêts à
l’exploitation et le personnel a le pouvoir d’ajouter, modifier, afficher, chercher et
supprimer dans ces services.
• Sprint 3 : Après ce sprint, les services « Consulter produits », « Consulter contrats

», « Gérer réclamations » « Gérer interventions » » seront prêts à l’exploitation, le
client a le pouvoir de consulter les produits, les contrats et ajouter une ou plusieurs
réclamations sur un ou plusieurs produits et le personnel a le pouvoir d’administrer
les réclamations et les interventions.
12
Priorité Futures ID Story User Story
Gérer les En tant que personnel je souhaite ajouter un ou

2 2.1
menus plusieurs menus
Gérer les En tant que personnel je souhaite afficher tous

2 2.2
menus les menus
Gérer les En tant que personnel je souhaite modifier un

2 2.3
menus ou plusieurs menus
Gérer les En tant que personnel je souhaite chercher un

2 2.4
Gérer les En tant que personnel je souhaite supprimer un

2 2.5
En tant que personnel je souhaite ajouter un ou

3 Gérer les rôles 3.1
plusieurs rôles
En tant que personnel je souhaite afficher tous
les rôles
En tant que personnel je souhaite modifier un
ou plusieurs rôles
En tant que personnel je souhaite chercher un
ou plusieurs rôles
En tant que personnel je souhaite supprimer un
ou plusieurs rôles

4 4.1
utilisateurs plusieurs utilisateurs
Gérer les En tant que personnel je souhaite afficher Tous

4 4.2
utilisateurs les utilisateurs avec leurs détails

4 4.3
utilisateurs ou plusieurs utilisateurs

4 4.4

4 4.5
Gérer les En tant que personnel je souhaite ajouter une

5 5.1
entreprises ou plusieurs entreprises
13
Gérer les En tant que personnel je souhaite afficher toutes

5 5.2
entreprises les entreprises

5 5.3

5 5.4

5 5.5
Gérer les En tant que personnel je souhaite affecter une

5 5.6
entreprises entreprise a un client

7 7.1
produits plusieurs produits

7 7.2
produits les produits

7 7.3
produits ou plusieurs produits

7 7.4

7 7.5
En tant que personnel je souhaite ajouter un ou

Gérer les plusieurs contrats (un contrat sur un produit
8 8.1
contrats d’un client traité par un personnel)

8 8.2
contrats les contrats

8 8.3
contrats ou plusieurs contrats

8 8.4
Gérer les En tant que personnel je souhaite supprimer

14 un
8 8.5
Gérer les En tant que client je souhaite ajouter une ou

11 11.1
réclamations plusieurs réclamations
Gérer les En tant que client je souhaite afficher toutes

11 11.2
réclamations mes réclamations
Gérer les En tant que client je souhaite chercher une

11 11.3
réclamations réclamation
Gérer les En tant que client je souhaite supprimer une ou

11 11.4
réclamations plusieurs réclamations

6 6.1
départements plusieurs départements

6 6.2
départements les départements

6 6.3
départements ou plusieurs départements

6 6.4

6 6.5
Gérer les En tant que personnel je souhaite affecter un

6 6.6
départements département a un personnel
Gérer les En tant que client je souhaite afficher les

13 13.1
interventions réclamations et les PV-interventions
Gérer les En tant que client je souhaite ajouter une

13 13.2
interventions intervention
Gérer les En tant que client je souhaite valider la

13 13.3
interventions PV-intervention
Administrer En tant que personnel je souhaite afficher les

14 14.1
interventions interventions avec leurs détails
15
Administrer En tant que personnel je souhaite chercher une

14 14.2
interventions intervention
Administrer En tant que personnel je souhaite supprimer une

14 14.3
interventions PV-intervention
Consulter les En tant que client je souhaite consulter mes

9 9.1
produits produits
Consulter les En tant que client Je souhaite chercher un de

9 9.2
produits mes produits
Consulter les En tant que client je souhaite afficher les détails

9 9.3
produits d’un produit
Consulter les En tant que client je souhaite Consulter mes

10 10.1
contrats contrats
Consulter les En tant que client je souhaite chercher un de

10 10.2
contrats mes contrats
Consulter les En tant que client je souhaite afficher les détails

10 10.3
contrats d’un contrat
Administrer En tant que personnel je souhaite consulter les

12 12.1
réclamations réclamations
Administrer En tant que personnel je souhaite ajouter une

12 12.2
réclamations PV-intervention
Administrer En tant que personnel je souhaite consulter une

12 12.3
réclamations intervention
Administrer En tant que personnel je souhaite chercher une

12 12.4
Administrer En tant que personnel je souhaite supprimer une

12 12.5
16
Chapitre 2. Sprint 0 :Analyse et spécification des2.6.
besoins
Choix Technique et Infrastructure
En tant qu’utilisateur, je dois m’authentifier

1 Authentification 1.1 pour accéder à mon espace au sein de
l’application
Table 2.1 – le backlog produit
Figure 2.2 – Planification des sprints
2.6 Choix Technique et Infrastructure

2.6.1 Environnement matériel
Pour la réalisation de ce projet, nous avons utilisé un ordinateur portable issus
tournant sur le système d’exploitation Windows 10. Cet ordinateur possède :
• Processus Intel core i3CPU @2.00 Ghz
• Mémoire installée (RAM) 8,00 Go
• Disque dur de 1T
• Un système d’exploitation 64bit
2.6.2 Environnement logiciel
Xampp : XAMPP est un ensemble de logiciels permettant de mettre en place faci-
lement un serveur Web et un serveur FTP. Il s’agit d’une distribution de logiciels libres
(X Apache MySQL Perl PHP) offrant une bonne souplesse d’utilisation, réputée pour son
installation simple et rapide.
17
Chapitre 2. Sprint 0 :Analyse et spécification des2.6.
besoins
Choix Technique et Infrastructure
Tomcat 7.0.92 Apache Tomcat est une implémentation logicielle open source de
Java Servlet, pages JavaServer, Java Expression Language et Java Technologies
WebSocket.
Cette version contient un certain nombre de corrections de bogues et d’améliorations par
rapport à version 7.0.91. Les changements notables depuis la version 7.0.91
Eclipse Oxygen Eclipse est un projet, décliné et organisé en un ensemble de sous-

projets de développements logiciels, de la fondation Eclipse visant à développer un en-
vironnement de production de logiciels libre qui soit extensible, universel et polyvalent,
en s’appuyant principalement sur Java. Son objectif est de produire et fournir des outils
pour la
réalisation de logiciels, englobant les activités de programmation .
Advanced REST Client Programme d’assistance des développeurs Web pour créer
et tester des requêtes HTTP personnalisées.
Visual studio Visual Studio Code est un éditeur de code extensible développé par
Microsoft pour Windows, Linux et macOS
Node js Node.js est une plate-forme de développement open source permettant d’exé-
cuter du code JavaScript côté serveur. Node est utile pour développer des applications
nécessitant une connexion persistante du navigateur au serveur
Draw.io Draw.io est une application gratuite en ligne, accessible via son navigateur
(protocole https) qui permet de dessiner des diagrammes (diagrammes UML). Cet outil
vous propose de concevoir toutes sortes de diagrammes, de dessins vectoriels, de les enre-
gistrer au format XML puis de les exporter.
2.6.3 Outils
Java EE 8 Java Platform, Enterprise Edition (Java EE) est la norme des logiciels
d’entreprise axés sur la communauté. Java EE est développé à l’aide du Java Community
Process , avec des contributions d’experts du secteur, d’organisations commerciales et
open source, de groupes d’utilisateurs Java et d’innombrables personnes. Chaque version
intègre de nouvelles fonctionnalités qui répondent aux besoins de l’industrie, améliore la
portabilité des applications et augmente la productivité des développeurs.
Plaguin spring boot Plugin qui ajoute la prise en charge du Framework d’applica-
tion populaire Spring Framework à la plate-forme Eclipse.
18
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.7. Architecture
Pourquoi choisir spring boot comme framework java ?

Spring Boot est un framework de développement JAVA. C’est une déclinaison du
framework classique de Spring qui permet essentiellement de réaliser des micro services
(ce sont la majeure partie du temps des services web qui sont regroupés en API). Pour
faire simple, Spring Boot est un framework de développement JAVA permettant la
création d’API web. En effet nous faisons recours au framework spring boot pour les
raisons suivantes :
-Légèreté : Spring Boot a la particularité d’être très léger et d’embarquer avec lui le
strict minimum pour faire tourner votre service.
-Intégration facilitée : Spring Boot s’intègre particulièrement bien dans une

architecture orientée micro services... et c’est l’un des seuls ! En effet, l’adoption des
architectures micro services au sein des organisations étant relativement récente, il
n’existait pas dans l’univers de JAVA de framework capable de créer des services
suffisamment légers et performants.
-Simplicité de prise en main : Spring Boot permet donc de créer une API de ser-
vices très simplement. Il suffit d’embarquer directement le serveur d’application dans un
seul et unique Jar qui est exécutable, par exemple, directement dans un service de conte-
neur.
Angular 7 : La nouvelle version 7 d’Angular est sortie officiellement le 18 octobre 2018 :

est un framework d’application Web open source basé sur TypeScript dirigé par l’équipe
angulaire de Google et par une communauté d’individus et sociétés. Angular est une ré-
écriture complète de la même équipe que celle qui a construit AngularJS .
Bootstrap : est un framework CSS, HTML et JavaScript. Il apporte du style pour les
éléments HTML de façon simplifié et rapide, car le code de style est déjà prêt, nous allons
juste faire appel à lui et l’utilisé. JSON : pour les Services Web REST
JSON (JavaScript Object Notation ? Notation Objet issue de JavaScript) est un format
léger d’échange de données. Il est facile à lire ou à écrire pour des humains et aisément
analysable par des machines. JSON est le langage d’échange de données idéal parce qu’il
est un format texte complètement indépendant de tout langage de programmation.
2.7 Architecture
Notre architecture est composée de deux parties comme est illustré dans la figure 2.3 : :
*Une partie back-end est formée généralement de trois éléments :
-Un serveur (nous avons utilisé le serveur Tomcat)
-Une application
-Une base de données (nous avons utilisé MySQL)
*Une partie front-end désigne les éléments de l’application que l’on voit à l’écran et avec
lesquels on peut interagir depuis un navigateur (il s’agit notamment de polices, de menus,
de boutons, de formulaires ) nous avons utilisé le framework Angular 7.
19
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.8. structure de projet
Figure 2.3 – Architecture
2.8 structure de projet

Dans cette partie on va représente la structure de notre application qui est representé
de deux partie back et front
2.8.1 Structure Back-end

Dans la figure 2.4 on peut voir la structure de notre back-end qui est composée de 6 pa-
ckages intitulés (com,com.controllers,com.entity,com.repository,com.security,com.services,
com.servicesImp)
20
Figure 2.4 – Structure Back-end du projet
Couche DAO
Package com.entity
-La class Usermanager.java de la figure 2.5 est un exemple de ce package dans laquel on
à fixé les differents associations entre les entités ainsi que les clés primaires,les jointures
et contructeurs tel que le constructeur par défault
21
Figure 2.5 – Usermanager.java
Package com.repository
L’exemple de la figure 2.6 de ce package nous montre que le role de ce dernier est d’im-
plementer une interface dans laquel on déclare les différentes services web(qui ne sont pas
génerer par le spring boot) selon le besoin et faire appel a des requettes hql
22
Figure 2.6 – UserRepository
Couche Métier
Package com.services
La figure 2.7 montre que ce package nous permet declarer les services qu’on va les imple-
menter dans le package com.servicesImpl
23
Figure 2.7 – UserService
Package com.servicesImpl
Elle nous permet d’implementer des sevices qu’on à definie dans le package com.services
elle est composé de trois annotation :
@Service : Très similaire en pratique à @Component. Initialement défini par Domain-

Driven Design comme "une opération offerte en tant qu’interface qui se trouve seule dans
le modèle, sans état encapsulé".
@Autowired : L’annotation @Autowired permet de sauter des configurations ailleurs,

elle permet l’injection des dépendances.
@Override : permet la redéfinition des méthodes
24
Figure 2.8 – UserServiceImp
Couche Web
Package com.controllers
La figure 2.9 nous montre que dans cette partie on va donnée un mapping a chaque service
web et de cette façon on peut l’identifier ce qui facilite la communication entre le back-
end et le front-end puisque on va faire appel a chaque service par son mapping en plus ce
package est trés utile pour définir les déférents méthode de manipulation des services tel
que get,post,delete....
25
Figure 2.9 – UserController
2.8.2 Structure Front-end

La figure 2.10 nous montre que la partie front-end de notre application est composé
de 3 sous parties tel que models,views,services
26
Figure 2.10 – Structure Front-end du projet
27
models
Ce modèle correspond à une classe, donc un nouveau type. Il sera utilisé par le com-
ponent, le template ainsi que pour transmettre les données au service est ca ce qui illustre
la figure 2.11
Figure 2.11 – User model
28
services
D’aprés la figure 2.12 on peut conclure que Dans cette partie on va définit les services
à utiliser dans ce composant (component).
Figure 2.12 – User service
29
views
La figure 2.13 partie views de la composante user est constitué de trois fichier : un
fichier html, un fichier scss et un fichier type script.
Figure 2.13 – User view
30
Users.component.html La figure 2.14 illustre que la partie html est utile pour
construire le formulaire de chaque composant de l’application
Figure 2.14 – Users.component.html
31
Users.component.ts La figure 2.15 montre que la partie component.ts nous permet

de faire appel au services qu’on à définie la partie services
Figure 2.15 – Users.component.ts
32
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.9. Conclusion
Users.component.scss d’aprés la figure 2.16 on peut dire que le role de cette partie
est simplement de faire le désigne des interfaces
Figure 2.16 – Users.component.scss
2.9 Conclusion
À l’issue de ce chapitre, nous avons présenté une étude de notre application qui sera
enrichie et détaillée durant les prochains chapitres, ainsi que l’architecture de notre travail.
La réalisation du premier sprint sera exposée dans le chapitre suivant.
33
CHAPITRE 3
SPRINT 1 :GESTION DES MENUES ET
DES UTILISATEURS
Introduction
L’étape la plus cruciale dans le processus Scrum est le sprint. Celui-ci va être réalisé
pendant une certaine tranche de temps, et à sa fin, l’équipe doit présenter un produit
livrable. Dans ce premier sprint, nous allons réaliser la gestion des menues et des
utilisateurs.
3.1 Le backlog du Sprint

Le backlog de sprint est l’ensemble des éléments de backlog de produit sélectionné
pour le sprint, ainsi qu’un plan pour fournir l’incrément de produit et atteindre l’objectif
Sprint. Ce backlog représente une prévision de l’ équipe de développement sur les fonction-
nalités qui figureront dans le prochain incrément et sur le travail nécessaire pour intégrer
cette fonctionnalité dans un incrément «Terminé». Le backlog de sprint rend visible tout
le travail que l’équipe de développement a identifié comme nécessaire pour atteindre l’ob-
jectif de sprint. Le tableau 3.1 regroupe toutes les fonctionnalités qui seront développées
au sein de ce sprint.
Rang User Story Cas d’utilisation Estimation
En tant qu’utilisateur, je
1 dois m’authentifier pour Authentification 7 jours
accéder à l’application
En tant que personnel, je

2.1 souhaite ajouter un ou Gestion des Menus 3 jours
plusieurs menus.
34
Chapitre 3. Sprint 1 :Gestion Des Menues et des Utilisateurs 3.1. Le backlog du Sprint

2.2 souhaite afficher la liste des Gestion des Menus 1 jour
menus.

2.3 souhaite modifier un ou Gestion des Menus 1 jour
plusieurs menus.

2.4 souhaite chercher un menu Gestion des Menus 1 jour
dans la liste des menus.

2.5 souhaite supprimer un ou Gestion des Menus 1 jour
plusieurs menus.

3.1 souhaite ajouter un ou Gestion des rôles 3 jours
plusieurs rôles.

3.2 souhaite afficher les rôles. Gestion des rôles 1 jour
avec leurs informations.

3.3 souhaite modifier un ou Gestion des rôles 1 jour
plusieurs rôles.
En tant que personnel, je 1 jour

3.4 Gestion des rôles
souhaite chercher un rôle.

3.5 souhaite supprimer un ou Gestion des rôles 1 jour
plusieurs rôles

4.1 souhaite ajouter un ou Gestion des utilisateurs 3 jours
plusieurs utilisateurs

souhaite afficher les 1 jour
4.2 Gestion des utilisateurs
utilisateurs avec leurs
informations.
35
Chapitre 3. Sprint 1 :Gestion Des Menues et des Utilisateurs
3.2. Spécification fonctionnelle

4.3 souhaite modifier un ou Gestion des utilisateurs 1 jour
plusieurs utilisateurs.

4.4 souhaite chercher un ou Gestion des utilisateurs 1 jour

4.5 souhaite supprimer un ou Gestion des utilisateurs 1 jour
plusieurs utilisateurs
Table 3.1 – Backlog Sprint 1
3.2 Spécification fonctionnelle

Lors de la première étape de chaque itération, la spécification fonctionnelle se traduit
par un diagramme de cas d’utilisation. Celui-ci donne une vue extérieure du système et
définit les fonctionnalités que propose celui-ci.
3.3 Diagramme du cas d’utilisation

La figure 3.1 illustre le diagramme de cas d’utilisation initial du sprint 1, dans ce
Sprint le Personnel (Exemple : Directeur projet) doit d’abord s’authentifier pour avoir ses
fonctionnalités, il peut gérer : les menus, les utilisateurs et les rôles.
Figure 3.1 – Diagramme de cas d’utilisation du Sprint 1
36
3.3. Diagramme du cas d’utilisation
3.3.1 Description textuelle du cas d’utilisation «S’authentifier»

Afin de mieux assimiler les cas d’utilisation, nous avons établi leurs raffinements pour
livrer une description sur les différents scénarios possibles qui sont représentés dans le
tableau 3.2
Cas d’utilisation S’authentifier
Acteur tous les utilisateurs
Pré Condition • une connextion au serveur doit étre établie
Post Condition • utilisateur authentifié
Scénario principal 1. l’utilisateur saisit son login et son mot de passe

2. il confirme en cliquant sur le bouton «login»
3. le système affiche l’interface d’accueil(Dashboard)propre à
l’utilisateur
Scénario alternatif Le système affiche un message d’erreur informant l’utilisateur que

son login ou mot de passe sont incorrects
Table 3.2 – Description textuelle du cas d’utilisation "s’authentifier"
3.3.2 Diagramme de séquence système du cas «S’authentifier»

La Figure 3.2 illustre le diagramme de séquence du premier cas dans notre sprint.
Chaque utilisateur doit s’authentifier, en fournissant son Username et son Password afin
d’accéder à l’application. Si les données saisies sont erronées, le système affiche un message
d’erreur.
37
Figure 3.2 – Diagramme de séquence système du " s’authentifier "
3.3.3 raffinement du cas d’utilisation «Gérer les menus»

La figure 3.3 représente le raffinement du cas « Gérer les menus ». Lorsque le personnel
accède à la page qui gère les menus, il peut afficher, ajouter, modifier , supprimer ou
chercher un menu.
38
Figure 3.3 – Raffinement du « Gérer les menus »
3.3.4 Description textuelle du cas d’utilisation « Gérer les

menus»
livrer une description sur les différents scénarios possibles qui sont représentés dans le
tableau 3.3
Cas d’utilisation Gérer les menus
Acteur Personnel
Pré Condition • application active

• le personnel est authentifier
Post Condition • ajouter,modifier,supprimer,rechercher un menu

• les menus sont générer et sauvegarder dans le système
39
Scénario principal 1. le personnel consulte la liste des menus

2. pour ajouter un menu,le personnel remplit les informations
qui concerne ce dernier en choisissant son role et en cliquant
sur le bouton « validé »
3. Pour modifier un menu, le personnel sélectionne ce dernier,
change les informations, puis il clique sur le bouton « « Valider
»»
4. Pour chercher un menu, il suffit que le personnel saisit ces
propriétés
5. Pour supprimer un menu, le personnel sélectionne ce dernier,
puis il clique sur le bouton Supprimer
Scénario alternatif Un message d’erreur s’affiche afin d’informer le personnel qu’il a

laissé un champ vide
Table 3.3 – tableau descriptif du cas d’utilisation « Gérer les menus »
3.3.5 Diagramme de séquence du cas d’utilisation «Gérer les

menus»
La Figure 3.4 illustre le diagramme de séquence gérer les menus. Chaque personnel
peut gérer ses menus c’est a dire consulter,modifier,supprimer,et ajouter un menu
Figure 3.4 – Diagramme de séquence « « Gérer les menus » »
40
3.3.6 Raffinement du cas d’utilisation «Gérer les rôles»

La figure 3.5 représente le raffinement du cas d’utilisation « Gérer les rôles ». Lorsque
le personnel accède à la page qui gère les rôles, il peut afficher, ajouter, modifier, supprimer
ou chercher un rôle.
Figure 3.5 – Raffinement du « Gérer les rôles »
3.3.7 Description textuelle du sous cas d’utilisation « Gérer les

rôles »
livrer une description sur les différents scénarios possibles qui sont représentés dans la
table 3.4
Cas d’utilisation Gérer les rôles
Acteur Personnel

Post Condition • ajouter,modifier,supprimer,rechercher un role

• les roles sont génèrer et sauvegarder dans le système
41
Scénario principal 1. Le personnel consulte la liste des rôles.

2. Pour ajouter un rôle, le personnel remplit les informations qui
concernent ce dernier, puis il clique sur le bouton « Valider »
3. Pour modifier un rôle, le personnel sélectionne ce dernier,
change les informations, puis il clique sur le bouton
« Valider »
4. Pour chercher un rôle, il suffit que le personnel saisit ces
propriétés
5. Pour supprimer un rôle, le personnel sélectionne ce dernier,
puis il clique sur le bouton Supprimer.
6. Le personnel affecte un rôle a un menu.
7. Le personnel affecte un rôle a un utilisateur.

Table 3.4 – tableau descriptif du cas d’utilisation « Gérer les roles »
3.3.8 Diagramme de séquence de sous cas d’utilisation «Gérer

rôles»
La Figure 3.6 illustre le diagramme de séquence gérer les rôles. Chaque personnel peut
gérer ses rôles c’est a dire ajouter,modifier,supprimer,chercher,afficher les rôles
Figure 3.6 – Diagramme de séquence « « Gérer rôles » »
42
3.3.9 Raffinement du cas d’utilisation «Gérer les utilisateurs»

La figure 3.7 représente le raffinement du cas d’utilisation « Gérer les utilisateurs ».
Lorsque le personnel accède à la page qui gère les utilisateurs, il peut afficher, ajouter,
modifier, supprimer ou chercher un utilisateur.
Figure 3.7 – Raffinement du « Gérer les utilisateurs »
3.3.10 Description textuelle du sous cas d’utilisation «Gérer les

utilisateurs»
livrer une description sur les différents scénarios possibles dans la table 3.5
Cas d’utilisation Gérer les utilisateurs
Acteur Personnel

Post Condition • ajouter,modifier,supprimer,rechercher un utilisateur

• les utilisateurs sont génèrer et sauvegarder dans le système
43
Scénario principal 1. Le personnel consulte la liste des utilisateurs.

2. Pour ajouter un utilisateur, le personnel remplit les
informations qui concernent ce dernier, puis il clique sur le
bouton « validé »
3. Pour modifier un utilisateur, le personnel sélectionne ce
dernier, change les informations, puis il clique sur le bouton
« Validé »
4. Pour chercher un utilisateur, il suffit que le personnel saisit
ces propriétés
5. Pour supprimer un utilisateur, le personnel sélectionne
ce dernier, puis il clique sur le bouton Supprimer

Table 3.5 – tableau descriptif du cas d’utilisation « Gérer les utilisateurs »
3.3.11 Diagramme de séquence du sous cas d’utilisation «Gérer

utilisateurs»
La Figure 3.8 illustre le diagramme de séquence gérer les utilisateurs. Chaque personnel
peut gérer ces derniers c’est à dire rechercher,supprimer,ajouter et modifier un utilisateur
Figure 3.8 – Diagramme de séquence « « Gérer utilisateurs » »
44
3.4. Diagramme du cas d’utilisation globale du
Chapitre 3. Sprint 1 :Gestion Des Menues et des Utilisateurs premier sprint :
3.4 Diagramme du cas d’utilisation globale du

premier sprint :
La figure 3.9 représente le diagramme du cas d’utilisation globale de notre premier
Sprint
Figure 3.9 – Diagramme de cas d’utilisation global du première Sprint
45
Chapitre 3. Sprint 1 :Gestion Des Menues
3.5. Diagramme
et des Utilisateurs
de classe global du premier sprint
3.5 Diagramme de classe global du premier sprint

La figure 3.10 représente le diagramme de classe globale de notre premier Sprint.
Chaque utilisateur est caractérisé par un code-user, un login, un password, un rôle, un
type-user, on a deux types d’utilisateurs l’un est client l’autre est personnel, et il possède
un rôle. Chaque rôle a un ou plusieurs menus.
Figure 3.10 – Diagramme de class globale du premier sprint
46
3.6. Réalisation du premier sprint
3.6 Réalisation du premier sprint

3.6.1 L’interface de l’authentification
Au lancement de l’application, l’utilisateur se trouve en face d’une fenêtre d’authentifi-
cation présentée dans la figure 3.11. Cette interface est commune pour tous les utilisateurs.
Figure 3.11 – Page login
3.6.2 L’interface de « Gérer les menus »

La figure 3.12 représente l’interface qui gère les menus. Une fois que le personnel
s’authentifie, il est le seul ayant accès à cette interface. En effet, il a le droit de consulter
la liste des menus, d’ajouter, modifier, chercher et supprimer un ou plusieurs menus.
Figure 3.12 – L’interface "Gestion des Menus"
47
3.6.3 L’interface de « Gérer les rôles »

La figure 3.13 représente l’interface qui gère les rôles. Le personnel a le droit de
consulter la liste des rôles, il peut ajouter, modifier, chercher et supprimer un ou plusieurs
rôles.
Figure 3.13 – L’interface "Gestion des Roles "
3.6.4 L’interface de « Gérer les utilisateurs »

La figure 3.14 représente l’interface qui gère les utilisateurs. Le personnel a le droit de
consulter la liste des utilisateurs, il peut ajouter, modifier, chercher et supprimer un ou
Figure 3.14 – L’interface "Gestion utilisateurs"
48
3.6.5 L’interface de client

La figure 3.15 ci dessous représente l’authentification pour le client
Figure 3.15 – Page login pour client
3.6.6 L’interface de dashboard

La figure 3.16 représente le Dashboard pour le client
Figure 3.16 – : Page «Dashboard» pour le client
49
3.7. Revue du premier Sprint
3.7 Revue du premier Sprint

Après une réunion avec le Scrum Master, il s’est avéré que le plan du Sprint est
conforme à ce qui a été réalisé pendant cette première itération, le Sprint est donc valide.
3.8 Rétrospective du premier Sprint

Nous avons identifié les axes d’amélioration à prendre en compte pendant le prochain
Sprint. Et cela à travers un résumé de la façon dont s’est déroulé le Sprint, avec ses points
positifs, ses points négatifs, les décisions et les événements marquants.
3.9 Conclusion
A la fin d’un sprint les user stories du backlog se traduisent en un produit, considéré
potentiellement livrable par rapport au produit final. Dans ce chapitre nous avons réussi
à produire un incrément jugé suffisamment utile pour le client. Le prochain chapitre
constitue une continuité de réalisation du projet dans sa phase du deuxième sprint.
50
CHAPITRE 4
SPRINT 2 LA GESTION DES CONTRATS
ET DES PRODUITS
Introduction
Aprés l’achévement du premier sprint, nous entamerons le deuxiéme sprint. Nous allons
exposer dans ce chapitre la réalisation de ce sprint réparti en quatre parties.
4.1 Planification du deuxiéme Sprint

Avant le démarrage du Sprint, Une réunion a été mise en place pour déterminer
l’objectif et le plan détaillé de l’itération.
4.1.1 Le backlog du Sprint

le tableau 4.1 ci-dessous correspond a une étude spécifique des besoins de clients qui
est constituer en 4 parties Gestion des entreprises,Gestion des départements,Gestion de
produits et gestion des contrats selon
Rang User story Cas d’utilisation Estimation

5.1 En tant que personnel, je Gestion des entreprises 2 jours
souhaite ajouter une ou plu-
sieurs entreprises.
souhaite afficher toutes les
entreprises..
souhaite modifier une ou
plusieurs entreprises.
51
Chapitre 4. sprint 2 la Gestion des contrats et des4.1.
produits
Planification du deuxiéme Sprint

souhaite chercher une ou
plusieurs entreprises.
souhaite supprimer une ou
plusieurs entreprises..

5.6 souhaite affecter une en-
treprise a un ou plusieurs 1 jours
clients
6.1 En tant que personnel, je Gestion des départements 2 jours
souhaite ajouter un ou plu-
sieurs départements..
souhaite afficher tous les dé-
partements.
souhaite modifier un ou plu-
sieurs départements.
souhaite chercher un ou plu-
sieurs départements.
souhaite supprimer un ou
plusieurs départements.
6.6
souhaite affecter un dépar-
tement a un ou plusieurs 1 jours
personnels.
7.1 En tant que personnel, je Gestion des produits 3 jours
sieurs produits.
souhaite afficher tous les
produits
sieurs produits
sieurs produit
52
Chapitre 4. sprint 2 la Gestion des contrats et des produits
4.2. Spécification fonctionnelles

plusieurs produits
8.1 En tant que personnel, je Gestion des contrats 3 jours
sieurs contrats
souhaite afficher tous les
contrats
8.3 En tant que d personnel, je Gestion des contrats 1 jours
sieurs contrats
sieurs contrats
plusieurs contrats
4.2 Spécification fonctionnelles

Lors de la premiére étape de chaque itération, la spécification fonctionnelle se traduit
par un diagramme de cas d’utilisation. Celui-ci donne une vue extérieure du systéme et
4.2.1 Diagramme du cas d’utilisation

La figure 4.1 ci-dessous illustre le diagramme de cas d’utilisation du sprint 2, dans ce
Sprint le personnel (Exemple : Directeur projet) doit d’abord s’authentifier pour avoir ses
fonctionnalités, il peut gérer : les entreprises, les départements, les produits et les contrats.
53
Figure 4.1 – Diagramme de cas d’utilisation du Sprint 2
4.2.2 Raffinement du cas d’utilisation « Gérer les entreprises »

La figure 4.2 illustre le raffinement du cas d’utilisation "Gérer les entreprises",
le personnel peut afficher, ajouter, modifier, supprimer, chercher une ou plusieurs entre-
prises et il peut aussi affecter une entreprise a un ou plusieurs clients.
Figure 4.2 – Raffinement du « Gérer les entreprises »
54
4.2.3 Descriptif textuel du cas d’utilisation « Gérer

les entreprises »
Afin de mieux assimiler les cas d’utilisation"Gérer les entreprises", nous avons établi
leurs raffinements pour livrer une description sur les différents scénarios possibles et les
conditions d’utilisations qui sont representé dans la table 4.2
Cas d’utilisation Gérer les entreprises
Acteur Personnel
Pré Condition • Application active

• Le Personnel est authentifié.
Post Condition
• ajouter, modifier, trouvé, supprimer une entreprise ;
• une entreprise est affecté à un client ;
• les entreprises sont génère et sauvegarder dans le système
Scénario principal 1. Le personnel consulte la liste des entreprises.

2. Pour ajouter une entreprise, le personnel remplit les informa-
tions qui concernent ce dernier, puis il clique sur le bouton «
Valider »
3. Pour modifier une entreprise, le personnel sélectionne
ce dernier, change les informations, puis il clique sur le bouton
« Valider »
4. Pour chercher une entreprise, il suffit que le personnel saisit
ces propriétés.
5. Pour supprimer une entreprise, le personnel sélectionne ce
dernier, puis il clique sur le bouton Supprimer.
6. Le personnel affecte une entreprise a un client.
Un message d’erreur s’affiche afin d’informer le client qu’il a laissé

Scénario alternatif un champ vide.
Table 4.2 – Description textuelle du cas d’utilisation " Gérer les entreprises "
55

les entreprises»
la figure 5.3 représente le diagramme de séquence de sous cas d’utilisation «Gérer les
entreprises». Le personnel aprés authentification peut consulter le menu gérer entreprises
il peut aussi afficher,rechercher et ajouter une entreprise
Figure 4.3 – Diagramme de séquence « Gérer les entreprises »
4.2.5 Raffinement du cas d’utilisation « Gérer les départements

»
La figure 4.4 ci-dessous illustre le raffinement du cas d’utilisation "Gérer les départe-
ments", le personnel peut afficher, ajouter, modifier, supprimer, chercher une ou plusieurs
départements et il peut aussi affecter un département à un ou plusieurs personnels.
56
Figure 4.4 – Raffinement du « Gérer les départements »
4.2.6 Descriptif textuel du cas d’utilisation « Gérer les dépar-

tements»
Afin de mieux assimiler les cas d’utilisation"Gérer les départements", nous avons établi
leurs raffinements pour livrer une description sur les différents scénarios possibles et les
conditions d’utilisations qui sont representé dans la table 4.3
Cas d’utilisation Gérer les départements
Acteur
— Personnel

Post Condition • ajouter, modifier, trouvé, supprimer un departement ;

• un departement est affecté à un personnel ;
• les entreprises sont génère et sauvegarder dans le système
57
Scénario principal 1. Le personnel consulte la liste des départements.

2. Pour ajouter un département, le personnel remplit les
informations qui concernent ce dernier, puis il clique sur le
bouton « Valider »
3. Pour modifier un département, le personnel sélectionne ce
« Valider »
4. Pour chercher un département, il suffit que le personnel saisit
ces propriétés.
5. Pour supprimer un département, le personnel sélectionne ce
6. Le personnel affecte un département à un personnel.
Scénario alternatif — Un message d’erreur s’affiche afin d’informer le client qu’il a

laissé un champ vide.
Table 4.3 – Description textuelle du cas d’utilisation " Gérer les entreprises "

les départements»
la figure 4.5 représente le diagramme de séquence de sous cas d’utilisation «Gérer
les départements». Le personnel(exemple directeur projet) aprés authentification peut
consulter le menu Gérer les départements il peut aussi afficher,supprimer,rechercher et
ajouter un département
58
Figure 4.5 – Diagramme de séquence « Gérer les départements »
4.2.8 Raffinement du cas d’utilisation « Gérer les produits »

La figure 4.6 illustre le raffinement du cas d’utilisation "Gérer les produits", le personnel
peut afficher, ajouter, modifier, supprimer et chercher un ou plusieurs produits.
59
Figure 4.6 – Raffinement du « Gérer les produits »
4.2.9 Descriptif textuel du cas d’utilisation « Gérer les

produits»
Afin de mieux assimiler les cas d’utilisation"Gérer les produits", nous avons établi leurs
raffinements pour livrer une description sur les différents scénarios possibles et les condi-
tions d’utilisations qui sont representé dans la table 4.4
Cas d’utilisation Gérer les produits
Acteur
— Personnel

Post Condition
• ajouter, modifier, trouvé, supprimer un produit ;
• les produits sont génère et sauvegarder dans le système
60
Scénario principal 1. Le personnel consulte la liste des produits.

2. Pour ajouter un produit, le personnel remplit les informations
qui concernent ce dernier, puis il clique sur le bouton « Valider
»
3. Pour modifier un produit, le personnel sélectionne ce dernier,
change les informations, puis il clique sur le bouton « Valider
»
4. Pour chercher un produit, il suffit que le personnel saisit ces
propriétés.
5. Pour supprimer un produit, le personnel sélectionne ce der-
nier, puis il clique sur le bouton Supprimer.

Table 4.4 – Description textuelle du cas d’utilisation " Gérer les produits "

les produits»
produits». Le personnel(Exemple : directeur projet) aprés authentification peut consulter
le menu Gérer les dil peut aussi afficher,rechercher,supprimer ajouter un produit
61
Figure 4.7 – Diagramme de séquence «Gérer produits »
4.2.11 Raffinement du cas d’utilisation « Gérer les contrats »

La figure 4.8 illustre le raffinement du cas d’utilisation "Gérer les contrats",
personnel peut afficher, ajouter, modifier, supprimer et chercher un ou plusieurs contrats.
62
Figure 4.8 – Raffinement du « Gérer les contrats »
4.2.12 Descriptif textuel du cas d’utilisation « Gérer les contrats»

Afin de mieux assimiler les cas d’utilisation"Gérer les contrats", nous avons établi leurs
raffinements pour livrer une description sur les différents scénarios possibles et les condi-
tions d’utilisations qui sont representé dans la table 4.5
Cas d’utilisation Gérer les contrats
Acteur — Personnel

Post Condition
• ajouter, modifier, trouvé, supprimer un contrat
• entreprise affecter à un client
• les contrats sont génère et sauvegarder dans le système
63
Scénario principal 1. Le personnel consulte la liste des entreprises.

2. Pour ajouter une entreprise, le personnel remplit les informa-
tions qui concernent ce dernier, puis il clique sur le bouton
« Valider »
3. Pour modifier une entreprise, le personnel sélectionne ce
« Valider »
4. Pour chercher une entreprise, il suffit que le personnel saisit
ces propriétés.
5. Pour supprimer une entreprise, le personnel sélectionne ce
6. Le personnel affecte une entreprise a un client.

Table 4.5 – Description textuelle du sous cas d’utilisation " Gérer les contrats "
4.2.13 Diagramme de séquence du sous cas d’utilisation«Gérer

contrat»
contrats». Le personnel(exemple directeur projet) aprés authentification peut consulter
le menu Gérer les départements il peut aussi afficher,supprimer,rechercher et ajouter un
département
64
Figure 4.9 – Diagramme de séquence« Gérer contrats »
4.2.14 Diagramme du cas d’utilisation globale du deuxième Sprint

La figure 4.10 représente le diagramme du cas d’utilisation globale du deuxième sprint
,le personnel(Directeur projet) a le droit de : gérer les entreprises ,gérer les départements
, gérer les produits, gérer les contrats.
65
Chapitre 4. sprint 2 la Gestion des4.3.
contrats
Diagramme
et des produits
de classe global du deuxième Sprint
Figure 4.10 – Diagramme de cas d’utilisation globale du deuxième Sprint
4.3 Diagramme de classe global du deuxième Sprint

La figure 4.11 représente le diagramme de classe globale de notre deuxième sprint , ce
diagramme est composé de neuf classes, un Personnel qui possède un Département , un
Client qui possède une Entreprise et un contrat ,le contrat est affecter a un produit
66
Chapitre 4. sprint 2 la Gestion des contrats et des 4.4.
produits
Réalisation du deuxième Sprint
Figure 4.11 – Diagramme de classe du deuxième sprint.
4.4 Réalisation du deuxième Sprint

Nous allons présenter la réalisation du deuxième sprint par la description des interfaces
développées.
4.4.1 L’interface de « ajouter menu Gestion entreprise »

La figure 4.12 représente l’interface de « Ajouter Menu » pour l’ajout du menu Gestion
entreprises. Une fois le personnel est authentifié, il peut accéder à cette interface
67
produits
Figure 4.12 – L’interface «Ajouter Menu» pour l’ajout du menu Gestion entreprises
4.4.2 L’interface de « Gérer les entreprises »

La figure 4.13 représente l’interface de gérer les entreprises. Une fois le personnel est
authentifié, il peut accéder à cette interface. Il a le droit d’afficher, ajouter, modifier,
supprimer et chercher une ou plusieurs entreprises.
Figure 4.13 – L’interface «Gestion entreprise»
68
produits
4.4.3 L’interface de « ajouter menu Gestion département »

La figure 4.14 représente l’interface de « « Ajouter Menu » » pour l’ajout du menu
Gestion départements. Une fois le personnel est authentifié, il peut accéder à cette
interface
Figure 4.14 – L’interface «Ajouter Menu» pour l’ajout du menu Gestion départements
4.4.4 L’interface de « Gérer les départements »

La figure 4.15 représente l’interface de gérer les départements. Une fois le personnel
est authentifié, il peut accéder à cette interface. Il a le droit d ?afficher, ajouter, modifier,
supprimer et chercher un ou plusieurs départements.
69
produits
Figure 4.15 – L’interface «Gestion départements»
4.4.5 L’interface de « ajouter menu Gestion produits

Gestion produits. Une fois le personnel est authentifié, il peut accéder à cette interface. Il
a le droit d’ajouter un menu.
Figure 4.16 – L’interface «Ajouter Menu» pour l’ajout du menu Gestion produits
70
produits
4.4.6 L’interface de « Gérer les produits »

La figure 4.17 représente l’interface de gérer les produits. Une fois le personnel est
authentifié, il peut accéder à cette interface. Il a le droit d ?afficher, ajouter, modifier,
supprimer et chercher un ou plusieurs produits.
Figure 4.17 – L’interface «Gestion produits»
4.4.7 L’interface de « ajouter menu Gestion Contrats »

Gestion contrats. Une fois le personnel est authentifié, il peut accéder à cette interface.
71
produits
Figure 4.18 – L’interface «Ajouter Menu» pour l’ajout du menu Gestion contrats
4.4.8 L’interface de « Gérer les contrats »

La figure 4.19 représente l’interface de gérer les contrats. Une fois le personnel est
authentifié, il peut accéder à cette interface.
Figure 4.19 – L’interface «Gestion contrats»
4.4.9 L’interface de « Ajouter un contrat »

Pour ajouter un contrat il suffit de remplir ce formulaire, en lui affecte ce dernier un
produit, un client et un personnel
72
4.5. Revue du deuxième Sprint
Figure 4.20 – L’interface «Ajouter Contrats»
4.5 Revue du deuxième Sprint

conforme à ce qui a été réalisé pendant cette deuxième itération, le Sprint est donc valide.
4.6 Rétrospective du deuxième Sprint

Nous avons identifié les axes d’amélioration à prendre en compte pendant le prochain
Sprint. Et cela à travers un résumé de la façon dont s’est déroulé le Sprint, les décisions
et les événements marquants.
4.7 Conclusion
Un autre produit potentiellement livrable s’ajoute à la liste des produits fournis à
la fin de chaque itération réalisée dans notre projet.Dans ce chapitre nous avons réussi
à produire un incrément jugé suffisamment utile, dans le prochain chapitre nous allons
attaquer le troisième sprint.
73
CHAPITRE 5
SPRINT3 : GESTION DES
RÉCLAMATIONS ET DES
INTERVENTIONS
Introduction
Aprés l’achévement du deuxiéme sprint, nous entamerons le troisiéme sprint. Nous
allons exposer dans ce chapitre la réalisation de ce sprint réparti en quatre modules ou il
ya une interaction entre le client et le personnel.
5.1 planification du deuxiéme Sprint

Avant le démarrage du Sprint, Une réunion a été mise en place pour déterminer
l’objectif et le plan détaillé de l’itération.
5.1.1 Le backlog du Sprint

le tableau 5.1 ci-dessous correspond a une étude spécifique des besoins de clients qui
est constituer en 6 parties consulter mes produits,consulter mes contrats,Gérer récalam-
tions,Gérer interventions et administrer reclamations et interventions
Rang User story Cas d’utilisation Estimation

9.1 En tant que client, je sou- Consulter mes 3 jours
haite afficher mes produits produits
9.2 En tant que client, je sou- Consulter mes produits 2 jours
haite chercher un produit
9.3 En tant que client, je sou- Consulter mes produits 2 jours
haite afficher les détails d’un
produit
10.1 En tant que client, je sou- Consulter mes contrats 3 jours
haite afficher mes contrats
74
Chapitre 5. sprint3 : Gestion des réclamations et 5.1.
des interventions
planification du deuxiéme Sprint

haite chercher un contrat
haite afficher les détails d’un
contrat
11.1 En tant que client, je sou- Gérer réclamations 3 jours
haite ajouter une réclama-
tion
haite afficher les réclama-
tions
11.3 En tant que client, je sou- Gérer réclamations 1 jour
haite chercher une réclama-
tion
haite supprimer une récla-
mation
13.1 En tant que client, je Gérer interventions 1 jours
souhaite afficher les ré-
clamations et les PV-
interventions
13.2 En tant que client, je sou- Gérer interventions 3 jours
haite ajouter une interven-
tion
13.3 En tant que client je Gérer interventions 3 jours
souhaite Valider la PV-
intervention
12.1 En tant que personnel, je Administrer réclamations 1 jours
souhaite consulter les récla-
mations
souhaite ajouter une PV-
intervention
souhaite consulter une in-
tervention
souhaite chercher une récla-
mation
souhaite, supprimer une ré-
clamation
14.1 En tant que personnel, je Administrer interventions 3 jours
souhaite afficher les PV-
intervention ou intervention
75
Chapitre 5. sprint3 : Gestion des réclamations et des interventions
14.2 En tant que personnel, je Administrer interventions 3 jours

souhaite chercher une inter-
vention ou PV-intervention
14.3 En tant que personnel, je Administrer interventions 1 jour
souhaite supprimer une PV-
intervention
5.2 Spécification fonctionnelles

Lors de la premiére étape de chaque itération, la spécification fonctionnelle se traduit
par un diagramme de cas d’utilisation. Celui-ci donne une vue extérieure du systéme et
5.2.1 Diagramme du cas d’utilisation du Sprint 3

La figure ci-dessous illustre le diagramme de cas d’utilisation du sprint 3, dans ce
Sprint le Client doit d’abord s’authentifier pour avoir ses fonctionnalités, il peut : consul-
ter ses produits, consulter ses contrats, gérer ces réclamations et ces interventions, et le
personnel aussi doit d’abord s’authentifier pour avoir ses fonctionnalités, il peut : admi-
nistrer les réclamations, administrer les interventions.
Figure 5.1 – Diagramme du cas d’utilisation du sprint 3
76
5.2.2 Raffinement du sous cas d’utilisation "Consulter les pro-

duits"
La figure ci-dessous illustre le raffinement du cas d’utilisation « Consulter les produits
», le client a le pouvoir d’afficher ses produits, afficher les détails de ses produits et de
chercher un produit.
Figure 5.2 – Raffinement du « Consulter les produits »
5.2.3 Description textuelle du sous cas d’utilisation "Consulter

les produits"
livrer une description sur les différents scénarios possibles qui sont representé dans la table
5.2
Cas d’utilisation Consulter les produits
Acteur Client

• Le Client est authentifié.
• -le client posséde un ou plusieurs produits
Post Condition -produit consulté, affiché
77
Scénario principal 1. Le client affiche la liste de ses produits

2. Pour afficher les
3. détails d’un produit, le client sélectionne se dernier, puis
clique sur le bouton
4. Le client peut aussi chercher un produit
Scénario alternatif Pas d’exception
Table 5.2 – Description textuelle du sous cas d’utilisation " Consulter les produits "

«Consulter les produits»
la figure 5.3 représente le diagramme de séquence de sous cas d’utilisation «Consulter
produits». Le client aprés authentification peut consulter le menu produits,afficher la liste
de produits,rechercher un produit
Figure 5.3 – diagramme de séquence du « Consulter les produits »
78
5.2.5 Raffinement du sous cas d’utilisation "Consulter les contrats"

La figure ci-dessous 5.4 illustre le raffinement du cas d’utilisation « Consulter les
contrats », le client a le pouvoir d’afficher ses contrats, afficher les détails de ses contrats
et de chercher un contrat.
Figure 5.4 – Raffinement du « Consulter les contrats »
5.2.6 Description textuelle du sous cas d’utilisation "Consulter

les contrats"
livrer une description sur les différents scénarios possibles.
Cas d’utilisation Consulter les contrats
Acteur Client

• le client posséde un ou plusieurs contrats
Post Condition contrat consulté, affiché
79
Scénario principal 1. Le client affiche la liste de ses contrats Pour afficher les détails
d’un contrat, le client sélectionne se dernier, puis clique sur
le bouton
2. Le client peut aussi chercher un contrat
Table 5.3 – Description textuelle du sous cas d’utilisation " Consulter les contrats "

«Consulter les contrats»
la figure 5.5 représente le diagramme de séquence consulter les contrats , une fois le
client est authentifié ,il peut consulter ces contrats ou chercher l’un d’eux et voir aussi ces
détails
Figure 5.5 – diagramme de séquence « Consulter contrats »
80
5.2.8 Raffinement du cas d’utilisation "Gérer réclamations "

La figure 5.6 illustre le raffinement du cas d’utilisation « Gestion réclamations », le
client a le pouvoir d’ajouter , afficher, chercher et supprimer une réclamation.
Figure 5.6 – Raffinement du « Gestion Réclamations »

de réclamations »
livrer une description sur les différents scénarios possibles. de cas d’utilisation Gestion de
réclamations ceci est representé dans la table 5.4
Cas d’utilisation Gestion de reclamations
Acteur Client

• le client posséde un ou plusieurs produits avec leurs contrats
Post Condition
• réclamation consulté, ajouté, trouvé, supprimé
• les réclamations sont gènére et sauvegarder dans le systéme
81
Scénario principal 1. Pour ajouter une réclamation, le client remplie le formulaire

d’ajout et valide.
2. Pour chercher une réclamation, il suffit de saisir ces propriétés
3. Pour supprimer une réclamation, il suffit de cliquer sur le
bouton de suppression.
Scénario alternatif Un message d’erreur s’affiche afin d’informer le client qu’il a laissé
un champ vide.
Table 5.4 – Description textuelle du cas d’utilisation " Gestion reclamations "
5.2.10 Diagramme de séquence de cas d’utilisation «Gérer ré-

clamations»
La figure 5.7 représente le diagramme de séquence gérer réclamations, une fois le
client est authentifié il a le droit d’afficher la liste des réclamations, d’ajouter, supprimer,
rechercher une réclamation.
Figure 5.7 – diagramme de séquence « Gérer les réclamations »
82
5.2.11 Raffinement du cas d’utilisation "Gérer interventions "

La figure ci-dessous illustre le raffinement du cas d’utilisation « Gestion interventions
», le client a le pouvoir d’afficher les réclamations et les PV-interventions, ajouter une
intervention et valider la PV-intervention.
Figure 5.8 – Raffinement du « Gestion Interventions »

d’intervention »
Afin de mieux assimiler les cas d’utilisation de la gestion d’intervention, nous avons
établi leurs raffinements pour livrer une description sur les différents scénarios possibles
dans la table 5.5 .
Cas d’utilisation Gestion d’interventions
Acteur Client

• Le client a une réclamation
Post Condition
• intervention consulté, ajouté
• PV-intervention validé
• les interventions sont génère et sauvegarder dans le systéme
83
Scénario principal 1. Pour ajouter une intervention, le client remplie le formulaire

d’ajout et valide.
2. Pour valider une PV-intervention, le client clique sur le bou-
ton résolu.

Table 5.5 – Description textuelle du cas d’utilisation " Gestion d’interventions "
5.2.13 Diagramme de séquence du cas d’utilisation «Gérer in-

terventions»
la figure 5.9 représente le diagramme de séquence de sous cas d’utilisation «Gérer
interventions». Le client aprés authentification peut consulter le menu réclamer un pro-
duit,afficher les reclamations,ajouter une reclamation ou une PV-intervention en rempliant
le formulaire d’ajout et bien sur valider les PV-Intervention a fin de cliquer sur le bouton
resolu en cas de satisfaction
Figure 5.9 – diagramme de séquence « Gérer les interventions »
84
5.2.14 Raffinement du sous cas d’utilisation "Administrer

réclamations"
La figure 5.10 illustre le raffinement du cas d’utilisation « Administrer réclamations »,
le personnel a le pouvoir de consulter les réclamations, saisir un PV-intervention, consulter
une intervention, chercher et supprimer une réclamation, .
Figure 5.10 – Raffinement du « Administrer les réclamations »
5.2.15 description textuel du sous cas d’utilisation "Administrer

Reclamations"
Afin de mieux assimiler le cas d’utilisation Administrer les réclamations, nous avons
dans la table 5.6
Cas d’utilisation Administrer les reclamations
Acteur Personnel

• Existence d’une réclamation/intervention
Post Condition • - réclamation consulté

• - une PV-intervention ajouté
• -consulter chercher, supprimer une intervention
• -les réclamations sont génère et sauvegarder dans le système
85
Scénario principal 1. Pour ajouter une PV-intervention, le personnel consulte la

réclamation remplie le formulaire de réponse et valide.
2. Pour chercher une réclamation, le personnel saisi ces propriétés
3. Pour supprimer une réclamation, personnel clique sur le bouton
de suppression.
Table 5.6 – Description textuelle du sous cas d’utilisation "Administrer réclamations "

«Administrer réclamations»
la figure 5.11 représente le diagramme de séquence de sous cas d’utilisation «Adminis-
trer réclamations». Le personnel aprés authentification peut consulter le menu gére récla-
mation afficher la liste des reclamations,supprimer une reclamation, faire une recherche
consulter la liste des anciennes interventions ajouter une PV-intervention en rempliant le
formulaire d’ajout et bien sur valider l’ajout
Figure 5.11 – diagramme de séquence « Administrer réclamation »
86
5.2.17 Raffinement du cas d’utilisation "Administrer interven-

tions"
La figure 5.12 illustre le raffinement du cas d’utilisation « Administrer interventions
», le personnel a le pouvoir d’afficher les interventions ou PV-intervention, chercher une
intervention/PV-intervention, et les supprimer en cas de besoin
Figure 5.12 – Raffinement du « Administrer interventions »
5.2.18 description textuel du cas d’utilisation "Administrer

interventions"
Afin de mieux assimiler les cas d’utilisation Administrer les interventions, nous avons
dans la table 5.7
Cas d’utilisation Administrer interventions
Acteur Personnel

• Existence d’une réclamation, d’une PV-intervention
Post Condition
• -intervention affiché, trouvé, supprimé
• -les interventions sont génère et sauvegarder dans le systéme
87
Scénario principal
1. Pour voir les détails de PV-intervention, il suffit de cliquer
sur le bouton en bleu.
2. Pour chercher une PV-intervention, le personnel saisi ces
propriétés
3. Pour supprimer une PV-intervention, le personnel clique sur
le bouton de suppression.
Table 5.7 – Description textuelle du cas d’utilisation "Administrer Interventions "

«Administrer interventions»
La figure 5.13 représente le diagramme de séquence administrer intervention, une fois
le personnel est authentifié, il peut consulter les PV-interventions et les interventions, les
chercher ou les supprimer.
Figure 5.13 – diagramme de séquence« Administrer interventions »
88
5.2.20 Diagramme de classe global du troisiéme sprint

La figure 5.14 représente le diagramme de classe globale détaillé du troisième sprint
il est composé de onze classe. avec deux classes associative intitué Role_menu et User
Role et deux classes nommé client et personnel qui hérite des données a partir de la classe
Usermanager
Figure 5.14 – Diagramme de class globale de troisiéme sprint.
5.2.21 Diagramme de classe global de l’application

La figure 5.15 représente le diagramme de classe globale de l’application qui est formé
de 13 classes avec relations OneToMany et ManyToMany entre ses classes
89
Figure 5.15 – Diagramme de class globale de l’application
5.2.22 Diagramme de cas d’utilisation global de l’application

La figure 5.16 représente le diagramme de cas d’utilisation globale de l’application, le
client a le droit de : consulter les produits, consulter les contrats, gérer les réclamations et
les interventions alors que le personnel a le droit de :gérer les menus, gérer les rôles , gérer
les utilisateurs ,gérer les entreprises ,gérer les départements ,gérer les produits ,gérer les
contrats , administrer les réclamations el les interventions
90
Chapitre 5. sprint3 : Gestion des réclamations et des5.3.
interventions
réalisation du troisième sprint
Figure 5.16 – Diagramme de class globale de l’application
5.3 réalisation du troisième sprint

dans cette partie on va représenter les interfaces de l’application concernant ce
troisième sprint
91
interventions
5.3.1 Interface« Ajouter menu Mes produits»

La figure 5.17 représente l’interface de « Ajouter Menu » pour l’ajout du menu Mes
produits. Une fois le personnel est authentifié, il peut accéder à cette interface qui lui
donne le droit d’ajouter un menu
Figure 5.17 – L’interface « Ajouter menu Mes produits»
5.3.2 L’interface de « Mes produits »

La figure 5.18 représente l’interface de « Mes produits ». Une fois le client est
authentifié, il peut accéder à cette interface. Il a le droit d’afficher ses produits avec des
détails, et de les chercher
92
interventions
Figure 5.18 – L’interface « Mes produits»
5.3.3 L’interface de « Ajouter menu Mes contrats »

La figure 5.19 représente l’interface de « Ajouter Menu » pour l’ajout du menu Mes
contrats. Une fois le personnel est authentifié, il peut accéder à cette interface
Figure 5.19 – L’interface« Ajouter menu Mes contrats »
93
interventions
5.3.4 L’interface de « Mes contrats »

La figure 5.20 représente l’interface de Mes contrats. Une fois le client est authentifié,
il peut accéder à cette interface. Il peut voir ses contrats avec détails et de faire une
recherche sur un contrat bien défini a l’aide de filtre
Figure 5.20 – L’interface« Mes contrats »
5.3.5 Interface« Ajouter menu réclamer un produit»

La figure 5.21 représente l’interface de « Ajouter Menu » pour l’ajout du menu réclamer
un produit. Une fois le personnel est authentifié, il peut accéder à cette interface .
Figure 5.21 – L’interface« Ajouter menu réclamer un produit »
94
interventions
5.3.6 L’interface de « réclamer un produit »

La figure 5.22 représente l’interface de réclamer un produit. Une fois le client est
authentifié, il peut accéder à cette interface. Il à le droit d’afficher ses réclamations, ajouter,
supprimer , et chercher une réclamation
Figure 5.22 – L’interface« réclamer un produit »
5.3.7 L’interface de intervention

la figure 5.23 représente une communication entre le client et le personnel c’est a dire
une intervention et Pv-intervention sur une réclamation qui à été généré précédemment
Figure 5.23 – L’interface de l’intervention & PV-intervention
95
5.4. Revue du troisième Sprint
5.4 Revue du troisième Sprint

conforme à ce qui a été réalisé pendant cette troisième itération, le Sprint est donc valide.
5.5 Rétrospective du troisième Sprint

Nous avons identifié les axes d’amélioration à prendre en compte pour ce Sprint en ce
qui concerne l’interface graphique.
5.6 Conclusion
Au cours de ce dernier chapitre, nous avons présenté le troisième sprint. Pour ce faire,
nous avons passé de la planification jusqu’à la revue de sprint pour arriver enfin à délivrer
le prototype attendu.
96
CONCLUSION GÉNÉRALE ET
PERSPECTIVES
De nos jours, toutes les entreprises ont un seul but qui est la satisfaction des clients.
Pour cela, notre projet de fin d’étude GRIC « Gestion Réclamation et Intervention
Client » constitue un service après-vente via lequel le client peut interagir avec
l’entreprise.
Pour parvenir à atteindre notre objectif, nous avons utilisé une méthodologie de travail
qui consiste à valoriser les individus et leurs interactions, le fonctionnement du logiciel, la
collaboration avec le client et qui constitue une bonne solution aux changements :
c’est la méthodologie Agile/Srcum.
Notre application est une application dédiée pour les clients et le personnel. Elle est
très avantageuse pour les deux. D’abord, elle facilite les taches du personnel par l’au-
tomatisation de l’historisation du traitement. Ensuite elle permet aux clients d’accéder
facilement à leurs réclamations afin de suivre le changement du statut de cette dernière.
De plus il y’a un seul personnel qui prend en charge chaque réclamation client.
Par ailleurs, la réalisation de cette application web nous a été bénéfique sur le plan
technique. En effet nous avons eu la chance d’utiliser le langage Java et de découvrir les
nouveaux outils de développement d’application Web comme les Frameworks
Spring Boot et Angular 7.
Certaines perspectives dessinent à l’horizon pour l’amélioration de ce travail par

l’intégration d’une partie statistique qui nous permet d’estimer et de définir les avis des
clients sur leurs produits et de faire les modifications nécessaires afin d’améliorer la qualité
de service.
97
WEBGRAPHIE
N1 : https ://angular.io/
N2 : https ://openclassrooms.com
N3 : https ://spring.io/
N4 : https ://stackoverflow.com/
N5 : https ://www.eclipse.org/
N6 : http ://www.adaming.tn/Fr/
N7 : https ://www.scrum.org/
N8 : https ://fr.slideshare.net/mohamedyoussfi9/mohamed-youssfi-support-architectures-
logicielles-distribues-bases-sue-les-micro-services-avec-spring-boot
Spring boot par la pratique -Développer les services Rest avec Spring-Boot et Spring-
RestTemplate
https ://books.ninja-squad.com/public/samples/Deviens_un_Ninja_avec_Angular_extrait.pdf
98
Conclusion Générale et Perspectives
Résumé Ce rapport a été réalisé dans le cadre du projet de fin d’étude pour l’obtention
de diplôme licence fondamentale en informatique et télécommunication à l’institut supé-
rieur des technologies de l’information et de télécommunication de borj cedria. L’objectif
de notre projet est de réaliser une application web dédiée principalement aux clients dont
le but est d’élaborer une communication avec l’entreprise Pour réclamer un produit. Cette
application est développée en utilisant les frameworks Spring boot et Angular 7 pour la
partie web et MySQL pour la partie base de données. Au cours de développement de notre
application de gestion des réclamations, nous avons adopté la méthode de développement
Scrum.
Mots clé : spring boot, angular 7,scrum
Abstract This report was produced as part of the end-of-study project for obtaining a
basic degree in computer science and telecommunications at the Higher Institute of Infor-
mation Technology and Telecommunications of BorjCedria. The objective of our project
is to create a web application dedicated mainly to customers whose goal is to develop
a communication with the company To claim a product. This application is developed
using the Spring boot and Angular 7 frameworks for the web part and MySQL for the
database part. Finally we adopted the Scrum development method to develop it.
Keywords :spring boot, angular 7, scrum
99

Rapport Maha

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Maha

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Maha

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur

Rapport de stage de fin d’étude

Système de Gestion des Reclamations et des

au sein de groupe Adaming

Encadrant académique : Mme Maha Sliti

Année Universitaire : 2018-2019

Autorisation de dépot du rapport de Projet de Fin d’Etudes :

Autorisation de dépot du rapport de Projet de Fin d’Etudes :

Mes remerciements s’adressent en premier lieu vers Dieu le tout puissant.

A mes chers parents Hedi et Madiha, que ce travail soit le symbole de

A mes professeurs, ce travail est le fruit de vos efforts.

A mes amis, je vous remercie pour vos encouragements.

Avec les vrais mots d’amour et de respect je dédie ce travail :

Nous adressons nos sincères remerciements à nos encadreurs :

Mm. Maha Sliti

— JSON = JavaScript Object Notation

— PFE = Projet Fin d’Etude

— RUP = Rational Unified Process

— UML = Unified Modeling Language

— XML = Extensible Markup Language

— GRIC : Gestion Réclamation et Intervention Client

2 Sprint 0 :Analyse et spécification des besoins 10

3 Sprint 1 :Gestion Des Menues et des Utilisateurs 34

4 sprint 2 la Gestion des contrats et des produits 51

4.2.7 Diagramme de séquence du sous cas d’utilisation «Gérer les dépar-

5 sprint3 : Gestion des réclamations et des interventions 74

5.2.14 Raffinement du sous cas d’utilisation "Administrer

Conclusion Générale et Perspectives 97

1.1 Méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 l’équipe scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 Diagramme de cas d’utilisation du Sprint 1 . . . . . . . . . . . . . . . . . . 36

3.16 : Page «Dashboard» pour le client . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Diagramme de cas d’utilisation du Sprint 2 . . . . . . . . . . . . . . . . . 54

5.1 Diagramme du cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . 76

1.1 Tableau comparatif des méthodologies agiles . . . . . . . . . . . . . . . . . 6

2.1 le backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Backlog Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1 Backlog Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Backlog Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Au cours du dernier siècle on a assisté à une grande avancée technologique dans le

Dans ce contexte de concurrence, la qualité des services offerts et la satisfaction des

Le présent rapport est réparti en cinq chapitres :

Dans le premier chapitre « Présentation générale » , nous présentons le cadre de notre

Dans le deuxième chapitre intitulé «Analyse et Specification de besoin», nous définis-

Dans le reste du rapport (troisième, quatrième, cinquième chapitre), nous déployons

1.1 Présentation de l’organisme d’accueil

Aujourd’hui, le groupe est engagé auprès d’une trentaine d’entreprises prestigieuses,

A travers ses différentes entités spécialisées, ils proposent à leurs clients un

-Des prestations personnalisées : Audit, Conseil, Développement Assistance...

-Mainframe : MVS, COBOL, PACBASE, CICS, DB2.

1.2 Domaine d’activités de la société

1.2.2 Activités des conseils

La pluralité des domaines de compétences de ses Consultants, Directeurs de projets,

-Audit du système d’information

-Assistance dans la définition des objectifs et stratégies,

-Schémas directeurs, études de faisabilité du projet,

-Elaboration du cahier des charges,

-Aide au choix d’architectures et d’outils