Universit de la Mannouba

Ecole Suprieure de Commerce de Tunis

MEMOIRE DE FIN D'ETUDES

Prsent en vue de lobtention de la Matrise MIAGE Elabor par :
Agina Samy Boussen Mohamed Ali

Suje t
Gestion de Parc Informatique
Prpar au sein de lENTREPRISE S.A.M.I

Encadr par : Mme. Chiraz Latiri Cherif (ESC) Mr. Sami Cherif ( S.A.M.I) Anne Universitaire : 2004-2005

REMERCIMENT S

Nous ddions ce travail : Nos familles Nos enseignants Nos ami(e) s Et vous

Remerciements
En tout premier lieu, nous remercions infiniment Madame latiri Chiraz davoir accepte de devenir notre tuteur aprs nous avoir enseign tout au long de notre formation en MIAGE . Sans ses conseils, ce mmoire naurait pas vu le jour sous cet angle. Dune rare gentillesse et dune extrme disponibilit reconnues par toutes et tous, Madame Latiri Chiraz nous a joyeusement aiguille sur le projet traiter. Inlassablement, tout au long de notre stage au sein de la socit S.A.M.I, Monsieur Cherif Sami a pris le temps de rpondre, humblement et avec humour incomparable nos questions. Nous tions trs touchs de lintrt que Monsieur Hanini Yessin a eu pour notre projet en nous donnant son point de vue de dveloppeur. Enfin, noublions pas notre fidle designer Agina Zied pour ses marques artistiques.

SOMMAIR E
Chapitre1 : Cadre gnral et tude de faisabilit 1

I. Prsentation du projet. II. Positionnement du projet dans S.A.M.I2 III. Objectifs et fonctionnalits attendus du systme EasyGPI..3 IV. Cycle de dveloppement logiciel retenu. V. Etude de la faisabilit technique..4 1. Etude de lexistant informatique 2. Procdure de travail. 3. Critique de lexistant. VI. Etude de la faisabilit conomique. .5 4. Etablissement dun calendrier de travail. 5. Dtermination du budget ncessaire. 6. Rentabilit. Chapitre 2 : Spcification des Besoins et Cahiers de Charges I. Champ dtude et MCF II. Dfinition des besoins..7 1. Besoins fonctionnels. 2. Besoins non fonctionnels.8 1.1 Scurit dutilisation. 1.2 Scurit de fonctionnement. 3. Evolution du systme. 3.1 Evolution matrielle. 3.2 Evolution fonctionnelle. 3.3 Maintenance volutive. III. Spcification Semi formelle : Diagramme de USE CASE.10 Chapitre 3 : Conception du systme EasyGPI I. Etapes de conception du systme. II. Conception globale.12 1. Diagramme de Composant. 11 6

III. Conception dtaill. ...13 1. Modlisation des Donnes. 1.1 Modle conceptuel de donnes. 1.2 Modle relationnel de donnes...14 1.2.1. Listes des tables...15 2. Modlisation des Traitements. 2.1 Modle conceptuel de traitement : MCT.. 25 2.2 Modle organisationnel de traitement : MOT.29 2.3 Modle logique de traitement : MLT30 Chapitre 4 : Ralisation du systme EasyGPI 37

I. Cycle de vie : prototypage. 7. Dfinition. 8. Cycle de vie dun prototype. 9. Objectifs du prototypage. II. Prototype initial du systme EasyGPI......38 1. MCD du prototype initial du systme EasyGPI. 39 2. Quelques interfaces du prototype initial........40 III. Modle physique de donnes : MPD...41 IV. Modle physique de traitement : MPT 42 Chapitre 5 : Tests et Intgration du systme EasyGPI I. Introduction. 1. Tests unitaires 2. Tests dintgrits. 3. Tests dacceptation. 4. Jeux de tests. 5.1 Exemples de jeux de tests et capture dcran.........45 II. Conclusion Gnrale..63 Bibliographie 64 44

PFE - MIAGE 2004/2005

Chapitre 1

Cadre Gnral et Etude de Faisabilit du systme EasyGPI

I. Prsentation du projet :
La prsentation de notre Projet de fin dtude consiste la conception et au dveloppement dun logiciel de gestion du parc informatique (GPI). Notre stage sest droul au sein de la socit La Socit des Ateliers Mcanique et Industriels S.A.M.I qui a t fonde en 1976. Elle fait partie dun groupe de socits oprantes dans le domaine de lindustrie tels que la mcanique et les composants automobiles ainsi que dans le domaine de distribution des pices de rechange. S.A.M.I se spcialise dans la fabrication et le montage des cycles et des motocycles. Son savoir-faire et sa matrise du processus, lui ont permis dexporter ses produits sur le march europen. Larchitecture technique est compose dune vingtaine dordinateurs et imprimantes, un ordinateur portable et deux serveurs interconnects par un rseau local de type Ethernet. Larchitecture applicative (Logiciels) sest dote dune informatique de gestion qui sest construite progressivement et diffrents degrs dune fonction lautre depuis plusieurs annes, principalement par des dveloppements raliss par une socit de service tablie en Tunisie. Actuellement, la socit est en cours dimplantation dun systme de gestion intgre de type ERP qui va lui permettre de rpondre aux nouveaux besoins exprims en terme de fonctionnalits ncessaires au traitement efficace de linformation.

II. Positionnement du projet dans S.A.M.I :

Intgration du systme EASY GPI au sein du schma directeur de la socit S.A.M.I : La direction gnrale de la socit S.A.M.I (voir figure1) se dcompose en quatre dpartements fondamentaux : production, Vente, Achat, Administration et informatique ou se focalise notre application EasyGPI. 1

PFE - MIAGE 2004/2005

PDG

Direction Gnrale

Informatique

Administration

Achat

Vente

Production

Comptabilit

Finance

Ressources humaines

Achat Locale

Import/ Export

Marketing

Commerciale

EASY GPI

Atelier

Maintenance

Stock

Bureau dtude

Figure1 : schma directeur correspondant la socit S.A.M.I

III. Objectifs et fonctionnalits attendus du systme EasyGPI :

Lobjectif de llaboration de ce logiciel est de faciliter et dautomatiser la gestion du parc informatique de la socit S.A.M.I ; il assurera : La saisie, le stockage et le classement sur une base de donne ACCESS 2000 des fiches techniques, bons de rparation et des fiches de maintenance. la consultation, la mise jours et limpression de diffrents tats grs via une interface ergonomique.

IV. Cycle de dveloppement logiciel retenu :

Etant donne que EasyGPI est une application logicielle, nous avons opt pour le cycle de dveloppement de MERISE qui sarticule autour de ces tapes : Le schma directeur : il permet de relier la stratgie et les besoins en systmes dinformation et didentifier des domaines de gestion (exemple : achat, tude, etc.) et des finalits. Ltude pralable : il sagit dune reprise par domaine du schma directeur et dune tude plus 2

PFE - MIAGE 2004/2005 approfondie des projets. Elle doit

tre courte dans le temps mais complte avec proposition de solution en vue du choix. Cette tude dbute par lanalyse de la situation existante et permet de proposer une architecture globale de la solution, en tenant compte des orientations de gestion, dorganisation et de choix techniques valids par le comit directeur du projet. Ltude dtaille : Elle est mene aprs ltude pralable et a pour objectif de dcrire compltement, au plan fonctionnel, la solution raliser. Les phases de traitement sont spcifies en dcrivant les donnes saisies, modifies et restitues ainsi que la description des traitements excuts sur ces donnes. Elle comprend deux phases :
- La conception gnrale

La conception dtaille, et se conclue par le dossier de spcifications dtailles.

-

La ralisation : Elle englobe une tude technique donnant une description logique et physique de lorganisation des donnes ainsi quune description de larchitecture des traitements. Son but est dobtenir les logiciels correspondant au dossier des spcifications dtailles. Cette tape est elle- mme dcompose en deux phases : - Ltude technique qui complte ltude dtaille par la prise en compte de tout lenvironnement technique informatique - La production de logiciel, qui permet dobtenir le logiciel test sur un jeu dessai La mise en uvre : son but est dexcuter toutes les actions (formation, documentation, installation de matriel, etc.) qui permettront daboutir au lancement du systme auprs des utilisateurs : ; La ralisation et linitialisation des bases de donnes La rception et linstallation de ressources ;

- La production de la documentation utilisateur ; La maintenance : Elle consiste faire vivre les applications.La diminution des cots de maintenance est trs lie la qualit des tapes prcdentes.

V. Etude de Faisabilit Technique :

1. Etude de lexistant informatique : Daprs notre analyse de lexistant de la socit S.A.M.I , nous avons remarqu quil existe une vingtaine de postes, une dizaine de personnels, un rseau local(quelques postes en font partie) et une implmentation en cours dun ERP.

2. Procdure de travail : La procdure manuelle de la maintenance du parc informatique au sein de S.A.M.I se droule comme suit :
a. Consultation dune fiche :

Une simple consultation dune fiche technique dun quipement ou la fiche prventive de maintenance demande au concern une fouille dans tout le classeur des fiches qui sont dans la majorit des cas en dsordre.
b. Mise jours dune fiche :

Ceci seffectue en consultant la fiche technique approprie et procder sa mise a jours (logiciels par exemples).
c. Ajout dune fiche :

Aprs lacquisition dun nouvel quipement, ladministrateur procde llaboration de sa fiche technique ainsi qu la mise jours de la fiche de maintenance prventive (faire figurer le matricule du nouvel quipement).
d. Suppression dune fiche :

Suppression dun quipement : supprimer du classeur la fiche de cet quipement ainsi que son matricule de la fiche prventive de maintenance .
e. Grer la demande de rparation : Si lutilisateur passe

un avis de rparation alors Le responsable consulte rparer sa ainsi fiche que technique les vrifie la garantie dernires rparations et

de lquipement effectues.

Si la garantie est encore valable alors Le responsable contacte son fournisseur sinon Le responsable contacte un intervenant.
sur lquipement : Aprs lexamen de la fiche technique de lquipement ainsi que de la fiche de maintenance, le technicien procde la rparation et mentionne les dtails de la rparation dans un bon de rparation. f. Intervention g. Evaluation du travail et payement :

Aprs rparation de lquipement, lvaluation du travail seffectue selon le rapport qualit/prix et la dure de rparation ; sils sont raisonnables alors lordre de paiement est accord sinon le montant sera ngoci.

h. Mise jour la fiche technique de lquipement en question : Rajouter la fiche technique les nouvelles

rparations ainsi que le nom de lintervenant, la date de rparation et le montant. 3. Critique de lexistant : La principale remarque quil faut faire, cest que le travail au sein de la socit S.A.M.I se base sur lutilisation dune masse de fichiers pour mener toutes les

taches relatives la gestion de son parc informatique. De mme, chaque fois que lutilisateur ou le technicien a besoin dune information, il est appel revoir aux classeurs de maintenance en effectuant des recherches lentes et parfois linformation trouve ne reflte pas la ralit. De mme ; compte tenu du volume assez important des donnes ; il savre trs difficile dappliquer manuellement certaines formules statistiques sur celle-ci.

VI. Etude de Economique :

la

Faisabilit

1. Etablissement dun calendrier de travail : La conception et la mise en place du logiciel EasyGPI peuvent tre planifies selon le calendrier suivant rparti sur 12 semaines Dure de ralisation de la phase tude des besoins : 1semaine Dure de ralisation de la phase analyse : 1 semaine Dure de ralisation de la phase conception : 3 semaines Dure de ralisation de la phase implmentation : 5 semaines Dure de ralisation de la phase test : 2 semaines 2. Dtermination du budget ncessaire : Il est recommand de prvoir une formation pour les utilisateurs sur site ainsi que la mise la leur disposition dun manuel dutilisation. Notre projet ne ncessite pas informatiques supplmentaires. 3. Rentabilit : La rentabilit du projet peut tre apprcie dans les apports suivants : - Minimum de papiers (Les documents lgaux doivent tre imprims) - Zro Erreurs - Zro Cots - Facilit de maintenance - Gain de temps - Scurit des donnes. Conclusion : Aprs avoir introduit le cadre gnral de notre travail et dcrit lacquisition dquipements

lexistant ainsi que la procdure de maintenance, nous passons dans le chapitre suivant la spcification des besoins et llaboration du cahier des charges du systme EasyGPI.

Chapitre 2

Spcification des Cahier Charges

Introduction

Besoins et des

Dans ce chapitre, nous allons dfinir les besoins utilisateurs de ce que notre systme EasyGPI devrait satisfaire travers une modlisation des flux et une tude dtaille des fonctionnalits requises.

I. Champs dtude et MCF :

Afin de dlimiter les champs dtude relatifs au systme EasyGPI, nous allons laborer le MCF qui est une reprsentation de lchange dinformations entre deux activits ou entre une activit et un partenaire extrieur lentreprise. Cest une reprsentation graphique des acteurs et des flux. Il est gnralement considr comme la premire tape de lanalyse dun systme. En effet, notre tude de lexistant de la maintenance du parc informatique de la socit de S.A.M.I nous a permis de dgager le MCF dtaill (pas dacteurs mais seulement les flux) dcrit dans la figure 2.
AJOU TER N OU VE L L ES R E P AR ATION S R EPAR ER EQU IPEMEN T

METTR E A J OU RS LA F I C HE TEC H N IQU E

TR AV A IL EF F EC TU E ET L E MONTAN T D EC R IR E U N D IAGN OSTI C

R ED IG E R U N B ON D E R EPAR ATION

D EMAN D E D E R E P AR ATION

C ON SUL TER S O N F OUR N I SSEU R

EQU IPEMEN T EN MAR C H E EQU IPEMEN T D EF IC IEN T

EQU IPEMEN T EN C OR E EN PAN N E PR OC ED ER A L A R EPAR ATIO N

EQU IPEMEN T EN C OR E EN GARAN TIE

G E R ER D EMAN D E

EVAL U ER L A R EPAR ATION ET PAYER

EQU IPEMEN T H OR S GAR AN TIE

C ON SUL TER U N TECH N I C IEN

EXAMI NER L ES F I C H ES

EXAMI NER L ' EQU I PEMEN T

Figure2 : Etude de contexte : MCF dtaill

II. Dfinition des Besoins :

Les besoins sont classs selon deux types : 1. Besoins Fonctionnels : La dfinition des besoins est considre selon deux points de vues savoir : Du point de vue administrateur : Apres stre connect sur la base au moyen de son nom dutilisateur et de son mot de passe ladministrateur consulte cette dernire pour : Voir sil y a des travaux prventifs de maintenance effectuer. Rdiger un avis de rparation. Mettre jours la fiche technique de lquipement dficient. Ajouter, retirer ou modifier un quipement ainsi que la fiche technique lui incombant et ses travaux de maintenance prventive. Pour ajouter une composante, ladministrateur saisit tous les champs concernant cette dernire. Ces donnes seront par la suite sauvegardes dans la base des fiches. Imprimer un bon de rparation. Evaluer les travaux de rparation effectus sur lquipement en fonction de la qualit de rparation et la dure totale mise pour la rparation. Elaborer des statistiques et des tats (si besoin est) pour le compte dun suivi permanent du parc informatique (par exemple faire une statistique annuelle du nombre de pannes par machine). Du point de vue technicien : Lintervenant effectue un diagnostic de lquipement et rdige un devis de rparation qui sera par la suite livr lutilisateur pour le signer si le montant demand appartient la fourchette de prix fixe par ladministration sinon il sera sign par ladministrateur lui-mme. Lintervenant consulte la base travers son identifiant unique. Lintervenant saisit le matricule de lquipement dficient. Lintervenant consulte les informations (fiche technique et fiche de maintenance) de cette dernire tout comme sa date dacquisition, les ventuelles rparations dj effectues

etc. Aprs rparation, et si ladministration lui accorde les droits ncessaires pour la mise jours, le technicien procde une mise jours des fiches, il remplit les champs du bon de rparation spcifique cet quipement ainsi que le montant et une description de la rparation effectue, sinon ce travail revient ladministrateur.

 Le technicien peut lui-mme procder limpression du bon et le signe. 2. Besoins Non Fonctionnels :
2.1. Scurit dutilisation :

Le systme ne peut tre utilis quau travers dun mot de passe et un identifiant. Les droits daccs (simple consultation ou mise jours) diffrent selon la nature des privilges accords par ladministrateur.
2.2. Scurit de fonctionnement

Sauvegarde priodique de la base

Les composants matriels du systme sur lequel tourne EASY GPI doivent faire lobjet dune maintenance priodique. 3. Evolution du Systme : On note deux types dvolutions :
3.1. Evolution matrielle:

Le systme doit satisfaire les besoins de lutilisateur quelle que soit lvolution matrielle.
3.2. Evolution fonctionnelle :

- Il serait judicieux de globaliser le cadre de fonctionnement du logiciel EasyGPI et de ne pas le limiter aux composantes traditionnelles du parc informatique. On pourrait ainsi rpertorier toutes sortes dquipements appartenant ou non au systme dinformation de lentreprise (Photocopieur, voitures etc.). - On envisagera de basculer la base en rseau local (Architecture client serveur).
4. Maintenance volutive :

On distingue trois sortes de maintenance : Corrective : qui traite les dfaillances des programmes ; Adaptative : faire adapter le logiciel des changements matriels et logiciels ; Perfective : qui amliore la performance du systme.

III. Spcification semi-formelle : Diagramme global de Use Case

Il existe plusieurs formes de spcifications citer la spcification formelle (spcification algbrique, LOTOS, VDH) et la spcification semi-formelle (mthode SADT, mthode graphique).

Nous avons adopt pour la spcification de notre systme une spcification semi- formelle via le diagramme de cas dutilisation puisquil montre dune manire

expressive les diffrentes fonctionnalits du systme et leur relations avec les principaux acteurs, i.e. les futurs utilisateurs. Les lments de base dun USE CASE sont : Acteur : cest une personne ou une chose qui va interagir avec le systme en cours de dveloppement. Pour notre systme EasyGPI, nous allons dfinir trois acteurs : lutilisateur, ladministrateur et le technicien. Use case : cest un ensemble dactions ralis par le systme, en rponse une action dun acteur. Le diagramme global de cas dutilisation est illustr dans la figure 3. Conclusion : Aprs avoir laborer le cahier de charges su systme EasyGPI, nous passons la prsentation de la conception dtaille et la conception globale du systme EasyGPI.

UTILISATEUR

PRE-REDIGER UN BON DE REPARATION

SIMPLE CONSULTATION DES FICHES GERER DEMANDES DE REPARATION

MISE A JOURS DES FICHES

ADMINISTRATEU R

AJOUT DE FICHES CONSULTER LA BASE

Le devis sera sign par l'utilisateur si le montant du devis appartient la fourchette de prix convenue sinon l'accord de l'administrateur sera ncessaire

SUPPRESSION DE FICHES

CONTACTER UN INTERVENANT

ELABORATION D'ETATS

REINITIALISER LA BASE

Examine la fiche technique et celle de la maintenan ce

CONSULTER LE BON

EVALUER ET SIGNER LE BON

EXAMINER L'EQUIPEMENT DEFAILLANT ET SA FICHE

PASSER UN DEVIS DE REPARATION

TECHNICIEN Une fois le bon est rempli, il sera livr l'administrateur pour la mise jours de la base PROCEDER A LA REPARATION DEFINIR LA DUREE DE REPARATION

MONTANT DE REPARATION

TRAVAIL EFFECTUE REDIGER UN BON DE REPARTION

DATE DE REPARATION

TYPE DE

REPARATION

Figure3 : Diagramme de cas dutilisation du systme EasyGPI

Chapitre 3

Conception du Systme EasyGPI

Introduction
Dans ce chapitre, nous allons commencer tablir la conception de notre systme EasyGPI qui se subdivise en une conception globale et une dtaille afin de faciliter la communication entre concepteurs ainsi quamliorer la qualit et la productivit logicielle.

I. Etape de conception du systme EasyGPI

La conception est un processus cratif qui ncessite le savoir-faire et lexprience de linformation. La conception dtermine la faon dont le logiciel fournit les diffrentes fonctionnalits recherches : La Conception Globale : Elle couvre une conception architecturale (structure du systme) et une conception des interfaces Conception dtaille : Elle sert dterminer les algorithmes pour les diffrentes parties du systme. Nous avons pour cela utilis la mthode MERISE (Mthode dEtude et de Ralisation Informatique pour les Systmes dEntreprise) dont elle date des annes 80(1978-1979) et fait suite une consultation nationale lance en 1977 par le ministre de lindustrie dans le but de choisir des socits de conseils en informatique afin de dfinir une mthode de conception de systme dinformation. Les deux principales socits ayant mis au point cette mthode sont le CTI (Centre Technique dInformatique) charg de grer le projet, et le CETE (Centre dEtude Techniques de lEquipement) implant Aix-en-provence. La vocation de MERISE est double : dune part MERISE reprsente une mthode (Autrement dit lintelligence ruse par laquelle se construit un chemin ) de conception du systme dinformation (SI) et dautre part MERISE propose une dmarche mthodologique de dveloppement de SI. La mthode MERISE fait partie des mthodes systmiques. Elle utilise

le modle tridimensionnel comme cycle de dveloppement (cycle de vie, cycle de dcision, cycle dabstraction).

La modlisation dun systme dinformation par la mthode MERISE se fait selon deux axes : Modlisation des donnes Modlisation des traitements

La modlisation dans MERISE consiste reprsenter le systme selon quatre niveaux dabstraction : a) Niveau conceptuel : Reprsente la finalit du systme en sappuyant sur ses objets et ses aspects invariants indpendamment de la manire dont ils seront raliss (LE QUOI). Le niveau conceptuel est le niveau dabstraction le plus lev. Il comprend les lments les plus stables en dcrivant les classes dobjets et les rgles significatives en fonction des objets fixs par les dcideurs. b) Niveau organisationnel : Il dfinit lorganisation que lon doit mettre en place pour atteindre les objectifs dcrits au niveau conceptuel : ce sont les ressources utilises pour supporter les descriptions du niveau conceptuel : (LE QUI, LE OU et LE QUAND). c) Niveau physique ou oprationnel : Ce niveau dcrit limplmentation du systme dinformation en tenant compte des choix techniques arrts : cest la reprsentation physique des donnes et oprationnelle des traitements en tenant compte des contraintes et des choix de ralisation. d) Niveau logique : Ce niveau exprime la forme que doit prendre loutil informatique pour tre adapt lutilisateur, son poste de travail indpendamment de linformatique spcifie, des langages de programmation ou de gestion des donnes. Il dcrit essentiellement le schma de la base de donne.

II. Conception globale :

1. Diagramme de composants : Afin de prsenter larchitecture globale du systme EasyGPI, nous utilisons le diagramme de composants, emprunt dUML (Unified Modeling Langage) qui illustre lorganisation des composants logiciels et leurs dpendances (aspect physique).
Un aspect peut tre : Un code source, un composant ncessaire

lexcution ou un programme.

E d i ti o n C o n su l ta t i o n

A j out

I n te r f a c e d e c o n n e x i o n l a b a s e E a sy G P I

N e tt o y a g e d e l a b a se

L a B a se d e d o n n e s E a sy G P I S u p p r e ssi o n d 'u n c h a m p

M a i n te n a n c e

Figure 4: Diagramme de composant

III. Conception dtaille :

Cette conception va couvrir les trois niveaux dabstraction de MERISE savoir le niveau conceptuel, le niveau organisationnel et le niveau logique en considrant les donnes et les traitements. 1. Modlisation des Donnes : Cette modlisation va couvrir le niveau conceptuel et relationnel moyennant un MCD et un MRD.
1.1. Modle conceptuel de donnes : MCD

A travers lanalyse de lexistant et la comprhension du systme du parc informatique de la socit S.A.M.I, nous avons pu dgager un MCD qui permet deffectuer une reprsentation graphique ou conceptuelle de lensemble de donnes et de relations manipules. Il dcrit la smantique des donnes indpendamment de leur utilisation et leur implmentation. Cest en fait la description la plus stable du systme dont le formalisme se base sur le modle ENTITE/RELATION.

Nous dfinissons dans ce qui suit les concepts cls :

Proprit (attributs) : cest un atome smantique lmentaire reprsentant la plus petite information manipule (exemple : matricule _machine, nom_machine, numro_ srie_machine) Entit (objet) : cest une association de proprits correspondant un type dobjet (quipement, composante). Association (relation) : reprsente les liens entre deux ou plusieurs entits (correspondre, remplir) Identifiant ou cl : un identifiant permet de connatre sans ambigut toutes les occurrences des autres proprits. Cardinalits : reprsente pour chaque couple (entit, association) les nombres minimum et maximum doccurrence de lassociation que peut avoir un objet. A titre dexemple, lquipement comprend une ou plusieurs composantes. Les cardinalits traduisent les rgles de gestion. Les seules valeurs possibles sont (0-1), (0-n), (1-1), (1-n). La dmarche suivie pour la construction du MCD est base sur une approche formelle qui consiste suivre une dmarche rigoureuse dont voici les tapes : 1. Etablir une liste de proprits : cest le dictionnaire de donnes qui regroupe tous les types de donnes ayant une existence physique et caractrisant tous les objets existants dans le domaine dtude. 2. Trier les lments de la liste par ordre alphabtique. 3. Eliminer les redondances, les synonymes et les polysmies. 4. Dterminer les entits cls du systme informatiser. 5. Rattacher les proprits leurs entits fonctionnelle avec leurs identifiants. 6. Placer les associations et leurs rattacher dpendance fonctionnelle avec leurs identifiants. en dpendance les proprits en

7. Revoir les proprits restantes fin de les regrouper dans des entits pour lesquelles seront cre de nouveaux identifiants. 8. Dterminer les cardinalits en utilisant les rgles de gestion. 9. Valider le modle avec certaines rgles.

En suivant cette dmarche nous avons labor notre MCD final du systme EasyGPI qui est illustr par la figure 5.

TYPE_REPARAT TIO N
ty pe_rep a

BON DE REPARATION
num bon mont ant_re parat 1,1 ion duree _repa diagn os t ic taf rep dat e panne dat e repa 1,1

REMPLIR SIGNER

TECHNICIEN
1,n matricule _tech nic ien nom_ t ec hnicien tel_tec h f ax_t ec h 1,n

APPARTENIR

1,1

1,n

1,1

INTERVENAN T matricule _interv

tel_interv f ax_int erv

CORRESPOND R E

CORRESPOND R E
date_r ep

CORESPONDR E
1,1

FICHE TECHNIQUE
numero f iche_tech caracteris t iques_t ech

UTILISATEU R matricule _use r

nom_ use r section_user numero_pos te_us er mot de pas s e droit 1,1 0,n 0,n 0,n

DEMANDER REP

EQUIPEME NTnum_s
erie_mac h matricule mac h des cription mac h garantie_ mac h c at eg orie_mac h dat e_ acquis _mach os_mach adres s e ip_mac h ty p_m ac h 1,n

1,n

CONCERNER

C ALENDRIER_MAINT
dat e_main t 0,1 t_ a_f

0,n

1,1

DESIGNER
0,n 0,n 1,1

DECRIRE
date panne

0,n

FA CTURE_MACHINE
numero _f act_mac h

COR RE SPONDRE

APPARTENI R GERER

LIVRER_MACHIN E

mont ant_f ac t_mac h

1,1

REDIGER

1,1

MARQUE
nom_marque

0,n

0,n

0,n 0,n 1,1

COMPOSANT E
c ode _c o m p Libelle

C ATEGORI E
c od e_c Libelle cnx num_ c sf ormat

1,n

SOUS C ATEGORIE
c od e_s c libelle _s c

FOURNISSEUR_MACHINE
matricule_f eur_m ach nom_f eur_mac h tel_f eur_mac h f ax _f eur_mac h

Figure 5 : MCD du systme EasyGPI

1.2. Modle relationnel de donnes : MRD Aprs la finalisation du MCD correspondant, nous passons llaboration du MRD qui constitue une intermdiaire entre le modle conceptuel et le modle physique de donnes. Cest le MCD auquel on rajoute la dfinition de lorganisation logique des donnes et en loptimisant compte tenu des traitements appliqus aux donnes.

A ce niveau on doit choisir le modle dorganisation des donnes : cest le modle RELATIONNEL le plus efficace et le plus utilis pour une bonne reprsentation des donnes. Il existe cependant les modles hirarchiques, rseau et la reprsentation classique des donnes par les fichiers.

Ce modle se repose sur les concepts structurels suivants : A un Domaine correspondent des Attributs A une Relation correspond un Schma dune relation A un Tuples correspond une Cl primaire A une Cl trangre correspond une Cl trangre Formes normales

Ainsi nous dfinissons les rgles de passage dun MCD un MLD relationnel : REGLE 1 : Une Entit se transforme en une Relation Une Proprit se transforme en Attributs Un Identifiant se transforme en une Cl primaire

REGLE 2 : Une association binaire ayant des cardinalits (1_1)-(1, n) ou (1,1)-(0, n) se traduit par : La migration de lidentifiant de lentit ayant la cardinalit (1,1). Cet identifiant devient une cl trangre. rflexive, lidentifiant est

Dans le cas dassociation dupliqu puis renomm.

La migration des proprits de lassociation (sil y en a) vers lentit de cardinalit (1,1). REGLE 3 : Une association n-aire porteuse ou non de proprits se transforme en une relation ayant comme identifiant la composition de lensemble des identifiants de la collection. Une association binaire de cardinalit (0.1)-(1.n) se traduit selon la rgle 2 ou 3. REGLE 4 : Une association rflexive, si elle ne rpond pas aux conditions de la rgle 2 se traduit par une association porteuse de deux attributs correspondant lidentifiant renomm de lentit .Ces attributs deviennent la cl de la relation.

A partir du MCD illustr dans la figure4 et en appliquant les rgles de passage dclares ci dessus, nous recensons les tables relationnelles suivantes. Notons que certaines tables sont sacrifies pour les besoins dimplmentations. (mat_mach, num_seri_mach, os_mach, garanti_mach, dat_acquis_mach, typ_mach, nom_mach, #code_c, adress_ip_mach, masq_mach,emplacement_mach num_fact_mach, mont_fact, dat_fact_mach, #marque_mach, , #mat_feur_mach ) COMPOSANTE ( N, #mat_mach, #code-ec, libelle_sc, libelle_comp) TMPCOMP (N, #mat_mach, #code-c, libelle_sc, libelle_comp) MARQUE(marq_mach) CATEGORIE (code_c, libelle, os, cnx, num, sformat) SOUS CATEGORIE (code_sc, libelle_sc, #code_c) TECHNICIEN (matricule_technicien, nom_tech, tel_tech, fax_tech, adress_tech) INTERVENANT(matricule_interv, tel_interv, fax_interv, adress_interv) UTILISATEUR (matricule_user, nom_user, section_user, poste_user, tel_user, #num_seri_mach,) FOURNISSEUR_MACHINE fax_feur_mach) BON REPARATION (num_bon, mont_bon, dat_pan, dat_rep, diagnostic, taf_rep, # typ_repa, #mat_tech, #mat_mach, #mat_interv, #mat_user) (matricule_feur_mach, nom_feur_mach, EQUIPEMENT

tel_feur_mach,

TYPE

REPARATION dure_rep,

(num_type_rep, typ_rep, diagnostic, travail_effectu)

FACTURE_MACHINE (numro_fact_mach, montant_fact_mach, dat_fact_mach, #num_seri_comp, #matricule_feur_mach) DECRIRE (matricule_user, num_serie_mach, num_panne,date_panne) DEM_REP(matricule_user, num_serie_machine) La liste et la description dtaille des diffrentes tables sont donnes ci dessous :

Nom Equipement composante calendrier_ maintenance intervenant utilisateur bon_rparation panne type_reparation Fournisseur_machine Catgorie Sous Catgorie Tmpcomposante Paramtre

Code MACH COMP CALEND_MAINT INTERV USER BON_REP PANNE TYP_REP FEUR_MACH CAT SCAT TMPCOMP PARA

Description de la Table Equipement Nom Origine . Nom de colonne Matricule_machine Description_machine Garantit_machine Numero_serie_machine Date_acquisition_machi ne Marque_machine Date_maintenance Code Matricul_mach Desc_mach Garanti_mach Num_seri_mach Dat_acquis_mac h Marq_mach Dat_maint Type Texte (30) Texte (30) Texte (30) Texte (30) Date Texte (30) Date P 0 O 0 0 0 0 0 0 0 : Equipement : Entit MACH

Description de la Table Composante Nom Origine : composante : Entit COMP

Nom de colonne Numero_serie_comp Matricule_comp Date acquisition Garantie_composante Numero_serie_machi ne Matricule_feur

Code Num_seri_comp Matricul_comp Dat-acquis Garant_comp Num_seri_mach Mat_feur

Type Integer Integer Date Texte (20) Texte (20) Texte (30)

P 0 0

O 0 0 0 0 0 0

Description de la Table Catgorie Nom Origine : Catgorie : Entit CAT

Nom de colonne Numero_fiche_tech caracteristique Numero_serie_machi ne

Code Num_fich_tech Caract Num_seri_mach

Type Integer Texte (30) Texte (30)

P 0

O 0 0 0

Description de la Table Sous Catgorie Nom Origine : Sous Catgorie : Entit SCAT

Nom de colonne Code categorieo Libelle_sc Code_c sous

Code Code_sc Libelle_sc Code_c

Type Texte (25) Texte (35) Texte (25)

P 0 0

O 0 0 0

Description de la Table Technicien Nom Origine : technicien : Entit TECH

Nom de colonne Matricule_technicie n Nom_technicien

Code Mat_technicien Nom_technicien

Type Integer Memo

P 0

O 0 0

Tel_technicien Fax_technicien

Tel_technicien Fax technicien

Integer Integer

0 0

Description de la Table Intervenant Nom Origine : intervenant : Entit INTERV

Nom de colonne Matricule_intervena nt Tel_intervenant Fax_intervenant Adresse_intervenant

Code Mat_interv tel_interv fax_interv adress_interv

Type Texte (35) Integer Integer Texte (35)

P 0 0 0 0

O 0 0 0 0

Description de la Table Utilisateur Nom Origine : utilisateur : Entit USER

Nom de colonne Matricule_user Nom_user Poste_user Departement_user Tel_user Droit_user Password

Code Mat_user Nom_user Poste_user depart_user Tel_user Droit_user password

Type Texte (30) memo Texte (30) Texte (30) Integer Texte (20) Texte (20)

P 0

O 0 0 0 0 0 0 0

Login Numero_serie_machi ne

login Num_seri_mach

Texte (20) Integer

0 0

Description de la Table Fournisseur_Machine Nom Origine : fournisseur_machine : Entit FEUR_MACH

Nom de colonne Matricule_feur_machi ne Nom_feur_machine Tel_feur_machine Fax_feur_machine

Code Mat_feur_mach Nom_feur_mach Tel_feur_mach Fax_feur_mach

Type Integer Memo Integer Integer

P 0

O 0 0 0 0

Description de la Table Tmp composante Nom Origine : Tmp composante : Entit TMP_COMP

Nom de colonne Matricule_feur_composan te Nom_feur_composante Tel_feur_composante Fax_feur_composante

Code Mat_feur_comp Nom_feur_comp Tel_feur_comp Fax_feur_comp

Type Integer Memo Integer Integer

P 0

O 0 0 0 0

Description de la Table Bon_rparation Nom Origine : bon_reparation : Entit BON_REP

Nom de colonne Numero_bon Montant_bon Numero_type_reparati on Matricule_technicien Matricule_intervenant Numero_serie_machine

Code Num_bon Mont_bon Num_typ_rep Mat_tech Mat_interv Num_seri_mach

Type Integer Reel Integer Texte (30) Texte (30) Texte (30)

P 0

O 0 0 0 0 0 0

Description de la Table Type_rparation Nom Origine : type_reparation : Entit TYP_REP

Nom de colonne Numero_type_reparati on Type_reparation Duree_rep diagnostic Travail_effectue

Code Num_typ_rep Typ_rep Duree_rep diagnostic taf

Type Memo Memo Real Texte (30) Texte (30)

P 0

O 0 0 0 0 0

Description de la Table Facture_Machine Nom Origine : facture_machine : Entit FACT_MACH

Nom de colonne Numero_facture_machin e Montant_facture_machin e Matricule_feur_mach Numero_serie_composan te

Code Num_fact_mach Montant_fact_mac h Mat_feur_mach Num_seri_comp

Type Integer Real Texte (30) integer

P 0

O 0 0 0 0

Description de la Table Demander Rparation Nom Origine : demander reparation : ASSOC DEM_REP

Nom de colonne Matricule_user Numero_serie_machi ne

Code Mat_user Num_seri_mach

Type Texte (30) Texte (30)

P 0 0

O 0 0

Description de la Table Dcrire Nom Origine : decrire : ASSOC DECRIRE

Nom de colonne Numero_serie_machi ne Matricule_user Numero_panne

Code Num_seri_mach Mat_user Num_pann

Type Integer Texte (30) Texte (30)

P 0 0

O 0 0 0

Date_panne

Dat_pann

Date

Description de la Table Marque Nom Origine : marque : Entit MARQUE

Nom de colonne Nom_maque

Code Nom_marq

Type Texte (50)

P 0

O 0

Nous passons dans ce qui suit la modlisation des traitements. 2. Modlisation des Traitements : Elle couvre aussi bien la modlisation organisationnelle. modlisation conceptuelle que la

2.1. Modle conceptuel de traitement : MCT Le MCT reprsente formellement les activits exerces par un domaine. Il repose sur la prise en compte des changes (flux) du domaine avec son environnement indpendamment de leurs organisations. Il donne une reprsentation dynamique des activits c'est--dire dterminer le QUOI sans se soucier du QUI ni du COMMENT. Les concepts cls du MCT sont : Evnement : Cest la reprsentation dun fait nouveau porteur dinformation pour le systme tudi. Exemple : demande de rparation, demande de devis Opration : Raction du service sous forme de traitement larrive dun seul ou dun ensemble dvnements. Exemple : mise jours des fiches, ajout de fiche technique ou de maintenance

 Synchronisation : Cest une expression boolenne forme partir des oprateurs logiques ET et OU qui permet lassociation de deux ou plusieurs vnements pour le dclanchement dune opration. Rsultat : vnements Cest la rponse du systme ayant dclanchs une opration. aux

Processus : Cest un enchanement synchronis doprations reprsentant une unit homogne de traitement. Exemple : processus de gestion des statistiques. Le formalisme qui dcrit le MCT est illustr dans la figure 6.

Figure 6 : Formalisme dun MCT

Le MCT relatif au systme EasyGPI est illustr dans la figure 7. Il englobe les processus suivant : Grer les droits daccs. Grer les bons de rparation. Grer les fiches des quipements(fiche technique et celle de maintenance).

panne d'une machine GERER PANNE EQUIPEMENT REPAREE

AVIS DE REPARATION REDIGER LE BON DE PEPARATION2

GERER DEMANDE touj ours TYPE DE REPARATION DECRIT MONTANT DETERMINEE DUREE DE REPARATION MENTIONNEE

DEMANDE ACCEPTEE

IMPRIMER ET SIGNER LE BON SAISIR MOT DE PASSE SI NOT OK SI OK

BON SIGNE'

EVALUER LE BON MOT DE PASSE INCORRECT MOT DE PASSE CORRECT si ok si not ok

BON SIGNE

BON NON SIGNE

CONSULTER SA FICHE TECH NEGOCIER L'INTERVENTION MAJ DES DEUX FICHES si administrateur

DEMANDE D'INTERVENTION EXTERNE

DEMANDE D'INTERVENTION GRATUITE MAJ DE LA FICHE TECH AJOUTER UNE FICHE TECH SUPPRIMER LA FICHE TECH

MAJ DE LA FICHE MAITENANCE

CONSULTER LA BASE

OU VALIDER ET ENREGISTRER

CODE CORRECTE BASE MAJ

FERMER LA BASE CONSULTER LES DEUX FICHES APPROPRIEES

BASE FERMEE'

DIAGNOSTIC DE REPARATION

PROCEDER A LA REPARATION

Figure 7 : MCT correspondant au systme EasyGPI

2.2. Modle organisationnel de traitement : MOT Aprs la finalisation de la modlisation conceptuel du traitement, nous pouvons commenc la modlisation organisationnel de traitement via le MOT qui permet deffectuer une reprsentation qui tient compte des contraintes et des rgles organisationnelles dun tel systme Il permet aussi de dcrire le QUAND, le QUI et le OU. On maintient ainsi les conceptuel de traitement. vnements et les rsultats du modle

Les oprations sont remplaces par les procdures fonctionnelles. On introduit de mme les postes de travail tel que le microordinateur et les imprimantes. La reprsentation graphique du MOT est trs similaire celle du MCT sauf que les procdures ont remplac les oprations. Le MOT peut tre ainsi exprim comme suit : MOT = MCT + Lieu + Moment + Nature Lieu : - Qui excute ? Acteurs (MCF) Moment : Quand excute-t-on lopration ? Agencement temporel

Nature : - Manuelle Automatique

Le formalisme dcrivant le MOT est illustr dans la figure 8 ci-dessous.

Figure 8 : Formalisme dun MOT

Nous dsignons trois principaux postes de travail au sein de la socit S.A.M.I concern pour le systme EasyGPI savoir : Lutilisateur Technicien Administrateur Ainsi le MOT correspondant sera dcrit en fonction de ses tris postes, de la priode et le type de traitement. Il sera dcrit comme le montre la figure 8. 2.3. Modle logique de traitement : MLT Aprs laffinement du MCT et le MOT, nous traitons le modle logique de traitement qui sagit ici dadapter le modle organisationnel des traitements (MOT) aux proccupations de linformaticien. Bien quun formalisme standard de description du modle logique des traitements nexiste pas encore dans MERISE. Il est propos les concepts suivants : Site : lieu physique des ressources informatiques. Ces ressources sont implantes sur des machines physiques.

 Machine logique : une machine logique est une machine virtuelle effectuant des taches qui dans la ralit sont effectues par une ou plusieurs machines physiques. Il sagit en fait dun ensemble de ressources informatiques. Toutefois la machine logique est situe en un site gographique donn. Une tache donne, dans le modle organisationnel des traitements, est effectue sur un poste de travail unique. Ce poste de travail peut mobiliser plusieurs machines logiques Unit logique de traitement : une tache automatise est dcompose en traitements informatiques appels units logiques de traitement (ULT). Le MLT correspondant au systme EasyGPI englobe les ULT suivants : - ULT du module connexion la base - ULT du module connexion au menu EQUIPEMENT - ULT du module connexion au menu BON - ULT du module connexion au menu FICHE MAINTENENCE Ces ULT sont illustrs dans les figures 10, 11, 12 et 13. DE

Priode

UTILISATEUR

TECHNICIEN

ADMINISTRATEUR

Type

MACHINE EN PANNE PASSER UN AVIS DE REP

Manuel

AVIS SIGNE

CONSULTER LA BASE

Auto ma tique

FICHES CONSULTEES

DEMANDE D'INTERVENTION DEMANDE D'INTERVENTION

Manuel

DIAGNOSTIQUER L'EQUIPEMENT CONSULTER LA BASE APPROPRIEE

Manuel Interactif

FICHES CONSULTEES ET DEVIS DE REP

MONTANT HORS FOURCHETTE MONTANT APPART FOURCHETTE SIGNER LE DEVIS NEGOCIER L'INTERVENTION SI OK SI NOT OK
Manuel Manuel

DEVIS ACCEPTE ANNULER LA REPARATION

REPARER LA MACHINE DEMANDER AUTRE INTERVENANT

Manuel Manuel

MACHINE REPAREE

REDIGER BON DE REP

Interactif

BON REDIGE

MISE A JOURS DE LA BASE

Temps diffr

FICHES M AJ

Figure 9 : MOT correspondant au systme EasyGPI

demande de reparation CONSULTER LA BASE

SAISIR MOT DE PASSE LOGIN OK SINON

VERIFIER LE LOGIN DANS BD

SE CONNECTER A LA BASE SI GUEST SI ADMIN

VERIFIER LE DROIT DANS BD

AFFICHER LES DROITS

MENU SAISIE MENU SESSION MENU GESTION MENU D 'AIDE EQUIPEMENT BON MAINTENANC

Figure 10 : ULT du module de connexion la base

CONSULTER EQUIPEMENT

SAISIE DU MATRICULE EQUIPEMENT

RECHERCHE DANS BD EQUIPEMENT

AFFICHER

AJOUTER UN EQUIPEMENT EDITER UN EQUIPEMENT SUPPRIMER UNEQUIPEMENT

EQUIPEMENT EDITE DANS BD

EQUIPEMENT SUPPRIME DANS BD

EQUIPEMENT AJOUTE DANS LA BD

Figure 11 : ULT du module de connexion au menu EQUIPEMENT

CONSULTER BON

SAISIE DU NUMERO DU BON

RECHERCHE DANS BD BON

AFFICHER

AJOUTER UN BON EDITER UN BON SUPPRIMER UN BON

BON EDITE DANS BD

BON SUPPRIME DANS BD

BON AJOUTE DANS LA BD

Figure 12 : ULT du module de connexion au menu BON

CONSULTER FICHE MAINTENANCE

SAISIE DU NUMERO DU FICHE MAINTENANCE

RECHERCHE DANS BD FICHE MAINTENANCE

AFFICHER

AJOUTER UNE FICHE EDITER UNE FICHE SUPPRIMER UNE FICHE

FICHE EDITE DANS BD

FICHE SUPPRIME DANS BD

FICHE AJOUTE DANS LA BD

Figure 13 : ULT du module de connexion au menu FICHE MAINTENANCE

Conclusion : Une fois que la conception est acheve, nous allons passer dans le chapitre suivant la description de la phase de dveloppement et de test.

Chapitre 4

Ralisation du systme EasyGPI

Introduction : Dans ce chapitre, nous allons prsenter le cycle de vie logiciel que nous avons choisi ainsi que laspect physique de notre modlisation (MPD et MPT) moyennant une base de donne ACCESS.

I. Cycle de vie retenu : le Prototypage

1. Dfinition : Un prototype est un modle intermdiaire du produit logiciel. Il sagit dune version simplifi dune partie de lapplication finale (par exemple un site web ou un logiciel).la mthode de prototypage consiste effectuer un test grandeur nature sur cette version partielle et toujours inacheve du systme en cours de dveloppement pour obtenir rapidement et moindre cot une ide du bon ou du mauvais fonctionnement de lapplication. Un prototype logiciel peut diffrer du produit final par : Fonctions offertes (spcification) Structure (conception) Langage de programmation (codage) Qualits non fonctionnelles : fiabilit, performance, confidentialit, volumes Environnement dexcution 2. Cycle de vie dun prototype : Le cycle de vie dun prototype se prsente comme le montre la figure13 ci- dessous :

Figure 14 : Cycle de vie dun prototype 3. Objectifs du prototypage : Lutilisation du prototypage permet de : Pr tester lapplication afin de dceler et analyser les erreurs. Fixer les spcifications donc aider lutilisateur produire ses besoins dans le cahier de charge grce une interface homme/machine. Faire une meilleure analyse des besoins et des risques. Dvelopper un environnement clair et adquat afin daboutir un produit stable ce qui allgera la phase de maintenance.

II. Prototype initial du systme EASY GPI :

1. MCD du prototype initial : A travers ce prototype, nous nous sommes bas sur la notion de machine/composante (mais sparment) On a aussi pris en considration la gestion de facturation et des fournisseurs de machines et de composantes sparment qui sillustre travers le schma de la figure qui suit :

TYPE_REPARATTIO N
num_ty p_rep ty pe_rep duree rep aratio n diagn ost ic trav _ ef f ec tu e 1,n

BON DE REPARATION
num bo n mont ant_re parat io n 1,1 1,1

RE M P LIR SIGNER

TECHNICIEN
1,n matricule _tech nicien nom_ t ec hnicie n tel_tec h f ax _t ec h

APPARTENIR
1,n

1,1

1,1

CORRE S P ON DRE

CORRES PONDR E
date_r ep

CORESPON DR E

INTERVENAN T matricule _int erv

tel_interv f ax _int erv

DE MANDER REP
0,n

0,n

1,n

CONCERNER

1,1

FICHE TECHNIQUE
numero f ic he _tech c arac terist iques _t ec h

MA CHINE
num_s erie_mac h 0,n matricule mac h des cription mach garantie_ mac h c at eg orie _mac 0,n h dat e_ acq uis_mach 0,n 1,n 1,1 0,n 1,1

UTILISATEU R matricule _us e r

nom_ use r section _user numero _pos te_us er 1,1

DESIGNER
0,1

CA LEN DRIER_MAINT
dat e_main t t_ a_f

LIVRER_MA CHINE

0,n

DECRIR E
date panne

CORRESPOND R E

APPARTENI R

FA C TURE_MACHINE
1,1

0,n

COMPOSANT E numero _serie_c

omp matricule _comp des c ription_c omp

0,1

DESIGNER

numero _f ac t _mac h mont ant_f ac t_mach 1,1

PAN NE
numero _pa nne des c ription de la p ann e 1,1

LIVRER_COMP

REDIGER
0,n 1,1 1,n

1,1

dat e_ acq uisitio n_c omp garantie_c omp

1,n

MARQUE
nom_marque

FOURNISSEUR_COM P
matricule _f eur_c omp nom_f eur_comp tel_f e ur_comp f ax _f eur_c omp

1,n

FACTURE_COMPOSANT E
REDIGER
numero f act _c omp 1,1 mont ant_f ac t_c omp

FOURNISSEUR_MACHINE
matricule _f eur_mac h nom_f eur_mach tel_f e ur_mac h f ax _f eur_mac h

Figure 15 : MCD initial du systme EasyGPI 2. Critiques apportes par le client : Le client na pas apprci le fait quune machine soit dcompose en composantes dclar sparment avec pour chaque une delle un fournisseur correspondant. Il a aussi cart la gestion des factures en prfrant lintgrer partiellement dans la gestion des quipements. 3. Modifications apportes : Raisonner en terme dquipement. Fusionner les module facturation et gestion des quipements.

III. Quelques interfaces du prototype initial :

Cette capture dcran reprsente le menu principal du prototype initial du systme EasyGPI ne se basant pas sur le concept MDI.

Figure 16 : Menu au format SINGLE FORM (non MDI)

Figure17 : Menu gestion des machines du prototype initial

VI. Modle physique de donnes : MPD

Comme, de nos jours, ce sont les bases de donnes relationnelles qui sont le plus utilises, le modle physique des donnes est exprim dans le langage fourni par le SGBD. Il sagit dune traduction du MCD qui intgre la contrainte technique, savoir la nature de loutils logiciel sur lequel sera installe la future structure de donnes (dans notre cas le AMC Designer va gnrer automatiquement la base de donne ACCESS). Le passage du MCD au MPD seffectue par application des rgles de passage : Chaque ENTITE se transforme en TABLE. Les PROPRIETES se transforment en COLONES de la table en question. Chaque IDENTIFIANT de lentit devient une CLE PRIMAIRE unique de sa table. En appliquant intgralement ces rgles, nous aboutissons au MPD du systme EASY GPI illustr dans la figure 17 ci dessous :

NUM_BON = NUM_BON ASSOC_CORRESPONDE R NUM _BO N L ong In t e g er

BON_REP NUM _BO N L on gIn t e g er NOM_INTER NUM _SERIE_M ACH MONT_REPARATIO N DURE_REPA Me m o Me m o Dou ble Me m o Me m Date Tim e Date Tim e Date Tim e

INTERV NOM_INTER Me mo NO M_ INTER = NOM _ I NTER NOM TECHNICIEN Te xt (40) TEL_TECH Lon gIntege r FAX_TECH Lon gIntege r ENT_117 3 NOM _ INTER = NOM_I NTER NOM_INTER TEL_INTERV FAX_INTERV NUM_SERIE_ MACH = Me m o Lon gIntege r Lon gIntege r

TYP_REPA TYPE_RE PA Me m o

TAF_REP o MATRICULE_US ER T e xt ( 15) DAT_PAN NUM _SERIE_M ACH Me DAT_REPA mo DATE_REP NU M_ SERIE_ MACH

ASSOC_ DREP

NUM_SERIE_ MACH = N U M_ SERIE_ MACH MATRICULE_U S ER = MATRICULE_USER

NUM_SERIE_ MACH = NUM_SERIE_ US E R MATRICULE_ USER T ex t ( 15) NUM _SERIE_M ACH Me m o NOM_USER Me m o NUM_SERIE_MACH = SECTION_USER Me m o NU M_ SERIE_ MACH NUM ERO_POSTE_ USER LongIntege r LOGIN Me m o DROIT OLE DATE_PA N N E Da te Tim e

MACH

MACH NUM _SERIE_M ACH Me m o DATE_MAINT Date Tim e MATRICULE_FEUR_MACH Me m o MATRICULE_MACH Me m o DESCRIPTION_MACH Me m o GARANTIE M ACH Me m o CATEGORIE_MACH Me m o DATE_A C QUIS_MACH Date Tim e OS_MACH Me m o ADRE S_IP_M ACH Me m o TYP_M ACH Me m o

FICHTECH NUM ERO_FICHE_TECH M em o NUM _SERIE_M ACH Me m o CARACTERISTIQUES_TECH Me m o ENT_CAL_MAINT DATE_MAINT D at e Ti m e NUM _SERIE_M ACH Me m o T_A_F Me m o AS SOC_DESIG03 NUM _SERIE_M ACH M em o NUM ERO_FA C T_MACH Me m o

NUM_SERIE_MACH = NU M_ SERIE_ MACH

DATE_MAINT =

DATE_MAINT

NUM_SERIE_MACH =

NUM_SERIE_ MACH NUM_SERIE_MACH = NU M_ SERIE_ MACH NUM_SERIE_ MACH = NUM_SERIE_ MACH NUMERO_ FACT_MACH = NUMERO_FACT_MACH ENT_FA C T_M AC H NUM ERO_FA C T_MACH M em o MATRICULE_FEUR_MA C H Me m o MONTANT_FA C T_M ACH Me m o MATRICULE_ FEUR_MACH = MATRICULE_FEUR_ MACH CODE_SC = CODE_SC ENT_115 0 MATRICULE_FEUR_MACH NO M_FEUR_MA C H TEL_F EUR_MACH FA X _FEUR_MACH M em o Me m o LongIntege r LongIntege r

ENT_MARQ NOM_M A R QUE M em o NUM _SERIE_M ACH Me m o

ASSOC_APPART01 NUM _SERIE_M ACH Me m o CODE_C Me m o CODE_COMP M em o CODE_C = CODE_ C

MATR C I ULE_FEUR_MACH = MATRIC U LE_FEU R _MACH

CODE_COMP = CODE_COMP

ENT_COMP CODE_CO MP M e m o LIBELLE Me m o

ENT_C A T CODE_C M e mo CODE_SC Me m o LIBEL LE Me mo CNX <non dfini> NUM _C Me m o SFORMAT Me m o

ENT_SCAT CODE_SC M e mo LIBELLE_SC Me m o

Figure 18 : MPD correspondant au systme EasyGPI

V. Modle physique de traitement : MPT

La modlisation physique des traitements correspond au dernier stade avant la programmation. Le modle oprationnel des traitements consiste en la dfinition dtaille des traitements qui sont exprims souvent en langage algorithmique ou en utilisant un environnement de programmation.

Le MPT dcrit les traitements raliss pour chaque transaction (en temps rel) ou chaque unit de traitement (en temps diffr). Nous illustrons titre dexemple quelques lignes de code du MAIN en algorithmique : Se connecter (,) Extraire (,) /* se connecter la base*/

/* extraire les champs utiliser de la base

correspondante*/ Extraire (,) Affecter /* affecter ces champs dans la zone correspondante de linterface*/ Afficher /* afficher ces champs*/

Conclusion : Nous passons la dernire tape de notre cycle de dveloppement qui est la phase de validation et de test.

Chapitre 5

Tests et Intgration du Systme EasyGPI

I. Introduction :
La vrification dun logiciel permet de dmontrer que les produits logiciels issus dune phase de dveloppement sont conformes aux spcifications (incluant les exigences lgales et rglementaires) tablies lors des phases prcdentes. Seules le recours des moyens de vrification et surtout de tests prouvs en sret de fonctionnement permettent dobtenir une confiance justifie (minimiser les erreurs, maximum dexactitude, pertinence etc.). Les tests doivent tre mens diffrents niveaux du dveloppement dun logiciel (ils se prparent ds la phase de spcification). Les tests peuvent servir montrer la prsence derreurs, pas leur absence 1 On distingue trois types de test : 1. Tests unitaires : Pour montrer que chaque module effectue toute la fonction prvue et seulement cette fonction. On peut distinguer dans ces tests unitaires : Les tests de logique (recherche derreurs, vrification, de lenchanement correct des branches parcourues) ; Les tests de calcul (vrification des rsultats des calculs, performances, de lexactitude des algorithmes). 2. Tests dintgration : Pour dmontrer le bon fonctionnement dunits fonctionnelles constitues dun assemblage de modules, la circulation des donnes, les aspects dynamiques, les squences dvnements prvus et les reprises en cas dinterruption. 3. Tests dacceptation : Ce genre de test nous permet de mieux dtecter les erreurs ainsi que les exceptions que le dveloppeur ne les prvoit pas. Ces tests se font en

prsence de lutilisateur final.

Edsgar Dijeskra

Pour ce, nous avons prpar une srie de jeux de test que nous dcrivons dans ce qui suit. 4. Jeux de test : On essayera dlaborer des jeux de test afin de : Laisser une trace pour le contrle (le vrificateur vrifie que le testeur a effectu les tests du jeu de tests utilis). Laisser une trace entre la conception et lexcution du test (entre le moment de la spcification et celui o le code est crit et peut tre test). Sparer lexcution des tests de lanalyse des rsultats (ce nest pas au moment ou on faut le test quil faut juger de la sorties, ce nest pas la mme personne qui le fait la plupart du temps).
4.1. Exemples de jeux de test effectu sur le systme EASY GPI et captures dcran :

Cette capture dcran reprsente le MENU PRINCIPAL (final) du systme EasyGPI sous format MDI ou on pourrait grer plusieurs feuilles la fois

Figure 33 : Menu Principal

Nous prsentons travers ces interfaces toute les procdures quun utilisateur peut pratiquer sur le systme EasyGPI telles que : simple consultation, dition, ajout, suppression, recherche et impression. Pour cette fentre, nous avons spcifi un bouton DETAILS travers lequel lutilisateur peut visualiser les bons correspondants lquipement en question sans tre oblig de retourner la fentre GESTION DES BONS DE REPARATION.

Figure 34 : Fentre GESTION DES EQUIPEMENTS

Pour procder une recherche, lutilisateur peut parcourir (sil le souhaite) tous les quipements et en slectionne celui dsir. Il peut aussi effectuer une recherche slective en introduisant un critre de recherche (le matricule de la machine).

Figure 35 : Module de Recherche

PFE - MIAGE 2004/2005

Pour tester la gestion des quipements, nous montrons la mise jour de la base aprs lajout dun quipement de catgorie Unit Centrale (UC).

quipement
mat_mach UC0001 num_seri_mach Non Disponible code_c UC Typ_mach SERVEUR os_mach NT4 SP6 garanti_mach 1 an dat_aquis_mach 01/01/2000 marq_mach Versus Nom VERSUS masq_mach adress_ip

255.255.0.0 158.157.156.1

UC0002

503192-404

UC

SERVEUR

NT4 SP6

1 an

01/01/2000

Versus

SERVEUR

255.255.0.0 158.157.156.2

UC0003

11507

UC

CLIENT

Win 98 FR

1 an

01/01/2000

Versus

Poste Sabeh

. _.

_.

158.157.156.3_

49

48

PFE - MIAGE 2004/2005 Aprs lajout de lquipement, lutilisateur pourra imprimer ltat correspondant comme le montre la figure ci-dessous.

Figure36 : Etat de lquipement slectionn

PFE - MIAGE 2004/2005

Figure 37 : Slection du menu BONS DE REPARATION

A travers cette fentre GESTION DES BONS DE REPARATION, nous prsentons les rparations effectues sur un quipement.

50

PFE - MIAGE 2004/2005

Figure 38 : Fentre GESTION DES BONS DE REPARATION

51

PFE - MIAGE 2004/2005

Pour tester la gestion des bons de rparation, nous montrons la mise jour de la base aprs lajout dun bon de rparation de lunit centrale UC0003.

bon_rep
num_bon 0001 mat_mach UC0017 mont_bon ND typ_repa Maintenance mat_interv ISB duree_rep diagnostic a faire: recuperer donnes d:\sauv format c: win98 FR SE+NAV+office+image c: taf_rep mat_tech dat_pan

sauvgarde des informations Nam 29/11/2003 +fdisq+win98 FR +ms office 2003 Chebbi +NAV +ghost+maj peripheriques Nam 01/01/2003 Chebbi

0002

UC0006

ND

Maintenance

ISB

A faire: recuperer donnes sauvgarder des informations format+fdisq c:etd:+win98 +fdisq+ms arab+nav+office+image c:+network office2000+norton+ghost+mise a jour des peripheriques recuperer donnes sur cd + format c: + Win98FR+NAV+Office+network+ LOGICIELS IGL

0003

UC0003

ND

Maintenance

ISB

Sauvegarder des informations Nam 29/11/2003 Format c: + windows 98 Ar+ NAV+ Chebbi Ghost+ms office 2000+maj priphriques nb: mmoire = 32mb

52

PFE - MIAGE 2004/2005 Aprs la saisie dun bon de rparation, lutilisateur pourra imprimer ltat correspondant comme le montre la figure ci-dessous.

Figure 39 : Etat du bon slectionn

PFE - MIAGE 2004/2005

Figure 40 : Slection du menu MAINTENANCE PREVENTIVE

54

PFE - MIAGE 2004/2005 A travers cette fentre, lutilisateur prvoit les maintenances prventives de ces quipements (dj saisi) et pourra limprimer.

Figure 41 : Fentre Gestion de la MAINTENANCE PREVENTIVE

55

PFE - MIAGE 2004/2005 Aprs la spcification de la maintenance prventive souhaite, lutilisateur pourra imprimer ltat correspondant comme le montre la figure ci-dessous.

Figure 42 : Etat de la MAINTENACE PREVENTIVE

III. Autres Captures dcran du systme EASY GPI final :

56

PFE - MIAGE 2004/2005

Figure 43 : SPLASH

57

PFE - MIAGE 2004/2005

Figure 44 : Module de connexion

Figure 45 : Menu TECHNICIENS

58

PFE - MIAGE 2004/2005 A travers cette fentre, ladministrateur dclare ses techniciens avec tous les renseignements correspondants. Il peut tout moment procder lajout, ldition et la suppression dun technicien.

Figure 46 : Fentre GESTION DES TECHNICIENS

59

PFE - MIAGE 2004/2005 A travers cette fentre, ladministrateur gre son personnel et lui accorde les droits daccs au systme EasyGPI.

Figure 47 : Slection du menu UTILISATEURS

60

PFE - MIAGE 2004/2005

Figure 48 : Fentre GESTION DES UTILISATEURS

61

PFE - MIAGE 2004/2005

Figure 49 : Slection du menu AIDE

62

PFE - MIAGE 2004/2005

A travers cette fentre, nous dcrivons avec dtails le mode dutilisation du systme EasyGPI.

Figure 50 : Fentre daide conue en html

63

PFE - MIAGE 2004/2005

II. Conclusion Gnrale :

Nous arrivons la phase finale de notre projet de fin dtudes et en guise de conclusion, nous pouvons constater que ce projet a contribu complter notre formation acadmique et nous a surtout permis de mettre en pratique les mthodes de conception ainsi quun ensemble dAGL tels que Rational Rose, Power AMC Designer, Visual Basic 6, Seagate Crystal Reports et Html Help Workshop. Aussi, nous avons t confronts durant notre stage au sein de la socit S.A.M.I des situations relles avec les futurs utilisateurs qui nous ont permis de dcouvrir les difficults que peut rencontrer un concepteur dsirant suivre le cycle de dveloppement du logiciel face la ralit de lexistant. Toutefois, cette exprience reste trs enrichissante o nous avons appris le travail en quipe et la rigueur suivre quant au dveloppement logiciel.

64

PFE - MIAGE 2004/2005

Bibliographie utilise
En plus des supports de cours de Mme Laatiri Chiraz, nous avons eu recours aux rfrences suivantes : MERISE et UML de Joseph Gabay, Edition Dunod, 2002. Pour le dveloppement avec Visual Basic 6, nous avons utilis la bibliothque daide MSDN et le forum dentraide des dveloppeurs francophones www.vbfrance.com .

65