Ministère de l’enseignement supérieur et de la recherche

scientifique
Université de Jendouba
Faculté des Sciences juridiques économiques et de Gestion
de Jendouba

En vue d’obtenir un diplôme en Informatique de Gestion

spécialité électronique Business
Conception et Développement d’une application
Web Suivie des Productions

Réalisé par : Encadré par :

Ben Salah Samar Mr. Marzouki Sofien
Encadrant du stage :
[Link] Seif Eddine

Année Universitaire : 2023/2024

 Remerciement
Ce rapport est le fruit de stage que j’ai eu le plaisir de passer au sein de la Société Autoliv.

Tout d’abord, je tiens à exprimer ma gratitude envers ALLAH le tout puissant, qui m’a
aordé sa grâce et sa bénédiction pour mener à bien c projet.

Je voudrais adresser toute ma reconnaissance à mon encadrant pédagogique Monsieur

Sofien Marzouki
pour sa patience, sa disponibilité et surtout ses judicieux conseils,qui ont contribué à
alimenter ma réflexion, pour sa confiance et son soutien inestimable.
Avec beaucoup d’égard, je ne manquerai pas de remercier
Madame haifa ben Romdhane
,responsable ressources humaines, pour l’accueil chaleureux qu’elle m’a réservé et ses
précieux conseils.

Je souhaite exprimer ma profonde gratitude envers

M. Seif Eddine Marzouki et M. Aymen ABDALLAH,
pour leur persévérance à partager leur expertise et leurs recommandations m’a été ex-
trêmement bénéfique. Leur volonté inébranlable de me soutenir et de me guider dans mes
choix et mes actions témoigne de leur dévouement remarquable.

Ben salah samar

i
 Dédicace
Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considéra-
tion pour les sacrifices que tu as consenti pour mon instruction et mon bien être. Je te re-
mercie pour m’avoir soutenue, et pour m’avoir encouragée pendant toutes ces années. Que
ce travail soit le fruit de tes innombrables sacrifices. Que dieux accorder santé, bonheur el
longue vie mon chère mère et pére "Rebah" et "Sahbii".

À ms sœurs "Sarra" et "Sanna", Qu c travail soit un modst témoignag, fait pour qu vous
soyz fièr d moi.

À mes frères Med "Sofien" et "koussay" Je tiens à exprimer ma gratitude pour votre gé-
nérosité, votre attention et votre soutien précieux lors des moments importants de ma vie.

A mes amies, Je ne peux trouver les mots justes et sincères pour vous exprimer mon
affection et mes pensées, vous êtes pour moi des sœurs et des amies sur qui je peux compter.
En témoignage de l’amitié qui nous unit et des souvenirs de tous les moments que nous
avons passés en- semble, je vous dédie ce travail et je vous souhaite une vie pleine de santé
et de bonheur.

A tous ceux qui ont cru en moi, Pour m’avoir donné le courage de continuer.

ii
 Table des matières

1 Présentation du cadre de projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation d’AUTOLIV Steering Wheels Tunisia . . . . . . . . . . . 3
1.2.2 ASWT filiale d’AUTOLIV Isodelta . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 L’activité d’ASWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Les partenaires d’ASWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Les principaux clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 L’usine d’ASWT ENNADHOUR . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Structure et organigramme de AUTOLIV . . . . . . . . . . . . . . . . . 5
1.5 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Méthodologies et modélisme adopté . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.1 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.2 Objectifs de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.3 Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Comparaison de méthodologie traditionnelle et méthodologie agile . 8
1.7.2 Justification du choix de la méthode . . . . . . . . . . . . . . . . . . . . 9
1.7.3 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.4 Les artefacts de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.5 Les rôles de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Chapitre 2 : Sprint 0 : Etude préliminaire 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Détail fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . 13
2.4.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Equipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Structure et planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Architecture de la solution : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.1 Environement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.2 Environement développement . . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii
0 TABLE DES MATIÈRES

3 Mise en oeuvre de sprint 1 26

3.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Diagramme de cas d’utilisation de sprint 1 . . . . . . . . . . . . . . . . 27
3.3 Description textuelle et raffinement des principaux cas d’utilisation . . . . . . 28
3.3.1 Raffinement du cas d’utilisation "S’authentifier" . . . . . . . . . . . . . 28
3.3.2 Description textuelle de cas d’utilisation « S’authentifier» . . . . . . . 28
3.3.3 Raffinement du cas d’utilisation "Gérer les utilisateurs" . . . . . . . . . 29
3.3.4 Description textuelle du cas d’utilisation"Ajouter utilisateur" . . . . . 30
3.3.5 Description textuelle des cas d’utilisation "Supprimer utilisateur" . . . 31
3.3.6 Description textuelle du cas d’utilisation "Modifier utilisateur" . . . . 32
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Diagramme de classe du premier sprint . . . . . . . . . . . . . . . . . . 33
3.4.2 Modèle relationnel du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . 34
3.4.4 Diagramme de séquence lié à la fonctionnalité « S’authentifier » . . . . 34
3.4.5 Diagramme de séquence «Ajouter utilisateur» pour l’administrateur . 36
3.4.6 Diagramme de séquence «Supprimer utilisateur »pour l’administrateur 36
3.4.7 Diagramme de séquence «Modifier utilisateur »pour l’administrateur 37
3.5 Test et validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.2 Interface de gestion l’utilisateurs . . . . . . . . . . . . . . . . . . . . . . 40
3.6.3 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . 41
3.6.4 Interface modifier un utilisateur . . . . . . . . . . . . . . . . . . . . . . 41
3.6.5 Interface de suppression d’un utilisateur . . . . . . . . . . . . . . . . . 42
3.7 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Mise en oeuvre de sprint 2 43

4.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Diagramme de cas d’utilisation de sprint 2 . . . . . . . . . . . . . . . . 45
4.3 Description textuelle et raffinement des principaux cas d’utilisation . . . . . . 46
4.3.1 Raffinement du cas d’utilisation "Consulter les productions" . . . . . . 46
4.3.2 Description textuelle du cas d’utilisation"Consulter les productions" . 46
4.3.3 Raffinement du cas d’utilisation "Gérer les productions" . . . . . . . . 47
4.3.4 Description textuelle du cas d’utilisation"Ajouter production " . . . . . 47
4.3.5 Description textuelle des cas d’utilisation "Supprimer production" . . 48
4.3.6 Description textuelle du cas d’utilisation "Modifier production" . . . . 49
4.3.7 Raffinement du cas d’utilisation "Gérer les produits" . . . . . . . . . . 51
4.3.8 Description textuelle du cas d’utilisation"Ajouter produit" . . . . . . . 51
4.3.9 Description textuelle des cas d’utilisation "Supprimer produit" . . . . 52
4.3.10 Description textuelle du cas d’utilisation "Modifier produit" . . . . . . 53
4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.1 Diagramme de classe du deuxiéme sprint . . . . . . . . . . . . . . . . . 55
4.4.2 Modèle relationnel du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 56
4.5 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.1 Diagramme de séquence «Consulter les productions» pour Supervi-
seur générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

iv
0 TABLE DES MATIÈRES

4.5.2 Diagramme de séquence «Ajouter production » pour Responsable pro-

duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.3 Diagramme de séquence «Supprimer production » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5.4 Diagramme de séquence «Modifier production » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.5 Diagramme de séquence «Ajouter produit » pour Responsable pro-
duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.6 Diagramme de séquence «Supprimer produit » pour Responsable pro-
duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.7 Diagramme de séquence «Modifier produit » pour Responsable pro-
duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Test et validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7.1 Interface de gestion des productions . . . . . . . . . . . . . . . . . . . . 64
4.7.2 Interface ajouter production . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.7.3 Interface modifier production . . . . . . . . . . . . . . . . . . . . . . . . 65
4.7.4 Interface de suppression production . . . . . . . . . . . . . . . . . . . . 66
4.7.5 Interface ajouter produit . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.7.6 Interface modifier produit . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7.7 Interface de suppression produit . . . . . . . . . . . . . . . . . . . . . . 68
4.8 Conclustion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Mise en oeuvre de sprint 3 69

5.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Spécification fonctionnelle : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Diagramme des cas d’utilisation de sprint 3 . . . . . . . . . . . . . . . . 71
5.4 Description textuelle et raffinement des principaux cas d’utilisation . . . . . . 72
5.4.1 Raffinement de cas d’utilisation «Gérer les Clients »pour l’acteur «
Responsable vente» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.2 Description textuelle du cas d’utilisation"Ajouter Client" . . . . . . . . 72
5.4.3 Description textuelle des cas d’utilisation "Supprimer client" . . . . . . 73
5.4.4 Description textuelle du cas d’utilisation "Modifier client" . . . . . . . 74
5.4.5 Raffinement de cas d’utilisation «Gérer les commandes »pour l’acteur
" Responsable vente" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.6 Description textuelle du cas d’utilisation"Ajouter Commande" . . . . . 76
5.4.7 Description textuelle des cas d’utilisation "Supprimer commande" . . 77
5.4.8 Description textuelle du cas d’utilisation "Modifier commande" . . . . 78
5.4.9 Diagramme du cas d’utilisation « visualiser tableau de bord» . . . . . 79
5.4.10 Description textuelle du cas d’utilisation "visualiser les nombres des
productions" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5.1 Diagramme de classe du troisiéme sprint . . . . . . . . . . . . . . . . . 81
5.5.2 Modèle relationnel du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6.1 Diagramme de séquence «Ajouter client» pour Responsable vente . . 83
5.6.2 Diagramme de séquence « Supprimer client » pour Responsable vente 83
5.6.3 Diagramme de séquence « Modifier client » pour Responsable vente . 84

v
0 TABLE DES MATIÈRES

5.6.4 Diagramme de séquence «Ajouter commande» pour Responsable vente

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.6.5 Diagramme de séquence « Supprimer commande » pour Responsable
vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6.6 Diagramme de séquence « Modifier commande » pour Responsable
vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.6.7 Diagramme de séquence « visualiser les nombres des productions » . 88
5.7 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.8 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.1 Interface gestion des clients . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.2 Interface ajouter client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.8.3 Interface modifier client . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.8.4 Interface de suppression client . . . . . . . . . . . . . . . . . . . . . . . 92
5.8.5 Interface gestion des commandes . . . . . . . . . . . . . . . . . . . . . . 92
5.8.6 Interface ajouter commande . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.8.7 Interface modifier commande . . . . . . . . . . . . . . . . . . . . . . . . 93
5.8.8 Interface de suppression commande . . . . . . . . . . . . . . . . . . . . 94
5.8.9 Interface Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

vi
 Table des figures

1.1 logo de Société AUTOLIV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Les principaux clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Organigrame de société AUTOLIV . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme du cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Méthode Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Organigramme des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 ARCHITECTURE 3 TIERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Modele MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Modele MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9 Logo Node js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.10 Logo HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.11 Logo Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.12 Logo TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.13 Logo Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.14 Logo eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.15 Logo Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.16 Logo MYSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.17 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.18 Logo spring boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.19 Logo Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.20 Logo StarUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.21 Logo [Link] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Diagramme de cas d’utilisation globale de sprint 1 . . . . . . . . . . . . . . . . 27

3.2 Raffinement de cas d’utilisation «S’authentifier» . . . . . . . . . . . . . . . . . 28
3.3 Raffinement du cas d’utilisation "gérer les utilisateur" . . . . . . . . . . . . . . 29
3.4 Diagramme de classes du premier sprint . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Diagramme de séquence «s’authentifier» . . . . . . . . . . . . . . . . . . . . . 35
3.6 Diagramme de séquence «Ajouter utilisateur» . . . . . . . . . . . . . . . . . . 36
3.7 Diagramme de séquences «Supprimer utilisateur» . . . . . . . . . . . . . . . . 37
3.8 Diagramme de séquences «Modifier utilisateur» . . . . . . . . . . . . . . . . . 38
3.9 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.10 Email qui permet de l’accès au notre plateformer . . . . . . . . . . . . . . . . . 40
3.11 Interface de gestion l’utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.12 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.13 Interface modifier d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.14 Interface suppression d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Diagramme de cas d’utilisation globale de sprint 2 . . . . . . . . . . . . . . . . 45

4.2 Raffinement de cas d’utilisation «Consulter les productions» . . . . . . . . . . 46
4.3 Raffinement de cas d’utilisation «Gérer les productions» . . . . . . . . . . . . 47
4.4 Raffinement de cas d’utilisation «Gérer les produits» . . . . . . . . . . . . . . 51
4.5 Diagramme de classe du deuxiéme sprint . . . . . . . . . . . . . . . . . . . . . 55

vii
0 TABLE DES FIGURES

4.6 Diagramme de séquences «Consulter les productions» . . . . . . . . . . . . . 56

4.7 Diagramme de séquences «Ajouter production» . . . . . . . . . . . . . . . . . 57
4.8 Diagramme de séquences «Supprimer production» . . . . . . . . . . . . . . . 58
4.9 Diagramme de séquences «Modifier production» . . . . . . . . . . . . . . . . . 59
4.10 Diagramme de séquences «Ajouter produit» . . . . . . . . . . . . . . . . . . . 60
4.11 Diagramme de séquences «Supprimer produit» . . . . . . . . . . . . . . . . . 61
4.12 Diagramme de séquences «Modifier produit» . . . . . . . . . . . . . . . . . . . 62
4.13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.14 Interface d’ajout production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.15 Interface modifier production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.16 Interface suppression d’un production . . . . . . . . . . . . . . . . . . . . . . . 66
4.17 Interface ajouter produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.18 Interface modifier produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.19 Interface suppression produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.1 Diagramme de cas d’utilisation global du sprint 3 . . . . . . . . . . . . . . . . 71

5.2 Raffinement du cas d’utilisation"Gérer les Clients". . . . . . . . . . . . . . . . . 72
5.3 Raffinement du cas d’utilisation"Gérer les commandes". . . . . . . . . . . . . . 76
5.4 Raffinement du cas d’utilisation"Visualiser tableau de bord". . . . . . . . . . . 80
5.5 Diagramme de classes du troisiéme sprint . . . . . . . . . . . . . . . . . . . . . 81
5.6 Diagramme de séquences «Ajouter Client» . . . . . . . . . . . . . . . . . . . . 83
5.7 Diagramme de séquences «Supprimer Client» . . . . . . . . . . . . . . . . . . 84
5.8 Diagramme de séquences «Modifier Client» . . . . . . . . . . . . . . . . . . . . 85
5.9 Diagramme de séquences «Ajouter Commande» . . . . . . . . . . . . . . . . . 86
5.10 Diagramme de séquences «Supprimer Commande» . . . . . . . . . . . . . . . 87
5.11 Diagramme de séquences «Modifier Commande» . . . . . . . . . . . . . . . . 88
5.12 Diagramme de séquences «Visualiser les nombres des productions» . . . . . . 88
5.13 Interface gestion des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.14 Interface d’ajout client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.15 Interface modifier client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.16 Interface suppression d’un client . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.17 Interface gestion des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.18 Interface d’ajout commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.19 Interface modifier client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.20 Interface suppression d’un commande . . . . . . . . . . . . . . . . . . . . . . . 94
5.21 Interface Tablau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

viii
 Liste des tableaux

1.1 Tableau comparatif Méthodologie de développement. . . . . . . . . . . . . . 9

2.1 Backlog product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Description textuelle du cas d’utilisation "S’authentifier" . . . . . . . . . . . . 29
3.3 Description textuelle du cas d’utilisation "Ajouter Utilisateur" . . . . . . . . . 31
3.4 Description textuelle du cas d’utilisation "Supprimer utilisateur" . . . . . . . . 32
3.5 Description textuelle du cas d’utilisation "Modifier utilisateur" . . . . . . . . . 33
3.6 Modèle relationnel du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7 Tests et résultats de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Description textuelle du cas d’utilisation "Consulter les Productions" . . . . . 47
4.3 Description textuelle du cas d’utilisation "Ajouter Production" . . . . . . . . . 48
4.4 Description textuelle du cas d’utilisation "Supprimer production" . . . . . . . 49
4.5 Description textuelle du cas d’utilisation "Modifier production" . . . . . . . . 50
4.6 Description textuelle du cas d’utilisation "Ajouter Produit" . . . . . . . . . . . 52
4.7 Description textuelle du cas d’utilisation "Supprimer produit" . . . . . . . . . 53
4.8 Description textuelle du cas d’utilisation "Modifier produit" . . . . . . . . . . 54
4.9 Modèle relationnel du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.10 Tests et résultats de sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2 Description textuelle du cas d’utilisation "Ajouter client" . . . . . . . . . . . . 73
5.3 Description textuelle du cas d’utilisation "Supprimer client" . . . . . . . . . . 74
5.4 Description textuelle du cas d’utilisation "Modifier client" . . . . . . . . . . . . 75
5.5 Description textuelle du cas d’utilisation "Ajouter commande" . . . . . . . . . 77
5.6 Description textuelle du cas d’utilisation "Supprimer commande" . . . . . . . 78
5.7 Description textuelle du cas d’utilisation "Modifier commande" . . . . . . . . 79
5.8 Description textuelle du cas d’utilisation "Modifier commande" . . . . . . . . 80
5.9 Modèle relationnel du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.10 Tests et résultats de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

ix
 Introduction générale
Aujourd’hui, grâce au développement des nouvelles technologies de l’information et de
la communication, rares sont les personnes qui nient que la digitalisation des documents
et la diffusion de l’information en mode numérique améliorent la flexibilité et l’agilité des
entreprises.

Mon stage a été effectué chez Autolive, plus précisément au service de production. Cette
entreprise a décidé d’abandonner le mode archaïque de gestion manuelle des processus de
production et a choisi d’investir dans des solutions informatiques permettant à chaque em-
ployé de faciliter le suivi des productions . Cela rend le travail plus structuré et dynamique.
C’est dans ce contexte qu’il m’a été demandé de créer une application web pour le suivi des
productions, et c’est dans ce cadre que mon Rapport PFE a été réalisé. Ce rapport est divisé
en cinq chapitres montrant les différentes étapes de réalisation de ce projet.

Le premier chapitre place le projet dans le contexte général de l’organisme d’accueil. Il

présente une critique de l’existant, la solution proposée, ainsi que la spécification de la mé-
thodologie adaptée.

Le deuxième chapitre dévoile les besoins de l’entreprise, définit le backlog du produit et

complète la planification du sprint.

Le troisième chapitre se concentre sur l’analyse, la conception et la réalisation du "Sprint

1", tandis que les deux autres chapitres se concentrent sur l’analyse, la conception et la réa-
lisation des autres sprints du projet.
La dernière partie du rapport est consacrée aux conclusions générales, résumant les princi-
pales caractéristiques de ce travail et présentant les perspectives futures d’amélioration de
la plateforme développée.

1
 C HAPITRE 1
Présentation du cadre de projet

Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Présentation d’AUTOLIV Steering Wheels Tunisia . . . . . . . . . . 3
1.2.2 ASWT filiale d’AUTOLIV Isodelta . . . . . . . . . . . . . . . . . . . . 3
1.2.3 L’activité d’ASWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Les partenaires d’ASWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Les principaux clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 L’usine d’ASWT ENNADHOUR . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Structure et organigramme de AUTOLIV . . . . . . . . . . . . . . . . 5
1.5 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Méthodologies et modélisme adopté . . . . . . . . . . . . . . . . . . . . . . 6
1.6.1 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.2 Objectifs de l’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.3 Diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Comparaison de méthodologie traditionnelle et méthodologie agile 8
1.7.2 Justification du choix de la méthode . . . . . . . . . . . . . . . . . . . 9
1.7.3 La méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.4 Les artefacts de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.5 Les rôles de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2
1 1.1. INTRODUCTION

1.1 Introduction
Ce premier chapitre a pour objectif de mettre le projet dans son cadre général. Il consiste
à présenter, en premier temps, son environnement à travers une présentation de l’entreprise
d’accueil et ses domaines d’activités et en second lieu, nous présenterons notre projet ainsi
que la méthodologie de réalisation adoptée.

1.2 Présentation de l’organisme d’accueil

Nous présentons dans ce qui suit l’organisme d’accueil dans lequel s’est déroulé notre
stage au sein de société AUTOLIV

1.2.1 Présentation d’AUTOLIV Steering Wheels Tunisia

1.2.2 ASWT filiale d’AUTOLIV Isodelta
AUTOLIV est une entreprise multinationale Franco-suédoise active sur le marché in-
ternational. La double mission d’AUTOLIV est de réduire considérablement les accidents
automobiles dans le monde et les blessures qui en résultent, et cela en créant, fabriquant et
commercialisant des produits et systèmes de sécurité.

AUTOLIV est créé en 1958, elle s’est progressivement mondialisée. Aujourd’hui, elle est
présentée dans 30 pays et emploie plus de 64 000 personnes sur les 5 continents.

AUTOLIV est le premier producteur mondial d’airbags, ceintures de sécurité, des vo-
lants, de l’électronique de sécurité passive et des systèmes de sécurité active tels que les
systèmes radar, la vision nocturne et de la vision de la caméra.

AUTOLIV s’est installée en TUNISIE en 1998 à ELNNADHOUR et El FAHS.

AUTOLIV Steering Wheels Tunisia est une filiale d’AUTOLIV Isodelta qui est une unité
de fabrication et de développement du groupe AUTOLIV. Tous les sites mis en place en
Tunisie sont spécialisés dans la fabrication des volants de direction à savoir gainage, mous-
sage,assemblage et coupe.
[<empty citation>]

F IGURE 1.1 – logo de Société AUTOLIV

3
1 CHAPITRE 1. PRÉSENTATION DU CADRE DE PROJET

1.2.3 L’activité d’ASWT

L’activité principale de l’organisation ASWT concerne l’industrialisation, et la commer-
cialisation des volants, des pommeaux, des soufflets de vitesse, gaines et armatures mous-
sées.

En effet, le site ASWT à Nadhour permet l’industrialisation, la production, la livraison et

les prestations associées de volants de direction pour l’industrie [Link] prenant le
volant, le rôle d’un individu passe d’un simple admirateur d’un véhicule à celui qui contrôle,
y compris l’énorme responsabilité d’avoir la vie des autres entre ses mains.

ASWN fabrique des volants qui sont extrêmement conçus pour garantir qu’ils répondent
aux exigences de sécurité et sont fonctionnels et élégants. Pour améliorer leur apparence et
leur sensation, les volants peuvent être recouverts de cuir ou de bois.

La housse en cuir est fabriquée à la main et un opérateur peut prendre jusqu’à une heure
pour coudre et coller le cuir sur un volant en mousse.

1.3 Les partenaires d’ASWT

1.3.1 Les principaux clients
Sur le marché de la construction des groupements automobile, AUTOLIV parmi les lea-
ders au niveau mondial grâce au rapport de qualité et le prix qu’elles offrent. Elle compte,
parmi ses clients, des sociétés de classe mondiale. Et voici quelques clients d’AUTOLIV pré-
sentés dans figure 1,2 ci-dessous :

F IGURE 1.2 – Les principaux clients

Grace aux innovations successives faites par le groupe Autoliv au profit de ses clients ainsi
que ses objectifs de sauver la vie des gens et assurer la sécurité, Autoliv est chargée de
mener des actions pour la protection des hommes (améliorer les conditions de conduire
pour réduire le nombre d’accidents).

4
1 1.4. L’USINE D’ASWT ENNADHOUR

1.4 L’usine d’ASWT ENNADHOUR

ASWT ENNADHOUR (une filiale du groupe ASWT) est une société totalement exporta-
trice qui produit des volants de direction pour divers clients de renommée internationale.

ASWT ENNADHOUR comporte deux ateliers dont chacune possède une tache spéci-
fique :

L’atelier ASWT3 : est un atelier d’injection.

L’atelier ASWT2 : est un atelier de gainage et d’assemblage.
Zone de coupe : coupe du cuir et de la mousse L’atelier ASWT3 produit des volants moussés
qui seront gainés au niveau de l’atelier ASWT2 ou bien expédiés directement à d’autres
usines d’AUTOLIV,

1.4.1 Structure et organigramme de AUTOLIV

Autoliv, en tant que leader dans l’industrie de la fabrication de volants, occupe une po-
sition cruciale dans la production et l’optimisation de ses produits.
Les volants, qui sont essentiels à la sécurité des voitures, sont essentiellement garantis par
le société.
Examinons de près la structure organisationnelle d’Autoliv, illustrée par son organigramme,
afin de mieux comprendre l’organisation interne et les processus qui sous-tendent cette réus-
site.

F IGURE 1.3 – Organigrame de société AUTOLIV

5
1 CHAPITRE 1. PRÉSENTATION DU CADRE DE PROJET

1.5 Présentation du Projet

Une application que nous développons actuellement vise à simplifier et à automatiser la
suivre et vente de la gestion des productions de notre entreprise. Cette application fournira
des fonctionnalités importantes telles que la visualisation des opérations de production et
de vente et la comparaison quotidienne de la liste des produits entre l’usine. Notre objectif
est de fournir une solution solide et efficace pour optimiser la gestion de la produc- tion,
permettant une utilisation plus fluide des ressources et une prise de décision éclairée pour
améliorer les performances globales de l’entreprise

1.5.1 Étude de l’existant

La gestion des services Internet fournis par Autoliv aux établissements soumis à la suivre
la production et vente tard pour ne pas prendre de décision rapidement . Sans tirer parti
des avantages de la technologie moderne pour simplifier leurs démarches et améliorer leur
communica- tion électronique, les institutions risquent de ne pas optimiser leur efficacité. Il
est crucial de reconnaître les avantages de l’utilisation des services Internet pour simplifier
les proces- sus administratifs et améliorer la rapidité et l’efficacité des services rendus. De
plus, des recommandations doivent être fournies pour améliorer l’utilisation efficace de ces
services et garantir une sécurité adéquate des données et des informations.

1.5.2 Solution proposée

Nous proposons de concevoir et développer une application permettant gestion de suivi
les productions et les ventes par Autoliv :

L’application doit Assurer les fonctions suivantes :

— La gestion des utilisateurs.
— La gestion des productions journalaire.
— l’automatisation des processus de production.
— la gestion automatisée des demandes et des autorisations.
— L’établissement des statistiques, et des tableaux de bord décisionnels.

1.6 Méthodologies et modélisme adopté

1.6.1 Langage de modélisation
Dans divers domaines, différents langages de modélisation sont utilisés pour décrire et
transmettre des concepts, des systèmes et des processus. Nous avons choisi l’UML (Uni-
fied Modeling Language), un langage graphique de modélisation largement utilisé dans le
domaine du développement logiciel, pour notre projet. Il représente, spécifie, visualise et
documente les systèmes logiciels.

6
1 1.6. MÉTHODOLOGIES ET MODÉLISME ADOPTÉ

Définition d’UML (Unified Modeling language) :

Le langage de modélisation visuelle connu sous le nom de ML est largement utilisé dans
les domaines du génie logiciel et du développement de systèmes d’information. Il fournit
un ensemble de notation graphique standardisée qui permet aux développeurs, architectes
logiciels et autres professionnels de la conception de visualiser, spécifier, construire et docu-
menter les artefacts d’un système logiciel.[6]

F IGURE 1.4 – UML

UML propose une variété de diagrammes organisés en deux catégories de perspectives, les
perspectives statiques et les perspectives dynamiques.

* Les perspectives statiques comprennent :

— Le diagramme des cas d’utilisation : décrivent le comportement et les fonctions d’un
système du point de vue de l’utilisateur.
— Le diagramme de classes : décrivent la structure statique, les types et les relations des
ensembles d’objets
— Le diagramme de déploiement : décrivent la répartition des programmes exécutables
sur les différents matériels
— Les diagrammes d’objets : décrivent les objets d ’un système et leurs relations

* Les perspectives dynamiques comprennent :

— Le diagramme d’activités : Il représente graphiquement les flux de travail d’entreprise
ou opérationnels afin de montrer l’activité de chacun des composants du système.
— Le diagramme de séquence : décrivent de manière temporelle les interactions entre
objets et acteur.

1.6.2 Objectifs de l’UML

1. Fournir une notation graphique commune.
2. Soutenir la modélisation des systèmes complexes.
3. Présenter les conceptions proposées et communiquer avec les parties prenantes.
4. Comprendre les exigences.

7
1 CHAPITRE 1. PRÉSENTATION DU CADRE DE PROJET

1.6.3 Diagrammes UML

— Diagramme des cas d’utilisation
— Diagramme de séquence
— Diagramme des composants
— Diagramme de classe
— Diagramme d’activité
— Diagramme de collaboration
— Diagramme de déploiement
— Diagramme d’état

1.7 Méthodologie de développement

Une méthodologie de développement est un ensemble de pratiques, de principes et de
processus utilisés pour gérer et organiser efficacement le développement de logiciels ou de
projets informatiques. Elle fournit un cadre structuré pour planifier, exécuter, contrôler et
livrer des résultats de manière cohérente.

1.7.1 Comparaison de méthodologie traditionnelle et méthodologie agile

Dans cette section nous allons comparer la méthode traditionnelle avec la méthode agile
à l’aide du tableau suivant :
Méthode Agile Méthodes Traditionnelles (cascade)

— Toute approche Agile organise le — Le processus de développement du

cycle de vie du développement du projet est divisé en phases / sé-
projet en sprints et suit une ap- quences distinctes .
proche incrémentale.

— La méthodologie Agile est connue — La méthode traditionnelle ou en

pour sa flexibilité. cascade est un processus de concep-
tion séquentielle .

— Le plan de test est revu après — Toutes les phases de développe-

chaque sprint . ment du projet telles que la concep-
tion, développement, les tests, etc...
Sont réalisées une seule fois dans le
modèle Waterfall .

8
1 1.7. MÉTHODOLOGIE DE DÉVELOPPEMENT

— Les membres de l’équipe Agile sont — Dans la méthode en cascade, le pro-

interchangeables, par conséquent, cessus est toujours simple, le chef
ils travaillent plus rapidement. Il de projet joue donc un rôle essentiel
n’y a pas non plus besoin de chefs à chaque étape .
de projet car les projets sont gérés
par toute l’équipe .

— Le Product Owner, avec équipe, — Le business case prépare les exi-

prépare les exigences tous les jours gences avant le début du projet .
durant un projet .

TABLE 1.1: Tableau comparatif Méthodologie de déve-

loppement.

1.7.2 Justification du choix de la méthode

On a choisi la méthodologie Agile car Une méthodologie agile prévoit la fixation d’ob-
jectifs à court terme utilisés dans la gestion de projets Alors que la méthode traditionnelle
prévoit la planification totale du projet avant même la phase développement .

1.7.3 La méthode SCRUM

Scrum est un framework ou cadre de développement de produits complexes. Il est défini
par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts
communs en livrant de manière productive et créative des produits de la plus grande valeur
possible ». Scrum est considéré comme un groupe de pratiques répondant pour la plupart
aux préconisations du manifeste agile.

1.7.4 Les artefacts de SCRUM

Les artefacts de SCRUM sont spécialement conçus pour maximiser la transparence d’in-
formations essentielles afin que tous en aient la même compréhension. Les artefacts de
SCRUM sont :

— Backlog produit : est une liste de nouvelles fonctionnalités, améliorations, corrections

de bugs, tâches ou exigences métier nécessaires à la conception d’un produit. Il re-
groupe différentes sources telles que le support client, l’analyse des concurrents, les
demandes du marché et l’analyse commerciale générale.
— Backlog de sprint : est un ensemble de tâches du backlog produit qui ont été mises en
avant pour être développées durant le prochain incrément de produit. Les backlogs de
sprint sont créés par l’équipe de développement pour planifier des livrables pour de

9
1 CHAPITRE 1. PRÉSENTATION DU CADRE DE PROJET

futurs incréments et préciser le travail nécessaire à la création de cet incrément.

1.7.5 Les rôles de SCRUM

Product Owner : Le chef de projet, pour le compte du client, qui est responsable de la spé-
cification fonctionnelle, établissant une liste prioritaire de ce qui doit être développé et en
assurant la validation.
Scrum master : Le chef d’équipe qui assure une bonne communication avec l’équipe de
développement dans le cadre du projet informatique.
L’équipe de développement : C’est l’équipe qui définit les "User Stories", qui sont Un objec-
tif commun pour l’achèvement du sprint et pour s’assurer qu’un incrément est livré à la fin
de chaque sprint.
L’architecture de l’application se réfère à la conception globale de l’application, qui in-
clut les choix de technologie, les choix d’infrastructure, la structure des données, la logique
métier, etc. Elle décrit comment les différentes composantes de l’application sont organi-
sées et interagissent les unes avec les autres pour répondre aux besoins fonctionnels et non-
fonctionnels de l’application. Une architecture bien conçue peut rendre une application plus
facile à maintenir, à évoluer et à déployer.

1.8 Conclusion :
Dans ce chapitre nous avons mis notre projet dans son cadre en précisant son environ-
nement et en commençant par l’introduction de l’organisme d’accueil avec une présenta-
tion détaillée de ses différents services et de sa clientèle. Ensuite, nous avons présenté la
problématique ainsi que la solution proposée. Puis, nous avons justifié nos choix pour la
méthodologie du travail.

10
 C HAPITRE 2
Chapitre 2 : Sprint 0 : Etude préliminaire

Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Détail fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . 13
2.4.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Equipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Structure et planification des sprints . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Architecture de la solution : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.1 Environement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.2 Environement développement . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

11
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

2.1 Introduction
Le but principal de ce deuxième chapitre est de garantir un démarrage optimal du projet
dans les conditions les plus optimales. Au cours de ce chapitre, nous allons d’abord identifier
nos acteurs, puis nous allons énumérer en détail les besoins fonctionnels et non fonctionnels.
Ensuite, nous allons expliquer en détail la gestion du projet avec SCRUM et nous allons
exposer le schéma de cas d’utilisation global. De plus, dans ce chapitre, nous allons don-
ner des détails sur l’architecture du système employé et Nous concluons par le backlog du
produit afin de déterminer toutes les fonctionnalités du produit que nous souhaitons créer.

2.2 Identification des acteurs

Les différents acteurs de notre système se répartissent en trois acteurs principales comme
suit :
Superviseure Générale : Le Superviseur Général joue un rôle essentiel dans la consultation
de la production au sein de la société industrielle En surveillant jounaliaux les processus, en
évaluant les rendements et en prenant des décisions pour améliorer l’ef- ficacité et la qualité.
Il travaille en étroite collaboration avec les équipes de production pour s’assurer que les
objectifs sont conformes aux normes de l’entreprise et que les protocoles sont respectés.
Administrateur : L’administrateur est une personne chargée de gérer les comptes d’utilisa-
teurs dans un système informatique.
Responsable Production : pour mission superviser, planifier et optimiser Le processus de
production, tout comme la détection proactive des erreurs et la garantie de normes de qualité
élevées.
Responsable vente : est chargé de superviser les activités de vente, de coordonner les
équipes commerciales et de maintenir des relations positives avec les clients.

2.3 Identification des besoins

En vue d’atteindre notre objectif, qui consiste à concevoir et développer l’application
précédemment décrite, nous allons tout d’abord identifier les acteurs ainsi que les besoins
fonctionnels et non fonctionnels.

2.3.1 Besoins fonctionnels

Les besoins fonctionnels expriment les fonctionnalités du futur système. Nous listons,
ci-dessous, les fonctionnalités de notre système par acteur .
Superviseur Général : le superviseur générale est accès aux données de production en pour
consultation et il faut avoir la capacité pouvoir surveiller les activités des l’entreprise afin
d’évaluer les résultats.
Administrateurs : gestion efficace des comptes d’utilisateurs.
Responsable Vente :
le responsable vente a accès aux données clients pour gérer les relations client et Capacité
à gérer des rapports sur les performances des commandes.
Responsable Production : le responsable production a accès aux données de production
pour générer des rapports et Capacité à suivre le processus de production pour identifier les
problèmes potentiels.

12
2 2.4. DÉTAIL FONCTIONNEL

2.3.2 Besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes techniques et ergonomiques
auxquelles est soumise l’application pour sa réalisation et pour son bon fonctionnement.[4]
Les principaux besoins non fonctionnels de notre application sont :
La sécurité : l’application doit fournir le critère de protection des données clients, en parti-
culier en ce qui concerne l’authentification. Afin de surmonter ces difficultés, nous limitons
l’accès à ces informations à l’administrateur.
Facilité de d’utilisation : l’application doit être intuitive et facile à utiliser pour tous les
utilisateurs.
La fiabilité : il est essentiel que le système fonctionne sans problème dans des conditions
particulières.
La convivialité :la première interaction de l’utilisateur avec l’application se fait via l’inter-
face. Ainsi, elle devrait être facile, transparente et conviviale.
La performance : il est essentiel que l’application assure le critère de performance et réagisse
rapidement, peu importe l’action de l’utilisateur.
La maintenance : Il est essentiel de maintenir l’application pour garantir sa progression
rapide.

2.4 Détail fonctionnel

2.4.1 Diagramme de cas d’utilisation général
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d’un système logiciel. Ils sont utiles pour des
présentations auprès de la direction ou des acteurs d’un projet. Mais pour le développement,
les cas d’utilisation sont plus appropriés .
L’objectif principal de ce diagramme est l’énumération des différents cas d’utilisation en
précisant les relations des acteurs ainsi que leurs tâches dans notre application. La figure
2.1, représente le diagramme de cas d’utilisation général de notre application.

13
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

F IGURE 2.1 – Diagramme du cas d’utilisation général

2.4.2 Diagramme de classe global

Un diagramme de classes est un diagramme utilisé dans les logiciels pour représen- ter
les classes et les interfaces et leurs relations. Ce diagramme fait partie de la partie
statique d’UML, ne se concentrant pas sur les aspects temporels et dynamiques. Une
classe décrit les responsabilités, le comportement et le contrôle d’un ensemble d’ob- jets.
Les éléments de cet ensemble sont des instances de la classe. Une classe est une collection
de fonctions et est liée entre elles par un champ sémantique. Les classes sont
utilisées dans la programmation orientée objet. Ils permettent de modéliser un pro- gramme
et autres pour une tâche complexe en un certain nombre de petits travaux
simples.

14
2 2.5. PILOTAGE DU PROJET AVEC SCRUM

F IGURE 2.2 – Diagramme de classe global

2.5 Pilotage du projet avec SCRUM

Nous allons présenter dans cette section, les outils de SCRUM, l’équipe de travail ainsi
que leurs rôles et le product backlog .

2.5.1 Equipe et rôles

Scrum est constituée d’un propriétaire de produit, de l’équipe de développement et d’un
Scrum Master. Nous présentons dans cette partie l’ensemble des acteurs participants au dé-
roulement des différentes phases du projet et d’élaboration du rapport du stage. Dans notre
cas, l’équipe de développement est constituée La méthodologie SCRUM fait intervenir trois
rôles principaux qui sont :
Scrum définit essentiellement trois rôles distincts :

Product Owner : Le chef de projet, pour le compte du client, qui est responsable de la spé-
cification fonctionnelle, établissant une liste prioritaire de ce qui doit être développé et en
assurant la validation.
Scrum master : Le chef d’équipe qui assure une bonne communication avec l’équipe de
développement dans le cadre du projet informatique ‘
L’équipe de développement : C’est l’équipe qui définit les "User Stories", qui sont Un objec-
tif commun pour l’achèvement du sprint et pour s’assurer qu’un incrément est livré à la fin
de chaque sprint.

15
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

F IGURE 2.3 – Méthode Scrum

2.6 Structure et planification des sprints

près avoir défini le backlog du produit, nous découpons notre projet en des sprints. Le
sprint comporte les tâches d’analyses, de conception, de développement et de tests. Nous
allons établir la planification du projet en 3 sprints. Chaque sprint peut durer de 4 à 5 se-
maines.

F IGURE 2.4 – Organigramme des taches

2.7 Backlog produit

16
2 2.7. BACKLOG PRODUIT

Le backlog de produit :
se présente comme la colonne vertébrale de tout projet mené selon la méthode agile,
incarnant une vision stratégique et détaillée des fonctionnalités à implémenter pour réaliser
les objectifs fixés. Ce tableau montre les différentes tâches à réaliser dans notre projet avec
une description. Nous avnons aussi affecté une priorité selon l’importance de la réalisation.
— sprint : Un sprint désigne le cycle de développement pendant lequel vont s’enchaîner
un certain nombre de tâches pour, à terme, arriver à la conception d’un produit final.
— user story : est la carte d’identité des fonctionnalités à développer. Savoir la rédiger est
une des compétences clés de l’application de la méthode agile.
— Priorité : c’est la valeur métier qui dirige la priorisation du dévelop- pement des his-
toires utilisateurs suivant les attentes et les besoins du client.

TABLE 2.1 – Backlog product

Sprint User story En tant que... Priorité
1 S’authentifier En tant qu’utilisateur je veux s’au- 1
thentifier pour accéder à L’applica-
tion.
1 Gérer les utilisateur En tant qu’Administrateur je veux 1
ajouter, Modifier, et supprimer des
utilisateurs.
2 Gérer les productions En tant que responsable production,je 2
veux pouvoir gérer les productions
(ajouter,supprimer ,modifier )et un
rapport de la production comprenant
les statistiques clés et les détails des
opérations effectuées.
2 gérer les produits En tant que responsable production, 2
je veux peuvent gérer les produits, y
compris leur ajout, leur modification
et leur suppression dans le système.
2 consulter les produc- En tant que superviseur générale, je 2
tions veux peuvent mise en place de l’in-
terface pour consulter les données de
production.
3 Gérer clients En tant que responsable les ventes, je 3
veux gérer les Clients (ajouter, modi-
fier, supprimer).
3 Gérer commandes En tant que responsable des ventes, 3
je veux pouvoir gérer les commandes
et en mettant à jour le statut de
chaque commande( ajouter ,Modi-
fier,supprimer).
3 Visualiser les ta- En tant que superviseur générale, je 3
bleaux de bord peux visualiser un tableau de bord.

17
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

2.8 Architecture de la solution :

2.8.1 Architecture logique
Dans une architecture 3-tiers, il y a une couche intermédiaire, ce qui veut dire qu’on a
généralement une architecture partagée :
1. La couche présentattion :est chargé du traitement de l’interaction avec l’utilisateur.
C’est un rôle d’affichage et d’interaction.
2. La couche application : effectue les traitements applicatifs. Elle effectue de plus le
tampon entre la présentation et les données. Elle effectue aussi les rêgles de gestion de
l’application
La partie donnée stocke les données pérennes de l’entreprise ou de l’application.
3. La couche de données ou métier :stocke les données pérennes de l’entreprise ou de
l’application.[7]

F IGURE 2.5 – ARCHITECTURE 3 TIERS

2.8.2 Architecture logicielle

Modele MVC
Le modèle MVC (Model View Controller) est un modèle architectural utilisé pour guider
la conception d’applications nécessitant une interaction de l’utilisateur avec le système. Elle
définit trois grandes catégories de responsabilité :

• Le Modèle : Les classes qui entrent dans cette catégorie définissent les données d’ap-
plication échangées entre l’utilisateur et le système.

• La Vue :Les classes appartenant à cette catégorie gèrent les représentations graphiques
et les interfaces utilisateur des données.

• Le Contrôleur : Les classes de cette catégorie gèrent l’interaction de l’utilisateur et

mettent à jour les vues après la modification des données. Les contrôleurs assurent la
cohérence entre le modèle et la vue.

18
2 2.8. ARCHITECTURE DE LA SOLUTION :

F IGURE 2.6 – Modele MVC

Modele MVVM
En architecture logicielle, MVVM (Model View ViewModel) est un Design pattern (Modèle
de conception) visant à séparer la logique de présentation d’une application en 3 couches :
• Model : Le modèle contient les données liés à la logique métier. Il peut s’agir par
exemple d’entités issues de bases de données ou encore d’API externes. Les modèles
métiers sont conçus et optimisés pour le bon fonctionnement de la persistance et/ou
de la transmission des donnés (backend). Les modèles métiers ne sont en aucun cas
dépendant de la manière dont elle seront présentés sur une interface graphique (fron-
tend).

• View : La vue est la description de l’interface graphique, elle fait le lien entre les actions
de l’utilisateur et le modèle de vue. Elle définie où et comment sont placés les compo-
sants graphiques sur l’interface et décris les liaisons de données (Data Bindings) entre
les valeurs affichés et le modèle de vue.
• View-Model : Le modèle de vue est chargé de transformer et organiser les modèles
métiers afin d’exposer les données à afficher par la vue. Si un changement critique in-
tervient au niveau du modèle métier, le view modèle peut être adapté sans en impacter
la vue. En revanche, la vue peut évoluer sans impacter les modèles de vue ou les mo-
dèles métiers.[9]

19
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

F IGURE 2.7 – Modele MVVM

2.9 Environnement de développement

2.9.1 Environement matériel
Machine : Dell.

Mémoire RAM installée :12,0 Go (11,7 Go utilisable).

Processeur :11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz 3.00 GHz.

Type de système :Système d’exploitation 64bits, processeur x64.

2.9.2 Environement développement

Dans cette partie nous allons présenter les différents langages et logiciel utilisés pour le
développement de notre Application web :

Angular :
Angular est un framework open-source pour le développement d’applications web, créé
et maintenu par Google. Il utilise le langage TypeScript pour écrire des applications du côté
client et implémente le modèle architectural MVVM (Model-View-ViewModel) pour faciliter
la séparation des responsabilités et la gestion des données.[15]

F IGURE 2.8 – Logo Angular

20
2 2.9. ENVIRONNEMENT DE DÉVELOPPEMENT

[Link]
[Link] est un langage de programmation utilisant la syntaxe de JavaScript. C’est un
plate-forme logicielle libre en Javascript orientée vers les applications. Il utilise la machine
virtuelle V8, la librairie liber pour sa boucle d’événements et implémente sous licence MIT
les spécifications CommonJS. Node Js est extrêmement rapide. Bien plus que tous les autres
langages de programmation web. Il utilise la technologie asynchrone pour gagner en puis-
sance et en vitesse.

F IGURE 2.9 – Logo Node js

HTML :
HTML (HyperText Markup Language) est le langage standard utilisé pour la création
et la structuration de pages web. Il s’agit d’un langage de balisage qui permet de définir la
structure et le contenu d’une page web en utilisant des balises et des attributs.[17]

F IGURE 2.10 – Logo HTML

Bootstrap :
Bootstrap est un framework front-end open-source qui facilite la conception et le déve-
loppement de sites web réactifs et esthétiquement agréables. Il fournit des composants pré-
définis, une grille de mise en page et des styles CSS pour accélérer le processus de création
de sites web.[18]

F IGURE 2.11 – Logo Bootstrap

21
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

TypeScript :
Le TypeScript est un langage de programmation développé par Microsoft en 2012. Son
ambition principale est d’améliorer la productivité de développement d’applications com-
plexes. C’est un langage open source, développé comme un sur-ensemble de Javascript. Ce
qu’il faut comprendre par là, c’est que tout code valide en Javascript l’est également en Ty-
peScript [8].[20]

F IGURE 2.12 – Logo TypeScript

java :
La technologie Java définit à la fois un langage de programmation orienté objet et une
plateforme [Link]éée par l’entreprise Sun Microsystems (souvent juste appelée
"Sun") en [Link] du domaine de l’informatique et du Web.

F IGURE 2.13 – Logo Java

eclipce :
Eclipse est un environnement de développement intégré (IDE) open source, multiplate-
forme et extensible, utilisé pour développer des applications dans de nombreux langages de
programmation tels que Java, C++, Python, PHP, Ruby, et bien d’autres.[23]

22
2 2.9. ENVIRONNEMENT DE DÉVELOPPEMENT

F IGURE 2.14 – Logo eclipse

Postman :

Postman est un logiciel de collaboration pour le développement d’API (Application Pro-

gram ming Interface) qui permet aux développeurs de tester, documenter et partager des
API de manière efficace.[16]

F IGURE 2.15 – Logo Postman

MYSQL :

MySQL est un système de gestion de base de données relationnelle (SGBDR) open-source

qui vous permet de stocker, organiser et récupérer des données de manière efficace. Il s’agit
de l’une des bases de données les plus populaires et les plus largement utilisées dans le
monde.[16]

F IGURE 2.16 – Logo MYSQL

23
2 CHAPITRE 2. CHAPITRE 2 : SPRINT 0 : ETUDE PRÉLIMINAIRE

Visual Studio Code :

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Win-
dows, Linux et macOS3.[23]

F IGURE 2.17 – Logo Visual Studio Code

Spring boot :
est un Framework open-source pour le développement d’applications Java. Il est conçu
pour simplifier et accélérer le processus de création d’applications en fournissant des fonc-
tionnalités prêtes à l’emploi et une configuration automatique
basée sur des conventions.[24]

F IGURE 2.18 – Logo spring boot

Overleaf :
Overleaf est une plateforme collaborative en ligne pour la rédaction et la publication de
documents scientifiques utilisant LaTeX.[11]

F IGURE 2.19 – Logo Overleaf

StarUML :
StarUML est un outil de génie logiciel dédié à la modélisation UML et édité par la société
coréenne MKLabs. Il est multiplateforme et fonctionne sous Windows, Linux et MacOS. La
dernière version gère l’ensemble des diagrammes définis par UML 2, ainsi que plusieurs
diagrammes SysML, le organigrammes,
les diagrammes de flux de données, et les diagrammes entité- association.[13].[13]

24
2 2.10. CONCLUSION

F IGURE 2.20 – Logo StarUML

[Link] :
[Link] est un logiciel de dessin graphique multiplateforme gratuit et open source de
veloppe en HTML5 et JavaScript. Son interface peut e tre utilise e pour cre er des dia-
grammes tels que des organigrammes, des structures filaires, des diagrammes UML, des
organigrammes et des diagrammes de re seau[17].

F IGURE 2.21 – Logo [Link]

2.10 Conclusion
Dans ce chapitre, nous avons commencé par présenter les principaux acteurs de notre
application. Ensuite, nous avons défini les besoins fonctionnels et non fonctionnels de notre
système ainsi que le diagramme de cas d’utilisation général. Nous avons aussi élaboré le
backlog du produit ainsi que la planification des sprints. Enfin, nous avons décrit les envi-
ronnements matériel et logiciel employés.

25
 C HAPITRE 3
Mise en oeuvre de sprint 1

Contents
3.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 Diagramme de cas d’utilisation de sprint 1 . . . . . . . . . . . . . . . 27
3.3 Description textuelle et raffinement des principaux cas d’utilisation . . . 28
3.3.1 Raffinement du cas d’utilisation "S’authentifier" . . . . . . . . . . . . 28
3.3.2 Description textuelle de cas d’utilisation « S’authentifier» . . . . . . 28
3.3.3 Raffinement du cas d’utilisation "Gérer les utilisateurs" . . . . . . . . 29
3.3.4 Description textuelle du cas d’utilisation"Ajouter utilisateur" . . . . 30
3.3.5 Description textuelle des cas d’utilisation "Supprimer utilisateur" . . 31
3.3.6 Description textuelle du cas d’utilisation "Modifier utilisateur" . . . 32
3.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Diagramme de classe du premier sprint . . . . . . . . . . . . . . . . . 33
3.4.2 Modèle relationnel du sprint 1 . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . 34
3.4.4 Diagramme de séquence lié à la fonctionnalité « S’authentifier » . . . 34
3.4.5 Diagramme de séquence «Ajouter utilisateur» pour l’administrateur 36
3.4.6 Diagramme de séquence «Supprimer utilisateur »pour l’administra-
teur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.7 Diagramme de séquence «Modifier utilisateur »pour l’administrateur 37
3.5 Test et validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.2 Interface de gestion l’utilisateurs . . . . . . . . . . . . . . . . . . . . . 40
3.6.3 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . 41
3.6.4 Interface modifier un utilisateur . . . . . . . . . . . . . . . . . . . . . 41
3.6.5 Interface de suppression d’un utilisateur . . . . . . . . . . . . . . . . 42
3.7 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

26
3 3.1. INRODUCTION

3.1 Inroduction
Dans le chapitre précédent, nous avons réussi à établir une liste de fonctionnalités décou-
pées en trois sprints. Ces fonctionnalités seront traitées selon la répartition qui a été faite.
Dans ce chapitre, nous allons décrire la réalisation du premier sprint en introduisant les
spécifications fonctionnelles, la conception, l’implémentation et les tests.

3.2 Spécification fonctionnelle

3.2.1 Backlog du Sprint 1
Le Backlog du Sprint représente un ensemble des tâches sélectionnées à partir du Back-
log de produit.

Le tableau ci-dessous résume les différentes fonctionnalités qui seront développées au

sein de ce sprint.

TABLE 3.1 – Backlog du sprint 1

Acteur Fonctions Tâche Esti-
mation
Administrateur/ Superviseur S’authentifier S’authentifier 7jrs
générale/ Responsable produc-
tion/Responsable ventes
Ajouter utilisateur 7jrs
Supprimer un nouvel
Administrateur Gérer utilisateurs
utilisateur
Modifier utilisateur

3.2.2 Diagramme de cas d’utilisation de sprint 1

F IGURE 3.1 – Diagramme de cas d’utilisation globale de sprint 1

27
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

3.3 Description textuelle et raffinement des principaux cas

d’utilisation
Après la réalisation du backlog du prémier sprint et pour que le déroulement des fonc-
tionnalités des cas d’utilisations soit plus simple, claire et facile à comprendre, nous allons
introduire une description textuelle et un raffinement des principaux cas d’utilisation.

3.3.1 Raffinement du cas d’utilisation "S’authentifier"

F IGURE 3.2 – Raffinement de cas d’utilisation «S’authentifier»

3.3.2 Description textuelle de cas d’utilisation « S’authentifier»

Cas d’Utilisation S’authentifier

Acteur Administrateur, Superviseur générale, Responsable

productions, Responsable ventes.

Objectif L’utilisateur doit s’authentifier pour accéder aux diffé-

rentes fonctionnalités de l’application.

Précondition Interface d’authentification affiché.

28
 3.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
3 D’UTILISATION

Postcondition Utilisateur authentifié.

Scénario nominal — l’utilisateur demande la page d’authentification.

— Le system lui affiche la page demandée.
— l’utilisateur saisit son pseudo et son mot de passe.
— l’utilisateur valide l’authentification.
— Le système vérifie les données saisies .
— Le système affiche l’espace personnel .

Scénario alternatif l’utilisateur n’a pas saisit les bons identifiants

(contrôle de saisie) :le système affiche un message
d’erreur et signale à l’utilisateur de recommencer la
saisie. Le cas d’utilisation reprend à l’étape 3 du scé-
nario nominal. . les identifiants saisies n’existent pas
dans la base de données ( contrôle d’existence de
l’utilisateur ) : Le système affiche le message d’erreur
suivant « vous devez saisir des identifiants valides » et
signale au client de recommencer la saisie Le cas d’uti-
lisation reprend à l’étape 3 du scénario nominal.

TABLE 3.2: Description textuelle du cas d’utilisation

"S’authentifier"

3.3.3 Raffinement du cas d’utilisation "Gérer les utilisateurs"

F IGURE 3.3 – Raffinement du cas d’utilisation "gérer les utilisateur"

29
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

3.3.4 Description textuelle du cas d’utilisation"Ajouter utilisateur"

Cas d’Utilisation Ajouter utilisateur

Acteur Administrateur

Objectif L’administrateur peut ajouter un ou plusieurs uti-

lisateurs.

Précondition — Administrateur doit être authentifié.

— L’administrateur doit accéder à la liste des utilisa-
teurs.

Postcondition Utilisateur ajouté

Scénario nominal — L’administrateur clique sur Gestion des l’utilisa-

teurs.
— Le système affiche l’interface de liste utilisateur.
— l’administrateur clique sur le boutton "Ajouter
utilisateur".
— Le système affiche l’interface d’ajout.
— l’administrateur remplit le formulaire d’ajout .
— L’administrateur clique sur bouton Ajouter utili-
sateur.
— Le système vérifie les données saisies .
— Le système ajoute l’utilisateur dans la base de
données et affiche le message suivant : « utilisa-
teur ajouté avec succès »

l’administrateur quitte la page d’ajout d’un utilisa-

Scénario alternatif teur :
— Le cas d’utilisation se termine avec échec.
Les données saisies sont incorrectes ou manquantes :
— Le système affiche le message d’erreur et l’ad-
ministrateur de corriger les erreurs mentionnées
dans le message.

30
 3.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
3 D’UTILISATION

TABLE 3.3: Description textuelle du cas d’utilisation

"Ajouter Utilisateur"

3.3.5 Description textuelle des cas d’utilisation "Supprimer utilisateur"

Cas d’Utilisation Supprimer utilisateur

Acteur Administrateur

Objectif L’administrateur peut supprimer un utilisateur.

Précondition — Administrateur doit être authentifié.

— L’administrateur doit accéder à la liste des utilisa-
teurs.

Postcondition Utilisateur est supprimé

Scénario nominal — L’administrateur clique sur Gestion des l’utilisa-

teurs.
— Le système affiche l’interface de liste utilisateur.
— l’administrateur clique sur le boutton "supprimer
utilisateur".
— Le système affiche l’interface d’ajout.
— L’administrateur clique sur le bouton qui contient
une icône de suppression utilisateur sélectionné.
— Le système affiche un pop-up de confirmation de
suppression.
— L’administrateur confirme la suppression.
— Le système enregistre la suppression et indique
par message que la suppression s’est effectuée
avec succès .

31
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

Scénario alternatif L’administrateur clique sur bouton Non.

Le cas d’utilisation se termine avec échec .

TABLE 3.4: Description textuelle du cas d’utilisation

"Supprimer utilisateur"

3.3.6 Description textuelle du cas d’utilisation "Modifier utilisateur"

Cas d’Utilisation Modifier utilisateur

Acteur Administrateur

Objectif L’administrateur peut modifer un utilisateur.

Précondition — Administrateur doit être authentifié.

— L’administrateur doit accéder à la liste des utilisa-
teurs.

Postcondition Utilisateur Modifié

32
3 3.4. CONCEPTION

Scénario nominal — L’administrateur clique sur Gestion des l’utilisa-

teurs.
— Le système affiche l’interface de liste utilisateur.
— l’administrateur clique sur le boutton "Modifier
utilisateur".
— Le système affiche l’interface Modifé.
— L’administrateur clique sur le bouton qui contient
une icône de modifé utilisateur sélectionné.
— Le système affiche un formulaire du modification.
— L’administrateur remplit le formulaire d’ajout .
— L’administrateur clique sur le boutton "Modifier".
— Le système vérifie les données saisies
— Le système enregistre les données saisies et in-
dique en message que le mise à jour s’est effectuée
avec succès .

l’administrateur quitte la page de modification d’un

Scénario alternatif utilisateur :
Le cas d’utilisation se termine avec échec. Les données
saisies sont incorrectes :
Le système affiche le message d’erreur et signale àl’ad-
ministrateur de corriger les erreurs mentionnées dans
le message.

TABLE 3.5: Description textuelle du cas d’utilisation

"Modifier utilisateur"

3.4 Conception
Dans cette section , nous présentons le diagramme de classe et les différents diagrammes
de séquence détaillés de ce sprint .

3.4.1 Diagramme de classe du premier sprint

Les diagrammes de classes sont l’un des types de diagrammes UML les plus utiles, car
ils décrivent clairement la structure d’un système particulier en modélisant ses classes, ses
attributs, ses opérations et les relations entre ses objets. Ci-dessous le diagramme de classes
du premier sprint.

33
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

F IGURE 3.4 – Diagramme de classes du premier sprint

3.4.2 Modèle relationnel du sprint 1

Nom du sprint Schéma relationnel

Sprint 1
— Administrateur(idAd,username,password).
— Utilisateur(idU,nom,prenom,email,password,role)
— Superviseur générale(idS, #idU)
— Responsable production(idP,#idU)
— Responsable vente(idV,#idU )

TABLE 3.6: Modèle relationnel du sprint 1

3.4.3 Diagrammes de séquences détaillés

Un diagramme de séquence est un diagramme UML (Unified Modeling Language) qui
représente la séquence de messages entre les objets au cours d’une interaction. Un dia-
gramme de séquence comprend un groupe d’objets, représentés par des lignes de vie, et
les messages que ces objets échangent lors de l’interaction.

3.4.4 Diagramme de séquence lié à la fonctionnalité « S’authentifier »

Lors de cette procédure, l’utilisateur demande l’accès à la page d’authentification, que
le système lui affiche ensuite. Une fois sur cette page, l’utilisateur entre ses identifiants de
connexion. Le système vérifie ensuite la syntaxe des champs. En cas d’erreur syntaxique, un

34
3 3.4. CONCEPTION

message d’erreur s’affiche, sinon une requête de recherche est envoyée pour vérifier l’exis-
tence de l’utilisateur dans la base de données. Si l’utilisateur n’est pas répertorié, le système
invite l’utilisateur à vérifier les données saisies. Sinon, l’espace utilisateur est affiché.

F IGURE 3.5 – Diagramme de séquence «s’authentifier»

35
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

3.4.5 Diagramme de séquence «Ajouter utilisateur» pour l’administra-

teur

F IGURE 3.6 – Diagramme de séquence «Ajouter utilisateur»

3.4.6 Diagramme de séquence «Supprimer utilisateur »pour l’adminis-

trateur
afin de procéder à la suppression d’un utilisateur, l’administrateur doit préalablement
s’authentifier et accéder à la liste des utilisateurs en question. Ensuite, l’administrateur sé-
lectionne l’utilisateur ou les utilisateurs qu’il souhaite supprimer. Le système demande une
confirmation de la suppression de l’utilisateur ou des utilisateurs sélectionnés. Si l’adminis-
trateur confirme, le système procède à la suppression de l’utilisateur ou des utilisateurs de
la liste et affiche cette liste mise à jour.

36
3 3.4. CONCEPTION

F IGURE 3.7 – Diagramme de séquences «Supprimer utilisateur»

3.4.7 Diagramme de séquence «Modifier utilisateur »pour l’administra-

teur
Pour effectuer une modification d’utilisateur, l’administrateur doit s’authentifier puis ac-
céder à la liste des utilisateurs. Ensuite, il modifie une propriété de l’utilisateur concerné
avant d’enregistrer les changements. Le système sollicite une confirmation de modification
de l’utilisateur. Si l’administrateur confirme, le système met à jour la nouvelle propriété de
l’utilisateur et affiche la liste des utilisateurs mise à jour.

37
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

F IGURE 3.8 – Diagramme de séquences «Modifier utilisateur»

3.5 Test et validations

Cette partie s’intéresse à la vérification du résultat de l’implémentation, en testant les
fonctionnalités ayant été développées. Le test d’un produit logiciel est un processus consis-
tant qui vise à garantir le bon fonctionnement du système à travers une comparaison des
comportements attendu et des résultats obtenus. Avant la fin de chaque Sprint nous, avons
testé les fonctionnalités du module. Ensuite, nous avons validé toutes les fonctionnalités
avec le Product Owner .

Le tableau suivant montre un ensemble de cas de scénario de tests fonctionnels relatifs

au sprint.

38
3 3.5. TEST ET VALIDATIONS

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

Afficher l’espace utilisa-
S’authentifier L’utilisateur teur. Afficher un message Conforme
de l’applica- d’erreur si :
tion remplit le — Une information obli-
formulaire d’au- gatoire manquante .
thentification
. — La syntaxe des
champs est
invalide .
— Identifiants invalides
.

Afficher l’espace « Ajou-

Ajouter uti- L’administrateur terutilisateur».Afficher un Conforme
lisateur remplit le for- message d’erreur si :
mulaire «Ajouter — Une information obli-
utilisateur» . gatoire manquante.
— La syntaxe des
champs est
invalide .

Afficher un message l’uti-

Supprimer L’administrateur lisateur est supprimer avec Conforme
utilisateur de l’application succès. Afficher un mes-
peut supprimer sage d’erreur si :
un utilisateur . — Une information obli-
gatoire manquante .
— La syntaxe des
champs est invalide .
.

Afficher un message l’uti-

Modifier L’administrateur lisateur est modifier avec Conforme
utilisateur de l’application succès. Afficher un mes-
peut modifier un sage d’erreur si :
utilisateur . — Une information obli-
gatoire manquante .
— La syntaxe des
champs est invalide .
.

TABLE 3.7: Tests et résultats de sprint 1

39
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

3.6 Réalisation
Dans cette partie,nous présenterons quelques captures d’écran des interfaces implémen-
tées lors du premier sprint .

3.6.1 Interface d’authentification

F IGURE 3.9 – Interface d’authentification

F IGURE 3.10 – Email qui permet de l’accès au notre plateformer

3.6.2 Interface de gestion l’utilisateurs

L’interface de gestion l’utilisateurs est illustrée à la figure 3.10 . Dans cette interface, nous
pouvons consulter la liste utilisateurs. Nous pouvons aussi naviguer vers l’interface ajouter,
modifier et supprimer un utilisateur.

40
3 3.6. RÉALISATION

F IGURE 3.11 – Interface de gestion l’utilisateurs

3.6.3 Interface d’ajout d’un utilisateur

L’interface d’ajout d’un utilisateur est illustrée à la figure 3.11 qui permet àl’administra-
teur d’ajouter un nouveau utilisateur.

F IGURE 3.12 – Interface d’ajout d’un utilisateur

3.6.4 Interface modifier un utilisateur

41
3 CHAPITRE 3. MISE EN OEUVRE DE SPRINT 1

F IGURE 3.13 – Interface modifier d’un utilisateur

3.6.5 Interface de suppression d’un utilisateur

L’interface de suppression des utilisateurs permet de rechercher et supprimer des utilisa-
teurs en utilisant des critères de filtrage. Après avoir sélectionné un utilisateur à supprimer,
un message de confirmation s’affiche pour confirmer la suppression.

F IGURE 3.14 – Interface suppression d’un utilisateur

3.7 conclusion
Dans ce chapitre, nous avons réussi à compléter toutes les tâches planifiées pour le pre-
mier sprint. Dans le chapitre suivant et avec la même démarche, nous passons à décrire la
réalisation du deuxième sprint.

42
 C HAPITRE 4
Mise en oeuvre de sprint 2

Contents
4.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Diagramme de cas d’utilisation de sprint 2 . . . . . . . . . . . . . . . 45
4.3 Description textuelle et raffinement des principaux cas d’utilisation . . . 46
4.3.1 Raffinement du cas d’utilisation "Consulter les productions" . . . . . 46
4.3.2 Description textuelle du cas d’utilisation"Consulter les productions" 46
4.3.3 Raffinement du cas d’utilisation "Gérer les productions" . . . . . . . 47
4.3.4 Description textuelle du cas d’utilisation"Ajouter production " . . . . 47
4.3.5 Description textuelle des cas d’utilisation "Supprimer production" . 48
4.3.6 Description textuelle du cas d’utilisation "Modifier production" . . . 49
4.3.7 Raffinement du cas d’utilisation "Gérer les produits" . . . . . . . . . 51
4.3.8 Description textuelle du cas d’utilisation"Ajouter produit" . . . . . . 51
4.3.9 Description textuelle des cas d’utilisation "Supprimer produit" . . . 52
4.3.10 Description textuelle du cas d’utilisation "Modifier produit" . . . . . 53
4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.1 Diagramme de classe du deuxiéme sprint . . . . . . . . . . . . . . . . 55
4.4.2 Modèle relationnel du sprint 2 . . . . . . . . . . . . . . . . . . . . . . 56
4.5 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.1 Diagramme de séquence «Consulter les productions» pour Supervi-
seur générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5.2 Diagramme de séquence «Ajouter production » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5.3 Diagramme de séquence «Supprimer production » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5.4 Diagramme de séquence «Modifier production » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.5 Diagramme de séquence «Ajouter produit » pour Responsable pro-
duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.6 Diagramme de séquence «Supprimer produit » pour Responsable
production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.7 Diagramme de séquence «Modifier produit » pour Responsable pro-
duction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6 Test et validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.7 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7.1 Interface de gestion des productions . . . . . . . . . . . . . . . . . . . 64
4.7.2 Interface ajouter production . . . . . . . . . . . . . . . . . . . . . . . . 65
4.7.3 Interface modifier production . . . . . . . . . . . . . . . . . . . . . . . 65
4.7.4 Interface de suppression production . . . . . . . . . . . . . . . . . . . 66
4.7.5 Interface ajouter produit . . . . . . . . . . . . . . . . . . . . . . . . . . 66

43
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.7.6 Interface modifier produit . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.7.7 Interface de suppression produit . . . . . . . . . . . . . . . . . . . . . 68
4.8 Conclustion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

44
4 4.1. INRODUCTION

4.1 Inroduction
Dans ce chapitre, nous allons décrire la réalisation du deuxième sprint en introduisant
les spécifications fonctionnelles, conception ,l’implémentation et les tests. Parmi les fonc-
tionnalités que nous allons aborder dans ce sprint.

4.2 Backlog du Sprint 2

L’objectif de ce sprint consiste à habiliter supervisure générale consulter les productions
pour la comparaison entre l’usine internationale ,et au responsable production pour gérer
les productions et produits.
Dans ce tableau on trouve la liste des tâches du deuxième sprint :

TABLE 4.1 – Backlog du sprint 2

Acteur Fonctions Tâche Esti-
mation
Superviseur génerale Consulter les produc- Consulter 5jrs
tions
Ajouter production 12jrs
Supprimer produc-
Responsable production Gérer productions
tion
Modifier production
Ajouter produit 12jrs
Supprimer produit
Responsable productions Gérer produits
Modifier produit

4.2.1 Diagramme de cas d’utilisation de sprint 2

F IGURE 4.1 – Diagramme de cas d’utilisation globale de sprint 2

45
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.3 Description textuelle et raffinement des principaux cas

d’utilisation
Après la réalisation du backlog du deuxiéme sprint et pour que le déroulement des fonc-
tionnalités des cas d’utilisations soit plus simple, claire et facile à comprendre, nous allons
introduire une description textuelle et un raffinement des principaux cas d’utilisation

4.3.1 Raffinement du cas d’utilisation "Consulter les productions"

F IGURE 4.2 – Raffinement de cas d’utilisation «Consulter les productions»

4.3.2 Description textuelle du cas d’utilisation"Consulter les productions"

Cas d’Utilisation Consulter les productions

Acteur Superviseur générale

Objectif Superviseur générale consulte les productions.

Précondition — Superviseur générale doit être authentifié.

— Des données de production doivent être disponibles dans
le système

Postcondition Superviseur générale consulte la liste des productions avec

succès

46
 4.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
4 D’UTILISATION

Scénario nominal [Link] générale demande la liste productions.

2. Le système lui affiche la page demandée.
3. Superviseur générale consulte les productions.

TABLE 4.2: Description textuelle du cas d’utilisation

"Consulter les Productions"

4.3.3 Raffinement du cas d’utilisation "Gérer les productions"

F IGURE 4.3 – Raffinement de cas d’utilisation «Gérer les productions»

4.3.4 Description textuelle du cas d’utilisation"Ajouter production "

Cas d’Utilisation Ajouter production

Acteur Responsable production

Objectif Resonsable production peut ajouter productions.

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des productions .

Postcondition Production ajouté

47
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

Scénario nominal — Responsable production clique sur Gestion des

productions.
— Le système affiche l’interface de liste productions.
— Responsable production clique sur le boutton
"Ajouter production".
— Le système affiche l’interface d’ajout.
— Responsable production remplit le formulaire
d’ajout .
— Responsable production clique sur bouton Ajou-
ter production.
— Le système vérifie les données saisies .
— Le système ajoute production dans la base de
données et affiche le message suivant : « produc-
tion ajouté avec succès »

Responsable production quitte la page d’ajout d’un

Scénario alternatif production :
— Le cas d’utilisation se termine avec échec.
Les données saisies sont incorrectes ou manquantes :
— Le système affiche le message d’erreur et respon-
sable production de corriger les erreurs mention-
nées dans le message.

TABLE 4.3: Description textuelle du cas d’utilisation

"Ajouter Production"

4.3.5 Description textuelle des cas d’utilisation "Supprimer production"

Cas d’Utilisation Supprimer production

Acteur Responsable production

Objectif Resonsable production peut supprimer produc-

tions.

48
 4.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
4 D’UTILISATION

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des productions .

Postcondition Production est supprimé

Scénario nominal — Responsable production clique sur Gestion des

productions.
— Le système affiche l’interface de liste productions.
— Responsable production clique sur le boutton
"supprimer production".
— Le système affiche l’interface d’ajout.
— Responsable production clique sur le bouton qui
contient une icône de suppression production sé-
lectionné.
— Le système affiche un pop-up de confirmation de
suppression.
— Responsable production confirme la suppression.
— Le système enregistre la suppression et indique
par message que la suppression s’est effectuée
avec succès .

Scénario alternatif Responsable production clique sur bouton Non.

Le cas d’utilisation se termine avec échec .

TABLE 4.4: Description textuelle du cas d’utilisation

"Supprimer production"

4.3.6 Description textuelle du cas d’utilisation "Modifier production"

Cas d’Utilisation Modifier production

Acteur Responsable production

Objectif Resonsable production peut modifié productions.

49
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des productions .

Postcondition Production Modifié

Scénario nominal — Responsable production clique sur Gestion des

production.
— Le système affiche l’interface de liste production.
— Responsable production clique sur le boutton
"Modifier production".
— Le système affiche l’interface Modifé.
— Responsable production clique sur le bouton qui
contient une icône de modifé production sélec-
tionné.
— Le système affiche un formulaire du modification.
— Responsable production remplit le formulaire
d’ajout .
— Responsable production clique sur le boutton
"Modifier".
— Le système vérifie les données saisies
— Le système enregistre les données saisies et in-
dique en message que le mise à jour s’est effectuée
avec succès .

Responsable production quitte la page de modifica-

Scénario alternatif tion d’un production :
Le cas d’utilisation se termine avec échec. Les données
saisies sont incorrectes :
Le système affiche le message d’erreur et signale à res-
ponsable production de corriger les erreurs mention-
nées dans le message.

TABLE 4.5: Description textuelle du cas d’utilisation

"Modifier production"

50
 4.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
4 D’UTILISATION
4.3.7 Raffinement du cas d’utilisation "Gérer les produits"

F IGURE 4.4 – Raffinement de cas d’utilisation «Gérer les produits»

4.3.8 Description textuelle du cas d’utilisation"Ajouter produit"

Cas d’Utilisation Ajouter produit

Acteur Responsable production

Objectif Resonsable production peut ajouter produits.

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des produits .

Postcondition Produit ajouté

51
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

Scénario nominal — Responsable production clique sur Gestion des

produits.
— Le système affiche l’interface de liste produits.
— Responsable production clique sur le boutton
"Ajouter produit".
— Le système affiche l’interface d’ajout.
— Responsable production remplit le formulaire
d’ajout .
— Responsable production clique sur bouton Ajou-
ter produit.
— Le système vérifie les données saisies .
— Le système ajoute production dans la base de
données et affiche le message suivant : « produit
ajouté avec succès »

Responsable production quitte la page d’ajout d’un

Scénario alternatif production :
— Le cas d’utilisation se termine avec échec.
Les données saisies sont incorrectes ou manquantes :
— Le système affiche le message d’erreur et respon-
sable production de corriger les erreurs mention-
nées dans le message.

TABLE 4.6: Description textuelle du cas d’utilisation

"Ajouter Produit"

4.3.9 Description textuelle des cas d’utilisation "Supprimer produit"

Cas d’Utilisation Supprimer produit

Acteur Responsable production

Objectif Resonsable production peut supprimer produits.

52
 4.3. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
4 D’UTILISATION

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des produits .

Postcondition Produit est supprimé

Scénario nominal — Responsable production clique sur Gestion des

produits.
— Le système affiche l’interface de liste produits.
— Responsable production clique sur le boutton
"supprimer produit".
— Le système affiche l’interface d’ajout.
— Responsable production clique sur le bouton qui
contient une icône de suppression production sé-
lectionné.
— Le système affiche un pop-up de confirmation de
suppression.
— Responsable production confirme la suppression.
— Le système enregistre la suppression et indique
par message que la suppression s’est effectuée
avec succès .

Scénario alternatif Responsable production clique sur bouton Non.

Le cas d’utilisation se termine avec échec .

TABLE 4.7: Description textuelle du cas d’utilisation

"Supprimer produit"

4.3.10 Description textuelle du cas d’utilisation "Modifier produit"

Cas d’Utilisation Modifier produit

Acteur Responsable production

Objectif Resonsable production peut modifier produits.

53
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

Précondition Responsable production doit être authentifié.

Responsable production doit accéder à l’interface
gestion des produits .

Postcondition Produit Modifié

Scénario nominal — Responsable production clique sur Gestion des

produits.
— Le système affiche l’interface de liste produit.
— Responsable production clique sur le boutton
"Modifier produit".
— Le système affiche l’interface Modifé.
— Responsable production clique sur le bouton qui
contient une icône de modifié produit sélec-
tionné.
— Le système affiche un formulaire du modification.
— Responsable production remplit le formulaire
modifié .
— Responsable production clique sur le boutton
"Modifier".
— Le système vérifie les données saisies
— Le système enregistre les données saisies et in-
dique en message que le mise à jour s’est effectuée
avec succès .

Responsable production quitte la page de modifica-

Scénario alternatif tion d’un produit :
Le cas d’utilisation se termine avec échec. Les données
saisies sont incorrectes :
Le système affiche le message d’erreur et signale à res-
ponsable production de corriger les erreurs mention-
nées dans le message.

TABLE 4.8: Description textuelle du cas d’utilisation

"Modifier produit"

54
4 4.4. CONCEPTION

4.4 Conception
4.4.1 Diagramme de classe du deuxiéme sprint

F IGURE 4.5 – Diagramme de classe du deuxiéme sprint

55
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.4.2 Modèle relationnel du sprint 2

Nom Schéma relationnel

du
sprint

Sprint 2 — Utilisateur(idU,nom,prenom,email,mot de passe,role).

— SuperviseurGénéral (idS,#idU).
— Responsableproduction(idP,#idU).
— Production (idProd, datecreation, nombrepiecedef, nombre-
piece,#idPdt).
— Produit (idPdt, référence, datecreation,stock).

TABLE 4.9: Modèle relationnel du sprint 2

4.5 Diagrammes de séquences détaillés

4.5.1 Diagramme de séquence «Consulter les productions» pour Super-

viseur générale

F IGURE 4.6 – Diagramme de séquences «Consulter les productions»

56
4 4.5. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

4.5.2 Diagramme de séquence «Ajouter production » pour Responsable

production
Le diagramme de séquence détaillé du cas d’utilisation "Ajouter production " est repré-
senté dans la figure 4.7.

F IGURE 4.7 – Diagramme de séquences «Ajouter production»

57
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.5.3 Diagramme de séquence «Supprimer production » pour Respon-

sable production
Le diagramme de séquence détaillé du cas d’utilisation "Ajouter production " est repré-
senté dans la figure 4.8.

F IGURE 4.8 – Diagramme de séquences «Supprimer production»

58
4 4.5. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

4.5.4 Diagramme de séquence «Modifier production » pour Responsable

production
Le diagramme de séquence détaillé du cas d’utilisation "Modifier production " est repré-
senté dans la figure 4.9.

F IGURE 4.9 – Diagramme de séquences «Modifier production»

59
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.5.5 Diagramme de séquence «Ajouter produit » pour Responsable pro-

duction
Le diagramme de séquence détaillé du cas d’utilisation "Ajouter produit " est représenté
dans la figure 4.10.

F IGURE 4.10 – Diagramme de séquences «Ajouter produit»

60
4 4.5. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

4.5.6 Diagramme de séquence «Supprimer produit » pour Responsable

production
Le diagramme de séquence détaillé du cas d’utilisation "Supprimer produit " est repré-
senté dans la figure 4.11.

F IGURE 4.11 – Diagramme de séquences «Supprimer produit»

61
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.5.7 Diagramme de séquence «Modifier produit » pour Responsable pro-

duction
Le diagramme de séquence détaillé du cas d’utilisation "Modifier produit " est représenté
dans la figure 4.12.

F IGURE 4.12 – Diagramme de séquences «Modifier produit»

62
4 4.6. TEST ET VALIDATIONS

4.6 Test et validations

Le tableau suivant montre un ensemble de cas de scénario de tests fonctionnels relatifs
au sprint.

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

Consulter Responsable Afficher les produc- Conforme

produc- production peut tions
tions consulter les
productions.

Afficher l’espace « Ajouter

Ajouter Responsable pro- production». Afficher un Conforme
production duction remplit message d’erreur si :
le formulaire — Une information obli-
«Ajouter produc- gatoire manquante.
tion» .
— La syntaxe des
champs est
invalide .

Afficher un message sup-

Supprimer Responsable primer avec succès. Affi- Conforme
production production de cher un message d’erreur
l’application si :
peut supprimer — Une information obli-
un ou pleusieur gatoire manquante .
production.
— La syntaxe des
champs est invalide .
.

Afficher un message est

Modifier Responsable modifier avec succès. Affi- Conforme
production production de cher un message d’erreur
l’application si :
peut modifier — Une information obli-
un ou pleusieur gatoire manquante .
production .
— La syntaxe des
champs est invalide .
.

63
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

Afficher l’espace « Ajouter

Ajouter Responsable produit». Afficher un mes- Conforme
produit production sage d’erreur si :
remplit le for- — Une information obli-
mulaire «Ajouter gatoire manquante.
produit» .
— La syntaxe des
champs est
invalide .

Afficher un message sup-

Supprimer Responsable primer avec succès. Affi- Conforme
produit production de cher un message d’erreur
l’application si :
peut supprimer — Une information obli-
un ou pleusieur gatoire manquante .
produit.
— La syntaxe des
champs est invalide .
.

Afficher un message est

Modifier Responsable modifier avec succès. Affi- Conforme
produit production de cher un message d’erreur
l’application si :
peut modifier — Une information obli-
un ou pleusieur gatoire manquante .
produit.
— La syntaxe des
champs est invalide.

TABLE 4.10: Tests et résultats de sprint 2

4.7 Réalisation
4.7.1 Interface de gestion des productions
L’interface de gestion des productions est illustrée à la figure 4.13 . Dans cette interface,
nous pouvons consulter la liste des productions. Nous pouvons aussi naviguer vers l’inter-
face ajouter, modifier et supprimer un ou pleusieur productions.

64
4 4.7. RÉALISATION

F IGURE 4.13 –

4.7.2 Interface ajouter production

L’interface ajouter production est illustrée à la figure 4.14 qui permet à responsable pro-
duction d’ajouter un nouveau production.

F IGURE 4.14 – Interface d’ajout production

4.7.3 Interface modifier production

65
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

F IGURE 4.15 – Interface modifier production

4.7.4 Interface de suppression production

L’interface de suppression des productions permet de rechercher et supprimer des pro-
ductions en utilisant des critères de filtrage. Après avoir sélectionné un utilisateur à suppri-
mer, un message de confirmation s’affiche pour confirmer la suppression.

F IGURE 4.16 – Interface suppression d’un production

4.7.5 Interface ajouter produit

L’interface ajouter produit est illustrée à la figure 4.17 qui permet à responsable produc-
tion d’ajouter un nouveau produit.

66
4 4.7. RÉALISATION

F IGURE 4.17 – Interface ajouter produit

4.7.6 Interface modifier produit

F IGURE 4.18 – Interface modifier produit

67
4 CHAPITRE 4. MISE EN OEUVRE DE SPRINT 2

4.7.7 Interface de suppression produit

L’interface de suppression des produits permet de rechercher et supprimer des produits
en utilisant des critères de filtrage. Après avoir sélectionné un produit à supprimer, un mes-
sage de confirmation s’affiche pour confirmer la suppression.

F IGURE 4.19 – Interface suppression produit

4.8 Conclustion
Dans ce chapitre, nous avons réussi à compléter toutes les tâches planifiées pour le
deuxiéme sprint. Dans le chapitre suivant et avec la même démarche, nous passons à dé-
crire la réalisation du troisiéme sprint

68
 C HAPITRE 5
Mise en oeuvre de sprint 3

Contents
5.1 Inroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Spécification fonctionnelle : . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3.1 Diagramme des cas d’utilisation de sprint 3 . . . . . . . . . . . . . . . 71
5.4 Description textuelle et raffinement des principaux cas d’utilisation . . . 72
5.4.1 Raffinement de cas d’utilisation «Gérer les Clients »pour l’acteur «
Responsable vente» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.2 Description textuelle du cas d’utilisation"Ajouter Client" . . . . . . . 72
5.4.3 Description textuelle des cas d’utilisation "Supprimer client" . . . . . 73
5.4.4 Description textuelle du cas d’utilisation "Modifier client" . . . . . . 74
5.4.5 Raffinement de cas d’utilisation «Gérer les commandes »pour l’ac-
teur " Responsable vente" . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.6 Description textuelle du cas d’utilisation"Ajouter Commande" . . . . 76
5.4.7 Description textuelle des cas d’utilisation "Supprimer commande" . 77
5.4.8 Description textuelle du cas d’utilisation "Modifier commande" . . . 78
5.4.9 Diagramme du cas d’utilisation « visualiser tableau de bord» . . . . 79
5.4.10 Description textuelle du cas d’utilisation "visualiser les nombres des
productions" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5.1 Diagramme de classe du troisiéme sprint . . . . . . . . . . . . . . . . 81
5.5.2 Modèle relationnel du sprint 3 . . . . . . . . . . . . . . . . . . . . . . 82
5.6 Diagrammes de séquences détaillés . . . . . . . . . . . . . . . . . . . . . . . 83
5.6.1 Diagramme de séquence «Ajouter client» pour Responsable vente . 83
5.6.2 Diagramme de séquence « Supprimer client » pour Responsable vente 83
5.6.3 Diagramme de séquence « Modifier client » pour Responsable vente 84
5.6.4 Diagramme de séquence «Ajouter commande» pour Responsable vente
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.6.5 Diagramme de séquence « Supprimer commande » pour Respon-
sable vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6.6 Diagramme de séquence « Modifier commande » pour Responsable
vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.6.7 Diagramme de séquence « visualiser les nombres des productions » 88
5.7 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.8 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.1 Interface gestion des clients . . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.2 Interface ajouter client . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.8.3 Interface modifier client . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.8.4 Interface de suppression client . . . . . . . . . . . . . . . . . . . . . . 92
5.8.5 Interface gestion des commandes . . . . . . . . . . . . . . . . . . . . . 92

69
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

5.8.6 Interface ajouter commande . . . . . . . . . . . . . . . . . . . . . . . . 93

5.8.7 Interface modifier commande . . . . . . . . . . . . . . . . . . . . . . . 93
5.8.8 Interface de suppression commande . . . . . . . . . . . . . . . . . . . 94
5.8.9 Interface Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

70
5 5.1. INRODUCTION

5.1 Inroduction
Dans ce chapitre, nous allons décrire la réalisation du sprint 3 en introduisant les spéci-
fications fonctionnelles, la conception, l’implémentation et les tests.

5.2 Backlog du Sprint 3

L’objectif de ce sprint consiste à habiliter le responsable vente gérer les commandes et les
clients et le superviseur générale visualiser le tableau de bord.
Dans ce tableau on trouve la liste des tâches du troiséme sprint :

TABLE 5.1 – Backlog du sprint 1

Acteur Fonctions Tâche Estimation
Ajouter Commande 10jrs
Supprimer Commande
Responsable vente gérer les commandes
Modifier Commande
Ajouter Client 10jrs
Supprimer Client
Responsable vente Gérer les Clients
Modifier Client
Responsable vente Visualiser tableaux de visualiser les analyses et 10jrs
bord les statistiques à travers
d’une tableau de bord

5.3 Spécification fonctionnelle :

5.3.1 Diagramme des cas d’utilisation de sprint 3

F IGURE 5.1 – Diagramme de cas d’utilisation global du sprint 3

71
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

5.4 Description textuelle et raffinement des principaux cas

d’utilisation
Après la réalisation du backlog du troisième sprint et pour que le déroulement des fonc-
tionnalités des cas d’utilisations soit plus simple, claire et facile à comprendre, nous allons
introduire une description textuelle et un raffinement des principaux cas d’utilisation.

5.4.1 Raffinement de cas d’utilisation «Gérer les Clients »pour l’acteur «

Responsable vente»

F IGURE 5.2 – Raffinement du cas d’utilisation"Gérer les Clients".

5.4.2 Description textuelle du cas d’utilisation"Ajouter Client"

Cas d’Utilisation Ajouter client

Acteur Responsable vente

Objectif Resonsable les ventes peut ajouter client.

Précondition — Responsable vente doit être authentifié.

— Responsable vente doit accéder à l’interface ges-
tion des Clients .

72
 5.4. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
5 D’UTILISATION

Postcondition Client ajouté

Scénario nominal — Responsable vente clique sur Gestion les clients.

— Le système affiche l’interface de liste client.
— Responsable vente clique sur le boutton "Ajouter
client".
— Le système affiche l’interface d’ajout.
— Responsable vente remplit le formulaire d’ajout .
— Responsable vente clique sur bouton Ajouter
client.
— Le système vérifie les données saisies .
— Le système ajoute client dans la base de données
et affiche le message suivant : « client ajouté avec
succès »

Responsable vente quitte la page d’ajout d’un client :

Scénario alternatif — Le cas d’utilisation se termine avec échec.
Les données saisies sont incorrectes ou manquantes :
— Le système affiche le message d’erreur et Respon-
sable vente de corriger les erreurs mentionnées
dans le message.

TABLE 5.2: Description textuelle du cas d’utilisation

"Ajouter client"

5.4.3 Description textuelle des cas d’utilisation "Supprimer client"

Cas d’Utilisation Supprimer client

Acteur Responsable vente

Objectif Resonsable les ventes peut Supprimer le client.

73
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

Précondition Responsable vente doit être authentifié. Respon-

sable vente doit accéder à l’interface gestion des
clients .

Postcondition Client est supprimé

Scénario nominal — Responsable vente clique sur Gestion les Clients.

— Le système affiche l’interface de liste clients.
— Responsable vente clique sur le boutton "suppri-
mer client".
— Le système affiche l’interface .
— Responsable vente clique sur le bouton qui
contient une icône de suppression client sélec-
tionné.
— Le système affiche un pop-up de confirmation de
suppression.
— Responsable vente confirme la suppression.
— Le système enregistre la suppression et indique
par message que la suppression s’est effectuée
avec succès .

Scénario alternatif Responsable vente clique sur bouton Non.

Le cas d’utilisation se termine avec échec .

TABLE 5.3: Description textuelle du cas d’utilisation

"Supprimer client"

5.4.4 Description textuelle du cas d’utilisation "Modifier client"

Cas d’Utilisation Modifier client

Acteur Responsable vente

74
 5.4. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
5 D’UTILISATION

Objectif Resonsable les ventes peut modifier client.

Précondition Responsable vente doit être authentifié. Respon-

sable vente doit accéder à l’interface gestion des
client .

Postcondition Client Modifié

Scénario nominal — Responsable vente clique sur Gestion des clients.

— Le système affiche l’interface de liste client.
— Responsable vente clique sur le boutton "Modi-
fier client".
— Le système affiche l’interface Modifé.
— Responsable vente clique sur le bouton qui
contient une icône de modifé client sélectionné.
— Le système affiche un formulaire du modification.
— Responsable vente remplit le formulaire d’ajout .
— Responsable vente clique sur le boutton "Modi-
fier".
— Le système vérifie les données saisies
— Le système enregistre les données saisies et in-
dique en message que le mise à jour s’est effectuée
avec succès .

Responsable vente quitte la page de modification

Scénario alternatif d’un client :
Le cas d’utilisation se termine avec échec. Les données
saisies sont incorrectes :
Le système affiche le message d’erreur et signale à
responsable vente de corriger les erreurs mentionnées
dans le message.

TABLE 5.4: Description textuelle du cas d’utilisation

"Modifier client"

75
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

5.4.5 Raffinement de cas d’utilisation «Gérer les commandes »pour l’ac-

teur " Responsable vente"

F IGURE 5.3 – Raffinement du cas d’utilisation"Gérer les commandes".

5.4.6 Description textuelle du cas d’utilisation"Ajouter Commande"

Cas d’Utilisation Ajouter Commande

Acteur Responsable vente

Objectif Resonsable les ventes peut ajouter commande.

Précondition Responsable vente doit être authentifié. Respon-

sable vente doit accéder à l’interface gestion les
ventes .

Postcondition Commande ajouté

76
 5.4. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
5 D’UTILISATION

Scénario nominal — Responsable vente clique sur Gestion les ventes.

— Le système affiche l’interface de liste client.
— Responsable vente clique sur le boutton "Ajouter
commande".
— Le système affiche l’interface d’ajout.
— Responsable vente remplit le formulaire d’ajout .
— Responsable vente clique sur bouton Ajouter
commande.
— Le système vérifie les données saisies .
— Le système ajoute commande dans la base de
données et affiche le message suivant : « com-
mande ajouté avec succès »

Responsable vente quitte la page d’ajout d’un com-

Scénario alternatif mande :
— Le cas d’utilisation se termine avec échec.
Les données saisies sont incorrectes ou manquantes :
— Le système affiche le message d’erreur et Respon-
sable vente de corriger les erreurs mentionnées
dans le message.

TABLE 5.5: Description textuelle du cas d’utilisation

"Ajouter commande"

5.4.7 Description textuelle des cas d’utilisation "Supprimer commande"

Cas d’Utilisation Supprimer commande

Acteur Responsable vente

Objectif Resonsable les ventes peut supprimer com-

mande.

77
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

Précondition Responsable vente doit être authentifié. Respon-

sable vente doit accéder à l’interface gestion les
ventes .

Postcondition Commande est supprimé

Scénario nominal — Responsable vente clique sur Gestion les ventes.

— Le système affiche l’interface de liste commande.
— Responsable vente clique sur le boutton "suppri-
mer commande".
— Le système affiche l’interface .
— Responsable vente clique sur le bouton qui
contient une icône de suppression commande sé-
lectionné.
— Le système affiche un pop-up de confirmation de
suppression.
— Responsable vente confirme la suppression.
— Le système enregistre la suppression et indique
par message que la suppression s’est effectuée
avec succès .

Scénario alternatif Responsable vente clique sur bouton Non.

Le cas d’utilisation se termine avec échec .

TABLE 5.6: Description textuelle du cas d’utilisation

"Supprimer commande"

5.4.8 Description textuelle du cas d’utilisation "Modifier commande"

Cas d’Utilisation Modifier commande

Acteur Responsable vente

78
 5.4. DESCRIPTION TEXTUELLE ET RAFFINEMENT DES PRINCIPAUX CAS
5 D’UTILISATION

Objectif Resonsable les ventes peut modifier commande.

Précondition Responsable vente doit être authentifié. Respon-

sable vente doit accéder à l’interface gestion les
ventes .

Postcondition Commande Modifié

Scénario nominal — Responsable vente clique sur Gestion les ventes.

— Le système affiche l’interface de liste commande.
— Responsable vente clique sur le boutton "Modi-
fier commande".
— Le système affiche l’interface Modifé.
— Responsable vente clique sur le bouton qui
contient une icône de modifé commande sélec-
tionné.
— Le système affiche un formulaire du modification.
— Responsable vente remplit le formulaire d’ajout .
— Responsable vente clique sur le boutton "Modi-
fier".
— Le système vérifie les données saisies
— Le système enregistre les données saisies et in-
dique en message que le mise à jour s’est effectuée
avec succès .

Responsable vente quitte la page de modification

Scénario alternatif d’un commande :
Le cas d’utilisation se termine avec échec. Les données
saisies sont incorrectes :
Le système affiche le message d’erreur et signale à
responsable vente de corriger les erreurs mentionnées
dans le message.

TABLE 5.7: Description textuelle du cas d’utilisation

"Modifier commande"

5.4.9 Diagramme du cas d’utilisation « visualiser tableau de bord»

79
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.4 – Raffinement du cas d’utilisation"Visualiser tableau de bord".

5.4.10 Description textuelle du cas d’utilisation "visualiser les nombres

des productions"

Cas d’Utilisation visualiser les nombres productions

Acteur Superviseur générale

Objectif Afficher les nombres des productions.

Précondition — Superviseur générale doit être authentifié.

— Le superviseur générale doit consulter la page
«tableau de bord».

Postcondition Le superviseur générale peut voir les nombres

des productions.

Scénario nominal — Le superviseur générale cliquer sur bouton "da-

shboards".
— la systéme affiche l’interface.
— le superviseur générale voir les nombres des pro-
ductions.

TABLE 5.8: Description textuelle du cas d’utilisation

"Modifier commande"

80
5 5.5. CONCEPTION

5.5 Conception
Dans cette section , nous présentons le diagramme de classe et les différents diagrammes
de séquence détaillés de ce sprint .

5.5.1 Diagramme de classe du troisiéme sprint

Les diagrammes de classes sont l’un des types de diagrammes UML les plus utiles, car
ils décrivent clairement la structure d’un système particulier en modélisant ses classes, ses
attributs, ses opérations et les relations entre ses objets. Ci-dessous le diagramme de classes
du troisiéme sprint.

F IGURE 5.5 – Diagramme de classes du troisiéme sprint

81
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

5.5.2 Modèle relationnel du sprint 3

Nom Schéma relationnel

du
sprint

Sprint 3 — Utilisateur(idU,nom,prenom,email,username,password,role).
— SuperviseurGénéral (idS,#idU).
— Responsableproduction(idP,#idU).
— Responsablevente(idV,#idU).
— Production(idProd,datecreation,nombrepiecedef, nombrepiece,#idPdt).
— Produit (idPdt,référence,datecreation,stock).
— Commande(idC,quantite, date,qualite,livraison,#idPdt,#idClt).
— Client(idClt,nom,email,adresse,#idC).

TABLE 5.9: Modèle relationnel du sprint 3

82
5 5.6. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

5.6 Diagrammes de séquences détaillés

5.6.1 Diagramme de séquence «Ajouter client» pour Responsable vente

F IGURE 5.6 – Diagramme de séquences «Ajouter Client»

5.6.2 Diagramme de séquence « Supprimer client » pour Responsable

vente

83
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.7 – Diagramme de séquences «Supprimer Client»

5.6.3 Diagramme de séquence « Modifier client » pour Responsable vente

84
5 5.6. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

F IGURE 5.8 – Diagramme de séquences «Modifier Client»

5.6.4 Diagramme de séquence «Ajouter commande» pour Responsable

vente

85
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.9 – Diagramme de séquences «Ajouter Commande»

5.6.5 Diagramme de séquence « Supprimer commande » pour Respon-

sable vente

86
5 5.6. DIAGRAMMES DE SÉQUENCES DÉTAILLÉS

F IGURE 5.10 – Diagramme de séquences «Supprimer Commande»

5.6.6 Diagramme de séquence « Modifier commande » pour Responsable

vente

87
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.11 – Diagramme de séquences «Modifier Commande»

5.6.7 Diagramme de séquence « visualiser les nombres des productions »

F IGURE 5.12 – Diagramme de séquences «Visualiser les nombres des productions»

88
5 5.7. TEST ET VALIDATION

N.B : Ce diagramme montre visualiser les nombres des productions, le même principe
pour les autres interfaces tels que :la qualité des commandes.

5.7 Test et validation

Le tableau suivant montre un ensemble de cas de scénario de tests fonctionnels relatifs
au sprint.

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

Ajouter Responsable — Afficher l’espace « Ajouter Conforme

client vente remplit client». Afficher un mes-
le formulaire sage d’erreur si :
«Ajouter client» .
— Une information obliga-
toire manquante .
— La syntaxe des champs est
invalide .

Supprimer Responsable — Afficher un message le Conforme

client vente de l’ap- client est supprimer avec
plication peut succès. Afficher un mes-
supprimer un sage d’erreur si :
client.
— Une information obliga-
toire manquante .
— La syntaxe des champs est
invalide . .

Modifier Responsable — Afficher un message le Conforme

client vente de l’ap- client est modifier avec
plication peut succès. Afficher un mes-
modifier un sage d’erreur si :
client .
— Une information obliga-
toire manquante .
— La syntaxe des champs est
invalide . .

89
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

Ajouter Responsable — Afficher l’espace « Ajouter Conforme

com- vente remplit commande». Afficher un
mande le formulaire message d’erreur si :
«Ajouter com-
— Une information obliga-
mande» .
toire manquante .
— La syntaxe des champs est
invalide .

Supprimer Responsable — Afficher un message le Conforme

com- vente de l’ap- commande est supprimer
mande plication peut avec succès. Afficher un
supprimer un message d’erreur si : —
commande. Une information obliga-
toire manquante . — La
syntaxe des champs est in-
valide . .

Modifier Responsable — Afficher un message le Conforme

com- vente de l’ap- commande est modifier
mande plication peut avec succès. Afficher un
modifier un message d’erreur si : —
commande . Une information obliga-
toire manquante . — La
syntaxe des champs est in-
valide . .

Visualiser Introduire les in- Visualisation d’un tableau Conforme

tablaux de formations pour de bord.
bord visualiser le ta-
bleau de bord .

TABLE 5.10: Tests et résultats de sprint 3

5.8 Réalisation
Dans cette section, nous allons présenter quelques interfaces de notre application à tra-
vers différents imprimes écrans réalisés qui illustrent le succès des implémentations.

5.8.1 Interface gestion des clients

L’interface de gestion des ventes est illustrée à la figure 5.12 . Dans cette interface, nous
pouvons consulter la liste des clients. Nous pouvons aussi naviguer vers l’inter- face ajouter,

90
5 5.8. RÉALISATION

modifier et supprimer un ou pleusieur clients.

F IGURE 5.13 – Interface gestion des clients

5.8.2 Interface ajouter client

L’interface ajouter client est illustrée à la figure 5.14 qui permet à responsable les ventes
d’ajouter un nouveau client.

F IGURE 5.14 – Interface d’ajout client

5.8.3 Interface modifier client

91
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.15 – Interface modifier client

5.8.4 Interface de suppression client

L’interface de suppression les clients permet de rechercher et supprimer des clients en
utilisant des critères de filtrage. Après avoir sélectionné un utilisateur à supprimer, un mes-
sage de confirmation s’affiche pour confirmer la suppression.

F IGURE 5.16 – Interface suppression d’un client

5.8.5 Interface gestion des commandes

L’interface de gestion des ventes est illustrée à la figure 5.17 . Dans cette interface, nous
pouvons consulter la liste des commandes. Nous pouvons aussi naviguer vers l’inter- face
ajouter, modifier et supprimer un ou pleusieur commandes.

92
5 5.8. RÉALISATION

F IGURE 5.17 – Interface gestion des commandes

5.8.6 Interface ajouter commande

L’interface ajouter commande est illustrée à la figure 5.18 qui permet à responsable les
ventes d’ajouter un nouveau commande.

F IGURE 5.18 – Interface d’ajout commande

5.8.7 Interface modifier commande

93
5 CHAPITRE 5. MISE EN OEUVRE DE SPRINT 3

F IGURE 5.19 – Interface modifier client

5.8.8 Interface de suppression commande

L’interface de suppression les commandes permet de rechercher et supprimer des com-
mandes en utilisant des critères de filtrage. Après avoir sélectionné un utilisateur à suppri-
mer, un message de confirmation s’affiche pour confirmer la suppression.

F IGURE 5.20 – Interface suppression d’un commande

5.8.9 Interface Tableau de bord

94
5 5.9. CONCLUSION

F IGURE 5.21 – Interface Tablau de bord

5.9 Conclusion
A ce stade , nous avons réussi donc à développer le dernier release de notre application
pour arriver à un produit complet et fonctionnel .Notre produit et donc prêt à être exploité
en offrant la possibilité de gérer convenablement toutes les fonctionnalités de notre applica-
tion web .

95
 Conclusion générale
Ce rapport représente le fruit d’un travail réalisé au sein société "Autolive" dans le cadre
de mon projet de fin d’études pour de l’obtention du diplôme de Licence en informatique
appliqué la gestion à l’université de FSJEGJ.
Il s’agit en effet de concevoir et réaliser une application web avec un système de recomman-
dation pour suivre la gestion des productions .On a amis notre connaisance théoriques et
pratiques acquises durant notre parcour universitaire pour etudier , analyser , concervoir
et développer une application web qui concerne la gestion des productions . Nous avons
essayé tout au long de notre travail de construire notre application en utilisant la méthodo-
logie SCRUM .
Dans un premier lieu nous avons commencé par étuder le contexte générale de notre ap-
plication et identifier les différentes exigences de notre futur système, nous avons préparé
par la suite notre planning de travail en respectant les priorités de nos besoins suite à une
discussion avec le Scrum Master, tout en respectant aussi le product Backlog du nfait que en
as réussé a réaliser le travail visualiser la totalité de notre application, tout en préparant la
documentation nécessaire.
La réalisation de ce projet nous a permis de se confronter à plusieurs contraintes tels que la
gestion du temps et l’apprentissage de certaines technologies.

Ce travail nous a appris comment réussir un travail de groupe, comment compter sur soi
pour résoudre les problèmes au cas où ils se présentent, comment être bien organisé pour
accomplir aux meilleurs délais et aux meilleurs conditions les tâches qui nous sont confiées

Finalement, ce projet peut être amélioré et étendu par l’ajout d’autres fonctionnalités ou
le développement d’une version mobile de notre application .

96
 Bibliographie
[1] https ://[Link]/methodologie-de-travail/ (Consulté le 12/03/2024)

[2] https ://[Link]/digitalguide/sites-internet/developpement-web/uml-un-langage-de-

modelisation-pour-la-programmation-orientee-objet/(Consulté le 16/03/2024)
}

[3] https ://[Link]/blog/pattern-mvvm/(Consulté le 16/03/2024)

}
[4] https ://[Link]/web-tech/dictionnaire-du-webmastering/1203555-java-
definition/(Consulté le 18/03/2024)
}
[5]
[6] https ://[Link]/definition overleaf(Consulté le 18/03/2024)
}
[7] https ://[Link]/ Angular(Consulté le 19/03/2024)
}

[8] https ://[Link]/fr/docs/Web/HTML HTMl(Consulté le 20/03/2024)

}

[9] https ://[Link]/ bootstrap(Consulté le 21/03/2024)

}

[10] https ://[Link]/fr/ MySql(Consulté le 22/03/2024)

}
[11] https ://[Link]/(Consulté le 23/03/2024)
}

[12] https ://[Link]/glossaire/sprint/(Consulté le 24/03/2024)

}

97