PROJET
Application de gestion des médicaments
Cahier des charges
1. Contexte : Le laboratoire GSB 1
2. Définition du besoin 1
Définition de l'objet 1
Forme de l'objet 2
Accessibilité/Sécurité 2
3. Contraintes 2
Ergonomie 2
Codage 2
Documents 2
Livrables 2
Environnement 3
Modules 3
Responsabilités 3
4. Description du domaine de gestion 3
La gestion des médicaments 3
Processus à informatiser 3
5. L’existant 4
6. Architecture technique 5
7. Organisation du projet 5
1. Contexte : Le laboratoire GSB
Présentation du contexte : GSB_PrésentationDuContexte.doc
2. Définition du besoin Définition de l'objet
L'activité commerciale d'un laboratoire pharmaceutique est principalement réalisée par les visiteurs médicaux. En effet, un médicament remboursé par la sécurité sociale n’est jamais vendu directement au consommateur mais prescrit au patient par son médecin.
Toute communication publicitaire sur les médicaments remboursés est d'ailleurs interdite par la loi. Il est donc important, pour l’industrie pharmaceutique, de promouvoir ses produits directement auprès des praticiens.
Les produits distribués par le laboratoire sont des médicaments : ils sont identifiés par un numéro de produit (dépôt légal) qui correspond à un nom commercial (ce nom étant utilisé par les visiteurs et les médecins).
Comme tout médicament, un produit a des effets thérapeutiques et des contre-indications.
On connait sa composition (liste des composants et quantité) et les interactions qu'il peut avoir avec d'autres médicaments (éléments nécessaires à la présentation aux médecins).
La posologie (quantité périodique par type d’individu : adulte, jeune adulte, enfant, jeune enfant ou nourrisson) dépend de la présentation et du dosage.
Un produit relève d’une famille (antihistaminique, antidépresseur, antibiotique, …).
Lors d'une visite auprès d'un médecin, un visiteur présente un ou plusieurs produits pour lesquels il pourra laisser des échantillons. De manière à pouvoir gérer les coûts des visites, le prix de l'échantillon est une donnée à retenir dans la base.
Forme de l'objet
L'application Web présentant les médicaments sera en ligne, accessible depuis un ordinateur.
La partie permettant la mise à jour des médicaments sera aussi sous forme d'une interface Web.
Accessibilité/Sécurité
L'environnement doit être accessible aux seuls acteurs de l'entreprise.
Une authentification préalable sera nécessaire pour l'accès au contenu.
3. Contraintes Ergonomie
Une charte graphique, en harmonie avec le logo GSB, devra être définie et proposée.
Codage
Le document “NormeDevlptPHP.doc” présente des règles de bonnes pratiques de développement utilisées par le service informatique de GSB pour encadrer le développement d’applications en PHP et en faciliter la maintenance ; l’application fournie s’efforce de les mettre en œuvre.
Les éléments à fournir devront respecter le nommage des fichiers, variables et paramètres, ainsi que les codes couleurs et la disposition des éléments déjà fournis.
Documents
La DSI de GSB met à la disposition du prestataire de service une maquette du dossier de spécifications fonctionnelles et techniques.
Livrables
Tous les documents livrés par le prestataire devront porter un nom respectant les règles de normalisation en cours chez GSB :
NomduProjet_TypeDeDocument_NomPertinent
Parmi les types de documents on pourra trouver :
BD
|
Documents en rapport avec la base de données
|
Symfony
|
Documents en rapport avec le projet symfony
|
DS
|
Dossier de spécification
|
DU
|
Documentation utilisateur
|
DT
|
Documentation technique
|
….
|
|
Environnement
L'utilisation de bibliothèques, API est à l'appréciation du prestataire.
L’utilisation du framework php est imposée par GSB : Symfony.
Modules
L'application présente les modules :
Consultation des médicaments
Mise à jour des médicaments
Responsabilités
Le commanditaire fournira à la demande toute information sur le contexte nécessaire à la production de l'application.
Le prestataire est à l'initiative de toute proposition technique complémentaire.
Le prestataire fournira un système opérationnel, une documentation technique permettant un transfert de compétence et un mode opératoire propre à chaque module.
4. Description du domaine de gestion La gestion des médicaments
La gestion des médicaments demande un suivi très précis.
Cette application est destinée aux visiteurs médicaux et aux administrateurs.
Cette application web est destinée aux visiteurs médicaux et administrateurs de la base de données des médicaments. Les premiers pour consulter les informations concernant les médicaments, les seconds pour réaliser la mise à jour de la base de données des médicaments.
Processus à informatiser
L’accès au site de gestion des médicaments doit être soumis à authentification préalable.
GSB souhaite mettre en place deux types de profils :
Les visiteurs médicaux
Les délégués régionaux
La page d’accueil du site devra être la liste des médicaments.
Une fois authentifié, un message de bienvenue contenant au moins le login et le rôle de l’internaute devra apparaître en entête de chacune des pages.
Après authentification,
les visiteurs médicaux accèdent :
A la liste des médicaments : Cette liste doit présenter pour chaque médicament, son numéro de dépôt légal, son nom commercial ainsi que le nom de sa famille. Par défaut la liste sera triée sur le numéro de dépôt légal.
A différents critères de tri de cette liste : Par numéro de dépôt et par nom commercial.
A partir de cette liste à la fiche détail d’un médicament présentant : le numéro de dépôt du médicament, son nom commercial, le nom de sa famille, ses éventuels effets secondaires et contre-indications, le prix de son échantillon ainsi que sa composition.
Des fonctionnalités de tri, de filtre et de recherche devront être proposées.
Les délégués régionaux ont quant à eux accès, en plus, à l’ensemble des fonctionnalités de gestion de la base de données des médicaments :
Consultation, ajout, modification et suppression des médicaments
Consultation, ajout, modification et suppression des familles
La demande de suppression d’une famille doit bien évidemment être impossible s’il existe des médicaments rattachés à cette famille. Dans ce cas, un message devra en informer l’utilisateur et lui donner la liste des médicaments concernés.
Consultation, ajout, modification et suppression des compositions
La demande de suppression d’une composition doit bien évidemment être impossible s’il existe des médicaments contenant cette composition. Dans ce cas, un message devra en informer l’utilisateur et lui donner la liste des médicaments concernés.
5. L’existant
Un stagiaire a déjà réalisé la modélisation de la base de données, modélisation qui a été validée par la DSI.
Le modèle de cette base GestMed_BD_GMedi.mcd vous est fourni au format WinDesign.
Ce modèle a été réalisé grâce à l’étude d’un script SQL contenant l’ordre de création d’une table médicament ainsi que les ordres d’insertion de certains médicaments : ScriptMedicament.sql.
Ce script est exploitable avec SQL Server.
La DSI souhaite reprendre les données de cette table.
Il est possible de récupérer dans l’avenir d’autres scripts d’insertion de médicaments, selon le même format. Aussi, la DSI souhaite que le prestataire de service fournisse la procédure de reprise des données à partir d’un script SQL.
Cette procédure de reprise des données devra être détaillée dans un document technique. Le choix de la forme de cette procédure est laissé au prestataire : Scripts SQL, procédures stockées, programme php, programme C#, macro, transfert de données au format CSV, XML, …etc.
Ces données devront être donc automatiquement insérées dans la future base de données implémentée dans le SGBDR choisi par GSB : Mysql.
6. Architecture technique
La DSI souhaite que l’application de gestion des médicaments soit réalisée via une interface WEB.
Le choix des outils de réalisation s’est donc porté sur :
Serveur Web : Apache
Langage de programmation : Php
Framework : Symfony
Base de données : Mysql
7. Organisation du projet
La DSI a signé une convention de stage avec trois étudiants en BTS SIO afin qu’il réalise l’application de gestion des médicaments.
Deux étudiants sont développeurs (DEV) et le troisième est nommé chef de projet (CP).
Le CP a la responsabilité du projet, doit coordonner l'équipe de développeurs, affecter les activités à chacun et rendre compte à la DSI de l'avancement du projet ainsi que des difficultés rencontrées.
Au début de chaque mission, le CP a donc la charge d’affecter les différentes tâches à mener à chacun des membres de son équipe.
A la fin de chaque mission, il a en charge de présenter le bilan de l’avancée des missions. Ce bilan est à réaliser en concertation avec les membres de son équipe. Le formalisme de ce bilan est laissé à sa libre appréciation.
Contexte GSB Application de Gestion de Médicaments
|
