Ministre de l'enseignement suprieur et de la recherche scientifique
Universit Mouloud Mammeri de Tizi Ouzou Facult de gnie lectrique et d'informatique Dpartement d'informatique Mmoire de fin d'tude En vue de l'obtention du diplme Master 2 en informatique. Option: Conduite de Projet Informatique (CPI).
Thme Conception et Ralisation dune application pilote pour la gestion commerciale (cas : ELIT/SONELGAZ).
Encadrer par: Ralis par : Mm TAOURI Dalila CHAMI - Mhand Mr YOUSNADJ Boussad KHADRAOUI - Kamal
2013/2014
Sommaire : Introduction... ...1 I. La phase dEtude ..1 I.1. Expression du besoin..1 I.2. Etude dOpportunit Analyse du ROI.2 I.2. Etude de Faisabilit ....2 II. La phase dInitialisation...3 II.1 Lancement du Projet...3 II.1. Organisation du Projet...4 III. La phase de Conception..4 III.1. Diagnostic de la situation 4 III.2. Recherche de Solutions ...5 III.3. Formalisation des Solutions.5 IV. La phase de Ralisation..6 IV.1. Prparation...6 IV.2. Excution.6 IV.3. Validation7 IV. La phase de Mise en uvre ...7 IV.1.Ralisation du site pilote...7 IV.2. Dploiement.8 IV.2. Assistance utilisateurs .8 Conclusion8 Chapitre II : ..9 Phase dEtude au sein dELIT..9 I. Organigramme de lentreprise 10 I.1.Prsentation de SONELGAZ ...10 I.2. Historique 11 I.3. Organisation du Groupe....12 I.4. Organisation de service commerciale au sein des socits SONELGAZ ...15 I.5. Prsentation de la structure daccueil : ELIT ...15 II. Etude dopportunit17 II.1. les bnfices en attendre 19 III. Etude de la faisabilit19 Conclusion..20 Chapitre III : ...21 Conception..21 I. Le Diagnostique...22 I.A. Approche par processus (Etude de lexistant) .22 I.A.1. Schma Gnrale de fonctionnement du service commercial ..22 I.A.3. Les diffrents Processus du Service Commerciale ...25 I.A.3.1. Tenu du fichier Client ....25 I.A.3.2. Prparation Commerciale ..25 I.A.3.3. Commande Client ..26 I.A.3.4. Facturation Client...26 I.A.3.5. Rglement client (Trsorerie) 27 I.A.3.4. Relance Client....27 I.A.5. Dtails des Fonctionnalits du service commercial ..28 I.A.5.1. Gestion des Clients 28 I.A.5.2. Edition des tats Clients ...29 I.A.5.3. Gestion des conventions cadre ..29 I.A.5.4. Gestion des avenants .30 I.A.5.5. Gestion des contrats de prestations ...30 I.A.5.6. Gestion des prestations/articles .31 I.A.5.7. Gestion des devis et des rvisions devis31 I.A.5.8. Gestion des Commandes32 I.A.5.9. Gestion des Factures Clients..32 I.A.5.10. Gestion des Relances Clients...33 II. Recherche des solutions et Objectifs..34 III. Description et Formalisation de la solution...35 III.a. Solution partag sous un rseau (intranet) .35 III.b. Modlisation de la solution ...36 III.b.1. Formalisation de laspect dynamique..36 III.b.1.1.Prsentation dUML..36 III.b.1.2.Prsentation du projet raliser37 III.b.1.3. Spcification des besoins & cas dutilisation ..37 III.b.1.3.1. Identification des acteurs..37 III.b.1.3.2. Identification des cas dutilisation ...38 III.b.1.4. Description cas dutilisation .......39 III.b.1.4.1. Gestion Des Clients...39 III.b.1.4.2. Gestion Des Commandes clients...40 III.b.1.4.3. Gestion des factures clients ..41 III.b.1.4.4. Gestion des produits 42 III.b.1.5. Les Diagramme de squences ..43 III.b.1.5.1. Diagramme de squence du cas dutilisation crer un client 44 III.b.1.5.2. Diagramme de squence du cas dutilisation modifier un client ..45 III.b.1.5.3.Diagramme de squence du cas dutilisation ajouter une commande46 III.b.1.5.4. Diagramme de squence du cas dutilisation ajouter un produit:..47 III.b.1.5.6 Diagramme de squence du cas dutilisation crer une facture.49 III.b.1.5.7 Diagramme de squence du cas dutilisation ajouter un utilisateur50 III.b.1.6.Diagrammes dactivit pour quelques cas dutilisation .51 III.b.2. Formalisation de la partie statique56 III.b.2.1. Prsentation du dictionnaire des donnes 56 III.b.2.2.Prsentation des classes association et methode 59 III.b.2.3. Diagramme de classe 61 Conclusion....63 Chapitre IV :.63 Realisation63 I. Prparation ...64 I.A. Mthode de Gestion de Projet SCRUM .64 I.A.1. Qu'est-ce que Scrum ?............................................................................................................64 I.A.2. Scrum, vue d'ensemble...65 I.A.3. Les rles dans Scrum..65 I.A.3.1.Le Product Owner65 I.A.3.2. Le scrummaster:..66 I.A.3.3.L'quipe...66 I.A.3. Le Backlog produit67 I.A.4. Le sprint:...68 I.B. Choix des outils technologiques ..68 I.B.1.Description des serveurs 68 I.B.1.1 Serveur de base de donnes.68 I.B.1.2 Serveur dApplication:68 I.B.2.JEE6 ..69 I.B.3.NetBeans IDE 7.4 .71 I.B.4. Frameworks de dveloppement71 I.B.4.1.Entreprise Java Bean : EJB 3.1 ..71 I.B.4.2.Java Persistance API : JPA.72 I.B.4.2.1 Dfinition ....72 I.B.4.2.2 les principaux services de lAPI JPA se sont ..72 I.B.4.2.3 certaines rgles qui doivent tre respect pour assurer la transformation des objets en entits et ainsi devenir persistants ...73 I.B.4.3. Java Server Faces : JSF 2 .73 I.B.5. Architecture applicative74 II.Excution74 II.a. Application de la mthode SCRUM...75 II.b. Description de larchitecture de lapplication.77 II.b.1. les diffrents espaces...77 II.b.2 prsentation des fonctionnalits de lapplication .78 II.b.2.1. Commande et Facturation 79 II.b.2.2.Enregistrer les donnes de bases ...79 II.b.2.3. Facture .82 II.b.2.4. Edition de la facture .83 Conclusion .83
Remerciement
ous remercions Dieu le tout puissant qui nous a donn le courage et la volont pour achever ce modeste travail ous tenons remercier particulirement, notre promotrice Madame TAOURI Dalila pour son aide, ses conseils, le suivi et lintrt quelle nous a apporte tout au long de ce travail. os remerciements vont galement tout le personnel dELIT de SONELGAZ, particulirement Monsieur YOUSNADJ Boussad et Madame Bouali Nadia. ous voudrions galement remercier vivement les membres du jury qui ont aimablement accept dexaminer et estimer notre travail. tous ceux qui nous ont conseills et encourags mais que nous navons pas pu citer, quils trouvent ici lexpression de nos remerciements les plus sincres.
Ddicaces
Je ddie ce modeste travail : A celle qui a berc mes rves : ma mre ; A ce lui qui a nourri mes ambitions : mon pre ; A mon ange gardien : mon frre ; A celles qui ont soulev bien des fardeaux avec moi : Mes surs ; A ceux qui mont encourag et aid : mes amis ; A celle qui sera fire de moi : ma famille ; A mes collgues et leurs familles ; A toute la promotion 2014 ; Mhand Ddicaces
Je ddie ce modeste travail : A celle qui a berc mes rves : ma mre ; A ce lui qui a nourri mes ambitions : mon pre ; A mon ange gardien : mon frre ; A celles qui ont soulev bien des fardeaux avec moi : Mes surs ; A ceux qui mont encourag et aid : mes amis ; A celle qui sera fire de moi : ma famille ; A mes collgues et leurs familles ; A toute la promotion 2014 ; Kamel
Liste des tableaux
Tableau 1: Schma Gnrale24 Tableau 2 : Fonctionnalits de Service Commercial27 Tableau 3 : fonctionnalit Gestion des Clients28 Tableau 4 : Edition des tats Clients29 Tableau 5 : Gestion des conventions cadre. 29 Tableau 6 : Gestion des avenants30 Tableau 7 : Gestion des contrats de prestation30 Tableau 8: Gestion des prestations/articles.31 Tableau 9 : Gestion des devis et des rvisions devis31 Tableau 10 : Gestion des commandes32 Tableau 11 : Gestion des Factures Clients33 Tableau12 : Gestion des relances Clients34 Tableau13 : Identification des acteurs37 Tableau14 : Liste des cas utilisations38 Tableau 15 : dictionnaire de donnes55 Tableau 16 : tableau association et methode..58
Listes des Figures
Figure1 : Les entres et sorties de la phase dtude..1 Figure2 : Les entres et sorties de la phase dinitialisation...3 Figure3 : Les entres et sorties de la phase de conception....4 Figure4 : Les entres et sorties de la phase de ralisation....6 Figure5 : Les entres et sorties de la phase mise en uvre ..7 Figure6 : Prsentation de SONELGAZ10 Figure7: Schma de lOrganisation..14 Figure8: Organisation de service commerciale15 Figure 9: Organigramme de la filiale ELIT16
Figure 10 : Organisation de la Direction Etudes et Dveloppement...17 Figure II : schma de larchitecture client/serveur 3 tiers...36 Figure13: Cas dutilisation Gestion des commandes clients...40 Figure14 : Cas dutilisation Gestion des factures clients.41 Figure 15: Cas dutilisation Gestion des produits42 Figure 16: Cas dutilisation Gestion des relances clients.43 Figure17: Diagramme de squence du cas dutilisation Crer un client 44
Figure18: Diagramme de squence du cas dutilisation Modifier un client45 Figure19: Diagramme de squence du cas dutilisation ajouter une commande.46 Figure20: Diagramme de squence du cas dutilisation ajouter un produit.47 Figure21: Diagramme de squence du cas dutilisation modifier un produit48 Figure22: Diagramme de squence du cas dutilisation crer une facture.49 Figure23: Diagramme de squence du cas dutilisation crer un utilisateur.50 Figure 24: Diagramme dactivit pour le cas dutilisation crer un client ..51 Figure 25: Diagramme dactivit pour le cas dutilisation modifier un client 52 Figure26 : Diagramme dactivit pour le cas dutilisation crer une commande.53 Figure27 : Diagramme dactivit pour le cas dutilisation crer un produit.54 Figure 28: Diagramme dactivit pour le cas dutilisation modifier un produit54 Figure 29: Diagramme dactivit pour le cas dutilisation crer une facture55 Figure30 : Diagramme de classe..61 Figure31 : Vue d'ensemble de Scrum65 Figure32 : le serveur java EE Glass Fish...69 Figure33 : Architecture dune application JEE..70 Figure 34: NETBEANZ 7.4...71 Figure35 : Architecture de SI GTR selon le design pattern MVC...74 Figure36 : Interface dauthentification...78
Figure37 : Interface Ecran daccueil des modules.78 Figure38: Interface module commande facturation...79 Figure39 : Interface Enregistrement de donnes de bases.79 Figure40 : Interface Ecran Gestion des clients 80 Figure41 : Interface Ecran ajout dun nouveau client80 Figure42 : Afficher dtails client81
Figure43 : Modification des informations client81
Figure44 : Interface module commande82 Figure45 : Interface module Facture..82 Figure46 : Edition de la facture ..83
Introduction Gnrale
Introduction Gnrale
Introduction Gnrale
De l'ge de la pierre nos jours, l'esprit perfectionniste de l'homme n'a cess de lui permettre d'amliorer sa vie quotidienne. Le passage de la mcanique aux domaines d'informatique, d'lectronique, d'automatique et de domotique a rvolutionn la vie journalire de l'tre humain. Les nouvelles technologies de l'information et de communication illustrent ce phnomne. Aujourd'hui, vu l'intrt croissant de vouloir gagner du temps, de conserver les donnes, de limiter le nombre d'employs et de plusieurs autres raisons, les petites, moyennes et grandes entreprises se voulut pousses chercher des solutions informatiques capables de rpondre leurs besoins. Cest dans ce cadre destine tre gnralise par la suite dans dautres services. Sinscrit notre projet de fin d'tudes qui consiste raliser une application pilote de gestion commerciale pour le service commerciale dELIT (filiale de groupe SONELGAZ) Pour atteindre notre objectif nous avons partag le travail comme suit :le premier chapitre sagit de la pratique de la conduite de projet ,Le second chapitre s'agit de ltude qui compose Spcification des besoins (organigramme daccueil) Etude de lopportunit Etude de faisabilit Le troisime chapitre sera consacr la conception de l'application il s'agit des 3 phases Diagnostique Recherche des solutions Et enfin formalisation des solutions Pour de clore ce travail nous prsenterons les mthodes et outils utilises pour raliser l'application et prsenter les rsultats obtenus dans le quatrime chapitre Ralisation.
Chapitre I Prsentation de la Conduite de Projet Informatique
1
Introduction Un projet se compose de phases, elles-mmes dcoupes en tches, ou lots de travaux. Chaque lot de travail se caractrise par la production dun livrable. Il en est de mme pour chaque phase pour laquelle le livrable final valid par le sponsor permet dacter la russite de celle-ci et de dcider le passage dans la phase suivante. Rappelons que les diffrentes phases dun projet sont : Phase 0 Etude Phase 1 Initialisation Phase 2 Conception Phase 3 Ralisation Phase 4 Mise en uvre La ralisation de chaque lot de travail passe par lutilisation doutils techniques et de livrables caractristiques.
I. La phase dEtude Le succs de la phase dtude passe par la ralisation de trois tapes successives : Expression du besoin Etude dopportunit / Analyse du ROI Etude de faisabilit
Figure 1 : les entres et les sorties de la phase dtude
I.1. Expression du besoin Cette tape consiste traduire et formaliser lide de dpart en plan dactions concret. Cette formalisation est ncessaire car elle permet de clarifier les objectifs du projet en : Chapitre I Prsentation de la Conduite de Projet Informatique
2
Concrtisant lide de dpart, en la rendant comprhensible et accessible tous. Dgageant lintrt de lancer ltude en faisant apparatre ses avantages et ses inconvnients pour les bnficiaires. Dfinissant les consquences prvisibles des objectifs pour lenvironnement interne ou externe lentreprise. Cette formalisation doit tre le rsultat du travail du sponsor ou du matre douvrage : elle prcde ltude dopportunit
I.2. Etude dOpportunit Analyse du ROI Cette tape consiste dmontrer lintrt du projet, en termes de rentabilit conomique pour lentreprise. Le besoin doit tre formalis au regard de lentreprise dans son environnement concurrentiel et rglementaire. La dmarche sarticule autour de sept questions selon le type de projet : Le projet est-il stratgique pour lentreprise? Que font le march et la concurrence? Quelles sont les diffrentes contraintes pour lentreprise? Quels gains en attendre (financier, image, service client, social)? Pour quels cots? Pour quel retour sur investissement? Quels sont les risques faire le projet ou ne pas faire? Une analyse du march est parfois ncessaire pour : Analyser les conditions de mise sur le march; Identifier les avantages concurrentiels de chaque acteur; Evaluer la capacit du march absorber cette nouvelle offre. I.2. Etude de Faisabilit Ltude de faisabilit dun projet sapprcie sous plusieurs angles : Technique : quelles sont les solutions techniques possibles? Organisationnel : lentreprise dispose-t-elle des ressources humaines pour engager un tel projet? La mobilisation des ressources en interne est-elle compatible avec les missions oprationnelles de lentreprise? Chapitre I Prsentation de la Conduite de Projet Informatique
3
Temporel : quelles sont les adhrences avec les projets en cours de droulement ou planifis? Systme dinformation et processus : en quoi le futur projet impacte-t-il le systme dinformation actuel? les processus de pilotage? les processus oprationnels ? les processus supports? Ltude de faisabilit permet ce stade didentifier et de dfinir les scnarios de solution envisageables et dvaluer pour chaque scnario ses avantages et inconvnients. La dmarche de conduite dune tude de faisabilit sarticule autour de quatre tapes : Analyse des impacts techniques, organisationnels, rglementaires, systme dinformation, budgtaires; Identification des scnarios possibles; Choix dun scnario; Recensement des lments de cots pour les premires estimations.
II. La phase dInitialisation Le succs de la phase dinitialisation passe par la ralisation de deux tapes successives : Le lancement du projet. Lorganisation du projet.
Figure 2 : les entres et les sorties de la phase dinitialisation.
II.1 Lancement du Projet Le lancement dun projet se fait partir dune note de lancement. Celle-ci officialise le lancement du projet auprs de lensemble des responsables et des personnes concernes par le projet dans lentreprise. La note de lancement est rdige et diffuse au dmarrage du projet. Le document de lancement qui sera prsent lquipe projet doit reprendre les lments suivants : Chapitre I Prsentation de la Conduite de Projet Informatique
4
Le contexte du projet; Le rappel des enjeux et de la problmatique; Les objectifs fixs au projet; Lorganisation du projet; Les grandes tapes du projet; Le budget; Les facteurs cls de succs; Les livrables pour chacun des acteurs impliqus sur le projet; Les rgles et les mthodes qui seront utilises dans le cadre du projet.
II.1. Organisation du Projet La manire de structurer le projet est capitale.
III. La phase de Conception Le succs de la phase de conception passe par la ralisation de trois tapes successives : Le diagnostic de la situation; La recherche de solutions; La formalisation des solutions.
Figure 3 : les entres et les sorties de la phase conception.
III.1. Diagnostic de la situation Cette phase a pour objectif danalyser la situation existante afin didentifier, dans le cadre dun projet de rorganisation, les diffrents axes damlioration. Dans cette perspective il est Chapitre I Prsentation de la Conduite de Projet Informatique
5
important de bien comprendre le contexte et les enjeux pour lesquels la rorganisation est souhaite par les dirigeants de lentreprise. Le diagnostic doit permettre de recenser les forces et faiblesses de lorganisation existante et den apprcier les effets quant la bonne marche de lentreprise ou de lentit concerne par le diagnostic. Cette tape est capitale et conditionne la qualit des propositions de scnarios en vue de lamlioration de lorganisation existante. Elle permet didentifier les principaux processus en jeu et de dcliner ces processus en activits afin de mieux comprendre les missions de chacun dans lorganisation. Pour chaque activit il est utile didentifier et danalyser les dysfonctionnements. Pour identifier et rsoudre les dysfonctionnements, ou problmes rencontrs, plusieurs mthodes peuvent tre utilises : La dmarche de rsolution de problme; Lanalyse des causes/effets; chaque effet il convient de trouver la ou les causes correspondantes. Les causes pouvant tre de plusieurs natures : humaines; procdurales; culturelles; environnementales; organisationnelles
III.2. Recherche de Solutions Le point dentre dans la recherche de solutions est le rsultat du diagnostic. Une bonne connaissance de lexistant facilite la recherche de solutions. Les solutions retenues doivent donner par ailleurs une rponse aux dysfonctionnements constats. La rgle des 20/80 aide porter lattention sur limportance relative de diffrents faits en mettant en vidence les enjeux majeurs. La recherche de solutions demande souvent une certaine ouverture desprit et un travail dquipe. Pour chaque solution, il est notamment ncessaire didentifier les impacts et conditions de mise en uvre. Les principaux impacts sur lesquels il faut porter une attention particulire sont les suivants : Organisationnels : conditions de travail, structure, rattachement hirarchique ou fonctionnel; Humains : ncessit dune conduite du changement (formation, modification de fonctions, communication interne ou externe, conditions de dploiement); Systme dinformation : modification de certains processus, adaptation des outils de production, refonte des procdures; Juridique; Chapitre I Prsentation de la Conduite de Projet Informatique
6
Logistique.
III.3. Formalisation des Solutions
Les solutions identifies doivent tre formalises dans un dossier de choix permettant de faire le choix le plus adapt entre elles. Les critres pris en compte sont souvent : Le niveau thorique dadquation aux besoins exprims dans le cahier des charges; Le retour sur investissement de chaque solution; Un certain nombre de critres annexes : Difficults techniques; Attrait pour les utilisateurs, usagers, clients; Facilit dentretien, de rparation, dvolutivit
IV. La phase de Ralisation Le succs de la phase de ralisation passe par le droulement de deux tapes successives : La prparation; Lexcution.
Figure 4 : les entres et les sorties de la phase ralisation.
IV.1. Prparation Cette tape comprend la planification des tches, la dfinition du programme et la mobilisation des ressources.
IV.2. Excution Cette tape consiste construire le produit fini qui rpondra aux objectifs assigns dans le cahier des charges.
Chapitre I Prsentation de la Conduite de Projet Informatique
7
IV.3. Validation Cette tape permet de sassurer de la conformit du produit du projet par rapport au cahier des charges. Il est ncessaire de prvoir dans la mesure du possible des sances de pr validation.
IV. La phase de Mise en uvre Le succs de la phase de mise en uvre passe par la ralisation de huit tapes successives : Lidentification des forces en prsence; La stratgie de passage de gap; La ralisation du site pilote; Le dploiement; Lassistance utilisateurs; Les actions daccompagnement; Les mesures de contournement; La dissolution de la structure projet
Figure 5 : les entres et les sorties de la phase mise en uvre.
IV.1.Ralisation du site pilote
Dans les projets concernant de nombreux bnficiaires, il est prudent de procder un test avant dploiement. Ce test appel site pilote permet dvaluer, en situation, la performance Chapitre I Prsentation de la Conduite de Projet Informatique
8
du rsultat du projet et de raliser les ajustements ncessaires (favorisant le confort des utilisateurs par exemple).
IV.2. Dploiement
Le dploiement intervient aprs que les rsultats du site pilote aient t valids par toutes les parties prenantes. Il consiste installer dans chacun des sites concerns loutil, lorganisation, les rgles de gestion dfinis dans le projet et tests dans le cadre du site pilote. Le dploiement contient plusieurs aspects : Aspects techniques : installation des machines, des matriels, des logiciels Aspects humains : formation des utilisateurs, assistance sur place et/ou distance; Aspects procdures : rdaction des guides de procdures, des rgles de contrle interne
IV.2. Assistance utilisateurs
Lassistance utilisateurs consiste apporter une assistance distance grce au tlphone ou Internet. Il est aussi possible la hot line de prendre la main sur le poste de travail informatis des utilisateurs afin de raliser leur place certains paramtrages.
Conclusion Dans ce chapitre nous avons prsent la conduite de projet informatique avec ces diffrentes phases.
Chapitre II Etude
9
Chapitre II : Phase dEtude au sein dELIT
Chapitre II Etude
10
I. Organigramme de lentreprise SONELGAZ est loprateur historique dans le domaine de la fourniture des nergies lectriques et gazires en Algrie. Ses missions principales sont la production, le transport et la distribution de llectricit ainsi que le transport et la distribution du gaz par canalisations. Son nouveau statut lui donne la possibilit dintervenir dans dautres segments dactivits tels que la commercialisation de llectricit et du gaz ltranger. I.1.Prsentation de SONELGAZ La restructuration de Sonelgaz en 2002 sest acheve avec la cration de la socit holding Sonelgaz ainsi que lensemble des filiales. Sonelgaz est aujourdhui rig en Groupe industriel compos de 35 filiales et 5 socits en participation.
Figure 6 : Prsentation de SONELGAZ.
Chapitre II Etude
11
I.2. Historique Depuis sa cration le Groupe est pass par diffrentes phases dvolution dont nous reprenons les principales dates : 1947 : Cration de lEtablissement Public National Electricit et Gaz dAlgrie, EGA par le dcret du 5 juin 1947. Le 16 aot 1947, seize socits qui se partageaient les concessions lectriques ont t transfres EGA. Ces socits dtenaient alors 90% des proprits industrielles lectriques et gazires du pays. 1969 : Le 28 juillet 1969 la dissolution de lEGA et la cration de la nouvelle Socit Nationale de lElectricit et du Gaz -SONELGAZ- fts dcrtes dans le cadre des mesures de nationalisation des secteurs cls de lconomie nationale. Lordonnance prcite a attribu la SONELGAZ le monopole de la production, du transport, de la distribution, de limportation et de lexportation de llectricit et du gaz manufactur. Lensemble des biens de lex EGA lui a t lgu. 1983 : Externalisation des activits de ralisation des travaux dans le cadre de la restructuration de la SONELGAZ qui conduit la cration de six entreprises travaux autonomes : KAHRIF pour llectrification; KAHRAKIB pour les travaux et montage lectriques, KANAGAZ pour la ralisation des rseaux gaziers; INERGA pour la ralisation des infrastructures, ETTERKIB pour le montage industriel et AMC pour la fabrication de compteurs et appareils de mesure et de contrle. 2002 : Promulgation de la loi 02/01 le 5 fvrier 2002 relative llectricit et la distribution du gaz par canalisations qui est venue supprimer le monopole exerc jusque- l par SONELGAZ en ouvrant les activits de production et de distribution la concurrence. En juin 2002, en vertu du dcret prsidentiel n02-195 le statut de SONELGAZ passe dEPIC Socit Par Actions -SPA- dont le capital est dtenu par lEtat. 2004 : Cration de trois filiales mtier de base : Sonelgaz Production Electricit SPE, Gestionnaire Rseau Transport Electricit GRTE et celui du Gaz GRTG. 2006 : Cration de quatre socits de distribution : Alger SDA, Centre SDC, Est SDE et Ouest SDO, et filialisation de lOprateur Systme OS. 2008 : Parachvement du processus de restructuration avec la filialisation des activits Systmes dinformation ELIT, de lEngineering de llectricit et du gaz CEEG et la gestion du patrimoine foncier SOPIEG.
Chapitre II Etude
12
I.3. Organisation du Groupe
SONELGAZ a toujours jou un rle prpondrant dans le dveloppement conomique et social du pays. Afin de contribuer la concrtisation de la politique nergtique nationale, elle a initi dimportants programmes en matire dlectrification rurale et de distribution publique du gaz,qui ont permis de ramener le taux de couverture en lectricit 98% et celui de pntration du gaz 43%. Dtermine faire plus et mieux, la SONELGAZ a toujours mobilis des financements importants afin de dvelopper et renforcer linfrastructure lectrique et gazire. Durant la priode allant de 2005 2010, un programme dinvestissement exceptionnel a t mis en oeuvre afin daugmenter ses capacits de production dlectricit, de densifier et rendre plus robuste son rseau de transport et de moderniser ses services en faveur de la clientle. Lambition de la SONELGAZ est de devenir plus comptitif pour pouvoir faire face la concurrence et compter parmi les meilleurs oprateurs du bassin mditerranen. SONELGAZ a adapt son organisation aux principes et dispositions de la loi relative llectricit et la distribution du gaz par canalisations. Elle sest restructure pour sadapter au nouveau contexte. Ses organes de direction se sont renforcs pour mettre en oeuvre sa stratgie et raliser ses objectifs. SONELGAZ sest rige en Groupe Industriel compos de 40 socits dont 6 en participation. Le Groupe est constitu de la maison mre et des filiales. Ces dernires sont rparties par ple de mtiers, savoir les filiales mtiers de base, les filiales mtiers priphriques et les filiales travaux. Ci-aprs les attributions, missions et principes dorganisation des diffrentes entits constituant le Groupe : Maison Mre : Elle est charge du pilotage et de llaboration de la stratgie du Groupe, du contrle des filiales, de llaboration et la mise en oeuvre de la politique financire et de la dfinition de la politique de dveloppement de la ressource humaine. Filiales mtiers de base : Durant ces dernires annes, les mtiers de base de SONELGAZ ont t filialiss. Au nombre de huit, ces filiales assurent la production de llectricit ainsi que le transport et la distribution de llectricit et du gaz. Filiales travaux : Les entreprises de ralisation institues en entreprises autonomes dans le cadre de la restructuration de 1983 ont t rintgres au sein du Groupe depuis janvier 2006. Chapitre II Etude
13
Elles sont spcialises dans la ralisation des infrastructures nergtiques : engineering, montage industriel et ralisation des rseaux. Filiales priphriques : SONELGAZ a externalis ses activits priphriques et en a fait des filiales dont elle dtient entirement le capital. Ces filiales sont au nombre de quatorze et exercent les prestations de services telles que la maintenance des quipements nergtiques, lapprovisionnement et la distribution du matriel lectrique et gazier, le transport et la manutention exceptionnels, ou encore la mise en uvre de systmes dinformation Socits en participation : SONELGAZ dtient galement des participations dans des socits dont le mtier est en rapport avec le domaine de llectricit et du gaz tels que la production de llectricit ou encore la maintenance des turbines gaz.
I.3.1. Organigramme du Groupe Le Groupe SONELGAZ est linstrument de mise en uvre, par le biais de ses socits filiales, de la politique nergtique nationale. Lorganigramme suivant donne une vision claire de la structure et de lorganisation de la socit :
Chapitre II Etude
14
Figure 7 : Schma de lOrganisation.
DIRECTION GENERALE
331* Direction Planification et Suivi de Projets
15 Secrtariat (Mutualis) 03 Direction Progiciels de Gestion Intgre 74* Secrtaire de Direction 02 Direction Exploitation SI
48 Direction Rseaux et Tlcoms
28 Direction Finances / Comptabilit 13 Direction Ressources Humaines 12 Direction Commerciale 14 Service Affaires Gnrales 07 Division Administration Marchs 08 Assistant SIE 01 Assistant Direction Gnral 01 Service Communication 06 Direction Scurit des Systme dInformation
24 Direction SI des Activits de Distribution / Gestion de Rseaux
74* Chapitre II Etude
15
I.4. Organisation de service commerciale au sein des socits SONELGAZ
Figure 8 : Organisation de service commerciale.
I.5. Prsentation de la structure daccueil : ELIT
ELIT Spa El-Djazar Information Technology , est une filiale dite priphrique dont le capital est 100% dtenu par SONELGAZ. Elle a t cre en janvier 2009. Les missions qui lui ont t assignes par la Direction Gnrale du Groupe sont scindes en deux niveaux, stratgique et oprationnel. Au niveau stratgique, ELIT contribue la stratgie du Groupe par : Llaboration de la politique des systmes dinformation et des technologies de linformation et de la communication du Groupe. La prise en charge des besoins du Groupe et des filiales en matire dinformatique et de tlcommunications. Au niveau oprationnel, ELIT semploie : Elaborer et mettre en oeuvre les systmes dinformation destins au pilotage et la gestion des diffrentes activits du Groupe. Mettre la disposition de lensemble du Groupe les moyens informatiques et de tlcommunications. Chapitre II Etude
16
Assurer la maintenance et ladministration des systmes dinformation. Assurer laccs linformation et aux applications et en garantir la scurit, lintgrit et la fiabilit. Mettre la disposition des utilisateurs lexpertise technique indispensable la satisfaction de leurs besoins. Proposer, terme, ces mmes services aux clients externes. Lorganigramme suivant illustre la manire dont est organise la filiale ELIT :
Figure 9 : Organigramme de la filiale ELIT
Chapitre II Etude
17
I.5.1. Direction Etudes et Dveloppement (DED)
Nous effectuons ntre stage au sein de la Direction Etudes et Dveloppement. Cette direction a pour mission de mener : ltude, la conception, le dveloppement et le dploiement de solutions nouvelles et la mise en place des systmes dinformation du Groupe. En outre, elle offre lassistance ncessaire et le suivi des solutions dployes. Lorganigramme suivant reprend les diffrentes structures de la Direction Etudes et Dveloppement :
Figure 10 : Organisation de la Direction Etudes et Dveloppement
II. Etude dopportunit
Le Groupe Sonelgaz est compos dun ensemble de socits, issues de la restructuration de loprateur historique charg, pour le compte de lEtat, de la production du transport et de la distribution de llectricit ainsi que la distribution publique de gaz, en Algrie. La restructuration de Sonelgaz, a permis depuis quelques annes la cration dune socit holding, dnomme Sonelgaz SPA et plusieurs filiales, toutes juridiquement autonomes les unes des autres. Le Groupe Sonelgaz, ainsi constitu renferme actuellement 36 socits activant dans divers secteurs, et comptant prs 80 000 salaris de diffrents profils et catgories. ELIT tant la filire IT et pour rpondre aux besoins des autres filiales du Groupe Sonelgaz, sest lance dans plusieurs projets de dveloppement des systmes dinformations. Parmi Chapitre II Etude
18
dautres le progiciel de gestion Finances et comptabilit baptis HISSAB , le progiciel de gestion Ressources Humaines baptis NOVA , le systme de gestion des Stocks baptis ATTAD , le systme de gestion de la trsorerie, le systme de gestion engagements,...etc. Nanmoins, et pour rpondre davantages aux besoins des filiales du Groupe, dautres projets de dveloppement sont mener afin de satisfaire les exigences non prise en charges par les systmes existants. Pour cela et parmi les besoins les plus pertinents surgit celui dun systme de gestion commerciale pour le suivi des achats et des ventes des filiales du Groupe. Ce systme va permettre dinformatiser les procdures de gestion en vigueur, dune part, et de les harmoniser au niveau du Groupe dautre part. De ce fait les utilisateurs du systme, vont gagner en productivit et en performance et bnficier de tous les avantages quoffre une application informatique moderne. Les risques lis aux mtiers des structures commerciales, son organisation et aux procdures de gestion et on peut les list dans ce qui suit : Lorganisation et lorganigramme des structures commerciales sont diffrents dune filiale une autre selon limportance de lactivit commerciale dans la filiale, elle peut tre une direction compose de plusieurs dpartements, une division ou bien un simple service. Pour cela il faut trouver une organisation type implmenter dans le systme. Les procdures de gestion sont htrognes, elles diffrent dune filiale une autre selon la nature de ses activits et de son organisation interne. De ce fait il faut essayer dharmoniser la faon de faire afin davoir un systme qui rpond aux besoins de toutes les filiales. Les clients autour desquels opre lactivit commerciale sont diffrents dune filiale une autre, en effet il existe des filiales qui travaillent exclusivement avec les clients du groupe Sonelgaz, alors que dautres travaillent avec des clients hors-groupe Sonelgaz, voir mme trangers. Le systme dvelopper doit prendre en considration tous les types de clients possibles. Les procdures de gestion sont instables, elles subissent des changements rgulirement et Pour remdier cela il faut essayer de les prvenir et de ralise un systme paramtrable. Le systme commercial doit interagir avec les systmes dj en place, pour cela il doit respecter les conventions techniques dfinies pralablement (Architecture, outils et choix technologique,) afin de faciliter linteraction avec les autres systmes. Le systme commercial est au cur du systme dinformation de toute entreprise, il gre une relation Chapitre II Etude
19
essentielle savoir la relation client/Entreprise, Ne pas avoir un systme informatis qui gre lactivit commerciale empche lentreprise de bnficier de tous les avantages quoffre les technologies modernes en matire defficacit et de transparence dans le travail, de disponibilit dinformations, de la clart des procdures tches quotidienne accomplir. II.1. les bnfices en attendre Limplmentation de lapplication de gestion commerciale optimise lorganisation commerciale de lentreprise et gnre un gain de temps synonyme de rentabilit. Le retour sur investissement est en effet considrable et conduit lentreprise vers une dmarche qualit en amliorant les process de travail. Lapplication de gestion commerciale met laccent sur la qualit de traitement de linformation. Les analyses gnres par les informations contenues dans lapplication permettent en effet de prendre les bonnes dcisions au bon moment. Il est donc important de construire larchitecture de lapplication de manire rationnelle et solide. Lutilisation dun logiciel de gestion commerciale implique avant toute chose, une gestion extrmement rigoureuse des informations saisies. III. Etude de la faisabilit
Lentreprise est en relation avec ses clients et fournisseurs : devis, factures, bons de commande sont autant de documents rptitifs crer. Linformatique peut, dans ce domaine, simplifier la tche de lutilisateur grce une gamme de produit spcifique : lapplication de Gestion Commerciale Lapplication va permettre dorganiser les fichiers ncessaires de lentreprise lors de son fonctionnement. Ainsi, lentreprise, elle vende un produit ou un service, doit identifier ses clients et les rper- torier dans un premier fichier. Lorsque ces prospects demandent une proposition commerciale, lentreprise doit effectuer un devis pour les articles/prestations concerns. Apparaissent alors trois nouvelles nomenclatures : les devis, les produits et leurs fournisseurs. Pour finir, la vente est consigne dans une facture, elle aussi constituant un recueil de donnes Cette chane commerciale est donc, au minimum, constitue de 5 fichiers diffrents : produits, clients, fournisseurs, devis, factures/ventes.Lapplication de gestion commerciale va permettre de grer toutes ces bases de donnes et les liens qui existent entre elles. Il est Chapitre II Etude
20
intressant de retrouver, pour un client, les devis envoys, les ventes ralises, les fournisseurs par produits, les rglements en cours, ceux effectus Toutes ces informations seront facilement collectes dans un systme de gestion informatis
Conclusion Avec ses dcennies dactivit dans le domaine de lnergie et une rputation qui nest plus faire, la SONELGAZ est un acteur incontournable de lconomie nationale. Cette brve prsentation nous a permis den savoir un peu plus sur le Groupe. Par ailleurs, cette prsentation nous a fait comprendre lenvironnement, la structuration et lorganisation de la Direction commerciale qui est la fonction cible du prsent projet. Aussi, elle nous a permis de nous pencher sur linformatique du Groupe dsormais gre, au niveau national, par la filiale ELIT . Pour rpondre au dfi des changements induits par la loi 02/01 du 05 Fvrier 2002, SONELGAZ a entrepris plusieurs initiatives denvergure visant aligner ses processus et utiliser les technologies de linformation et de la communication pour soutenir sa stratgie. La mise niveau et la modernisation de l'ensemble des systmes informatiques de gestion figurent au premier plan des actions inscrites au Plan Stratgique de la SONELGAZ.
Chapitre III Conception 21
Chapitre III : Conception
Chapitre III Conception 22
Dans ce chapitre nous allons dcrire la conception de notre solution. Qui est reparties en 3 parties Diagnostique, recherche de solution et formalisation de la solution
I. Le Diagnostique
I.A. Approche par processus (Etude de lexistant)
Ltude de lexistant est une tape indispensable dans tout projet informatique, une bonne conception doit reposer sur une connaissance du systme actuel. Notre tude de lexistant portera sur la situation actuelle relative la gestion commerciale au sien dELIT. Elle met en vidence tous les documents y circulant, les procdures de travail, le circuit par lesquels circulent les informations ainsi que les ventuels problmes et insuffisances. Afin de mieux comprendre le systme et son environnement et enfin de proposer des solutions.
I.A.1. Schma Gnrale de fonctionnement du service commercial
Chapitre III Conception 23
Client Service commercial Systme adjacents
Ngociation Facture de retenue de garantie OV/Avis de crdit Rclamation/Erreur facture Facture de prestation Commande Demande prestation Informations client Signature Devis/Rvision devis Etablissement de la facture davoir Enregistrement du rglement Avec/Sans pointage des factures concernes (Rapprochement) Commande de prestation Attestation de service fait Facturation du service fait Avec/Sans remise Avec/Sans restitution montant davance Etablissement de la facture de retenue de garantie Etablissement de la facture davance Tenu du fichier client Signature des conventions cadre Signature des contrats de prestation Enregistrement de la demande du client HISSAB Systme de gestion finance et comptabilit
GTR Systme de gestion finance et comptabilit
Chapitre III Conception 24
Tableau 1 : Schma Gnrale.
Chapitre III Conception 25
I.A.3. Les diffrents Processus du Service Commerciale 1. Tenu du fichier client 2. Prparation commerciale 3. Commande client 4. Facturation client 5. Rglement client (Trsorerie) 6. Relance client
I.A.3.1. Tenu du fichier Client La tenue du fichier client consiste centraliser la totalit des informations concernant chaque client, afin dassurer un accs rapide et fiable et centraliser aux informations de chaque client. La tenue du fichier client comporte les donnes suivantes : Les informations didentification dun client (Code client, nom client, famille client,.) Les informations bancaires (banque, compte bancaire,.) Les modalits des rglements (mode rglement, le dlai de rglement,) Les renseignements fiscaux (N registre de commerce, N article fiscal,) Les informations dordre comptable (Compte de crance, Compte davance) Les informations sur le compte fournisseur, factures rgles et factures non rgls Un rcapitulatif des oprations entreprise avec le client (historique des commandes, des factures, des avoirs, des rglements ainsi que lhistorique des rceptions) I.A.3.2. Prparation Commerciale La prparation commerciale consiste enregistrer les donnes indispensables pour le traitement commercial savoir les conventions cadres, les contrats et les demandes de prestations, les devis et ventuellement les rvisions devis afin de traiter les commandes des clients. La prparation commerciale regroupe les taches suivantes : Enregistrement des conventions cadre Enregistrement des contrats de prestations Enregistrement des demandes de prestations Enregistrement des devis et rvisions devis
Chapitre III Conception 26
I.A.3.3. Commande Client Les commandes clients peuvent tre matrialises par : Les bons de commandes : Les lettres de commandes : Les commandes : Les marchs : Les informations lmentaires dune commande sont : N commande, date commande, client, article et/ou prestation,
I.A.3.4. Facturation Client Une facture atteste de la vente de biens (articles) et/ou de services (prestations). Une facture peut tre une facture de doit ou une facture davoir . Il peut y avoir plusieurs factures pour une seule commande (Contrat/March) Il existe plusieurs types de facturation : Facture 100% : Le montant de la totalit de la prestation est pay aprs excution. Facture davance : Facture pour un pourcentage prdfini dans le contrat. Facture de retenue de garantie : Facture pour un pourcentage prdfini dans le contrat Facture avec restitution davance : La facture comporte une retenue qui reprsente une partie ou la totalit de lavance selon les conditions du contrat. Facture avec retenue de garantie : Un pourcentage du montant est pay aprs excution de la prestation. Le reste (100 pourcentage pay) reprsente la retenue de garantie qui est dfalque du montant hors taxe de la facture, cette dernire peut tre rpartie en deux parties : La premire partie de la retenue est librable aprs la rception provisoire avec tablissement dune facture. La deuxime partie de la retenue de garantie est librable aprs la rception dfinitive (expiration du dlai garantie) avec tablissement dune facture. Facture avec remise : Le prestataire peut accorder une remise au client, cette dernire doit apparaitre sur la facture. Les dductions soprent sur le montant hors taxe.
Chapitre III Conception 27
I.A.3.5. Rglement client (Trsorerie) La fonctionnalit rglement client est assure au niveau du module Trsorerie. Toute fois une consultation de la situation de client ainsi que ses rglements doit tre assure au profil du gestionnaire commercial. Une facture est considre rgle au reu de son ordre de virement (OV) ou de lavis de crdit.
I.A.3.6. Facturation Client La relance des clients consiste mettre des lettres de rappel ou dans les cas extrme une lettre de mise en demeure pour les clients qui ont accuss des retards pour le payement de leurs factures. La relance ne concerne que les clients ayants des crances exigibles. La crance est dite exigible si : La date en cous >= Date de remise + Dlai de rglement. La lettre de relance doit mentionner : la date de son tablissement, le montant payer, le client concern, lmetteur de la lettre,. I.A.4. Les diffrentes Fonctionnalits du service commercial PROCESSUS FONCTIONNALITES ( Par Processus) Tenu du fichier client Gestion des clients : Crer, Modifier, Bloquer, Supprimer Edition des tats de client : Fiche client, Liste des clients, Relev client (dtaill et simple), Solde client Prparation commerciale Gestion des conventions cadre Gestion des contrats de prestations Gestion des avenants Editions des tats : Gestion des articles/prestations Gestion des modalits de rglement : dlais, mode rglement Commande client Gestion des commandes des clients (Suivi des commandes) Facturation Gestion des factures des clients : Crer, diter, Modifier ltat, Gestion des devis et des rvisions devis Gestion des tats des factures Edition des factures : Selon ltat, le fournisseur,.. Gestion des interfaces avec HISSAB Chapitre III Conception 28
Rglement client Gestion des rglements clients Gestion des modes de rglements Gestion des interfaces avec GTR (Rapprochement) Relance client Gestion des relances clients
Tableau 2 : Fonctionnalits de Service Commercial.
I.A.5. Dtails des Fonctionnalits du service commercial Chaque fonctionnalit se reforme : fonctionnalit : le nom de la fonctionnalit processus : le processus qui elle appartient niveau de traitement : niveau auquel se fait priorit : priorit de dveloppement
I.A.5.1. Gestion des Clients Fonctionnalit Gestion des clients Processus Tenu du fichier client Niveau de traitement Filiale Priorit 1 Principes et rgles et de gestion La gestion des clients consiste en la cration, la modification, la suppression et le blocage des clients. Rgles de gestion : Le client est unique dans lentreprise. Il existe plusieurs familles de clients. Les clients Sonelgaz sont traits de la mme manire que les clients externes. Le client peut tre bloqu sil est jug mauvais. NB : Les informations lmentaires du client sont jointes en annexe
Tableau 3 : fonctionnalit Gestion des Clients.
Chapitre III Conception 29
I.A.5.2. Edition des tats Clients Fonctionnalit Edition des tats de client Processus Tenu du fichier client Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Ldition des tats de client consiste imprimer la fiche client et les diffrents tats relatifs aux clients sous divers format (PDF, Excel,) Les tats relatifs aux clients sont : Liste des clients ; Relev client dtaill ; Relev client simple ; Solde client.
Tableau 4 : Edition des tats Clients.
I.A.5.3. Gestion des conventions cadre Fonctionnalit Gestion des conventions cadre Processus Prparation commerciale Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Les conventions cadres sont des accords signs entre le prestataire et le client. La convention dcrit les natures des prestations et/ou biens fournis et leurs modalits de mise en uvre en termes de taux et de dure. Rgles de gestions : Une convention concerne un et un seul client Une convention peut avoir un ou plusieurs prestations et/ou articles NB : Les informations lmentaires dune convention cadre sont jointes en annexe
Tableau 5 : Gestion des conventions cadre.
Chapitre III Conception 30
I.A.5.4. Gestion des avenants Fonctionnalit Gestion des avenants Processus Prparation commerciale Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Lavenant fait lobjet de clauses additionnelles permettant dapporter des modifications au contrat/convention pralablement tabli. Rgles de gestions : Un avenant fait rfrence un et un seul contrat/convention Un contrat/convention peut tre tendu par un ou plusieurs avenants NB : Les informations lmentaires dun avenant sont jointes en annexe Tableau 6 : Gestion des avenants.
I.A.5.5. Gestion des contrats de prestations Fonctionnalit Gestion des contrats de prestations Processus Prparation commerciale Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Les contrats de prestations sont des accords signs entre le prestataire et le client. Le contrat dcrit les natures des prestations et/ou articles fournis et leurs modalits de mise en uvre en termes de taux et de dure. Rgles de gestions : Un contrat est associ un et un seul client Un contrat peut contenir plusieurs prestations et/ou biens NB : Les informations lmentaires dun contrat de prestation sont jointes en annexe
Tableau 7 : Gestion des contrats de prestation.
Chapitre III Conception 31
I.A.5.6. Gestion des prestations/articles Fonctionnalit Gestion des prestations/articles Processus Prparation commerciale Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Les prestations commerciales reprsentent lensemble des services offerts par la socit, tandis que les biens sont les articles vendus par la socit. Rgles de gestions : Une prestation/bien doit avoir un et un seul code Chaque prestation/bien possde un prix unitaire (par dfaut). NB : Les informations lmentaires dune prestation/bien sont jointes en annexe
Tableau 8 : Gestion des prestations/articles.
I.A.5.7. Gestion des devis et des rvisions devis
Fonctionnalit Gestion des devis et des rvisions devis Processus Facturation Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Un devis (ou facture pro-forma) est un document crit prsent par un fournisseur proposant de vendre des biens et/ou des services des prix qu'il s'engage ne pas modifier tant que l'acheteur n'a pas exprim son intention de renoncer en faire l'acquisition et que la dure de validit nest pas expire. Rgles de gestions : Un devis fait rfrence un et un seul client. Le devis doit ncessairement contenir la liste des biens et/ou des prestations fournis. Le devis doit indiquer le dcompte dtaill, en quantit et en prix, de chaque bien/prestation. Le devis doit mentionner la somme payer Hors Taxes (HT) et Toutes Taxes Comprises (TTC), en prcisant le ou les diffrents taux de TVA appliqus. Le devis possde une dure de validit exprime en jours partir de la date de son tablissement. NB : Les informations lmentaires dun devis sont jointes en annexe
Tableau 9 : Gestion des devis et des rvisions devis. Chapitre III Conception 32
I.A.5.8. Gestion des Commandes Fonctionnalit Gestion des commandes Processus Prparation commerciale Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion La gestion des commandes de commandes des clients consiste en la cration, la modification et ldition des commandes. Les commandes clients peuvent tre matrialises par : Les bons de commandes : Toute opration dacquisition de biens ou de services dont le montant est infrieur ou gal cent milles dinars (100.000 DA), toutes taxe comprise. Les lettres de commandes : Toute opration dacquisition de biens ou de services dont le montant est infrieur ou gal cinq cent milles dinars (500.000 DA), toutes taxe comprise et suprieur cent milles de dinars (100.000 DA), toutes taxe comprise. Les commandes : Toute opration dacquisition de biens ou de services dont le montant est infrieur ou gal huit millions de dinars (8.000.000 DA), toutes taxe comprise et suprieur cinq cent milles dinars (500.000 DA), toutes taxe comprise. Les marchs : Tout contrat dacquisition de biens ou de services dont le montant est suprieur huit millions de dinars (8.000.000 DA), toutes taxe comprise. NB : Les informations lmentaires dune commande sont jointes en annexe
Tableau 10 : Gestion des commandes.
Chapitre III Conception 33
I.A.5.9. Gestion des Factures Clients Fonctionnalit Gestion des factures clients Processus Facturation Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion Une facture est le document qui atteste lopration de vente de biens et/ou de prestations de service. Cest un lment de preuve dune opration commerciale, qui renseigne sur les biens vendus et/ou les prestations rendues au client en termes de quantit et de prix. Une facture peut tre une facture de doit ou une facture davoir . Il existe plusieurs types de facturation : Facture 100% : Le montant de la totalit de la prestation est pay aprs excution. Facture davance : Facture pour un pourcentage prdfini dan le contrat. Facture de retenue de garantie : Facture pour un pourcentage prdfini dans le contrat Facture avec restitution davance : La facture comporte une retenue qui reprsente une partie ou la totalit de lavance selon les conditions du contrat. Facture avec retenue de garantie : Un pourcentage du montant est pay aprs excution de la prestation. Le reste (100 pourcentage pay) reprsente la retenue de garantie qui est dfalque du montant hors taxe de la facture, cette dernire peut tre rpartie en deux parties. Facture avec remise : Le prestataire peut accorder une remise au client, cette dernire doit apparaitre sur la facture. Les dductions soprent sur le montant hors taxe. Rgles de gestions : Une facture fait rfrence un et un seul client. La facture doit ncessairement contenir la liste des biens et/ou des prestations fournis. La facture doit indiquer le dcompte dtaill, en quantit et en prix, de chaque bien/prestation. La facture doit mentionner la somme payer Hors Taxes (HT) et Toutes Taxes Comprises (TTC), en prcisant le ou les diffrents taux de TVA appliqus. La facture mis au client doit tre rgle dans un dlai mentionn dans la facture en jours partir de la date de sa rception par le client. Une facture est dite exigible si son dlai de rglement par le client est expir. Le client peut ventuellement rejeter la facture dans un dlai dtermin (dans le contrat). Pass ce dlai, les arguments de rejet ne seront pas recevables et la facture sera considre accepte par le Client. Il peut y avoir plusieurs factures pour la mme commande, en dautres termes une facture peut solder la totalit ou bien une partie du montant de la commande. NB : Les informations lmentaires dune facture sont jointes en annexe
Tableau 11 : Gestion des Factures Clients. Chapitre III Conception 34
I.A.5.10. Gestion des Relances Clients Fonctionnalit Gestion des relances client Processus Relance client Niveau de traitement Filiale Direction rgionale - Unit Priorit 1 Principes et rgles et de gestion La relance des clients consiste identifier les clients dont des factures sont exigibles afin dentreprendre les dmarches ncessaires pour le payement de leurs factures par lenvoi de lettres de relance ou dans les cas extrmes des lettres de mises en demeure. Les lettres de relances sont des lettres de rappel mises pour les clients qui ont accuss des retards pour le payement de leurs factures. Rgles de gestions : Les lettres de relances concernent uniquement les factures dites exigibles . La lettre de relance doit mentionner la date de son tablissement et les factures payer. On peut mettre plusieurs lettres de relances pour les mmes factures du mme client.
Tableau 12 : Gestion des relances Clients.
I.B. Listes des diffrents dysfonctionnements
Toutes les procdures de traitement de l'Information sont manuelles et par consquent coteuses et source de beaucoup d'erreurs ; Le retard dans la production des rsultats d au fait du traitement manuel ; Cumul des fonctions d au manque de confiance envers le personnel et une mauvaise organisation entranant parfois conflits de comptences ; Gaspillage de la main d'uvre en utilisant plusieurs personnes produire une mme tche Baisse de rendement Certains documents sont trs mal prsents ce qui rend difficile leur exploitation aise ; Il manque certains documents qui nous semblent trs important dans la gestion commerciale tels que le Journal de vente, la solvabilit dun client, Les documents sont mal codifis
Chapitre III Conception 35
II. Recherche des solutions et Objectifs Aprs avoir analys le contexte du systme actuel, nous avons suggrs une solution informatique pouvant remdier aux diffrentes lacunes souleves durant notre stage La future application devra prendre en charge : La commande et facturation Le suivie des clients LAdministration systme Lensemble de ces processus devra rpondre aux fonctionnalits suivantes : Gestion des clients Gestion des produits Gestion des socits Gestion des directions Gestions des units Facture Devis Commande Rglement clients. Suivie client Gestion des administrateurs Edition Le futur systme aura pour objectifs : Rpondre aux besoins des gestionnaires. Amliorer la gestion commerciale au niveau technique et fonctionnelle de lentreprise. Amliorer la gestion des fournisseurs. Amliorer la gestion des clients. Amliorer le suivi des ventes.
III. Description et Formalisation de la solution
III.a. Solution partag sous un rseau (intranet) Vu que le futur systme concevoir doit tre d'une part, accessible par: Les diffrents agents de service commercial Les diffrentes structures de service commercial. On a opt pour la : Conception et ralisation d'une application trois niveaux (3 tiers) Chapitre III Conception 36
Lapplication renfermera trois modules applicatifs qui seront hbergs dans le serveur dapplication Lorganisation du travail entre les diffrents postes est donne par le schma suivant : Architecture Client/serveur 3 tiers :
Figure 11 : schma de larchitecture client/serveur 3 tiers.
III.b. Modlisation de la solution Dans cette partie nous allons formaliser notre solution. Qui est devis en deux parties Formalisation de laspect dynamique Formalisation de laspect technique
III.b.1. Formalisation de laspect dynamique Nous allons, dabord, commencer par introduire lenvironnement de travail : Langage de modlisation : Unified Modeling Language : UML. Outil de modlisation : PowerAMC.
Chapitre III Conception 37
III.b.1.1.Prsentation dUML UML (Unified Modelling Language) est la synthse des diffrentes notations que lon retrouve dans : Booch de Grady Booch, OMT (Object Modeling Technique) de Jim Raumbaugh et OOSE (Object-Oriented Software Engineering), de Ivar Jacobson. UML est en particulier conu pour tre lisible sur des supports courants et varis,comme le papier, les crans dordinateurs, etc. UML propose 9 diagrammes de modlisation, rpartis sur trois axes du niveau conceptuel : Fonctionnel. Structurel. Temporel. III.b.1.2.Prsentation du projet raliser Cest un logiciel qui doit grer la gestion des commercialisations au niveau de lentreprise(SONELGAZ).Il doit permettre de suivre les vents des produits aux clients depuis leur rception lentreprise.
III.b.1.3. Spcification des besoins & cas dutilisation III.b.1.3.1. Identification des acteurs Un acteur : Reprsente un rle que peut jouer lutilisateur dans le systme. Lacteur est associ un cas dutilisation; cest dire quil peut interagir avec lui et participer son scnario, il est reprsent par un personnage stylis. Les acteurs de notre systme sont : Acteur Rle Client Fait une commande
Utilisateur de systme Gestion des clients Gestion des commandes Gestion des produits Gestion des factures Gestion des rglements clients Gestion des relances clients Gestion des avenants
Chapitre III Conception 38
Administrateur de systme Administrer le systme Gestion des utilisateurs
Tableau 13: Identification des acteurs.
III.b.1.3.2. Identification des cas dutilisation
Un cas dutilisation reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier [ROQ, 04]. Nous allons donner dans ce qui suit lidentification des cas dutilisation obtenues aprs plusieurs itrations. Ensuite, nous allons prsenter les cas dutilisations, les diffrents acteurs associs et leurs interactions avec le systme. Liste des cas dutilisation : Cas utilisation 01 Crer un client 02 MAJ un client 03 Consulter un client 04 Dsactiver un client 05 Ajouter une commande 06 MAJ une commande 07 Consulter une commande 08 Imprimer une commande 09 Crer une facture 10 MAJ une facture 11 Consulter une facture 12 Imprimer une facture 14 Ajouter un produit 15 MAJ un produit 16 Consulter un produit 17 Supprimer un produit 18 Crer un avenant 19 Consulter un avenant 20 Imprimer un avenant Chapitre III Conception 39
Tableau14 : Liste des cas utilisations
III.b.1.4. Description des cas d`utilisation 21 Rgularisation des clients 22 Gestion des relances clients 23 Crer une famille 24 MAJ une famille 25 Consulter une famille 26 Crer un utilisateur 27 Consulter un utilisateur Chapitre III Conception 40
Dans ce qui suit nous proposons le diagramme des cas dutilisation en paquetages avec une description textuelle, cette dernire elle permet d`avoir une ide sur le fonctionnement de chaque cas d`utilisation.
III.b.1.4.1. Gestion Des Clients
Figure 12 : Cas dutilisation Gestion des clients But : Ce cas dutilisation permet lUtilisateur System de gre les clients et fait les ditions des tats clients. Acteurs Utilisateur de systme. Description Ds larrive dun client lutilisateur de systme crer une fiche client, Aprs l'enregistrement de ces informations, l'utilisateur a le droit de mettre jour ou consulter ou dsactiver, supprimer, dition des tats clients . Le scnario de gestion des commande permet de Uti l i sateurSystem Gre l es cl i ents Edi ti on des etats cl i ents Modi fi er un cl i ent Crer un cl i ent Affi cher un cl i ent Dsacti ver un cl i ent Rel ev cl i ent Sol de cl i ent Li ste cl i ent Fi che cl i ent Fi cher cl i ent word Fi che cl i ent pdf rel ev detai l l rel ev si mpl e Rechercher un cl i ent Suppri mer un cl i ent Chapitre III Conception 41
Crer un client MAJ un client Consulter un client Dsactiver un client Supprimer un client Edition tats clients
III.b.1.4.2. Gestion Des Commandes clients
Figure 13 : Cas dutilisation Gestion des commandes clients
But : Ce cas dutilisation permet lUtilisateur de systme de cre, de mettre jour et de consulter diter une Commande. Acteurs Utilisateur de systme Description A la rception de demande dachat lutilisateur va crer une nouvelle commande, remplit les informations ncessaires sur la Commande cre. Aprs l'enregistrement l'utilisateur a le droit de MAJ ou la consultation ou diter de Commande. Le scnario de gestion des commande permet de : Crer une Commande MAJ une Commande Ger l es commande cl i ent Edi ti on des commandes Crer une commande Modi fi er une commande Commande pdf Commande execl Uti l i sateurSystem Bon commande Lettre de commande Contrat Conventi on cadre Avenant Chapitre III Conception 42
Consulter une Commande Editer une commande III.b.1.4.3. Gestion des factures clients
Figure 14: Cas dutilisation Gestion des factures clients
But : Ce cas dutilisation permet lUtilisateur de systme de cre, de mettre jour, diter et de consulter ltat facture. Acteurs : Utilisateur de systme Description Pour crer une facture, lutilisateur doit remplir les renseignements ncessaires sur ce dernier. Aprs lenregistrement, lutilisateur a le droit de mettre jour ou consulter les factures en cas derreur. Le scnario de gestion des fournisseurs permet de : Crer une facture MAJ une facture Consulter ltat de la facture Editer une facture III.b.1.4.4. Gestion des produits
Ger l es factures cl i ent Edi ti on des factures Crer une facture Modi fi er l 'etat facture Facture pdf Facture execl Uti l i sateurSystem Ger l es etats des factures Chapitre III Conception 43
Figure 15 : Cas dutilisation Gestion des produits But : Ce cas dutilisation permet lutilisateur de systme de cre, modifier, mettre jour et consulter un Bien. Acteurs Lutilisateur de systme Description Lutilisateur de systme enregistr des biens(produits) rceptionn. Aprs l'enregistrement, l'utilisateur a le droit de mettre jour ou consulter ou supprimer.
Le scnario de gestion des Bien permet de Crer un produit MAJ un produit Consulter un produit Supprimer un produit
III.b.1.4.5. Gestion des relances clients : Aj outer un produi t affi cher l i ste produi t Uti l i sateurSystem Modi fi er un produi t Suppri mer un produi t Chapitre III Conception 44
Figure 16 : Cas dutilisation Gestion des relances clients
But : Ce cas dutilisation permet lutilisateur de systme denvoyer des lettres de relance ou lettres des mises en demeure au client. Acteurs : Lutilisateur de systme
Description : Lutilisateur de systme tablir des lettres de rappel mises pour les clients qui ont accuss des retards pour le payement de leurs factures.
Le scnario de gestion des Bien permet de : Envoi des lettres de relance. Envoi des lettres de mises en demeure. III.b.1.5. Les Diagramme de squences Les diagrammes de squences permettent de dcrire les scenarios de chaque cas dutilisation en mettant laccent sur la chronologie des oprations en interaction avec les objets. Ce type de diagramme insiste sur l'aspect temporel, ils sont formes avec des classes traduisant la dynamique du systme et qui seront utiliss dans lactivit de conception.
III.b.1.5.1. Diagramme de squence du cas dutilisation crer un client
Uti l i sateurSystem Ger l es rel ances cl i ents Envoi des l ettres de rel ance Envoi des l ettres des mi ses en demeure Chapitre III Conception 45
Figure 17: Diagramme de squence du cas dutilisation Crer un client .
III.b.1.5.2. Diagramme de squence du cas dutilisation modifier un client
Cl i ent sauvegarder val i der demande de conformati on cl i ent est crer (fami l l e,categori e)sel cti onner sel ect categori e sel ect fami l l e aj outer un cl i ent Uti l i sateur system Cl i ent Fami l l e Nature sauvegarder val i der demande de conformati on cl i ent est crer (fami l l e,categori e)sel cti onner sel ect categori e sel ect fami l l e aj outer un cl i ent Chapitre III Conception 46
Figure 18 : Diagramme de squence du cas dutilisation Modifier un client.
III.b.1.5.3.Diagramme de squence du cas dutilisation ajouter une commande Modfi er cl i ent val i der demande de confi rmati on sauvegarder modi fi cati on crer (cl i ent,maj )sel ecti onner sel ect modi fi er sel ect cl i ent modi fi er un cl i ent Uti l i sateur System Modi fi cati on Cl i ent MAJ val i der demande de confi rmati on sauvegarder modi fi cati on crer (cl i ent,maj )sel ecti onner sel ect modi fi er sel ect cl i ent modi fi er un cl i ent Chapitre III Conception 47
Figure 19: Diagramme de squence du cas dutilisation ajouter une commande.
III.b.1.5.4. Diagramme de squence du cas dutilisation ajouter un produit: Commande (fami l l e,qte,pri x,tva)sel ecti onner aj outer qte pri x tva cmd sauvegarder val i der demande de conformati on commande est crer sel ect fami l l e aj outer une commande Uti l i sateur system Commande Fami l l e l i gne_cmd (fami l l e,qte,pri x,tva)sel ecti onner aj outer qte pri x tva cmd sauvegarder val i der demande de conformati on commande est crer sel ect fami l l e aj outer une commande Chapitre III Conception 48
Figure 20: Diagramme de squence du cas dutilisation ajouter un produit.
III.b.1.5.5. Diagramme de squence du cas dutilisation modifier un produit Produi t (categori e)sel ecti onner produi t crer val i der l a creati on demande de confi rmati on sel ect categori e aj outer un produi t Uti l i sateur System Produi t Nature (categori e)sel ecti onner produi t crer val i der l a creati on demande de confi rmati on sel ect categori e aj outer un produi t Chapitre III Conception 49
Figure 21: Diagramme de squence du cas dutilisation modifier un produit.
III.b.1.5.6 Diagramme de squence du cas dutilisation crer une facture Modi fi er produi t mi se a produi t produi t sel ecti onner sel ect produi t modi fi er produi t val i der confi rmati on de l a maj sauvegarder l e produi t maj Uti l i sateur System produi t MAJ mi se a produi t produi t sel ecti onner sel ect produi t modi fi er produi t val i der confi rmati on de l a maj sauvegarder l e produi t maj Chapitre III Conception 50
Figure 22: Diagramme de squence du cas dutilisation crer une facture.
III.b.1.5.7 Diagramme de squence du cas dutilisation ajouter un utilisateur Facture (fami l l e,qte,pri x)sel ecti onner aj outer qte pri x facture sauvegarder val i der demande de conformati on facture est crer sel ect fami l l e aj outer une facture Uti l i sateur system Facture Fami l l e l i gne_facture (fami l l e,qte,pri x)sel ecti onner aj outer qte pri x facture sauvegarder val i der demande de conformati on facture est crer sel ect fami l l e aj outer une facture Chapitre III Conception 51
Figure 23: Diagramme de squence du cas dutilisation crer un utilisateur.
III.b.1.6.Diagrammes dactivit pour quelques cas dutilisation
Uti l i sateur (profi l )sel ecti onner uti l i sateur crer val i der l a creati on demande de confi rmati on aj outer profi l aj outer uti l i sateur admi ni strateur uti l i sateur Profi l (profi l )sel ecti onner uti l i sateur crer val i der l a creati on demande de confi rmati on aj outer profi l aj outer uti l i sateur Chapitre III Conception 52
Le diagramme dactivit fait partie des diagrammes dUML utilise pour la modlisation des aspects dynamique des systmes.
Figure 24 : Diagramme dactivit pour le cas dutilisation crer un client
Chapitre III Conception 53
Figure25 : Diagramme dactivit pour le cas dutilisation modifier un client
Chapitre III Conception 54
Figure 26 : Diagramme dactivit pour le cas dutilisation crer une commande Chapitre III Conception 55
Figure 27 : Diagramme dactivit pour le cas dutilisation crer un produit
Figure 28 : Diagramme dactivit pour le cas dutilisation modifier un produit Chapitre III Conception 56
Figure 29 : Diagramme dactivit pour le cas dutilisation crer une facture
III.b.2. Formalisation de la partie statique
III.b.2.1. Prsentation du dictionnaire des donnes Dsignation Dsignation Type Observation Adresse_c Adresse client AN 100 Adresse_s Adresse socit AN 100 Agence Agence A 20 Article_fiscal Article fiscal A 20 Banque Banque AN 20 Capital_social_s Capital social socit AN 20 client_b Client bloqu A 50 Chapitre III Conception 57
code_c Code client AN 50 code_prest Code prestation/bien AN 50 Compte_bancaire Compte bancaire AN 50 Dara Dara A 20 Date_avenant Date avenant DATE JJ/MM//AAAA Date_com Date commande DATE JJ/MM//AAAA Date_contrat Date contrat DATE JJ/MM//AAAA Date_contrat_prest Date contrat prestation DATE JJ/MM//AAAA Date_conv Date convention DATE JJ/MM//AAAA Date_conv_cadre Date convention cadre DATE JJ/MM//AAAA Date_chance Date dchance DATE JJ/MM//AAAA Date_devis Date devis DATE JJ/MM//AAAA Date_fact Date facture DATE JJ/MM//AAAA Date_remise_fact Date remise facture DATE JJ/MM//AAAA Dbut_exct Dbut dexcution DATE JJ/MM//AAAA Dlai_prest Dlai de prestation (en jours) N 100 Dlai_rgle Dlai de rglement N 100 Dlai_livrai Dlai livraison N 100 Dnom_abrge_fr_s Dnomination abrge en franais socit A 50 Dnom_fr_s Dnomination en franais socit A 50 Dure contrat Dure contrat( annes) N 50 Dure_conv Dure convention N 100 Dure_garan Dure de garantie( annes) N 2 Email_c Email client AN 20 Email_s Email socit AN 20 Exonr de TVA Exonr de TVA N 10 Famille_c Famille client A 20 Fax_s Fax socit N 15 Forme_jur_c Forme juridique client A 15 Forme_jur_s Forme juridique socit A 15 Id_fiscal Identifiant fiscal AN 50 Id_stat Identifiant statistique AN 50 Chapitre III Conception 58
Lib_prest Libelle prestation/article AN 50 Lib_prest Libelle prestation/bien AN 50 Lieu ralisation Lieu ralisation A 20 Mod_paie Modalits de paiement A 10 Mod_rgle Mode rglement A 10 Mont_contrat Montant contrat N 20 Mont_fact Montant de la facture N 20 Mont_TVA Montant de la TVA N 20 Mont_HT Montant HT N 20 Mont_pna Montant pnalit N 20 Mont_remise Montant remise N 20 MontTTC Montant TTC N 20 N art_fiscal_c N article fiscal client AN 30 N art_fiscal_s N article fiscal socit AN 30 N avenant N avenant N 30 N com N commande N 50 N contrat N contrat N 50 N Contrat_prest N Contrat prestation N 50 N conv N convention N 50 N conv_cadre N convention cadre N 50 N dem_prest N demande prestation N 50 N devis N devis N 20 N facture N facture N 20 N id_fiscal_c N identifiant fiscal (NIF) client N 20 N id_fiscal_s N identifiant fiscal (NIF) socit N 20 N id_stat_c N identifiant statistique client N 20 N re_commerce_c N registre de commerce client N 20 N reg_commerce_s N registre de commerce socit N 20 N_abrg_c Nom abrg client A 20 N_c Nom client A 20 Obs Observation A 20 Chapitre III Conception 59
Priode_validit Priode de validit (en jours) N 20 Prix unit Prix unitaire N 20 Quant Quantit N 10 Rf_demande_c Rfrence demande client AN 20 Registre de commerce Registre de commerce AN 30 Remise Remise % N 3 Sect_act_c Secteur dactivit client A 20 Sect_act_s Secteur dactivit socit A 20 Site_web_s Site web socit AN 15 TVA Taux TVA N 3 Tel_c Tlphone client N 10 Tel_s Tlphone socit N 10 Total_HT Total HT N 10 Type_prest Type prestation A 10 Unit_mesure Unit de mesure A 20 Valeur Valeur AN 100 Valeur_HT Valeur HT aprs remise N 10 Wilaya Wilaya A 15 Wilaya_c Wilaya client A 15
Tableau 15 : dictionnaire de donnes
III.b.2.2.Prsentation des classes association et methode Attribut Description Type de donne Taille code_ socit Code de socit AN 20 nom_socit Nom de socit A 50 adresse_socit Adresse de socit AN 100 forme_juridique Forme juridique de socit A 20 capitale_social Capital social de socit AN 20 tel_socit Tlphone de socit N 20 fax_socit Fax de socit AN 30 mail_socit Mail de socit AN 20 Siteweb Site web de socit AN 30 Chapitre III Conception 60
code_dr Code de direction AN 20 Nom_dr Nom de direction A 50 adresse_dr Adresse de direction AN 100 tel_dr Tlphone de direction N 20 fax_dr Fax de direction AN 30 mail_dr Mail de direction AN 20 code_unit Code unit AN 20 nom_unit Nom unit A 50 adresse_unit Adresse unit AN 100 tel_unit Tlphone unit N 20 fax_unit Fax unit AN 30 mail_unit Mail unit AN 20 id_client Identifiant client N 1 code_client Code client N 20 nom_client Nom client A 30 adresse_client Adresse client AN 50 tel_client Tlphone client N 20 mail_client Mail client AN 20 raison_sociale Raison sociale client AN 20 article_imposition Article dimposition client AN 20 id_fiscal Identifiant fiscal client AN 30 activite_client Activit client A 15 num_registre_co m Numro registre commerce AN 20 code_prod Code produit AN 20 nom_prod Nom produit A 50 famil_prod Famille produit A 50 qte_prod Quantit produit N 10 prix_prod Prix produit N 100 code_fact Code facture AN 15 code_client Code client N 20 Nom_client Nom client A 30 id_fiscal_client Identifiant fiscale client N 15 adresse_client Adresse client AN 100 code_produit Code produit AN 20 famil_prod Famille produit AN 50 qte_prod Quantit produit N 10 mont_tva Montant TVA N 50 Mont_ttc Montant TTC en lettre AN 50 Chapitre III Conception 61
code_client Code client N 20 nom_client Nom client A 30 nom_cmd Nom commande A 20 id_fiscal Identifiant fiscal client AN 30 adresse_client Adresse client AN 50 code_prod Code produit AN 20 famil_prod Famille produit AN 50 qte_prod Quantit produit N 10 prix_prod Prix produit N 100 qte_cmd Quantit commande N 10 prix_cmd Prix commande N 100 tva_cmd Tva commande N 50 qte_fact Quantit facture N 10 prix_fact Prix facture N 100 date_d Date de dbut unit DATE
Tableau 16 : tableau association et methode
III.b.2.3. Diagramme de classe Le diagramme de classe constitue lun des pivots essentiels de la modlisation avec UML. En effet, ce diagramme permet de donner la reprsentation statique du systme dvelopper. Cette reprsentation est centre sur les concepts de classe et dassociation. Chaque classe se dcrit par les donnes et les traitements dont elle est responsable pour elle-mme et vis--vis des autres classes. les traitements sont matrialiser par des oprations. La description du diagramme de classe est fonde sur : Le concept dobjet, Le concept de classe comprenant les attributs et les oprations, Les diffrents types dassociation entre classe
Chapitre III Conception 62
Figure 30 : Diagramme de classe Globale.
1 1..* 1 1..* 1..* 1 1 1..* 1 1..* 1 1..* 1..* 0..* 1..* 1..* 1..* 1..3 1..* 1 1 1..* 1..* 1..* 1..* 1..* 1 0..* Conventi on-cadre - - pri x_produi t qte_produi t : Stri ng : i nt Contrat-prestati on - - pri x_produi t qte_produi t : Stri ng : i nt Lettre-commande - - pri x_produi t qte_produi t : Stri ng : i nt Bon-commande - - pri x_produi t qte_produi t : Stri ng : i nt Commande - - - - - code_commande date_commande code_cl i ent nom_cl i ent type_cmd : i nt : Date : Stri ng : Stri ng : Stri ng Cl i ent - - - - - - - - - code_cl i ent nom_cl i ent adresse_cl i ent fami l l e_cl i ent tel num_regi stre_commerce scteur_acti vi te emai l i d_f : Stri ng : Stri ng : Stri ng : Stri ng : i nt : Stri ng : Stri ng : Stri ng : Stri ng Soci et - - - - - - - - - - code_soci ete nom_soci ete adresse tel ephone si te_web i d_f secteur_acti vi te capi tal _soci al fax num_regi stre_commerce : Stri ng : Stri ng : Stri ng : i nt : Stri ng : Stri ng : Stri ng : Stri ng : Stri ng : Stri ng Di recti on-regi onal - - - - - - - - code_dr nom_dr adresse tel si te_web secteur_acti vi te capi tal _soci al fax : Stri ng : Stri ng : Stri ng : i nt : Stri ng : Stri ng : Stri ng : Stri ng Uni te - - - - - - - - code_uni te nom_uni te adresse tel si te_web secteur_acti vi te capi tal _soci al fax : Stri ng : Stri ng : Stri ng : i nt : Stri ng : Stri ng : Stri ng : Stri ng Produi t - - - - - - - - code_produi t nom_produi t type_produi t quanti t pri x_uni tai re val eur_ht montant_tva montant_ttc : i nt : i nt : Stri ng : i nt : i nt : i nt : i nt : i nt Facture - - - - - - - - - code_facture date_facture code_cl i ent nom_cl i ent num_cp date_cp num_commande date_commande code_produi t : Stri ng : Date : Stri ng : Stri ng : i nt : Date : i nt : Date : i nt Facture-proformat - - pri x_uni tai re uni te_mesure : Stri ng : Stri ng Facture-cl i ent - - pri x_uni tai re uni te_mesure : Stri ng : Stri ng Payement - - code_payem nature_payem : i nt : Stri ng Mode-regl ement - - code_regl ement dsi gnati on : Stri ng : Stri ng Rel ance-cl i ent - - - num_facture date_rel ance type_rel ance : i nt : Date : Stri ng Avenant - - - - - num_avenant date_avenant obj et_avenant num_contrat date_contrat : Stri ng : Date : Stri ng : i nt : Date Li gne-comma nde - - - Pri x Qte TVA : i nt : i nt : i nt Li gne-facture - - pri x Qte : i nt : i nt Fami l l e-cl i ent - - code_fami l l e dsi gnati on : Stri ng : Stri ng Date - - date_debut date_fi n : Date : Date Chapitre III Conception 63
Conclusion
Ce chapitre a trait la conception du systme Systme dinformation pour la gestion commerciale . Conformment la mthode standard de conduite de projet informatique, ce chapitre a t divis en trois phases principales : Diagnostique, Recherche des solutions et Formalisation des solutions. Chacun son tour, ces modles ont apport une prcision supplmentaire en considrant le systme selon diffrentes approches : fonctionnelle, statique ou encore dynamique, pour aboutir la fin une architecture globale du futur systme. Cette phase de conception est incontournable pour envisager la ralisation dun systme informatique. Les diagrammes qui y sont faits permettent daider la rflexion et dinstaurer la discussion entre les clients et les dveloppeurs.
Chapitre IV Ralisation
63
Chapitre IV : REALISATION
Chapitre IV Ralisation
64
Aprs avoir prsent dans le chapitre prcdant les diffrentes tapes de la phase conception, nous allons prsenter dans ce dernier chapitre la phase ralisation qui se devise en deux tapes : Prparation Excution
I. Prparation Cette tape est une rflexion sur le choix des techniques et outils technologique et logiciels utiliss pour dvelopper la solution. Approche Gnie Logiciel I.A. Mthode de Gestion de Projet SCRUM I.A.1. Qu'est-ce que Scrum ? "Scrum est une mthode agileddie la gestion de projets. Son objectif est d'amliorer la productivit des quipes auparavant ralenties par des mthodologies plus lourdes." [wikipedia] Le principe de base de Scrum est de focaliser l'quipe de faon itrative sur un ensemble de fonctionnalits raliser, dans des itrations de dure fixe de une quatre semaines, appeles "Sprints". Chaque sprint possde un but atteindre, dfini par le directeur de produit (appell aussi le product owner), partir duquel sont choisies les fonctionnalits implmenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de rduire au maximum les perturbations extrieures et de rsoudre les problmes non techniques de l'quipe.
Chapitre IV Ralisation
65
I.A.2. Scrum, vue d'ensemble
Figure31 : Vue d'ensemble de Scrum
La figure ci-dessus nous donne une vue globale de processus de dveloppement avec la mthode agile Scrum. Les diffrents points prendre en compte sont:
I.A.3. Les rles dans Scrum En Scrum, comme reprsenter dans la figure 5.1, on distingue plusieurs rles et pour chacun, des responsabilits et des tches accomplir: I.A.3.1.Le Product Owner Il sagit de la personne reprsentant le client. Le Product Owner : Reprsente toutes les personnes qui ont un intrt dans le logiciel qui sera produit. Finance le projet. Est responsable de ltablissement des besoins initiaux du projet qui sont lists dans le backlog produit. A des objectifs de retour sur investissement. Dcide des releases, c'est dire des versions qui seront mises disposition des utilisateurs. Chapitre IV Ralisation
66
Est responsable de la mise jour du backlog produit. Il doit notamment classer rgulirement les besoins exprims dans le backlog produit pour s'assurer que les fonctionnalits qui gnreront le plus de valeur pour le logiciel seront implmentes en priorit. Il doit galement mettre jour les besoins en fonction des incrments de logiciel qu'il teste chaque fin de sprint. I.A.3.2. Le scrummaster: Ce rle semble simple mais il est en ralit dlicat apprhender car il diffre normment de la culture projet traditionnelle. Le scrummaster n'est pas un chef de projet. Il n'a aucune autorit hirarchique sur l'quipe. Il sagit plus dun rle de coach, et de facilitateur. Un catalyseur de projet en quelque sorte. Son rle est de : Isoler l'quipe des perturbations extrieures en cours de sprint. Apprendre la mthodologie Scrum l'quipe. S'assurer que l'quipe respecte bien la mthode : que chacun fait bien du Scrum et ne dvie pas vers d'anciennes mthodes connues et matrises. Rpondre aux besoins de l'quipe. Faire cadrer scrum dans la culture d'entreprise. Travailler avec le product owner pour slectionner avec lui les besoins apportant le plus de valeur ajoute au logiciel. Il est responsable de la russite du projet, au mme titre que l'quipe. I.A.3.3.L'quipe Les responsabilits et le pouvoir de dcision sont transfrs du chef de projet (dans les organisations traditionnelles) vers l'quipe. Ainsi l'quipe : Dveloppe les fonctionnalits : elle transforme les besoins en incrments fonctionnels de logiciel. Est autogre et auto organise : c'est elle de dcider comment arriver au mieux produire le logiciel partir des besoins exprims par le product owner. Est multidisciplinaire. Si les spcialits persistent, elles sont toutes prsentes au sein de l'quipe. Les mthodes d'estimation supposent que les personnes ne sont pas Chapitre IV Ralisation
67
spcialises et que chacun est capable de remplir toutes les tches du backlog de sprint. Est responsable collectivement du succs de chaque itration. Toutes les cartes sont entre ses mains pour russir. I.A.3. Le Backlog produit Le backlog produit est un des lments principaux de Scrum. Il s'agit d'un catalogue qui recense toutes les fonctionnalits souhaites sur le projet. Il est cr par le product owner. Les entres sont dcrites dans les termes du client, c'est--dire en termes mtier. Le product owner priorise le backlog en fonction des lments qui reprsentent le plus de valeur pour lui en assignant un chiffre qui reprsente l'importance de chaque lment. Plus le chiffre est lev, plus le besoin est important ses yeux et doit tre dvelopp en priorit par lquipe. Le Backlog produit n'est pas un document fig, il est toujours vivant. Le product owner a la possibilit de changer ce backlog a tout moment : ajouter ou enlever des lments, changer les priorits, modifier les descriptions...
Tableau 17 : Le tableau de Backlog Produit Chapitre IV Ralisation
68
I.A.4. Le sprint: Un sprint est un dlai fixe durant lequel le logiciel est dvelopp par l'quipe. Scrum ne recommande pas de dure de sprint prcise. La dure est de 2 semaines 4 semaines . Cest lquipe de choisir une dure qui lui convient. Une fois qu'une dure est choisie, il est ncessaire que cette dure devienne le dlai standard de tous les sprints. Comme le reprsente la figure 7.1, le sprint comporte plusieurs phases : La runion de planification du sprint: Se fait au dbut de chaque sprint, pour fixer et planifier les objectifs de ce sprint. se poursuit par le sprint en soi: Pendant lequel se fait les dveloppements et les tests avec une runion quotidienne qui ne dpasse pas les 15 minutes. Pendant ce temps, Le product owner peut faire voluer son backlog de produit. En fin de sprint ont lieu la revue de sprint pendant laquelle l'quipe prsente le logiciel produit et enfin la rtrospective du sprint pour essayer d'amliorer le processus de dveloppement. I.B. Choix des outils technologiques On tait oblig de respecter les choix technologique adopts dj par ELIT. Ainsi les outils et les mthodes utiliss I.B.1.Description des serveurs I.B.1.1 Serveur de base de donnes Le serveur de la base de donnes utilis dans notre projet est PostgreSQL 9.0. Ce dernier est un systme de gestion de bases de donnes Objet-Relationnel (SGBDRO). Il est disponible pour de nombreuses plateformes, dont Linux, FreeBSD, Solaris, Windows et Mac OS X. Cest un logiciel gratuit et open source. PostgreSQL est considr comme le SGBD non commercial le plus avanc. I.B.1.2 Serveur dApplication: Le serveur dapplication que nous avons utilis est le Glassfish 3.1 qui est le successeur de la version 3.0.X, offrant un runtime modulaire. Lui aussi, est un outil open source. La figure suivante illustre la composition dun serveur dapplication. Chapitre IV Ralisation
69
Figure32 : le serveur java EE GlassFish I.B.2.JEE6
Il est souvent vrai que lorsque lon crit et que lon compile un programme pour un type de systme il ne s'excutera pas sur n'importe quel autre systme car la spcification des services fournis par le systme d'exploitation amne un problme de compatibilit. En effet, la plupart des programmes ne sont pas portables, et cela provoque des problmes pour les utilisateurs multiplateformes. JAVA est un langage de programmation multiplateforme grce la machine virtuelle JAVA (JVM) qui permet de contourner cette limitation. Ainsi les logiciels crits dans ce langage seront trs facilement portables sur nimporte quelle machine indpendamment du systme dexploitation. Cest un langage orient objet avec une riche bibliothque de classes traitant la gestion des interfaces graphiques, exceptions, etc. En outre, JAVA simplifie laccs aux BDD implmentes dans diffrents SGBD. A la fin des annes 1990, est apparu Java Enterprise Edition (JEE, Java EE). Cest un ensemble de spcifications destines aux applications dentreprise. JEE peut tre vu comme une extension du langage Java afin de faciliter la cration dapplications rparties, robustes, performantes et haute disponibilit. Avec des partenaires industriels comme IBM, Sun Microsystems a conu JEE. Cette technologie permet de crer des composants modulaires standardiss et facilement rutilisables, mais aussi de grer de nombreux aspects de la programmation automatiquement. L'avantage tir dune application conue avec JEE est de pouvoir cacher au client l'implmentation du code ct serveur. On peut avoir deux types de clients dans ce cas : Chapitre IV Ralisation
70
Client lger, client Web ou encore thin client : Ce client est entirement gr par un serveur. Il est accessible en utilisant une interface web o la totalit de la logique mtier est traite du ct serveur. Le client lourd ou heavy client : Contrairement au client lger, il ne dpend du serveur que pour l'change des donnes dont il prend gnralement en charge l'intgralit du traitement. La technologie JEE occupe une place de plus en plus importante. Sa portabilit, sa scurit et ses nombreuses API (Application Programming Interface) sont les lments principaux l'origine de son succs. Les infrastructures web ont d s'adapter cette nouvelle technologie et de nouveaux serveurs ont d tre mis en place. Limplmentation de cette spcification contient un ensemble dextensions au Framework Java standard (JSE, Java Standard Edition) [LAFOSSE, 2009]. Notre objectif tant de proposer une application web performante tout en minimisant la maintenance logicielle et permettre aux utilisateurs de profiter pleinement des avantages de lapplication accessible depuis un client lger, nous avons choisi dutiliser le JEE. Nimporte quelle application JEE suit larchitecture prsente dans la figure suivante :
Figure 33: Architecture dune application JEE
Chapitre IV Ralisation
71
I.B.3.NetBeans IDE 7.4
Un langage de programmation ncessite forcment un environnement dans lequel on va dvelopper lapplication. Un IDE est un environnement de dveloppement intgr. Il permet aux dveloppeurs de crer rapidement des applications Web, de bureau et des applications mobiles et cela en utilisant la plateforme Java, ou encore PHP, JavaScript et Ajax, Groovy et Grails, et C et C ++. Pour notre application, nous avons utilis l'IDE NetBeans qui est un environnement prim de Dveloppement intgr. Il disponible pour diverses plateformes.
Figure34 : netbeans 7.4 I.B.4. Frameworks de dveloppement Un framework est un ensemble cohrent de classes et dinterfaces collaborant pour fournir des services la partie centrale dun sous-systme logique. Il contient principalement des classes abstraites que lutilisateur devra spcialiser pour ses besoins fonctionnels propres, ainsi que des interfaces auxquelles il lui faudra se conformer.
I.B.4.1.Entreprise Java Bean : EJB 3.1
Enterprise Java Bean (EJB) est la vritable particularit du dveloppement JEE. Il reprsente larchitecture de composants logiciels ct serveur et une brique matresse de la plateforme de dveloppement JEE. Chapitre IV Ralisation
72
La spcification des EJB dtaille ce que le serveur applicatif fournit et propose un cadre pour crer des composants dploys sur des serveurs distants crit en langage de programmation Java et hbergs au sein d'un serveur applicatif permettant de reprsenter des donnes (EJB dit entit), de proposer des services avec ou sans conservation d'tats entre les appels (EJB dit session), ou encore d'accomplir des tches de manire asynchrone (EJB dit message). Les EJB permettent aux dveloppeurs dviter de se proccuper de tout ce qui a trait au systme (transactions, scurit, persistance, etc.). Pour tre dploys, les EJB ont besoin dun conteneur qui est souvent intgr dans les serveurs dapplications tel quil a t reprsent prcdemment.
I.B.4.2.Java Persistance API : JPA
I.B.4.2.1 Dfinition Java Persistance API est lAPI standard utilise pour la gestion des donnes persistantes et le Mapping Objet/Relationnel. Cette API fait partie de la spcification EJB3 qui permet de faire de la persistance de donnes. Chaque serveur dapplication compatible avec JEE supporte le JPA. Bien quelle soit couramment utilise dans le contexte dun serveur dapplication, JPA peut sintgrer a toutes les applications JAVA. JPA cest un gage de qualit recommand par la communaut Java EE mais qui nest pas vritablement loutil de persistance en lui-mme. En effet, JPA repose sur des annotations Java et des techniques mettre en place, mais laisse au dveloppeur Java le choix de son outil dimplmentation de persistance. Ainsi, les classes et fichiers de configuration seront crits avec JPA et les persistances seront ralises par un outil ddi sous forme de paquetages, comme EclipseLink ou Hibernate.
I.B.4.2.2 les principaux services de lAPI JPA se sont Le mcanisme dORM permettant le mapping des donnes objet vers relationnel et vice versa Un gestionnaire appel Entity Manager pour la gestion des oprations comme le pattern DAO et les oprations CRUD (Create : la cration, Read : la lecture, Update : la mise jour et Delete : la suppression). Un langage de manipulation des donnes appel Java Persistence Query Language (JPQL) permettant de manipuler les donnes avec un langage orient objet. Chapitre IV Ralisation
73
Un systme de transaction volu permettant des accs concurrentiels par lintermdiaire de lAPI Java Transaction API (JTA). Les programmes Java SE avec des ressources locales sont galement supports. I.B.4.2.3 certaines rgles qui doivent tre respect pour assurer la transformation des objets en entits et ainsi devenir persistants Lobjet doit pouvoir tre persistant. Plus clairement, son tat doit pouvoir tre reprsent par des donnes dans une base de donnes. Par exemple, les donnes de type image, vido ou flux multimdia sont difficilement reprsentes pour la persistance. Les objets Java doivent possder une identit ou cl unique (primaire) permettant de rfrencer de manire unique chaque instance. Ce concept est nouveau en objet car lObject Identifier (OID) utilis de faon implicite doit ltre dsormais de manire explicite en tant dclar dans la classe. Les objets doivent tre transactionnels, cest dire pouvoir tre crs, modifis et supprims. Les entits doivent ainsi respecter les contraintes de la JVM pour la persistance. Le principe dun Object Relationnal Mapping est de dlguer un outil tiers la tche de correspondance entre les objets et tables. Le mapping permet alors de dvelopper des classes sous forme dentits et dutiliser par transparence des bases de donnes relationnelles. Typiquement, une entit reprsente une table dans une base de donnes relationnelle et chaque instance dentit correspond une ligne de la table.
I.B.4.3. Java Server Faces : JSF 2 JSF est ax sur la demande web MVC base sur le composant modle, plus prcisment sur la conception d'interface utilisateur en utilisant des fichiers XML appels modles ou vues Facelets. Les demandes sont traites par le Faces Servlet, qui charge le modle de vue appropri, construit un arbre de composants et rend la rponse (gnralement HTML) au client. Ltat des composants dinterface utilisateur est enregistr la fin de chaque requte, appel stateSaving, et est restaur lors de la prochaine cration de cet avis.
Chapitre IV Ralisation
74
I.B.5. Architecture applicative
JEE est une plateforme multi-niveaux. Chaque niveau reprsente un partitionnement logique ou fonctionnel du systme. Les applications 3tiers sont composes de 3 niveaux : la logique d'affichage, la logique mtier et la logique de bases de donnes. La figure suivante reprsente larchitecture 3tiers de notre application :
Figure 35 : Architecture de SI GTR selon le design pattern MVC
La couche Affichage est constitue dun ensemble de composants JSF. Les EJB session permettent lchange des donnes entre la couche Affichage et la couche Mtier, la validation des donnes et la gestion des transactions et des sessions des utilisateurs. Les EJB entits reprsentent le modle des donnes qui seront persists dans la BDD grce lAPI JPA.
II. Excution Dans la partie, nous allons prsenter : Lapplication de la mthode SCRUM Description de larchitecture de lapplication
Chapitre IV Ralisation
75
II.a. Application de la mthode SCRUM Scnario ou story Priorit et estimation d la dure Niveau utilisateur (cas dutilisation) Niveau dtaill En tant que utilisateur du systme je veux la gestion des clients et consulter la liste des clients Priorit : A
Dure estim : 2 semaines Raliser une interface gestion des clients -Construire le formulaire de lajout dun client Et indiquer les champs obligatoires
-Construire et programm les boutons consulter modifier et supprimer un client (ce qui nous permet la gestion des clients) Lister les clients dans un tableau -construire les champs de recherche dun client selon son code ou bien son nom
En tant que utilisateur du systme je veux la gestion des produits/prestation et consulter les fiches produits/prestation Priorit : A
Dure estim : 2 semaines Raliser une interface gestion des Produits/prestations Construire le formulaire de lajout dun produit/prestation Et indiquer les champs obligatoires
-Construire et programm les boutons afficher informations, modifier et supprimer un Produit/prestation (ce qui nous permet la gestion des Produits/prestations) Chapitre IV Ralisation
76
Lister les produits/Prestation construire les champs de recherche dun produit/Prestation selon son code, nom bien sa dsignation
En tant que utilisateur du systme je veux la gestion des Socits, Directions, Units Priorit : B
Dure estim : 1 semaine -Raliser une interface gestion des Socits (Priorit B1) -Raliser une interface gestion des Directions (Priorit B2) -Raliser une interface gestion des Units (Priorit B3) Construire le formulaire de lajout dune (socit, direction, Unit) Et indiquer les champs obligatoires
-Construire et programm les boutons afficher informations, modifier et supprimer une (socit, direction, Unit) ce qui nous permet la gestion des (socits, directions, Units)
En tant que utilisateur du systme je veux ajouter une nouvelle commande et consulter la liste des commandes mises Priorit : C
Dure estim : 1 semaine -Enregistrement dune nouvelle commande Construire le formulaire de lajout dune nouvelle commande Et indiquer les champs obligatoires
-Edition de la commande -imprimer la commande -Lister les commandes construire les champs de recherche dune commande selon son code ou bien la date
En tant que utilisateur du systme je veux ajouter une nouvelle commande consulter et imprimer la liste des factures
Priorit : c
Dure estim : 1 semaine -Enregistrement dune nouvelle Facture
Construire le formulaire de lajout dune nouvelle Facture Et indiquer les champs obligatoires
Chapitre IV Ralisation
77
-Edition de la commande
-imprimer la Facture
-Lister les factures construire les champs de recherche dune Facture selon son code ou bien la date
En tant quadministrateur, je dois pouvoir Supprimer, ajouter et modifier un usager du systme
Priorit : D
Dure estim : 2 jours Raliser une interface gestion des administrateurs -Construire le formulaire de lajout dun Administrateur
-Construire et programm les boutons ajouter, modifier et supprimer un administrateur (ce qui nous permet la gestion des administrateurs) -Lister les administrateurs construire les champs de recherche dun administrateur selon son nom, son code ou bien sa fonction
Tableau 18: application de la mthode SCRUM.
II.b. Description de larchitecture de lapplication
Dans cette partie nous allons prsenter les fonctionnalits de lapplication travers ses diffrentes interfaces
II.b.1. les diffrents espaces a) espace Utilisateur C'est l'espace ddi aux utilisateurs du systme (les agents commercial)
b) espace Administrateur Cest lespace rserv ladministrateur du systme qui gre les comptes des utilisateurs
Chapitre IV Ralisation
78
II.b.2 prsentation des fonctionnalits de lapplication
Avant de pouvoir accder lapplication, lutilisateur doit dabord sauthentifier en utilisant les paramtres de connexion qui lui ont t donns (login, mot de passe).
Figure36 : Interface dauthentification.
Suite lauthentification, lutilisateur est dirig vers la page daccueil qui comprend tous les diffrentes fonctionnalits auxquels il a le droit daccder.
Figure37 : Interface Ecran daccueil des modules
Chapitre IV Ralisation
79
II.b.2.1. Commande et Facturation
Figure38 : Interface module commande facturation
La fonction Commande et Facturation reforme un ensemble de sous-fonction
II.b.2.2.Enregistrer les donnes de bases Nous proposons lutilisateur la gestion de plusieurs donnes de base relative la gestion commercial de SONELGAZ. La figure suivante apparait lorsque lutilisateur slectionne la fonction Enregistre de donnes de bases
Figure39 : Interface Enregistrement de donnes de bases
Chapitre IV Ralisation
80
a- Interface Gestion clients
Figure40 : Interface Ecran Gestion des clients
b. Interface Ajout dun nouveau client
Figure41 : Interface Ecran ajout dun nouveau client.
Chapitre IV Ralisation
81
c. Afficher dtails client
Figure42 : Afficher dtails client.
d. Modification des informations client
Figure43 : Modification des informations client.
Chapitre IV Ralisation
82
II.b.2.2.commande
le module Commande est compos de la fonction commande client
Figure44 : Interface module commande
II.b.2.3. Facture
Figure45 : Interface module Facture
Chapitre IV Ralisation
83
II.b.2.4. Edition de la facture
Figure46 : Edition de la facture
Conclusion
En dpit de certains problmes rencontrs durant cette phase de ralisation, nous pouvons dire que nous avons pu raliser la plus grande partie du travail qui nous a t confi. A travers cette phase de ralisation, nous avons pu nous familiariser avec de nouvelles techniques de programmation et la plateforme JEE. Conclusion Gnrale
Conclusion Gnrale
Conclusion Gnrale
Ce projet tait bnfique pour nous dans plusieurs sens. Il nous a permis : de nous perfectionner en amliorant nos connaissances en programmation et en conception. De bien comprendre et mettre en uvre le droulement d'un cycle de vie d'un logiciel. De dcouvrir le monde de l'entreprise (fonctionnement). Nous avons essay de raliser ce projet pour le but de faciliter l'entreprise en question, d'amliorer la gestion et le suivi de ses clients. On a appliqu au maximum possible les rgles de bases permettant d'avoir une application performante. Nous avons appliqu UML pour concevoir une grande partie de notre travail. Nous avons utilis aussi Java et Java/EE pour implmenter notre application. Grce aux architectures que nous avons utilis (MVC et client/serveur) et du fait que Java/EE est un langage adaptable dans plusieurs domaines, notre application peut avoir des extensions ou des modifications dans le futur. Citons quelques-unes : On peut lier cette application un site web dynamique qui nous permettra le suivi des clients et des fournisseurs en ligne. Implmenter la gestion des stocks et des ventes
[Y.PRIE, 2005] : Yannick PRIE ; Introduction la conception de systmes d'information, CoursM1- MIAGE , Universit Claude Bernard Lyon 1 : UFR Informatique, Lyon, 2005/2006.
[P.ROQUES, 2007] : Pascal ROQUES ; Les cahiers du programmeurs UML 2 : Modliser une application web , Editiond EYROLLES, 2007. [ROQ, 04] : Pascal ROQUES ; UML 2 en action, de lanalyse des besoins la conception J2EE , 1re dition,2004.
[J.BARZIC, 2008] : Jacques BARZIC ; Les 13 diagrammes UML 2 , ebook 2008.
[P.ROQUES, 2002] : Pascal ROQUES et CHALMON ; collaboration de Martine, Les cahiers du programmeur UML : Modliser un site e-commerce , Edition Eyrolles, 2002.
Rsum :
Il est indispensable pour lentreprise, davoir une connaissance parfaite de la situation commerciale afin dviter toute situation litigieuse avec ses partenaires. Le Groupe SONELGAZ, premier oprateur nergtique en Algrie, nchappe pas cette rgle. Il a dcid de revoir sa politique financire en adaptant ses systmes dinformation, notamment dans le domaine de la gestion Commerciale par le dveloppement par moyens propres dun nouveau Systme dInformation SIGC . De plus, lentreprise a prvu un ensemble de fonctionnalits concernant sa gestion commerciale qui ne seront pas intgres avec le SIGC, dans un premier temps. Ceci donnera une visibilit sur les fonds de lentreprise, une meilleure gestion commerciale. Notre travail consistait en le dveloppement de cette premire version du systme. Lobjectif premier de notre tude tant de mettre la disposition du Groupe, un systme fiable qui lui permette davoir une vue sur ses fonds, de grer ses flux de commercialisation et de pouvoir contrler les oprations vents. Pour ce faire nous avons dvelopp une application web trois tiers sur la plateforme de dveloppement JEE6 avec le SGBDRO PostgrSQL.