WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et implémentation d'une GMAO ( gestion de maintenance assistée par ordinateur ) pour le département santé de l'Eglise Evangélique du Cameroun

( Télécharger le fichier original )
par Jean- Pierre et Flavien Boris Kamga et Ngomne Bouwa
Université des montagnes Cameroun - En vue de l'obtention d'une licence de technologie en génie informatique option informatique et réseaux 2012
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

République du Cameroun Republic of Cameroon

Ministère de l'enseignement supérieur Ministry of Higher education

Université des Montagnes

Institut Supérieur des Sciences et de Technologie

251658240

Département Santé

RAPPORT DE PROJET DE FIN D'ETUDES

En vue de l'obtention d'une Licence de Technologie en Génie Informatique option, Informatique et Réseaux

Titre :

Conception et Implémentation d'une GMAO pour le Département Santé de l'EEC « GMABIO »

Présenté par:

- Kamga Jean Pierre Mat : 09C029

- Ngomne Bouwa Boris Flavien Mat : 09C048

Sous l'Encadrement Académique de :

- Mr Takoudjou Alexis

Sous l'Encadreur Professionnel de:

- Mr Pelamie Pierre

Bangangté Octobre 2012

DÉDICACES

Après avoir rendu grâce à DIEU LE TOUT PUISSANT,

Nous dédions ce modeste travail à

Nos chers parents

Nos frères et soeurs

Nos promotionnaires

Ainsi qu'à tous ceux qui nous sont chers.

REMERCIEMENTS

Après avoir rendu grâce à DIEU de nous avoir donné la force physique, morale et intellectuelle d'achever ce projet de fin d'études, nous tenons à témoigner notre profonde gratitude

- A M. le Directeur Général du département santé de l'EEC pour nous avoir accueillis dans sa structure ainsi qu'à tous le personnel de cette dernière ;

- A tous nos encadreurs pour leur disponibilité et leurs conseils, durant toute la durée du projet à savoir:

ï M. Takoudjou Alexis Professeur à l'université des montagnes ;

ï M. Pelamie Pierre Chef service maintenance au département santé de l'EEC, Ingénieur biomédical ;

- Nous tenons également à remercier tous ceux qui, de près ou de loin, ont contribué à la réalisation de ce travail sans oublier nos camarades de promotion.

- L'Université des Montagnes, pour la formation qu'elle nous a donnée tout au long de notre cycle faisant de nous des ingénieurs à part entière et capables de s'insérer dans le monde professionnel.

RÉSUMÉ

La technologie joue un rôle essentiel dans l'efficacité de la prestation de la santé. Le choix des technologies médicales appropriées et l'organisation requise pour maintenir ces technologies en bon état de fonctionnement relèvent des programmes de gestion des technologies de la santé. La responsabilité de la gestion des technologies de la santé incombe souvent au département du génie biomédical (ou de l'équipement médical), qui teste, répare et entretient le matériel clinique diagnostique et thérapeutique pour garantir qu'il peut être utilisé efficacement et en toute sécurité. Les systèmes de gestion de maintenance assistée par ordinateur (GMAO) ont été conçus pour aider les responsables de la gestion des technologies de la santé à entretenir l'équipement et à suivre les dépenses connexes automatiquement.

Le but de ce projet de fin d'études est de concevoir et de développer un système de gestion de la maintenance adaptée au contexte des hôpitaux et centres médicalisés de l'oeuvre médicale de l'Eglise Evangélique du Cameroun. Ce système permettra à l'entreprise d'avoir une traçabilité et une transparence des activités d'entretien aussi bien sur le plan technique que humain.

D'après le cahier des charges, le progiciel doit être un système de gestion de base de données qui doit enregistrer les activités d'entretien (état avant intervention, pièces changées, reconduites, travaux, durées, intervenants, bons de sortie, état du stock etc.) fournir les fiches machines des équipements (caractéristiques, pièces de rechange, service concerné), l'historique des interventions.

Ce progiciel que nous avons nommé « GMABIO Solution » compte deux applications : « GMABIO Admin » pour l'administration du système et « GMABIO Client » pour les hôpitaux, elles sont toutes deux développées sous Netbeans 6.9, avec des outils tels que Hibernate, AJAX.

ABSTRACT

Technology plays a vital role in the effectiveness of health delivery. The choice of appropriate medical technologies and organization required to maintain these technologies are good working condition management programs of health technologies. Responsibility for the management of health technologies often falls to the Department of Biomedical Engineering (or medical equipment), which tests, repairs and maintains diagnostic and therapeutic clinical equipment to ensure it can be used safely and effectively safety. Management systems of computer-aided maintenance (CMMS) have been designed to help those responsible for the management of health technologies to maintain equipment and related expenses automatically follow.
The purpose of this final project is to design studies and develop a system for maintenance management adapted to the context of hospitals and medical centers of the medical work of l'Eglise Evengélique du Cameroun. This system will allow the company to have a traceability and transparency of maintenance activities on both the technical and human.
According to the specifications, the package should be a management system database should record maintenance activities (before state intervention, parts changed, renewed, work, duration, actors, good output status stock etc.). Plugs provide machinery equipment (specifications, spare parts service), the history of interventions. The package that we named GMABIO Solution has two applications: «GMABIO Admin» for system administration and «GMABIO Client» for hospitals, they are both developed in Netbeans 6.9, with tools such as Hibernate, AJAX.

TABLE DES MATIERES

DÉDICACES 2

REMERCIEMENTS 3

RÉSUMÉ 4

ABSTRACT 5

TABLE DES MATIERES 6

LISTE DES FIGURES 8

LISTE DES CYCLES ET ABRÉVIATIONS 9

INTRODUCTION GÉNÉRALE 10

Chapitre 1 CONTEXTE, PROBLEMATIQUE ET METHODOLOGIE DE TRAVAIL 11

I.1 ETUDE DE L'EXISTANT 11

II.1.1 Présentation de l'entreprise 11

II.1.2 Etat de la gestion de la maintenance 11

I.2 PRÉSENTATION DU PROJET 12

I.3 PROBLÉMATIQUE DU PROJET 12

I.4 OBJECTIFS 12

I.5 MÉTHODOLOGIE DU PROJET 13

Chapitre 2 ETAT DE L'ART 14

II.1 FONCTION DE LA MAINTENANCE DANS UNE STRUCTURE 14

II.1.1 Définition 14

II.1.2 Importance et rôle de la maintenance 14

II.1.3 Phases de la maintenance 14

II.1.3.1 Choix de l'équipement 14

II.2 CONCEPT DE GMAO 15

II.3 LOGICIELS DE GMAO 15

II.3.1 Unigest 15

II.3.2 AssetPlus 15

II.3.3 Justification du choix de développement 16

II.4 ARCHITECTURE ET TECHNOLOGIES À UTILISER 16

II.4.1 Architecture 3-tiers 16

II.4.2 Architecture d'une application Java en couche 16

II.4.3 JPA/Hibernate 17

II.4.4 FPDF 18

II.4.5 AJAX 18

Chapitre 3 ANALYSE ET CONCEPTION DE GMABIO SOLUTION 19

III.1 SPÉCIFICATION FONCTIONNELLE DE L'APPLICATION 19

III.1.1 Fonctions du système 19

III.1.2 Description des utilisateurs 19

III.1.3 Fonctions liées aux droits d'accès 20

III.2 EXIGENCES SPÉCIFIQUES 20

III.2.1 Interfaces externes 21

III.2.2 Spécification des cas d'utilisations 21

III.3 MODÈLE OBJET DU SYSTÈME 27

III.3.1 Diagramme de classe du module gestion des interventions 27

III.3.2 Diagramme de classe du module gestion des équipement 28

III.3.3 Règles de gestion 29

III.4 EXIGENCES D'OPÉRATIONS, DE COMMUNICATIONS ET DE PERFORMANCE 29

III.5 EXIGENCE DE LA BASE DE DONNÉES 29

III.5.1 Modèle Conceptuel de données 29

III.6 CONCEPTION DE L'APPLICATION 30

III.6.1 Domaine d'Application 30

III.6.2 Architecture du système 30

III.6.3 Langages utilisés 30

III.6.4 Diagramme de déploiement 31

III.6.5 Architecture Générale du système 31

III.6.5.4 Gestion des Erreurs 34

Chapitre 4 MISE EN OEUVRE 36

IV.1 ENVIRONNEMENT DE TRAVAIL 36

IV.2 DEMARCHE DE TRAVAIL 36

IV.3 DIFFICULTÉS RENCONTRÉS 37

IV.4 RÉSULTATS OBTENUS 37

BIBLIOGRAPHIE 42

I. Référence bibliographique 42

II. Site web 42

ANNEXES 43

LISTE DES FIGURES

Figure1 : Architecture 3-tiers 16

Figure2 : Architecture d'une application java en couche 17

Figure3 : Diagramme des cas d'Utilisation 22

Figure4 : Diagramme de séquence « Afficher liste Equipement » 23

Figure5 : Diagramme de classe « module Intervention » 27

Figure6 : Diagramme de classe « module Equipement » 28

Figure7 : Architecture générale de l'application GMABIO Solution 30

Figure8 : Diagramme de déploiement 31

Figure9 : Architecture générale du système 32

Figure10 : Architecture application d'administration 33

Figure11 : Architecture application cliente 34

Figure12 : Arborescence des paquetages 37

Figure13 : Interface de connexion application d'administration 37

Figure14 : Fenêtre de choix de l'opération « module gestion équipements » 38

Figure15 : Interface fiche équipement 38

Figure16 : Interface contrat maintenance « module gestion équipement » 39

Figure17 : Interface connexion application cliente 39

Figure18 : Interface commencer Intervention 40

LISTE DES CYCLES ET ABRÉVIATIONS

2TUP:2 Tract Unified Process

API: Application Programming Interface

DAO: Data Access Object

EEC:

GMABIO: c'est le nom de l'application

IHM : Interface Homme Machine

JDBC: Java Data Base Connection

JPA: Java Persistence API

JSE: Java Standard Edition

MERISE : Méthode d'Etude et de Réalisation Informatique des Systèmes d'Entreprise

MVC: Model View Controller

MySQL: My Structured Query Language

SGBD: Système de Gestion des Bases de Données

TCP/IP: Transmission Control Protocol / Internet Protocol

UML: Unified Modeling Language

INTRODUCTION GÉNÉRALE

La fonction maintenance prend une importance croissance et se révèle une fonction clé au sein de l'entreprise tout comme la fonction production. Elle se charge de conserver en bon état le patrimoine technique de l'entreprise, c'est-à-dire les outils de production et donc doit avoir une vision à moyen et à long terme.

Pour être efficace dans sa mission d'assurer l'entretien et l'amélioration de l'équipement de production, la fonction maintenance doit se doter d'outils fiables afin de gérer le flux d'informations qui gravite autour de ses activités quotidiennes :

- Identification de chaque équipement de l'entreprise (caractéristiques techniques, pièces de rechange etc.),

- Notifications de toutes les interventions effectuées sur les équipements afin de pouvoir établir leur historique,

- Situation des responsabilités en identifiant les intervenants et les travaux effectués lors d'une activité d'entretien,

- Appréciation des agents de maintenance en notifiant les temps d'interventions (heures normales et supplémentaires, qualité de la prestation ...)

- Information sur les pièces de rechanges disponibles afin d'éviter une rupture de stock.

Le progiciel nommé GMABIO que nous avons développé dans le cadre de ce projet de fin d'études est un outil de prise de décision qui apporte une solution aux points énumérés ci-dessus.

Quoiqu'étudié dans le contexte du département santé de l'EEC, GMABIO peut s'adapter à la plupart des grands groupes l'hospitalier tel que : ALucem.

Le présent rapport est composé de quatre chapitres : le premier porte sur la problématique et la méthodologie du travail à effectuer, le deuxième sur la revue des concepts et technologie pour la mise sur pied de cette solution tandis que le troisième et le quatrième traitent respectivement de l'analyse conceptuelle du progiciel de gestion de la maintenance et de sa mise en oeuvre.

Chapitre 1

I.1 ETUDE DE L'EXISTANT

II.1.1 Présentation de l'entreprise

L'église évangélique du Cameroun dans ses diverses oeuvres aussi bien religieuses que sociales a créé plusieurs hôpitaux sur l'étendu du territoire. Ces hôpitaux sont sous la tutelle des oeuvres département santé EEC qui est lui-même subdiviser en plusieurs services à savoir : Ressources Humaines, Pharmacie, Audits et Finances et Maintenance biomédical.

Le service de la maintenance est celui qui s'occupe de gérer la maintenance des équipements de tous les hôpitaux et centres médicalisées. Il convient de préciser que ces hôpitaux sont aux nombres de seize et que certains d'entre eux possèdent des centres médicalisés ou annexes.

II.1.2 Etat de la gestion de la maintenance

I.1.2.1 Intervenants

Dans le système actuel, les intervenants sont les responsables des hôpitaux qui interpellent l'ingénieur lorsqu'une panne survient. Mais ce système est entrain de laisser sa place à un autre qui fera intervenir des techniciens qui seront dispatchés dans les centres. Ce qui nous pousse à prendre en compte ces nouveaux intervenants dans la solution qui nous a été demandée à mettre sur pied visant a facilité la gestion de ce nouveau système.

I.1.2.2 Déroulement actuel de la maintenance

Les activités menées jusqu'ici par le service de maintenance se déroulent comme suit : lors de l'acquisition d'un équipement celui-ci est enregistré dans une fiche d'inventaire. Lorsqu'une panne survient le responsable du centre peut contacter le service de maintenance en la personne de l'ingénieur responsable du service qui prend en compte la demande ; se déplace ou fait déplacer l'équipement dans l'optique d'une intervention. A la fin, il doit produire une fiche d'intervention qu'il fait viser par le centre demandeur. Dans la situation contraire à celle décrite ci-dessus le responsable du centre contacte un fournisseur agrée ou une entreprise de maintenance de la place.

I.1.2.3 Critique de l'existant

Les remarques que nous avons relevées sont les suivantes :

- Un traitement lent, dû au traitement manuel de certaines tâches ce qui peut éventuellement conduire à de nombreuses erreurs.

- Grande perte d'informations car celles-ci ne sont pas centralisées.

- Une sauvegarde pas assez fiable de données.

I.2 PRÉSENTATION DU PROJET

Le produit à développer est un système de gestion de la maintenance assistée par ordinateur pour le service de maintenance biomédical du département santé de l'EEC, nommé « GMABIO Solution».

Le projet consiste à mettre sur pied un système qui permet une centralisation de l'information, un traitement rapide et plus efficace des données recueillies. En effet, le nouveau système permet la gestion informatisée des équipements médicaux des hôpitaux de l'EEC. Il s'agit non seulement de recenser les différents types d'équipements présents dans l'entreprise, leur localisation, mais aussi permettre de connaître l'année d'acquisition de ces équipements, le nom des fournisseurs, l'historique des interventions sur chaque équipement, de prendre des décisions stratégiques et de fournir des statistiques... Le système comporte deux applications, une application cliente « GMABIO Client » qui sera accessible aux clients via le réseau internet et une application serveur « GMABIO Admin » qui sera accessible via la machine d'administration et offre une vision globale de l'état et du suivi des équipements utilisés dans l'entreprise. Ce système s'occupera aussi de la gestion des ressources humaines et la gestion des inventaires.

I.3 PROBLÉMATIQUE DU PROJET

Les questions qu'on se pose au regard d'un tel projet sont les suivantes : Comment mettre donc à disposition du département santé un outil devant aidé à gérer le parc des équipements de leur hôpitaux ? Comment assurer une bonne gestion du processus de maintenance ? Quel choix d'architecture allons-nous opérer pour faciliter la maintenance du futur système ? Comment peut-on modéliser fidèlement la solution en tenant compte des besoins des utilisateurs et des contraintes de l'environnement ?

L'objectif principal pour nous sera de satisfaire les attentes ci-dessous.

I.4 OBJECTIFS

Le logiciel permettra de :

· Fournir à tout moment la localisation d'un équipement dans l'entreprise;

· Avoir un meilleur suivi et un meilleur contrôle des équipements (pas de confusion entre les noms des équipements et pas d'erreurs)

· Produire des statistiques et des rapports (ou des fiches techniques) sur les équipements ;

· Faciliter la gestion et le contrôle des équipements ;

· Améliorer la qualité de service et assurer la meilleure productivité du département Santé en général et du service de maintenance B.M. en particulier ;

· Mieux planifier les interventions préventives ;

· Mieux planifier les prévisions d'acquisition et de remplacement ;

· Avoir une meilleure visibilité sur les ressources qui vont permettre de prendre de meilleures décisions 

I.5 MÉTHODOLOGIE DU PROJET

La démarche que nous utiliserons pour ce logiciel sera calquée sur le cycle de vie de ce dernier; en partant de l'avant-projet jusqu'à l'installation et en effectuant en parallèle les autres tâches tel que : La documentation, La vérification, La validation, La gestion. Le tableau ci-dessous présente le cycle de vie du logiciel.

Activités

Sous-Activités

Activités Parallèle

Documents

Autres

Avant-projet

Etude Préalable

-Cahier de charge du Projet

Vérification,

Validation

et

Gestion

Initiation des Projets

Développement

Analyse et

Spécification

- Cahier de charge du logiciel

-Fiche de version du logiciel

-Document de conception

-Dossier de programmation

-Manuel d'utilisation

Conception

Implémentation et

test unitaire

Intégration et test

d'intégration

/

- Dossier de test d'intégration

Installation et test

système

/

-Dossier de test système

Chapitre 2 

II.1 FONCTION DE LA MAINTENANCE DANS UNE STRUCTURE

II.1.1 Définition

L'entretien ou la maintenance est défini comme étant « l'ensemble des actions permettant de maintenir ou de rétablir un bien dans un état spécifié ou en mesure d'assurer un service déterminé» (norme AFNOR X 60-010). Entretenir, maintenir, c'est donc effectuer des opérations (dépannage, graissage, visite, réparation, amélioration, vérification, etc.) qui permettent de conserver le potentiel du matériel pour assurer la continuité et la qualité du service ainsi que la sécurité des opérations.

II.1.2 Importance et rôle de la maintenance

L'importance et le rôle de la maintenance sont illustrés par la nécessité d'assurer la disponibilité permanente et le bon fonctionnement des installations matérielles de production. Le rôle de la maintenance serait, en définitive, de permettre aux structures hospitalières et autres de remplir leurs fonctions en obtenant un rendement optimum.

II.1.3 Phases de la maintenance

La planification de la maintenance se fait en trois phases successives qui sont: le choix de l'équipement, son utilisation et la gestion de la maintenance de l'équipement.

II.1.3.1 Choix de l'équipement

Le choix de l'équipement, sa conception ou son achat, marque le début de la planification de la maintenance. Elle est une étape décisive, en ce sens que, une mauvaise décision à cette étape peut avoir pour effet un entretien difficile, fréquent et coûteux. Les différents aspects à prendre en considération lors du choix sont: la maintenabilité, la standardisation et la fiabilité.

II.1.3.2 Utilisation de l'équipement

C'est la deuxième phase de la maintenance où des mesures et des observations sont effectuées afin de faire des appréciations sur l'utilisation de l'équipement. On peut noter dans cet aspect, une bonne ou mauvaise utilisation et une sous ou sur utilisation de la machine qui en découle des exigences du constructeur et parfois aussi du non-respect des planifications des maintenances faite par le responsable en charge.

II.1.3.3 Gestion de la maintenance

La gestion de la maintenance qui est la troisième et dernière phase de la maintenance, consiste à optimiser les différentes activités d'entretien qui permettent au système de production de produire à temps, la qualité et la quantité d'unités requises, au meilleur coût. Ceci nécessite la mise sur pied d'un système de gestion qui, à l'aide de différentes données recueillies, fournit entre autres, un programme d'entretien et divers rapports.

II.2 CONCEPT DE GMAO

Un système de GMAO est composé de champs, de tables et de modules remplis de données fournies par le département du génie biomédical ou d'équipement d'un établissement donné. Un système de GMAO permet d'accéder aux données essentielles, de les manipuler et de les analyser au moyen d'interfaces faciles à utiliser. Les rapports émanant du système peuvent aider les responsables des politiques à prendre les décisions concernant les technologies de la santé. Il convient toutefois d'examiner plusieurs facteurs avant de décider d'adopter ou de concevoir un système de GMAO. Les facteurs tels que les ressources financières et techniques jouent un rôle important dans la décision d'acheter un produit commercial, d'utiliser un logiciel libre, ou de concevoir un système sur place. La mise en oeuvre passe par un certain nombre d'étapes qui permettront une planification complète du système. Au terme de ce processus échelonné, les options de déploiement auront été évaluées en profondeur ; un système adapté aura été choisi, installé et personnalisé ; les données seront enregistrées ; et une formation à la GMAO sera dispensée.

Les organisations dotées des ressources requises pour la mise en oeuvre de cet outil tireront un grand profit de la GMAO. Bien utilisé, cet outil d'une grande souplesse pourra transformer la gestion de l'équipement biomédical tout en améliorant la disponibilité et la fonctionnalité des technologies requises pour prévenir, diagnostiquer et traiter les maladies.

II.3 LOGICIELS DE GMAO

II.3.1 Unigest

Unigest GMAO est un logiciel de gestion des interventions dans le domaine du biomédicale. Nos clients recherchent avant tout un outil simple et adapté à leur budget. UNIGEST a été développé dans cet objectif et a mis au point avec le partenariat de professionnels de haut niveau. La priorité est de vous apporter un outil simple, convivial et puissant à la fois. Basé conjointement sur une application Windows et une interface web simple, le produit a pour vocation de saisir les interventions, d'en gérer le traitement et de délivrer un historique clair.

II.3.2 AssetPlus

AssetPlus est une solution clef en main, unique, de gestion pour toutes les directions hospitalières. Depuis plus de 15 ans, AssetPlus propose des fonctionnalités de GMAO. adaptées aux procédures et aux contraintes du milieu hospitalier. Sous l'impulsion de ses utilisateurs, AssetPlus est devenu un véritable outil de référence pour le suivi de la maintenance et des investissements nécessaires au bon fonctionnement des institutions de santé. En véritable ERP technique, AssetPlus permet le suivi complet du cycle de vie de tous les actifs en agissant comme un microscope pour identifier, analyser et corriger les dysfonctionnements.

II.3.3 Justification du choix de développement

Dans la mesure où toutes ses GMAO proposent des solutions bien plus adaptées aux exigences du maître d'ouvrage qui dans ce plan constitue déjà en l'objet d'un problème lié à l'utilisation mais encore qui sont à des prix pas très abordables, c'est alors qu'il nous a été confié la tâche de mettre sur pied une application qui respectera les exigences aussi bien professionnelles qu'académiques dans l'optique d'un projet de fin d'études.

II.4 ARCHITECTURE ET TECHNOLOGIES À UTILISER

Vu que notre logiciel est une double application : une application Java standard (JSE) en couche basée sur une architecture 3-tiers et utilisant les technologies JPA/ Hibernate pour l'administration et une application web en couche basée sur une architecture 3-tiers, nous allons présenter les architectures et les outils à utiliser.

II.4.1 Architecture 3-tiers

L'architecture 3-tiers est une architecture ou on retrouve trois entités communicants ensemble. On peut avoir les cas suivant.

- Un client

- Un serveur d'application web (serveur web + moteur PHP) qui répond aux requêtes http de l'utilisateur.

- Un système de gestion de base de données (SGBD) qui traite et répond les requêtes qui lui sont émises par le serveur d'application.

Figure1 : Architecture 3-tiers

II.4.2 Architecture d'une application Java en couche

Afin de permettre l'indépendance et la réutilisation des composants, nous avons opté pour une architecture en couche. Ceci dit l'application sera divisée en cinq couches.

Couche Données : cette couche contient les données physiques stockées dans la base de données MySQL. Elle ne requiert pas d'implémentation Java particulière et fonctionne simplement comme un espace de consultation massif.

Couche Mapping : cette couche contient l'implémentation des accès à la base de données afin de la masquer à la couche métier. Cette couche est entièrement gérée par JPA.

Couche Métier : cette couche contient les objets métiers de l'application. Il existe un objet par fonctionnalité de l'application. Ces objets implémentent les fonctionnalités spécifiques relatives à la location de voitures, et font le lien entre la couche contrôleur et la couche Mapping.

Couche Application : cette couche contient la partie fonctionnelle de l'application. Elle s'appuie sur les objets métier pour réaliser les actions sollicitées par l'utilisateur par l'intermédiaire de la couche présentation. Elle est en charge de vérifier la validité des requêtes de la couche présentation.

Couche Présentation : cette couche représente les interfaces qui permettent à utilisateur d'interagir avec l'application.

Pour l'illustration, nous avons la figure suivante :

Figure2 : Architecture d'une application java en couche

II.4.3 JPA/Hibernate

L'idée principale de JPA est que le développeur n'ait besoin que de travailler avec de simples instances de classes et non pas avec des requêtes SQL dont il doit ensuite passer le résultat.

Hibernate vient se placer entre la couche [dao] écrite par le développeur et la couche [JDBC]. Hibernate est un ORM (Object Relational Mapping), un outil qui fait le pont entre le monde relationnel des bases de données et celui des objets manipulés par Java. Le développeur de la couche [dao] ne voit plus la couche [JDBC] ni les tables de la base de données dont il veut exploiter le contenu. Il ne voit que l'image objet de la base de données, image objet fournie par la couche [Hibernate]. La couche [Hibernate] est une couche d'abstraction qui se veut la plus transparente possible. L'idéal visé est que le développeur de la couche [dao] puisse ignorer totalement qu'il travaille avec une base de données.

II.4.4 FPDF

FPDF est une bibliothèque PHP qui aide dans la génération des états en fichier PDF. Il présente l'avantage d'être assez flexible, bien documenté.

II.4.5 AJAX

La technique de développement Ajax (acronyme d'Asynchronous JavaScript and XML) permet de construire des applications Web et des sites web dynamiques interactives sur le poste client. Ajax combine JavaScript, les CSS, XML, le DOM et le XMLHttpRequest afin d'améliorer maniabilité et confort d'utilisation des Applications Internet Riches.

II.4.1 Réplication MySQL

Depuis la version 3.23.15, MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et les autres serveurs servent d'esclaves. Le serveur entretient des logs binaires de toutes les modifications qui surviennent. Il entretient aussi un fichier d'index des fichiers de logs binaires, pour garder la trace de la rotation des logs. Chaque esclave, après connexion réussie au serveur maître, indique au maître le point qu'il avait atteint depuis la fin de la dernière réplication, puis rattrape les dernières modifications qui ont eu lieu, puis met en attente des prochains événements en provenance du maître. Un esclave peut aussi servir de maître à son tour, pour réaliser une chaîne de réplication.

Chapitre3 

III.1 SPÉCIFICATION FONCTIONNELLE DE L'APPLICATION

III.1.1 Fonctions du système

- Module gestion des équipements : Le système doit permettre l'ajout d'un équipement, enregistrer les informations relatives au type de l'appareil et son emplacement physique. Permettre la modification des données de l'équipement et le retirer lorsqu'il est mis en rancart. Le système permettra de trouver l'équipement selon son code ou sa variété.

- Module gestion des pièces détachées : Le système permettra d'ajouter dans la banque de données toutes les pièces qui s'avéreront un jour nécessaire pour une intervention et permettra aussi de faire une décrémentation quand celle-ci sera utilisée.

- Module gestion des fournisseurs : Le système permettra aussi d'enregistrer les fournisseurs en fonctions des services offerts et des types de partenariat.

- Module gestion des interventions : Le système gérera toute intervention qui surviendra sur équipement, il permettra d'accéder en interne à une fiche de suivi, d'y associer un nom d'utilisateur (pour bien gérer les historiques) avant d'y apporter certaines informations relatives au travail à accomplir. Il permettra aussi de planifier la maintenance préventive. Trois types de droits pourront être attribués : usager, technicien et administrateur.

- Module gestion des bons de commande : Ce module permettra à l'administrateur de directement ressortir les états afin de contacter les fournisseurs pour passer des commandes bien précises.

- Module gestion des techniciens : Ce module permettra à l'administrateur de créer et d'effectuer les mises à jour sur les techniciens ; c'est-à-dire création, affection dans un centre, suivi ...

- Module Statistiques : Ce module permettra de faire ressortir l'historique et certains diagrammes de toutes les opérations qui seront effectuées via cet outil afin d'avoir les rapports sur les différents modules.

III.1.2 Description des utilisateurs

Ce système a plusieurs types d'utilisateurs avec des droits d'accès différents et des restrictions d'utilisation qui seront définies aux niveaux de la couche présentation et de la couche application.

Ø Administrateur

Il est le super-utilisateur qui aura les droits d'accès à tous les différents modules ainsi qu'à leurs fonctions. Il pourra ainsi créer les autres utilisateurs et charger les informations dans l'application « GMABIO » afin de rendre l'application opérationnelle pour les autres utilisateurs.

Ø Technicien

Il est le personnage ayant le deuxième droit d'accès le plus élevé derrière l'administrateur lui permettant ainsi de renseigner toutes ses interventions et d'effectuer d'autres tâches en fonction des droits qui lui sont associés.

Ø L'usager (responsable de centre)

Il appartient à un centre et c'est donc via ce centre qu'il accède à l'application lui permettant ainsi d'effectuer une seule opération primordiale celui de déclarer une panne (demande d'intervention) mais en plus il pourra avoir accès à la liste des demandes d'intervention liées à son centre.

III.1.3 Fonctions liées aux droits d'accès

- L'utilisateur

Ses droits lui permettent juste de faire une demande d'intervention et d'afficher toute la liste de toutes les demandes faites par le centre auquel il est rattaché et commande les équipements.

- Le Technicien

Le technicien pourra accéder de façon générale à des modules tels que :

ü Equipements

ü Interventions

ü Pièces Détachées

ü Statistiques

Mais alors l'accès à ces modules ne sera que partiel car certains de ces modules leur permettra juste de bien renseigner leur opération d'intervention. Il s'agit des modules : Equipement (où ils pourront accéder à la liste des équipements se trouvant dans le centre où ils sont affectés), pièces détachées (qui leur permettra de changer les pièces défectueuses sur les équipements en panne) et statistiques (pour avoir certains rapports sur certaines fonctions les concernant directement).

Le module Interventions est le seul module qui pourra être totalement parcouru par un technicien.

- Administrateur

En ce qui concerne ce dernier il possède tous les droits sur les modules du système. Et c'est lui qui rend le système utilisable.

III.2 EXIGENCES SPÉCIFIQUES

Dans cette partie, les exigences du système seront définies de façon détaillée. Le niveau de détail permettra de procéder à la conception du système.

III.2.1 Interfaces externes

Cette section a pour but de décrire les différentes interfaces qu'offre ou nécessite le système GMABIO Solutions.

III.2.1.1 Interface usagers

o Client

L'interface usager est sous la forme WEB accessible via le site web du département à l'aide du navigateur Mozilla Firefox de préférence. Avant de pouvoir utiliser les fonctionnalités du système, l'usager devra s'authentifier à l'aide de son login et mot de passe en ce qui concerne le « technicien » et d'un mot de passe uniquement (mot de passe attribué par hôpital que seuls les employés d'une firme devraient savoir) pour l ' « utilisateur simple » bien sûr après avoir précisé l'hôpital où il est en fonction.

o Administrateur

L'interface administrateur est sous forme «Windows classique» installé sous sa machine. Avant de pouvoir utiliser les fonctionnalités du système, l'usager devra s'authentifier à l'aide de son login et mot de passe.

III.2.1.2 Interfaces matériels

On devra installer par centre des postes clés qui seront connectés à internet afin de permettre aux différents clients de pouvoir atteindre l'application hébergée.

III.2.1.3 Interfaces aux logiciels

La partie cliente du système aura un hyperlien sur le site web du département santé et offrira une interface WEB accessible via Mozilla Firefox tandis que le système administratif résidera sur la machine de l'administrateur.

III.2.1.4 Interfaces de communication

o . Client

A partir des postes client connecte au réseau internet, il sera possible d'accéder au site web.

o Administrateur

A partir de son poste connecte au réseau internet, l'administrateur sera capable d'accéder à la base de données distante via son application.

III.2.2 Spécification des cas d'utilisations

Diagramme des cas d'utilisation du système

Figure3 : Diagramme des cas d'Utilisation

Ø Fonctions du module d'Inventaire DM (gestion des équipements)

But :

Ces fonctions permettent de gérer les dispositifs médicaux des hôpitaux du département et offrent des techniques de recherche.

- Afficher équipements

· Fiche cas d'utilisation

Acteur(s): Administrateur, technicien

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de consulter les dispositifs médicaux auxquels il est rattaché.

Dépendances: AUTHENTIFIER

Pré-condition : L'acteur doit être authentifié.

Post-condition : La liste des DM est affichée à l'écran. Cette liste contient les informations suivantes concernant les DM: nom, emplacement, code CNEH, numéro de série, date de mise en service et le type.

Raisons : Pour aider l'administrateur du système dans le processus d'acquisition de nouveaux équipements et de remplacements ceux qui sont en pannes.

Exceptions :

Ligne 2 : Si la liste est vide, le système affiche un message «aucun équipement » indiquant qu'il n'a trouvé aucun équipement.

· Diagramme de séquence

Figure4 : Diagramme de séquence « Afficher liste Equipement »

- Afficher équipements Hors-services

· Fiche cas d'utilisation

Acteur(s): Administrateur, technicien

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de consulter tous les équipements qui sont hors service.

Dépendances: AUTHENTIFIER

Pré-condition : L'acteur doit être authentifié.

Post-condition : Une liste des équipements qui sont hors services est affichée à l'écran. Cette liste contient les informations suivantes concernant les équipements: nom, emplacement, code CNEH, numéro de série, date de mise en service et le type.

Raisons : Pour aider l'administrateur du système dans le processus d'acquisition de nouveaux équipements et de remplacer ceux qui sont en panne.

Exceptions :

Ligne 2 : Si la liste est vide, le système affiche un message «aucun équipement hors service» indiquant qu'il n'a pas trouvé les équipements dont le critère de recherche : staut de l'équipement = `hors service'.

- Ajouter équipement

· Fiche cas d'utilisation

Acteur(s): Administrateur

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet d'ajouter un équipement.

Dépendances: AUTHENTIFIER

Pré-condition : L'acteur doit être authentifié.

Post-condition : La fiche de l'équipement est créée et sauvegardée dans la base de données.

Exceptions :

Ligne 4: Si le nom existe déjà, le système affiche un message d'erreur et le traitement est interrompu.

- Supprimer équipement

· Fiche cas d'utilisation

Acteur(s): Administrateur.

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de supprimer un équipement.

Dépendances: AUTHENTIFIER

Pré-condition : authentification de l'acteur réussie

Post-condition : L'équipement est supprimé.

Post-condition : la suppression de l'équipement est effectué.

- Recherche d'équipements selon un attribut

· Fiche cas d'utilisation

Acteur(s): Administrateur, Technicien

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de rechercher un équipement à partir d'un attribut qui sera spécifié par l'acteur.

Dépendances: AUTHENTIFIER

Pré-condition : L'acteur doit être authentifié.

Post-condition : La fiche de description de l'équipement est affichée s'il s'agit d'un élément à retourner ou une liste s'il s'agit de plusieurs équipements.

Exceptions :

Ligne 2: Si un équipement identifié par l'attribut spécifié n'existe pas, affichage d'un message avertissant l'usager de la situation.

Recherche Avancée d'équipements

· Fiche cas d'utilisation

Acteur(s): Administrateur, Technicien

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de rechercher avec plus de précision un équipement.

Dépendances: AUTHENTIFIER

Pré-condition : L'acteur doit être authentifié.

Post-condition : La fiche de description de l'équipement est affichée.

Exceptions :

Ligne 3 : Si un équipement identifié par un ou plusieurs attributs choisis n'existe pas, affichage d'un message avertissant l'usager de la situation.

Ø Fonctions du module de gestion des interventions

But :

Ces fonctions permettent de gérer les interventions.

- Prévention maintenance

· Fiche cas d'utilisation

Acteur(s): Administrateur

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de planifier les dates d'interventions pour la maintenance préventive.

Dépendances: AUTHENTIFIER

Pré-condition : l'acteur doit être autorisé à l'aide de son identificateur utilisateur et son mot de passe.

Post-condition : les informations de prévention sont enregistrées.

- Commencer Intervention

· Fiche cas d'utilisation

Acteur(s): Administrateur, technicien

Description: Ce cas d'utilisation est déclenché par un acteur. Il lui permet de renseigner les informations concernant l'intervention qu'il effectue.

Dépendances: AUTHENTIFIER

Pré-condition : l'acteur doit être autorisé à l'aide de son identificateur utilisateur et son mot de passe, une panne doit être déclarée.

Post-condition : une fiche d'intervention est créée.

Ø Fonctions du module de gestion demander intervention

But :

Ces fonctions permettent de gérer les déclarations de panne.

- Déclaration de panne

· Fiche cas d'utilisation

Acteur(s): Utilisateur

Description: Ce cas d'utilisation est déclenché par un acteur ou par le système lorsque la date de maintenance préventive est arrivée. Il lui permet de déclarer une panne survenue sur un équipement.

Dépendances: AUTHENTIFIER

Pré-condition : l'acteur doit être autorisé à l'aide de son identificateur utilisateur et son mot de passe.

Post-condition : confirmation de déclaration.

III.3 MODÈLE OBJET DU SYSTÈME

III.3.1 Diagramme de classe du module gestion des interventions

Figure5 : Diagramme de classe « module Intervention »

III.3.2 Diagramme de classe du module gestion des équipement

Figure6 : Diagramme de classe « module Equipement »

III.3.3 Règles de gestion

Les règles de gestion décrivent la nature des relations entre les entités d'un système d'information. L'ensemble de ces règles permet de définir un système correspondant à une problématique métier précisément adaptée aux besoins du client. Ces règles de gestion sont utilisées directement dans le modèle métier : chaque règle correspond à une relation entre 2 (ou plusieurs) entités.

R1 : un type d'équipements rassemble un ou plusieurs dispositifs médicaux.

R2 : un technicien ne peut intervenir que sur un équipement qui a été l'objet d'une demande d'intervention.

R3 : un technicien ne peut avoir accès qu'aux interventions dont il est le coordonnateur.

R4 : plusieurs techniciens peuvent intervenir sur équipements dans le cadre où le premier technicien a recommandé un autre ou encore si l'administrateur a décidé de s'occuper d'un équipement qui faisait déjà l'objet d'une intervention.

R5 : un prestataire extérieur ne peut avoir accès à l'application, il doit avoir recourt à un technicien pour faire suite à une intervention faite sur équipement.

R6 : un équipement peut bénéficier d'un seul contrat partenaire.

R7 : le prix unitaire d'une pièce détachée est le prix unitaire du dernier stock entré au magasin.

III.4 EXIGENCES D'OPÉRATIONS, DE COMMUNICATIONS ET DE PERFORMANCE

Le flot de données entre les clients et le serveur web n'est pas excessif, on négligera le trafic occasionné par l'outil puisque la bande passante de la connexion internet sera de 256kbps.

III.5 EXIGENCE DE LA BASE DE DONNÉES

III.5.1 Modèle Conceptuel de données

La représentation du système d'information a été réalisée à l'aide du diagramme de classe et de la méthode MERISE. Cette méthode nous a permis de réaliser le Modèle Conceptuel de Données ou MCD, qui fait le lien entre le modèle métier et le modèle logique. Le MCD est un modèle dit « entités-relations » qui modélisent l'ensemble des règles de gestion et des contraintes du système. Il correspond globalement au modèle métier, en détaillant le contenu des entités métiers (attributs).

La construction du MCD a été réalisée à partir des spécifications du cahier des charges, du modèle métier et des réunions avec le maître d'ouvrage. Celui-ci a été généré grâce au logiciel Win Design, qui permet de transformer le MCD en MLR et de générer le script de la base de données correspondant.

III.6 CONCEPTION DE L'APPLICATION

III.6.1 Domaine d'Application

L'objectif de ce projet est de fournir un système destiné à gérer le parc des DM des hôpitaux et centres médicalisé du département santé de l'EEC. Ce système contient deux applications, une application d'administration installée au siège du département, et une application web héberger sur le web et accessible via un navigateur.

L'application d'administration permet d'avoir une vue global sur le système, de gérer et de contrôler le travail des techniciens sur le terrain tout en centralisant les informations sur les DM se trouvant dans les différents hôpitaux.

L'application web permet au technicien sur le terrain de renseigner leurs activités, d'avoir les informations sur les DM et aux usagers de déclarer les pannes.

III.6.2 Architecture du système

Figure7 : Architecture générale de l'application GMABIO Solution

III.6.3 Langages utilisés

Voici la liste des différents langages utilisés dans le projet GMABIO Solution:

- SQL pour les scripts de création de la base de données (création de tables et insertions des tuples dans la BD) ainsi que pour les requêtes spécifiques de l'AM.

- Java pour le développement de l'application administrative.

- HTML 5, CSS 3, PHP et JavaScript 2.0 pour le développement de l'application cliente.

- XML pour les fichiers de configuration Spring, JPA.

III.6.4 Diagramme de déploiement

Figure8 : Diagramme de déploiement

III.6.5 Architecture Générale du système

Chaque application bénéficie d'une architecture séparée, où le seul point commun est la base de données centrale. Dans ce paragraphe, nous allons nous attarder sur les problèmes d'architecture fondamentaux du système. Tous les autres choix de conception sont expliqués dans le chapitre « Conception détaillée ».

Figure9 : Architecture générale du système

III.6.5.1 Architecture 4 couches pour l'application administrative

L'application nationale est divisée en quatre couches de fonctionnalités, totalement autonomes les unes des autres, et communiquant par un système de file : chaque couche ne dialogue qu'avec les couches voisines supérieure et inférieure. Toutes les couches doivent agir de façon transparente les unes des autres. La séparation des couches est la suivante :

Couche Données : cette couche contient les données physiques stockées dans la base de données MySQL. Elle ne requiert pas d'implémentation Java particulière et fonctionne simplement comme un espace de consultation massif.

Couche Mapping : cette couche contient l'implémentation des accès à la base de données afin de la masquer à la couche métier. Cette couche est entièrement gérée par JPA.

Couche Métier : cette couche contient les objets métiers de l'application. Il existe un objet par fonctionnalité de l'application. Ces objets implémentent les fonctionnalités spécifiques relatives à la location de voitures, et font le lien entre la couche contrôleur et la couche mapping.

Couche Présentation : cette couche représente les interfaces qui permettent de présenter les contenus générés par la couche métier, grâce à des vues dynamiques (JAVA). Elle se charge d'afficher des contenus à l'utilisateur et de lui offrir des interfaces avec la couche contrôleur pour interagir avec l'application.

Figure10 : Architecture application d'administration

III.6.5.2 Synchronisation des données

La problématique de la synchronisation prend une part importante dans la conception du système et notamment de la base de données et des parties applicatives. Pour rappel ces synchronisations interviennent lorsque l'administrateur veut faire coïncider les données qu'il possède sur sa machine avec celles stockées en base de données centrale (sur le serveur distant). Le cas d'utilisation type se présente ainsi :

- Au démarrage du logiciel, l'application administrative se synchronise avec la base MySQL pour avoir des données à jour ;

- Lors de ses déplacements (vers une zone sans connexion), il peut consulter, modifier, insérer ou supprimer (ou tout autre opération possible) des données chargées dans la base de données sans connexion réseau ;

- Et une fois la connexion retrouvée, l'application administrative se chargera de synchroniser ses mises à jour et de récupérer celles des autres

III.6.5.3 Architecture de l'application cliente

Sur l'application cliente, la stratégie adoptée est d'utiliser un modèle en couches similaire. Cependant, la taille de l'application n'impose pas une séparation aussi fine que l'application nationale. Nous appliquons donc un modèle à 3 couches organisées comme suit :

Couche Présentation : cette couche effectue la présentation des données à l'utilisateur par l'intermédiaire de formulaires et de listes de données interactives. L'utilisateur accède à l'application par cet unique moyen ; elle est développée en HTML5-CSS3.

Couche Métier : de même que pour l'application administrative, cette couche contient d'une part les objets métier, correspondant aux données métier à manipuler dans l'application, d'autre part, les services métiers reliés à ces objets (création, recherche, suppression, modification et autres services spécifiques). A l'image de l'application administrative, cette couche s'occupe de garantir que le métier de l'application est respecté, que les règles liées aux données sont toujours suivies. Dans cette couche, on retrouve également les méthodes d'accès à la base de données (présentes dans la couche Données dans l'application administrative).

Couche Données : cette couche contient les données physiques stockées dans la base de données MySQL. A ce niveau, tenant compte du fait qu'on aura deux bases de données (une locale et l'autre distante) nous allons dans le cadre d'une mise à jour des bases de données gérer la fonction de réplication de bases de données pour résoudre les demandes à satisfaire par ce service.

Figure11 : Architecture application cliente

III.6.5.4 Gestion des Erreurs

Lorsqu'une erreur est rencontrée par un contrôleur, il place un message d'erreur dans le modèle. Celui-ci sera ensuite automatiquement affiché à l'utilisateur par la couche présentation.

Ø Compatibilité Firefox/Internet Explorer

La problématique de compatibilité entre les deux navigateurs les plus utilisés par les internautes doit être prise en compte très tôt, car ce sont surtout les styles CSS qui doivent être écrits avec ces contraintes. En effet, certains styles ne sont reconnus que par l'un ou l'autre des navigateurs. La feuille de style a été définie dès l'établissement des maquettes des écrans. Elle peut donc être utilisée tout au long du développement pour être testée.

Ø Authentification utilisateur

L'application GMABIO comporte une interface de gestion destinée à gérer les différents processus du département Santé EEC. Cette partie de l'application n'est pas destinée à être accessible par une personne extérieure. L'authentification des employés est donc nécessaire.

Les connexions utilisateurs sont effectuées par identification classique : login et mot de passe. Ces informations sont stockées dans la base de données, leur vérification est donc immédiate lors de l'authentification de l'utilisateur.

Ø Gestion des droits d'utilisateurs

Au sein du département, il existe plusieurs catégories d'employés qui n'ont pas accès aux mêmes fonctionnalités. Les groupes d'employés considérés sont les suivants :

- Chef service maintenance (administrateur)

- Techniciens

- utilisateur (celui en charge d'un dispositif Médical

Il est possible de définir des fonctionnalités au sein de l'application. Celles-ci pourront, pour chaque type d'employé, contenir le type d'autorisation d'accès défini. Par exemple, les techniciens n'auront pas accès aux fonctions liées à leur gestion ni d'autant plus à la gestion des différents centres. La solution est donc de stocker une matrice fonction/types d'utilisateurs qui permettra de savoir à un moment précis quels droits sont accordés à tel type d'utilisateur pour telle fonctionnalité.

Ø Sessions utilisateurs

L'authentification d'un utilisateur conduit à l'ouverture d'une session qui permettra à celui-ci de naviguer sur tout le site sans devoir s'identifier à chaque page. La technologie employée pour la réalisation du site permet de définir une session utilisateur contenant un nombre quelconque de variables de sessions, définies et existantes pendant toute la durée de la session.

Il est important de conserver le login (ou le nom associé) de l'employé connecté, pour des raisons de traçabilité. Les droits alloués à cet utilisateur doivent être conservés. On conserve donc les droits associés au type d'utilisateur auquel appartient l'employé. Lors de la connexion de l'utilisateur, une entité contenant les droits de celui-ci sera donc initialisée pour la session ouverte.

Ø Gestion interne de l'authentification

Il convient de détailler les différents composants qui rentrent en jeu lors d'une authentification utilisateur. Lors de la soumission du formulaire d'identification par l'utilisateur, une première vérification est effectuée, permettant de s'assurer que ni le champ de mot de passe, ni le champ de login ne sont vides. Ensuite, les données sont comparées avec les données stockées en base :

- vérifier que le mot de passe correspond bien à l'utilisateur ;

- dans le cas où le mot de passe est erroné, rediriger vers le formulaire avec une notification d'erreur ;

- dans le cas où le mot de passe est correct, charger les droits de l'utilisateur et rediriger vers la page d'accueil de l'application.

Chapitre 4

IV.1 ENVIRONNEMENT DE TRAVAIL

L'environnement de développement utilisé pour développer les applications a été Netbeans 6.9 qui est un IDE proposant tous les outils nécessaires à la création d'applications professionnelles avec les langages Java, C / C++, JavaScript, Ruby, PHP et HTML. En plus il permet une intégration facile des Framework comme JPA et Hibernate. Nous avons aussi utilisé EASYPHP qui intégre un serveur web (Apache), un interpréteur PHP avec le serveur de base de données MYSQL.

IV.2 DEMARCHE DE TRAVAIL

Après avoir spécifié et conçu le logiciel, nous avons créé un projet nommé « GMABIO » sous Netbeans 6.9, nous avons créé les paquetages « Entity», « Dao », « IHM », « Application »

- Paquetage « Entity»

Dans ce paquetage on crée une classe « Entity Classes from Database » qui permet après configuration d'éffectuer le Mapping entre la base de données et le projet, elle génère également les objets Persistants et le fichier persistence.xml.

- Paquetage « Dao»

Qui contient les classes Data Access Object des classes Entity généré par mapping. Ces classes permettent l'accès aux données des objets persistant.

- Paquetage « IHM »

Ce paquetage contient les classes des différentes interfaces de l'application d'administration.

- Paquetage « Application »

Il contient les classes de la couche application qui assure l'interaction entre les interfaces et les Dao.

Représentation des paquetages

Figure12 : Arborescence des paquetages

IV.3 DIFFICULTÉS RENCONTRÉS

Dans le développement de l'application « GMABIO Solution » nous avons rencontré plusieurs difficultés parmi lesquelles :

- La communication des deux bases de données (mise à jour)

- La gestion des interfaces

- La gestion des MVC

IV.4 RÉSULTATS OBTENUS

- Application d'administration

· Connexion

Figure13 : Interface de connexion application d'administration

· Fenêtre du Module gestion des Equipements

- Fenêtre de choix de l'opération

Figure14 : Fenêtre de choix de l'opération « module gestion équipements »

- Fenêtre fiche équipement

Figure15 : Interface fiche équipement

- Fenêtre de contrat de maintenance d'un équipement

Figure16 : Interface contrat maintenance « module gestion équipement »

- Application Cliente

· Connexion

Figure17 : Interface connexion application cliente

· Fenêtre Commencer Intervention

Figure18 : Interface commencer Intervention

Ce projet de fin d'étude est à cheval entre l'informatique qui est notre première compétence et la maintenance qui est aussi l'un des aspects de notre formation. Ce travail nous a permis, d'une part, d'approfondir nos connaissances en conception des systèmes d'informations, développement des applications 3 tiers et d'autre part de renforcer notre esprit d'organisation et de gestion du patrimoine technique des centres médicalisées mais aussi de profiter de l'expérience professionnelle de notre encadreur aussi bien en maintenance biomédicale qu'en management. Tout au long de ce projet, nous avons pu suivre le processus de maintenance d'un dispositif médical ce qui nous a donné les moyens nécessaires à la conception de notre solution « GMABIO Solution ».

Destiné à résoudre les problèmes de traçabilité des activités de maintenance, « GMABIO Solution» peut s'adapter à la plupart des structures médicales de la place.

Lors de la programmation de cette solution nous avons porté une grande attention à sa simplicité d'exploitation (par un environnement intuitif et des contrôles de saisi) afin de permettre au technicien ou à un utilisateur qui n'a pas de notion en informatique de s'adapter très vite; Cependant, comme tout travail humain, le nôtre peut comporter des imperfections et nous sommes ouverts aux critiques et suggestions en vue de l'améliorer.

Notre ambition est de faire évoluer « GMABIO Solution » en ajoutant d'autres fonctionnalités comme la gestion de tout le personnel technique, la commande d'équipements et de pièces détachées en ligne etc.

I. Référence bibliographique

- Apprenez à programmer en Java - site du zéro - cysboy et John-John

- Cours de génie logiciel dispensé par Monsieur TAKOUDJOU Alexis pour l'année scolaire 2011-2012

- Développer en AJAX - Michel Plasse - Eyrolles

- Java Persistance et Hibernate - Anthony Patricio - Eyrolles 2008

- Manuel de référence MySQL 5.0

- Système de gestion de maintenance assistée par ordinateur Série technique de l'OMS sur les dispositifs médicaux, 2012 ISBN 978 92 4 250141 4

II. Site web

- Encyclopédie en ligne - www.wikipedia.com

- Site web du logiciel Unigest, une GMAO - http://www.unigest.fr/index.php

- Notice simplifiée d'utilisation de votre gmao en ligne - http://www.biomesnil.com

Ø Cahier de charge : conception et Implémentation d'une GMAO pour le département santé de l'EEC.

Ø Document de spécification des exigences logiciel : conception et Implémentation d'une GMAO pour le département santé de l'EEC.

Ø Document de conception : conception et Implémentation d'une GMAO pour le département santé de l'EEC.

Ø Fiche d'intervention générer par « GMAOBIO Client »






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Le don sans la technique n'est qu'une maladie"