Projet de conception et de développement

�dure d'achat.2.515

_achat _achat

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écification des besoins 7

2.1 Les acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Spécification 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 figures

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écification 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 figure 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 figure 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 figure 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 figure 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

DAns 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’affichage 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 figure ci-dessous présente les différentes classes du package traitement.

22


FIGURE 3.4 – Diagramme de traitement

Dans la figure 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 afin 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

TOut 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

APrè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

Afin de réaliser ce projet dans les conditions favorables, nous avons mis en notre disposition

deux ordinateurs avec les configurations 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 confidentielles, 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écifique 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 afin 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 afin 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éfinir 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 simplifié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 modifiables.

– 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 df́inition 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 finance, les ressources humaines et la comptabilité afin 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 Misfits : 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 benefits 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 Unified Modeling Language.

53

Projet de conception et de développement

Engineering

Transcript of Projet de conception et de développement