Université de Sousse

École Nationale d’Ingénieurs de Sousse

Rapport de projet module en génie logiciel :

Application de gestion de médicaments
Réalisé par :

Iftima Sendi

Filière : 2éme Année

Génie informatique appliquée Groupe 2

1
Table des matières
Tableau des figures ............................................................................. Erreur ! Signet non défini.
Fiche-synthèse des projets semestriels antérieurs................................ Erreur ! Signet non défini.
Introduction Générale .............................................................................................................. 5
Chapitre 1 :Cahier des charges ................................................................................................. 6
1. Introduction: ............................................................................................................................ 6
2. Objectif du projet: .................................................................................................................... 6
3. Etude préalable: ....................................................................................................................... 6
3.1. Étude de l’existant : ..................................................................................................................................... 6
3.2. Critique de l’existant :......................................................................................... Erreur ! Signet non défini.
3.3. Solutions proposées : ................................................................................................................................. 7

4. Conclusion : .............................................................................................................................. 7
Chapitre 2 : Conception et réalisation ....................................................................................... 8
I. Introduction : ....................................................................................................................... 8
II. Conception: ........................................................................................................................ 8
1.Analyse des besoins: ................................................................................. Erreur ! Signet non défini.
1.1. Besoins fonctionnels : ........................................................................................................................... 8
1.2. Besoins non fonctionnels : ................................................................................................................... 9

2. Identification des cas d’utilisation : ............................................................................................... 9

3. Conclusion: ................................................................................................................................. 10
III. Réalisation: .................................................................................. Erreur ! Signet non défini.
1. Introduction: ....................................................................................... Erreur ! Signet non défini.
2. Environnement de travail: ................................................................... Erreur ! Signet non défini.
3. Choix technologiques :......................................................................... Erreur ! Signet non défini.
3.1. Langage de programmation :...................................................................... Erreur ! Signet non défini.
3.2. Choix du Framework : ................................................................................ Erreur ! Signet non défini.
3.3. Choix de plateforme pour conception de la base de données : ................. Erreur ! Signet non défini.
4. Travail réalisé et scénarios d’exécution : .............................................. Erreur ! Signet non défini.

2
 4.1. Développement de la couche présentation : le front : ............................... Erreur ! Signet non défini.
4.2. Conception de la base de données : ............................................................ Erreur ! Signet non défini.

5. Conclusion : ......................................................................................... Erreur ! Signet non défini.

Conclusion générale ............................................................................ Erreur ! Signet non défini.

3
4
 Introduction Générale

Il s'agissait au cours du projet d'étudier et de développer une application mobile , avec l'avancée et
l'émergence des technologies mobiles, les développements sanitaires sont de plus en plus
progressées. Le médicament n’est pas un produit de consommation courante. Ses principes actifs
ont des effets sur l’organisme. Le bon usage du médicament commence par le respect de quelques
règles simples. Lors d’un traitement, il est important de respecter la durée, les doses prescrites et la
fréquence des prises. D'où nait l'idée de développer une application utile, à installer sur les
Smartphones permettant de scanner le code à barre d’un médicament pour connaître le mode
d’emploi et de suivre l’ordonnance du médecin en toute sécurité .
Mis à part le développement proprement dit de l'application, la première étape à choisir les outils
conviviaux et envisageables à l'aboutissement du projet. Par la suite, nous entamerons la
modélisation et le développement de l'application.

5
 Chapitre 1 :Étude au préalable

1. Introduction:
Dans ce premier chapitre, nous allons commencer en un premier lieu par expliquer le cadre du
projet . Puis faire notre étude préalable qui contient l’étude la critique de l’existant et nos solutions
proposées.

2. Objectif du projet:
Nous sommes demandés dans ce projet de faire la conception puis le développement d’une
application mobile qui permettre aux patients de découvrir le mode d’emploi d’un médicament à
l’aide d’un scan rapide du code à barre du produit et de profiter d’autres services médicaux.
Nous souhaitons exposer une méthode simple et cohérente d’avoir la manière de prendre un
médicament un un champ de recherche est aussi disponible.

3. Étude de faisabilité

Ce projet nécessite un effectif d’environ 2 à 3 personnes ayant des connaissances en

développement mobile . On estime que ce projet exige une durée de 2 à 3 mois pour être
réalisé et testé convenablement. Donc on peut conclure que ce projet est faisable.

4. Etude de marché :
Dans cette partie du rapport on va entamer l’étude de l’existant. On choisit les applications Medico
et GoodMed qui sont les plus connus dans ce domaine, puis on va le critiquer pour en déduire des
solutions qui seront proposés au sein de notre projet.

4.1. Le tableau de comparaison :

6
 L’application Les avantages Les inconvénients

GoodMed -Contient tout ce qui concerne un -Pas d’interaction avec le médecin

médicament(beaucoup
d’information)
-alerter les utilisateurs sur les
interactions médicamenteuses,
qui peuvent survenir .

Medico -Suivi en temps réel le prise d’un -Pas d’interaction avec le médecin
médicament .

-Contient une assistance pour les

personnes handicapées .

4.2. Solutions proposées :

L’application a été entièrement pensée à ces besoins qui soutient et accompagne les personnes
déficientes visuelles et facilite le traitement. L’idée, c’était de mettre l’essentiel dans cette
application. D’abord, elle permet au médecin de suivre les médicament prises par le patient.
Ensuite, elle peut scanner de façon performante les code-barres ou Datamatrix (codes
d’identification des médicaments) sur les boîtes. Enfin, elle permet d’accéder au nom du
médicament, à son dosage mais aussi à sa date de péremption .Elle contient aussi un assistant virtuel
(pharmacien) qui a le role d’alerter les utilisateurs sur les interactions médicamenteuses . En dernier
recours, un champ de recherche est aussi disponible.

5. Conclusion :
Dans ce chapitre, on a commencé par une présentation du cadre du projet dans laquelle on a décrit
son objectif. Puis, on a passé par une étude préalable qui contient l’étude de et la critique de
l’existant accompagné de quelques solutions proposées. A ce qui concerne le chapitre suivant, on
s’intéressera à l’ analyse des besoins fonctionnels et non fonctionnels et á la spécification de ces
besoins.

7
 Chapitre 2 : Spécification des besoins

I. Introduction :
Avant de commencer le développement ou la réalisation d’une solution qui répond aux besoins
demandés il est nécessaire de faire sa conception. Dans cette étape nous nous intéressons à la
conception globale et l’analyse des besoins dans laquelle on va en un premier lieu les différents
acteurs intervenants dans l’application .

II. Analyse des besoins:

1. Identification des acteurs :
Notre application a pour cible : Le patient et son médecin
2. Besoin fonctionnels :

Enregistrement du Patient :
• Le système doit permettre au patient de créer un profil avec des informations telles que le
nom, l'âge, le sexe, les antécédents médicaux et les allergies.
• Le système doit permettre au médecin d'accéder et de mettre à jour les informations du patient.
Prescription de Médicaments :
• Le médecin doit pouvoir prescrire des médicaments pour un patient spécifique, en
spécifiant la posologie, la durée du traitement et les instructions.
• Le patient doit recevoir des notifications pour ses prescriptions, rappelant les heures de
prise, les interactions possibles avec d'autres médicaments, etc.
Gestion des Stocks de Médicaments :
• Le médecin doit avoir la possibilité de consulter l'inventaire des médicaments disponibles.
• Le système doit informer le médecin lorsque le stock d'un médicament est faible.
Suivi des Prises de Médicaments :
8
 • Le patient doit pouvoir enregistrer chaque prise de médicament dans l'application.
• Le médecin doit avoir accès à un historique des prises de médicaments du patient.
Interaction Patient-Médecin :
• Le patient doit pouvoir communiquer avec son médecin via la messagerie intégrée dans
l'application.
• Le médecin doit recevoir des notifications en cas de messages non lus ou d'urgence
signalée par le patient.
Historique des Consultations :
• Le médecin doit avoir accès à un historique complet des consultations avec le patient, y
compris les prescriptions précédentes, les résultats de tests, etc.
Alertes et Rappels :
• Le système doit envoyer des rappels au patient pour les rendez-vous médicaux, les prises
de médicaments, les examens à effectuer, etc.
• Le médecin doit recevoir des alertes pour les rendez-vous à venir et les tâches médicales
planifiées.
3. Besoins non fonctionnels :
Les besoins non fonctionnels forment l’ensemble des contraintes techniques auxquelles notre
système doit répondre.
Sécurité et Confidentialité :
La confidentialité des données médicales doit être assurée par des mécanismes de cryptage
robustes, un contrôle d'accès strict et des procédures de gestion des identités. La conformité aux
normes de sécurité médicale, peut également être nécessaire.
Performances :
Les utilisateurs, tant les patients que les médecins, s'attendent à une expérience fluide et rapide.
La gestion efficace des charges de travail, en particulier aux heures de pointe, est également un
aspect crucial.
Convivialité :
L'interface utilisateur doit être conviviale pour que les patients puissent facilement enregistrer
leurs prises de médicaments, accéder à leurs prescriptions et communiquer avec leurs médecins.
De même, l'interface pour les médecins doit faciliter la prescription, la consultation des
antécédents médicaux et la communication avec les patients.
Conformité Réglementaire :
L'application doit être conforme aux réglementations en vigueur dans le domaine de la santé. Cela
peut inclure la conformité aux normes médicales, aux lois sur la protection des données et autres
réglementations locales et internationales.
Fiabilité et Disponibilité :
La fiabilité de l'application est cruciale pour garantir que les informations médicales sont toujours
accessibles. Une disponibilité élevée, avec une tolérance aux pannes minimale, est essentielle
pour assurer que les patients peuvent accéder à leurs données médicales et que les médecins
peuvent effectuer leurs tâches sans interruption.

2. Identification des cas d’utilisation :

Un cas d'utilisation (use case) représente un ensemble de séquences d'action qui sont réalisées par
le système et qui produisent un résultat observable intéressant pour un acteur particulier. Il

9
permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera [8].
Reprenons un à un les quatre acteurs et listons les différentes façons qu'ils ont d'utiliser le futur
système. •

Patient :

• Créer un compte utilisateur.

• Consulter son espace user.
• Consulter l’historique de ses médicament.

Nous situons ici le diagramme de cas d’utilisation global de notre application .

Fig.1 : Diagramme de cas d’utilisation globale

3. Conclusion:
Dans ce chapitre nous avons commencé par une analyse des besoins dans laquelle nous avons cité
nos besoins fonctionnels et non fonctionnels. Puis nous avons décrit la conception en se basant sur
les diagrammes de cas d’utilisation de l’ UML. Dans la partie suivante on va entamer la réalisation
de notre application.

10