Pfe Ult 4

Projet fin d’études
Haffar Nadia Trabelsi Adel
September 2020
Sommaire
1 Liste des abréviations 7
2 Dédicaces 8
3 Dédicaces 9
4 Remerciements 10
5 Introduction générale 11
6 Étude préalable 12
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Présentation de l’université . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Profil de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1 Organigramme de la société d’accueil . . . . . . . . . . . . . . . . . . . . 13
6.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.2 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4.3 Intêrét de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5.1 Analyse de la solution ISP . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 Spécification des besoins 19

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2 Méthode de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1 La gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.2 Méthodologies de développement . . . . . . . . . . . . . . . . . . . . . . 19
7.2.3 Comparaison entre les méthodes . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3 Etude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1
SOMMAIRE
7.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4 Backlog sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . 27
7.5 Étude des technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.5.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.6 Architecture et framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.6.1 Framework ”Spring Boot” pour la partie Backend . . . . . . . . . . . . . . 31
7.6.2 Framework Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.6.3 Framework Angular pour la partie FrontEnd . . . . . . . . . . . . . . . . . 32
7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8 Sprint 1 33
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3 Indicateurs clés de performance KPI . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.3.1 Les formules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.4 Nettoyage de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.5 Digramme de classe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.6 Transformation en requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9 Sprint 2 44
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.3 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . 46
9.3.1 Description textuelle du scénario d’authentification . . . . . . . . . . . . 47
9.3.2 Diagramme de séquence ”S’authentifier” . . . . . . . . . . . . . . . . . . 47
9.3.3 Description textuelle du scénario d’ajout membre . . . . . . . . . . . . . . 48
9.3.4 Diagramme de séquence ”Ajouter membre” . . . . . . . . . . . . . . . . . 48
9.3.5 Description Textuelle du scénario supprimer membre . . . . . . . . . . . . 49
9.3.6 Diagramme de séquence ”Supprimer membre” . . . . . . . . . . . . . . . 50
9.4 Test et Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2
SOMMAIRE
10 Sprint 3 55
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.2 Backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.3.1 Description textuelle du cas ”Consulter CA” . . . . . . . . . . . . . . . . 57
10.3.2 Description textuelle du cas ”Consulter FPY” . . . . . . . . . . . . . . . . 58
10.3.3 Diagramme de séquence du cas d’utilisation ”Consulter FPY” . . . . . . . 58
10.3.4 Description textuelle du cas ”Consulter PPM” . . . . . . . . . . . . . . . . 59
10.3.5 Description textuelle du cas ”Consulter taux de rebut” . . . . . . . . . . . 60
10.3.6 Diagramme de séquence du cas d’utilisation ”Consulter taux de rebut” . . . 60
10.3.7 Description textuelle du cas ”consulter TRS” . . . . . . . . . . . . . . . . 61
10.3.8 Diagramme de séquence du cas d’utilisation ”Consulter TRS” . . . . . . . 61
10.3.9 Description textuelle du cas ”consulter OTD” . . . . . . . . . . . . . . . . 62
10.3.10 Diagramme de séquence du cas d’utilisation ”Consulter OTD” . . . . . . . 62
10.3.11 Description textuelle du cas ”consulter l’efficience” . . . . . . . . . . . . . 63
10.3.12 Diagramme de séquence du cas d’utilisation ”Consulter efficience” . . . . 63
10.3.13 Description textuelle du cas ”consulter Temps d’arrêt” . . . . . . . . . . . 64
10.3.14 Diagramme de séquence du cas d’utilisation ”Consulter temps d’arrêt” . . 64
10.4 Test et réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
11 Conclusion générale 68
12 Nétographie 69
13 Réalisation d’un tableau de bord KPI 70
3
Liste des figures
6.1 Université libre de Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.2 Société d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3 Société d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4 Organigramme de la société d’accueil . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5 Page d’accueil ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6 Affichage Efficience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.7 Affichage TRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.8 Affichage Taux de rebut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Contraintes du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7.2 Méthode agile scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3 DCU global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4 Fonctionnement du REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1 Formule TRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.2 Base de données de l’usine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Base de données de l’usine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.5 Requête CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.6 Requête efficience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.7 Requête taux de rebut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.8 Requête TRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.9 Requête OTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.10 Requête PFY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.11 Requête temps d’arrêt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.12 Requête PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9.2 Diagramme de séquence s’authentifier . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3 Diagramme de séquence ”Ajouter membre” . . . . . . . . . . . . . . . . . . . . . 49
9.4 Diagramme de séquence ”supprimer membre” . . . . . . . . . . . . . . . . . . . . 50
9.5 Page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4
LISTE DES FIGURES
9.6 Erreur d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9.7 Page de gestion membres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.8 Ajouter membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.9 Message d’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.10 Affectation rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.11 Supprimer membre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

10.2 Diagramme de séquence consulter FPY . . . . . . . . . . . . . . . . . . . . . . . 59
10.3 Diagramme de séquence consulter taux de rebut . . . . . . . . . . . . . . . . . . . 60
10.4 Diagramme de séquence consulter TRS . . . . . . . . . . . . . . . . . . . . . . . 61
10.5 Diagramme de séquence consulter OTD . . . . . . . . . . . . . . . . . . . . . . . 62
10.6 Diagramme de séquence consulter efficience . . . . . . . . . . . . . . . . . . . . . 63
10.7 Diagramme de séquence consulter temps d’arrêt . . . . . . . . . . . . . . . . . . . 64
10.8 Affichage CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.9 Affichage PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.10Affichage FPY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
10.11Affichage OTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.12Affichage TRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.13Affichage efficience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.14Affichage taux de rebut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10.15Affichage temps d’arrêt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5
Liste des tableaux
6.1 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1 Tableau de comparaison entre les méthodes . . . . . . . . . . . . . . . . . . . . . 20

7.2 Tableau de comparaison entre les méthodologies . . . . . . . . . . . . . . . . . . 21
7.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4 Backlog sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1 Backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1 Backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6
Liste des abréviations
KPI : Key performance indicator

PPM : Pièce Par million
FPY : First Pass Yield
OTD : On Time Delivery
CA : Chiffre d’Affaires
7
Dédicaces
Je dédie ce modeste travail :

A celui qui a toujours garni mon chemin avec sagesse, force et lumière... mon
très cher père et la plus belle perle du monde ma tendre mère. Ils ont toujours été là
pour moi et m’ont donné un magnifique modèle de labeur et de persévérance.
J’espère qu’ils trouveront dans ce travail toute ma reconnaissance, tout mon
amour et ses sacrifices tout au long de mes années d’études.
A mes soeurs et mes beaux frères pour leur patience et leur soutien qu’ils n’ont
cessés d’apporter au cours de ma vie, en leurs souhaitant tout le succès et tout le bonheur.
A mes amies pour l’amour et le respect qu’elles m’ont toujours accordé et une
sincérité si merveilleuse et inoubliable. Je vous souhaite le bonheur dans vos vies.
A toute personne, qui m’a aidé à franchir un autre pallié dans ma vie
8
Dédicaces
Je dédie ce modeste travail :

A celui qui a toujours garni mon chemin avec sagesse, force et lumière... mon
très cher père et la plus belle perle du monde ma tendre mère. Ils ont toujours été là
pour moi et m’ont donné un magnifique modèle de labeur et de persévérance.
J’espère qu’ils trouveront dans ce travail toute ma reconnaissance, tout mon
amour et ses sacrifices tout au long de mes années d’études.
A ma chère sœur et mes frères pour leur patience et leur soutien qu’ils n’ont
cessés d’apporter au cours de ma vie, en leurs souhaitant tout le succès et tout le bonheur.
A mon cher ami Safwen qui m’a toujours soutenu et pour l’amour et le respect
qu’il m’a toujours accordé.
A tous mes amis pour une sincérité si merveilleuse et inoubliable. Je vous
souhaite le bonheur dans vos vies.
A toute personne, qui m’a aidé à franchir un autre pallié dans ma vie
9
Remerciements
Tout d’abord, nous tenons à remercier toute l’équipe d’ULT qui nous a bien accueilli
et encadré tout le long de nos études. Nous tenons évidement à féliciter les enseignants
pour leurs qualités humaines et multiples compétences : aux niveaux scientifique, pédagogique
et en expertise ; ce qui nous ont offert la chance d’exprimer nos talents.
Nous remercions également mademoiselle « Laayouni Olfa », qui a accepté de
superviser notre travail, pour l’aide et les conseils qu’elle nous a prodigué concernant
le cheminement de ce rapport.
Nous tenons à remercier tout particulièrement et à témoigner toute notre reconnaissance
à messieurs « Attia Chaker », chef de projet et responsable, pour son accueil et la
confiance qu’il nous a accordé dès notre arrivée dans l’entreprise « Tis Circuit » et
pour nous voir intégré rapidement au sein de l’équipe.
Enfin, nous remercions nos amis et tous ceux qui ont contribué directement ou
indirectement à la réalisation de ce travail.
10
Introduction générale
De nos jours, les entreprises agissent dans un environnement dynamique marqué par
la complexité et l’incertitude. Avec la mondialisation de l’économie et l’ouverture des
frontières, les entreprises sont face à une concurrence agressive vu que l’écoulement de
leurs produits est dans un marché où seules les entreprises bien organisées peuvent se
permettre une bonne part du marché.
Considéré depuis longtemps comme valeur stratégique en raison de son importance,
le contrôle de gestion est devenu une source de progrès et d’amélioration potentiels
à tous les types d’entreprises. Pour celles qui ont une faible organisation, ils doivent
se marginaliser car leur survie dépend de l’amélioration de leurs performances. En
outre, le contrôle de gestion peut être perçu comme une amélioration de performance
de l’entreprise.
Dans cette perspective, afin de permettre un soutien informationnel à l’organisation et
une bonne prise de décision les tableaux de bord semblent être des outils indispensables
pour une direction plus réfléchie des opérations et de la stratégie d’ensemble.
11
Étude préalable
6.1 Introduction
Dans ce premier chapitre, nous allons commencer par présenter l’organisme d’accueil, définier le
contexte de notre projet et décrire la problématique pour arriver à la fin à proposer notre solution.
6.2 Présentation de l’université

L’université Libre de Tunis est un établissement d’enseignement supérieur privé qui par sa large
gamme de programmes d’études et de ses activités diversifiées en dehors du cadre académique a pour
mission de former aussi bien la relève que les personnes en situation d’emploi, de rendre accessible la
connaissance de pointe à tous les milieux sociaux et culturels et de servir la collectivité qui lui exprime
ses besoins.
Figure 6.1: Université libre de Tunis
6.3 Profil de l’entreprise

Tis circuits est né sur le site de la Soukra (Tunisie) au sein du groupe Satelec. Reprise en 2002
par Sagem, l’usine devient rapidement un fleuron de l’industrie locale. Tis circuits a un riche passé
industriel dans la fabrication de cartes électroniques et se positionne aujourd’hui comme un acteur
majeur de la sous-traitance électronique low cost au maghreb sur les marchés de l’énergie, de l’automatisme,
de l’électroménager et de l’automobile.
12
CHAPTER 6. ÉTUDE PRÉALABLE
Figure 6.2: Société d’accueil
Cette entreprise industrielle fait partie du groupe français ALL Circuits et est répartit en
quatre UAP :
• UAP SHNEIDER
• UAP GE
• UAP PE
• UAP Automobile
Figure 6.3: Société d’accueil
6.3.1 Organigramme de la société d’accueil

La figure suivante présente l’organigramme de la société d’accueil ”Tis Circuit”.
13
Figure 6.4: Organigramme de la société d’accueil
6.4 Présentation du projet
6.4.1 Contexte du projet

Dans le cadre de l’obtention du diplôme national d’ingénieur à l’Université Libre de Tunis, notre
projet de fin d’études au sein de Tis circuits consiste à développer un dashboard pour permettre la
visualisation des indicateurs de performance (KPI), le suivi et l’exploitation facile de données sous
forme de chiffres, ratios et graphiques.
6.4.2 Objectifs du projet

L’objectif de notre projet consiste à créer un outil d’aide à la décision, notre dashboard sera un
moyen d’apprentissage et un système d’alerte pour le chef d’entreprise. Il lui permet de prendre les
mesures nécessaires lorsque des écarts sont détectés entre ce qui est prévu et ce qui se passe réellement
et ainsi tirer des conclusions sur ces écarts constatés et les actions mises en place pour corriger le tir.
Le responsable est ainsi réactif en cas de problème.
6.4.3 Intêrét de l’application

L’utilisateur a la possibilité de consulter le chiffre d’affaire atteint par jour, de voir le taux de
rendement synthétique(TRS) qui met en évidence les pertes de production et mesure la performance
des lignes de production, de savoir les pièces passées bonnes dès le premier coup (FPY), de consulter
le pourcentage des commandes produites à temps pour les clients par rapport au total des commandes
(OTD), de consulter pendant le mois courant le nombre de pièces qui reviennent chez le fournisseur
14
car elles présentent un défaut (PPM), de voir le nombre des pièces jetées par jour (taux de rebut), de
vérifier les cartes produites Bonnes par rapport au temps d’occupation du Poste de travail (Efficience),
de vérifier le temps d’occupation par poste afin d’être réactif en cas de panne et savoir le responsable
(Temps d’arrêt).
6.5 Etude de l’existant

Avant d’entamer la réalisation de tout projet, nous sommes appelés à étudier et bien analyser l’existant
pour profiter de ses avantages et éviter ses malveillances. Pour cela, nous avons exploré tous les
ateliers pour pouvoir récupérer des informations concernant les applications existantes.
6.5.1 Analyse de la solution ISP

Cette analyse consiste à étudier les avantages et les inconvénients de l’application ISP pour pouvoir
enrichir notre solution et éviter les failles déjà rencontrées.
Figure 6.5: Page d’accueil ISP
15
Inconvénients
Figure 6.6: Affichage Efficience
Figure 6.7: Affichage TRS
• Efficience par poste n’affiche rien
• TRS n’affiche rien
• Inexistance des autres KPI ils sont traités par l’équipe traçabilité
• La barre de Note info est encore en cours de construction
• Calcul du retour client n’est pas en marche
• mauvaise ergonomie
16
• Pas de logo de l’usine
Avantages
• Titres claires
• Calcul du chiffre d’affaire par jour
• Affichage taux de rebut
• Produit un rapport de production
Figure 6.8: Affichage Taux de rebut
17
6.6 Solution proposée
Inconvénients Solutions proposées

Des KPI qui n’existent pas sur des Notre application calculera tous les
applications, ils sont traités à part par indicateurs demandés
l’équipe traçabilité
Pour calculer l’efficience j-1 ils Notre application sera autonome et
dépendent de l’équipe traçabilité ne dépend pas de l’équipe traçabilité
pour extraire les données pour calculer l’efficience
Ils existent plusieurs applications Notre application regroupera tous les
pour calculer les KPI indicateurs ensemble en une seule
interface
• Tis portail pour calculer le
chiffre d’affaires seulement
• iPro pour calculer le TRS
• Click View pour calculer

l’efficience
Notre application aura une seule

• Pas de charte graphique template et une charte graphique
• pas de template commune
• Différents input
Taux de réponse faible à cause de la Taux de réponse optimisé avec une

technologie de développement technologie plus évoluée
Dans le code, il ya des requêtes SQL Notre application utilisera des
qui nécessite à chaque fois une procédures stockées
compilation et une exécution
Table 6.1: Solution proposée
6.7 Conclusion
Dans ce chapitre, nous avons défini le contexte du projet et ses objectifs, nous avons analysé
l’existant et tiré une meilleure solution. le chapitre suivant comportera la méthode de travail choisie.
18
Spécification des besoins
7.1 Introduction
Le deuxième chapitre révèle la méthode de travail choisie après avoir étudié les différentes méthodologies
de développement. Dans sa deuxième partie, nous nous intéressons aux besoins fonctionnels et non
fonctionnels.
7.2 Méthode de travail
7.2.1 La gestion de projet

Le projet est un ensemble d’activités et d’actions ordonnées afin de répondre à un besoin spécifique
dans un délai déterminé. Dans ce cadre, une équipe est formée visant à organiser le bon déroulement
du projet en appliquant les méthodes, techniques et outils de gestion spécifiques aux différentes étapes
du projet. Pour réssuir un projet, l’équipe est appelée à respecter le temps, le coût et le contenu.
Figure 7.1: Contraintes du projet
7.2.2 Méthodologies de développement

Afin de répondre aux beoins du client, nous suivons une méthode d’analyse et de conception qui part
d’un ensemble de principes théoriques, suit une démarche conforme aux besoins du client et recourt
à un ensemble de modèles pour décrire les éléments pertinents de la réalité. Nous distinguons deux
familles de méthodes: les méthodes agiles et les méthodes classiques.
Les méthodes agiles
Une méthode agile est une méthode de développement informatique reposant sur un cycle de développement
itératif, incrémental et adaptatif impliquant au maximum le demandeur(client). Son principe itératif
19
CHAPTER 7. SPÉCIFICATION DES BESOINS
qui consiste à découper le projet en plusieurs étapes implique dans chaque itération le client en détaillant
les différentes fonctionnalités qui seront développées en fonction de leur priorité.
Les méthodes classiques
Une méthode traditionnelle est une méthode de développement informatique reposant sur des approches
séquentielles basées sur un découpage des projets par tâche bien définies en impliquant la vérification
et la validation à la fin de chaque étape. Ainsi, le projet dans les méthodes classiques est plannifié de
bout en bout.
7.2.3 Comparaison entre les méthodes

Afin de bien choisir la méthode qui répond parfaitement aux exigences du client et fournit l’ouvrage
dans les plus brefs délais, nous sommes appelés à effectuer une étude comparative entre les méthodes
pour en séléctionner la meilleure selon nos besoins. Le tableau ci-dessous représente les différences
entre les deux méthodes.
Eléments du projet Méthodes classiques Méthodes agiles

Cycle de vie Approche séquentielle Approche itérative
Planification Découpage par étape/ découpage par plusieurs
vérification et étapes/ implique le
validation après chaque client dans chaque
étape itération
Documentation En quantité importante Réduite
Qualité Contrôle qualité à la fin Contrôle de qualité dès
du cycle le début du projet
Changement A la fin de la phase de Intégré au processus de
la mise en oeuvre paramétrage
Mesures de succés Respecte les contraintes Rapidité
mises dès le début d’implémantation/
Satisfaction du client
acquise puisqu’il
participe tout au long
du projet
Table 7.1: Tableau de comparaison entre les méthodes
Nous choisissons de travailler avec la méthode agile car elle implique le client tout au long du
projet et ceci garantit sa satisfaction à la fin, en addition, sa documentation est réduite contrairement
aux méthodes classiques, de plus elle assure un contrôl de qualité du projet dès le début.
20
7.2.4 Méthodologie adoptée

Après l’étude effectuée, nous avons choisi de travailler avec la méthode agile donc nous sommes
appelés maintenant à adopter une méthodologie. Le tableau ci-dessous représente les différences entre
les méthodologies de développement.
Description Points forts Points faibles

XP(eXtreme Identifier les le suivi est ne convient que
programming) facteurs qui régulier lors des sur des équipes
déterminent le itérations/ des de taille réduite/
projet/ Se tests Mise en oeuvre
concentrer à systématiques floue
l’extrême lors de tout au long du
phases itératives processus de
de développement
développement
et de tests
RUP(Rational Une Générique / Difficile de faire
unified process) implémentation itératif / des mises à jour
du processus incrémental/ des fréquentes /trop
unifié/A la fois livrables gérés et de prévisibilité
méthodologie et contrôlés
un outil prêt à
l’emploi
Scrum Découpage de S’adapte aux Peu de
projets en sprints besoins du client/ documentation
en livrant de auto-organisation écrite/ Ne couvre
manière des équipes/ aucune technique
productive et livraison rapide d’ingénierie de
créative grâce à et régulière/ logiciel
l’auto- s’adapte aux
organisation de changements/
l’équipe de Simplicité des
développement processus de
développement
TUP(Two track Propose un cycle itératif/ Superficiel sur
unified process) de incrémental/ les phases de
développement capacité à gérer développement:
en Y/ cibled des les risques/ support,
projets de toutes définit les profils maintenance,
tailles des intervenants, gestion du
les livrables, les changement...
prototypes...
Table 7.2: Tableau de comparaison entre les méthodologies
21
Suite à cette étude comparative, nous constatons que les quatre méthodologies permettent le travail
itératif et le suivi régulier lors des itérations pour des meilleurs résultats. En ce qui nous concerne, la
méthodoligue scrum nous convient le plus:
• Le client participe tout au long du déroulement du projet
• Le travail se fait avec des équipes de tailles réduites qui est notre cas un travail binôme.
• Livraison rapide est régulière et la progression du projet s’effectue sur une courte durée.
Présentation de scrum
Scrum est un terme emprunté au rugby qui désigne la solidarité et la force qui lient les membres de
l’équipe au succès de l’itération dont un projet Scrum est rythmée avec. Ces itérations sont appelées
”sprint”. Elles sont d’une période de 2 à 4 semaines au maximum.
Figure 7.2: Méthode agile scrum
L’équipe scrum détérmine les tâches du sprint durant la réunion de planification de sprint dans un
backlog-sprint(sous ensemble du backlog produit). A la fin de chaque sprint une démonstration est
présentée au client contenant les derniers développements afin de s’assurer du bon déroulement du
projet.
L’équipe Scrum
• Scrum master: Responsable de la mise en oeuvre du scrum et coach d’équipe. Il veille à

ce que les principes et les valeurs de la méthodologie sont respectés. Il aide à améliorer la
communication au sein de l’équipe et cherche à maximiser la productivité.
• Product owner: reponsable à la gestion du produit backlog et représentant des clients et des
utilisateurs. Il travaille en interaction avec l’équipe de développement qui doit suivre ses instructions.
• L’équipe de développement composée de 3 à 9 personnes (développeur, testeur..) et chargée de

transformer en fonctionnalités utilisables les besoins définis par le product owner.
22
Le processus
Le processus comporte le backlog produit et le backlog sprint qui sont constitués des critères et des
exigences du produit:
• Le backlog produit ”Product backlog” comporte la liste des fonctionnalités du produit.
• Le backlog de sprint ”Sprint backlog” comporte la liste des tâches de chaque fonctionnalité du
backlog produit et leurs estimations .
Planification
La planification du sprint est une étape fondamentale avant de lancer un sprint afin d’obtenir des
meilleurs résultats. Elle est effectuée en collaboration avec toute l’équipe Scrum.
• Release: période de temps consacrée à déployer une version du produit et constituée d’une série
de sprints.
• Sprint: Des itérations de courte durée décrivant un processus de développement souvent complexe
afin de le rendre plus facile à réaliser
La revue des sprints
A la fin du sprint, une démonstration est réalisée afin de valider le travail effectué durant le sprint
avec le client.
7.3 Etude des besoins

Cette partie comportera une étude des besoins fonctionnels des utilisateurs pour parvenir à une
application de bonne qualité et qui répond aux exigences du client.
7.3.1 Besoins fonctionnels

Les besoins fonctionnels de notre application sont:
• S’authentifier
• Gérer membres
• Consulter TRS (taux de rendement synthétique)
• Consulter OTD (On time delivery)
• Consulter PPM (pièce par mille)
• Consulter Taux de rebut
23
• Consulter FPY (First pass yield)
• Consulter CA (Chiffre d’affaire)
• Consulter l’efficience
• Consulter temps d’arrêt
L’authentification
Notre application doit être sécurisée pour la confidentialité des données. L’utilisateur a un badge et
une matricule pour se connecter.
La gestion des membres
L’administrateur peut choisir à qui donner l’accès pour consulter. Il peut ajouter ou supprimer un
membre.
La consultation du TRS
Les membres ont besoin de voir le taux de rendement synthétique (TRS) en temps réel ou bien
choisir une date et afficher le taux à cette date là.
La consultation du OTD
Les membres ont besoin de voir le ratio de pièces délivrées en temps et en heure par rapport au
nombre total de pièces commandées.
La consultation du PPM
Les membres ont besoin de consulter en temps réel le nombre de pièces qui reviennent chez le
fournisseur (PPM) car elles présentent un défaut.
La consultation du Taux de rebut
Les membres ont besoin de savoir le nombre de pièces jetées par jour.
La consultation du FPY
Les membres ont besoin de consulter le rendement de première passe(FPY): les premières pièces
passées bonnes dès le premier coup .
La consultation du CA
Les membres ont besoin de consulter le chiffre d’affaire acquis par jour.
24
La consultation de l’efficience
Les membres ont besoin de consulter les cartes produites Bonnes par rapport au temps d’occupation
du Poste de travail.
La consultation du temps d’arrêt
L’administrateur a besoin de vérifier arrêts de travail de chaque personnel et leurs absences et connâitre
l’occupation par poste afin d’être réactif en cas de panne et savoir le responsable.
7.3.2 Besoins non fonctionnels

Les besoins non fonctionnels agissent de façon indirecte sur le rendement final, ils caractérisent le
système et ne doivent pas ainsi être négligés. Dans ce cas, il faut répondre aux exigences suivantes:
Sécurité
L’une des contraintes les plus importantes c’est que les données affichées sont confidentielles et
doivent être sécurisées. Notre application doit assurer la confidentialité.
Fiabilité
Il n’ya pas place aux erreurs. l’application doit tourner sans erreurs car elle affiche des données de
production. Elle doit aussi satisfaire la période spécifiée dans le cahier de charges.
Ergonomie et bonne interface
L’application doit être claire et simple. Les couleurs des courbes et leurs formes doivent être convenables.
Aptitude à la maintenance et la réutilisation
Afin de maintenir sa réutilisation et assurer sa maintenance le système doit être conforme à une
architecture claire.
7.3.3 Backlog produit

Le backlog de produit est une liste de fonctionnalités livrée par le product owner et destinée à
l’équipe de développement. Il est utilisé pour planifier et détailler les sprints. Les user stories qui
constituent le backlog sont classés par la priorité MOSCOW tel que: M:Must S:Should C:Could
W:Won’t
25
ID Nom du sprint User stories Priorité Estimation

1 Nettoyage et gestion de En tant que développeur je M 2 jours
la base de données dois étudier les formules KPI
la base de données dois filtrer les tables de la base
de données principale
la base de données dois créer une nouvelle base
de données de test
la base de données dois créer les tables filtrées
la base de données dois créer les relations entre
les tables en transformant les
formules KPI en requêtes
6 Authentification En tant qu’administrateur M 7 jours
ou membre je dois
m’authentifier
7 Gestion membres En tant qu’administrateur je C 7 jours
peux ajouter un membre
8 Gestion membres En tant qu’administrateur je C 3 jour
peux supprimer un membre
9 Consulter KPI En tant qu’administrateur ou M 5 jours
membre je peux consulter
PPM
FPY
TRS
OTD
taux de rebut
26
Table 7.3 – continuation backlog sprint 3

ID Nom du sprint User stories Priorité Estimation
Efficience
membre je peux consulter CA
Temps d’arrêt
= 87jours
Table 7.3: Backlog produit
7.3.4 Planification des sprints

• sprint0 : Documentation et recherche
• sprint1: Nettoyage et gestion de la base de données
• sprint2: Authentification et gestion des membres
• sprint3 : Consultation des KPI
7.4 Backlog sprint 0

Le sprint0 a commencé par une exploration dans toute l’usine afin de comprendre le processus
de création des cartes électroniques, nous avons après rassemblé les formules des indicateurs de
performance pour travailler avec et nous les avons étudié un à un et compris leur fonctionnement.
Par la suite, nous avons décidé l’architecture et la technologie de travail.
7.4.1 Diagramme de cas d’utilisation global

Dans cette partie, nous détaillerons le diagramme de cas d’utilisation global afin d’avoir une vision
claire sur le comportement de notre système.
27
User stories Tâches Priorité Estimation

Documentation Comprendre le 1 10 jours
et fonctionnement
recherche des machines
Comprendre et 1 10 jours
collecter les
formules des
indicateurs de
performance
Comprendre le 1 4 jours
fonctionnement
du système
existant
Architecture Choix de 1 4 jours
et l’architecture
framework convenable
Choix du 1 2 jours
framework
adopté
= 30 jours
Table 7.4: Backlog sprint 0
Figure 7.3: DCU global
28
7.5 Étude des technologies
7.5.1 Environnement matériel

Notre application web a été réalisée sur deux ordinateurs ayant les mêmes caractéristiques suivantes:
• Ordinateur Portable : Lenovo
• Système d’exploitation : Windows10
• Processeur : Intel Core i5
• RAM : 8,00
7.5.2 Environnement Logiciel
IntelliJ : également appelé ”IntelliJ,IDEA” ou ”IDJ” est un environnement de dévloppement

integré de technologie Java destiné au développement de logiciel informatique. Il est développé par
Jet Brains et disponible en deux versions : l’une communautaire, open source, sous licence Apache2
et l’autre propriétaire et protégée par une licence commerciale.
Le SQL Server désigne couramment un serveur de base de données. C’est un langage

informatique permettant d’exploiter des bases de données.
29
SQL Serveur Managment Studio: est un outil utilisé dans la gestion des bases de données
de Microsoft SQL Server. Il permet l’interaction entre le code SQL nécessaire à la manipulation des
bases de données par les développeurs comme à la gestion par les administrateurs de bases de données
des différentes instances SQL Server.
Un logiciel qui permet de mettre en place des diagrammes UML. Ces diagrammes sert à
visualiser la conception du système.
Apache Maven est un outil logiciel de gestion et de compréhension de projets. Basé sur le
concept d’un modèle d’objet de projet (POM), Maven peut gérer la construction, le reporting et la
documentation d’un projet à partir d’une information centrale.
TypeScript est un langage open source qui s’appuie sur JavaScript, l’un des outils les plus
utilisés au monde, en ajoutant des définitions de type statiques.
Les types fournissent un moyen de décrire la forme d’un objet, en fournissant une meilleure documentation
et en permettant à TypeScript de valider que votre code fonctionne correctement.
7.6 Architecture et framework

En raison de l’utilisation des applications gourmandes en ressources la performance, le coût et
la maintenance deviennent des challenges à confronter lors du choix de l’architecture à adopter.
L’architecture MVC est ainsi apparue apportant une réponse concrète à tous ces besoins. En effet,cette
architecture offre plusieurs avantages à notre égard :
• Une meilleure organisation du code
• Une diminution de la complexité de la conception ce qui engendre une conception claire grâce
à la séparation des données de la vue et du contrôleur
• Une réutilisation du code dans d’autres applications
30
• Un gain de temps de maintenance
• Une bonne organisation lors de la phase de développement entre différents développeurs
• Une facilitation pour les tests unitaires
7.6.1 Framework ”Spring Boot” pour la partie Backend

La création d’applications utilisant l’architecture MVC peut s’avérer lente et coûteuse. Afin de
profiter pleinement de ses avantages il est recommandé d’utiliser un framework. Spring boot est
un framework qui permet de démarrer rapidement le développement d’applications ou services en
fournissant les dépendances nécessaires et leurs auto-configuration.Ses grands avantages résident dans
son code source très épuré, un temps d’adaptation minime, la création des API Rest et son architecture
MVC.
Structure générale
• Annotation : Permettent de simplifier le code, le framework dans ce cas s’occupe de démarrer

le serveur web et de rédiger les requêtes aux méthodes concernées. Exemple: @GetMapping,
@RestController, @PostMapping...
• Autowiring : Permet d’instancier la classe directement en injectant les dépendances décrites

dans les paramètres de construction.
• Contient l’annotation @RestController et les méthodes de l’API.
• Service : Décrire la logique métier déclarée dans le controller
• Repository : Un mécanisme d’encapsulation de stockage, d’extraction et de recherche via une

BD.
31
Figure 7.4: Fonctionnement du REST API
7.6.2 Framework Hibernate

Hibernate est une solution open source de type ORM (Object Relational Mapping) qui permet de
faciliter le développement de la couche persistance d’une application. Hibernate permet donc de
représenter une base de données en objets Java et vice versa.
Hibernate facilite la persistence et la recherche de données dans une base de données en réalisant
lui-même la création des objets et les traitements de remplissage de ceux-ci en accédant à la base de
données. La quantité de code ainsi épargnée est très importante d’autant que ce code est généralement
fastidieux et redondant.
7.6.3 Framework Angular pour la partie FrontEnd

Comme notre application est composée d’une partie backend déjà étudiée nous passons maintenant
à la partie Frontend développée avec le framework Angular. Angular est un framework dédié pour la
partie Frontend dans les applications web en utilisant HTML et Javascript ou TypeScript compilé en
Javascript. Le Framework est basé sur l’architecture MVC et permet de séparer les données, le visuel
et les actions pour une meilleure gestion des responsabilités.
7.7 Conclusion
Dans ce chapitre, nous avons étudié les différences entre les méthodes agiles et classiques et choisi
scrum parmi les méthodologies évoquées. Nous avons présenté les besoins fonctionnels et non fonctionnels
de l’application et tiré le backlog de produit ainsi que la planification des releases.
32
Sprint 1
8.1 Introduction
Un sprint est une itération de courte durée décrivant un processus de développement souvent complexe
afin de le rendre plus facile à réaliser. Dans ce chapitre, nous détaillerons le travail réalisé durant le
premier sprint. Le développement de chaque sprint passe par les étapes d’analyse de conception et de
réalisation.
8.2 Backlog du sprint 1

Le tableau ci-dessous illustre le backlog du sprint 1 ”Nettoyage et gestion de la base de données”.
33
CHAPTER 8. SPRINT 1

En tant que Faire une 1 2 jours
développeur je recherche sur les
dois étudier les formules
formules KPI
En tant que Extraire les 1 7 jours
développeur je tables utiles pour
dois filtrer les notre application
tables de la base
de données
principale
En tant que créer une base de 1 2 jours
développeur je données dans sql
dois créer une server
nouvelle base de
données de test
En tant que créer les tables 1 7 jours
développeur je dans la BD de
dois créer les test
tables filtrées
En tant que 1 12 jours
faire des requêtes
développeur je
sql
dois créer les
relations entre faire des tests
les tables en
transformant les
formules KPI en
requêtes
= 30 jours
34
CHAPTER 8. SPRINT 1
8.3 Indicateurs clés de performance KPI

Les indicateurs clés de performance (KPI) sont extrêmement importants pour surveiller la production
de l’entreprise et atteindre ses objectifs stratégiques. A l’aide d’un tableau de bord (Dashboroard) la
visualisation et l’interprétation des indicateurs augmentent la rapidité, la compréhension et la transparence
des processus. La première étape dans notre projet était de comprendre chaque KPI et d’extraire sa
formule.
8.3.1 Les formules

1. Chiffre d’affaire : le montant des affaires ( vente des marchandises, services, biens, et de la
production vendue) réalisées par une entreprise avec les tiers
CA = Quantités vendues * prix de vente unitaire
2. Taux de rendement synthétique (TRS) : Met en évidence les pertes de production et mesure la
performance des lignes de production
Figure 8.1: Formule TRS
TRS = taux de disponibilité * taux de performance * taux de qualité
3. Rendement première passe : calculer les pièces passées bonnes dès le premier coup
FPY = total des pièces bonnes (1er passage) / total des 1er passage
4. Taux de rebut : calculer le pourcentage des cartes jetées par jour
Taux de rebut = Nombre de cartes rebutées / total des cartes produites
35
CHAPTER 8. SPRINT 1
5. Efficience : Les cartes produites Bonnes par rapport au temps d’occupation du Poste de travail
(sans calculer les repassages)
Efficience = Nombre de cartes produites bonnes dès le 1er coup / temps

d’occupation par poste
6. Pièces par million : le nombre de pièces défaillantes par rapport à un million de pièces produites
PPM = Nombre de pièces défaillantes / million pièces
7. Temps d’arrêt : Temps d’occupation par poste
8. Fiabilité de livraisons (On time delivery) : évaluer le respect des délais de livraison et la qualité
des fournisseurs
OTD = ratio de pièces délivrées / nombre total des pièces commandées
8.4 Nettoyage de la base de données

Avant d’entamer la réalisation de notre application, nous avons procédé à un nettoyage de la base
de données. La taille de la base de données de toute l’usine est 3 To trop grande et trop lourde. Les
figures suivantes présentent un petit aperçu de la base principale:
36
CHAPTER 8. SPRINT 1
Figure 8.2: Base de données de l’usine
37
CHAPTER 8. SPRINT 1
Figure 8.3: Base de données de l’usine
38
CHAPTER 8. SPRINT 1
8.5 Digramme de classe général

Après nettoyage, nous avons filtré les tables dont nous avons besoin pour réaliser notre application,
crée une base de données de test et les tables. La figure ci-dessous présente le diagramme de classe
de notre application qui sert à présenter les classes et les interfaces du système ainsi que les relations
entre elles.
39
CHAPTER 8. SPRINT 1
Figure 8.4: Diagramme de classe
40
CHAPTER 8. SPRINT 1
8.6 Transformation en requête

Dans cette partie, nous étudierons la transformation de chaque formule en requête selon le besoin du
client.
Commençons par le chiffre d’affaire, nous sommes appelés à afficher le chiffre d’affaire par jour.
La requête créée :
Figure 8.5: Requête CA
Passons ensuite à l’efficience, nous devons afficher le nombre de cartes produites bonnes dès le
premier passage par rapport au temps d’occupation par poste.
La requête créée afin d’afficher l’efficience global et détaillé
Figure 8.6: Requête efficience
Nous détaillerons par la suite la requête créée afin d’afficher le taux de rebut.
Figure 8.7: Requête taux de rebut
Nous procédons ici à la requête créée afin d’afficher le TRS
41
CHAPTER 8. SPRINT 1
Figure 8.8: Requête TRS
Dans la figure suivante nous affichons l’OTD
Figure 8.9: Requête OTD
La figure ci-dessous montre la requête créée pour afficher FPY
Figure 8.10: Requête PFY
Nous continuons avec la requête du temps d’arrêt
Figure 8.11: Requête temps d’arrêt
Nous passons à la requête du PPM dans la figure suivante
42
CHAPTER 8. SPRINT 1
Figure 8.12: Requête PPM
8.7 Conclusion
Dans ce chapitre, nous avons détaillé les différentes étapes réalisées durant le premier sprint de nettoyage
et gestion de base de données en étudiant les formules des KPI et les transformant en requêtes.
43
Sprint 2
9.1 Introduction
Un sprint est une itération de courte durée décrivant un processus de développement souvent complexe
afin de le rendre plus facile à réaliser.
Dans ce chapitre, nous détaillerons le travail réalisé durant le premier sprint. Le développement de
chaque sprint passe par les étapes d’analyse de conception et de réalisation.
9.2 Backlog du sprint 2

Le tableau suivant représente le backlog du sprint 2 ”Authentification et gestion des membres”
44
CHAPTER 9. SPRINT 2

En tant 1 7 jours
créer entités
qu’administrateur
ou membre je créer repositories
dois créer component

m’authentifier login
pour accéder à
créer service
l’application
d’authentification
créer interface
login
En tant qu’admin 2 7 jours
Implémenter
je peux ajouter
méthode ajout
un membre
dans le controller
créer service
créer interface
ajout
En tant 2 3 jours
Implémenter
qu’administrateur
méthode de
je peux
suppression dans
supprimer un
le controller
membre
Appel à la
méthode de
suppression dans
le service
créer bouton
supprimer
= 17 jours
45
CHAPTER 9. SPRINT 2
9.3 Diagramme de cas d’utilisation du sprint 2

Dans cette partie, nous présenterons le diagramme de cas d’utilisation du deuxième sprint afin
d’avoir une vision globale sur le comportement de notre système.
Figure 9.1: Diagramme de cas d’utilisation du sprint 2
46
CHAPTER 9. SPRINT 2
9.3.1 Description textuelle du scénario d’authentification
Cas d’utilisation Authentification

Acteurs
Administrateur
Membre
Précondition L’acteur saisit son badge et son
matricule pour s’authetifier
Post-condition Acteur authentifié
Scénario nominal Le système vérifie l’existence du
membre dans la base de données.
Une fois vérifié l’utilisateur est
authentifié sinon il renvoie un
message d’erreur
Scénario alternatif
Le système indique à l’utilisateur que
le badge ou/et le matricule est
incorrect.
9.3.2 Diagramme de séquence ”S’authentifier”

La figure suivante représente le diagramme de séquence du scénario d’authentification.
Figure 9.2: Diagramme de séquence s’authentifier
47
CHAPTER 9. SPRINT 2
9.3.3 Description textuelle du scénario d’ajout membre
Cas d’utilisation Ajouter un membre

Acteurs Administrateur
Précondition Acteur s’authentifie et remplit les
champs nécessaires à l’ajout du
membre
Post-condition Le système ajoute le membre dans la
base de données
Scénario nominal Le système vérifie l’existence du
membre et renvoie son nom et
prénom en cas de succès.
L’utilisateur confirme et choisit de lui
accorder un rôle d’administrateur ou
pas. L’utilisateur est ajouté
Scénario alternatif
Le système indique à l’administrateur
que le membre qu’il souhaite ajouter
est inexistant.
9.3.4 Diagramme de séquence ”Ajouter membre”

Pour mieux mettre en relief le scénario du cas d’utilisation ajouter membre, nous procédons au diagramme
de séquence présenté dans la figure ci-dessous
48
CHAPTER 9. SPRINT 2
Figure 9.3: Diagramme de séquence ”Ajouter membre”
9.3.5 Description Textuelle du scénario supprimer membre
Cas d’utilisation Supprimer un membre

Acteurs Administrateur
Précondition Acteur s’authentifie et choisit le
membre à supprimer
Post-condition Le système supprime le membre de
la base de données
Scénario nominal L’acteur choisit un membre à
supprimer et le système le supprime
Scénario alternatif Problème de connexion.
49
CHAPTER 9. SPRINT 2
9.3.6 Diagramme de séquence ”Supprimer membre”

La figure suivante présente le diagramme de séquence qui illustre le scénario de suppression d’un
membre.
Figure 9.4: Diagramme de séquence ”supprimer membre”
9.4 Test et Réalisation

Dans cette partie, nous présenterons les différentes interfaces réalisées lors du deuxième sprint. La
figure suivante présente l’interface d’authentification qui s’affiche une fois l’application est lancée.
50
CHAPTER 9. SPRINT 2
Figure 9.5: Page d’authentification
• Si les coordonnées sont erronés un message d’erreur s’affiche indiquant la vérification des
coordonnées.
Figure 9.6: Erreur d’authentification
51
CHAPTER 9. SPRINT 2
• Si les coordonnées sont correctes et l’utilisateur authentifié est un administrateur l’interface de

gestion d’utilisateurs est affiché.
Figure 9.7: Page de gestion membres
• Si l’administrateur souhaite ajouter un membre il clique sur le bouton ”nouvel utilisateur” et un

popup s’affiche
Figure 9.8: Ajouter membre
• Si le membre choisi existe déjà un message d’erreur s’affiche comme suit
52
CHAPTER 9. SPRINT 2
Figure 9.9: Message d’erreur
• Si le membre choisi est valide nous pouvons choisir de lui affecter un rôle d’administrateur ou
pas en cochant la case suivante
Figure 9.10: Affectation rôle
• Pour supprimer un membre nous cliquons sur le bouton supprimer qui se trouve devant chaque
membre
53
CHAPTER 9. SPRINT 2
Figure 9.11: Supprimer membre
9.5 Conclusion
Dans ce chapitre nous avons détaillé le premier sprint en commençant d’abord par la planification
en présentant ensuite la conception des diagrammes et les descriptions textuelles pour enfin arriver à
illustrer dans des figures les interfaces réalisées au cours du premier sprint.
54
Sprint 3
10.1 Introduction
Ce chapitre sera consacré au sprint 3, nous détaillerons avec précision les étapes qui le constituent et
nous présenterons l’interface réalisée ainsi par les multiples courbes.
10.2 Backlog sprint 3

et membre je
peux consulter créer méthode get dans rest
TRS créer une requête native dans
le service
créer componenet dashboard
et membre je créer méthode get dans rest
peux consulter
créer une requête native dans
PPM
le service
mise à jour componenet
dashboard
peux consulter
FPY
le service
dashboard
Page suivante
55
CHAPTER 10. SPRINT 3
Table 10.1 – continuation backlog sprint 3

Nom du sprint User stories Tâches Estimation
peux consulter
OTD
le service
dashboard
peux consulter
Efficience
le service
dashboard
peux consulter
Temps d’arrêt
le service
dashboard
peux consulter
CA
le service
dashboard
peux consulter
Taux de rebut
le service
dashboard
= 40 jours
56
10.3 Diagramme de cas d’utilisation du sprint 3

Durant ce sprint, nous présenterons le diagramme de cas d’utilisation du sprint ”Consulter KPI”
Figure 10.1: Diagramme de cas d’utilisation du sprint 3
10.3.1 Description textuelle du cas ”Consulter CA”
Cas d’utilisation Consulter CA

Acteurs Administrateur, membre
Précondition Acteur authentifié
Post-condition Le système affiche le chiffre d’affaire
Scénario nominal Le système exécute la requête qui
contient la formule, crée les jointures
nécessaires et affiche le chiffre
d’affaire
Scénario alternatif Problème de connexion ou pas de
données.
57
10.3.2 Description textuelle du cas ”Consulter FPY”
Cas d’utilisation Consulter FPY

Post-condition Le système affiche le nombre de
cartes Go et NoGo et le pourcentage
PFY
Scénario nominal L’acteur saisit la date début et fin et
le produit sur lequel il veut calculer
FPY, le système exécute la requête
qui contient la formule, crée les
jointures nécessaires et affiche un
camembert contenant le résultat
données.
10.3.3 Diagramme de séquence du cas d’utilisation ”Consulter FPY”

Ce diagramme de séquence montre le scénario du cas d’utilisation ”consulter FPY”.
58
Figure 10.2: Diagramme de séquence consulter FPY
10.3.4 Description textuelle du cas ”Consulter PPM”
Cas d’utilisation Consulter PPM

Post-condition Le système affiche le une courbe
contenant le pourcentage PPM
le système affiche la courbe adéquate
données.
59
10.3.5 Description textuelle du cas ”Consulter taux de rebut”
Cas d’utilisation Consulter taux de rebut

Post-condition Le système affiche le taux de rebut
données.
10.3.6 Diagramme de séquence du cas d’utilisation ”Consulter taux de rebut”

Ce diagramme de séquence décrit le scénario du cas d’utilisation ”consulter taux de rebut”.
Figure 10.3: Diagramme de séquence consulter taux de rebut
60
10.3.7 Description textuelle du cas ”consulter TRS”
Cas d’utilisation Consulter TRS

Post-condition Le système affiche le TRS
données.
10.3.8 Diagramme de séquence du cas d’utilisation ”Consulter TRS”

Ce diagramme de séquence montre le scénario du cas d’utilisation ”consulter TRS”.
Figure 10.4: Diagramme de séquence consulter TRS
61
10.3.9 Description textuelle du cas ”consulter OTD”
Cas d’utilisation Consulter OTD

Post-condition Le système affiche l’OTD
données.
10.3.10 Diagramme de séquence du cas d’utilisation ”Consulter OTD”

Ce diagramme de séquence présente le scénario du cas d’utilisation ”consulter OTD”.
Figure 10.5: Diagramme de séquence consulter OTD
62
10.3.11 Description textuelle du cas ”consulter l’efficience”
Cas d’utilisation Consulter efficience

Post-condition Le système affiche le taux de rebut
données.
10.3.12 Diagramme de séquence du cas d’utilisation ”Consulter efficience”

Ce diagramme de séquence met en évidence le scénario du cas d’utilisation ”consulter efficience”.
Figure 10.6: Diagramme de séquence consulter efficience
63
10.3.13 Description textuelle du cas ”consulter Temps d’arrêt”
Cas d’utilisation Consulter temps d’arrêt

Post-condition Le système affiche le temps d’arrêt
données.
10.3.14 Diagramme de séquence du cas d’utilisation ”Consulter temps d’arrêt”

Ce diagramme de séquence montre le scénario du cas d’utilisation ”consulter temps d’arrêt”.
Figure 10.7: Diagramme de séquence consulter temps d’arrêt
64
10.4 Test et réalisation

Dans cette partie, nous mettrons les différentes interfaces réalisées lors du troisième sprint. La figure
suivante présente la section réservée à l’affichage du chiffre d’affaire.
Figure 10.8: Affichage CA
La figure suivante présente la section réservée à l’affichage du PPM.
Figure 10.9: Affichage PPM
La figure ci-dessous présente la section réservée à l’affichage du FPY.
Figure 10.10: Affichage FPY
La figure qui suit présente la section réservée à l’affichage du OTD.
65
Figure 10.11: Affichage OTD
La figure suivante présente la section réservée à l’affichage du TRS.
Figure 10.12: Affichage TRS
La figure suivante met en évidence la section réservée à l’affichage de l’efficience détaillé.
Figure 10.13: Affichage efficience
La figure suivante présente la section réservée à l’affichage du taux de rebut.
66
Figure 10.14: Affichage taux de rebut
La figure suivante présente la section réservée à l’affichage du temps d’arrêt.
Figure 10.15: Affichage temps d’arrêt
10.5 Conclusion
Dans ce chapitre, nous avons détaillé le backlog du sprint 3, présenté le diagramme de cas d’utilisation
et décrit pour chaque cas le scénario équivalent dans un diagramme de séquence pour arriver à la fin
à présenter les différentes interfaces réalisées durant ce sprint.
67
Conclusion générale
Le tableau de bord a inauguré une véritable approche du management stratégique

il propose une analyse multidimensionnelle de la performance fondée sur l’équilibre
entre les ambitions stratégiques à long terme et les contraintes opérationnelles à court
terme il vient ainsi en réponse aux insuffisances des systèmes classiques de mesure de
la performance qui, s’intéressant uniquement aux aspects financiers, sont incapables de
faire le lien entre la stratégie et les actions à court terme.
Mais construire un outil de pilotage n’est pas une fin en soi il faut surtout créer une
dynamique dans l’organisation et favoriser l’adhésion de tous les acteurs de l’organisation
à un projet commun.
Par ailleurs, la mise en oeuvre du tableau de bord nécessite une bonne organisation
du mécanisme de collecte, de traitement et de présentation des données afin qu’il soit
à même de produire les indicateurs nécessaires pour le suivi de la performance des
services de l’entreprise Tis circuit. L’analyse permanente des indicateurs obtenus constitue
un gage du succès de la mise en oeuvre du tableau de bord.
Au total, la réalisation de la phase de déploiement du tableau de bord pourra se faire sur
trois mois à compter du mois de Septembre.
68
Nétographie
https://tn.kompass.com/c/tis-circuits/tn853636/ Consulté le 03-08

https://www.fimarkets.com/pages/projets
Consulté le 04-08 https://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/1443838-methode-
agile-definition-comparatif-et-avantages/ Consulté le 04-08
https://www.planzone.fr/blog/quest-ce-que-la-methodologie-scrum Consulté le 05-08
https://www.jmdoudoux.fr/java/dej/chap-hibernate.htm Consulté le 20-08
https://www.typescriptlang.org/ Consulté le 21-08
https://maven.apache.org/ Consulté le 21-08
https://fr.wikipedia.org/wiki/IntelliJ Consulté le 21-08
https://en.wikipedia.org/wiki/SQL Consulté le 21-08
69
Réalisation d’un tableau de bord KPI
RESUME
Notre projet consiste à créer un outil d’aide à la décision, notre tableau de bord sera un moyen
d’apprentissage et un système d’alerte pour le chef d’entreprise. Il lui permet de prendre les mesures
nécessaires lorsque des écarts sont détectés entre ce qui est prévu et ce qui se passe réellement et
ainsi tirer des conclusions sur ces écarts constatés et les actions mises en place pour corriger le tir. Le
responsable est ainsi réactif en cas de problème.
ABSTRACT
Our project consists in creating a decision support tool, our dashboard will be a means of learning
and an alert system for the business manager. It allows him to take the necessary measures when
discrepancies are detected between what is planned and what is actually happening and thus draw
conclusions on these discrepancies observed and the actions taken to correct the situation. The manager
is thus reactive in case of a problem
70

Pfe Ult 4

Transféré par

Droits d'auteur :

Formats disponibles

Pfe Ult 4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pfe Ult 4

Transféré par

Droits d'auteur :

Formats disponibles

Projet fin d’études

Haffar Nadia Trabelsi Adel

1 Liste des abréviations 7

7 Spécification des besoins 19

7.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

13 Réalisation d’un tableau de bord KPI 70

6.1 Université libre de Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7.1 Contraintes du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.1 Formule TRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.1 Diagramme de cas d’utilisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . 46

9.6 Erreur d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

10.1 Diagramme de cas d’utilisation du sprint 3 . . . . . . . . . . . . . . . . . . . . . . 57

6.1 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.1 Tableau de comparaison entre les méthodes . . . . . . . . . . . . . . . . . . . . . 20

8.1 Backlog sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.1 Backlog sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

10.1 Backlog sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

KPI : Key performance indicator

Je dédie ce modeste travail :

Je dédie ce modeste travail :

6.2 Présentation de l’université

Figure 6.1: Université libre de Tunis

6.3 Profil de l’entreprise

Figure 6.2: Société d’accueil

Figure 6.3: Société d’accueil

6.3.1 Organigramme de la société d’accueil

Figure 6.4: Organigramme de la société d’accueil

6.4 Présentation du projet

6.4.1 Contexte du projet

6.4.2 Objectifs du projet

6.4.3 Intêrét de l’application

6.5 Etude de l’existant

6.5.1 Analyse de la solution ISP

Figure 6.5: Page d’accueil ISP

Figure 6.6: Affichage Efficience

Figure 6.7: Affichage TRS

• Efficience par poste n’affiche rien

• TRS n’affiche rien

• La barre de Note info est encore en cours de construction

• Calcul du retour client n’est pas en marche

• Pas de logo de l’usine

• Calcul du chiffre d’affaire par jour

• Affichage taux de rebut

• Produit un rapport de production

Figure 6.8: Affichage Taux de rebut

6.6 Solution proposée

Inconvénients Solutions proposées

• iPro pour calculer le TRS

• Click View pour calculer

Notre application aura une seule

• pas de template commune

Taux de réponse faible à cause de la Taux de réponse optimisé avec une

Table 6.1: Solution proposée

7.2 Méthode de travail

7.2.1 La gestion de projet

Figure 7.1: Contraintes du projet

7.2.2 Méthodologies de développement

Les méthodes agiles

Les méthodes classiques