Projet de conception et de développement

¡dure d9—™h—tFPFSIS
•—™h—t •—™h—t
Projet de conception et de développement 2014-2015
Université de la Mannouba
Ecole Nationale des Sciences de l’Informatique
Campus Universitaire de la Manouba
Ecole Nationale des Sciences de L’Informatique
Rapport :
Projet de conception et de développement
Sujet :
Conception et développement d’un ERP(module d’achat,module de
gestion de stock)
Réalisé par :
Themri Abdelkarim
Hadji Glei
Encadré par :
Mme. Guermazi Houda

Remerciements
Il nous est indispensable de remercier avec gratitude Mme. GUERMAZI HOUDA aussi bien pour sa collaboration
ainsi que pour son assistance précieuse qui nous ont donné un coup d’aide pour réaliser notre projet convenablement.
De même, nous tenons à exprimer nos gratitudes à ceux qui nous ont aidé de près ou de loin pour avancer dans nos
développements et nos recherches.
i

Table des matières
Introduction générale 2
1 Présentation générale 3
1.1 Evolution des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Avantages des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Inconvénients des ERPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Présentation du travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Analyse et spéciﬁcation des besoins 7
2.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Spéciﬁcation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Les scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Conception 19
3.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Conception détaillée du package persistance . . . . . . . . . . . . . . . . . 21
3.2.2 Conception détaillée du package traitement . . . . . . . . . . . . . . . . . 22
3.3 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Modèle Entités Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ii

TABLE DES MATIÈRES
3.3.2 Description des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Réalisation 29
4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Les technologiques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Technologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1.1 Microsoft .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1.2 J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Gestion de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Choix retenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Conclusion générale 49
Bibliographie 50
Netographie 51
Glossaire 52
iii

Table des ﬁgures
2.1 Diagramme des cas d’utilisation à l’administrateur . . . . . . . . . . . . . . . . . . 11
2.2 Diagramme des cas d’utilisation relatif au responsable d’achat . . . . . . . . . . . 12
2.3 Diagramme des cas d’utilisation relatif au responsable du stock . . . . . . . . . . 13
2.4 Diagramme des cas d’utilisation relatif au responsable . . . . . . . . . . . . . . . 14
2.5 Diagramme de séquence d’une procédure d’achat . . . . . . . . . . . . . . . . . . 15
2.6 Diagramme de séquence de consultation de stock . . . . . . . . . . . . . . . . . . 16
2.7 Diagramme de séquence d’ajout d’un groupe . . . . . . . . . . . . . . . . . . . . . 17
2.8 Diagramme de séquence de consultation des articles . . . . . . . . . . . . . . . . . 18
3.1 L’architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Diagramme de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Le modèle entités associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Architecture de JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Architecture d’HIbernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Interface d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Interface de l’espace de l’administrateur . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Interface de l’espace du responsable d’achat . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Interface de l’espace du responsable de stock . . . . . . . . . . . . . . . . . . . . . 39
4.7 Interface de l’espace du responsable . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Interface de l’espace de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Interface de la demande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Interface de la commande d’achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
iv

TABLE DES FIGURES
4.11 Interface de la validation de réception . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 Interface de la gestion des fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . 42
4.13 Interface de la gestion des catalogues . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.14 Interface de la gestion des articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.15 Interface de la gestion des sorties des articles . . . . . . . . . . . . . . . . . . . . . 44
4.16 Interface de la consultation des articles . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.17 Interface de l’administration des groupes . . . . . . . . . . . . . . . . . . . . . . . 45
4.18 Interface de l’administration des utilisateurs . . . . . . . . . . . . . . . . . . . . . 45
4.19 Interface de la gestion des accès des groupes . . . . . . . . . . . . . . . . . . . . . 46
4.20 Interface de la consultation des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.21 Interface de la consultation des mouvements . . . . . . . . . . . . . . . . . . . . . 47
4.22 Interface de la gestion des sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.23 Interface de la consultation des articles par site . . . . . . . . . . . . . . . . . . . . 48
v

Liste des tableaux
3.1 Table article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Table groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Table catalogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Table entete_achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Table fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Table ligne_achat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Table groupe_utlisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Table mouvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Table role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Table site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.11 Table utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vi

Introduction Générale
DE nos jours, toute entreprise est prête à investir des sommes considérables dans l’im-
plantation des technologies logicielles afin d’améliorer ses services, d’accroître 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.
Pour surpasser ces difficultés, une entreprise doit utiliser des outils optimisés et adaptés
facilitant les tâches et offrant des fonctionnalités riches et utiles. Parmi ces outils nous trouvons
les systèmes intégrés de gestion tels que les ERPs(Entreprise Ressources Planning).
Les ERPs appelés aussi Progiciel de Gestion Intégré sont des systèmes dont le but est d’in-
tégrer les données et les processus dans les organisations. Les données sont stockées dans une
même base de données ce qui garantit l’unicité des informations qui circulent à l’intérieur des
différents départements[0].
C’est dans ce cadre que s’inscrit notre projet de conception et de développement, intitulé
«Conception et Développement d’un ERP(module d’achat, module de gestion de stock» dont
l’objectif est de concevoir une application dédiée aux entreprises, permettant à son propriétaire
la gestion des achats et du stock.
Le présent rapport synthétise tout le travail que nous avons effectué dans cette perspective.
Il s’articule autour de quatre parties :
Le premier chapitre donne une présentation générale du projet : étude des avantages et des
inconvénients des ERPs ainsi que les objectifs à atteindre.
1

Introduction Générale
Le deuxième chapitre comportera l’analyse et la spéciﬁcation des besoins fonctionnels et des
besoins non fonctionnels qui décrivent les fonctionnalités attendues de l’ERP à proposer, ainsi
que les exigences qui vont déterminer sa qualité.
Dans le troisième chapitre, nous présenterons la conception de l’ERP à développer : nous com-
mencerons d’abord par la description du système suivi de son architecture, ensuite nous dé-
taillerons et modéliserons la conception globale.
Finalement, l’implémentation et la réalisation de la solution seront abordées dans le dernier
chapitre.
2

Chapitre 1
Présentation générale
Introduction
NOus commençons dans ce premier chapitre par une étude de l’évolution des ERPs, puis
nous allons présenter les avantages et les inconvénients de ces progiciels pour finir par présen-
ter notre travail.
1.1 Evolution des ERPs
Au fil des années, les systèmes ERP ont évolué et avancé depuis l’émergence des systèmes
"Material Requirements Planning" (MRP) et des "Manufacturing Resource Planning" (MRP2) .
La première différence entre un système ERP et ses prédécesseurs est que ERP engendre toute
la gestion de l’entreprise non seulement les opérations reliées à la production. Les systèmes
ERPs ont été inventés dans les années 1960, Ces systèmes ont été évolués en systèmes MRPs
durant les années 1970. Les systèmes MRPs ont été utilisés au sein des entreprises industriels
dans le but de gérer la production et le stockage.
Dans la décennie suivante, on a vu l’apparition des systèmes "Manufacturing Requirements
Planning" (MRP2) qui présentent une version étendue des MRPs couvrant d’autres opérations
et processus entrepreneuriales des entreprises industrielles[1].
Outre la planification de fabrication, l’extension a géré les processus de finance, de gestion
d’ordre, de gestion de stock, de distribution et d’approvisionnement MRP2 peuvent aussi s’oc-
cuper des processus d’affaires au sein et entre les entités des grandes entreprises comme les
3

CHAPITRE 1. PRÉSENTATION GÉNÉRALE
entrepôts et les centres de distribution.
Bien que les implémentations de MRP n’étaient pas triviales, cependant, MRP2 consommaient
plus de temps et de ressources car ils étaient de plus large portée et avaient des impacts plus
importants sur les processus d’affaires et les personnes. Dans les années 1990, les systèmes ERP
ont été introduits comme extension de ses prédécesseurs pour couvrir toute l’activité de l’orga-
nisation. LES ERPs mettent l’accent sur les processus de la fonction d’affaires et non seulement
les opérations reliées à la production de plus, ils offrent un stockage central des données et une
intégration entre les différents départements de l’organisation.
1.2 Avantages des ERPs
Concrètement, les avantages de la mise en place d’un ERP sont les suivants :
– L’intégrité et l’unicité du SI, c’est-à-dire qu’un ERP permet une logique et une ergonomie
unique à travers sa base de données, elle l’est aussi unique au sens " logique ". Ceci se tra-
duit par le fait qu’il peut exister plusieurs bases de données " physiques " mais celles-ci
respectent la même structure. En bref, un ERP permet d’éviter la redondance d’informa-
tion entre différents SI de l’entreprise ce qui rend l’entreprise fiable vis-à-vis des autres
organisations.
– L’utilisateur a la possibilité de récupérer des données de manière immédiate, ou encore
de les enregistrer. Un avantage important , les mise à jour dans la base de données sont ef-
fectuées en temps réel et propagées aux modules concernés ce qui garantit une traçabilité
des flux de production permettent un tavail d’amélioration continue de l’organisation.
– Un ERP est un outil multilingue et multidevise, il est donc adapté au marché mondial, en
particulier aux multinationales.
– Pas d’interface entre les modules, il y a une synchronisation des traitements et une opti-
misation des processus de gestion. De même, la maintenance corrective est simplifiée car
celle-ci est assurée directement par l’éditeur et non plus par le service informatique de
l’entreprise .(Celui-ci garde néanmoins sous sa reponsabilité la maintenance évolutive :
amélioration des fonctionnalités , évolution des règles de gestion , etc ...)
– Un ERP permet de maîtriser les stocks et les flexibiliser, élément important pour la plu-
part des entreprises car les stocks coûtent chers ce qui augmente la compétivité de l’en-
treprise.
– L’automatisation de la gestion de certains processus pour soulager les équipes en interne
4

ainsi que pour optimiser la productivité et la rentabilité de l’organisation[10,11,12].
1.3 Inconvénients des ERPs
Malgré la grande reconnaissance des systèmes ERPs au sein des organisations, certaines
critiques ont été dirigées vers ces types de systèmes, que ce soit d’un point de vue technique
ou d’un point de vue commercial[2].
La rigidité des systèmes ERPs est souvent soulignée comme étant un facteur limitant leur uti-
lisation. D’un côté, les organisations qui adoptent ces types de systèmes finissent par avoir les
processus conçus sous une forme standard, juste parce que le système mis en place l’exige[3,4,5,6].
Cependant, cela n’arrive que lorsque les organisations veulent une solution de système ERP
moins chère et avec un délai de mise en œuvre plus court, donc moins paramétré[7].
Une des difficultés majeures dans la mise en œuvre des systèmes ERP est la longue période que
tels systèmes nécessitent[3,4,8]. Dans les grandes organisations, une application peut durer de
trois à cinq ans qui est jugée en tant qu’une très longue période dans un environnement d’af-
faires en évolution constante.
Une autre critique des systèmes ERP est l’utilisation d’une technologie dépassée, même si cer-
tains efforts ont récemment été faits comme Business By Design (SAP) et les systèmes SaaS
offrant des installations Web 2.0 (SAP, Oracle, ...). En fait, certains systèmes ERPs ne font pas
des interfaces graphiques et modernes, que les utilisateurs aimeraient. Cependant, il n’existe
pas d’alternatives viables à cette situation[2].
De plus, le fait que cette technologie est basée sur des utilisateurs individuels, forçant le paie-
ment de licences individuelles pour l’utilisation de système ERP, il en résulte un coût élevé de
l’utilisation du système, ce qui rend la mise à jour du système difficile pour la plupart des ver-
sions[9].
Un autre inconvénient des systèmes ERP est sa rigidité hiérarchique et la centralisation de
contrôle et de gestion. Les Systèmes ERPs supposent que l’information doit être gèrée de ma-
nière centralisée et que les organisations ont bien défini les structures hiérarchiques. Certains
détracteurs de ces types de systèmes prétendent que l’habilitation devrait être de plus en plus
appliquée aux organisations et les employés devraient être perçus comme des agents indé-
pendants. Pour surmonter ces faiblesses, certains auteurs comme Davenport, soutiennent que,
d’une part, la grande majorité des organisations ont bien définis les structures hiérarchiques et
d’autre part, lorsque cela n’est pas le cas, il est possible d’implémenter un système ERP pour
5

chaque unité d’affaire[2].
1.4 Présentation du travail demandé
Dans notre approche, nous nous intéressons à la conception de deux modules que nous
jugeons très important pour les entreprises : l’achat et la gestion du stock. De plus, nous es-
sayons de proposer un ERP simple qui ne dépasse pas les besoins des organisations qui sont
les suivants :
– Offrir à l’utilisateur la possibilité de consulter les articles.
– Offrir à l’administrateur la possibilité de gérer les groupes, les utilisateurs et les rôles.
– Gérer la procédure d’achat.
– Permettre au responsable du stock la gestion du stock.
Conclusion
DAns ce chapitre, nous avons exposé théoriquement notre projet pour mieux comprendre
le système implémenté. Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et
non fonctionnels auxquels doit répondre notre ERP.
6

Chapitre 2
Analyse et spécification des besoins
Introduction
L
’analyse et la spécification des besoins représentent la première phase du cycle de déve-
loppement d’un logiciel et c’est au cours de laquelle que les besoins de l’utilisateur sont
identifiés et précisés.
Dans ce chapitre, nous étudions dans un premier temps les besoins fonctionnels et non fonc-
tionnels de notre système, ensuite, une spécification formelle des besoins est présentée par des
diagrammes de cas d’utilisation et de séquences suivant la modélisation UML.
2.1 Les acteurs
Cette partie consiste à présenter les acteurs du système.
L’utilisateur : il s’identifie et consulte les articles avec les quantités existantes.
Le responsable d’un service : les responsables des différents départements peuvent exprimer
leurs besoins à travers la rédaction d’une demande d’achat.
Le responsable d’achat : il fait toute l’analyse stratégique et consulte le nouveau dossier d’achat
qui lui est destiné afin de valider la demande et établir la commande.
Le responsable du stock : il vérifie la conformité de la marchandise reçue avec le bon de com-
mande puis il valide la réception et il gère le stock.
L’administrateur : il gère les groupes, les utilisateurs et les accès.
7

CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
2.2 Spécification des besoins
Au cours de cette partie, nous allons définir les besoins fonctionnels et non fonctionnels de
notre application.
2.2.1 Les besoins fonctionnels
Ces exigences répondent à la question à quoi sert notre système. Les services proposés par
notre application se manifestent suivant les acteurs comme suit :
L’utilisateur :
– S’identifier en tant que simple utilisateur.
– Consulter les articles avec les quantités existantes.
L’administrateur :
– S’identifier en tant qu’administrateur.
– Ajouter un utilisateur.
– Modifier un utilisateur.
– Supprimer un utilisateur.
– Ajouter un groupe.
– Modifier un groupe.
– Supprimer un groupe.
– Consulter les rôles.
Le responsable :
– S’identifier en tant que responsable.
– Envoyer une demande.
Le responsable d’achat :
– S’identifier en tant que responsable d’achat.
– Envoyer une commande.
– Ajouter un fournisseur.
8

– Supprimer un fournisseur.
– Modifier un fournisseur.
– Ajouter un article.
– Modifier un article.
– Supprimer un article.
– Ajouter un catalogue.
– Modifier un catalogue.
– Supprimer un catalogue.
Le responsable du stock :
– S’identifier en tant que responsable du stock.
– Valider la réception d’une commande.
– Ajouter un mouvement.
– S’informer de l’état du stock.
– Ajouter un site.
– Supprimer un site.
– Modifier un site.
2.2.2 Les besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le sys-
tème pour sa réalisation et son bon fonctionnement. Ce sont des exigences qui ne concernent
pas spécifiquement le comportement du système mais plutôt imposent des contraintes internes
et externes du système.
Les principaux besoins non fonctionnels de notre application se résument dans les points sui-
vants :
– BNF1. Ergonomie
L’application doit être adaptée à l’utilisateur sans fournir aucun effort (utilisation claire et
facile) de point de vue navigation entre les différentes pages, couleurs et mise en textes utilisés.
– BNF2. Fiabilité
9

L’application doit fonctionner de façon cohérente sans erreurs et doit être satisfaisante.
– BNF3. Robustesse
Les ambiguités doivent être signalées par des messages d’erreurs bien organisés pour bien
guider l’utilisateur et le familiariser avec notre application web.
– BNF4. Maintenabilité
Le système doit être conforme à une architecture standard et claire permettant sa mainte-
nance.
– BNF5. Sécurité
Notre solution doit respecter la confidentialité des données personnelles des utilisateurs.
2.3 Analyse des besoins
Dans cette partie, on s’intéresse à la modélisation des besoins fonctionnels et leur analyse.
2.3.1 Diagrammes des cas d’utilisation
L’étude approfondie des spécifications permet de dégager plusieurs cas d’utilisation. Un
cas d’utilisation décrit une utilisation du système par un acteur particulier. Ce qui revient à
présenter les besoins fonctionnels de façon formelle.
Cas d’utilisation d’un administrateur
Dans la figure 2.1, on montre les différents fonctionnalités de l’administrateur parmi lesquelles
on trouve la consultation des rôles qui lui permet de connaitre ce que peut faire chaque utilisa-
teur.
10

FIGURE 2.1 – Diagramme des cas d’utilisation à l’administrateur
Cas d’utilisation du responsable d’achat
La ﬁgure 2.2 montre les fonctionnalités du responsable d’achat formellement.
11

FIGURE 2.2 – Diagramme des cas d’utilisation relatif au responsable d’achat
Cas d’utilisation du responsable de stock
Le responsable de stock gère les sites, ajoute les mouvements en cas de sortie ou retours du
stock et valide la réception comme l’indique la ﬁgure 2.3.
12

FIGURE 2.3 – Diagramme des cas d’utilisation relatif au responsable du stock
Cas d’utilisation d’un responsable
Le responsable est celui qui passe les demandes de tous les employés de son département.
13

FIGURE 2.4 – Diagramme des cas d’utilisation relatif au responsable
2.3.2 Les scénarios
Les diagrammes de séquences peuvent servir à illustrer un cas d’utilisation décrit précé-
demment. C’est un moyen semi formel de capturer le comportement de tous les objets et ac-
teurs impliqués dans un cas d’utilisation. Dans ce qui suit nous allons présenter quelques scé-
narios de notre application.
14

Diagramme de séquence d’une procédure d’achat
La procédure d’achat est l’une des tâches les plus importantes de notre système qu’on trouve
son déroulement représenté dans la ﬁgure 2.5.
FIGURE 2.5 – Diagramme de séquence d’une procédure d’achat
15

Diagramme de séquence de consultation de stock
Ce diagramme concerne la consultation de l’état du stock par le responsable du stock.
FIGURE 2.6 – Diagramme de séquence de consultation de stock
Diagramme de séquence d’ajout d’un groupe
Le diagramme de la ﬁgure 2.7 montre la méthode de l’ajout d’un groupe par l’administrateur.
16

FIGURE 2.7 – Diagramme de séquence d’ajout d’un groupe
17

Diagramme de séquence de consultation des articles
La figure 2.8 nous renseigne sur la fonctionnalité de base d’un utilisateur.
FIGURE 2.8 – Diagramme de séquence de consultation des articles
Conclusion
D
Ans ce chapitre, nous avons spécifié les fonctionnalités que doit assurer notre projet.
Nous avons, ensuite, spécifié les besoins requis par l’application via le diagramme de
cas d’utilisation qui applique la méthode de conception UML et les diagrammes de séquences
associés. Ceci, nous a permis d’avoir une idée claire sur les services offerts par notre applica-
tion.
La conception et ses détails seront décrits dans le prochain chapitre.
18

Chapitre 3
Conception
Introduction
APrès avoir identifié les différentes fonctionnalités que doit accomplir notre application,
nous allons réserver ce chapitre pour la phase de conception qui présente une étape primordiale
dans le cycle de développement d’un projet.
Nous allons présenter dans ce chapitre l’aspect architectural et l’aspect conceptuel de notre
solution.
3.1 Conception globale
Dans cette section, nous allons étudier certaines architectures afin d’assurer un choix adé-
quat pour la réalisation de notre application. Ensuite, nous allons présenter le diagramme de
paquetage.
3.1.1 Choix de l’architecture
L’architecture MVC (modèle, vue et contrôleur) est une architecture à trois couches utilisée
pour la programmation client/serveur et d’interface graphique. C’est un modèle architectural
très puissant qui intervient dans la réalisation d’une application. Il tire sa puissance de son
concept de base qui est la séparation des données (modèle), de l’affichage (vue) et des actions
(contrôleur). C’est trois couches sont décrites comme suit :
– Modèle
19

CHAPITRE 3. CONCEPTION
Il s’agit en général d’un ou plusieurs objets Java. Ces objets s’apparentent généralement
à ce qu’on appelle souvent « la couche métier » de l’application et effectuent des traitements
absolument transparents pour l’utilisateur.
– Vue
Ne contenant que les informations liées à l’affichage, la vue se contente d’afficher le contenu
qu’elle reçoit sans avoir connaissance des données. En bref, c’est l’interface homme machine de
l’application.
– Contrôleur
Le contrôleur sert de base à récupérer les informations, de les traiter en fonction des para-
mètres demandés par la vue (par l’utilisateur), puis de renvoyer à la vue les données afin d’être
affichées. C’est donc l’élément qui va utiliser les données pour les envoyer à la vue.
L’interaction entre ces trois couches est décrite à l’aide de la figure suivante.
FIGURE 3.1 – L’architecture MVC
Les avantages apportés par l’architecture MVC sont :
– La séparation des données de la vue et du contrôleur (ce qui permet une conception claire
et efficace de l’application).
20

– Une indépendance des données, de l’afﬁchage et des actions (ce qui donne plus de sou-
plesse pour la maintenabilité et l’évolutivité du système).
– Un gain de temps de maintenance et d’évolution de l’application.
Pour toutes ces raisons nous avons opté pour l’architecture MVC.
3.1.2 Diagramme de paquetage
Notre application se base sur l’architecture MVC. Elle se décompose à son tour en trois
paquets qui sont persistance, traitement et présentation.
FIGURE 3.2 – Diagramme de paquetage
3.2 Conception détaillée
Dans cette section, nous allons décrire les trois parties de l’architecture MVC.
3.2.1 Conception détaillée du package persistance
Le package persistance comporte les classes qui représentent les données sauvegardées
dans la base. Il permet l’intégrité et la gestion des données.
21

FIGURE 3.3 – Diagramme de classes
3.2.2 Conception détaillée du package traitement
La ﬁgure ci-dessous présente les différentes classes du package traitement.
22

FIGURE 3.4 – Diagramme de traitement
Dans la ﬁgure 3.4, nous montrons que :
– L’utilisateur consulte les articles.
– Le responsable consulte les articles et passe des demandes.
– Le responsable d’achat consulte les articles, demande et commande. De plus, il fait la
gestion des fournisseurs, des articles et des catalogues.
– Le responsable du stock envoie des demandes et fait toutes les opérations nécessaires
concernant le stock.
– L’administrateur gère les utilisateurs ainsi que les groupes et consulte les rôles pour bien
s’informer des droits d’accès.
23

3.3 Conception de la base de données
Cette partie est consacrée à la conception de la base de données.
En tenant compte des diverses fonctionnalités que le site doit assurer et aﬁn de garantir l’ex-
tensibilité et l’adaptabilité de la base, nous avons conçu un modèle de la base de données rela-
tionnelle que nous allons détailler dans ce qui suit.
3.3.1 Modèle Entités Associations
Le modèle conceptuel ci-dessous permet d’écrire formellement les données qui seront uti-
lisées par notre application. Il s’agit donc d’une représentation de données facilement compré-
hensible, décrivant le système à l’aide des entités associations.
FIGURE 3.5 – Le modèle entités associations
24

3.3.2 Description des tables
Champ Commentaire
idA identifiant article
T taux annuel de consommation
designation nom article
delai_liv délai livraison
description description article
marge_delai nombre de jours si le délai non respecté
note_delai aptitude du fournisseur à respecter le délai
note_qualite qualité de l’article
note_retour_stock facilité du retour du stock
prix prix unitaire
stock quantité existante
idF identifiant fournisseur
idC identifiant catalogue
idS identifiant site
TABLE 3.1 – Table article
Champ Commentaire
idG identifiant groupe
nom nom groupe
description description du groupe
responsable responsable du groupe
TABLE 3.2 – Table groupe
25

Champ Commentaire
idC identifiant catalogue
coeff_delai importance du respect du délai
coeff_qualite importance de la qualité
coeff_retour_stock importance du retour du stock
consommation la consommation journaliére
marge_consommation la consommation à prévoir
nom nom catalogue
TABLE 3.3 – Table catalogue
Champ Commentaire
idE identifiant entête
date_doc date création de la demande
type_doc indique l’état de la demande
idU identifiant demandeur
TABLE 3.4 – Table entete_achat
Champ Commentaire
nom nom fournisseur
tel numéro téléphone
mail mail fournisseur
adresse adresse fournisseur
TABLE 3.5 – Table fournisseur
Champ Commentaire
idL identifiant ligne achat
quantite quantité à demander
unite l’unité de la demande
idE identifiant de l’entête achat correspondante
idA identifiant de l’article lié à la ligne
TABLE 3.6 – Table ligne_achat
26

Champ Commentaire
idU identifiant utilisateur
idG identifiant du groupe de associé à l’utilisateur
TABLE 3.7 – Table groupe_utlisateur
Champ Commentaire
idM identifiant mouvement
date_op date du mouvement
type entrée ou sortie ou retour stock
quantite la quantité du mouvement
idA identifiant de l’article concerné
TABLE 3.8 – Table mouvement
Champ Commentaire
idR identifiant rôle
demande indique si l’utilisateur peut faire une demande
commande indique si l’utilisateur peut faire une commande
validation indique si l’utilisateur peut valider la réception
TABLE 3.9 – Table role
Champ Commentaire
idS identifiant site
nom nom du site
localisation localisation du site
TABLE 3.10 – Table site
Champ Commentaire
idU identifiant utilisateur
nom nom utilisateur
prenom prénom utilisateur
mail mail utilisateur
idR groupe correspondant
TABLE 3.11 – Table utilisateur
27

Conclusion
T
Out au long de ce chapitre, nous avons décrit les différents aspects conceptuels de notre
travail. Nous avons commencé par la présentation de l’architecture globale de l’appli-
cation. Ensuite nous avons illustré l’architecture détaillée. Nous entamons dans ce qui suit la
partie réalisation.
28

Chapitre 4
Réalisation
Introduction
A
Près avoir achevé l’étape de conception de l’application, nous entamons dans ce chapitre
la phase de réalisation. Nous allons présenter, en premier lieu, l’environnement de tra-
vail utilisé pour le développement de l’application. Ensuite, nous allons donner un aperçu sur
le travail accompli à travers des captures d’écran.
4.1 Environnement matériel
Aﬁn de réaliser ce projet dans les conditions favorables, nous avons mis en notre disposition
deux ordinateurs avec les conﬁgurations suivantes :
Le premier :
– Processeur : Intel Core i7-3537U
– Disque dur : 1To
– RAM : 4Go
Le deuxième :
– Processeur : Intel(R) Core(TM) i5-2400M CPU
– Disque dur : 720Go
– RAM : 6Go
29

CHAPITRE 4. RÉALISATION
4.2 Les technologiques utilisées
Dans cette partie, nous allons présenter les raisons pour lesquelles nous avons fait nos choix
de technologie.
4.2.1 Technologie de développement
Dans le chapitre précédent, nous avons choisi l’architecture du système et nous avons fait
une comparaison entre les deux technologies .NET et J2EE avoir une application robuste, por-
table, complexe et sécurisée, d’autant plus elles traitent des données conﬁdentielles, et font
appels aux technologies les plus modernes.
4.2.1.1 Microsoft .NET
4.2.1.1.1 Présentation La plate-forme Microsoft .NET est une solution complète pour déve-
lopper, déployer et exécuter des application de tous types, y compris des services web. Fondée
sur des standards de l’industrie (HTTP, XML, SOAP, WDSL), la plate-forme .NET est un moyen
simple et puissant pour implémenter la coopération des services logiciels entre eux, quelle que
soit leur localisation, leur impléméntation technique, qu’ils soient internes ou externes, exis-
tants ou à inventer.
4.2.1.1.2 Les composants .NET A travers les différentes annonces de Microsoft depuis son
lancement, les composants de .NET semblent s’organiser de la manière suivante :
Pour la couche présentation et logique de présentation :
– ASP .NET : c’est une nouvelle version d’ASP (Active Server Pages) qui supporte une
véritable compilation en IL, alors qu’ASP était interprété auparavant. On peut également
écrire les pages ASP dans n’importe quel langage disposant d’un compilateur IL.
– WinForms et WebForms : ils présentent un ensemble de composants graphiques acces-
sibles dans Visual Studio .NET.
Pour la couche logique métier et objets intermédiaires :
– CLR (Common Language Runtime) : c’est un environnement d’exécution commun qui
30

exécute un bytecode écrit dans un langage intermédiaire (Microsoft Intermediate Lan-
guage)
– C# : c’est un nouveau langage orienté objet destiné à faciliter la programmation dans
.NET, notamment les composants, qui intègre des éléments de C, C++ et de Java en ap-
portant quelques innovations comme les méta-données.
– Langages quelconques qui peuvent être compilés en IL et exécutés par le CLR si un com-
pilateur IL existe pour ce dernier.
– Une grande bibliothèque de composants et d’objets de base accessibles par le CLR, qui
fournissent les fondations pour écrire rapidement un programme (accès réseau, graphisme,
accès aux données).
– Visual Studio .NET : c’est une réfonte de l’environnement Visual Studio et de VisualIN-
terDev permettant aussi bien le développement d’application et de composant classique.
– Un support de terminaux mobiles avec une version compacte de l’environnement .NET.
Pour la couche de données : ADO .NET : c’est une nouvelle génération de composants d’accès
aux bases de données ADO qui utilise XML et SOAP pour l’échange de données.
4.2.1.1.3 Les avantages de .NET La plate-forme .NET comprend un mod¨le de programma-
tion homogène et des outils de développement multi langages qui accèlèrent le développement
et l’intégration de Services Web et de tout autre type d’application multi langages et intégrant
les standards, la plate-forme .NET laisse au développeur toute liberté de choisir le langage de
développement. D’autre part son support des standards et son approche moderne, la plate-
forme .NET est parfaitement adaptée à la construction d’une architecture orientée services. La
plate-forme .NET offre donc plusieurs avantages :
– Un développement spéciﬁque grace au moteur CLR.
– Une structure multi langages et extensible.
– Une exécution multi plate-forme.
– Une productivité comparable à celle des environnements Client/Serveur comme Power-
Builder ou Delphi.
– Un modèle de programmation simple et cohérent.
– Une installation automatisée des Web Services.
31

4.2.1.2 J2EE
4.2.1.2.1 Présentation J2EE est logiquement destiné aux gros systèmes d’entreprise. Les lo-
giciels employés à ce niveau ne fonctionnent pas sur un simple PC mais requière une puissance
beaucoup plus importante. Pour cette raison, les applications doivent être constituées de plu-
sieurs composants pouvant être déployés sur des plate-formes multiples aﬁn de disposer de la
puissance de calcul nécessaire. C’est la raison d’être des applications distribuées.
J2EE est une collection de composants, de conteneurs et de services permettant de créer et de
déployer des applications distribuées au sein d’une architecture standardisée.
4.2.1.2.2 Les composants J2EE J2EE fournit une gamme d’outils et d’API aﬁn de concevoir
facilement les différentes couches.
Pour la couche de présentation et logique de présentation :
– Java Servlet :une servlet est un programme écrit en JAVA qui tourne sur la machine du
serveur J2EE. Une servlet est chargée lorsque le serveur est mis en route ou lorsque le
premier client fait appel aux services de la servlet. Le serveur Web reçoit une demande
adressée à une servlet sous la forme d’une requete HTTP. Il transmet la requete à la servlet
concernée, puis renvoie la réponse fournie par celle du client. La servlet reçoit également
les paramètres de la requete envoyée par le client. Elle peut alors effectuer toutes les
opérations nécessaires pour construire la réponse avant de renvoyer celle-ci sous forme
de code HTML. Une fois chargée, une servlet reste active dans l’attente de nouvelles
requetes. Une servlet doit soit implémenter l’interface javax.servlet.Servlet ou étendre
soit la classe javax.servlet.GenericServlet soit javax.servlet.http.HttpServlet.
– Java Server Pages (JSP) : cette extension permet de valoriser davantage les applications
web avec la plate-forme J2EE en permettant le développement d’applications web basées
sur ce modèle ; les JSP permettent grace au moteur de servlet de produire facilement des
pages HTML.
– Struts : Jakarta Struts est un projet d’Apache software foundation qui a pour but de four-
nir un cadre standard de développement web en java respectant le modèle d’architecture
MVC (Model-View-Controller). Il fournit le minimum de r¨gles pour construire des ap-
plications web professionnelles.
– Java Server Faces (JSF) : Java Server Faces est un framework d’interface utilisateur pour
les applications web, basé sur les technologies JSP et Servlets. Le but de JSF est d’ac-
32

croitre la productivité des développeurs dans le développement des interfaces utilisateur
tout en facilitant leur maintenance. JSF permet de réconcilier deux points de vues diamé-
tralement opposés en fournissant un framework basé sur une abstraction complète des
mécanismes d’internet tout en garantissant une totale maîtrise du cycle de vie du traite-
ment d’une requete. JSF permet :
– Une séparation nette entre la couche de présentation et les autres couches.
– Le mapping HTML/Objet.
– Un mod¨le riche de composants graphiques réutilisables.
– Une gestion de l’état de l’interface entre les différentes requetes.
– Une liaison simple entre les actions coté client de l’utilisateur et le code Java correspon-
dant coté serveur.
– La création de composants customs grace à une API.
– Le support de différents clients (HTML, WML, XML, ...) grace à la séparation des pro-
blématiques de construction de l’interface et du rendu de cette interface.
FIGURE 4.1 – Architecture de JSF
– Spring : c’est un framework ayant pour but de rendre facile le développement des appli-
cations web tout en augmentant la consistance et la productivité.
Pour la couche métier et objets intermédiaires :
– Les EJB : ce sont des composants Java pour des applications distribuées multi niveaux.
Cette extension fournit un moyen standard pour déﬁnir les composants coté serveur et
33

définit une vaste infrastructure d’exécution pour l’hébergement des composants coté ser-
veur.
– Les JavaBeans : selon la spécification des Javabeans, une Bean est un composant logiciel
réutilisable pouvant etre manipulé visuellement dans un outil de construction (builder-
tool).
Pour la couche de données :
– JDBC Connector : JDBC (l’acronyme de JAVA Data Base Connectivity) est une API JAVA
permettant d’accéder à la base de données, de façon indépendante de la base utilisée,
à partir d’une application JAVA. La procédure sera la meme quelle que soit la base de
données choisie. JDBC définit une API de bas niveau désignée pour supporter les fonc-
tionnalités basiques de SQL indépendemment de toute implémentation SQl spécifique.
– Hibernate : c’est un framework qui donne une solution pour le mapping objet/relationnel
et la gestion de la couche de persistance. Hibernate permet la gestion automatique de la
structure de la base de données : création et mise à jour. IL utilise un langage simple pour
l’interrogation de la base de données appelé HQL (Hibernate Query Language) et qui
fournit une couche d’abstraction SQL.
34

FIGURE 4.2 – Architecture d’HIbernate
4.2.1.2.3 Les avantages de J2EE L’approche multi niveaux adoptée par la plate-forme J2EE
offre plusieurs avantages :
– Elle réduit la compléxité du développement distribué avec une architecture simpliﬁée et
le partage de la charge de travail.
– C’est une solution hautement évolutive qui permet le développement des systèmes satis-
faisant de nombreux besoins rapidement modiﬁables.
– Les nouvelles applications peuvent s’intégrer correctement avec les systèmes d’informa-
tions existants.
– La sécurié est améliorée.
– Les développeurs peuvent choisir parmi une diversité d’outils de développement et de
35

composants pour développer les applications requises.
– L’équipe de développement peut sélectionner les meilleurs solutions pour leurs besoins,
sans etre verrouillée par l’offre du fournisseur unique.
– Tous les composants sont gratuits.
4.2.2 Gestion de la base de données
Oracle DataBase Oracle est un SGBDR édité par la société du meme nom Oracle Corpora-
tion leader mondial en base de données. Oracle peut assurer entre autres fonctionnalités :
– La d´finition et la manipulation des données.
– La cohérence des données.
– La confidentialité des données.
– L’intégrité des données.
MySQL MySQL a pour origine l’application mSQL. Cette application permettait de ce connec-
ter à des tables en utilisant des routines bas niveau. Cependant, après quelques tests, les déve-
loppeurs sont arrivés à la conclusion que mSQL n’était pas assez rapide et flexible pour leurs
besoins. Le serveur de bases de données MySQL est très rapide, able et facile à utiliser. Il dis-
pose aussi de fonctionnalités pratiques, développées en coopération avec les utilisateurs.
Les principales fonctionnalités qu’offre MySQL sont :
– Fonctionne sur de nombreuses plate-formes.
– Dispose d’API pour C, C++, Eiffel, Java, Perl, PHP, Python, Ruby et Tcl.
– Compl¨tement multi-threadé, grace aux threads du noyau. Cela signifie qu’on peut l’uti-
liser facilement sur un serveur avec plusieurs processeurs.
– Tables B-tree très rapide, avec compression d’index.
– Système d’allocation mémoire très rapide, exploitant les threads.
– Tables en mémoire, pour réaliser des tables temporaires.
– Les fonctions SQL sont implémentées grace à une librairie de classes optimisées, qui sont
aussi rapides que possible.
PostegreSQL PostgreSQL est un SGBD relationnel objet Open Source implémenté par l’univer-
sité de Ber-keley. Les fonctions clés du mod¨le objet de PostgreSQL sont les classes, l’héritage
et la surcharge. PostgreSQL est un logiciel â modulaire â possédant un langage d’écriture de
procédures similaire à celui d’Oracle mais également d’autres interfaces de programmation.
Voici les fonctions clés du modèle orienté objet de PostgreSQL :
36

– Les classes : une classe correspond à un ensemble d’objets possédant un identificateur
unique.
– L’héritage : la notion d’héritage correspond à une organisation hiérarchique des tables.
Par exemple, si deux tables se trouvent dans une relation parent/enfant, les informations
contenues dans la table parent sont également disponible dans la table enfant.
– La surcharge : On parle de " surcharge de fonction " lorsqu’une fonction peut etre définie
plusieurs fois avec des paramètres différents.
4.2.3 Choix retenus
La clareté de l’architecture qu’elle propose ainsi que la multitude des IDE qui peuvent la
supporter et sa gratitude, la technologie J2EE a été le choix Judicieux pour le développement de
notre application. L’IDE sur lequel nous avons choisit de développer notre application est l’IDE
Eclipse. Une base de donnée MySQL est celle qui va être implémentée pour gérer les données
nécessaires à l’application.
4.2.4 Environnement logiciel
Eclipse Eclipse est un environnement de développement intégré (Integrated Development
Envi-ronment) dont le but est de fournir une plate-forme modulaire pour permettre de réaliser
des développements informatiques. I.B.M. est à l’origine du développement d’Eclipse qui est
d’ailleurs toujours le cœur de son outil Websphere Studio Workbench (WSW), lui même à la
base de la famille des derniers outils de développement en Java d’I.B.M. Tout le code d’Eclipsea
a été donné à la communauté par I.B.M afin de poursuivre son développement.
Eclipse utilise énormément le concept de modules nommés " Plug-ins " dans son architecture.
D’ailleurs, hormis le noyau de la plate-forme nommé " Runtime ", tout le reste de la plate-
forme est développé sous la forme de Plug-ins. Ce concept permet de fournir un mécanisme
pour l’extension de la plate-forme et ainsi fournir la possibilité aux tiers de développer des
fonctionnalités qui ne sont pas fournies en standard par Eclipse.
Tomcat Tomcat est un serveur d’application totalemet écrit en java. A partir de la version 5.0,
il implémentait les spécifications 2.4 des JavaServlet et 2.0 des JSP. Tomcat a été développé en
open source au sein du projet Apache Jakarta, dont le but est de fournir des solutions serveur
basées sur la plate-forme Java, de qualité identique aux applications commerciales. Tomcat est
37

un moteur d’exécution pour les servlets et les pages JSP. Il prend en charge la partie dynamique
du site et laisse la partie statique au serveur web.
4.3 Travail réalisé
A cette étape du rapport, nous donnons les captures d’écran relatives aux pages des princi-
pales fonctions réalisées par l’application.
FIGURE 4.3 – Interface d’acceuil
FIGURE 4.4 – Interface de l’espace de l’administrateur
38

FIGURE 4.5 – Interface de l’espace du responsable d’achat
FIGURE 4.6 – Interface de l’espace du responsable de stock
39

FIGURE 4.7 – Interface de l’espace du responsable
FIGURE 4.8 – Interface de l’espace de l’utilisateur
40

FIGURE 4.9 – Interface de la demande d’achat
FIGURE 4.10 – Interface de la commande d’achat
41

FIGURE 4.11 – Interface de la validation de réception
FIGURE 4.12 – Interface de la gestion des fournisseurs
42

FIGURE 4.13 – Interface de la gestion des catalogues
FIGURE 4.14 – Interface de la gestion des articles
43

FIGURE 4.15 – Interface de la gestion des sorties des articles
FIGURE 4.16 – Interface de la consultation des articles
44

FIGURE 4.17 – Interface de l’administration des groupes
FIGURE 4.18 – Interface de l’administration des utilisateurs
45

FIGURE 4.19 – Interface de la gestion des accès des groupes
FIGURE 4.20 – Interface de la consultation des rôles
46

FIGURE 4.21 – Interface de la consultation des mouvements
FIGURE 4.22 – Interface de la gestion des sites
47

FIGURE 4.23 – Interface de la consultation des articles par site
.
48

Conclusion Générale
LEs ERPs sont un produit d’avenir au moins en Tunisie car ils permettent l’automatisation
des tâches ,une optimisation des gains et une bonne gestion des ressources.
L’objectif de ce projet était de concevoir et de développer deux modules faisant parti d’un ERP
destiné aux entreprises classées en tant que PME. Pour réaliser le travail nous avons utilisé
le framework JSF pour le développement des applications web et MySQL pour la gestion des
bases de données. Pour la programmation de cette applications Web, nous avons utilisé l’IDE
Eclipse suivant l’architecture MVC ainsi qu’Hibernate pour la manipulation de la couche de
persistance.
En tant que perspective, nous pouvons proposé le développement d’autres modules de l’ERP
tels que la production, la ﬁnance, les ressources humaines et la comptabilité aﬁn de présen-
ter un produit complet, pouvant automatiser plusieurs taches, aux petites et moyennes entre-
prises.
49

Bibliographie
[0] Al-Mashari M., Al-Mudimigh A., and Zairi M.. (2003). Enterprise resource planning : A
taxonomy of critical factors. European Journal of Operational Research, 146(2), 352-364.
[1] Robert Jacobs and Ted Weston Jr. (2007). Enterprise resource planning (ERP) - A brief
history. Journal of Operations Management, 25(2), 357-363.
[2] Davenport T.. (2000). Mission Critical : Realizing the Promise ok Enterprise Systems.
Boston, Massachusetts : harvard Business School Press.
[3] Alshawi S., Themistocleous M. and Almadani R.. (2004). Integrating diverse ERP Sys-
tems : a case study. The Journal of Enterprise Information Management, 17 (6), pp. 454-462.
[4] Themistocleous M., Irani Z. , O’Keefe R. and Paul R.. (2001). ERP Problems and Appli-
cation Integration Issues. Proceedings of the 34th Hawaii International Conference on System
Sciences : An Empirical Survey ( HICSS-34) , (9), pp. 1-10.
[5] Soh C., Kien S. and Tay-Yap. (2000). Cultural Fits and Misﬁts : Is ERP a Universal solu-
tion ? Communications of ACM , 43 (4), pp. 47-51.
[6] Sumner M.. (1999). Critical Success Factors in Enterprise Wide Information Management
Systems Projects. Proceedings of the 1999 ACM SIGCPR Conference on Computer Personnel
Research , pp. 297-303.
[7] Lee j., Siau K. and Hong S.. (2003). Enterprise Integration with ERP and EAI. Communi-
cations of the ACM , 46 (2), pp. 54- 60.
[8] Murphy K. and Simon S.. (2002). Intangible beneﬁts valuation in ERP projects. Informa-
tion Systems Journal , 12, 4, pp. 301- 320.
[9] Markus M. L. and Tanis C.. (2000). The Enterprise System Experience-From Adoption to
Success. In R. W. Zmud (Ed.), Framing the Domains of IT Management : Projecting the Future
Through the Past (pp. 173-207).
50

Netographie
[10] www.entreprise-erp.com, date de dernière consultation 05/03/2015.
[11] www.erp-logiciel-gestion.com, date de dernière consultation 20/03/2015.
[12] www.erp.comprendrechoisir.com, date de dernière consultation 04/04/2015.
[13] www.microsft.com, date de dernière consultation 23/04/2015.
51

Glossaire
A
API Application Programmable Interface.
ASP Active Server Pages.
C
CLR Common Language Runtime.
E
EJB Entreprise JavaBean.
ERP Entreprise Ressource Planning.
E
HQL Hibernate Query Language.
HTTP Hyper Text Transfer Protocol.
I
IDE Integrated Development Environment.
J
JDBC Java Data Base Connectivity.
JSF Java Server Faces.
52

Glossaire
JSP Java Server Pages.
M
MVC MODEL-VIEW-CONTROLLER.
P
PGI Progiciel de Gestion Integré.
PME Petites et Moyennes Entreprises.
S
SI Syst¨me d’Information.
SQL Structured Query Language.
U
UML Uniﬁed Modeling Language.
53

Projet de conception et de développement

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Projet de conception et de développement

Similaire à Projet de conception et de développement (20)

Dernier

Dernier (20)

Projet de conception et de développement