Conception Et Développement D'un Module ERP Gestion de La Production
Conception Et Développement D'un Module ERP Gestion de La Production
Conception Et Développement D'un Module ERP Gestion de La Production
MEMOIRE
Présenté à
En vue de l’obtention
Par
Mahdi NEIFAR
CONCEPTION ET DÉVELOPPEMENT
D’UN MODULE ERP :
GESTION DE PRODUCTION
I
DEDICACE
Du profond de mon cœur, je dédie ce travail à tous ceux qui me
sont chers,
réussite. Que dieu vous préserve en bonne santé et vous accorde une
longue vie,
A toute ma famille
A tous mes amis, au nom de la belle amitié qui nous réunit, je vous
Neifar Mahdi
II
REMERCIEMENT
Je tiens à remercier tous ceux qui m’ont aidé pour la réalisation de ce
grande estime.
Ben Abdallah, Mme Nouha Besbes, Mme Farah Sallem, Mme Fedia
stage.
III
Table de matières :
Introduction générale............................................................................................................ 1
Introduction ...................................................................................................................... 3
Conclusion ........................................................................................................................ 8
Introduction : .................................................................................................................. 10
IV
2.1.5. Architecture modulaire d'un ERP ............................................................... 11
Conclusion ...................................................................................................................... 17
Introduction .................................................................................................................... 19
Conclusion ...................................................................................................................... 47
V
Chapitre IV : Architecture et conception détaillée du système .......................................... 48
Introduction .................................................................................................................... 49
Conclusion ...................................................................................................................... 66
Introduction .................................................................................................................... 68
Conclusion ...................................................................................................................... 85
VI
Table des figures :
Figure 1: Quelques partenaires de Spark-it ......................................................................... 4
Figure 2 : Présentation générale de Scrum .......................................................................... 8
Figure 3: Vision systémique d'un système de production ................................................. 13
Figure 4: Les flux informationnels et physiques .............................................................. 14
Figure 5: Volume de recherche Web pour les technologies Angular et ReactJS .............. 16
Figure 6 : Diagramme de modélisation de contexte.......................................................... 21
Figure 7 : Diagramme de cas d’utilisation global ............................................................. 26
Figure 8 : Cas d’utilisation de l’authentification............................................................... 27
Figure 9 : Diagramme de cas d'utilisation : Gérer les produits ......................................... 29
Figure 10 : Diagramme de cas d'utilisation : Gérer nomenclatures .................................. 31
Figure 11 : Diagramme de cas d'utilisation : Gérer ateliers .............................................. 35
Figure 12 : Diagramme de cas d'utilisation : Gérer machine ............................................ 37
Figure 13 : Diagramme de cas d 'utilisation : Gérer gammes de fabrication .................... 40
Figure 14 : Diagramme de cas d 'utilisation : gérer ordres de fabrication ........................ 43
Figure 15 : Diagramme de cas d 'utilisation : Traiter les opérations de fabrication.......... 45
Figure 16 : Architecture logicielle .................................................................................... 49
Figure 17 : Architecture de la couche présentation ........................................................... 50
Figure 18 : Architecture physique ..................................................................................... 51
Figure 19 : Diagramme de package de la partie front-end ................................................ 53
Figure 20 : Diagramme de package de la partie back-end ................................................ 55
Figure 21 : Structure de la couche « fr.sparkit.controller » .............................................. 56
Figure 22 : Structure d’une partie de la couche « fr.sparkit.service» ............................... 58
Figure 23: Structure d’une partie de la couche « fr.sparkit.repository»............................ 60
Figure 24 : Structure de la couche « fr.sparkit.entity» ...................................................... 62
Figure 25 : Diagramme de séquence système ˝ Gestion des nomenclatures ˝ .................. 64
Figure 26 : Diagramme de séquence système ˝ Gestion de l’ordre de fabrication ........... 65
Figure 27 : Diagramme d'activité « Traiter une opération» .............................................. 66
Figure 28 : Interface liste des nomenclatures .................................................................... 73
Figure 29: Interface consultation nomenclature ................................................................ 74
Figure 30 : Interface liste des composants avec pagination .............................................. 75
Figure 31 : Interface structure nomenclature sous forme d’une arbre .............................. 76
Figure 32 : Interface suppression d'une nomenclature ...................................................... 77
Figure 33 : Interface notification de suppression d'une nomenclature .............................. 77
VII
Figure 34 : Interface de modification d'une gamme de fabrication .................................. 78
Figure 35 : Interface de création d'un ordre de fabrication ............................................... 79
Figure 36 : Interface :liste des composants manquants en stock ...................................... 80
Figure 37 : Interface de suivi d'un ordre de fabrication ................................................... 81
Figure 38 : Interface :recherche d'une opération de fabrication ........................................ 82
Figure 39 : Interface export informations d'un ordre de fabrication sous forme d'un fichier
.................................................................................................................................................. 83
Figure 40 : Demande de tirage code front-end.................................................................. 84
Figure 41 : Build sur l'environnement d'intégration continue ........................................... 85
VIII
Liste des tableaux :
IX
Introduction générale
Toute entreprise est prête à investir des sommes considérables dans l’implantation des
technologies logicielles afin d’améliorer ses services, d’accroitre son agilité et sa flexibilité, de
réduire les coûts, d’augmenter la production et de faire face aux défis du marché.
En effet, vu la croissance des activités au sein des entreprises, la tâche de gérer efficacement
toutes ces fonctions s’avère de plus en plus complexe et difficile.
En parallèle, avec les améliorations des outils technologiques, l’augmentation des données
à stocker et l’apparition des nouveaux besoins de l’entreprise, la refonte du système
d’information semble être assez importante. Pour surpasser ces difficultés, une entreprise doit
utiliser des outils optimisés et adaptés facilitants les tâches et offrants des fonctionnalités riches
et utiles. Parmi ces outils nous trouvons les systèmes intégrés de gestion tel que les ERP
(Entreprise Ressources Planning). Les ERP sont des outils de gestion et d’analyse permettant
d’optimiser la diffusion des informations en interne, d’améliorer les processus de gestion et
d’automatiser les tâches ce qui augmente énormément la réactivité des entreprises et leurs
agilités. C’est dans ce cadre s’inscrit notre projet de fin d’études qui a pour objectif de concevoir
et de développer un module ERP de gestion de production.
Ce module doit automatiser les différents processus de production à savoir la gestion des
nomenclatures, la planification des ordres des fabrications, la gestion des processus de
fabrication et le suivi des ordres de fabrications.
Notre rapport présente les différentes phases à travers lesquelles nous sommes passés pour
réaliser notre projet. Le premier chapitre intitulé « Présentation du projet », est consacré,
d’abord, à une présentation générale du projet. Ensuite, la problématique est présentée ainsi que
la méthodologie adoptée. Dans le chapitre suivant, intitulé « Étude préalable », nous passons
par un tour d’horizon sur les notions théoriques des ERP. Ensuite, nous faisons une étude de
l’existant et nous finissons par mettre en valeur les technologies utilisées. Dans le troisième
chapitre intitulé « Analyse et spécification des besoins », nous présentons le contexte du projet
à l’aide d’un diagramme de contexte en identifiant l’environnement extérieur au système de
gestion de production avec lequel ce dernier communique suivi par une analyse des besoins
fonctionnels et non fonctionnels de la solution proposée ainsi que la modélisation de ces besoins
par le recours aux diagrammes de cas d’utilisation.
1
A partir de la spécification dégagée, nous abordons, dans le quatrième chapitre,
l’architecture générale de l’application et offrons un aperçu des diagrammes de conception
utilisés.
Cet aperçu mènera à la conception générale des différentes fonctionnalités offertes. Cette
conception est réalisée en utilisant le langage de modélisation UML touchant le comportement
statique de la solution proposée. Ensuite, le cinquième chapitre intitulé « Réalisation » qui est
réservé à l’implémentation de l’application, où nous récapitulons les différents outils utilisés,
présentons les différentes interfaces homme/machine de notre solution proposée. Finalement,
le rapport est clôturé par une conclusion générale qui résume notre travail et propose les
éventuelles perspectives de ce travail.
2
Chapitre I : Présentation du projet
Plan du chapitre :
2
Chapitre I : Présentation du projet
Introduction
Dans ce premier chapitre, nous allons présenter le cadre général du projet. Nous
commencerons d’abord par une présentation générale de l’organisme d’accueil, à savoir Spark-
it. Par la suite, nous allons expliquer et détailler le sujet du projet. Nous allons aussi faire une
étude des solutions existantes et expliquer leurs limites. Enfin, nous présenterons la
méthodologie de travail utilisée pour la réalisation du projet.
Spark-it est une Société de Services et d’ingénierie Informatique et d’édition logicielle créée
en France en 2013. Elle a développé ses activités et a créé sa filiale Tunisienne en 2014 et est
devenue société-mère de « Further Technology ».
Logo 1: Spark-it
Spark-it garantit aussi un ensemble de services associés, tel que le consulting, la formation
et le support technique. De nombreuses entreprises étrangères de secteurs différents tels que les
secteurs bancaires, de télécommunications, des assurances, et industriels font confiance à
Spark-it pour la conception et la mise en place des systèmes d'informations décisionnels.
Spark-It accompagne ses clients dans leurs projets liés aux technologies de l’information.
En effet, Spark-it est une ESN qui propose une large gamme de solutions personnalisés telles
3
Chapitre I : Présentation du projet
que le développement Front et Back End (Web, CRM, Progiciels, etc.), la stratégie E-Business
et Business Intelligence.
Spark-it a réussi à accompagner des grandes entreprises dans la mise en place de leurs
solutions décisionnelles. Parmi ces entreprises nous citons le cabinet de recrutement mondial
HAYS, le groupe VALEO qui est l’un des premiers équipementiers mondiaux, spécialiste dans
la conception, la fabrication et la vente de composants, de systèmes intégrés et de modules pour
l’industrie automobile, aussi SERVIER qui est le premier groupe pharmaceutique Français
indépendant et le deuxième groupe pharmaceutique Français au niveau mondial.
Ce projet est réalisé au sein de l’équipe Java de l’entreprise Spark-it durant la période allant
du 4 Février 2019 jusqu’au 30 juin 2019.
existantes. Ces analyses sur les solutions existantes permettent de bien définir les besoins et des
fonctionnalités que nous pouvons intégrer dans notre application.
Dans cette partie, nous allons mentionner quelques applications existantes avant d’analyser
leurs points forts et leurs points faibles.
Dans le tableau 1, nous allons récapituler les fonctionnalités de chacune des solutions
proposées. Les applications citées assurent les fonctionnalités de base comme la gestion des
produits, la gestion des nomenclatures et la gestion des ordres de fabrication. Mais d’autres
fonctionnalités assez importantes telle que la planification des ordres de fabrication et la gestion
des rôles des utilisateurs ne sont pas disponibles dans ces applications.
5
Chapitre I : Présentation du projet
Afin de garantir la réussite du projet, la solution proposée doit pallier aux limites des
applications existantes. La solution proposée doit moderniser la gestion de la production.
La solution proposée doit aussi assurer des besoins non fonctionnels tel que :
6
Chapitre I : Présentation du projet
L’ergonomie
Sécurité
Performance
Pour la gestion de notre projet, nous avons opté pour Scrum[3] en tant que méthode agile
dédiée à la gestion de projet.
Il s’agit d’un modèle itératif de développement logiciel utilisé pour le développement des
logiciels complexes. La première étape de la méthode Scrum consiste à formaliser la vision du
produit en décrivant les principaux objectifs, jalons et utilisateurs visés. La suite consiste à
spécifier la liste des exigences fonctionnelles et non fonctionnelles du produit sous forme de
Product Backlog d’une manière ordonnée selon la priorité fixée par le Product Owner.
Le Product Backlog permettra de diriger l’équipe sur les objectifs du produit tout au long
du projet, et à partir de ce Backlog l’équipe de développement choisit les tâches qui seront
développées au cours du sprint prochain lors de la réunion de planification du sprint.
Une revue de sprint est planifiée à la fin de chaque sprint afin d’inspecter l’avancement du
produit au cours du sprint précédent. Le Product Owner donne ses impressions à l’équipe de
développement, il accepte ou refuse les fonctionnalités présentées et donne les changements
qui doivent être faites sur le produit.
7
Chapitre I : Présentation du projet
Une réunion quotidienne appelée Daily Stand-up Meeting doit se dérouler entre les
membres de l’équipe de développement pour se synchroniser, remonter les obstacles rencontrés
et vérifier l’avancement du sprint.
Product Owner : c’est le représentant des clients. Il définit la liste des fonctionnalités du
produit et choisit la date et contenu de chaque sprint.
Le « scrum master » : il veuille à assurer que le processus scrum est respecté et il est
responsable de l’application quotidienne des directives Scrum.
L’équipe de développeurs : se compose de développeurs qui doivent identifier leurs
tâches en cours et les tâches achevées dans le « Sprint Backlog ».
Conclusion
Dans ce premier chapitre, nous avons présenté l’organisme d’accueil et ses domaines
d’activité. Ensuite, nous avons décri le contexte général du projet et ses objectifs. Dans la suite,
nous avons fait une étude comparative des solutions existantes, cette étude nous a permis de
définir les besoins et les fonctionnalités à intégrer dans notre projet. Enfin, nous avons défini la
méthodologie de travail adoptée tout au long de la réalisation du projet.
8
Chapitre II : Etude préalable
Plan du chapitre :
9
Chapitre II : Etude préalable
Introduction :
Afin d'assurer la bonne compréhension du projet, il est nécessaire de faire le retour des
différents concepts et technologies utilisés et de détailler l'existant fonctionnel. Ce chapitre se
compose de trois parties : L'état de l'art, une étude des ERP existants, une étude du marché des
logiciels de gestion de production et une étude comparative sur les technologies existantes.
Suite au progrès technologiques, les entreprises ont eu recourt pendant des années à
plusieurs solutions afin d'automatiser la gestion des ressources telles que la gestion des
ressources humaines, la gestion de production, la gestion des ventes, etc… C'est là qu'ont
commencé à apparaître les systèmes d'informations qui avaient pour but de gérer les bases de
données des différentes entreprises jusqu'à l'apparition des ERP, l'abréviation en anglais de
(Entreprise Ressources Planning) traduite en français par PGI qui veut dire Progiciel de Gestion
Intégré mais ERP reste le terme le plus couramment utilisé.
- Définition
L’ERP (Entreprise Ressource Planning), est une solution informatisée qui offre la
possibilité de gérer l’ensemble des moyens de l’entreprise,[5] en privilégiant deux aspects : une
communication entre les différents acteurs métiers et une cohérence de l’information. C’est le
centre nerveux du système d’information. Un « Entreprise Ressource Planning » (ERP ou
Progiciel de Gestion Intégré) est un logiciel qui englobe toutes les fonctionnalités d’une
entreprise (gestion de stock, gestion de ventes, gestion de ressources humaines, gestion de
maintenance, gestion de production…).
Pour bien comprendre les aspects fonctionnels de l'ERP, la concentration du marché sur
certains éditeurs permet d'identifier clairement cinq domaines généraux de compétence gérée
par les progiciels de gestion intégrée :
10
Chapitre II : Etude préalable
Gestion de la production
Gestion des stocks, des approvisionnements et des achats
Gestion commerciale
Gestion des ressources humaines
Gestion comptable et financière
Ces différentes catégories se retrouvent dans les différentes offres du marché. Ils constituent
le noyau du système d’information et serviront les différents acteurs de l’entreprise.
L’adaptation à la société de ces progiciels s’effectue par un paramétrage important, ce qui
nécessite un effort considérable de structuration de la société pour "coller" son mode de
fonctionnement aux possibilités du package.
Concrètement, les avantages de la mise en œuvre d'un ERP sont nombreux. Outre le fait
que l’ERP est utilisé dans le monde entier, il permet de :
Un ERP est un ensemble dont toutes les parties fonctionnent ensemble, d'où l'ergonomie et
le caractère unique des informations et donc la cohérence du système d'information. Un ERP
est modulaire en ce sens qu'il est possible d'avoir une ou plusieurs applications à la fois le temps,
ou petit à petit. Les applications modulaires telles que les ERP permettent de s'assurer de la
compatibilité des modules entre eux, ils s'emboîtent comme des blocs Lego et fonctionnent
11
Chapitre II : Etude préalable
12
Chapitre II : Etude préalable
La production d'un service s'effectue par une succession d'opérations consommant des
ressources sans qu'il n'y ait nécessairement une transformation de matière.
Au sens industriel, la production peut être définie comme un flux ayant deux composants
principaux montré par la figure 5 :
Le flux physique
Le flux d'informations
L’objectif principal du GP est d’assurer une bonne régulation du flux de produits dans
l’entreprise (flux de pièces du fournisseur au premier, la production et le stock de produits finis).
Le GP permet de :
13
Chapitre II : Etude préalable
OF : Ordre de fabrication
OA : Ordre d’approvisionnement
La gestion de la production consiste à optimiser les délais, les coûts, la qualité ainsi que les
ressources de l'entreprise afin d'assurer sa durabilité, son développement et sa compétitivité.
Le GPAO n’est donc qu’un support informatique pour ce type de gestion, visant à :
14
Chapitre II : Etude préalable
Toute au long de cette partie, nous allons établir une comparaison entre différentes
technologies à adopter pour le développement de notre solution dans sa partie front-end et
notamment dans la partie back-end.
15
Chapitre II : Etude préalable
Angular utilise l’outil CLI qui permet de générer une squelette d’application avec des bouts
de code (composant, module, route), de faire tourner un serveur de développement, d’exécuter
les tests, de déployer l’application.
ReactJS est plus orienté vers le JavaScript avec tous ses avantages alors qu’Angular offre
plus de maturité que celle de ReactJS.
Pour cela, nous avons adopté le Framework Angular pour développer la partie front end
qui nous a permis de construire une architecture robuste qui inclut toutes les briques nécessaires
16
Chapitre II : Etude préalable
à la création d’une application professionnelle à savoir routeur, requêtage HTTP, gestion des
formulaires, internationalisation. Le Framework lui-même est découpé en modules
correspondant aux grandes aires fonctionnelles (core, forms, router, http. . .). Mise à part son
caractère de modernité conçu pour le web de demain à travers l’utilisation des évolutions
récentes du langage JavaScript (ECMAScript 6 et TypeScript) architecture inspirée des Web
Components. Enfin, il s’agit d’un Framework qui est soutenu par Google.
Conclusion
Tout au long de cette partie, nous avons diffusé une revue de la littérature théorique sur les
solutions ERP et gestion de production. Nous avons ensuite réalisé une étude de marché sur le
logiciel de gestion de production et présenté la relation entre ERP et ses produits. Et pour
terminer ce chapitre nous avons effectué une étude comparative sur les technologies front-end
et back-end.
Afin de suivre la méthodologie adoptée dans la dernière partie, une étude fonctionnelle et
technique fera l’objet du prochain chapitre.
17
Chapitre III : Analyse et spécification des besoins
Plan du chapitre :
18
Chapitre III : Analyse et spécification des besoins
Introduction
Le présent chapitre est consacré à l’identification, l’analyse et la spécification des besoins
qui représentent une phase importante dans le cycle de développement d’un logiciel. Pour ce
faire, Nous présentons, en premier lieu nous définissons les acteurs de notre système. Par la
suite, nous présentons le contexte du projet à travers un diagramme de contexte. Ensuite, nous
entamons une spécification des besoins fonctionnels et non fonctionnels. Ainsi, nous
modélisons ces besoins à l’aide des diagrammes des cas d’utilisation en décrivant leurs
fonctionnalités majeures.
Un acteur est toute entité physique ou abstraite qui interagit avec le système afin de répondre
à un besoin bien défini.
Nous avons identifié quatre acteurs majeurs dans notre application. Nous les détaillons dans
la suite.
Administrateur : C'est la personne qui a le privilège le plus élevé. Cet acteur est capable
de gérer toutes les fonctionnalités offertes par l'application, et plus précisément la gestion des
utilisateurs.
Responsable de production : C'est la personne qui a pour rôle de gérer les ordres de
fabrication (O.F). Il planifie et optimise les méthodes de production et la gestion de la
production, il est l’orchestrateur de tout ce qui entre et sort des ateliers. Il organise et coordonne
la production (planification), attribue à chaque charge de travail (machine, homme) une charge
de travail.
Opérateur : C’est la personne qui traite les opérations au sein de l’atelier : c’est lui qui
initie l’opération, la valide en pause, il peut également consulter les informations concernant
l’opération qui les traite.
19
Chapitre III : Analyse et spécification des besoins
20
Chapitre III : Analyse et spécification des besoins
Les acteurs décrivent les fonctionnalités du système à développer. Ce sont les besoins qui
spécifient le comportement d’entrée/sortie du système. Notre application doit fournir aux
différents utilisateurs les fonctionnalités que nous spécifions dans le tableau 3.
-S’authentifier.
- Créer un produit.
-Supprimer un produit.
-Chercher un produit.
22
Chapitre III : Analyse et spécification des besoins
-S’authentifier.
-S’authentifier.
23
Chapitre III : Analyse et spécification des besoins
Les besoins non fonctionnels représentent les exigences implicites auxquelles le système
doit répondre de telle sorte que toutes les fonctionnalités offertes par l’ERP doivent obéir à un
ensemble de contraintes. Dans ce qui suit, nous présentons les besoins non fonctionnels par
ordre prioritaire comme suit :
• La confidentialité des données : La plateforme doit assurer un accès privilégié, c’est à dire
chaque utilisateur ne peut accéder qu’à certaines fonctionnalités qu’après connexion
(identification et authentification) pour garantir la traçabilité des opérations.
24
Chapitre III : Analyse et spécification des besoins
Dans le diagramme du cas d’utilisation général de la figure 8, nous regroupons tous les cas
d’utilisation de base afin d’avoir une vue globale du fonctionnement de notre système ainsi que
mettre en évidence les éventuelles relations qui peuvent les lier.
25
Chapitre III : Analyse et spécification des besoins
26
Chapitre III : Analyse et spécification des besoins
27
Chapitre III : Analyse et spécification des besoins
Identification
Titre : S’authentifier
Objectif : Ce CU est utilisé pour identifier les utilisateurs et sécuriser l’accès à l’application.
Post condition : L’utilisateur se connecte au système et peut ainsi accéder aux différentes
fonctionnalités.
Scénario nominal :
Le système vérifie si le login et le mot de passe sont correctement saisis. En cas d’anomalie,
le système affiche « Exception1 ».
Scénario alternatif :
Au niveau de l’étape 3, si les informations saisies ne sont pas valides, le système affiche un
message d’erreur et affiche de nouveau l’écran d’authentification.
Exception :
Le diagramme illustré par la figure 10 montre les fonctionnalités liées à la gestion des
produits. La description textuelle associée est récapitulée au tableau 5.
28
Chapitre III : Analyse et spécification des besoins
Identification :
29
Chapitre III : Analyse et spécification des besoins
Post-conditions :
Scénario nominal :
a. Ajouter un produit :
4. Le système vérifie que toutes les données obligatoires sont saisies correctement, et
vérifie l’existence du produit. Dans le cas où ce dernier existe déjà, le système déclenche
l’exception 1.
Si toutes les informations sont validées, le système enregistre le nouveau produit puis
affiche la liste des produits.
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au
système de valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à
l’écran initial de modification.
c. Supprimer un produit :
30
Chapitre III : Analyse et spécification des besoins
Exceptions :
Le diagramme illustré par la figure 11 montre les fonctionnalités liées à la gestion des
nomenclatures. La description textuelle détaillée est récapitulée dans le tableau 6.
31
Chapitre III : Analyse et spécification des besoins
Identification :
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, consulter et de supprimer une
nomenclature.
Post-conditions :
Scénario nominal :
3. L’utilisateur saisit toutes les informations générales du nomenclature (référence, produit, type
nomenclature).
4.Par la suite, l’utilisateur sélectionne les composants de la nomenclature tout en spécifiant les
quantités pour chaque composant, puis il demande au système de valider les informations saisies.
5. Le système vérifie que toutes les données obligatoires sont saisies correctement sinon le système
déclenche l’exception 1.
6. Le système vérifie que la référence de la nomenclature est unique sinon il déclenche l’exception
2.
32
Chapitre III : Analyse et spécification des besoins
8. Le système vérifie que produit sélectionnée de la nomenclature est différent des produits
composants sinon le système il déclenche l’exception 4.
Si toutes les informations sont validées, le système enregistre la nouvelle nomenclature puis affiche
la liste des nomenclatures.
b. Editer nomenclature :
2. L’utilisateur parcourt la liste des nomenclatures, sélectionne une nomenclature selon un critère
de recherche (description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système de
valider les informations saisies.
5. Le système vérifie que toutes les données obligatoires sont saisies correctement sinon le système
déclenche l’exception 1.
6. Le système vérifie que la référence de la nomenclature est unique sinon il déclenche l’exception
2.
8. Le système vérifie que produit sélectionnée de la nomenclature est différent des produits
composants sinon le système il déclenche l’exception 4.
9. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
33
Chapitre III : Analyse et spécification des besoins
si la nomenclature courante est déjà utilisée dans une autre nomenclature dans ce cas le système interdit
la suppression et déclenche l’exception 6 sinon le système valide la suppression et retourne à l’écran
initial.
Exceptions :
Exception 3 : Le système affiche un message indiquant « Produit possède déjà une nomenclature ».
Exception 5 : Le système affiche un message indiquant « Cette nomenclature est déjà utilisée dans
un ordre de fabrication ».
Exception 6 : Le système affiche un message indiquant « Cette nomenclature est déjà utilisée dans
une autre nomenclature».
Le diagramme illustré par la figure 12 montre les fonctionnalités liées à la gestion des
ateliers. La description textuelle détaillée est récapitulée dans le tableau 7.
34
Chapitre III : Analyse et spécification des besoins
Identification :
Post-conditions :
35
Chapitre III : Analyse et spécification des besoins
Scénario nominal :
a. Ajouter atelier :
4. Le système vérifie que la référence de l’atelier est unique sinon il déclenche l’exception 1.
Si toutes les informations sont validées, le système enregistre le nouvel atelier puis affiche la liste
des ateliers.
b. Editer atelier :
2. L’utilisateur parcourt la liste des ateliers, sélectionne un atelier selon un critère de recherche
(description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au système de
valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
c. Supprimer atelier :
3. Si l’utilisateur confirme la suppression alors le système vérifie si l’atelier courant possède une
machine dans ce cas le système interdit la suppression et déclenche exception 2 sinon le système valide
la suppression et retourne à l’écran initial.
36
Chapitre III : Analyse et spécification des besoins
Exception :
Le diagramme illustré par la figure 13 montre les fonctionnalités liées à la gestion des
machines. La description textuelle détaillée est récapitulée dans le tableau 8.
37
Chapitre III : Analyse et spécification des besoins
Identification :
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher et de supprimer une
machine.
Post-conditions :
Scénario nominal :
a. Ajouter machine :
4. Le système vérifie que la référence de la machine est unique sinon il déclenche l’exception 1.
Si toutes les informations sont validées, le système enregistre la nouvelle machine puis affiche la
liste des machines.
b. Editer machine :
2. L’utilisateur parcourt la liste des machines, sélectionne une machine selon un critère de recherche
(description) et demande au système de le modifier.
38
Chapitre III : Analyse et spécification des besoins
4. L’utilisateur modifie les informations qui peuvent être modifiées. Puis, il demande au système de
valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
c. Supprimer machine :
1. L’utilisateur parcourt la liste des machines, sélectionne une machine et demande au système de
supprimer cette machine.
Exceptions :
Exception 2 : Le système affiche un message indiquant « Impossible de supprimer une machine qui
possède déjà des opérations de fabrications».
Le diagramme illustré par la figure 14 montre les fonctionnalités liées à la gestion des
gammes de fabrications. La description textuelle détaillée est récapitulée dans le tableau 9.
39
Chapitre III : Analyse et spécification des besoins
Identification :
Objectif : L’objectif de ce cas d’utilisation est d’ajouter, d’éditer, chercher et de supprimer une
gamme de fabrication.
Post-conditions :
40
Chapitre III : Analyse et spécification des besoins
- Une nouvelle gamme de fabrication validée figure dans la liste des gammes de fabrication.
- La gamme de fabrication supprimée n’existe plus dans la liste des gammes de fabrication.
Scénario nominal :
3. L’utilisateur saisit toutes les informations nécessaires (référence gamme, description gamme).
4. L’utilisateur saisit toutes les informations relatives aux opérations de fabrication (description
opération, durée opération).
5. Par la suite l’utilisateur sélectionne la machine sur laquelle s’exécute cette opération.
7. Le système vérifie que la référence de la gamme de fabrication est unique sinon il déclenche
l’exception 1.
Si toutes les informations sont validées, le système enregistre la nouvelle gamme de fabrication
puis affiche la liste des gammes de fabrications.
2. L’utilisateur parcourt la liste des gammes de fabrications, sélectionne une gamme de fabrication
selon un critère de recherche (description) et demande au système de le modifier.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système de
valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
41
Chapitre III : Analyse et spécification des besoins
1. L’utilisateur parcourt la liste des gammes de fabrications, sélectionne une gamme de fabrications
et demande au système de supprimer cette gamme.
3. Si l’utilisateur confirme la suppression alors le système vérifie si la gamme courante possède des
ordres de fabrication dans ce cas le système interdit la suppression et déclenche exception 2 sinon le
système valide la suppression et retourne à l’écran initial.
Exceptions :
Le diagramme illustré par la figure 15 montre les fonctionnalités liées à la gestion des ordres
de fabrications. La description textuelle détaillée est récapitulée dans le tableau 10.
42
Chapitre III : Analyse et spécification des besoins
Identification :
43
Chapitre III : Analyse et spécification des besoins
Post-conditions :
-Nouvel ordre de fabrication validée figure dans la liste des ordres de fabrication.
- L’ordre de fabrication supprimée n’existe plus dans la liste des ordres de fabrication.
Scénario nominal :
3. L’utilisateur saisit toutes les informations nécessaires (date début, heure début, quantité).
7. Le système vérifie que le produit sélectionné possède déjà une nomenclature sinon il
déclenche l’exception 1.
Si toutes les informations sont validées, le système enregistre le nouvel ordre de fabrication
puis affiche la liste des ordres de fabrications.
4. L’utilisateur modifie les informations qui peuvent être modifiées, Puis il demande au système
de valider les informations saisies.
5. Le système vérifie les informations modifiées et les enregistre. Sinon, le cas reprend à l’écran
initial de modification.
44
Chapitre III : Analyse et spécification des besoins
Exceptions :
Le diagramme illustré par la figure 16 montre les fonctionnalités liées au traitement des
opérations de fabrication La description textuelle détaillée est récapitulée dans le tableau 11.
45
Chapitre III : Analyse et spécification des besoins
Identification :
Acteur : Opérateur.
Objectif : L’objectif de ce cas d’utilisation est de commencer, mettre en pause, terminer une
opération de fabrication et de consulter les informations relatives à cette opération.
Post-conditions :
Scénario :
3. L’utilisateur clique sur un bouton pour accéder à l’interface de suivi des opérations.
Le système enregistre l’opération avec la date courante puis affiche la liste des opérations de
fabrications avec le nouvel état de l’opération.
3. L’utilisateur clique sur un bouton pour accéder à l’interface de suivi des opérations.
46
Chapitre III : Analyse et spécification des besoins
4. L’utilisateur clique sur le bouton mettre en pause pour arrêter une opération.
Le système enregistre l’opération avec la date courante puis affiche la liste des opérations de
fabrications avec le nouvel état de l’opération.
3. L’utilisateur clique sur un bouton pour accéder à l’interface de suivi des opérations.
Le système enregistre l’opération avec la date courante puis affiche la liste des opérations de
fabrications avec le nouvel état de l’opération.
Conclusion
Dans ce chapitre, nous avons analysé les différents besoins de notre projet. Ces besoins ont
été spécifiés à l’aide des diagrammes des cas d’utilisation d’UML. Dans le chapitre suivant,
nous décrivons d’une façon détaillée l’architecture ainsi que la conception de notre système.
47
Chapitre IV : Architecture et conception détaillée du système
Plan du chapitre :
48
Chapitre IV : Architecture et conception détaillée du système
Introduction
Afin de mieux comprendre le système à développer, une démarche structurée s’impose.
Nous avons choisi d’utiliser le langage UML pour la modélisation des différents aspects de
notre système, ce qui permet de structurer le développement. Nous présentons, en premier lieu,
l’architecture globale que nous avons suivi dans notre application. Ensuite, nous présentons une
vue statique du système.
49
Chapitre IV : Architecture et conception détaillée du système
Cette couche de plus haut niveau, responsable de l’affichage des données et de l’aspect
visuel et graphique de l’application. Elle fait appel à la couche applicative pour répondre aux
requêtes du client. La figure 18 présente l’architecture de la couche présentation.
Module : Un module est un fichier de code avec son propre scope. Ce code se concentre
généralement sur une tâche précise.
Les métadonnées : Les métadonnées est la façon de définir le traitement d’une classe.
Template : Les templates sont la partie visible d’une application Angular. Ils mélangent
code HTML et code Angular.
Directive : c’est similaire à un composant, mais sans template. Elle permet d’ajouter un
comportement à un élément.
Liaison par attributs ou binding des propriétés : écrire dans n’importe quelle propriété
du DOM sur les éléments HTML.
50
Chapitre IV : Architecture et conception détaillée du système
Liaison par évènement : c’est un déclenchement des événements qu’on peut écouter :
click, keyup, mousemove qui permet l’exécution d’une méthode déclarée.
Service : Les services représentent une vaste catégorie qui inclut toute valeur, fonction, ou
fonctionnalité dont une application a besoin.
Elle contient tous les traitements métiers de l’application à savoir les services des différents
modules fonctionnels, les services de communication avec la base de données. La couche
Helper définit un service auxiliaire cachée au client et elle est utilisée en interne pour satisfaire
un besoin spécifique la couche service.
La couche Entity représente une abstraction des tables de la base de données sous forme des
classes java.
Le choix pour une telle architecture s’explique principalement par ses avantages. En effet
elle permet de :
– avoir un découplage des aspects métier et technique et des services entre eux d’où une
meilleure modularité.
– garantir une facilité d’évolution : en garantissant un couplage faible entre les services ce
qui permet de faire évoluer les services un par un sans modification du reste de l’application.
• Un client léger : c’est le navigateur web permettant à l’utilisateur d’accéder aux différentes
interfaces homme-machine de l’application.
• Un serveur d’application back-end : c’est le serveur qui contient l’application back- end
celle qui accède aux données à la demande de l’application front-end afin de retourner un
contenu compréhensible et représenté dans l’application frontale.
• Un serveur de base de données : ce serveur est utilisé pour la partie persistance des données
de l’application.
Nous illustrons les différents paquetages côté client et côté serveur afin de fournir une
représentation graphique de haut niveau de l’organisation de notre application. La figure 20
illustre le diagramme de package côté client.
52
Chapitre IV : Architecture et conception détaillée du système
Le package app.module décrit comment les pièces d’application sont emboîtées. Le package
manufacturing.module décrit le package principale, de l’application qui contient l’ensemble des
composants Angular et leur services et template respectives. Les classes de logique métier sont
définies sous le répertoire Métier.
Le package shared englobe un ensemble des directives, pipes et composants communs par
l’ensemble des templates de notre application décrit par la figure 20.
53
Chapitre IV : Architecture et conception détaillée du système
Afin de mieux comprendre notre solution, nous présentons dans la figure 21 le diagramme
de package qui expose la composition de la partie serveur de notre application. Ce diagramme
est composé de dix packages principaux à savoir :
-fr.sparkit.service.utils: ce package contient les codes d’erreurs lancés par les exceptions
gérées par les contrôleurs.
54
Chapitre IV : Architecture et conception détaillée du système
Le diagramme de paquetages précédant contient les modules ainsi que les couches du
système à réaliser. Afin de mieux présenter la structure de ces couches, nous présentons les
diagrammes « de » classe associés. Dans cette couche, nous trouvons neuf classes java dont
chacune fait référence à un module. Chaque classe est constituée de plusieurs services Web qui
présentent un moyen rapide de distribution de l’information entre le client et sa partie back-end.
55
Chapitre IV : Architecture et conception détaillée du système
56
Chapitre IV : Architecture et conception détaillée du système
A noter que tous les services présentés par la figure 23 héritent du service
GenericService.
57
Chapitre IV : Architecture et conception détaillée du système
58
Chapitre IV : Architecture et conception détaillée du système
Cette couche joue l’intermédiaire entre la couche entity et service, permet de faciliter l’accès
aux données exploité par des entity.
59
Chapitre IV : Architecture et conception détaillée du système
60
Chapitre IV : Architecture et conception détaillée du système
-User : Cette classe de stéréotype « entity » encapsule les données relatives au collaborateur
de l’application. Chaque utilisateur a un rôle à savoir un responsable technique, un responsable
de production, opérateur et l’administrateur.
-Area : Cette classe de stéréotype « entity » contient des informations relatives à un atelier
de fabrication.
-Machine : Cette classe de stéréotype « entity » contient des informations relatives à une
machine de fabrication
-Opération : Cette classe de stéréotype « entity » contient des informations relatives à une
opération de fabrication contenant la durée et le responsable ainsi que la machine sur laquelle
se déroule l’opération.
-Gamme : Cette classe de stéréotype « entity » contient des informations relatives à une
gamme de fabrication tel que l’ensemble des opérations avec l’ordre de chaque opération.
A noter que l’entité Produit existe déjà dans l’ERP dans un module implémenté avec
le langage .net, nous faisons une communication entre le back-end .net pour consommer
les identifiants des produits.
Nous passons l’identifiant du produit sous forme d’une référence faible (week-
reference).
61
Chapitre IV : Architecture et conception détaillée du système
62
Chapitre IV : Architecture et conception détaillée du système
63
Chapitre IV : Architecture et conception détaillée du système
Responsable
technique
La figure 27 présente le diagramme de séquence du cas d’utilisation ˝gestion des ordres de fabrications ˝.
65
Chapitre IV : Architecture et conception détaillée du système
L'opérateur peut commencer une opération, la mettre en pause, continuer une opération et
enfin l’arrêter.
Conclusion
Au cours de ce chapitre, nous avons mis en place la partie conception de l’application. Ainsi,
nous avons présenté l’architecture adoptée. Puis, nous avons montré une vue statique du
système. Dans le chapitre suivant, nous décrivons la partie réalisation.
66
Chapitre V : Réalisation
Chapitre V : Réalisation
Plan du chapitre :
67
Chapitre V : Réalisation
Introduction
Dans ce chapitre, nous présentons, en premier, lieu l’environnement matériel ainsi que
logiciel de développement de l’application. En second lieu, nous exposons les différentes étapes
de réalisation de notre projet via l’essentiel des interfaces de notre solution
Environnement matériel
Nous mentionnons les caractéristiques de l’ordinateur sur laquelle nous avons développé
notre application pour l’environnement matériel. L’application a été développée en premier
temps sur un ordinateur ayant les caractéristiques illustrées par le tableau 12.
68
Chapitre V : Réalisation
Swagger
TFS
69
Chapitre V : Réalisation
Git
SonarQube
- Duplication de code
- Documentation
- Règles de programmation
- Analyse de la complexité
- Bugs potentiel
70
Chapitre V : Réalisation
Java EE
Maven
Hibernate
71
Chapitre V : Réalisation
Spring Boot
Angular 5
72
Chapitre V : Réalisation
73
Chapitre V : Réalisation
74
Chapitre V : Réalisation
La figure 31 représente l’interface de la liste des composants d’une nomenclature qui permet
au responsable technique de :
75
Chapitre V : Réalisation
Afficher pour chaque composant qui possède déjà une nomenclature, à N niveaux, le coût
de sa nomenclature.
76
Chapitre V : Réalisation
77
Chapitre V : Réalisation
78
Chapitre V : Réalisation
79
Chapitre V : Réalisation
80
Chapitre V : Réalisation
-Pour commencer une opération, l'opérateur sélectionne le bouton " Démarrer ".
-Pour mettre en pause une opération, l'opérateur sélectionne le bouton " Pause ".
-Pour relancer une opération l'opérateur sélectionne le bouton " Continuer ".
-Pour terminer une opération l'opérateur sélectionne le bouton " Terminer ".
81
Chapitre V : Réalisation
82
Chapitre V : Réalisation
Figure 40 : Interface export informations d'un ordre de fabrication sous forme d'un fichier
83
Chapitre V : Réalisation
Un réviseur obligatoire qui fait une vérification sur le code source puis il accepte la
demande pour l’intégrer dans la branche Master.
84
Chapitre V : Réalisation
Conclusion
Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre
solution. Nous avons décelé cette réalisation à travers un ensemble d’interfaces accompagnées
de description et interprétation. Nous clôturons notre travail par une conclusion qui résume
notre travail et avise ses futures perspectives.
85
Conclusion générale
Le capital humain est un facteur de succès au sein des entreprises. De ce fait, savoir gérer
d’une manière efficace ses ressources et garantir une communication rapide de l’information
doit avoir un rôle stratégique pour l’entreprise. C’est dans ce cadre que s’est inscrit ce projet de
fin d’études au sein de la société Spark-it. Il consiste à concevoir, implémenter et déployer
module ERP de gestion de production.
Ce module facilite le workflow de fabrication d’un produit depuis la phase de définition des
données technique jusqu’à la réalisation. Nous avons décomposé cet outil en plusieurs
fonctionnalités : la gestion des machines, la gestion des ateliers la gestion des nomenclatures,
la gestion des gammes de fabrication, la gestion des opérations de fabrication, gestion des ordres
de fabrication et le suivi de chaque ordre de fabrication.
Pour atteindre cet objectif, nous avons commencé par l’étude préalable qui a permis de
décrire et de comprendre les principaux concepts des ERPs qui existent dans les marchés en
identifiant les ERPs qui automatise la gestion de production en spécifiant les fonctionnalités
disponibles pour chaque ERP ainsi que les différents choix technologiques adoptés pour la
partie front-end (Angular) et back-end (Java).
Puis nous avons passé à l’analyse et la spécification des besoins et exigences. Ensuite, nous
avons élaboré la forge logicielle de l’outil à développer en commençant par l’architecture
adoptée, pour aboutir par la suite à la conception, qui met l’accent sur l’aspect statique du
système. Enfin, nous avons abordé l’étape de réalisation au cours de laquelle nous avons traduit
notre modélisation conceptuelle en une implémentation physique moyennant les différentes
technologies et techniques aussi bien choisies que celles exigées par l’entreprise. Ce travail
nous a été très instructif vu l’énorme quantité de connaissances acquises. Il nous a procuré une
opportunité pour, d’une part aborder un domaine métier et d’autre part confirmer une fois de
plus nos compétences dans le développement Java/JEE et Web, et toucher de près plusieurs
aspects du cycle de vie d’un produit logiciel. Par ailleurs, le projet était une expérience
enrichissante et fructueuse puisqu’il nous a donné l’occasion de mettre à l’épreuve nos
connaissances pratiques en matière de conception et de développement et d’approfondir nos
acquis sur le développement Web à travers une panoplie de nouvelles technologies
(SpringBoot, Angular, Spring data).
86
Hormis le côté technique, ce projet a été une opportunité d’appréhender le travail dans une
hiérarchie professionnelle au sein d’une grande société et, les difficultés inhérentes comme la
répartition du temps et des efforts. Il nous a permis aussi d’apprendre les bonnes pratiques
nécessaires à la réalisation d’un produit de qualité.
87
Annexe : Backlog du produit :
Le backlog est une liste de fonctionnalités à réaliser. Ces fonctionnalités, exprimées sous
forme de besoins, sont priorisées par les Product Owner ce qui permet d’établir un ordre à
respecter lors de la réalisation de l’application. Le tableau présente l’ensemble des histoires des
utilisateurs. Ces histoires sont décrites à l’aide de leur id, noms et l’estimation.
— Le champ User story qui décrit de manière claire et succincte la fonctionnalité désirée
par l’utilisateur.
88
En tant que responsable technique, je peux
consulter la liste des produits sous forme de
2.5
pages.
89
En tant que responsable technique, je
peux consulter la liste des machines sous
4.6
forme de pages.
90
En tant que responsable technique, je
peux consulter les coût total d’une
5.10
nomenclature.
Gestion des
nomenclatures
91
En tant que responsable de
production, je peux éditer les
6.2
informations d’une gamme de
fabrication .
92
7.3 En tant que responsable de
production, je peux supprimer un ordre
de fabrication.
93
7.7 ordres de fabrications sous forme des
pages.
A noter qu’avant de commencer un UserStory, nous démarrons avec une phase d’analyse et
de conception pour chaque fonctionnalité à implémenter.
94
Bibliographie
95