dKP9c6 1378

Bujumbura, Juillet 2010
Travail prsent et dfendu publiquement en vue de lobtention du diplme de licence en Informatique de Gestion.
AUTOMATISME DE FACTURATION, DE GESTION DE TRESORERIE ET DE GESTION DE STOCKS (CAS DU RESTAURANT BELVEDERE)
REPUBLIQUE DU BURUNDI UNIVERSITE LUMIERE DE BUJUMBURA
Facult dInformatique de Gestion
Travail prsent par :
AKSANTI MIRINDI Marcellin et MURISHI Booz
Sous la direction de :
Ir. Hamim HAMISI
Ddicaces et Remerciements
DEDICACES ET REMERCIEMENTS
Que nos ddicaces et nos vifs remerciements retournent tout dabord Dieu tout puissant, ensuite : MURISHI Booz : mes trs chers parents MURISHI Isaac et MASAWA Jeannette ; la famille de mon oncle GASORE David ;
AKSANTI MIRINDI Marcellin : mes trs chers parents MIRINDI Evariste et MASTAKI Alexandrine ; Mr. labb MWEZE Faustin; enfin, notre directeur Ir. HAMISI Hammim, Mr. BUKERA Do, Frre Emmanuel tous mes frres et surs, tous mes amis et tous ceux qui auraient contribus la russite de ce travail.
Chapitre 0. Introduction
Chapitre 0. INTRODUCTION
Aux carillons des cloches dglise martelant les heures, aux tic-tacs de la montre, se substituent aujourdhui les nanosecondes silencieuses des Nouvelles Technologies de lInformation et de la Communication (NTIC). Autrefois rgulateur du travail de lhomme, le temps devient laube du XXIme sicle cette instance insaisissable qui le presse, le stresse et lobsde. Le temps, dans une socit o prnent les NTIC, se compte, se dcompte et rgule la plupart des activits de lhomme au travail. Lordinateur accule lindividu au zro dlai; les nouvelles formes de communication crent une demande de limmdiat; le temps qui file devient un facteur de management; les technologies fragmentent le temps obligeant lhomme aux exercices mentaux du zapping et de la commutation. La premire machine arithmtique calculer (invente par Blaise Pascal 1642) vient de subir des mtamorphoses spectaculaires, caractrises plus particulirement par lavnement de lordinateur, grce auquel il est dsormais possible dexcuter en un rien de temps, de lourdes tches jadis difficiles, si pas impossibles raliser. Remarquons surtout la manire dont cet outil permet de fiabiliser les rsultats en les librant des facteurs tels que la fatigue, le stress, lincomptence, la subjectivit et toutes leurs implications dont nul nignore jusquici les consquences : loubli, la lenteur, etc. Ces consquences peuvent entraner des erreurs, souvent involontaires certes mais parfois graves ! Il ne fait donc plus aucun doute que lordinateur et l'informatique sont la rvolution la plus importante et la plus innovante qui a marqu la vie de l'humanit moderne. En effet, les logiciels informatiques proposent maintenant des solutions un nombre toujours croissant de problmes de la vie, aussi bien dans des domaines professionnels que pour des applications personnelles. Et leurs mthodes de conception et de dveloppement ont vu l'avnement d'autant de technologies qui facilitent leur mise en place et leur donnent des fonctionnalits et des possibilits de plus en plus tendues.
Chapitre 0. Introduction
Un restaurant reprsente une des organisations ayant des ressources et des activits dont la gestion ncessite une application informatique. Ainsi, l'objectif de notre projet est de raliser une application informatique interactive, fiable, conviviale et facile intgrer dans l'environnement de travail du restaurant, assurant la gestion des systmes d'informations compte tenu des besoins exprims. Cette application vise essentiellement diminuer la complexit des traitements lie la facturation et la gestion des stocks. Nous avons eu le besoin de visiter le restaurant BELVEDERE, situ Kiriri et, par le biais de la grante, avons eu le privilge dobtenir toutes les informations ncessaires et suffisantes la ralisation de notre application. Dans le prsent travail, nous allons prendre le soin de prsenter en dtail toutes les tapes que nous avons suivies pour raliser notre application. Celuici comporte quatre chapitres organiss de la manire suivante: Dans le premier chapitre, Etude prliminaire , nous prsenterons ltablissement (le restaurant BELVEDERE) qui nous a servi de maison pilote : les dirigeants, la structure, le mode de travail. Nous nous intresserons ensuite une tude de faisabilit dun projet dinformatisation ralise pour cet tablissement. Le second chapitre, Diagnostic de lexistant , traitera des forces ou des faiblesses du processus existant et du systme dinformation qui le soutient, les causes de ces problmes, ainsi que les objectifs que devrait atteindre le processus transform. Le troisime chapitre, Modlisation et conception du nouveau systme dinformation , dcrira toutes les tapes de conception qui nous ont permis de raliser notre application que nous allons appeler Contr'Ol.sys partir du processus de spcification des besoins jusqu llaboration des diagrammes. Dans le quatrime et dernier chapitre, Ralisation, implmentation et test , nous dcrirons la phase finale de ralisation de Contr'Ol.sys : la codification, larchitecture, le fonctionnement, le test et lenvironnement de travail.
Chapitre I : Etude prliminaire
Chapitre I. ETUDE PRELIMINAIRE

I. 1. Restaurant BELVEDERE
I.1.1 Prsentation Comme le nom lindique, le restaurant BELVEDERE uvre dans le domaine de la restauration cela depuis 2001, anne de son ouverture et de son implantation au quartier Kiriri Bujumbura. Il engage plus de 50 employs permanents et prs de 10 non permanents (pour le service traiteur).Il propose plus de 400 articles (mets et boissons confondus) regroups en trois services : le restaurant, le bar et le traiteur. I.1.2 Organigramme
Directeur Gnral
Directeur Financier
Grant
Chef de cuisine
Matre dhtel
Aide
Aide
Serveur
Serveur
Figure I.1.2-1 : Organigramme du Restaurant BELVEDERE
I.1.3 Services La maison offre 3 services comme nous lavons soulign prcdemment : le restaurant, le bar et le traiteur (qui consiste dlocaliser les deux premiers services chez des clients qui le souhaitent). Ils sont tous aliments par un mme stock approvisionn intervalle rgulier (tous les dbuts de la semaine) et les prix sont fixs la suite de la concertation entre DG, la grante et ventuellement, le chef cuisinier. Le restaurant peut accueillir jusqu 200 personnes, offrir une centaine de recettes diffrentes, spcialement europennes, et dispose dune vinothque avec une dizaine de catgories de vins. Le bar, quant lui, peut offrir plus de 200 boissons, la vinothque incluse. I.1.4 Missions et objectifs Les dirigeants du restaurant BELVEDERE se sont fix les missions et les objectifs suivants : Assurer un cadre confortable de divertissement et de loisir ; Sinscrire dans la logique de la promotion du tourisme et lutter contre le chmage au Burundi et ; Offrir une cuisine aux spcialits europennes. I.1.5 De linformatique Peu de temps seulement aprs sa cration, le restaurant sest dot dun ordinateur pour le traitement de quelques documents sur Word (bons de commandes, quelques factures,), pour quelques oprations de contrle sur tableur Excel et pour le traitement des courriers lectroniques. Le restaurant dispose aussi dun site web sur lequel sont publis tous les services disponibles et les informations importantes. Linformatique nest donc pas une technologie assez nouvelle au sein du restaurant BELVEDERE, cependant prs de 70% de linformation reste toujours traite manuellement.
I. 2 Mthodologie de ltude prliminaire

Les donnes pour mener ltude prliminaire ont t recueillies lors dentrevues avec les dirigeants du restaurant BELVEDERE et avec certains employs impliqus dans les activits lies au processus daffaires et au systme dinformation. Lobservation des activits et la consultation de la documentation interne ont complt cette information.
I. 3 Frontire du processus daffaire, et du systme dinformation

Quelques dfinitions1 : Un processus est un ensemble dactivits qui saisissent un input, le transforment et fournissent un output un client (interne ou externe). Les processus utilisent les ressources organisationnelles dans la transformation quils effectuent. Un processus de production en est un qui vient en contact physique avec le produit ou le service qui sera ultimement livr au client externe, excluant la livraison et la distribution (par exemple, la fabrication des mdicaments, la mise en conserve daliment, la fabrication dordinateurs, les soins donnes un patient). Un processus daffaires est un ensemble dactivits qui soutiennent les processus de production (par exemple, la prise de commande, la paye, le contrle de la qualit). Un systme dinformation est un ensemble dactivits qui saisissent, stockent, transforment, et diffusent des donnes sous un ensemble de contraintes appel lenvironnement du systme. Du point de vue thorique, dterminer la frontire est une tche qui se dcrit simplement : il sagit de distinguer ce qui fait partie du processus ltude de ce qui nen fait pas partie. Il sagit donc de dterminer des inputs et leurs sources - les fournisseurs du processus - les outputs et leurs destinations - les clients du processus - les activits qui composent le processus ainsi que les processus qui interagissent avec le processus ltude sans omettre les activits exclues du processus.
Suzanne RIVARD et Jean TALBOT, Le Dveloppement de Systmes dInformation, 3 Ed., Presse de lUniversit de Qubec, P. 20, 2003.
La figure et les tableaux suivants dcrivent la frontire du processus de gestion de commandes et de facturation et, de gestion des stocks, la liste des vnements ainsi que les dterminants de cette frontire :
Processus de gestion de commandes et de facturation et de gestion des stocks
Commande Paiement
Facture
Personnes effectuant les tches

Service
Client
Requte sur commande
Grante, Caissires, Serveurs, Responsables des stocks
Client
Info sur crdits
Respo Stocks
Rapports sur ventes et approvisionnement
Services impliqus
Ventes, Stocks, Service des contrles
Inventaires
Direction
Figure I.3 : Frontire du processus Liste des vnements Un client passe une commande dun ou de plusieurs produits ; La caisse labore une facture ; Un client effectue un paiement et la caisse lenregistre ; La caisse produit quotidiennement ltat de la trsorerie ; Les responsables des stocks produisent quotidiennement les rapports sur les mouvements des stocks ; 6. La grante produit quotidiennement et mensuellement des inventaires. 1. 2. 3. 4. 5.
Tableau I.3-1 : Liste des vnements
Tableau 1.3 : Dterminants de la frontire du processus Composante Inputs Description : Commande, paiement, requte sur commande, rapports sur ventes/approvisionnement. : Clients, responsables des stocks. : Facture, service, inventaires, informations sur les crdits. : Transcription de commande, saisie de la commande, offre de service, prparation des paiements, mission des factures, mission des rapports surs les ventes/approvisionnement, production des inventaires. : Client, direction : Vente, direction Serveurs, grante, responsable des stocks
Fournisseurs Outputs Activits
Clients Dpartements Personnes
Activits exclues : Gestion des ressources humaines, Gestion des fournisseurs du processus
Tableau 1.3-2 : Dterminants de la frontire du processus
I.4 Processus et systme dinformation de gestion, de facturation et de gestion des stocks

Ltude prliminaire a port sur le processus de gestion des commandes et de facturation, de gestion des stocks et sur le systme dinformation qui les supporte. Comme lillustre la figure et les tableaux prcdents, le processus et le systme dinformation de gestion des commandes et de facturation et de gestion des stocks sont en interaction avec plusieurs autres processus et systmes de lentreprise, de mme quavec un principal partenaire du restaurant, soit les clients. A linterne, peu prs tous les services sont impliqus de prs ou de loin dans la gestion des commandes ainsi que dans la gestion des stocks. Ces processus sont donc au cur des activits de la maison et leur performance a des incidences directes sur celle du restaurant lui-mme.
Les paragraphes qui suivent, de mme que la figure et les tableaux prcdents dcrivent les lments essentiels du processus et du systme dinformation de gestion des commandes et des stocks. Deux sources fournissent de linformation. Tout dabord le client qui passe ses commandes, effectue des paiements et fait des requtes sur ces commandes et ensuite les responsables des stocks qui fournissent quotidiennement des rapports sur les approvisionnements ou sur les ventes. Les outputs sont dirigs vers lune ou lautre des deux entits suivants : le client qui reoit un service selon sa demande, accompagn dune facture ; linformation sur les crdits quil aurait pris auparavant ; et les membres de la direction qui sont transmis tous les jours divers inventaires. Le processus daffaire ltude chevauche trois units : les ventes, les stocks et le service des contrles. Le service des ventes est impliqu dans le processus par le biais des serveurs, prposs la prise des commandes. Ils saisissent la commande des clients sur des bons de commande quils acheminent la caisse, et une copie aux responsables des stocks (la cuisine et le bar) qui effectuent la mise jour de leurs stocks et transmettent des rapport quotidiens au responsable du service des contrles(la grante). Les serveurs se chargent aussi de rpondre aux diverses requtes des clients au sujet de leurs commandes. La caisse met la facture et peut octroyer une dette sur permission de la grante ou dun autre responsable. Les responsables des stocks soccupent principalement de prparer les produits que les serveurs se chargent de servir aux clients. Le processus de gestion des commandes et des stocks interagit aussi avec deux autres processus qui nont pas t inclus dans le cadre de ltude. Il sagit des processus de gestion des ressources humaines et de gestion des fournisseurs.
I.5 Objectifs du processus et du systme dinformation

Nous avons tabli les objectifs que devraient atteindre le processus et le systme dinformation qui le supporte afin de desservir lentreprise de faon optimale. Les objectifs du processus ont t tablis partir des meilleures pratiques de lindustrie et linformation recueillie auprs des personnes interviewes :
Rduction de 67% des pertes occasionnes par les cas de tricherie, de casse ou de vol sur les boissons ; Une quantit minimale dactivits sans valeur ajoute. Bien que lanalyse effectue jusqu maintenant soit prliminaire, nous avons pu observer quun certain nombre dactivits ne comportent pas de valeur ajoute. Il importe de limiter le nombre dactivits de ce type. En ce qui a trait au systme dinformation, deux objectifs spcifiques ont t retenus. Sans pour autant ngliger les autres aspects de la qualit de linformation, notre analyse nous a rvl deux critres plus importants que les autres dans le cas qui nous occupe et qui sont : Un taux derreur de 1%. Linformation produite par le systme de gestion des commandes doit tre, autant que possible, exempte derreurs. Latteinte de cet objectif est importante non seulement au niveau de linformation produire pour supporter la prise de dcision des gestionnaires, mais aussi pour assurer la satisfaction de la clientle (pas derreurs de facturation, de contenu de commande, etc.). De linformation de gestion satisfaisant les besoins des gestionnaires. Les gestionnaires du restaurant BELVEDERE jugent essentiel de disposer dinformation adquate leur permettant de suivre lvolution de leur entreprise.
I.6 Problmes
Les observations et les entrevues que nous avons menes auprs de la direction et des employs du restaurant BELVEDERE ont permis de confirmer la prsence de certains problmes lis au processus de gestion des commandes et de facturation et celui de gestion des stocks.
10
Ces problmes sont : Des erreurs de facturation ; Des cots (surtout en temps) levs de traitement de donnes. En effet, le restaurant BELVEDERE dispose dun stock principal partir duquel les autres stocks (la cuisine et le bar) sapprovisionnent. Le stock bar est son tour subdivis en 3 sous stocks : frigo-Heineken, frigo-aquavie et frigo-expo. La subdivision de ce stock ne pose aucun problme mais cest le traitement de linformation li cette subdivision qui alourdi la tche du responsable car celui-ci doit chaque fois complter deux fiches.2
I.7 Evaluation de la faisabilit du projet

De faon gnrale, lvaluation de la faisabilit dun projet de dveloppement consiste se demander sil existe des lments qui empcheraient les solutions envisages dtre ralises et implantes avec succs. Brivement, ltude de la faisabilit a pour objectif de dterminer les possibilits raisonnables de russite dun projet. Pendant notre tude, nous avons examin seulement deux domaines de faisabilit ; lun des type organisationnel et lautre de type technique. I.7.1 Faisabilit organisationnelle Le restaurant vient rcemment denregistrer des pertes normes dues aux cas de vol, de tricherie ou de casse. Selon notre analyse, ces pertes proviennent de la difficult de la direction traiter certaines donnes dune faon plus nette. Le traitement de donns (la facturation, le calcul de la trsorerie,) se fait presque manuellement et une partie des inventaires sur des tableurs Excel mais les membres de la direction sont, pour la plupart, en faveur du changement et chacun est conscient que la situation actuelle ne peut se perptuer sans danger pour lentreprise. Nous avons galement peru cette disposition au changement de la part de plusieurs employs rencontrs.
Voir fiches de lannexe A11 et A12
11
I.7.2 Faisabilit technique Linstallation dun nouveau systme pourrait ventuellement requrir de nouvelles comptences. A notre avis, lacquisition de ces dernires ne devrait poser aucun problme majeur vu que parmi les critres de recrutement des serveurs, il y a entre dautre, qui ncessite une matrise de lutilisation de Word et Excel.
Chapitre II. Diagnostique de lexistant
12
Chapitre II. DIAGNOSTIC DE LEXISTANT
II. 1 De la ncessit de faire une tude de lexistant

Trop souvent a-t-on entendu : Nous dpensons des sommes normes en technologies de linformation, et pourtant, nous voyons trs peu de bnfices directs dans les gains en productivit . A ce commentaire, plusieurs experts rpondront que ce manque de gains directs est d non pas une technologie fautive ou inutile, mais plutt une implantation de technologie qui sest faite sans analyser, diagnostiquer et modifier les processus daffaires et/ou les systmes dinformation que cette technologie devait soutenir. En effet, il arrive quon informatise sans analyse, cest--dire quon dveloppe une application informatique ou quon fasse lacquisition dun logiciel sans se proccuper ni du processus daffaires dont fait partie le systme dinformation, ni du systme dinformation lui-mme. Quelles sont les consquences dune telle faon de faire ? Si lon applique une technologie de linformation un systme dinformation mdiocre en calquant lapplication informatique sur une faon de faire errone, les consquences se feront sentir trs rapidement. En effet, les problmes apparatront plus rapidement puisque la technologie permet daugmenter la rapidit du traitement ! Un cas extrme pourrait tre celui dune entreprise de distribution o lon ne vrifie pas le crdit du client avant dapprouver une vente. Si cette entreprise fait affaire avec un nombre restreint de bons clients, il se peut que les mauvaises crances soient relativement peu leves, et que lentreprise se sente instable auprs de ce processus erron. Imaginons maintenant que lentreprise dcide de faire du commerce lectronique et de faire affaire sur Internet. Son bassin de clientle devient beaucoup plus vaste, et les mauvaises crances plus difficiles recouvrer. Il serait donc essentiel, ce moment, de resserrer la politique de crdit. Si lentreprise ne fait quappliquer la nouvelle technologie son ancienne faon de faire, les risques sont levs quelle se retrouve trs rapidement avec de srieux problmes de mauvaises crances !
13
Un autre cas de figure est celui de la mise en place dune application informatique qui, quoique techniquement correcte, amne de la complexit et de linefficacit dans le processus daffaires plutt que de le soutenir. Telle fut lexprience de Sabex3, une PME fabriquant des produits pharmaceutiques. En 1989, Sabex fit lacquisition dun progiciel qui devrait soutenir la gestion de la production, la prise de commande, la facturation et lexpdition. Aprs quatre ans dutilisation du progiciel, la direction de Sabex sinquitait des longs dlais des facturations. On fit donc appel une firme-conseil qui entreprit danalyser le processus de prise de commande et de facturation et sa recommandation fut dliminer la production de bons de commande qui napportait rien au processus. Au contraire, elle navait pour effet que de ralentir le processus, de le complexifier et, finalement, daugmenter les risques derreurs. Somme toute, lentreprise ne lutilisait que parce quil faisait parti du progiciel qui tait acquis !4 Une autre tude faite auprs des entreprises membres du Information Week 5005 aux Etats-Unis, Erik Brynjolfsson et Lorin Hitt ont trouv que les entreprises les plus performantes du point de vue de la productivit et de la profitabilit taient celles qui investissaient en technologies de linformation en mme temps quelles transformaient leur processus daffaires6. La technologie en elle-mme ne peut donc apporter de bnfices rels. Cest en transformant les processus daffaires et les systmes dinformation dabord, puis en les soutenant avec des technologies de linformation adquates ensuite, quon parvient obtenir dimportants bnfices.
II.2 Objectifs
Les principaux objectifs du diagnostic de lexistant sont de dfinir les problmes du processus existant et du systme dinformation qui le soutient, ainsi que les causes de ces problmes, de dfinir les objectifs que devraient atteindre un processus et un systme dinformation transforms et de suggrer quelques lments de solution qui permettraient datteindre ces objectifs.
C. BERNER, La socit Sabex , Ecole des Hautes Etudes Commerciales, 1994. S. RIVARD et J. TALBOT, op. cit., P. 116. 5 Les entreprises faisant partie du Information Week 500 sont les entreprises amricaines qui sont les plus importantes utilisatrices des technologies de linformtion. 6 E. BRYNJOLFSSON et HITT, The Productive Keep Producing , Information Week, 18 sept. 1995
4
14
II.3 Planification de ltude de lexistant

II. 3. 1 Formation de lquipe La composition finale dune quipe dtude dpend de plusieurs facteurs : lenvergure du processus daffaires et du systme dinformation, la taille de lorganisation, les modes de gestion de projets en vigueur dans lorganisation, la disponibilit et lexprience des intervenants potentiels. Pour notre cas, cette quipe est forme de nous deux qui prsentons ce travail, de la grante et dune caissire. II. 3. 2 Mthodes et outils de travail Faire une tude consiste essentiellement recueillir de linformation, en faire la mise en forme en construisant des modles du processus daffaires et du systme ltude, prparer la documentation de ces modles et utiliser ces modles et une documentation pour dfinir les problmes, leurs causes et dterminer des lments de solution. Les mthodes de travail et les outils de lquipe seront donc les instruments qui faciliteront laccomplissement de ces tches. Les outils dont nous nous sommes le plus servi sont lobservation, linterview et la documentation du restaurant. Une heureuse concidence a fait que, pendant cette tude, lun dentre nous a eu la chance de se faire engager au restaurant comme grant a.i. Le fait quil fasse entirement parti de lorganisation nous a accord le privilge davoir tout le temps pour ces observations et de nous rapprocher de plus en plus des personnes concernes pour les interviews.
15
II. 4 Fonctionnement du processus daffaire et du systme dinformation

II. 4. 1 Amnagement physique et aspect ergonomique Le restaurant BELVEDERE dispose de deux grandes salles ayant une capacit daccueillir prs de 200 personnes ; dune cuisine qui peut alimenter les deux salles en mme temps ; dun bar (ou deux, lorsque la deuxime salle est occupe mais pour la suite, nous ne parlerons que du bar de la salle principale, celle qui est occupe toutes les occasions ); dune caisse pour la facturation ; dun dpt central qui constitue les stocks du restaurant et dune direction pour la gestion du fonctionnement du restaurant. La cuisine dispose dun dpt local et le bar de trois dpts locaux: frigo-Heineken, frigo-expo et, frigo-aquavie. II. 4. 2 Fonctionnement Le restaurant est ouvert tous les jours raison de deux sances par jour, cest--dire de 12h 14h, puis de 18h 23h, sauf les samedis et les dimanches o il est ouvert de 12h 23h. Tous les matins partir de 10h, on procde la mise en place. Cest un processus qui consiste prparer la salle de faon quelle soit propre et disposer le plus prs possible de soi tout ce dont on aura besoin par la suite : les boissons, les verres, les cuillres, etc. Tous les stocks locaux ( la cuisine et au bar) sont donc aliments par le dpt central tous les matins en fonction de la prvision de la clientle de la journe. Chaque stock est gr par une personne qui se charge de contrler les mouvements dentre et de sortie et de remettre au quotidien les rapports la direction.7 Lorsquun client passe une commande, le serveur complte un bon quil remet la caisse, avec une copie la cuisine et une autre au bar.8 La caisse enregistre les commandes passes par le client et labore une facture. A la fermeture du restaurant, la caisse complte une fiche qui fait ressortir la trsorerie de la sance ou de la journe. Rappelons que toutes les oprations la caisse se font manuellement (llaboration de la facture et la cration du fiche journalire).9
7 8
Voir annexe A12 Voir annexe A13 9 Voir annexe A14 et A15
16
A partir des souches du facturier, la direction se charge dinventorier les boissons vendues et de confronter, grce un ordinateur, sur une feuille de calcul Excel, les donnes renvoyes par cet inventaire avec les rapports du responsable des stocks au bar pour dcel le nombre de boissons invendues, perdues ou casse.
II. 5 Analyse de lenvironnement

Un processus daffaires et le systme dinformation qui en fait partie nvoluent pas en vase clos. Ils sont influencs par de nombreux facteurs externes et ils ont un impact sur ces facteurs que composent lenvironnement. Pour effectuer une tude, nous devrions nous efforcer dacqurir une connaissance approfondie de cet environnement, afin dvaluer le degr de concordance entre le processus, le systme et les contraintes de lenvironnement. Cette connaissance sera aussi prcieuse ultrieurement, lors de lactivit de conception. Dabord, il y a la clientle du restaurant BELVEDERE qui constitue le principal environnement, du moins pour ce qui est du processus et du systme dinformation transformer. Elle est essentiellement constitue dentreprises prives et publiques (gouvernementales), de privs et de touristes. Lors de notre tude prliminaire, nous avons numr deux problmes lis au processus daffaires en cours et au systme dinformation qui le supporte, savoir : les erreurs de facturations et le temps de traitement de donnes relativement long. Ces clients sont parmi les premiers payer le prix de ces erreurs et donc parmi les premiers souhaiter le changement. Il y a ensuite les employs, et plus particulirement les serveurs, qui constituent un autre lment de notre environnement. Ils aimeraient ne plus se voir attribuer la responsabilit derreurs pourtant dues la complexit de donnes traiter manuellement et presque dans la globalit. Quelques sances de formation de tous les utilisateurs (les caissires qui sont par moment des serveuses et la grante) sur le nouveau systme implanter suivies au besoin dune certaine priode de suivie (un mois par exemple) et dvaluation seront ncessaires, pour que le passage du manuel linformatique seffectue sans heurts
17
Il y a enfin, les dirigeants. Ils ont finalement peru les bienfaits des nouvelles technologies de linformation et de la communication et voudraient aussi en tirer profit au maximum. Ils ont aussi ce dsir damliorer limage de leur entreprise par ce passage du systme manuel au systme informatis.
II. 6 Prsentation du processus (modle ANSI)

Cette tche consiste analyser linformation sur le processus daffaire et le systme dinformation qui a pralablement t recueillie puis synthtiser dans un modle, le fonctionnement de ce processus et du systme dinformation qui le supporte.
18
Fact
Respo Stock
Respo Stock
Fig. II.6-1 : Modle de processus daffaire
19
II. 7 Analyse causale

Ltude prliminaire a dj permis didentifier quelques problmes lis au processus daffaire et systme dinformation qui le supporte. Lexamen du modle du processus est une autre avenue quil est essentiel dexploiter et qui nous permet de voir beaucoup plus clairement ces problmes. Voici dans le tableau ci-dessous, une synthse de lanalyse causale qui rcapitule tous ces problmes, leurs impacts et leurs causes et, les objectifs dfinir pour amliorer le processus. Objectif
Rduction de 67% de cas de pertes sur les boissons.
Problme
Prs de 24% des boissons sont invendues.
Evaluationimpacts
La moyenne mensuelle de ventes potentiellement perdues se situe autour de 1900 000 FBu.
Causes
Processus daffaires complexe, Systme dinformation non matris.
Minimiser le nombre dactivits sans valeur ajoute.
Prsence dun grand nombre dactivits sans valeur ajoute.
Frais dexploitation immobiliss inutilement.
Systme non intgr.
Linformation produite doit tre exacte.
Il y a des erreurs frquentes de facturation.
Le client paie le prix de la surfacturation et le restaurant, le prix de la sousfacturation.
Non vrification de la facture avant expdition chez le client, Systme dinformation manuel et fastidieux.
Tableau II.7-1 : Analyse causale
Chapitre III. Modlisation et conception du nouveau systme dinformation
20
Chapitre III. MODELISATION ET CONCEPTION DU NOUVEAU SYSTEME DINFORMATION
III.1 Notions
III.1.1 Quest ce quun modle Un modle est une abstraction de la ralit o l'abstraction est un des piliers de l'approche objet. Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est--dire l'ensemble de caractristiques essentielles d'une entit, retenues par un observateur. En plus, cest une vue subjective mais pertinente de la ralit car il dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente. Montrons quelques exemples de modles10 : Modle mtorologique : A partir de donnes d'observation (satellite ...), celui-ci permet de prvoir les conditions climatiques pour les jours venir. Modle conomique : Il peut par exemple permettre de simuler l'volution de cours boursiers en fonction d'hypothses macro-conomiques (volution du chmage, taux de croissance...). Modle dmographique : Il dfinit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des tudes statistiques, d'augmenter l'impact de dmarches commerciales, etc.
10
ftp://ftp-developpez.com/laurent-piechocki/uml/tutoriel/lp/cours/coursUml.pdf visit le 15 Fvrier 2010
21
Les caractristiques fondamentales des modles sexpliquent lorsquun caractre abstrait d'un modle permet notamment de : Faciliter la comprhension du systme tudi : Un modle rduit la complexit du systme tudi ; Simuler le systme tudi : Un modle reprsente le systme tudi et reproduit ses comportements. Un modle rduit (dcompose) la ralit, dans le but de disposer d'lments de travail exploitables par des moyens mathmatiques ou informatiques : modle / ralit et digital / analogique. III. 1. 2 Langage UML III.1.2.1 Dfinition et formalisme UML (Unified Modeling Language, langage de modlisation unifi ) est un langage graphique de modlisation des donnes et des traitements. C'est une formalisation trs aboutie et non-propritaire de la modlisation objet utilise en gnie logiciel. Les vues de ce langage sont les observables du systme. Elles dcrivent le systme d'un point de vue donn, qui peut tre organisationnel, dynamique, temporel, architectural, gographique, logique, etc. En combinant toutes ces vues, il est possible de dfinir (ou retrouver) le systme complet. L'intrt de ces vues est de piloter l'analyse par les exigences des utilisateurs. Ceux-ci se sentent concerns car ils peuvent facilement les comprendre. Les diagrammes eux, sont des lments graphiques. Ceux-ci dcrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs vues.
22
Il existe 13 diagrammes UML qui sont dpendants hirarchiquement et qui se compltent, de faon permettre la modlisation d'un projet tout au long de son cycle de vie. Ils sont classs en 3 groupes : Les diagrammes structurels ou statiques (Structure Diagram) ; Les diagrammes comportementaux (Behavior Diagram) et ; Les diagrammes d'interaction ou dynamiques (Interaction Diagram) III.1.2.2 Avantages UML est un langage formel et normalis : gain de prcision, gage de stabilit, encourage l'utilisation d'outils, L'aspect formel de sa notation limite les ambiguts et les incomprhensions.
UML est un support de communication performant : Il cadre l'analyse. Il facilite la comprhension de reprsentations abstraites complexes. Son caractre polyvalent et sa souplesse en font un langage universel.
III. 2 Processus de spcification des besoins

III.2.1 Diagramme de cas dutilisation A partir des stratgies, le restaurant sest fix des objectifs atteindre en termes de qualit et de quantit. Nous avons numr quelques uns lors de notre tude prliminaire. Ces objectifs demandent la collaboration de plusieurs dpartements pour tre atteints.
23
Dans le cadre de la ralisation dun systme dinformation, les responsables des diffrents dpartements ont reu le mandat dlaborer la spcification dun systme dinformation remplissant les objectifs de la direction. Ces responsables ont dcrit le systme raliser au moyen des cas dutilisation que nous prsentons dans le diagramme de cas dutilisation de la Figure III.2-1, p.24
24
Restaurant
Enregistrer commande
Imprimer facture Caissire
Visualiser lhistorique Imprimer un journal

Enregistrer le paiement
Sauvegarder
Etablir linventaire Extend
Include
B.D
Passer la commande Grer les stocks Grant Grant Rgler la facture Client
Figure III.2.1-1 : diagramme de cas dutilisation
25
III.2.2 Exemple de cas dutilisation Enregistrer le paiement (au comptant) Acteurs Objectif : : Client, Caissier Dcrire un paiement au comptant dun service par le client. Un client se prsente au restaurant et passe une caissire commande. La enregistre la commande, imprime la facture, encaisse et enregistre le paiement du client et lui rend la monnaie.
Aperu
Tableau III.2.1-1 : Exemple de cas dutilisation : Enregistrer le paiement (au comptant)
Interaction typique Action dacteur Action systme 1. Le client est accueilli par le chef de rang, qui aprs examen du plan de la salle, le met en place. Le serveur donne la carte au client. Le client examine la carte et commande ses plats au serveur ainsi que les boissons.
2.
26
Interaction typique (suite) Action dacteur Action systme 4. Le serveur transmet la commande la caissire et au chef cuisinier. La caissire enregistre la 6. commande et crer une facture. La caisse dtermine automatiquement le prix unitaire de chaque produit et calcule le sous total
5.
7.
Les plats et les boissons prpars sont apports par le serveur Le client mange et boit. Le client demande laddition. 11. La caisse effectue la sommation du montant payer La caisse imprime laddition.
8. 9.
10. La caissire clture laddition.
12. Le serveur apporte laddition au client.
27
Interaction typique (suite) Action dacteur Action systme 13. Le client envoie la monnaie la caissire par le serveur ou se prsente lui-mme la caisse pour le paiement. 14. La caissire encaisse la monnaie, enregistre le paiement et rend la monnaie au cas o. 16. Le client quitte le restaurant. 15. La caisse classe laddition comme paye au comptant
Tableau III.2.1-2 : Interaction typique.
Alternatives 11. Clturer dabord la facture avant de limprimer. La caisse indique une erreur. 13. Le client na pas assez dargent. Le client paie une avance sur le solde d. 15. Slectionner le mode de paiement. La caisse indique une erreur.
Tableau III.2.1- 3: Alternatives.
28
III. 3 Processus de dveloppement

Les cas dutilisation de la Figure III.2.1-1, p.24 vont servir de rfrence tout au long de ce processus de dveloppement. La mission cette tape, va consister raliser un systme qui puisse fonctionner exactement comme dcrit dans ces cas ; ce qui va simplifier la procdure de test par la suite, car il ne suffira que de suivre les scnarios des ces cas dutilisation et de contrler que le systme peut sutiliser comme il tait prvu. Prcdemment, nous avions voqu que nous cherchions satisfaire les critres de complexit, dvolutivit, dimplmentabilit et de robustesse. Nous cherchons aussi diminuer la complexit du systme en permettant aux utilisateurs de spcifier le systme. Nous le rendons plus concret car les utilisateurs sont plus centrs sur laction que sur les abstractions. Au dpart, les descriptions peuvent paratre embrouilles, mais au fur et mesure des itrations, les objectifs de ces actions vont se dgager. A priori, il nya pas de modlisations fausse, il ny a que des modlisations qui ne refltent pas la ralit. Dans les paragraphes qui vont suivre, nous allons donc tcher de ramener la ntre le plus proche possible de la ralit. III. 3. 1 Proposition de la brigade du restaurant A part la ralisation dun systme dinformation, le processus de dveloppement a une autre mission : celle de procder la transformation du processus daffaires de faon ladapter de manire efficace au systme dinformation qui le supporte. Commenons donc par proposer notre organigramme.
29
Directeur Gnral
Directeur Financier
Grant
Directeur Administratif
Trancheur
Matre dhtel Chef de rang
Chef sommelier
Chef barman
Barman Commis de rang Commis dbarrasseur Commis barman
Caissire
Portier
Personnel dencadrement Figure III.3.1-1 : Proposition de la brigade du restaurant
Personnel dexcution
30
Le Directeur Gnral est responsable : de la gestion et de la rentabilit de ltablissement, du recrutement du personnel d'encadrement, des relations avec les fournisseurs, des relations commerciales en gnral. Il participe galement l'accueil des clients et peut traiter les rclamations. Il participe l'laboration de la carte avec le chef de cuisine et collabore l'analyse des ventes afin de dterminer les grandes lignes de la politique de l'tablissement. Le Grant joue le rle du premier matre dhtel et organise le travail de la brigade du restaurant. Il doit : laborer les diffrents plannings de service, recruter et former le personnel de salle, grer les relations clientles et les rservations, s'assurer de la qualit constante du travail en salle, il peut aussi remplacer le directeur lorsque celui-ci est absent, il labore les menus et les cartes (des boissons, des vins et des cocktails). Le matre d'htel est responsable d'un ou plusieurs carrs. Il doit : vrifier la mise en place gnrale du restaurant avant le service, encadrer toute la brigade pendant le service, accueillir et placer les clients, prendre les commandes des mets, effectuer les dcoupes, filetages ou flambages en salle. Le chef de rang fait partie du personnel d'excution. Il doit : participer la mise en place et l'entretient la salle de restaurant en vue du service, assurer le service des mets sur son rang, diriger les commis de suite, Il peut galement prendre en charge l'encaissement des clients.
31
Le commis de rang ou de suite : Ce poste confre plus de responsabilits qu'il n'y parait ; en effet il doit : assurer l'entretien des locaux et du matriel, participer la mise en place, et grer le linge, assurer la liaison entre la cuisine et le restaurant, ventiler et annoncer les bons aux diffrents services, seconder son chef de rang (son suprieur) pour le service des mets, il dirige les commis de suite. Le commis dbarrasseur doit : assurer l'entretien des locaux et du matriel, participer la mise en place, et grer le linge, seconder son commis de suite (son suprieur) pour des tches simples telles que le dbarrassage, la mise en place des couverts, etc. Le chef sommelier est le responsable du secteur "vins" au restaurant en collaboration avec le directeur de restaurant, le chef de cuisine et le matre d'htel : il dirige l'achat des vins et gre le room, il conseille la clientle dans ses choix et prend la commande des vins, il prend les commandes et effectue le service des vins, il s'occupe du matriel de sommellerie (sceaux, stands, paniers, etc.), il s'occupe de la gestion du room, s'occuper de la ventilation des bons de commandes et transporte les bouteilles la table client. Le chef barman doit : diriger et former son quipe de bar (barmans, commis de bar), participer lorganisation du travail de son quipe (plannings), grer le stock journalier des boissons. Le barman (Bar lady au fminin) : Dans le cadre de sa fonction, il doit : participer l'entretien des locaux et du petit matriel, il prpare les commandes clients avec le chef barman.
32
Le commis barman doit : entretenir le bar et le petit matriel du bar, participer la mise en place du bar, effectuer le service des boissons auprs de la clientle. Le trancheur est le responsable de l'organisation et de la mise en place du buffet. Il est le chef de cuisine. III.3.2 Diagramme de structure statique Ce type de diagramme possde plusieurs variantes, lies aux diffrentes perspectives (concept, type ou classe). Dans la phase danalyse, le diagramme de structure statique reprsente : les concepts du domaine tudi, les attributs et les responsabilits de ces concepts, les relations entre ces concepts. Rappelons quun concept est la reprsentation mentale dun objet11. III.3.2.1 Relations (Une cl de la relation est indique par un soulignement) REGLEMENT (N, NFact, ModePaiement, Etat, Avance, DateRgl, Observation, SessRgl) FACTURE (NFact, Matricule, Montant, DateFact, NomClient, NTable, TlClient, StClient) VENTES (NFact, CodeProd, Qvendu, Sesion, Temps, DateVente) PRODUITS (CodeProd, Libell, Prix, PrixPerso, Type) STOCKVIN (Num, CodeProd, DateSL, QSortie, QReste, Perte) STOCKBOISSON (Num, CodeProd, Ouverture, Fermeture, DateS, Perte, VentesTh, Ajout) EVALSP (Num, CodeProd, DateS, QSortie, Perte, QReste, Livr) SPRINCIPAL (CodeProd, Article, StockAl) USERS (UserID, Login, Password, Nom) DEPENSE (N Dpense, Matricule, DateDp, Motif, Montant, Sesion, Temps) PERSONNEL (Matricule, Prenom, Fonction)
11
Dr Adronis N., Cours dingnierie des logiciels , Universit Lumire de Bujumbura, AA 2007-2008
33
III.3.2.2 Diagramme des classes Ce diagramme reprsente larchitecture conceptuelle du systme. Il dcrit les classes ainsi que les relations entre ces classes.
Entraine Gnre
Gnre
Produit Effectue Produit Occasionne
Figure III.3.2.2-1 : Diagramme des classes
34
III.3.2.3 Domaine des constituants Un domaine dsigne un ensemble de valeurs. Il est similaire la notion de type (voir tableaux III.3.2.3-1 11, p.35-38) que lon trouve dans les langages de programmation. Ces valeurs seront prises par les donnes de notre champ dapplication. Dfinition12 : Un domaine est un ensemble D non vide, fini ou dnombrable. Un ensemble est dnombrable si lon peut compter laide des entiers naturels N. notons que les nombres rels ne sont pas dnombrables, mais leur reprsentation dans les ordinateurs tant finie, ils deviennent dnombrables. On pourra donc les utiliser comme domaine ! On dira que a est une valeur de D si a D Exemples de domaine : Domaine_des_couleurs = vert, jaune, bleu, rouge Domaine_des nombres_entiers = 1, 2, 3, , n, Domine_des_tats_des_portes = ouvertes, fermes Domaine_des_pays = Burundi, France, Panama, Domaine_des_tats_logiques = vrai, faux Un constituant (ou nom de champ pour le cas des tableaux III.3.2.3-1 11, p.35 - 38) est un ensemble de donnes ayant une proprit et un comportement homogne dans le champ dapplication. La signification des donnes rside dans lappartenance cette classe. La donne ROSE sera interprte comme un prnom si elle est une valeur du constituant PRENOM, comme une espce de fleur si elle est une valeur du constituant FLEUR, comme une couleur si elle est une valeur du constituant COULEUR. Le constituant est associ un identificateur (PRENOM, NOM, FLEUR, COULEUR, DATE_NAISSANCE). Le constituant est associ un et un seul domaine qui dfinit les valeurs que peut prendre cette proprit.
_12 Jacques G., Conception & ralisation des bases de donnes : de UML SQL , Editions systmes et information, 2002, p. 91.
35
REGLEMENT
Tableau III.3.2.3-1 : Table REGLEMENT
FACTURE
Tableau III.3.2.3-2 : Table FACTURE
VENTES
Tableau III.3.2.3-3 : Table VENTES
36
PRODUITS
Tableau III.3.2.3-4 : Table PRODUITS
STOCKVIN
Tableau III.3.2.3-5: Table STOCKVIN
STOCKBOISSON
Tableau III.3.2.3-6 : Table STOCKBOISSON
37
EVALSP
Tableau III.3.2.3-7 : Table EVALSP
SPRINCIPAL
Tableau III.3.2.3-8 : Table SPRINCIPAL
USERS
Tableau III.3.2.3-9 : Table USERS
38
DEPENSE
Tableau III.3.2.3-10 : Table DEPENSE
PERSONNEL
Tableau III.3.2.3-11 : Table PERSONNEL
39
III.3.3 Diagramme de squence Le diagramme suivant va dcrire le droulement de linteraction de paiement dune facture au comptant, en mettant en vidence sa dimension temporelle.
User Interface
: Serveur
: Facturation
: Client
Caissire
1 : Logon 2 : Demander les bons
3: Transmettre les bons 4 : Enregistrer commandes 5 : Etablir la facture 6 : Sous-total
7: Afficher le montant
8 : New : Imprimer la facture
: Facture
9 : Communiquer le montant
10 : Paiement 11 : Encaisser et enregistrer le paiement
Figure III.3.3-1 : Diagramme de squence
40
III.3.4 Dictionnaire de donnes Table Champs N NFact ModePaiement Etat Avance DateRg Observation SessRgl NFact Matricule Montant DateFact NomClient NTable TlClient StClient NFact CodeProd Qvendu Sesion Temps DateVente Dsignation Numro denregistrement Numro de facture Mode de paiement Etat de la facture(en cours, pay, avance, crdit ou annule) Montant avanc si la facture nest pas paye en totalit La date de paiement Observations sur la facture sils existent Session de paiement (AM : pour les facture de la journe et PM : pour la soire) Numro de facture Numro matricule du serveur qui va apparatre sur la facture Total payer Date de cration de la facture Nom du client (enregistr pour le cas des crdits) Numro de la table Tlphone du client (enregistr pour le cas des crdits) Socit o travail le client (enregistr pour le cas des crdits) Numro de facture Code de larticle Quantit vendue Session de vente (AM : pour les facture de la journe et PM : pour la soire) Heure de vente Date de vente
REGLEMENT
(Enregistrement des paiements)
FACTURE
(Enregistrement des factures cres)
VENTES
(Enregistrement des ventes)
41
Table
Champs CodeProd Libell PRODUIT Prix (Enregistrement des produits) PrixPerso Type Num CodeProd STOCKVIN DateSL (Evaluation du QSortie stock de vins) QReste Perte Num CodeProd Ouverture STOCKBOISSON Fermeture (A part les vins et DateS les liqueurs) Perte VentesTh Ajout
Dsignation Code de larticle Nom de larticle Prix de larticle Prix rduit (pour le personnel du restaurant) Type darticle (Produit Brarudi, aliments, vins) Numro de lenregistrement Code de larticle Date de lvaluation du stock Quantit vendue Quantit restant dans le stock Pertes Numro de lenregistrement Code de larticle Quantit en ouverture du stock Quantit en fermeture du stock Date dvaluation du stock Pertes Vente thorique de larticle X = Ouverture + Ajout Fermeture Quantit ajoute au stock vendre
42
Table
Champs Num CodeProd EVALSP DateS (Evaluation du QSortie stock principal Perte (central)) QReste Livr CodeProd SPRINCIPAL Article (Stock principal) StockAl UserID Login USERS (Utilisateurs) Password Nom NDpense Matricule DateDp DEPENSE Motif (Enregistrement des dpenses) Montant Sesion Temps Matricule PERSONNEL Prenom (Seulement concern par le SI) Fonction
Dsignation Numro de lenregistrement Code de larticle Date de lvaluation Quantit sortie du stock principal Pertes Quantit reste dans le stock la fermeture livraison Code de larticle Libell de larticle Stock dalerte Numro de lenregistrement Login de lutilisateur Mot de passe de lutilisateur Nom de lutilisateur Numro de lenregistrement Numro matricule du personnel crditeur Date de la dpense Raison de la dpense Montant de la dpense Session de la dpense (AM : pour les facture de la journe et PM : pour la soire) Heure de la dpense Numro matricule Prnom Fonction (serveur, caissire, grante)
Tableau III.3.4-1 : Dictionnaire de donnes
Chapitre IV. Ralisation, Implmentation et Test
43
Chapitre IV. REALISATION, IMPLEMENTATION ET TEST
Le chapitre prcdent nous a dj donn une ide globale de laspect fonctionnel quaura notre systme dinformation bien que les choses ne se dgagent pas assez clairement quen ingnierie traditionnelle (mcanique, ingnierie civile,). En effet, la nature immatrielle du logiciel (model dans linformation et non dans la matire), rend la frontire entre larchitecture et le produit beaucoup plus flou quen ingnierie traditionnelle. Cependant, cette phase de conception logicielle (chapitre III) a permis de raliser entirement le produit sous sa forme abstraite avant sa production effective. Dans le prsent chapitre, nous prsentons le mme produit, mais cette fois sous sa forme la plus concrte cest--dire : le nom permettant de lidentifier sans ambigut ; comment il a t ralis et les outils partir desquels il a t ralis ; une description des problmes quil vise rsoudre.
IV.1 Rles des membres dune quipe de ralisation dun Systme Informatique
Le dveloppement des systmes dinformation (logiciels) se fait diffremment dans chaque organisation, et dans chaque bureau travers le monde. Le processus quune organisation ou une personne utilise peut fonctionner pour un environnement ou une situation spcifique et chouer misrablement dans dautres circonstances. Cest, en partie, les diffrences denvironnement qui font quil soit difficile de dfinir de manire standard le processus de dveloppement des SI. Cependant, en dpit de tous ces changements il existe certaines choses qui restent les mmes : il y aura toujours besoin de comprendre le problme traiter ; de convertir le problme en une architecture ; de convertir larchitecture en une solution et de tester la solution et la dployer.
44
Bien que chacun de ces processus puisse changer mesure de modles de programmation et les outils utiliss, fondamentalement, il existe quelques fonctions que chaque processus doit avoir sous une forme ou une autre. Une personne peut remplir toutes ces fonctions, un certain nombre, ou une fonction bien dtermine. Pour notre cas nous avons prfr effectuer toutes les fonctions ensemble. Evidement, toutes les fonctions suivantes ne se sont pas retrouves dans notre projet mais elles reviennent dune manire ou dune autre dans tous les projets de dveloppement de SI. Ainsi, nous avons le : Development Manager : Gardien du plan de travail de toute llaboration du projet, il est le chef excutif du dveloppement du projet. Il apprend lquipe comment communiquer avec la direction de lentreprise et comment adapter les priorits du dveloppement de logiciel aux objectifs de lentreprise. Project Manager : Travaillant en collaboration avec le Development Manager, il sassure du bon fonctionnement des processus du dveloppement de logiciel. Expriment aussi comme un analyste fonctionnel (FA), il dveloppe les mthodes, normes, modles et processus. Subject Matter Expert : Souvent appel un expert, entrepreneur ou utilisateur daffaires, cest une personne qui connat ce que le logiciel doit faire et comment le processus sexcutera, tout en ignorant ce qui est du dveloppement de logiciel car il en a peu dexprience. Developer : Il est le noyau moniteur (core) du dveloppement de systme. Expriment en syntaxes et algorithmes, il cre et crit les codes du systme par lesquels le Development Lead fournira des spcifications. Development Lead : Son rle considr comme un pont reliant le Developer et Solutions Architect est focalis dans la fourniture du plus de dtails dans larchitecture du logiciel. Il est le premier support dassistance lorsque les dveloppeurs rencontrent certaines entraves.
45
Quality Assurance : Responsable dans la garantie du niveau de la qualit du systme la satisfaction du client. Il intervient la dtection en premier lieu des erreurs pouvant surgir lors du processus de dveloppement. Cest lui qui tablit les diffrents tests (Debugger) du systme. Functional Analyst : Il tablit le modle de processus daffaires et le transforme en un langage de modlisation (ex.UML) en claircissant les lments reflts par lExpert (SME). Solutions Architect : Il convertit les besoins dans une architecture et design qui, par la suite, deviendra le prototype du systme pour la solution cre et attendue. Il est responsable du choix des outils technologiques pour la rsolution des problmes. Deployement : Il conoit un programme qui construit un environnement oprationnel que la solution requiert ; en tablissant les changements de configuration, en installant des sites sine qua non ainsi que des programmes de procdure (fonction ne renvoyant pas de rsultat) et en dployant les composants du systme. Trainer : Responsable de la documentation du systme, il conoit des matriels ncessaires linstruction de base de lutilisation du systme. Cependant, Il dmontre et explique la convivialit du systme aux utilisateurs (utilisation des interfaces ou crans du systme).
46
IV.2 Prsentation du produit

IV.2.1 Nom et caractristiques techniques
Nom: ContrOl.sys Version: 1.0 Platform: Windows Utilisateur : Mono-utilisateur Licence : Freeware open source Taille : 3,26 MB Vitrine : www.control.unblog.fr IV.2.2 Interfaces humain-machine Larchitecture de ContrOl.sys a t conu dans le strict respect des principes de Joseph Dumas. Selon lui, la conception de linterface humainmachine dun systme dinformation doit sappuyer sur les sept principes gnraux qui suivent13 : sassurer que lutilisateur soit en contrle du systme, cest--dire quil toujours capable dindiquer au systme les actions accomplir ; concevoir le systme en fonction de lhabilit et de lexprience des utilisateurs ; tre cohrent dans les termes, les formats, et les procdures utiliss ; dissimuler aux utilisateurs les rouages internes des logiciels et matriels utiliss la conception du systme ; fournir de la documentation lcran ; rduire au minimum la quantit dinformation que lutilisateur doit mmoriser durant lutilisation du systme ; se baser sur les principes reconnus du graphisme lorsquon dispose linformation lcran et sur papier.
13
S. RIVARD et J. TALBOT, op. cit, p.270.
47
IV.2.1.1 Splash Screen
IV.2.1.2 Interface didentification
Figure IV.2.1.2-1 Splash Screen
Figure IV.2.1.2-1 Interface didentification
IV.2.1.3 Facturation et paiement
Figure IV.2.1.3-1 : Facturation et paiement
48
IV.2.1.4 Trsorerie et dpenses
Figure IV.2.1.4-1 : Trsorerie
49
IV.2.1.5 Historiques
Figure IV.2.1.5-1 : Historique
50
IV.2.1.6 Gestion des stocks (Bar)
Figure IV.2.1.6-1: Gestion des stocks (Bar)
51
IV.2.1.7 Gestion des stocks (principal)
Tableau IV.2.1.7 Gestion des stocks (principal)
IV.3 Environnement de travail

ContrOl.sys a t dvelopp avec les outils suivants : Microsoft Visual Basic 6.0 : pour le dveloppement et lencodage. Adobe Photoshop (master collection CS3) : pour le design Microsoft Access 2007: pour la base de donnes Microsoft Excel 2007 et internet explorer 5.5: pour les fichiers supplmentaires (facture, journal, fichier daide,)14 Setup Factory 7.0.4.0 : pour la cration du Setup Ordinateur portable IBM Pentium III, 820MHz, 128MB RAM, 40GB HDD sous Windows XP SP2 Version 2002
14
Fichiers en annexe
52
IV.4 Design
Larchitecture de ContrOl.sys est conue partir des objets courants du compilateur Visual Basic 6.0. Nonobstant, celui-ci ne dispose pas de moyens de ralisation de graphismes beaucoup plus personnaliss. Cest ainsi que nous avons fait recourt Adobe Photoshop V. CS3, un logiciel spcialis pour le graphisme, pour crer dautres boutons de commande, dautres icones.15 Voici comment nous avons procd pour crer le bouton imprimer par exemple, du snap shoot Facturation et paiement de la Figure IV.2.1.3-1., p.47 : Dmarrer Photoshop puis crer un nouveau fichier Sous le menu image taille de limage, dterminer la taille au choix. (pour notre cas, 30/80) Insrer une image de limprimante et crire cot de limage le mot imprimer ; ce qui nous donne une image de la forme suivante : Enregistrer limage au format JPEG
Retourner Visual Basic et dessiner un cadre avec loutil image Dans la fentre de proprit, sous la proprit picture , insrer limage rcemment cre. Pour donner laspect dun bouton de commande limage, crer une autre image mais elle cette fois, partir de la fentre des calques, lui associer un effet de lombre pour avoir une image de la forme suivante :
Constatons que lombre vient de donner un effet de gonflement limage. Superposer les deux images dans Visual Basic de faon que le premier cache le second. Renommer les deux objets de la mme faon ; ce qui donne un nom de la forme : imprimer_fact(0) et imprimer_fact(1).
15
Voir Figure IV.2.1.3-1, p.48
53
Pour que limage ombre (imprimer_fact(1) qui, au dpart se situe en dessous de imprimer_fact(0)) apparaisse au passage du curseur, crire le bout de code suivant :
Ce qui donne la fin, un effet de gonflement au passage du curseur sur lobjet et de dgonflement lorsque le curseur sloigne de lobjet.
IV.5. Encodage
La cration d'un programme informatique consiste pour un programmeur concevoir puis crire les algorithmes en rapport avec le travail que l'ordinateur devra faire. Les instructions d'un processeur tant difficilement comprhensibles pour un humain, les instructions seront crites en suivant les rgles lexicales et la ponctuation d'un langage de programmation, puis soumises un programme informatique appel compilateur, qui les transformera en instructions pour le processeur. Le texte crit dans un langage de programmation et comprhensible par un humain est appel code source. Le code source de ContrOl.sys comporte plus de 4500 lignes de code. Nous ne saurons transcrire lintgralit ici, mais seulement une partie. Nous allons donc considr le code suivant (du bouton Imprimer de la Figure IV.1.1.5-1, p.48), permettant dimprimer une facture :
54
55
IV.6 Guide dutilisation

Ce guide dcrit les grandes tapes du fonctionnement de ContrOl.sys. Il est galement disponible sous le menu Aide au format html. Ainsi donc, pour : Crer une nouvelle facture - Remplir les 4 champs : produit, serveur, quantit, ntable, - Cliquer le bouton nouvelle . Ajouter un nouveau produit - Slectionner la facture dans la liste des factures, - Ne remplir que 2 champs : produit, quantit, - Cliquer le bouton Ajouter . Supprimer un produit ajout par erreur - Slectionner la facture dans la liste des factures, - Slectionner la ligne de commande errone, - Ecrire la quantit supprimer dans le champ quantit , - Cliquer sur le bouton supprimer , - Confirmer la suppression. Clturer la facture - Slectionner la facture dans la liste des factures, - cliquer le bouton clturer . Imprimer la facture - Cliquer le bouton imprimer , - Attendre quelque seconde, le temps de laisser la feuille de calcul Excel souvrir16, ensuite imprimer partir de la feuille, - Fermer la feuille de calcul Excel et ne pas enregistrer les modifications (aucune importance). Classer la facture * Comme paye en totalit - Slectionner la facturer dans la liste des factures, - Cocher la case paye en totalit , - Slectionner le mode de paiement (cash ou crdit), - Cliquer le bouton classer .
16
Voir Annexe A16
56
* Comme paye crdit - Slectionner la facturer dans la liste des factures, - Remplir les cases correspondant aux coordonnes du client (Nom, Tl. et/ou socit), - Cliquer le bouton modifier , - Dcocher la case paye en totalit , - Cliquer le bouton classer , - Confirmer le classement. * Comme paye en avance - Slectionner la facturer dans la liste des factures, - Remplir les cases correspondant aux coordonnes du client (Nom, Tl. et/ou socit), - Cliquer le bouton modifier , - Dcocher la case paye en totalit , - Remplir le montant reu dans la case Avance paye , - Slectionner le mode de paiement (cash ou crdit), - Cliquer le bouton classer . Annuler une facture - Slectionner la facturer dans la liste des factures, - Remplir la case Observation , - Cliquer sur le bouton Annuler , - Confirmer lannulation. Enregistrer les dpenses - Cliquer sur le menu Journal , - Remplir les 3 champs : Motif, Montant, Crditeur, - Cliquer le bouton Enregistrer . Supprimer une dpense - Cliquer sur le menu Journal , - Cliquer la dpense supprimer, - Cliquer le bouton supprimer , - Confirmer la suppression.
57
Clturer un journal - Cliquer sur le menu Journal , - Cliquer sur le bouton Clturer , - Enregistrer la base de donnes, - Imprimer le journal.17 Parcourir lhistorique - Cliquer le menu Historique , - Slectionner la date de lhistorique recherch dans le calendrier, - Cliquer sur le bouton Dtail . Ajouter un nouveau produit dans le stock - Menu Stock , - Remplir les champs Article, prix et prix rduit, - Slectionner le type de produit, - Ajouter . Modifier un produit - Menu Stock , - Remplir le ou les champ(s) modifier, - Modifier . Supprimer un produit - Menu Stocks , - Slectionner le produit supprimer dans la liste, - Supprimer , - Confirmer la suppression. Evaluer les stocks - Menu Stocks , - Slectionner la date valuer dans le calendrier (sauf celle daujourdhui), - Cliquer sur le bouton Dtail et attendre quelques 10 secondes, - Slectionner la ligne de produit valuer, - Remplir les champs Ouv, Aj, Ferm et perte, - Cliquer licne de la disquette pour enregistrer les modifications sur le produit.
17
Voir Annexe 17
58
Pour le stock principal - Cliquer sur le bouton Stock P. , - Toutes les oprations ci-dessus (Ajouter, modifier, supprimer un produit, valuer le stock) sont aussi valables ici.
IV.7 Test et validation

Cette phase vise valuer la qualit du produit logiciel dvelopp, vrifier sil est conforme aux rsultats des phases danalyse et de conception et sil satisfait au cahier des charges (du Tableau I.3-1, p.6). Le procd que nous avons utilis pour tester notre logiciel sappelle le test en boite noire. Il consiste analyser un systme logiciel travers son interface.18 Son objectif est de dterminer si le systme satisfait ou non ses exigences fonctionnelles. Avec la collaboration des dirigeants du Restaurant BELVEDERE, il a t question de dceler les erreurs appartenant aux catgories suivantes : les fonctionnalits absentes ou incorrectement implmentes, les erreurs dinterface, les erreurs dans les structures de donnes, les dfauts de performance, les erreurs dinitialisation ou de terminaison.
IV.8 Analyse de limpact Aprs avoir dcel et corrig toutes les erreurs, le systme a t valid par la grante et install depuis le mois davril 2009. A partir de ce moment, nous avons effectu des observations et avons constat des volutions reprsentes sur les graphiques suivants :
18
Adronis N., Cours dingnierie du logiciel , Universit Lumire de Bujumbura, AA 2007-2008, p240.
59
Mois Janvier Fevrier Mars Pertes/Mois 1,780,000 1,530,000 1,930,000 60,000 54,642 62,258 Pertes/Jour
2,500,000 2,000,000
Pertes/Mois Pertes/Jour
Montant(en Fr Bu)
1,500,000 1,000,000 500,000 0 Janvier
Fvrier Mois
Mars
Fig. IV.8-1 : Analyse de limpact pr-installation19.
La figure prcdente concerne lvolution des pertes sur toutes les boissons sauf les liqueurs et les vins. Il sagit en effet, des boissons inventories par la direction comme produits les plus exposs au cas de tricherie et de vol. Ces donnes ont t prleves sur 3 mois avant linstallation du logiciel et lon peut constater quelles ont t en moyenne de 59000FBu par jour, puis de 11000FBu par jour au courant des 6 mois qui ont suivi linstallation (figure ciaprs).
19
Source : Direction du Restaurant BELVEDERE (Voir Annexe A1)
60
Mois Pertes/Mois Pertes/Jour
Avril
Mai
Juin
Juillet
Aot
Septembre
960,000 493,500 262,500 32,000 15,919 8,750
48,000 1,548
58,500 1,887
101,500 3,383
1,200,000 1,000,000
Montant
Pertes/Mois Pertes/Jour
800,000 600,000 400,000 200,000 0 Avril

Mai
Juin
Juillet
Aot
Septembre
Mois
Fig. IV.8-2 : Analyse de limpact post-installation20.
20
Source : Direction du Restaurant BELVEDERE (Voir Annexe A2 A7)
Conclusion Gnrale
61
CONCLUSION GENERALE
I. Enjeux
Il y a d'abord ce besoin de pouvoir rpondre aux exigences des clients dont les choix et les habitudes de consommation deviennent plus sophistiqus avec l'avnement des nouvelles technologies et l'effritement des frontires, ce qui ne fait qu'accrotre le niveau d'excellence requis pour les satisfaire. Il y a ensuite la ncessit daccrotre le niveau defficacit des ressources humaines, caractrises par une mauvaise organisation du travail et par le trop grand nombre de personnes engages dans la ralisation dun produit ou dun service, ainsi que par le manque de synergie entre ces personnes. Enfin, les bnfices de la ringnierie sont considrables: rduction dramatique du temps de ralisation du produit ou du service, amlioration de la qualit, rduction des cots et, invitablement, accroissement du niveau de satisfaction de la clientle. Dans ces conditions, certaines entreprises ont vu leurs chiffres d'affaires doubler en peu de temps.
II. Le processus daffaire et le systme dinformation : deux domaines finalement indissociables

Linformatique a toujours t largement critique dans lentreprise : on la souponne dtre tentaculaire, complique, peu flexible, coteuse. Cependant, elle ne cesse de progresser dans la puissance, le dbit, la facilit dusage et convivialit. Il existe dans lentreprise une opposition entres les utilisateurs de linformatique (homme de mtiers) et les concepteurs (techniciens de linformatique). Ils ne parlent pas le mme langage, ils nont pas les mmes proccupations et nont pas les mmes cycles de dveloppement.
Conclusion Gnrale
62
Lapproche organisationnelle de lentreprise (le monde des hommes) et lapproche informationnelle (le monde de linformatique) sont en fait deux visions diffrentes de la mme ralit oprationnelle : lentreprise. Et chaque fois quune entreprise a voulu sattaquer un seul de ces deux aspects, la tentative sest solde par un chec. Le Business Process Reengineering (BPR) en a t un exemple chaque fois que lon na pas associ troitement le Sytme dInformation. Cette rorganisation des mthodes de travail constitue souvent la premire phase d'un projet dinformatisation : on commence par rationaliser une activit de l'entreprise (la prise en compte d'une commande d'un client) afin de bien cerner tous les cas de figure et de pouvoir dclencher des actions adquates de manire automatique et sans ambigut.
III. Bref
Dans ce travail, nous venons de parcourir toutes les tapes dun projet dinformatisation depuis ltude prliminaire jusqu la ralisation dun systme informatique de facturation, de gestion de trsorerie et de gestion des stocks du Restaurant BELVEDERE. Nous avons dabord commenc par prsenter le Restaurant BELVEDERE et son systme de travail qui sous entend le processus daffaire et le systme dinformation qui le soutient - qui jusque l tait essentiellement manuel. Ensuite, nous avons dfini les problmes de ce systme ainsi que les causes de ces problmes. Puis, nous avons propos un nouveaux processus daffaire et un systme dinformation informatique adapt ce processus. Nous avons enfin conu et ralis le systme dinformation test et valid par le Restaurant BELVEDERE.
IV. Recommandations
Nous avouons que ce travail nest pas parfait et complet, et quil peut prsenter des lacunes. Nous souhaiterions donc que les gnrations venir les prennent en compte pour remplir efficacement notre devoir : ramener le plus proche possible les NTIC Nouvelles Technologies de lInformation et de la Technologie au service des plus ncessiteux.
Conclusion Gnrale
63
Pour ce fait, nous recommandons : 1. de dvelopper la mme application, mais cette fois en multi utilisateurs puis ; 2. dintgrer un module de gestion des Ressources Humaines.
Rfrences
REFERENCES
S. RIVARD et J. TALBOT, Le Dveloppement de Systmes dInformation , 3 Ed., Presse de lUniversit de Qubec, P. 20, 2003. C. BERNER, La socit Sabex , Ecole des Hautes Etudes Commerciales, 1994. BRYNJOLFSSON et HITT, The Productive Keep Producing , Information Week, 18 sept. 1995 Jacques G., Conception & ralisation des bases de donnes : de UML SQL , Editions systmes et information, 2002, p. 91 I. Jacobson, M. Christerson, P. Jonson, G. Overgard, Object-Oriented software engineering : A use case , Addison-Wesley 1992 Liskov B. ; Wing J. , Behvioral Botion of Subtyping, ACM Transactions on Programming Languages and Systems, Vol 16, No 6, November, 1994, p. 1811-1841 R. Bogue, Breaking Down Software development Roles, Jupitermedia Corp., 2006 Adronis N., Cours dingnierie des logiciels , Universit Lumire de Bujumbura, AA 20072008 ftp://ftp-developpez.com/laurent-piechocki/uml/tutoriel/lp/cours/coursUml.pdf
Table de tableaux
TABLE DE FIGURES
Table de tableaux
TABLE DE TABLEAUX
Table de matires
TABLE DE MATIERES
Chapitre 0. INTRODUCTION .............................................................. 1 Chapitre I. ETUDE PRELIMINAIRE................................................... 3
I. 1. Restaurant BELVEDERE ..................................................................................................................... 3 I.1.1 Prsentation ............................................................................................................................ 3 I.1.2 Organigramme......................................................................................................................... 3 I.1.3 Services .................................................................................................................................... 4 I.1.4 Missions et objectifs ................................................................................................................ 4 I.1.5 De linformatique .................................................................................................................... 4 I. 2 Mthodologie de ltude prliminaire .............................................................................................. 5 I. 3 Frontire du processus daffaire, et du systme dinformation........................................................ 5 I.4 Processus et systme dinformation de gestion, de facturation et de gestion des stocks ............. 7 I.5 Objectifs du processus et du systme dinformation ........................................................................ 8 I.6 Problmes........................................................................................................................................... 9 I.7 Evaluation de la faisabilit du projet ................................................................................................ 10 I.7.1 Faisabilit organisationnel..................................................................................................... 10 I.7.2 Faisabilit technique ............................................................................................................. 11
Chapitre II. DIAGNOSTIC DE LEXISTANT .................................. 12

II. 1 De la ncessit de faire une tude de lexistant ............................................................................ 12 II.2 Objectifs .......................................................................................................................................... 13 II.3 Planification de ltude de lexistant ............................................................................................... 14 II. 3. 1 Formation de lquipe ........................................................................................................ 14 II. 3. 2 Mthodes et outils de travail.............................................................................................. 14 II. 4 Fonctionnement du processus daffaire et du systme dinformation .......................................... 15 II. 4. 2 Fonctionnement ................................................................................................................. 15 II. 5 Analyse de lenvironnement........................................................................................................... 16 II. 6 Prsentation du processus (modle ANSI) ..................................................................................... 17 II. 7 Analyse causale .............................................................................................................................. 19
Table de matires
Chapitre III. MODELISATION ET CONCEPTION DU NOUVEAU SYSTEME DINFORMATION .......................................................... 20

III.1 Notions ........................................................................................................................................... 20 III.1.1 Quest ce quun modle ................................................................................................... 20 III. 1. 2 Langage UML ..................................................................................................................... 21 III. 2 Processus de spcification des besoins ......................................................................................... 22 III.2.1 Diagramme de cas dutilisation ........................................................................................... 22 III.2.2 Exemple de cas dutilisation ................................................................................................ 25 III. 3 Processus de dveloppement ....................................................................................................... 28 III.3.2 Diagramme de structure statique ....................................................................................... 32
III.3.2.1 Relations ......................................................................................................... 32 III.3.2.2 Diagramme des classes ................................................................................... 33 III.3.2.3 Domaine des constituants ............................................................................... 34
III.3.3 Diagramme de squence ..................................................................................................... 39 III.3.4 Dictionnaire de donnes ..................................................................................................... 40
Chapitre IV. REALISATION, IMPLEMENTATION ET TEST ....... 43

IV.1 Rles des membres dune quipe de ralisation dun Systme Informatique .............................. 43 IV.2 Prsentation du produit ................................................................................................................. 46 IV.2.1 Nom et caractristiques techniques ................................................................................... 46 IV.2.2 Interfaces humain-machine ................................................................................................ 46
IV.2.1.1 Splash Screen ................................................................................................ 47 IV.2.1.2 Interface didentification ............................................................................... 47 IV.2.1.3 Facturation et paiement ................................................................................. 47 IV.2.1.4 Trsorerie et dpenses .................................................................................... 48 IV.2.1.5 Historiques ..................................................................................................... 49 IV.2.1.6 Gestion des stocks (Bar) ................................................................................ 50 IV.2.1.7 Gestion des stocks (principal) ........................................................................ 51
IV.3 Environnement de travail............................................................................................................... 51 IV.4 Design ............................................................................................................................................. 52 IV.5. Encodage ....................................................................................................................................... 53 IV.6 Guide dutilisation .......................................................................................................................... 55 IV.7 Test et validation............................................................................................................................ 58 IV.8 Analyse de limpact ........................................................................................................................ 58
CONCLUSION GENERALE ............................................................. 61

I. Enjeux ................................................................................................................................................. 61 II. Le processus daffaire et le systme dinformation : deux domaines finalement indissociables ..... 61 III. Bref ................................................................................................................................................... 62 IV. Recommandations ........................................................................................................................... 62
Annexes
Annexe A11 : MOUVEMENT JOURNALIER

DATE : 1. CONTENEUR ARTICLE Afflichem blonde Affl.doubl.brun Amstel GD Amstel PT Aquavie GD Aquavie Ptte Aquavie PT Bellevue framb. Bellevue Kriek Bock Brussels fr.Beer Cava M.N.20cl Chimay Chimay Brune Chimay Trapist Chivas Coca Coca Light Codo.Sec 20cl Duvel Edge l D Fanta Citron Fanta Orange Fruitropic Fruito Maracouja Heineken GR Heineken PT Hoegaarden Jupiler Leffe Blonde Leffe Brun Mort Subit G. Mort Subit Kreik Primus Red Bull Smirnoff ICE Soda Water Sprite Tonic Tusker Q In E S QR OB 2. FRIGO HEINEKEN
ARTICLE A65 A33 BO PRI HEI.Gd HEI Pt
Q In
S QR OB
3. FRIGO AQUAVIE
ARTICLE AQ. Gde AQ. Ptte AQ. Pte 4. FRIGO EXPO
QIn
S QR
OB
ARTICLE QIn Fruitropic Fruito mara Leff Bl. Leff Br. Leff Rad Tusker Jupiler Smirnoff Red Bull Chim.Black Chim.Brune Chim.Trapist Duvel ID Edge Brussel Fr.B Hoegaarden
QR OB
Annexe A12 : BOISSON SUIVI BELVEDERE Bar
Article
S/ou Bt ou Vr
CHAUD
+ Ajoute
+ Ajoute
+ Ajoute
+ Ajoute
Perte/T
S/Total
S/Total Perte
S.Ferm
Personnel
Amstel GD
Amstel PT Aquavie Petiante
Aquavie PT
Bock Coca Coca Light Fanta Citron Fanta Orange Fruitropic Fruit maracouja Heineken GR Heineken PT Leffe Blonde Leffe Brun Primus Red Bull Sprite Tonic Tusker
Aprs Midi / Soir *
RESPONSABLE OUVERT
SIGNATURE
RESPONSABLE FERME
SIGNATURE
ANNEXES A13
ANNEXES A14
ANNEXES A15
ANNEXES A16
ANNEXES A17
Juillet 2010
MURISHI Booz A. MI. Marcellin
Cet ouvrage est une mthode de dveloppement de systmes dinformation flexibles et un outil de conception et de transformation de processus pouvant sintgrer toute stratgie daffaires lectroniques. Un cas rel (celui du Restaurant BELVEDERE) illustre les grandes activits du projet, de ltude prliminaire la ralisation technique, en passant par la conception du nouveau processus et celle du nouveau systme dinformation.
Des chercheurs qui cherchent, on en trouve mais des chercheurs qui trouvent, on en cherche Il faut chercher obtenir ce quon aime, sinon on est contraint daimer ce quon obtient

dKP9c6 1378

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

dKP9c6 1378

Transféré par

Droits d'auteur :

Formats disponibles

Bujumbura, Juillet 2010

AUTOMATISME DE FACTURATION, DE GESTION DE TRESORERIE ET DE GESTION DE STOCKS (CAS DU RESTAURANT BELVEDERE)

REPUBLIQUE DU BURUNDI UNIVERSITE LUMIERE DE BUJUMBURA

Facult dInformatique de Gestion

Travail prsent par :

AKSANTI MIRINDI Marcellin et MURISHI Booz

Ir. Hamim HAMISI

Chapitre I : Etude prliminaire

Chapitre I. ETUDE PRELIMINAIRE

Figure I.1.2-1 : Organigramme du Restaurant BELVEDERE

Chapitre I : Etude prliminaire

Chapitre I : Etude prliminaire

I. 2 Mthodologie de ltude prliminaire

I. 3 Frontire du processus daffaire, et du systme dinformation

Chapitre I : Etude prliminaire

Personnes effectuant les tches

Grante, Caissires, Serveurs, Responsables des stocks

Rapports sur ventes et approvisionnement

Tableau I.3-1 : Liste des vnements

Chapitre I : Etude prliminaire

Fournisseurs Outputs Activits

Clients Dpartements Personnes

I.4 Processus et systme dinformation de gestion, de facturation et de gestion des stocks

Chapitre I : Etude prliminaire

I.5 Objectifs du processus et du systme dinformation

Chapitre I : Etude prliminaire

Chapitre I : Etude prliminaire

I.7 Evaluation de la faisabilit du projet

Voir fiches de lannexe A11 et A12

Chapitre I : Etude prliminaire

Chapitre II. Diagnostique de lexistant

Chapitre II. DIAGNOSTIC DE LEXISTANT

II. 1 De la ncessit de faire une tude de lexistant

Chapitre II. Diagnostique de lexistant

Chapitre II. Diagnostique de lexistant

II.3 Planification de ltude de lexistant

Chapitre II. Diagnostique de lexistant

II. 4 Fonctionnement du processus daffaire et du systme dinformation

Chapitre II. Diagnostique de lexistant

II. 5 Analyse de lenvironnement

Chapitre II. Diagnostique de lexistant

II. 6 Prsentation du processus (modle ANSI)

Chapitre II. Diagnostique de lexistant

Fig. II.6-1 : Modle de processus daffaire

Chapitre II. Diagnostique de lexistant

II. 7 Analyse causale

Minimiser le nombre dactivits sans valeur ajoute.

Prsence dun grand nombre dactivits sans valeur ajoute.

Frais dexploitation immobiliss inutilement.

Systme non intgr.

Linformation produite doit tre exacte.

Il y a des erreurs frquentes de facturation.

Le client paie le prix de la surfacturation et le restaurant, le prix de la sousfacturation.

Tableau II.7-1 : Analyse causale

Chapitre III. Modlisation et conception du nouveau systme dinformation

Chapitre III. MODELISATION ET CONCEPTION DU NOUVEAU SYSTEME DINFORMATION

ftp://ftp-developpez.com/laurent-piechocki/uml/tutoriel/lp/cours/coursUml.pdf visit le 15 Fvrier 2010

Chapitre III. Modlisation et conception du nouveau systme dinformation

Chapitre III. Modlisation et conception du nouveau systme dinformation

III. 2 Processus de spcification des besoins

Chapitre III. Modlisation et conception du nouveau systme dinformation

Chapitre III. Modlisation et conception du nouveau systme dinformation

Imprimer facture Caissire