Table des matières

Table des figures vii

Liste des tableaux x

Introduction générale 1

1 PRESENTATION DU CADRE DU PROJET 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Cadre du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Activité et service . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Classification de méthodologie de conduite de projets . . . . . . . . 6
1.4.2 Méthodes agiles vs. Classiques . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Choix de la méthodologie de conception . . . . . . . . . . . . . . . 8
[Link] Comparaison entre SCRUM, XP et DSDM . . . . . . . . . 8
[Link] Choix de la méthodologie : SCRUM . . . . . . . . . . . . 9
1.4.4 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
[Link] Les bases de SCRUM . . . . . . . . . . . . . . . . . . . . 9
[Link] Les ateurs dans SCRUM . . . . . . . . . . . . . . . . . . . 9
[Link] Terminologie Scrum . . . . . . . . . . . . . . . . . . . . . 10
[Link] Processus SCRUM . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Processus de modélisation . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Langage de Modélisation Unifié : UML . . . . . . . . . . . . . . . . 12
1.6 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 12
1.6.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 12

iii
 TABLE DES MATIÈRES

1.6.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 14

[Link] Outil de conception . . . . . . . . . . . . . . . . . . . . . 14
[Link] Outil de rédaction du rapport . . . . . . . . . . . . . . . . 14
[Link] Technologies utilisées et Langages de développement . . . 15
1.7 Architecture logicielle du projet . . . . . . . . . . . . . . . . . . . . . . . . 20
1.7.1 Architecture 3-tiers : . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.7.2 Modèle de conception (Design pattern) : . . . . . . . . . . . . . . . 21
[Link] Modèle de conception Backend (MVC) : . . . . . . . . . . 21
[Link] Modèle de conception Frontend (MVVM) : . . . . . . . . . 22
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Sprint 0 : Analyse et Spécification des Besoins 23

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1 Capture de besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . 25
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . 25
2.2 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 26
2.4 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Sprint 1 30
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . 31
3.1.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Analyse du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 34
[Link] Cas d’utilisation ≪ S’authentifier ≫ . . . . . . . . . . . . . 35
[Link] Cas d’utilisation ≪ Gérer les utilisateurs ≫ . . . . . . . . . 36
[Link] Cas d’utilisation ≪ Gérer les contrats ≫ . . . . . . . . . . . 38
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . . . . 40
[Link] Cas d’utilisation ≪ S’authentifier ≫ . . . . . . . . . . . . . 40
[Link] Cas d’utilisation ≪ Ajouter utilisateur ≫ . . . . . . . . . . 41
[Link] Cas d’utilisation ≪ Consulter utilisateur ≫ . . . . . . . . . 43
[Link] Cas d’utilisation ≪ Supprimer utilisateur ≫ . . . . . . . . . 43
3.3.2 Diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . . . 44

page iv
 TABLE DES MATIÈRES

[Link] Cas d’utilisation ≪ S’authentifier ≫ . . . . . . . . . . . . . 44

[Link] Cas d’utilisation ≪ Ajouter utilisateur ≫ . . . . . . . . . . 46
[Link] Cas d’utilisation ≪ Supprimer utilisateur ≫ . . . . . . . . . 47
3.3.3 Diagramme du classe du Sprint 1 . . . . . . . . . . . . . . . . . . . 48
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 Sprint 2 52
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Spécification des besoins du sprint 2 . . . . . . . . . . . . . . . . . . . . . . 53
4.1.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . 53
4.1.2 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 55
[Link] Cas d’utilisation ≪ Gérer facture ≫ . . . . . . . . . . . . . 55
[Link] Cas d’utilisation ≪ traiter les réclamations ≫ . . . . . . . . 58
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . . . . 59
[Link] Cas d’utilisation ≪ Ajouter une facture ≫ . . . . . . . . . . 59
[Link] Cas d’utilisation ≪ Consulter facture ≫ . . . . . . . . . . . 61
[Link] Cas d’utilisation ≪ Supprimer une facture ≫ . . . . . . . . 62
[Link] Cas d’utilisation ≪ traiter les reclamation ≫ . . . . . . . . 63
[Link] Cas d’utilisation ≪ traiter les reclamation ≫ . . . . . . . . 63
4.3.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . 65
[Link] Cas d’utilisation ≪ ajouter facture ≫ . . . . . . . . . . . . 65
4.3.3 Diagramme de Classe du Sprint 2 . . . . . . . . . . . . . . . . . . . 66
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Sprint 3 70
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1 Spécification des besoins du sprint 3 . . . . . . . . . . . . . . . . . . . . . . 71
5.1.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.2 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . 71
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . . . . 72
[Link] Ca d’utilisation ≪ consulter son compte ≫ . . . . . . . . . 73
[Link] Cas d’utilisation ≪ gérer les réclamations ≫ . . . . . . . . . 74

page v
 TABLE DES MATIÈRES

5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . . . . 75
[Link] Cas d’utilisation ≪ consulter compte ≫ . . . . . . . . . . . 75
[Link] Cas d’utilisation ≪ consulter compte ≫ . . . . . . . . . . . 75
[Link] Cas d’utilisation ≪ gérer reclamation ≫ . . . . . . . . . . . 76
[Link] Cas d’utilisation ≪ gérer reclamation ≫ . . . . . . . . . . . 77
5.3.2 Diagramme de Classe du Sprint 3 . . . . . . . . . . . . . . . . . . . 79
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Conclusion et perspectives 83

Bibliographie 84

page vi
Table des figures

1.1 Comparaison entre les méthodes Agiles vs les méthodes Classiques. . . . . 7

1.2 Processus Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Caractéristiques de l’ordinateur . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Logo de StarUml. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Logo de Overleaf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Logo de Symfony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Logo de NodeJs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.9 Logo de composer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.10 Logo de php. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.11 Logo de HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.12 Logo de CSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.13 Logo de Bootstrap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.14 Logo de XAMPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.15 Logo de visual Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.16 Logo de SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.17 Logo de Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.18 Logo de json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.19 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.20 Design Pattern MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.21 Design Pattern MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 Diagramme de cas d’utilisation global. . . . . . . . . . . . . . . . . . . . . 27

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . . . . . . . . 31

3.2 Diagramme de cas d’utilisation ≪ S’authentifier ≫. . . . . . . . . . . . . . . 35
3.3 Diagramme de cas d’utilisation ”Gérer les utilisateurs ”. . . . . . . . . . . 36
3.4 Diagramme de cas d’utilisation ≪ Gérer les contrats ≫. . . . . . . . . . . . . 38
3.5 Diagramme de séquences détaillé du cas d’utilisation ≪ S’authentifier ≫. . . 41

vii
 TABLE DES FIGURES

3.6 Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Ajouter utili-

sateur ≫. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Consulter uti-
lisateur ≫. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8 Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Supprimer uti-
lisateur ≫. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Diagramme d’activité du cas d’utilisation ≪ S’authentifier ≫. . . . . . . . . 45
3.10 Diagramme d’activité du sous-cas d’utilisation ≪ Ajouter direction ≫. . . . 46
3.11 Diagramme d’activité du sous-cas d’utilisation ≪ Supprimer direction ≫. . . 47
3.12 Diagramme Global du classe du Sprint 1 . . . . . . . . . . . . . . . . . . . 48
3.13 Interface : Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.14 Interface : dashboard administration . . . . . . . . . . . . . . . . . . . . . 49
3.15 Interface : consulter contrat . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.16 Interface :ajouter contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.17 Interface : liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Diagramme de cas d’utilisation du sprint 2. . . . . . . . . . . . . . . . . . . 53

4.2 Diagramme de cas d’utilisation ≪ Gérer facture ≫. . . . . . . . . . . . . . . 55
4.3 Diagramme de cas d’utilisation ”Gérer tickets”. . . . . . . . . . . . . . . . 58
4.4 Diagramme de séquences détaillés du sous cas d’utilisation ≪ Ajouter facture ≫ 60
4.5 Diagramme de séquences détaillés du sous cas d’utilisation ≪ Consulter
facture ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Diagramme de séquences détaillés du sous cas d’utilisation ≪ Supprimer
une facture ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Diagramme de séquences détaillés du sous cas d’utilisation ≪ Consulter
reclamation ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 Diagramme de séquences détaillés du sous cas d’utilisation ≪ supprimer
reclamation ≫ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.9 Diagramme d’activité du sous cas d’utilisation ≪ ajouter une facture ≫ . . . 65
4.10 Diagramme de classe du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . 66
4.11 Interface : Consulter une facture . . . . . . . . . . . . . . . . . . . . . . . . 67
4.12 Interface : consulter liste de factures . . . . . . . . . . . . . . . . . . . . . . 67
4.13 Interface : dashboard technicien . . . . . . . . . . . . . . . . . . . . . . . . 68
4.14 Interface :supprimer reclamation . . . . . . . . . . . . . . . . . . . . . . . . 68
4.15 Interface : Consulter reclamation . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Diagramme de cas d’utilisation du sprint 3. . . . . . . . . . . . . . . . . . . 72

5.2 Diagramme de cas d’utilisation ≪ consulter son compte ≫. . . . . . . . . . . 73
5.3 Diagramme de cas d’utilisation ≪ gérer les réclamations ≫ . . . . . . . . . . 74
5.4 Diagramme de séquences détaillés du cas d’utilisation ≪ Consulter compte ≫ 75

page viii
 TABLE DES FIGURES

5.5 Diagramme de séquences détaillés du cas d’utilisation ≪ consulter compte ≫ 76

5.6 Diagramme de séquences détaillés du cas d’utilisation ≪ gérer reclamation ≫. 77
5.7 Diagramme de séquences détaillés du cas d’utilisation ≪ gérer reclamation ≫. 78
5.8 Diagramme de classe du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . 79
5.9 Interface :dashboard client . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.10 Interface :suivi reclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.11 Interface : Refuser ticket en attente . . . . . . . . . . . . . . . . . . . . . . 81
5.12 Interface :suivi l’etat de facture . . . . . . . . . . . . . . . . . . . . . . . . 81
5.13 Interface :suivi contrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

page ix
Liste des tableaux

1.1 Table comparative des méthodes agiles Scrum, XP et DSDM [HI12] . . . . 8

2.1 Table des acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Le backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Le Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Description textuelle du cas d’utilisation ≪ S’authentifier ≫ . . . . . . . . . 35
3.3 Description textuelle du sous cas d’utilisation ≪ Ajouter utilisateur ≫ . . . 36
3.4 Description textuelle du sous cas d’utilisation ≪ Consulter utilisateur ≫ . . 36
3.5 Description textuelle du sous cas d’utilisation ≪ modifie utilisateur ≫ . . . 37
3.6 Description textuelle du sous cas d’utilisation ≪ Supprimer utilisateur ≫ . . 37
3.7 Description textuelle du sous cas d’utilisation ≪ afficher utilisateur ≫ . . . . 38
3.8 Description textuelle du sous cas d’utilisation ≪ Ajouter contrat ≫ . . . . . 38
3.9 Description textuelle du sous cas d’utilisation ≪ Consulter contrat ≫ . . . . 39
3.10 Description textuelle du sous cas d’utilisation ≪ modifier contrat ≫ . . . . . 39
3.11 Description textuelle du sous cas d’utilisation ≪ Supprimer contrat ≫ . . . . 39
3.12 Description textuelle du sous cas d’utilisation ≪ afficher contrat ≫ . . . . . 40
3.13 Table des acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.14 Tests de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 Le Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Description textuelle du sous cas d’utilisation ≪ Ajouter facture ≫ . . . . . 56
4.3 Description textuelle du sous cas d’utilisation ≪ Consulter facture ≫ . . . . 56
4.4 Description textuelle du sous cas d’utilisation ≪ Supprimer facture ≫ . . . . 56
4.5 Description textuelle du sous-cas d’utilisation ≪ afficher un factur ≫ . . . . 57
4.6 Description textuelle du sous-cas d’utilisation ≪ Modifier facture ≫ . . . . . 57
4.7 Description textuelle du sous cas d’utilisation ≪ modifier reclamation ≫ . . 58
4.8 Description textuelle du sous cas d’utilisation ≪ Consulter reclamation ≫ . 59
4.9 Description textuelle du sous cas d’utilisation ≪ Supprimer reclamation ≫ . 59
4.10 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Le Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

x
 LISTE DES TABLEAUX

5.2 Description textuelle du sous cas d’utilisation ≪ suivi compte ≫ . . . . . . . 73

5.3 Description textuelle du sous cas d’utilisation ≪ suivi reclamation ≫ . . . . 74
5.4 Description textuelle du sous cas d’utilisation ≪ Ajouter réclamation ≫ . . . 74
5.5 Liste des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

page 1
Introduction générale

Le monde change constamment et l’importance de l’informatique augmente dans

presque tous les domaines de la vie. Son concept est extrêmement important et mul-
tidimensionnel. Les défis actuels et futurs et le développement rapide du marché obligent
les entreprises à se doter des moyens technologiques les plus avancés afin de gérer le flux
d’informations de manière à être actualisées et compétitives.

Le stage du PFE nous a donné l’opportunité d’avoir un contact direct avec le monde
professionel afin de consolider notre pratique.

Notre projet consiste à concevoir et développer une application web appelée ≪PRO-
GRESS ENGINEERING≫, qui permettra de gérer l’ensemble des contrats de support de
maintenance enregistrés par l’entreprise, ainsi que les informations liées aux clients, aux
factures et aux prestations de support. Elle permettra également d’assurer le suivi des
contrats en cours ,de générer des rapports d’activité pour l’ensemble des contrats gérés,de
faciliter la gestion des contrats de support de maintenance pour l’entreprise en offrant
une interface utilisateur simple et intuitive pour l’enregistrement , la mise à jour et la
consultation des contrats .

Notre projet s’organise comme suit :

• Le premier chapitre : est réservé au cadre général du projet, l’organisme d’accueil,
la critique de l’existant, la solution proposée et le choix méthodologique et conceptuel
et l’environnement pour la réalisation du projet.

• Le deuxième chapitre : concerne la planification et l’architecture : Dans ce

chapitre, nous allons définir la méthodologie de gestion de projet, le contexte du
système, déterminer les besoins fonctionnels, les besoins non fonctionnels, le Back-
log du produit, planifier les sprints et enfin donner le diagramme de cas d’utilisation
global ainsi que le diagramme de classes.

• Le troisième chapitre : présente la réalisation du Sprint 1 après l’avoir analysé

et détaillé.
• Le quatrième chapitre : présente la réalisation du Sprint 2 après l’avoir analysé

1
 et détaillé.
• Le cinquième chapitre : présente la réalisation du Sprint 3 après l’avoir analysé
et détaillé.
A l’issue de ce travail, les perspectives d’amélioration de la vision et de développement
de cette application seront discutées en guise de conclusion.
Chapitre 1

PRESENTATION DU CADRE DU
PROJET

Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Cadre du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . 4
1.2.1 Activité et service . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Classification de méthodologie de conduite de projets . . . . . 6
1.4.2 Méthodes agiles vs. Classiques . . . . . . . . . . . . . . . . . . 6
1.4.3 Choix de la méthodologie de conception . . . . . . . . . . . . . 8
1.4.4 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Processus de modélisation . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Langage de Modélisation Unifié : UML . . . . . . . . . . . . . . 12
1.6 Environnement de développement . . . . . . . . . . . . . . . 12
1.6.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . 12
1.6.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Architecture logicielle du projet . . . . . . . . . . . . . . . . . 20
1.7.1 Architecture 3-tiers : . . . . . . . . . . . . . . . . . . . . . . . . 20
1.7.2 Modèle de conception (Design pattern) : . . . . . . . . . . . . . 21
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

Introduction
Dans ce chapitre, nous commençons par présenter l’organisme d’accueil de notre projet.
Ensuite, nous décrivons l’étude de l’existant ainsi que ses limites afin de déduire la solution
Proposée. A la fin de ce chapitre, nous exposons la méthodologie qui a conduit à la
réalisation de notre projet.

1.1 Cadre du Projet

Ce stage s’inscrit dans la cadre de la validation de notre projet de fin d’étude en vue de
l’obtention du diplôme de licence en informatique appliquée a la gestion (LIAG) spécialité
Business Information System (BIS) à la Faculté des Sciences Juridiques Economiques et
de Gestion de Jendouba (FSJEGJ). Pendant ce stage, nous sommes appelés à réaliser
un projet mettant l’accent sur nos connaissances, nos capacités techniques et pratiques
acquises pendant notre formation académique.
Nous sommes alors accueillis au sein de lA sociéte de PROGRESS ENGINEERING
pour une durée de 4 mois.

1.2 Présentation de l’organisme d’accueil

Progress Engineering est une société de services informatiques spécialisée dans l’étude,
le conseil et le développement informatique. Crée en 2000 par trois ingénieurs, la société a
acquis un savoir-faire, des compétences et de l’expérience lui permettant de mener à bien
tout projet informatique avec tous ses aspects (spécification, conception, développement,
test, validation, déploiement, assistance et maintenance). Grâce à sa politique de crois-
sance étudiée, Progress Engineering a su maintenir sa position d’acteur majeur dans le
secteur des SSII en Tunisie.

1.2.1 Activité et service

Les activités et les services offerts par la société Progress Engineering sont :
• Formation professionnelle ,
• Création des services et produits informatiques et multimédias,
• Recherche scientifique ,
• Accompagnement de projet et conseils ,
Et durant les quatre mois précédents j’ai effectué mon stage au service d’accompa-
gnement de projet et conseils.

page 4
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

1.3 Analyse de l’existant

L’analyse de l’existant est une étape importante pour bien comprendre le système
actuel. Elle a pour objectif de dégager les lacunes du système existant et de proposer les
solutions adéquates et définir les objectifs à atteindre au titre de perfectionnement.

1.3.1 Description de l’existant

Le projet de conception et développement d’une application web de gestion des contrats
du support de maintenance vise a simplifier et automatiser le processus de gestion des
contrats lies au support de maintenance d’une entreprise.
À l’heure actuelle, l’entreprise utilise une méthode traditionnelle de gestion des contrats.
En effet, un responsable administratif est charge de remplir manuellement le contrat,
puis de l’envoyer au client. le client a la possibilité d’effectuer et de suivre sa réclamation
soit par email, soit par téléphone
L’application web sera conçue pour être conviviale et intuitive, offrant une interface
utilisateur attrayante et facile a naviguer.

1.3.2 Critique de l’existant

L’étude de l’existant nous a permis de dégager les points faibles détaillés ci dessous :
• L’intervention manuelle cause une lenteur du déroulement des tâches ainsi que le
risque de la non fiabilité ;
• Les tâches à effectuer nécessitent beaucoup d’attention et de temps pour une vérification
manuelle et régulière ;
• La redondance des tâches ;
• Le risque d’oubli de traitemement ou de perte de la demande ;
• Le manque de suivi : inexistence de système permettant au demandeur de suivre
l’état de sa demande.
• Il y a un problème de communication dû à l’absence d’une interface client infor-
matisée qui gère le traitement et le suivi d’une demande dès sa création jusqu’à
son traitement. Cela nécessite souvent des rencontres physiques, des demandes par
téléphones ou par e-mail. Le suivi de la progression des travaux est aussi un point
faible dans le processus actuel, car il n’y a pas un outil informatique centralisé.

1.3.3 Solution proposée

Pour remédier aux difficultés présentées dans la section précédente, j’ai proposé au
responsable de mon stage au PROGRESS ENGINEERING de concevoir et mettre en place

page 5
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

une application web multi-utilisateurs permettant d’automatiser la gestion des contrats

de support de maintenance,de gérer les périodes de garantie relatifs à chaque marché .
Cette application sera utilisée par tout les employés et les clients de la societe.
L’objectif principal de l’application est la mise en place d’un système fiable capable
d’effectuer la gestion des contrats de support de maintenance . Le futur système doit :
• Améliorer considérablement la qualité des services offerts ;
• Garantir une transparence opérationnelle ;
• Permettre de gagner le temps, limiter les efforts, diminuer la perte d’informations ;
• Faciliter le suivi des contrat pour les clients .

1.4 Méthodologie adoptée

Pour pouvoir choisir la bonne méthodologie, il faut avoir une idée sur les avantages
et les inconvénients de quelques unes afin de pouvoir choisir celle qui convient mieux à
mon projet. Dans ce qui suit, je présenterai un aperçu sur les différentes méthodologies
utilisées.

1.4.1 Classification de méthodologie de conduite de projets

Les méthodologies de conduite de projets aident à accomplir chaque étape d’un pro-
jet, de la planification à la mise en oeuvre, dans un souci d’efficacité et rentabilité. Ces
méthodologies sont réparties en deux grandes familles :

• Les méthodes traditionnelles :

Dites aussi méthodes classiques. Une succession de phases qui se déverse les unes
dans les autres. Une phase de l’approche classique ne peut commencer tant que la
précédente n’est pas terminée. Alors, le plan du projet se fait étape par étape.
• Les méthodes Agiles :
Plus efficaces et moins rigides que les méthodes classiques. Ces dernières placent
les besoins du client au centre des priorités du projet. Une méthode Agile est une
approche itérative et collaborative, capable de prendre en compte les besoins initiaux
du client et ceux liés aux évolutions.

1.4.2 Méthodes agiles vs. Classiques

Lorsqu’on démarre un projet, il est normal de se questionner sur l’organisation que
l’on va adopter pour sa mise en place et sa réalisation. Combien de réunions ? Quel rôle va
jouer chaque personne de l’équipe ? Comment faire pour éviter de recommencer le travail

page 6
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

depuis le début si le client change d’avis ? Depuis quelque temps, on entend parler de
la méthode Agile, ou encore Scrum (la méthodologie Agile la plus utilisée). Mais cette
méthode de gestion de projet n’est pas la plus facile à comprendre, et la plupart des sites
internet qui proposent une explication se perdent souvent dans des explications textuelles
longues dont on décroche facilement.
Pour simplifier cela, la figure ci-après [Guy18]est un schéma explicatif du processus de
la méthodologie Agile, comparé au processus de la méthodologie Classique de gestion de
projet .

Figure 1.1 – Comparaison entre les méthodes Agiles vs les méthodes Classiques.

On privilégiera plutôt la méthode classique lorsqu’on a une idée précise du projet,

avec un planning bien détaillé et où on a anticipé tous les risques possibles, quant à la
méthode Agile, on la choisira plutôt pour les gros projets, celle-ci permettant une meilleure
adaptabilité, visibilité et gestion des risques. On privilégiera également la méthode Agile
pour les projets où il n’y a pas de documents détaillés, ou quand vous sentez que votre
client est indécis. Le client pourra alors voir l’évolution du projet et l’adapter à ses besoins
sans pour autant vous obliger à recommencer tout le travail que vous avez fourni depuis
le début [Guy18].
Les méthodes agiles répondent aux méthodes classiques, trop prédictives et trop ri-
gides, en exposant de nouveaux principes plus souples dont l’anticipation, l’auto-régulation,

page 7
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

le feedback et la collaboration. Elles renforcent aussi la capacité d’une organisation ≪ ap-

prenante ≫ au changement et à la transformation [CS16].
Le mouvement Agile est en effet né en réponse à l’échec des paradigmes dominants de
gestion de projets et de développement logiciels (y compris la méthodologie en cascade).

1.4.3 Choix de la méthodologie de conception

[Link] Comparaison entre SCRUM, XP et DSDM

Après la sélection de la méthodologie Agile comme étant la méthodologie de conduite

du projet, je doit choisir l’une de ces populaires méthodes pour mon projet. Pour cela, je
vais procéder à la comparaison de trois méthodes agiles : SCRUM, XP et DSDM [HI12].
La table ci-après décrit le principe de chacune de ces méthodes ainsi que ses points
forts et ses points faibles.

Table 1.1 – Table comparative des méthodes agiles Scrum, XP et DSDM [HI12]

Méthode Points Forts Points Faibles

• Personnels engagés
• Meilleure vue de l’ensemble du projet
• Peu de place pour les étapes
• Courtes itérations
postérieures ainsi que les étapes
• Amélioration de la communication
SCRUM antérieures.
• Augmentation de la productivité
• Faible documentation et donc
• Réduction des bugs
facile à détourner.
• Mise à jour des priorités
• Qualité du produit mise en avant
• Une forte réactivité au changement
• Méthodologie déroulante.
des besoins du client.
• Petits et moyens projets
• Un travail d’équipe.
XP seulement.
• Un code de qualité.
• Nécessité une forte implication
• Une efficacité importante.
du client
• Un coût de modification linéaire.
• Une gestion de projet efficace et un
• Client relégué au 2nd plan.
contrôle solide sur le cycle de vie du projet
DSDM • La documentation est complexe.
• Exigences en matière d’approche
• Consomme beaucoup de temps.
prioritaire utiles à assurer en premier.

L’analyse de la table précédente, me conduit à éliminer la méthode DSDM car le client

n’est pas impliqué au premier plan, sa documentation est complexe et sa maintenance
est difficile. En plus, j’élimine la méthode XP qui, néglige l’étude fonctionnelle et la
capture des besoins fonctionnels et techniques. Par voie de conséquence, je vais opter
pour la méthode agile Scrum pour plusieurs raisons. Sa principale caractéristique consiste
à valoriser les individus et leurs interactions, le fonctionnement du logiciel, la collaboration

page 8
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

avec les clients d’où elle constitue une bonne solution tenant compte du processus, de la
documentation complète, de la négociation des contrats et des plans préétablis.

[Link] Choix de la méthodologie : SCRUM

Mon projet suivra le processus de développement agile SCRUM (processus de mêlée)

vu qu’elle présente la méthodologie la plus appropriée à ma démarche projet. Elle fournit
un ensemble de pratiques de base qui laissent volontairement le choix libre des techniques
de développement. Dans ce qui suit, je cite quelques avantages offerts par la méthodologie
SCRUM [CS16] :
• Une flexibilité : Je priorise moi-même les exigences selon les besoins de mon orga-
nisation et les circonstances changeantes.
• Une mise à jour des tâches et des priorités : le client bénéficie d’une flexibilité au
niveau de la définition, de l’évolution des fonctionnalités et des séquences d’activités.
• Une idée claire de l’état du projet : je peux consulter l’avancement du projet, évaluer
éventuellement les obstacles rencontrés et suivre les tâches de différentes équipes.
• Une planification correcte : une planification détaillée à court terme et une planifi-
cation globale à long terme.

1.4.4 Scrum
[Link] Les bases de SCRUM

La méthodologie SCRUM est basée sur 3 principes qui sont au même temps les prin-
cipes de la culture agile qui sont [Aub11] :

• Transparence : Scrum met l’accent sur le fait d’avoir un langage commun.

• Inspection : À intervalle régulier, Scrum propose de faire le point sur les différents
artéfacts produits, afin de détecter toute variation indésirable.
• Adaptation : Si une dérive est constatée pendant l’inspection, le processus doit
alors être adapté.

[Link] Les ateurs dans SCRUM

Scrum définit 3 rôles [Aub11] :

• Le Product owner : C’est le maı̂tre d’ouvrage, également le propriétaire du pro-

duit il est responsable de maximiser le travail de l’équipe. Il est le seul de gèrent
du carnet du produit il définit les exigences que doit satisfaire le produit, ajuste et
règle les fonctionnalités du produit au cours de chaque itération. C’est lui également
qui donne l’ordre d’approbation ou les refus de travail présenté.

page 9
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

• L’équipe de développement : Celle-ci est responsable de transformer les besoins

exprimés dans le Product Backlog par le Product owner en fonctionnalités concrètes
et utilisables. Elle doit livrer un incrément, une version du logiciel, à la fin de chaque
sprint. L’équipe de développement est auto – organisée. Nulle personne ne peut lui
indiquer comment transformer les histoires du Product backlog. On dit qu’elle est
autonome. Elle est pluridisciplinaire car elle peut contenir d’autres rôles tels que
développeur, concepteur, designer.
• Le Scrum master : Le scrum master doit maitriser SCRUM dans son intégralité.
Il doit s’assurer que la méthode scrum doit être mise en œuvre correctement, que la
démarche de l’équipe de développement s’adapte selon les pratiques de la méthode,
généralement il est confondu avec le chef du projet. Il a comme mission de :

— Diriger et aider les membres de l’équipe ;

— Gérer efficacement le carnet du produit, afin qu’il soit concis et clair pour
l’équipe ;
— Aider l’équipe à éliminer les obstacles à son progrès ;
— S’assurer que l’équipe est productive.

[Link] Terminologie Scrum

Dans Scrum, nous utilisons la terminologie suivante [CS16] :

• Daily Scrum (ou mêlée quotidienne) : moment de partage, courte ≪ cérémonie
≫ ou réunion (environ 15 minutes) menée chaque jour avec les membres de l’équipe

et le product owner pour informer sur l’activité de tous, déterminer les tâches de la
journée et identifier les obstacles empêchant l’équipe d’atteindre l’objectif du sprint.
• Product Backlog (ou produit backlog) : liste priorisée des fonctionnalités du
produit, soit une liste partagée des choses à faire. Rétrospective : ≪ cérémonie ≫ à
l’issue de chaque sprint dont l’objectif est de discuter, en présence du Scum master
et du product owner, des axes d’amélioration de l’équipe. Moment capital qui in-
carne l’un des principes fondamentaux énoncés par le Manifeste agile : à intervalles
réguliers, l’équipe réfléchit sur la manière de préparer le futur et d’accroı̂tre son
efficacité, puis adapte et ajuste son comportement en conséquence.
• Sprint Backlog : liste des fonctionnalités à réaliser lors d’un sprint. La liste des
tâches correspondantes est établie lors d’un sprint planning. La charge des tâches
est déterminée par les développeurs.
• Sprint Planning (ou planification) : il réunit l’équipe et le product owner pour
déterminer l’objectif et le contenu du sprint à venir. Les user stories sont découpées
en tâches faisant chacune l’objet d’une estimation des charges, exprimée en heures
ou en jours, par l’équipe. Le principal résultat est le sprint backlog.

page 10
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

• Sprint Review (ou revue de sprint) : elle consiste pour l’essentiel, au terme de
chaque cycle, à faire une démonstration publique du résultat du sprint, à collecter
le feedback des parties prenantes et à prendre des décisions. User Story : élément
du backlog. Une exigence du système à développer, une brève description d’une
fonctionnalité telle que vue par l’utilisateur (client). Vision produit (ou vision) :
décrivant les principaux objectifs, jalons, utilisateurs visés et rédigée par le Product
Owner, elle contribue à guider et à fédérer les acteurs du projet.

[Link] Processus SCRUM

La Figure ci-après présente le fonctionnement général de la méthode Scrum.

Figure 1.2 – Processus Scrum

L’examen de la Figure 1.4 me permet de conclure que :

• Scrum est basé sur des itérations (périodes courtes de développement dont les ob-
jectifs sont définis à l’avance) appelées sprints.
• Les objectifs font partis d’un référentiel d’exigences appelé le product backlog qui
est et tenu à jour par le product owner (“Correspondant métier”).
• Ce référentiel est composé de fonctionnalités constamment priorisées. Avant chaque
sprint, les fonctionnalités les plus prioritaires passent dans le sprint backlog et de-
viennent donc les objectifs à réaliser durant le sprint (itération).
• Un sprint démarre toujours par sa planification en partant de discussions entre le
product owner et l’équipe concernant le product backlog. A l’issue de cette rencontre,
des tâches sont définies et le sprint peut débuter.

page 11
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

• L’équipe de développement est piloté par le Scrum Master qui a pour but de résoudre
les obstacles, participer au développement en cas de besoin et tout mettre en oeuvre
pour que les objectifs soient réalisés durant le sprint.
• Chaque sprint améliore la valeur ajoutée du produit en ajoutant de nouvelles fonc-
tionnalités qui peuvent être livrées au client.

1.5 Langage de modélisation

1.5.1 Processus de modélisation
Le processus de modélisation vise à obtenir une solution acceptable du système infor-
matique. La solution finalement retenue n’est pas obtenue en une seule itération. Plusieurs
étapes sont nécessaires ; ces étapes successives permettent de raffiner le niveau de détails
du système à réaliser. Les premières étapes donnent une vision à très gros grains et per-
mettent d’avancer dans la compréhension du problème [MG00].

1.5.2 Langage de Modélisation Unifié : UML

UML est un langage de modélisation unifié basé sur des notations graphiques. Il est
destiné à l’architecture, la conception et la mise en œuvre de systèmes logiciels complexes
par leur structure aussi bien que leur comportement [MG00].

Figure 1.3 – Langage UML

1.6 Environnement de développement

1.6.1 Environnement matériel
Pour le développement de notre application nous avons principalement utilisé un or-
dinateur acer ayant les caractéristiques suivantes :

— Processus : 1,70GHz Intel(R) Core(TM)i3-4005u CPU

— Mémoire : 4 Go
— Stockage : 464 Go

page 12
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

— Système d’exploitation : Windows 10

Figure 1.4 – Caractéristiques de l’ordinateur

page 13
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

1.6.2 Environnement logiciel

Dans cette partie, je vais présenter l’environnement logiciel de mon projet de point de
vue Technologies, Langages, Frameworks, Logiciels et Services.

[Link] Outil de conception

StarUml
C’est un logiciel de modélisation UML (Unified Modeling Language) open source qui
peut remplacer dans bien des situations des logiciels commerciaux et coûteux comme
Rational Rose1 ou Together2.

Figure 1.5 – Logo de StarUml.

[Link] Outil de rédaction du rapport

Overleaf
C’est une plateforme en ligne gratuite permettant d’éditer du texte en LATEX sans
aucun téléchargement d’application. En outre, elle offre la possibilité de rédiger des do-
cuments de manière collaborative, de proposer ses documents directement à différents
éditeurs (IEEE Journal, Springer, etc.) ou plateformes d’archives ouvertes (arXiv, en-
grxiv, etc.) pour une éventuelle publication.
Cette plateforme est très compatible avec différents supports tels que tablettes et
smartphones [Bas16].

Figure 1.6 – Logo de Overleaf.

page 14
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

[Link] Technologies utilisées et Langages de développement

Symfony
Symfony est un ensemble de composants PHP ainsi qu’un framework MVC libre écrit
en PHP. Il fournit des fonctionnalités modulables et adaptables qui permettent de faciliter
et d’accélérer le développement d’un site web

Figure 1.7 – Logo de Symfony

NodeJs
C’est un environnement d’exécution JavaScript open source et multiplateforme. C’est
un outil populaire pour presque tous les types de projets ! [Link] exécute le moteur
JavaScript V8, le cœur de Google Chrome, en dehors du navigateur. Cela permet à [Link]
d’être très performant

Figure 1.8 – Logo de NodeJs

Composer
C’est un gestionnaire de dépendances au niveau de l’application pour le langage de
programmation PHP qui fournit un format standard pour la gestion des dépendances du
logiciel PHP et des bibliothèques requises

page 15
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

Figure 1.9 – Logo de composer.

PHP
est un langage de scripts généraliste et Open Source, spécialement conçu pour le
développement d’applications web. Il peut être intégré facilement au HTML

Figure 1.10 – Logo de php.

page 16
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

HTML
Le langage de balisage hypertexte, HTML, est un type de langage informatique des-
criptif. Plus précisément, c’est un format de données utilisé dans le monde de l’Internet
pour la mise en forme des pages Web. [RLJ+99].

Figure 1.11 – Logo de HTML.

CSS
Les feuilles de style en cascade (CSS) sont un langage de feuille de style utilisé pour
décrire la présentation d’un document écrit dans un langage de balisage tel que le HTML.
[Mey06].

Figure 1.12 – Logo de CSS.

Bootstrap
C’est un ensemble d’outils utiles à la création du design d’applications et de sites et
web. C’est une collection qui contient des codes CSS et HTML, des outils de navigation,
boutons, formulaires, et autres éléments interactifs, ainsi que des extensions JavaScript
en option. [Bha15].

Figure 1.13 – Logo de Bootstrap.

page 17
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

XAMPP
C’est un ensemble de logiciels permettant de mettre en place un serveur Web local,
un serveur FTP et un serveur de messagerie électronique. Il s’agit d’une distribution
de logiciels libres offrant une bonne souplesse d’utilisation, réputée pour son installation
simple et rapide .

Figure 1.14 – Logo de XAMPP.

Visual Studio Code

C’est Facile à installer, à comprendre, à utiliser et rapide, il dispose d’une interface
graphique responsive et customisable via des thèmes déjà installés. Quel que soit le lan-
gage : Javascript, PHP, JAVA, C, C++ ou autres, VS code permet de développer soit
via les fonctionnalités par défaut (pour le HTML, CSS, Javascript, Typescript. . .) ou en
ajoutant des extensions disponibles selon les besoins de chacun. Cette application nous a
aider à développer l’application web VueJSet Flutter .

Figure 1.15 – Logo de visual Studio.

SQL
C’est un langage informatique normalisé servant à exploiter des bases de données rela-
tionnelles. La partie langage de manipulation des données de SQL permet de rechercher,
d’ajouter, de modifier ou de supprimer des données dans les bases de données relation-
nelles. Outre le langage de manipulation des données .

page 18
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

Figure 1.16 – Logo de SQL.

Github
Github est une entreprise de développement logiciel et de service dont le siège est
situé aux États-Unis. Github développe notamment la plateforme Github,l’éditeur de
texte Atom ou encore le framework Electron

Figure 1.17 – Logo de Github

JSON
JSON Est un format de données textuelles dérivé de la notation des objets du langa-
geJavaScript. Il permet de représenter de l’information structurée comme le permet XML
par exemple. Dans notre projet, il nous a servir lors d’échange de données entre notre
backend et notre application mobile facilitant ainsi une communication fluide entre nos
deuxparties

Figure 1.18 – Logo de json

page 19
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

1.7 Architecture logicielle du projet

En informatique, architecture désigne la structure générale inhérente à un système
informatique, l’organisation des différents éléments du système (logiciels et/ou matériels
et/ou humains et/ou informations) et des relations entre ces éléments. Plus simplement
l’architecture d’une application sert à décrire d’une manière symbolique et schématique
les différents éléments de cette dernière, leurs interrelations et leurs interactions. Comme
architecture de notre application, nous allons choisir l’architecture 3-tiers.

1.7.1 Architecture 3-tiers :

L’architecture 3-tiers (le terme ”tier” vient de l’anglais et signifie ”niveau”) est un
modèle d’architecture d’application. Son principe de base consiste à séparer trois couches
logicielles contenues dans une application :
• Un client (le téléphone demandeur de ressources) équipé d’une interface utilisa-
teur.
• Un serveur d’application (appelé middleware) qui fournit la ressource mais en
faisant appel à un autre serveur.
• Un serveur de données qui fournit au serveur d’application les données (et/ou
les traitements) requises pour répondre au client.
La figure ci-dessus montre l’architecture de notre application côté front et back :

Figure 1.19 – Architecture de l’application

page 20
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

1.7.2 Modèle de conception (Design pattern) :

Un modèle de conception (ou patron de conception) est un ensemble de “bonnes pra-
tiques”, qui répond à un problème de conception d’une application. Il décrit une manière
d’architecturer une application informatique en la décomposant en sous-parties. Pour
notre application nous allons utiliser le modèle MVC pour le projet de Backend et MVVM
pour le projet Frontend.

[Link] Modèle de conception Backend (MVC) :

L’architecture Model-Vue-Controller consiste à découper son code pour qu’il appar-

tienne à l’une des trois composantes du MVC :
• Modèle : est responsable de la validation de la lecture et de l’enregistrement des
données. Dans notre exemple, il va s’assurer que toutes les données pour créer un
utilisateur ont bien été fournies. Dans l’affirmative il va créer l’utilisateur dans la
base de données et le passer au contrôleur
• La Vue : est responsable de l’interface graphique. Elle contient la logique pour
l’affichage des données qui ont été récupérées dans par le modèle.
• Le Contrôleur : est responsable de coordonner les actions à effectuer. Ici par
exemple, il peut vérifier le contenu de la requête, puis demander au modèle d’inscrire
l’utilisateur dans la base de données. Une fois que le modèle aura inscrit l’utilisateur,
il pourra préparer la vue à retourner à l’utilisateur.

Figure 1.20 – Design Pattern MVC

page 21
 CHAPITRE 1. PRESENTATION DU CADRE DU PROJET

[Link] Modèle de conception Frontend (MVVM) :

Model-View-ViewModel (MVVM) est un modèle de conception structurelle qui sépare

les objets en trois groupes distincts :

• Comme on le voit dans le cas de MVC, le modèle ici aussi est utilisé pour décrire la
logique métier et un ensemble de classes la caractérisant. Il travaille sur la concep-
tion de règles métier pour les données sur la façon dont les données sont modifiées
ou traitées. Vue Encore une fois, comme dans le cas de MVC et MVP, la vue ici
représente les composants de l’interface utilisateur comme HTML, CSS, etc.
• La Vue : Affiche les données que le contrôleur renvoie sous forme de résultat. Le
modèle peut également être converti en interface utilisateur à l’aide de la vue.
• View-Model : Il est de la responsabilité du View-Model d e présenter les méthodes
et les fonctions. Il doit présenter des commandes pour faire fonctionner le modèle,
maintenir l’état de la vue et activer les évènements dans la vue.

Figure 1.21 – Design Pattern MVVM

Conclusion
Dans ce chapitre, j’ai commencé par cerner le cadre général du projet. Ensuite, j’ai
présenté la méthodologie de conception que je vais suivre dans mon application. Enfin, j’ai
listé les différents outils et technologies nécessaires pour la mise en place de ma solution.
A ce stade, nous pouvons désormais passer au chapitre suivant, qui contiendra le plan du
projet et l’identification des fonctionnalités de notre application.

page 22
Chapitre 2

Sprint 0 : Analyse et Spécification

des Besoins

Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1 Capture de besoins . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . 24
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . 25
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . 25
2.2 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . 26
2.3 Diagramme de cas d’utilisation global . . . . . . . . . . . . . 26
2.4 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

23
 CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

Introduction
Une étape essentielle de tout cycle de développement logiciel ou conceptuel consiste
à effectuer une étude préalable. Le but de cette phase est de comprendre le contexte du
système. Il s’agit d’éclaircir au mieux les besoins fonctionnels et non fonctionnels, faire
apparaitre les acteurs et identifier les cas d’utilisation.
Dans ce chapitre, nous allons essayer de cerner les besoins sous forme de diagrammes
de cas d’utilisation.

2.1 Capture de besoins

Dans cette partie, nous allons identifier les acteurs et leurs rôles. Par la suite, nous
répondrons aux questions suivantes ≪ Que doit faire le système ? ≫ et ≪ Quelles sont les
contraintes ?≫ afin d’expliquer les différents besoins fonctionnels et non fonctionnels de
notre projet.

2.1.1 Identification des acteurs

On s’intéresse tout d’abord à la présentation des acteurs qui sont en contact direct avec
l’application et qui profitent des différents accès aux données. (Notons ici que tout genre
d’accès est obligatoirement authentifié) La table ci-après présente les différents acteurs
interagissant avec le système.

Table 2.1 – Table des acteurs.

Acteur Description
Administrateur L’administrateur joue un rôle primordiale et
fondamentale, c’est un personne responsable
de tous les paramétrages de l’application, il
a le droit de gérer tous l’utilisateur de l’ap-
plication .
Gestionnaire Acteur principale, sa fonction est de gérer les
contrats,les factures et les clients .
technicien Acteur principle, sa fonction est traiterles re-
clamation de maintenances.
Client Acteur principale, sa fonction est de ajouter
des reclamation et suivi son contrat,facture
et reclamation .

page 24
 CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.1.2 Identification des besoins fonctionnels

Les besoins fonctionnels correspondent aux fonctionnalités du système. Ce sont les
besoins spécifiant un comportement d’entrée/sortie du système.
Nous présenterons ainsi tous les besoins fonctionnels de mon projet :
• S’authentifier : Chaque membre dispose d’un login (choisi par l’admin) et d’un
mot de passe spécifique, qui assurent la vérification de son identité et lui autorisent
l’accès pour bénéficier des services fournis par l’application de manière totalement
sécurisée.
• Gérer les contrats : Le système permet à l’administrateur et le gestionnaire de
modifier, ajouter , supprimer et afficher les contrats.
• Gérer les utilisateurs : Le système permet à l’administrateur de modifier, ajouter
et supprimer les utilisateurs.
• Gérer les factures : les systéme permet L’administrateur et le gestionnaire de
modifier, ajouter ,supprimer et afficher les factures.
• Gérer les reclamations de maintenances : Le système permet à le technicien
du support de supprimer , modifier et consulter les reclamation.
• Gérer les réclamtions : Le système permet à le client d’ajouter,consulter et suivi
les reclamation et de suivi l’etat de son contrat et son facture .
• consulter compte : Le système permet à le client de suivi l’etat de son contrat et
son facture .

2.1.3 Identification des besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes techniques, ergonomiques
et esthétiques auxquelles est soumis le système pour sa réalisation et pour son bon fonc-
tionnement. Concernant notre application, j’ai dégagé les besoins suivants :
• Sécurité et confidentialité des informations : C’est l’une des contraintes les
plus importantes dans les app web. Notre application doit être hautement sécurisée,
doit respecter la confidentialité des données personnelles des utilisateurs, les infor-
mations ne doivent, pas être accessibles à tout le monde, c’est-à-dire que l’application
est possible à partir d’un login et d’un mot de passe.
• Intégrité des données : Grâce à l’existence de contrôles d’entrée, les données
saisies par l’utilisateur doivent être cohérentes et complètes.
• Extensibilité : Dans le cadre de ce travail, l’application devra être extensible,
c’est-à dire qu’il pourra y avoir une possibilité d’ajouter ou de modifier de nouvelles
fonctionnalités.

page 25
 CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

• Rapidité : le système est une application web et mobile, donc il doit être léger à
l’utilisation. Des optimisations doivent être réalisées sur le temps de calcul et sur
l’accès à la base des données .
• Convivialité et ergonomie : Les interfaces de l’application ont un grand impact
sur les utilisateurs quotidiens, pour cela elle doit être simple et facile à manipuler
même par des non experts et le thème adopté doit inspirer des couleurs et du logo
type de l’entreprise d’accueil.

2.2 Pilotage du projet avec SCRUM

Comme indiqué dans le chapitre précédent, nous avons choisi la méthodologie agile
SCRUM lors de la mise en place de l’application. En effet, la méthodologie SCRUM
nécessite la collaboration de plusieurs intervenants, pour notre projet :
• Poduct Owner : Mr MOUHA Mouhamed Sadok
• Scrum Master : Mr AYADI mouhamed Ghaith.
• Scrum Team : GRAMI haifa.

2.3 Diagramme de cas d’utilisation global

Pour mieux comprendre le fonctionnement de l’application, nous présentons le dia-
gramme de cas d’utilisation système. C’est un diagramme général qui englobe les fonction-
nalités principales que doit fournir l’application qui est présenté dans la Figure ci-après.

page 26
 CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

Figure 2.1 – Diagramme de cas d’utilisation global.

2.4 Product Backlog

Un Backlog est une liste de fonctionnalités ou de tâches, jugées nécessaires et suffisantes
pour la réalisation satisfaisante du projet. Les éléments du Backlog sont appelés des
histoires utilisateur (user story). Chacune de ces histoires doit avoir un but métier . Pour
le traitement des histoires, j’ai choisi de commencer par les tâches les plus prioritaires.
En effet, chaque histoire utilisateur possède une estimation qui est l’évaluation initiale de
l’équipe sur la quantité de travail nécessaire en jours pour implémenter cette exigence.
La TABLE suivante résume le backlog produit de l’application.

page 27
CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

Table 2.2 – Le backlog du produit

ID Fonctionnalité User stories Priorité

1 S’authentifier En tant qu’administrateur Élevée
/gestionnaire/technicien de
support/client, je dois m’au-
thentifier afin d’accéder à mon
interface de travail
2 Gérer les utilisateures En tant qu’administrateur,je Élevée
peux gérer les utilisateures
3 Gérer les contrats En tant administrateur/ ges- Élevée
tionnaire, je peux gérer les
contrats
4 Gérer les factures En tant qu’administra- Élevée
teur/gestionnaire, je peux
gérer les factures
6 traiter lereclamation de En tant que technicien de sup- Élevée
maintenance port, je peux traiter le reclama-
tion de maintenance
7 consulter comptr En tant que client, je peux suivi Élevée
mes contrat et facture
8 gérer reclamation En tant que client, je peux suivi Élevée
et ajouter une reclamation

page 28
 CHAPITRE 2. SPRINT 0 : ANALYSE ET SPÉCIFICATION DES BESOINS

2.5 Planification des sprints

Figure 2.2 – Planification des sprints

Conclusion
Tout au long de ce chapitre, nous avons détaillé les besoins attendus de notre solution.
Nous avons défini par la suite le diagramme de cas d’utilisation général, le diagramme de
classes et le backlog produit ainsi que la planification des différents sprints.
Le chapitre suivant sera consacré à la description des différentes étapes de mise en
place du premier sprint.

page 29
Chapitre 3

Sprint 1

Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Diagramme de cas d’utilisation du sprint 1 . . . . . . . . . . . 31
3.1.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Analyse du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . 34
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . 40
3.3.2 Diagrammes d’activité . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3 Diagramme du classe du Sprint 1 . . . . . . . . . . . . . . . . . 48
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

30
 CHAPITRE 3. SPRINT 1

Introduction
Ce chapitre est consacré aux travaux effectués durant le premier sprint et ceci en
décomposant les User Stories du sprint en des tâches présentées dans le Backlog de sprint.
Nous passons par une phase de spécification fonctionnelle et une phase de conception,
pour clôturer enfin par quelques interfaces réalisées lors de la phase de réalisation.
Rappelons que ce premier sprint contient les fonctionnalités suivantes :
• S’authentifier
• Gérer les utilisateures
• Gérer les contrats

3.1 Spécification des besoins

Dans cette partie, nous présentons le diagramme de cas d’utilisation du sprint ainsi
que le backlog du sprint.

3.1.1 Diagramme de cas d’utilisation du sprint 1

La Figure ci-après représente le diagramme de cas d’utilisation du sprint 1.

Figure 3.1 – Diagramme de cas d’utilisation du sprint 1

page 31
 CHAPITRE 3. SPRINT 1

3.1.2 Backlog du sprint 1

Avant de commencer le travail et après le choix des User Stories à réaliser durant
le sprint 0, nous arrivons à l’étape de décomposition des User Stories en des tâches
élémentaire. Nous présentons à travers le tableau 3.1 le Backlog du sprint 1 détaillé avec
complexité de chaque tâche qui peut avoir 1 au minimum et 3 au maximum.

page 32
 CHAPITRE 3. SPRINT 1

Table 3.1 – Le Backlog du sprint 1

ID User Stories ID Type Tache Complexité

1 En tant que 1.1 - Rechercher et déterminer -
responsable de les meilleures technologies
développement, qui seront utilisées dans
je veux adopter mon projet.
les meilleures
technologies qui
répondent au
mieux aux besoins,
de même que mon-
ter en compétences.
2 En tant qu’admi- 2.1 Front-End Mettre en place un bou- 1
nistrateur je dois ton devant chaque catégorie
m’authentifier. pour y accéder.

2.2 Front-End Développer une barre 3

latérale commune mais
personnaliser pour chaque
catégorie de notification.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.
3 En tant qu’admi- 3.1 Back-end Créer l’entité ‘utilisateur’ 1
nistrateur je peux dans la base de données.
consulter, ajouter
,afficher et suppri-
mer un utilisateur.
3.2 Back-End Créer un web service pour 1
gérer les utilisateur.

3.3 Front-End Créer un service web front. 2

3.4 Front-End Créer l’interface gérer “uti- 2

lisateur“.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.

page 33
 CHAPITRE 3. SPRINT 1

4 En tant que 4.1 Back-end Créer l’entité ‘contrat’ dans 1

gestionnaire je la base de données.
peux consulter,
ajouter,afficher
et supprimer un
contrat.
4.2 Back-End Créer un web service pour 1
gérer les contrats.

4.3 Front-End Créer un service web front. 2

4.4 Front-End Créer l’interface gérer 2

“contrat“.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.

3.2 Analyse du sprint1

Afin de mieux assimiler les cas d’utilisation, nous avons etabli leurs raffinements pour
livrer une description détaillée sur les différents scénarios possibles.

3.2.1 Raffinement des cas d’utilisation

Dans cette sous-section, nous allons présenter les raffinements des diagrammes de cas
d’utilisation liés au premier sprint, ainsi qu’une description textuelle des principaux cas
d’utilisation.

page 34
 CHAPITRE 3. SPRINT 1

[Link] Cas d’utilisation ≪ S’authentifier ≫

Figure 3.2 – Diagramme de cas d’utilisation ≪ S’authentifier ≫.

Table 3.2 – Description textuelle du cas d’utilisation ≪ S’authentifier ≫

Cas d’utilisation S’authentifier

Acteurs Administrateur / Gestionnaire/ Technicien du support/client
Pré-condition L’utilisateur doit avoir un compte et le login et le mot de passe
saisis doivent être corrects.
1. Afficher l’interface de l’authentification
Scénario Nominal 2. Saisir le login et le mot de passe et valider
3. Le système vérifie les coordonnées
4. Le système affiche l’interface d’accueil propre à l’utilisateur.
Post-condition L’acteur accède à la configuration des notifications.
Données saisies invalides :
Exception
Affichage d’un message d’erreur

page 35
 CHAPITRE 3. SPRINT 1

[Link] Cas d’utilisation ≪ Gérer les utilisateurs ≫

Figure 3.3 – Diagramme de cas d’utilisation ”Gérer les utilisateurs ”.

Table 3.3 – Description textuelle du sous cas d’utilisation ≪ Ajouter utilisateur ≫

Cas d’utilisation Ajouter utilisateur

Acteurs Administrateur
Pré-condition Administrateur authentifié
1. L’administrateur clique sur bouton ≪Ajouter utilisateur≫.
Scénario Nominal 2. Le système affiche le formulaire d’ajout d’un utilisateur.
3. L’administrateur remplit le formulaire d’ajout d’un utilisa-
teur et clique sur le bouton ≪Enregitrer≫.
4. Le système ajoute l’utilisateur à la liste des utilisateurs.
Post-condition utilisateur ajoutée.
Données invalides :
Exception
Affichage d’un message d’erreur ”utilisateur déjà existante
dans la base de données”

Table 3.4 – Description textuelle du sous cas d’utilisation ≪ Consulter utilisateur ≫

Cas d’utilisation Consulter utilisateur

Acteurs Administrateur
Pré-condition Administrateur authentifié
1. L’administrateur ouvre l’interface gerer utilisateures.
Scénario Nominal
2. La table utilisateur s’affiche.
Post-condition La liste des utlisateures est affichée.
Exception Problème de connexion à la base de données.

page 36
 CHAPITRE 3. SPRINT 1

Table 3.5 – Description textuelle du sous cas d’utilisation ≪ modifie utilisateur ≫

Cas d’utilisation Modifier un utilisateur

Acteurs Administrateur
Pré-condition Administrateur authentifié
1. L’administrateur clique sur bouton ≪Modifier≫.
Scénario Nominal 2. Le système affiche le formulaire du modification d’un utili-
sateurs.
3. L’administrateur remplit le formulaire du modification d’un
utilisateur et clique sur le bouton ≪Enregitsrer≫.
4. Le système met à jour les informations de l’utilisateur mo-
difiée à la liste du utilisateur.
Post-condition utilisateur modifié.
*Affichage d’un message d’erreur ”impossible de modifier
Exception
cette utilisateur”.
Problème de connexion à la base de données.

Table 3.6 – Description textuelle du sous cas d’utilisation ≪ Supprimer utilisateur ≫

Cas d’utilisation Supprimer utilisateur

Acteurs Administrateur
Pré-condition Administrateur authentifié
[Link] la liste des utilisateur.
2. L’administrateur choisit l’utilisateur à supprimer et clique
sur le bouton supprimer.
3. Le système affiche un message de confirmation
Scénario Nominal 4. L’administrateur clique sur le bouton≪Confirmer≫ .
5. Le systéme affiche un message de succés de suppression
d’utilisateur.
6. Le système affiche la nouvelle liste des utlisateurs.
Post-condition utilisateur Supprimé.
*Affichage d’un message d’erreur ” impossible de supprimer
Exception
cette utilisateur ”.
*Problème de connexion à la base de données

page 37
 CHAPITRE 3. SPRINT 1

Table 3.7 – Description textuelle du sous cas d’utilisation ≪ afficher utilisateur ≫

Cas d’utilisation afficher utilisateur

Acteurs administrateur
Pré-condition administrateur authentifié
[Link] la liste des utilisateurs .
2. L’administrateur choisit l’utilisateur à afficher et clique sur
le bouton ≪Afficher≫.
3. Le système affiche l’utilisateur qui a choisit.
Post-condition utilisateur afficher.
Exception Problème de connexion à la base de données.

[Link] Cas d’utilisation ≪ Gérer les contrats ≫

Figure 3.4 – Diagramme de cas d’utilisation ≪ Gérer les contrats ≫.

Table 3.8 – Description textuelle du sous cas d’utilisation ≪ Ajouter contrat ≫

Cas d’utilisation Ajouter contrat

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
1. Le gestionnaire clique sur bouton ≪Ajouter contrat≫.
Scénario Nominal 2. Le système affiche le formulaire d’ajout d’un contrat.
3. Le gestionnaire remplit le formulaire d’ajout d’un contrat
et clique sur le bouton ≪Enregitrer≫.
4. Le système ajoute le contrat à la liste des types tickets.
Post-condition contrat ajouté.
Données invalides :
Exception
Affichage d’un message d’erreur ”contrat déjà existant dans
la base de données”.
Retour à l’étape 2 du scénario nominal.

page 38
 CHAPITRE 3. SPRINT 1

Table 3.9 – Description textuelle du sous cas d’utilisation ≪ Consulter contrat ≫

Cas d’utilisation Consulter contrat

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
1. gestionnaire ouvre l’interface gerer contrat.
Scénario Nominal
2. La table contrat s’affiche.
Post-condition La liste des contrat est affichée.
Exception Problème de connexion à la base de données.

Table 3.10 – Description textuelle du sous cas d’utilisation ≪ modifier contrat ≫

Cas d’utilisation Modifier un contrat

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
1. Le gestionnaire clique sur bouton ≪Modifier≫.
Scénario Nominal 2. Le système affiche le formulaire du modification d’un
contrat.
3. Le gestionnaire remplit le formulaire du modification d’un
contrat et clique sur le bouton ≪Enregitsrer≫.
4. Le système met à jour les informations de contrat modifiée
à la liste du contrats.
Post-condition contrat modifié.
*Affichage d’un message d’erreur ”impossible de modifier
Exception
cette contrat”.
Problème de connexion à la base de données.

Table 3.11 – Description textuelle du sous cas d’utilisation ≪ Supprimer contrat ≫

Cas d’utilisation Supprimer contrat

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
[Link] la liste des contrats.
2. Le gestionnaire choisit le contrat à supprimer et clique sur
le bouton supprimer.
Scénario Nominal 3. Le gestionnaire clique sur le bouton≪ok≫ .
4. Le système affiche la nouvelle liste contrats.
Post-condition contrat Supprimé.
Exception Problème de connexion à la base de données.

page 39
 CHAPITRE 3. SPRINT 1

Table 3.12 – Description textuelle du sous cas d’utilisation ≪ afficher contrat ≫

Cas d’utilisation afficher contrat

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
[Link] la liste des contrats.
2. Le gestionnaire choisit le contrat à afficher et clique sur le
bouton ≪Afficher≫.
3. Le système affiche le contrat qui a choisit.
Post-condition contrat afficher.
Exception Problème de connexion à la base de données.

3.3 Conception
La conception présente une entrée majeure pour les activités d’implémentation et de
test. Elle se traduit, dans mon cas, par les diagrammes d’activité et les diagramme de
séquences détaillés.

3.3.1 Diagramme de séquences détaillés

Un diagramme de séquences détaillé permet de représenter en détails les interactions
entre les objets métiers de notre système selon un ordre chronologique.

[Link] Cas d’utilisation ≪ S’authentifier ≫

La Figure suivante présente le diagramme de séquences détaillé du cas d’utilisation

≪ S’authentifier ≫.

page 40
 CHAPITRE 3. SPRINT 1

Figure 3.5 – Diagramme de séquences détaillé du cas d’utilisation ≪ S’authentifier ≫.

[Link] Cas d’utilisation ≪ Ajouter utilisateur ≫

La Figure suivante présente le diagramme de séquences détaillé du sous-cas d’utilisa-

tion ≪ Ajouter utilisateur ≫.

page 41
 CHAPITRE 3. SPRINT 1

Figure 3.6 – Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Ajouter

utilisateur ≫.

page 42
 CHAPITRE 3. SPRINT 1

[Link] Cas d’utilisation ≪ Consulter utilisateur ≫

La Figure ci-après montre le diagramme de séquences détaillé du sous-cas d’utilisation

≪ Consulter utilisateur ≫.

Figure 3.7 – Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Consulter

utilisateur ≫.

[Link] Cas d’utilisation ≪ Supprimer utilisateur ≫

La Figure suivante présente le diagramme de séquences détaillés du sous-cas d’utilisa-

tion ≪ Supprimer utilisateur ≫.

page 43
 CHAPITRE 3. SPRINT 1

Figure 3.8 – Diagramme de séquences détaillé du sous-cas d’utilisation ≪ Supprimer

utilisateur ≫.

3.3.2 Diagrammes d’activité

Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et
de flots de données. Ils permettent ainsi de représenter graphiquement le comportement
d’une méthode ou le déroulement d’un cas d’utilisation [Fou12].

[Link] Cas d’utilisation ≪ S’authentifier ≫

La Figure suivante présente le diagramme d’activité du cas d’utilisation ≪ S’authenti-

fier ≫.

page 44
 CHAPITRE 3. SPRINT 1

Figure 3.9 – Diagramme d’activité du cas d’utilisation ≪ S’authentifier ≫.

page 45
 CHAPITRE 3. SPRINT 1

[Link] Cas d’utilisation ≪ Ajouter utilisateur ≫

La Figure suivante présente le diagramme d’activité du sous-cas d’utilisation ≪ Ajouter

utilisateur ≫.

Figure 3.10 – Diagramme d’activité du sous-cas d’utilisation ≪ Ajouter direction ≫.

page 46
 CHAPITRE 3. SPRINT 1

[Link] Cas d’utilisation ≪ Supprimer utilisateur ≫

La Figure suivante présente le diagramme d’activité du sous-cas d’utilisation ≪ Sup-

primer utilisateur ≫.

Figure 3.11 – Diagramme d’activité du sous-cas d’utilisation ≪ Supprimer direction ≫.

page 47
 CHAPITRE 3. SPRINT 1

3.3.3 Diagramme du classe du Sprint 1

Figure 3.12 – Diagramme Global du classe du Sprint 1

page 48
 CHAPITRE 3. SPRINT 1

3.4 Réalisation
• Interface : Authentification

Figure 3.13 – Interface : Authentification

• Interface : dashboard administration

Figure 3.14 – Interface : dashboard administration

page 49
 CHAPITRE 3. SPRINT 1

• Interface admin :consulter client

Figure 3.15 – Interface : consulter contrat

• Interface : ajouter contrat

Figure 3.16 – Interface :ajouter contrat

page 50
 CHAPITRE 3. SPRINT 1

• Interface : liste des utilisateurs

Figure 3.17 – Interface : liste des utilisateurs

3.5 Tests et validation

En informatique, un test désigne une procédure de vérification partielle d’un système.
Le tableau suivant présente les tests effectués lors sprint1 en collaboration avec le product
owner comme le montre le tableau suivant :

Table 3.13 – Table des acteurs.

Fonctionnalité Résultat
S’authentifier . Conforme
Gérer les utilisateures. Conforme
Gérer les contrats. Conforme

Table 3.14 – Tests de validation

Conclusion
Tout au long de ce chapitre, nous avons présenté le backlog du sprint 1 ainsi que la
conception, l’analyse, et les interfaces des cas d’utilisation ”S’authentifier”, ”Gérer les
utilisateurs” et ”Gérer les contrats”. Dans le prochain chapitre, nous allons présenter
le deuxième sprint.

page 51
Chapitre 4

Sprint 2

Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Spécification des besoins du sprint 2 . . . . . . . . . . . . . . . 53
4.1.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . 53
4.1.2 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . 55
4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . 59
4.3.2 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.3 Diagramme de Classe du Sprint 2 . . . . . . . . . . . . . . . . . 66
4.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

52
 CHAPITRE 4. SPRINT 2

Introduction
En partant sur le même principe que le Sprint précédent, nous commençons par défaut,
par le but de notre deuxième Sprint :
Rappelons que ce premier sprint contient les fonctionnalités suivantes :
• Gérer les factures
• traiter les reclamations

4.1 Spécification des besoins du sprint 2

Dans cette partie, nous présentons le diagramme de cas d’utilisation du sprint 2 suivi
par le backlog du sprint.

4.1.1 Diagramme de cas d’utilisation du sprint 2

La Figure 4.1 présente le diagramme de cas d’utilisation du sprint 2.

Figure 4.1 – Diagramme de cas d’utilisation du sprint 2.

4.1.2 Backlog du sprint 2

En partant du même principe que le sprint précédent, nous commençons par définir
le but du deuxième sprint. La Table 4.1 détaille le Backlog du sprint 2.

page 53
 CHAPITRE 4. SPRINT 2

Table 4.1 – Le Backlog du sprint 2

ID User Stories ID Type Tache Complexité

1 En tant que ges- 1.1 Back-end Créer l’entité ‘facture’ dans 1
tionnairer je peux la base de données.
consulter, ajouter
modifier,afficher
et supprimer une
facture.
1.2 Back-End Créer un web service ’fac- 1
tureAPI’ pour gérer les fac-
ture.

1.3 Front-End Créer un service web front. 2

1.4 Front-End Créer l’interface CRUD 2

“facture“.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.
2 En tant technicien 2.1 Back-end Créer l’entité ‘reclamation’ 1
je peux consulter, dans la base de données.
modifier et suppri-
mer une reclama-
tion .
2.2 Back-End Créer un web service pour 1
traiter les reclamation.

2.3 Front-End Créer un service web front. 2

2.4 Front-End Créer l’interface gérer “re- 2

clamtion“.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.

page 54
 CHAPITRE 4. SPRINT 2

4.2 Analyse
Afin de mieux assimiler les cas d’utilisation, nous allons établir leurs raffinements pour
livrer une description sur les différents scénarios possibles.

4.2.1 Raffinement des cas d’utilisation

Dans cette sous-section, nous présentons les raffinements des diagrammes de cas d’uti-
lisation liés au deuxième sprint, ainsi qu’une description textuelle des principaux cas
d’utilisation.

[Link] Cas d’utilisation ≪ Gérer facture ≫

La Figure 4.2 représente le diagramme de cas d’utilisation de ≪ Gérer facture ≫.

Figure 4.2 – Diagramme de cas d’utilisation ≪ Gérer facture ≫.

page 55
 CHAPITRE 4. SPRINT 2

Table 4.2 – Description textuelle du sous cas d’utilisation ≪ Ajouter facture ≫

Cas d’utilisation Ajouter facture

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
[Link] gestionnair ouvre l’interface gerer facture.
2. le gestionnair clique sur bouton ≪Ajouter≫.
Scénario Nominal 3. Le système affiche le formulaire d’ajout d’un factur.
4. Le gestionnair remplit le formulaire d’ajout d’un facture et
clique sur le bouton ≪Enregitrer≫.
5. Le système ajoute un facture à la liste des facture.
Post-condition Un facture ajouté.
*Les informations manquantes
Exception
*Affichage d’un message d’erreur ”facture n’existe pas dans
la base”.

Table 4.3 – Description textuelle du sous cas d’utilisation ≪ Consulter facture ≫

Cas d’utilisation Consulter facture

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
1. Le gestionnaire ouvre l’interface gerer facture.
Scénario Nominal
2. La table facture s’affiche.
Post-condition La liste facture est affichée.
Exception Problème de connexion à la base de données.

Table 4.4 – Description textuelle du sous cas d’utilisation ≪ Supprimer facture ≫

Cas d’utilisation Supprimer facture

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
[Link] la liste des facture.
2. Le gestionnaire choisit le facture à supprimer et clique sur
le bouton supprimer.
Scénario Nominal 3. Le gestionnaire clique sur le bouton≪ok≫ .
4. Le système affiche la nouvelle liste de facture.
Post-condition facture Supprimé.
Exception Problème de connexion à la base de données.

page 56
 CHAPITRE 4. SPRINT 2

Table 4.5 – Description textuelle du sous-cas d’utilisation ≪ afficher un factur ≫

Cas d’utilisation afficher un facture

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
[Link] la liste des factures.
Scénario Nominal 2. gestionnaire choisit une facture à afficher et clique sur le
bouton afficher.
3. Le systéme affiche toutes les informations relatives à la
facture.
Post-condition Detail facture affiché.
Exception Problème de connexion à la base de données.

Table 4.6 – Description textuelle du sous-cas d’utilisation ≪ Modifier facture ≫

Cas d’utilisation Modifier une facture

Acteurs gestionnaire
Pré-condition gestionnaire authentifié
1. Le gestionnaire clique sur bouton ≪Modifier≫.
Scénario Nominal 2. Le système affiche le formulaire du modification d’une fac-
ture.
3. L’administrateur remplit le formulaire du modification
d’une facture et clique sur le bouton ≪Enregitsrer≫.
4. Le système met à jour les informations de la facture mo-
difiée à la liste du factures.
Post-condition facture modifié.
*Affichage d’un message d’erreur ”impossible de modifier
Exception
cette facture”.
Problème de connexion à la base de données.

page 57
 CHAPITRE 4. SPRINT 2

[Link] Cas d’utilisation ≪ traiter les réclamations ≫

La figure 5.2 représente le diagramme de cas d’utilisation de ”traiter les reclamation”.

Figure 4.3 – Diagramme de cas d’utilisation ”Gérer tickets”.

Table 4.7 – Description textuelle du sous cas d’utilisation ≪ modifier reclamation ≫

Cas d’utilisation Modifier reclamation

Acteurs technicien
Pré-condition technicien authentifié
1. Le technicien clique sur bouton ≪Modifier≫.
Scénario Nominal 2. Le système affiche le formulaire du modification d’un
contrat.
3. Le gestionnaire modifier l’etat et le date du reclamation et
clique sur le bouton ≪Enregitsrer≫.
4. Le système met à jour les informations de reclamation mo-
difiée à la liste du reclamations.
Post-condition contrat modifié.
*Affichage d’un message d’erreur ”impossible de modifier
Exception
cette contrat”.
Problème de connexion à la base de données.

page 58
 CHAPITRE 4. SPRINT 2

Table 4.8 – Description textuelle du sous cas d’utilisation ≪ Consulter reclamation ≫

Cas d’utilisation Consulter reclamation

Acteurs technicien
Pré-condition technicien authentifié
1. L’acteur ouvre l’interface reclamations.
Scénario Nominal
2. L’interface reclamationss .
Post-condition L’interface reclamatons est affichée.
Exception Problème de connexion à la base de données.

Table 4.9 – Description textuelle du sous cas d’utilisation ≪ Supprimer reclamation ≫

Cas d’utilisation Supprimer reclamation

Acteurs technicien
Pré-condition technicien authentifié
[Link] la liste des relamation.
2. Le technicien choisit le reclamation à supprimer et clique
sur le bouton supprimer.
Scénario Nominal 3. Le technicien clique sur le bouton≪ok≫ .
4. Le système affiche la nouvelle liste contrats.
Post-condition contrat Supprimé.
Exception Problème de connexion à la base de données.

4.3 Conception
4.3.1 Diagramme de séquences détaillés
[Link] Cas d’utilisation ≪ Ajouter une facture ≫

Dans ce qui suit le diagramme de séquences détaillés du sous cas d’utilisation ≪ Ajouter
une facture ≫.

page 59
 CHAPITRE 4. SPRINT 2

Figure 4.4 – Diagramme de séquences détaillés du sous cas d’utilisation ≪ Ajouter facture ≫

page 60
 CHAPITRE 4. SPRINT 2

[Link] Cas d’utilisation ≪ Consulter facture ≫

Dans ce qui suit le diagramme de séquences détaillés du sous cas d’utilisation ≪ Consul-
ter facture ≫.

Figure 4.5 – Diagramme de séquences détaillés du sous cas d’utilisation ≪ Consulter facture ≫

page 61
 CHAPITRE 4. SPRINT 2

[Link] Cas d’utilisation ≪ Supprimer une facture ≫

Dans ce qui suit le diagramme de séquences détaillés du sous cas d’utilisation ≪ Sup-
primer une facture ≫.

Figure 4.6 – Diagramme de séquences détaillés du sous cas d’utilisation ≪ Supprimer une
facture ≫

page 62
 CHAPITRE 4. SPRINT 2

[Link] Cas d’utilisation ≪ traiter les reclamation ≫

Dans ce qui suit le diagramme de séquences détaillés du sous cas d’utilisation ≪ Consul-
ter reclamation ≫.

Figure 4.7 – Diagramme de séquences détaillés du sous cas d’utilisation ≪ Consulter

reclamation ≫

[Link] Cas d’utilisation ≪ traiter les reclamation ≫

Dans ce qui suit le diagramme de séquences détaillés du sous cas d’utilisation ≪ sup-
primer reclamation ≫.

page 63
 CHAPITRE 4. SPRINT 2

Figure 4.8 – Diagramme de séquences détaillés du sous cas d’utilisation ≪ supprimer

reclamation ≫

page 64
 CHAPITRE 4. SPRINT 2

4.3.2 Diagramme d’activité

Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et
de flots de données. Ils permettent ainsi de représenter graphiquement le comportement
d’une méthode ou le déroulement d’un cas d’utilisation [Fou12].

[Link] Cas d’utilisation ≪ ajouter facture ≫

Dans ce qui suit le diagramme d’activité du sous cas d’utilisation ≪ ajouter une fac-
ture ≫.

Figure 4.9 – Diagramme d’activité du sous cas d’utilisation ≪ ajouter une facture ≫

page 65
 CHAPITRE 4. SPRINT 2

4.3.3 Diagramme de Classe du Sprint 2

Figure 4.10 – Diagramme de classe du sprint2

page 66
 CHAPITRE 4. SPRINT 2

4.4 Réalisation

• Interface : cosulter facturel

Figure 4.11 – Interface : Consulter une facture

• Interface :consulter facture

Figure 4.12 – Interface : consulter liste de factures

page 67
 CHAPITRE 4. SPRINT 2

• Interface :dashboard technicien

Figure 4.13 – Interface : dashboard technicien

• Interface : supprimer reclamation

Figure 4.14 – Interface :supprimer reclamation

page 68
 CHAPITRE 4. SPRINT 2

• Interface : Consulter reclamation

Figure 4.15 – Interface : Consulter reclamation

4.5 Tests et validation

Nous avons terminé ce sprint par une étape de validation et tests réalisés avec le
product owner qui a testé toutes les fonctionnalités du sprint 2 et les a validées.

Fonctionnalité Résultat
Gérer les facture Conforme
traiter les reclamation Conforme

Table 4.10 – Tests et validation

Conclusion
Dans le présent chapitre, nous avons détaillé toutes les étapes de mise en place des
fonctionnalités du sprint 2 de l’analye des besoins jusqu’aux tests et validation. Le pro-
chain chapitre sera consacré au sprint 3 d’où la finalisation de notre application.

page 69
Chapitre 5

Sprint 3

Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1 Spécification des besoins du sprint 3 . . . . . . . . . . . . . . . 71
5.1.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.2 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . 71
5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1 Raffinement des cas d’utilisation . . . . . . . . . . . . . . . . . 72
5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.1 Diagramme de séquences détaillés . . . . . . . . . . . . . . . . 75
5.3.2 Diagramme de Classe du Sprint 3 . . . . . . . . . . . . . . . . . 79
5.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . 82

70
 CHAPITRE 5. SPRINT 3

Introduction
Ce chapitre est consacré aux travaux effectués durant le troisième et dernier sprint. À
la fin de ce sprint le backlog produit sera clôturé, pour avoir un projet complet.

5.1 Spécification des besoins du sprint 3

Dans cette partie, nous présentons le backlog du sprint suivi par le diagramme de cas
d’utilisation.

5.1.1 Backlog du sprint 3

Au niveau de cette partie, nous présentons le backlog du sprint 3 à travers la Table
5.1.

Table 5.1 – Le Backlog du sprint 3

ID User Stories ID Type Tache Complexité

1 En tant que client, 1.1 Back-End Créer un web service pour 1
je peux consulter our consulter mon compte.
mon compte
1.2 Front-End Créer un service web front. 2

1.3 Front-End Créer l’interface . 2

- Test Test et validation. -

- Conception Conception des dia- -

grammes.
2 En tant que client, 2.1 Back-End Créer un web service pour 1
je peux gérer les re- gérer les reclamation.
clamation
2.2 Front-End Créer un service web front. 2

2.3 Front-End Créer l’interface “reclama- 2

tion“.

- Test Test et validation. -

- Conception Conception des dia- -

grammes.

5.1.2 Diagramme de cas d’utilisation du sprint 3

La figure représente le diagramme de cas d’utilisation du sprint 3.

page 71
 CHAPITRE 5. SPRINT 3

Figure 5.1 – Diagramme de cas d’utilisation du sprint 3.

5.2 Analyse
Afin de mieux assimiler les cas d’utilisation, nous allons établir leurs raffinements pour
livrer une description sur les différents scénarios possibles.

5.2.1 Raffinement des cas d’utilisation

Dans cette sous-section, nous présentons les raffinements des diagrammes de cas d’uti-
lisation liés au troisiéme sprint, ainsi qu’une description textuelle des principaux cas d’uti-
lisation.

page 72
 CHAPITRE 5. SPRINT 3

[Link] Ca d’utilisation ≪ consulter son compte ≫

Figure 5.2 – Diagramme de cas d’utilisation ≪ consulter son compte ≫.

Table 5.2 – Description textuelle du sous cas d’utilisation ≪ suivi compte ≫

Cas d’utilisation suivi compte

Acteurs client
Pré-condition client authentifié
1. Le client sélectionne l’interface qu’il souhaite suivre.
Scénario Nominal
2. Le système affiche les informations détaillées du l’interface
sélectionné,.
Post-condition Linterface est affichée.
Exception Problème de connexion à la base de données.

page 73
 CHAPITRE 5. SPRINT 3

[Link] Cas d’utilisation ≪ gérer les réclamations ≫

Figure 5.3 – Diagramme de cas d’utilisation ≪ gérer les réclamations ≫

Table 5.3 – Description textuelle du sous cas d’utilisation ≪ suivi reclamation ≫

Cas d’utilisation suivi reclamation

Acteurs client
Pré-condition client authentifié
1. Le client sélectionne l’interface reclamation.
Scénario Nominal
2. Le système affiche les informations détaillées du l’interface
reclamation,.
Post-condition Linterface est affichée.
Exception Problème de connexion à la base de données.

Table 5.4 – Description textuelle du sous cas d’utilisation ≪ Ajouter réclamation ≫

Cas d’utilisation Ajouter réclamation

Acteurs client
Pré-condition client authentifié
[Link] client ouvre l’interface gerer réclamation
2. le client clique sur bouton ≪Ajouter≫.
Scénario Nominal 3. Le système affiche le formulaire d’ajout d’un réclamation.
4. Le client remplit le formulaire d’ajout d’un réclamation et
clique sur le bouton ≪Enregitrer≫.
5. Le système ajoute une réclamation à la liste des
réclamations.
Post-condition Une réclamation ajouté.
*Les informations manquantes
Exception
*probléme de connexion à la base de données.

page 74
 CHAPITRE 5. SPRINT 3

5.3 Conception
Dans cette section je présenterai les diagrammes de séquences détaillés du sprint 3.

5.3.1 Diagramme de séquences détaillés

Un diagramme de séquences détaillé permet de représenter en détails les interactions
entre les objets métiers de notre système selon un ordre chronologique.

[Link] Cas d’utilisation ≪ consulter compte ≫

La Figure suivante présente le diagramme de séquences détaillés du sous-cas d’utilisa-

tion ≪ suivi compte ≫.

Figure 5.4 – Diagramme de séquences détaillés du cas d’utilisation ≪ Consulter compte ≫

[Link] Cas d’utilisation ≪ consulter compte ≫

La Figure ci-dessous présente le diagramme de séquences détaillés du sous-cas d’utili-

sation ≪ suivi compte ≫.

page 75
 CHAPITRE 5. SPRINT 3

Figure 5.5 – Diagramme de séquences détaillés du cas d’utilisation ≪ consulter compte ≫

[Link] Cas d’utilisation ≪ gérer reclamation ≫

La Figure suivante présente le diagramme de séquences détaillés du sous-cas d’utilisa-

tion ≪ ajouter reclamation ≫.

page 76
 CHAPITRE 5. SPRINT 3

Figure 5.6 – Diagramme de séquences détaillés du cas d’utilisation ≪ gérer reclamation ≫.

[Link] Cas d’utilisation ≪ gérer reclamation ≫

La Figure suivante présente le diagramme de séquences détaillés du sous-cas d’utilisa-

tion ≪ suivi reclamation ≫.

page 77
 CHAPITRE 5. SPRINT 3

Figure 5.7 – Diagramme de séquences détaillés du cas d’utilisation ≪ gérer reclamation ≫.

page 78
 CHAPITRE 5. SPRINT 3

5.3.2 Diagramme de Classe du Sprint 3

Figure 5.8 – Diagramme de classe du sprint3

page 79
 CHAPITRE 5. SPRINT 3

5.4 Réalisation

• Interface : dashboard client

Figure 5.9 – Interface :dashboard client

• Interface : suivi reclamation

Figure 5.10 – Interface :suivi reclamation

page 80
 CHAPITRE 5. SPRINT 3

• Interface : ajouter un reclamation

Figure 5.11 – Interface : Refuser ticket en attente

• Interface :suivi compte

Figure 5.12 – Interface :suivi l’etat de facture

page 81
 CHAPITRE 5. SPRINT 3

• Interface :suivi compte

Figure 5.13 – Interface :suivi contrat

5.5 Tests et validation

Les tests des fonctionnalités ont été réalisés en collaboration avec le product owner.
Avec cette étape nous clôturons la mise en place de mon application qui a été faite avec
succès.

Fonctionnalité Résultat
consulter compte. Conforme
gérer les reclamation. Conforme

Table 5.5 – Liste des tests

Conclusion
ConclusionA ce stade, nous avons réussi à développer le dernier sprint de notre so-
lution pour arriver à un produit complet et fonctionnel. Notre solution est donc prête
à être exploitée en offrant aux acteurs la possibilité de gérer convenablement toutes les
fonctionnalités du système.

page 82
Conclusion et perspectives

Dans le cadre de mon projet de fin d’études, j’ai conçu et développé une application
web de PROGRESS ENGINEERING permettant d’automatiser la gestion des contrats
de support de maintenance . Cette application sera un système fiable utilisé par tout le
employès et les clients de PROGRESS ENGINEERING participant dans le traitement
d’une demande dés son remplissage jusqu’à la dernière signature.
En se basant sur la formation acquise durant mon cursus universitaire et sur les nou-
velles notions que j’ai pu assimiler au sein de l’entreprise dans laquelle j’ai effectué mon
stage, les objectifs que j’ai fixés au départ sont en grande partie atteints.

Ce projet de fin d’études m’a été très bénéfique et enrichissant puisqu’il m’a permis,
d’une part, de me familiariser avec la vie professionnelle et, d’autre part, de découvrir de
nouvelles approches de développement et d’utiliser des technologies récentes (symfony6,
Nodejs, php8, Postman, Overleaf,..) ainsi que les principes de fonctionnement des PRO-
GRESS ENGINEERING. Mais cela n’empêche que j’ai eu quelques difficultés, vu que
c’était ma première expérience avec SCRUM, j’ai consacré beaucoup de temps pour ap-
prendre et maı̂triser cette méthodologie et malgré toutes les difficultés rencontrées et les
contraintes de temps, j’ai réussi à améliorer mes performances et mes connaissances de la
conception jusqu’à la réalisation en pratiquant mes acquis et en dépassant toutes sortes
de problèmes.

Mon travail ne s’arrête pas à ce niveau, il est loin d’être le temps d’arrêter le développement
de cette application du PROGREE ENGINEERING, en effet la solution développée reste
extensible à tout type d’amélioration.
Pour conclure, à travers ce stage, j’ai eu la chance d’améliorer mes aptitudes à communi-
quer, à travailler en collaboration et à savoir être responsable, ce qui va me permettre de
bien s’intégrer dans le milieu professionnel.

83
Bibliographie

[Aub11] Claude Aubry. ≪ Scrum ≫. In : Le guide pratique de la méthode Agile la plus

populaire (2nd ed). Malakoff, France: Dunod Editions (2011).
[Bas16] Arindam Basu. ≪ How to write using rich text format and markdown in latex
and overleaf ≫. In : Universidad de Canterbury (2016).
[Bha15] Snig Bhaumik. Bootstrap essentials. Packt Publishing Ltd, 2015.
[CS16] Alain Collignon et Joachim Schöpfel. ≪ Méthodologie de gestion agile
d’un projet. Scrum–les principes de base ≫. In : I2D Information, donnees
documents 53.2 (2016), p. 12-15.
[Fou12] Damien Foures. ≪ Transformation des diagrammes d’activités SysML1. 2
vers les réseaux de Petri dans un cadre MDE ≫. In : (2012).
[Guy18] Marine Guyot. ≪ Méthode Agile vs Méthode Classique, quelle est la meilleure
façon de gérer son projet ? ≫ In : marine-guyot (2018).
[HI12] Lamia Ben Hiba et Mohammed Abdou Janati Idrissi. ≪ Tendances des
méthodes de gestion des projets informatiques ≫. In : Revu (2012), p. 7.
[Mey06] Eric A Meyer. CSS: The Definitive Guide: The Definitive Guide. ” O’Reilly
Media, Inc.”, 2006.
[MG00] Pierre-Alain Muller et Nathalie Gaertner. Modélisation objet avec UML.
T. 514. Eyrolles Paris, 2000.
[RLJ+99] Dave Raggett, Arnaud Le Hors, Ian Jacobs et al. ≪ HTML 4.01 Speci-
fication ≫. In : W3C recommendation 24 (1999).

84
BIBLIOGRAPHIE

page 85