Stage Fabien Ménager

Planning des tâches à accomplir

Formation initiale

Semaine 1

• Prise en main de l'environnement de développement
• Développement d'un module pour Mediboard
• Rapide prise en main de l'API
• Etude d'un module simple de facturation
• Développement du module de Forum
• Correction de la part de Thomas
• Optimisation pour utiliser au mieux l'API

Semaine 2

Le but de cette semaine est de mettre en place l'environnement de travail autant matériel que logiciel.

• Réalisation d'une architecture client / serveur web pour libérer le poste de travail déjà assez lent comme ça :
  • L'ancien poste de travail devient le serveur :
    • Installation de SSH et Webmin pour administrer sans soucis (avec les modules pour Webmin : Apache, PHP, gestion des paquets logiciels, mySQL)
    • Désactivation de GDM (Gnome Display Manager) du démarrage pour libérer de la RAM
    • Mise en place en place du partage de fichiers :
      • NFS sur /home en écriture
      • Samba sur /home avec gestion des utilisateurs pour ceux qui se serviront de mon serveur pour leurs tests sous Windows
    • Installation de differentes extensions pour PHP :
    • APC pour gerer du cache, l'opCode de PHP pour accélérer
    • xDebug pour avoir des traces, des points d'arrêt, tout ce qu'il faut pour debugger

• Utilisation d'une autre machine a laquelle j'ajoute 512Mo de RAM :
  • Installation de Ubuntu Desktop 7.10
  • Mise a jour des paquets (sudo apt-get upgrade)
  • Patience
  • Installation de JVA JRE 1.6 et suppression de l'interpreteur de bytecode java GNU (GIJ)
  • Installation d'Eclipse (sudo apt-get install eclipse)
  • et non, ca ne suffit pas car impossible d'installer l'outil de dév PHP pour Eclipse
  • Désinstallation ce qui vient d'être installé
  • Téléchargement du pack PDT (PHP Development tool) de Eclipse qui a deja tout d'integré, mais c'est moins propre, tant pis
  • Rajout Subclipse pour gérer le SVN et être synchro avec les autres
  • Installation de KcacheGrind qui permet de visualiser et utiliser les rapports faits par xDebug puis mise en place du partage des fichiers générés par xDebug

Génération d'une doc Doxygen (PHPdoc) de Mediboard, car elle n'existe pas. Le code est assez bien commenté, malgré encore quelques trous noirs, que nous allons peut etre combler. En fait ils n'ont pas besoin de la doc grâce à Eclipse qui fait l'aide a la saisie, et tout ça, qui leur donne toutes les infos qu'il faut sur les variables et methodes qui sont deja dans le code, mais pour ceux qui arrivent juste, c'est assez difficile, d'autant plus que les docs sont utiles.

Semaine 3

• Releasing Mediboard v0.5
• Test Tracker item 351 : Mise en cache des CodeCCAM
  • Premiere etape terminé: constructeur caché pour la classe CCodeCCAM pour garder des elements en statique :
    • Liste des classes chargées
    • Liste des niveaux de chargement des classes
    • Diverses infos statistiques
  • Seconde etape en test : Mise en memoire partagée de tout cela pour le partage entre les utilisateurs et tout le long des sessions pour raisons de performances
• En cours icones PNG medicaments
• Terminé Tracker item 347 : Messagerie par module
• Pas mal de peer-programming avec Alexis :
  • Terminé, 2 jours Mise en place du selecteur de modèles de documents pour pouvoir ajouter par exemple des compte rendus de type "Patient" à des "Operations". Avant on ne pouvait pas faire de telles associations, c'est bien pratique pour les praticiens.
  • Mise en place des identifiants externes IMEDS : permettent d'envoyer des résulats de labo vers un serveurs IMEDS. Les identifiants permettent de faire le lien entre un utilisateur de Mediboard (docteur, praticien...) et son compte IMEDS. Nous avons mis en place une page qui permet de definir un login et un mot de passe IMEDS pour chacun d'entre eux, il sera envoyé par methode POST a la page de soumission des resultats.

Semaine 4

• Mise en place d'une fonctionnalité de parametrage de la sureté des mots de passe :

Au changement ou a la definition des mots de passe, on verifie en direct la sureté du mot de passe selon plusieurs critères :

• Longueur
• Composition de lettre et chiffres
• Ne contient pas le login

On utilise 2 niveaux de sureté : (variable de config "strong_password" = 1 ou 0, dans l'optique de mettre d'autres niveaux par la suite) Le plus faible définit seulement un mot de passe comme suffisant s'il est composé d'au minimum 4 caractères Le plus élevé :6 caractères au minimum, doit contenir des lettres et des chiffres, ne doit pas contenir le login. Implémentation :

• Je voulais d'abord faire seulement un controle "en direct", en javascript lors de la saisie du nouveau mot de passe. Mais je me suis rendu compte qu'il y avait deja des specifications pour cela : chaque champs de chaque object a des "Specs" qui definissent le format, comme la taille min, taille max, composé de chiffres seulement, pas de balises HTML, etc

Je m'en suis alors servi, en definissant un format "password" qui utilisait le "minLength", mais aussi d'autres specs que j'ai definies : "alphaAndNum" et "notContaining" associé au nom d'un autre champs (en l'occurence, ici : le nom de l'utilisateur).

• J'ai du faire le parallèle en PHP, pour faire un 2eme contrôle, et au cas ou Javascript est désactivé.

Cependant, les fonction existantes pour vérifier tout cela ne le font qu'a la soumission des formulaires (fonction checkForm), j'ai du rajouter une fonction "checkFormElement" qui contrôle la validité d'un seul élément de formulaire HTML (je ne l'ai faite que pour des champs password pour le moment, mais c'est facilement evolutif). Cette fonction est appelée au relachement des touches lorsque l'on tape dans le champs (evenement "onKeyUp"), elle met a jour une balise <div> ou <span> que je mets tout pret du champs HTML a controler (met un message comme "Securité trop faible", et un fond rouge ou vert).

• J'ai passé le plus de temps sur l'implantation en PHP car elle mettait en oeuvre beaucoup d'appels entre objets. Notamment les classes CMediusers et CUser qui sont proches, mais totalement séparées et on été difficiles à modifier.

Semaines 5 et 6

Réalisation du module de gestion des stocks

Ce module doit permettre la gestion complète des stocks d'un établissement de santé. Il est réalisé dans le cadre du remplacement du logiciel Generics de la Générale de Santé utilisé par la pharmacie d'une clinique cliente. Une étude a été faite auprès de la responsable de celle-ci. Voici un cahier des charges se rapprochant des attentes du client, réalisé dans le cadre d'une autre étude.

Planning prévisionnel :

Le planning lié au cahier des charges ci-dessus :

• Les entrées : 15j
  • Gestion des commandes : 2j
  • Réception des commandes : 3j
  • Facturation : 9j
  • Retour des services : 1j
• Les sorties : 15j
  • Gestion des sorties : 7j
  • Délivrance globale et nominatives : 7j
  • Gestion des reliquats : 1j
• Les inventaires : 7j

Total : 37j

Ce planning avait été fait par mon maitre de stage, mais pour un développeur qui connait déjà Mediboard.

Voici celui que je projette de respecter (le début n'est pas une prévision, mais ce que j'ai réellement fait):

• Etude du cahier des charges : 1j
• Elaboration de la structure globale des données : 2j
• Developpement de la structure de base de toutes les classes : 3j
  • Inspiration de l'ancien module
  • Utilisation des possibilités du framework pour accélérer le développement

• Elaboration des premiers éléments d'IHM : 3j
  • utilisation de ces classes réalisées et prise en main du moteur de templates
    • Edition des Sociétés (fournisseurs, fabricants), liste des catégories de produits, gestion des produits
  • Etude de l'ergonomie même pour les choses les plus simples

• Etude des classes nécessitant des IHM plus avancées (stocks, commandes) : 4j
  • Debut d'IHM utilisant Ajax :
    • Gestion des stocks, references produits, mais surtout edition et reception des commandes
  • Mise en place de liens entre les éléments du module pour l'ergonomie (editeur de commandes)

• Révision de certains éléments de structure pour prendre en compte : les reliquats de commandes, commandes automatiques, alertes, administration des produits aux patients, tracabilité : 4j

• Réalisation plus avancée de l'IHM en revoyant le cahier des charges : 8j
  • Amélioration de l'ergonomie
  • Révision de la structure des templates
  • Ajout de fonctionnalités avancées nouvellement intégrées dans la structure

• Lien entre le module de stocks et les besoins dans tout Mediboard : 8j

• Phase de tests avancés : 3j

Total : 36j

Ce que nous faisons déjà

• Gestion des fournisseurs
• Gestion des références fournisseurs (association fournisseur / matériel avec prix et quantité)
• Gestion des catégories de matériel
• Gestion des fiches matériel
• Création de commandes
• Visualisation des stocks

Etude de la demande

Nous indiquerons en italique les éléments à développer.

Les entrées

• Gestion des commandes
  • Création du bon de commande
    • En fonction d'une référence fournisseur
  • Préparation commande fournisseur
    • Gestion des proposition automatique / semi-automatique en fonction des stocks actuels et en commande
    • Gestion des historiques de consommation
  • Identification des produits avec commande en cours (nous avons une liste des commandes en cours)
  • Envoi de la commande par fax (difficile à faire)
  • Envoi de la commande par e-mail
  • Modification de la commande avant réception
  • Suppression de commandes
  • Edition des reliquats de commande et des produits non livrés

• Réception des commandes
  • Réception à partir du numéro de commande ou du nom du fournisseur
  • Possibilité de réceptionner globalement la commande
  • Possibilité de réceptionner la commande ligne par ligne
  • Possibilité de réceptionner sur plusieurs commandes
  • Gestion des reliquats de commande
  • Accès à la fiche article pour mise à jour paramètres
  • Message d'alerte si dépassement du stock optimum
  • Gestion des unités gratuites
  • possibilité d'effectuer une réception sans commande
  • Possibilité de saisir des produits tracés (numéro de lot et date de péremption)
  • Tout le bon de commande est à créer

• Facturation
  • Action déportée vers la comptabilité (liaison compta)
  • Mini module de facturation inter-établissement

• Retour des services
  • Réintégration des produits dans le stock

Les sorties

• Gestion des sorties
  • Gestion complète des sorties à créer
• Délivrance globale et nominatives
  • Gestion complète des délivrances à créer
• Gestion des reliquats
  • Visualiser, livrer, solder les reliquats

Les inventaires

• Gestion des inventaires de pharmacie et des services : actuellement, les stocks sont globaux à un établissement
• édition des plans d'inventaires
• Filtres pour l'édition d'inventaires
• Valorisation automatique en fonction des PUMP

7ere semaine :

Un module de gestion des stocks existant déjà, mais loin d'être complet, je suis parti de zero après avoir étudié les differents documents que l'on m'a fourni, et ai fait un modele de structure des données que voici :

Il a changé jusqu'a maintenant mais la structure est restée a peu pres identique. Les classes ont été réalisées juste après, en se basant sur le framework Mediboard qui permet des relations de toutes sortes entre les objets, et très simplement. Ce projet me permet de me familiariser avec ce framework dans le but de realiser des projets plus importants et toucher au coeur de ce framework.

Durant cette semaine, en plus de mettre en place les classes, certaines ameliorations possibles du framework se sont montrées, ont été mises en place et ont permis d'accelerer Mediboard de 30 dans certains cas. D'autres potentielles sont encore visibles, mais seront mises en place plus tard par l'equipe de developpement.

8eme semaine :

Completion des classes en fonction du travail sur l'interface graphique du module.

La premiere partie de celle-ci a consisté à réaliser l'edition des societés, des categories, gestion des listes de produits, de references fournisseurs et ensuite des stocks, un peu plus complexes car voués à etre des données dynamiques, donc l'interface est très importante (les liste des sociétés et des categories de produits peuvent pratiquement être considées comme statiques, mais surement pas la liste des stocks ni celle des références fournisseurs).

Le gestionnaire de commande est commencé, mais ne permet pas toutes les fonctionnalités demandées, comme la reception des commandes, cependant des commandes peuvent etre remplies en Ajax pour plus de rapidité et ensuite passées.

3eme semaine :

Suite de la réalisation du gestionnaire de commandes et implantation du module de déstockage (sortie du stock pour aller dans un service). Une page de rapports a été réalisée pour visualiser rapidement les stocks qui ont besoin d'être réapprovisionnés.

Les gestionnaire de commande fut grandement remanié et permet maintenant de remplir des commande automatiquement en fonction des stocks actuels et des stocks après réception des commandes passées mais pas encore reçues.

Les templates du gestionnaire de commandes ont été aussi refaits pour éviter la répétition du code et faciliter les changements. D'autres refactorisations sont prévues pour les autres parties du module.

9eme semaine

Développement d'un nouvel élement de formulaire du type champs texte avec fleches pour incrementer une valeur numérique. Le développement c'est déroulé en 1 journée, mais quelques problemes se sont posés, et a été mis en pause en attendant mon responsable de stage. Le schéma de données a été mis a jour en fonction de ce que j'ai développé :

10eme semaine

Travail sur l'ergonomie de Mediboard et suppression de quelques librairies Javascript devenues obsolètes.

• Remplacement des "accordeons" http://demos.openrico.org/demos/accordion qui sont trop lents, pas pratiques, pour laisser place à des tabulations du genre de celles de Firefox, basées sur Prototype.js et donc suppression de la librairie Rico. Certains accordeons avaient un comportement non ordinaire, il a fallu le retranscrire sur les tabulations (dont la sauvegarde en cookie pour garder le dernier accordeon consulté, et revenir dessus au prochain chargement de la page). Un style pour les tabulations peut etre facilement mis dans la CSS (ce qui n'etait pas le cas pour les accordéons, qui avaient un style defini en dur)
• optimisation de quelques fonctions de requetes de bases de données
• Suppression de la dependance aux librairies Gosu (plein de fonction standard mais non presentes dans le ECMA script, qui existent dans Prototype (ou y ressemblent)
• Un theme nommé phenx a été commencé : basé sur la simplicité et la clarté, utilise au maximum les possibilité de CSS (pas encore pour le moment, jattends quelques gros refactorings, notamment celui de la prochaine version, pour pour voir changer certaines choses et pouvoir simplifier enormement le code HTML et CSS)

11eme semaine

Suite du développement du module des gestion des stocks :

• Amelioration du code : factorisation, decoupage en fichiers Javascript
• meilleurs prise en compte de la tracabilité en enregistrant un code au destockage d'un produit et a son administration (pose d'une prothèse, prise d'un médicament...) et possibilité de lier à une base BCB grace au code associé au produit
• Possibilité de choisir le format des numeros de commande
• debut d'internationalisation
• nouvelle fonction permettant d'obtenir la valeur d'un attribut d'un objet (formatée grace aux specs)
• ajout d'un onglet "Commandes validées" pour rendre conforme le workflow des commandes
• ajout de filtres en Ajax à tous les onglets (facilités grace a une classe JS Filter)
• optimisation de quelques requetes SQL.

12eme semaine

• Ajout de la possibilité de redimensionner en hauteur toutes les zones de texte de Mediboard, la hauteur de chacune d'elle est sauvgardée en cookie. Je me suis basé sur le CMS Drupal qui implemente cette fonction, mais ai du reecrire tout le code pour utiliser Prototype.js. Cette possibilité est meme extensible à tous les elements de la DOM grace a Prototype, mais peu utile pour nous.
• Ajout de l'impression du bon de commande
• Realisation d'une interface graphique qui permet d'associer un etat a chaque dent d'un patient (utilisé dans la consultation d'anethésie pour l'intubation). Réalisé en javascript, elle se base sur des zone de map HTML circulaire mises sur une image (schema dentaire), recupere les coordonnées de ces cercles, et pose de div qui auront un comportement defini de prendront la couleur desirée en fonction de l'etat donné a la dent :

13eme et 14eme semaines

Environnement de développement

• Système de vérification de présence d'indexes sur les champs des types : ref, date, datetime : Terminé (refaction de tout l'ancien système, permet d'avoir plus de détails). Fournit des suggestions de requetes autant pour rajouter des index, qu'en enlever (index en double)...

Plan du rapport de stage :

• Introduction
  • Présentation de la société, de la fac et des infos sur le stage (dates...).
  • Présentation de Mediboard et de son implication dans les établissements de santé

• Projet principal
  • Contexte et besoins
  • Aspects de la gestion de stocks
  • Architecture du système de gestion
  • Réalisation
  • Interaction avec le reste du système

• Projets annexes
  • Administration système et installation d'un serveur web
  • Amélioration des performances de Mediboard
  • Amélioration de l'ergonomie et de l'esthétique
  • Fonctionnalités diverses (dents, graphiques...)
  • Mise en place de constantes médicales et de graphiques dynamiques

• Bilan et suite du stage

---