Pfepfe

République Tunisienne
Ministère de l‘Enseignement Supérieur et de la Recherche Scientifique

Université de Jendouba
Faculté des Sciences Juridiques, Économiques et de Gestion de

Jendouba
Département Informatique
Rapport : Projet de fin d’étude
Présenté en vue de l’obtention du
Diplôme de Licence Fondamentale en Informatique Appliquée à la Gestion
Sujet
Création et développement d’un
Blockchain Médical
Realisé par : Sabrine Khemiri
Encadré par : Mr.Mongi Boulehmi
Année universitaire : 2020-2021

Remerciements
Je voudrais bien remercier notre dieu pour nous avoir donné la force et la fois
pour que nous puissions achever ce projet de fin d’étude.
Tout d’abord, ce travail ne serait pas aussi riche et n’aurait pas pu avoir le jour sans
l’aide et l’encadrement de Mr Mongi Boulehmi, On le remercie pour la qualité de son
encadrement exceptionnel, pour sa patience, sa disponibilité durant notre préparation
de ce projet.
Je tenais à remercier aussi toute l’équipe pédagogique de la faculté des Sciences
Juridiques, Économiques et Gestion de Jendouba.
Je remercie également tous mes enseignements pour le pleine d’intérêt durant ma
période d’étude.
Mes profonds remerciements vont aux membres de jurys qui ont accepté d’évaluer ce
travail.
...
Dédicace
Je dédie ce travail À mon cher père Ali qui a été pour moi l’exemple de devoir
et de travail et qui a su me guider dans mes études, qu’il trouve ici l’expression de
ma gratitude et de mon amour,
À ma chère mère, Latifa pour tout l’amour et la patience qu’elle m’a offerte, qui a
toujours été à mes côtés pour me soutenir et m’encourager,
À ma sœur Safe, mes frères Mohamed et Marwen, ma grand-mère qui ont partagé
avec moi tous les moments d’émotion lors de la réalisation de ce travail. Ils m’ont
supporté et encouragé et motivé tout au long de mon parcours,
À mon Nièce Ahmed Bayram, je vous aime fort et je ferai mieux pour être une super
tata, tu as déjà pris sa place dans notre cœur,
À tous mes amis qui m’ont toujours encouragé, et à qui je souhaite plus de sucées.
...
Table des matières
Table des figures vii
Introduction générale 1
1 Présentation générale du projet 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Critique des solutions existantes . . . . . . . . . . . . . . . . . 4
1.2.3 Application similaire « DOSSIER Médicaux » . . . . . . . . . 9
1.2.4 Comparaison et critique des solutions existantes . . . . . . . . 13
1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.3 La méthodologie Scrum . . . . . . . . . . . . . . . . . . . . . 15
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Analyse et spécification des besoins 18

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 20
2.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Initialisation du projet 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Carte d’identité du projet . . . . . . . . . . . . . . . . . . . . . . . . 28
ii
TABLE DES MATIÈRES
3.3 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 sArchitecture logicielle . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Conecption détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . 30
3.5.2 Diagramme de classe global . . . . . . . . . . . . . . . . . . . 32
3.5.3 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . 33
3.5.4 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . 33
3.5.5 Diagramme de composants . . . . . . . . . . . . . . . . . . . . 34
3.6 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 35
3.6.2 Environnement technique . . . . . . . . . . . . . . . . . . . . 35
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Mise en œuvre du release 1 42

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Sprint1 : gestion d’accès . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Backlog du sprint 1 de gestion d’accès . . . . . . . . . . . . . 42
4.2.2 Tableau de tâches . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.1 Interface d’inscription . . . . . . . . . . . . . . . . . . . . . . 51
4.3.2 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Sprint1 : Administration . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.1 Tableau de tâches . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Sprint 3 : « Médecin » . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
iii
TABLE DES MATIÈRES

5.5 Sprint 4 « Patient » . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5.1 Bocklog du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.5.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.6 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2 Sprint5 : Analyste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2.1 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . 96
6.2.3 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Conclusiongénérale 109
bibliography 110
A Annexe 1
iv
Table des figures
1.1 Capture d’écran de l’Accueil de l’application « Med »[6] . . . . . . . . 6

1.2 Capture d’écran de l’interface des spécialités de l’application « Med
»[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Capture d’écran de liste des médecins de l’application « Med »[6] . . 8
1.4 Capture d’écran de l’interface d’inscription de l’application « DOS-
SIER Médicaux »[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Capture d’écran de l’interface d’inscription de l’application « DOS-
SIER Médicaux »[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Capture d’écran de l’interface de menu de l’application « DOOSIER
Médicaux »[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Capture d’écran de l’interface de rendez-vous de l’application « DOS-
SIER Médicaux »[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Gestion du Projet en SCRUM [11] . . . . . . . . . . . . . . . . . . . . 16
2.1 Liste des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Organigramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Organigramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Carte d’identité du projet . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 architecture logique [34] . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Architecture logicielle MVC[24] . . . . . . . . . . . . . . . . . . . . . 30
3.4 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . 31
3.5 Diagramme de classe global . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 Diagramme de paquetage . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . 33
3.8 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . 34
3.9 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.10 Vagrant[19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.11 git[31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Virtuel Box[20] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.13 Mysql workbench[32] . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
v
TABLE DES FIGURES
3.14 Android Studio[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.15 Apache[26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.16 Python[22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.17 Frameworkflask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.18 Laravel [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.19 Composer [25] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.20 Visuel code [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.21 Notepad ++[29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.22 Php 7[27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.23 StarUML [30] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.24 Trello [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.25 overleaf [33] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Tableau de tâches de sprint 1 . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Cas d’utilisation «Gestion d’accès» . . . . . . . . . . . . . . . . . . . 45
4.3 Diagramme de classe d’utilisateur de sprint 1 . . . . . . . . . . . . . . 46
4.4 Diagramme de package de sprint 1 . . . . . . . . . . . . . . . . . . . 48
4.5 Diagramme de séquence « S’inscrire » . . . . . . . . . . . . . . . . . . 49
4.6 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . . . 50
4.7 Diagramme d’activité de sprint 1 "S’inscrire" . . . . . . . . . . . . . . 51
4.8 Diagramme d’activité de sprint 1 "S’authentifier" . . . . . . . . . . . . 51
4.9 Capture d’écran d’interface "Inscription" de patient . . . . . . . . . . 52
4.10 Capture d’écran d’interface "Login" d’administrateur . . . . . . . . . 53
4.11 Capture d’écran d’interface "Login" de patient . . . . . . . . . . . . . 53
4.13 Cas d’utilisation « Administration » . . . . . . . . . . . . . . . . . . . 58
4.14 Diagramme de classe de sprint 2 « Administrateur » . . . . . . . . . . 58
4.16 Conception détaillée de sprint 2 . . . . . . . . . . . . . . . . . . . . . 60
4.17 Diagramme de séquence « Ajouter Hôpital » . . . . . . . . . . . . . . 61
4.18 Diagramme de séquence « Modifier Cadre médical » . . . . . . . . . . 62
4.19 Diagramme de séquence « Supprimer pharmacie » . . . . . . . . . . . 63
4.20 diagramme d’activité " Ajouter hôpital" . . . . . . . . . . . . . . . . . 63
4.21 diagramme d’activité " modifier cadre médical" . . . . . . . . . . . . . 64
4.22 diagramme d’activité " supprimer pharmacie" . . . . . . . . . . . . . 64

5.2 Cas d’utilisation de sprint 3 . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Diagramme de classe de sprint 3 . . . . . . . . . . . . . . . . . . . . . 72
5.6 Diagramme de séquence « Modifier profil » . . . . . . . . . . . . . . . 75
5.7 Diagramme de séquence « Ajouter analyse » . . . . . . . . . . . . . . 76
5.8 Diagramme de séquence « Consulter ordonnance ». . . . . . . . . . . 77
vi
TABLE DES FIGURES
5.9 Diagramme de séquence « Supprimer consultation » . . . . . . . . . . 78

5.10 Diagramme de séquence « demande l’accès » . . . . . . . . . . . . . . 78
5.11 Diagramme d’activité « ajouter consultation » . . . . . . . . . . . . . 79
5.12 Diagramme d’activité « diagramme d’activité "supprimer consultation"» 79
5.13 Diagramme d’activité « demande l’accès à l’historique médical de
patient » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.14 Tableau de tâches de sprint4 . . . . . . . . . . . . . . . . . . . . . . . 81
5.19 Diagramme de séquence « Prise rendez-vous » . . . . . . . . . . . . . 92
5.20 Diagramme de séquence « Contacter médecin textuelle » . . . . . . . 93
5.21 Diagramme de séquence « Chercher Médecin » . . . . . . . . . . . . . 94

6.2 Diagramme de cas d’utilisation de sprint 5 . . . . . . . . . . . . . . . 100
6.5 Diagramme de séquence « Modifier recommandation » . . . . . . . . 103
6.6 Diagramme de séquence « Supprimer recommandation » . . . . . . . 104
6.7 Diagramme de séquence « Créer recommandation » . . . . . . . . . . 105
6.8 Diagramme de séquence « Chercher recommandation » . . . . . . . . 106
6.9 Diagramme d’activité « supprimer recommandation » . . . . . . . . . 106
6.10 Diagramme de séquence « Créer recommandation » . . . . . . . . . . 107
6.11 Diagramme de séquence «Modifier recommandation » . . . . . . . . . 107
A.1 capture 1 de statistique de l’enquête de question 1 . . . . . . . . . . . 1

vii
Liste des tableaux
1.1 Analyse technique de l’application « Med » . . . . . . . . . . . . . . . 5

1.2 Analyse technique de l’application « DOOSIER Médicaux » . . . . . 9
1.3 Tableau de comparaison et critique . . . . . . . . . . . . . . . . . . . 13
2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Tableau descriptif de sprint 1 «S’inscrire» . . . . . . . . . . . . . . . 44
4.3 Tableau descriptif de sprint 1 «S’authentifier» . . . . . . . . . . . . . 45
4.4 la description des classes du sprint 1 . . . . . . . . . . . . . . . . . . 47
4.5 Tableau de test et validation de sprint 1 . . . . . . . . . . . . . . . . 54
4.7 Tableau descriptif de sprint 2 « ajouter hôpital » . . . . . . . . . . . 55
4.8 Tableau descriptif de sprint 2 « modifier cadre médical » . . . . . . . 56
4.9 Tableau descriptif de sprint 2« supprimer pharmacie » . . . . . . . . 57
4.10 Tableau descriptif de sprint 2« Affecter médecin à l’hôpital » . . . . . 57

5.2 Tableau descriptif de sprint 3 « Modifier profil » . . . . . . . . . . . . 68
5.3 Tableau descriptif de sprint 3 « Consulter ordonnance » . . . . . . . . 68
5.4 Tableau descriptif de sprint 3 « Supprimer consultation » . . . . . . . 69
5.5 Tableau descriptif de sprint 3 « Demande l’accès » . . . . . . . . . . . 70
5.6 Tableau descriptif de sprint 3 « Ajouter analyse » . . . . . . . . . . . 71
5.10 Tableau descriptif de sprint4 « Prendre un rendez-vous » . . . . . . . 82
5.11 Tableau descriptive de sprint4 « Contacter médecin textuelle » . . . . 83
5.12 Tableau descriptive de sprint4 « Chercher Médecin » . . . . . . . . . 84
viii
LISTE DES TABLEAUX
5.13 Tableau descriptive de sprint4 « accès à l’historique (suivi état santé) » 85


6.2 Tableau descriptive « Créer recommandation » . . . . . . . . . . . . . 97
6.3 Tableau descriptive « Modifier recommandation » . . . . . . . . . . . 98
6.4 Tableau descriptive « Supprimer recommandation » . . . . . . . . . . 99
6.5 Tableau descriptive « Chercher recommandation » . . . . . . . . . . . 100
6.7 Tableau test et validation de sprint 5 . . . . . . . . . . . . . . . . . . 108
0
Introduction générale
Le secteur de la santé fait face à de nombreuses problématiques que certaines en-

treprises cherchent aujourd’hui à résoudre. Les principaux concernent l’éparpillement
des données médicales, les contrefaçons de médicaments et le manque de transpa-
rence dans la recherche.
Plusieurs acteurs de la santé s’intéressent de près à la création d’un registre

patient distribué, pouvant par exemple s’appuyer sur une architecture blockchain.
Actuellement, l’information n’est pas partagée entre les différents médecins, et le
patient doit lui-même reporter les comptes rendus de ses précédentes consultations
auprès de chaque nouveau spécialiste. Une mission d’autant plus difficile pour un
patient non averti ne maîtrisant pas le discours médical et n’ayant pas une idée
précise du contenu de son dossier.
La santé n’est pas un secteur comme les autres et doit répondre à des règles
de confidentialité particulièrement strictes. Pour fonctionner dans le domaine de la
santé, une blockchain doit en premier lieu garantir la protection et l’anonymat des
données patientes.
C’est dans ce contexte que se situe ce travail qui consiste à concevoir et implé-
menter une application web mobile, ayant pour objectif de faciliter les échanges de
données entre les cadres médicaux, de mieux sécuriser les données des patients.
Pour cela notre projet permet :
• Peut détecter la maladie plus rapide.
• Gagner le temps.
• La protection et l’échange de données médicales de patient.
• L’efficacité, la rapidité, la traçabilité et la transparence
• Faciliter les services médicaux au patient.
Approche :
Blockchain : est une technologie de stockage et de transmission d’informations, trans-
parente, sécurisée, et fonctionnant sans organe central de contrôle Elle est la tech-
nologie au cœur du Web Décentralisé.
1
CHAPITRE 0. INTRODUCTION GÉNÉRALE
Elle constitue une base de données qui contient l’historique de tous les échanges ef-
fectués entre ses utilisateurs depuis sa création. Cette base de données est sécurisée
et distribuée.
Nous essayerons de présenter dans ce qui suit l’organisation de notre rapport :
• Le premier chapitre Présentation Générale du Projet est un chapitre introduc-

tif dans lequel nous effectuons une brève description de l’application. Ensuite, nous
exposons le cadre général du projet et la solution proposée.
• Le second chapitre nommé Analyse et Spécification des Besoins dédié la réalisa-
tion de ce travail avec la méthodologie Scrum. Nous dégageons également les besoins
fonctionnels dans un Backlog de produit et nous définissons le planning des sprints.
Par la suite, nous spécifions les besoins fonctionnels illustrés par des diagrammes de
cas d’utilisation avec quelques scénarios suivis d’une spécification des besoins non
fonctionnels de notre application.
• Le troisième chapitre est mis en œuvre de relise du projet est dédié à l’initialisation
du projet et la mise en place de l’environnement de développement, l’architecture
ainsi que l’environnement matériel et logicielle. • Le quatrième chapitre dédié au
une release de notre application ou nous intéressons à la réalisation des deux sprints
répartis chacun en quatre module, analyse, conception, réalisation et test.
• Le cinquième chapitre dédié au deux releases de notre application ou nous inté-
ressons à la réalisation des cinq sprints répartis chacun en quatre module, analyse,
conception, réalisation et test.
• Le sixième chapitre dédié au release 3 de notre application ou nous intéressons à
la réalisation des une sprint répartis chacun en quatre module, analyse, conception,
réalisation et test.
• Nous achevons ce rapport par une conclusion générale et des perspectives.
fancyhdr
Sabrine Khemiri 2 Blockchain Médical

Chapitre 1
Présentation générale du projet
1.1 Introduction
Dans ce chapitre, nous allons présenter en premier lieu une petite définition
et la mise en place de l’application, En citant quelques problèmes de l’existant et
l’ensemble des solutions proposées pour éviter ces problèmes et enfin nous allons
expliquer le choix méthodologie.
1.2 Présentation du Projet

Ce projet rentre dans le cadre du projet de fin d’études qui vient de conclure notre
formation de licence informatique appliquée à la gestion au Faculté des Sciences Ju-
ridiques Économiques et Gestion de Jendouba.
L’application se demandée s’intitule Blockchain Médical. Elle a pour objectif de

la conception et le développement d’une Blockchain Médical.
Cette application est destinée aux cadres médicaux et les patients pour la pro-
tection et l’échange de données médicales, faciliter la traçabilité, l’efficacité et la
rapidité.
fancyhdr La mise en place d’un Blockchain médical nécessite le développement
de trois axes à savoir :
o Axe Gestion du projet : utilisation de la méthode agile Scrum.
o Axe modélisation conceptuelle : utilisation du langage de modélisation UML

(Unied Modeling Language) pour développer les axes fonctionnel, statique et dyna-
mique.
3
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET
o Axe de développement : utilisation du langage PHP7, Android, Python, Lare-

vel et l’utilisation de la plateforme de développement vagrant et Git.
1.2.1 Problématique
Aujourd’hui, le domaine de santé a de nombreuses problématiques que certaines
entreprises cherchent à résoudre. Les principaux concernent la sécurise et l’échange
des données personnelles de patient, la traçabilité des dossiers médicaux et le manque
de transparence dans la recherche.
1.2.2 Critique des solutions existantes

L’étude de l’existant permet de déterminer les points faibles et les points forts
d’un produit actuel pour pouvoir déterminer les besoins du client, en vue d’en
prendre en considération lors de la conception et la réalisation de produit infor-
matique.
Dans cette section, nous présentons une analyse de quelques exemples d’applications
marchands.
Ensuite, nous formulerons une solution de la problématique.
1.2.2.1 Application similaire « Med »

Description
« Med » est une application mobile qui permet de chercher des médecins, les phar-
macies ouvertes, prendre de rendez-vous et chercher les médicaments selon le classe
qui choisit.
Analyse fonctionnelle de « Med »

Cette application permet aux Patients de :
• Chercher des médecins
• Chercher la pharmacie ouverte
• Chercher un médicament selon les classes thérapeutiques ou sous classes.
• Prendre un rendez-vous
• Peut poser des questions
Analyse technique

Table 1.1 – Analyse technique de l’application « Med »
Dénotations Description
Logo Il s’agit de un couleur « bleu » Il se situe à la gauche de
la page
La page d’accueil est dispo- Cette disposition donne un sens de lecture qui rend la
sée verticalement page plus simple mais je veux que non organisé
Liste de menu se trouve Liste de menu se trouve verticalement et horizontale-
verticalement et horizonta- ment .
lement .
La gamme de couleurs utili- Le Blanc est pour l’utilisation dans l’arrière-plan, Le
sés est blanc , noir , bleu et noir est utilisé pour le menu à gauche, Le Bleu est utilisé
jaune dans la liste de menue horizontale et dans le logo de liste
de menu, Le jaune est pour l’utilisation dans l’arrière-
plan de bouton de « chercher médecin » et le bouton de
« Poser votre question gratuitement » et dans le logo de
Pharmacies, de médicaments et le favori.
L’assemblage de ces couleurs donne une cohérence aux
différentes pages d’application.
L’interface de l’authentifica- L’interface de l’authentification et d’inscription est plus
tion et d’inscription simple connecter par E-mail ou numéro de téléphone et
par Mot de passe ou connecter se trouve dans le menu
verticale ou à droite de haut de l’interface , s’inscrire à
partir de Facebook ou Google.
L’interface de Spécialités et L’interface de Spécialités et de chercher de médecin est
de chercher de médecin bien organisée et détaillées.
Nous avons constaté que cette application est utilisée le pays Tunis

Figure 1.1 – Capture d’écran de l’Accueil de l’application « Med »[6]

Figure 1.2 – Capture d’écran de l’interface des spécialités de l’application « Med

»[6]

Figure 1.3 – Capture d’écran de liste des médecins de l’application « Med »[6]

1.2.3 Application similaire « DOSSIER Médicaux »

Description
« DOSSIER Médicaux » est une application mobile qui faciliter les services médi-
caux de patient.
Analyse fonctionnelle
Cette application permet aux Patients de :
• Faire de visite médicale.
• Faire de consultation en ligne.
• Recevoir les tests de laboratoire, les ordonnances et les radiologies.
• Attribuer un rendez-vous.
Analyse technique
Table 1.2 – Analyse technique de l’application « DOOSIER Médicaux »
Dénotations Description
Logo Se présente sous forme d’un image de médecin Il s’agit
de un couleur « blanc » Il se situe à la gauche a le haut
de la page.
La page d’accueil est La page d’accueil présenter sous forme de liste de menu
disposée verticalement , cette disposition donne un sens de lecture qui rend la
page plus simple et organisé.
Liste de menu se Menu organisé et facilite aux patients la recherche .
trouve verticalement
dans la page d’accueil.
La gamme de couleurs Le Blanc est pour l’utilisation dans l’arrière-plan et dans
utilisés est blanc et le logo d’application. Le Bleu est utilisé dans la liste de
bleu. menu et le design. L’assemblage de ces couleurs donne
une cohérence aux différentes interfaces d’application
L’interface d’inscrip- L’interface d’inscription est plus simple
tion
Nous avons constaté que cette application est utilisée le pays étranger

Figure 1.4 – Capture d’écran de l’interface d’inscription de l’application « DOS-

SIER Médicaux »[7]

Figure 1.5 – Capture d’écran de l’interface d’inscription de l’application « DOS-


Figure 1.6 – Capture d’écran de l’interface de menu de l’application « DOOSIER

Médicaux »[7]

Figure 1.7 – Capture d’écran de l’interface de rendez-vous de l’application « DOS-

1.2.4 Comparaison et critique des solutions existantes

Notes : 1(très limité),2(limité),3(moyen),4(bon),5(excellent)
Table 1.3 – Tableau de comparaison et critique
Critère Med DOSSIER Médicaux

L’ergonomie 4 4
Sécurité 3 5
Fiabilité 2 3
Disponibilité 3 1
Performance 3 2

Les problèmes :
« Application Med »
-Problème de mise à jour
- Problème de connexion
-Application incomplète : ne donne aucun accès au médecins, ne renvoi aucun noti-
fication ou email.
- Manque des informations
« DOSSIERS Médicaux »
-Trop difficile et pas pratique à utiliser.
- design simple
-difficile à le patient utilisé
1.3 Solution proposée

En se concentrant sur ce thème et pour remédier aux problèmes précédemment
cités, nous a cloné la mission de concevoir et de réaliser une application que nous
avons appelés : Blockchain médicale.
Blockchain médical est divisée par 5 modules sont :

• Module 1 : Administrateur.
• Module 2 : Médecin
• Module 3 : Patient
• Module 4 : Analyste
• Module 5 : Portail web
De plus, ce projet répond à un besoin Santé très important qui a comme but de
stocker et sécuriser le dossier médical et l’historique de tous échanges, la traçabi-
lité des patients, la transmission d’informations et faciliter la communication ou le
contact entre les médecins et les patients dans le cadre médical et les patients.
1.4 Méthode de développement

La réalisation du projet dans les délais de livraison est le souci majeur de chaque
équipe de développement d’un logiciel. L’un des problèmes les plus fréquemment
arrentés lors de la construction du logiciel est la mauvaise spécification et le change-
ment brusque des besoins. Cela peut influencer non seulement l’équipe de dévelop-
pement en créant un environnement de stress, mais aussi le temps consacré pour la
réalisation du projet et donc des délais de livraison dépassées.
Pour éviter ces situations critiques, nous adoptons la méthodologie agile pour la
gestion de notre projet.

1.4.1 Méthode Agile

Les problématiques précédemment mentionnées ont poussé les informaticiens à
réinventer les méthodes de gestion de projet et de conception en introduisant ce qu’on
appelle les méthodes agiles. C’est une approche incrémentale et itérative, menée dans
un esprit collaboratif, avec juste ce qu’il faut de formalisme. Elle peut générer un
produit de bonne qualité tout en prenant en compte l’évolution des besoins des
clients.
En suivant cette approche, le logiciel est conçu dans son ensemble et peut être
construit étape par étape.
1.4.2 Méthode adoptée

Parmi les méthodes agiles, nous citons Scrum que nous avons choisi pour les
raisons suivantes :
• Entièrement développée et testée pour de courtes itérations, simplicité des pro-
cessus.
• Augmentation de productivité.
• Elle permet d’adapter le logiciel crée suivant l’évolution du projet.
1.4.3 La méthodologie Scrum

Scrum est la méthodologie suivie par la société Sopra HR Software pour la ges-
tion de ses projets. C’est une méthodologie agile itérative basée sur des itérations de
courtes durées appelées Sprints. Lorsqu’on dit Scrum, il faut comprendre les mots
clés suivants :
• Responsable Produit : le représentant des clients et des utilisateurs. Il déter-

mine ce qui doit être réalisé.
• Scrum Master : le responsable du déroulement du processus. Il garantit la moti-
vation de l’équipe et l’e cécité de la collaboration entre les membres.
• Équipe projet : Les développeurs chargés de la construction du logiciel et d’en

faire une démonstration.
• Backlog du produit : tout le travail est encadré par le Backlog. En met, tout
le projet est découpé en un ensemble de "User Stories" classés par priorité et listés
dans le backlog.
• Backlog du sprint : une sélection de tâches retenues du "backlog du produit"

pour construire l’objectif du sprint.
• Daily Meeting : c’est un point quotidien qui permet de mettre le point sur ce
qui a été réalisé, les problèmes rencontrés et les objectifs de la journée.

• Démonstration du sprint : on la nomme aussi "Sprint Review". C’est une

réunion programmée à la n de chaque sprint durant laquelle l’équipe projet peut
présenter son travail. Sur la base de cette démonstration, le responsable produit
valide ce qui a été réalisé et détermine le nouvel objectif en se basant sur le Backlog
du produit et si jamais il y a un ajout ou bien une modification dans ce dernier.
Figure 1.8 – Gestion du Projet en SCRUM [11]
1.4.3.1 Les rôles Scrum :

L’équipe Scrum est constituée d’un propriétaire de produit, de l’équipe de dé-
veloppement et d’un Scrum Master. Le modèle d’équipe de Scrum est conçu pour
optimiser la flexibilité, la créativité et la productivité.
Nous allons tout d’abord tenter de cerner notre équipe Scrum :
• Product Owner (PO) : Monsieur Mongi Boulehmi Son rôle est d’assurer la
présentation des caractéristiques et des fonctionnalités du produit à développer et
approbation du produit à livrer.
• Scrum Master (SM) : Monsieur Mongi Boulehmi Le Scrum Master assure glo-
balement la Supervision de l’avancement du projet et des activités de l’équipe. Il
assure également l’organisation des réunions et la bonne application de la méthode
AGILE de par ce biais.
• L’équipe de développement : Monsieur Mongi Boulehmi Il comporte une ou

plusieurs personnes qui se chargent de la réalisation des histoires utilisateurs et éla-

boration des sprints.
• L’équipe de développement : Madame Sabrine Khemiri Elle comporte une

ou plusieurs personnes qui se chargent de la réalisation des histoires utilisateurs et
élaboration des sprints.
1.5 Conclusion
Au cours de ce chapitre, nous avons présenté la présentation et étudier de l’exis-
tant. Par ailleurs, nous avons présenté le choix de la méthodologie de développement,
Nous passons au chapitre suivant auquel nous allons faire l’étude des besoins fonc-
tionnelles et non fonctionnelles.
fancyhdr

Chapitre 2
Analyse et spécification des besoins
2.1 Introduction
Ce chapitre présente l’étude des besoins qui constitue une phase d’analyse du
projet.
Nous allons présenter tout d’abord, les acteurs principaux de l’application.
Puis, nous allons présenter les besoins fonctionnels et non fonctionnels de la fu-
ture application Ensuite nous présenté le Backlog de produit et la planification des
sprints.
Enfin, en conclure par le diagramme de cas d’utilisation global.
2.2 Identification des acteurs

Un acteur est une personne ou un autre système informatique qui attend un ou
plusieurs services offerts par l’application. Il interagit avec le système par envoi ou
réception des messages. Par conséquent, nous identifions quatre acteurs :
Figure 2.1 – Liste des acteurs
• Acteur 1 : Administrateur est un acteur incontournable du projet et la per-

formance de sa prestation impacte directement la performance du projet dans son
18
CHAPITRE 2. ANALYSE ET SPÉCIFICATION DES BESOINS
ensemble, il est responsable des différents paramétrages de l’application. Son rôle

est géré les o Et les hôpitaux, les cadres médicaux, les médecins et les pharmacies.
• Acteur 2 : Médecin est un acteur principal, la personne qui consulte l’appli-

cation web, il a besoin de demande la confirmation de patient pour accéder à leur
historique personnel, contacter patient et le détecter la maladie plus rapide et de
gérer les patients, les médecins, les analyses, les ordonnances, les consultations et le
rendez-vous.
• Acteur 3 : Patient est un acteur principal, la personne qui consulte l’application

mobile, il a besoin de connecté pour accéder à leur historique personnel, chercher
médecin et le contacter et aussi peut prendre rendez-vous, recevoir leurs ordonnances
et leurs analyses.
• Acteur 4 : Analyste est l’analyseur, est un acteur secondaire. Son rôle est étu-
dié et décomposé les différentes fonctions et analyse les besoins de client.
Identification des besoins L’identification des besoins consiste à traduire les objec-
tifs du projet en un ensemble de fonctionnalités ciblées par l’outil à réaliser. Ceci
procurera une compréhension plus approfondie des tâches à mettre en œuvre.
2.2.1 Besoins fonctionnels

Les fonctions pour l’administrateur sont :
• Authentification : l’administrateur doit entrer pseudo et password pour accéder
en toute sécurité à son espace de travail.
• Gestion des hôpitaux : l’administrateur doit avoir l’accès et à la possibilité de
gérer les informations concernant les hôpitaux de son application.
• Gestion des cadres médicaux : l’administrateur doit avoir l’accès et à la possibilité
de gérer les informations concernant les cadres médicaux de son application.
• Gestion des médecins : l’administrateur doit avoir l’accès et à la possibilité de
gérer les informations concernant les médecins de son application.
• Gestion des pharmacies : l’administrateur doit avoir l’accès et à la possibilité de
gérer les informations concernant les pharmacies de son application.
Les fonctions pour le médecin sont :

• Authentification : le médecin doit entrer pseudo et password pour accéder en toute
sécurité à son espace de travail.
• Inscription : l’utilisateur qui n’est pas inscrit, il doit entrer ses coordonnées per-
sonnelles et obtenir un pseudo et password pour rejoint à l’application.
• Gestion des patients : le médecin peut gérer les informations concernant la gestion
des patients.
• Gestion des ordonnances le médecin peut gérer les informations concernant la
gestion des ordonnances.

• Gestion des analyses : le médecin peut gérer les informations concernant la gestion
des analyses.
• Gestion des consultations : le médecin peut gérer les informations concernant la
gestion des consultations.
• Gestion des rendez-vous : le médecin peut gérer les informations concernant la
gestion des rendez-vous.
• Accès au dossier médical de patient : pour accès au dossier médical de patient, le
médecin doit connecter et envoyer une demande d’acceptation au patient.
Les fonctions pour le patient sont :

• Accepter ou refuser la demande de médecin : pour accepter ou refuser la demande
de médecin, le patient doit être connecter.
• Authentification : : le patient doit entrer un email et password pour accéder en
toute sécurité à son espace de travail. • Inscription : le patient qui n’est pas inscrit,
il doit
entrer ses coordonnées personnelles et obtenir un email et password pour rejoint à
l’application.
• Prendre un rendez-vous : pour prise un rendez-vous, le patient doit choisi spécia-
lité et chercher médecin.
• Recevoir les ordonnances : le patient accéder à l’application pour recevoir les or-
donnances.
• Recevoir les analyses : le patient accéder à l’application pour recevoir les ordon-
nances.
• Contacter médecin : pour demande une consultation en ligne, le patient doit
contacter médecin.
• Chercher médecin : pour chercher médecin, le patient doit choisi la spécialité.
• Suivi état santé : pour suivi le patient leur état santé, il doit accéder à leur his-
torique personnelle
Les fonctions pour l’analyste sont :

• Authentification : : l’analyste doit entrer un pseudo et password pour accéder en
toute sécurité à son espace de travail.
• Gestion des recommandations : pour gérer les recommandations, l’analyste doit
créer, modifier et supprimer les ordonnances.
• Prévisualisation des statistiques : pré visualiser les statistiques.
2.2.2 Besoins non fonctionnels

Pour compléter les besoins fonctionnels, notre projet devra respecter un ensemble
de propriétés contribuant à une meilleure qualité de la solution obtenue. Parmi ces
critères on retrouve :
• L’ergonomie : Étant donné que notre application va être utilisé par acteur 1 les
interfaces doivent être réalisées de telle façon que l’utilisateur s’y trouve facilement

et ceci en respectant la charte graphique demandé par le client.

• La rapidité et la Performance : L’application doit être adaptable au maximum
possibles aux besoins des utilisateurs et il doit aussi offrir un temps de réponse mi-
nimale pour l’affichage des pages.
• L’évolutivité : l’application peut avoir des extensions, en intégrant des nouveaux
modules pour répondre aux nouveaux besoins fonctionnels et ceci sans modifier les
modules déjà existants.
• Portabilité : doit être facile à utiliser et doit être accessible par pc, tablette ou
téléphone.
• La sécurité : doit garantir à l’utilisation l’authentification des utilisateurs et éviter
l’usurpation d’identité ainsi que l’intégrité et la confidentialité des données person-
nelles et des données manipulées par le système.
• Compatibilité avec le navigateur : consiste à rendre un site cohérent et utilisable
quel que soit son support.
• Fiabilité : Répondre à tous les besoins.
• Aptitude à la maintenance : Effectue le dépannage, l’entretien et l’installation
d’équipements ou de parcs d’équipements informatiques ou bureautiques (matériels,
logiciels, réseaux, ...), selon les règles de sécurité et la réglementation.
• Disponibilité : la disponibilité permet d’assurer et de garantir la bonne organisa-
tion des applications ou services procurés, et ce, 24h/24 et 7j/7. Que vous soyez une
start-up ou un commerçant, vous êtes concerné par la disponibilité de votre système
d’information.
2.3 Backlog produit

Le Backlog de produit correspond à une liste priorisée des besoins et des exigences
du client. Les éléments du Backlog de produit, appelé aussi les histoires utilisateurs,
sont formulés en une ou deux phrases décrivant de manière claire et précises la fonc-
tionnalité désirée par le client, généralement, écrit sous la forme suivante En tant
que X, je veux Y, afin de Z.
Le Backlog de produit présenté dans le tableau 1 comprend les champs suivants :
• ID : C’est un nombre unique et auto-incrémenté pour chaque histoire utilisateur.
• User Story : C’est une phrase décrivant la fonctionnalité désirée par le client.
• Priorité : C’est la valeur métier qui dirige la priorisation du développement des
histoires utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100.
• Story Point : C’est l’effort nécessaire à la réalisation d’une histoire utilisateur.
(Nous avons pu établir une étude afin de répartir ces stories par priorité.
Les normes sur lesquelles nous nous sommes basés, sont :
• Story Point Priorité : par rapport au client Entreprise) représentée suivant la
méthode "MoSCoW" qui est une technique possédant un objectif qui s’articule au-
tour d’un accord entre le maître d’œuvre (MOE) et le maître d’ouvrage (MOA) sur

l’importance des tâches que l’on va réaliser par rapport aux délais prévus. MoSCoW
a pour signification :
o M : doit être fait (vital).
o S : devrait être fait dans la mesure du possible (essentiel).
o C : pourrait être fait dans la mesure où cela n’a pas d’impact sur les autres
tâches (confort).
o W : ne sera pas fait cette fois mais sera fait plus tard (luxe, c’est la zone d’op-
timisation budgétaire).
Dans le tableau suivant, nous présentons la liste des histoires utilisateurs ainsi
que leurs estimations. Nous avons listé les besoins et les exigences du client selon
l’ordre croissant de priorité :
ID Feature USER STORY Priorité STORY

POINT
1 S’inscrire En tant que utilisateur je veux inscrit MUST 13

pour obtenir participer à l’application
2 S’authentifier En tant que utilisateur je veux entrer MUST 8

email et password pour accéder à
l’application
3 Gérer les En tant que Administrateur je veux MUST 9

hôpitaux accéder à l’application pour gérer les
hôpitaux

médecins accéder à l’application pour gérer les
médecins

5 Gérer les cadres En tant que Administrateur je veux MUST 9

médicaux accéder à l’application pour gérer les
cadres médicaux

Pharmacies accéder à l’application pour gérer les
pharmacies
7 Accès au dossier En tant que Médecin je veux accéder à MUST 8

médical de l’application pour consulter le dossier
patient médical de patient
8 Demander accès En tant que Médecin je veux entrer clé MUST 8

à l’historique de unique de patient pour demander
patient l’accès
9 Gérer les En tant que Médecin je veux accéder à MUST 6

Patients l’application pour gérer les patients
Gérer les En tant que Médecin je veux accéder à COULD 6

10 ordonnances l’application pour gérer les
ordonnances
Gérer les En tant que Médecin je veux accéder à Could 6

11 analyses l’application pour gérer les analyses

Gérer les En tant que Médecin je veux accéder à Could 6

12 consultations l’application pour gérer les
consultations
Gérer les En tant que Médecin je veux accéder à MUST 6

13 rendez-vous l’application pour gérer les
rendez-vous
Modifier profile En tant que Médecin je veux accéder à Could 2

14 l’application pour modifier mon profil
Accepter le En tant que Patient je veux accepter MUST 4

15 partage de la partage de la demande de médecin
demande pour accéder à ma historique
personnel
Prendre En tant que Patient je veux connecter MUST 7

16 rendez-vous et chercher un spécialiste pour prendre
un rendez-vous
Contacter En tant que Patient je veux contacter Could 6

17 médecin médecin pour demander une
consultation en ligne et contrôler ma
état santé.
Chercher En tant que Patient je veux connecté MUST 6

18 Médecin pour chercher médecin

Accès à En tant que Patient je veux accéder à MUST 4

19 l’historique ma historique personnelle pour suivi
personnelle ma état santé
Recevoir les En tant que Patient je veux connecter MUST 2

20 ordonnances pour recevoir mes ordonnances
Recevoir les En tant que Patient je veux connecter MUST 2

21 analyses pour recevoir mes analyses
Gérer les recom- En tant que Analyste je veux accéder MUST 9

22 mandations à l’application pour gérer les
recommandations
Prévisualisation En tant que Analyste je veux accéder MUST 6

23 des statistiques à l’application pour prévisualisation
les statistiques
Table 2.1 – Backlog produit
Les "User stories" précédemment définis dans le Backlog du produit sont triés
par ordre de priorités et de valeurs métiers. Le but étant d’implémenter en premier
ce qui a le plus de valeur. Le travail sera planifié selon des sprints que nous avons
définis et chacun dure deux semaines. Après une réunion avec l’équipe, on a identifié
cinq sprints et trois releases.
2.4 Planification des sprints

La planification du sprint est une cérémonie Scrum qui lance le sprint. Elle a
pour objectif de définir ce qui peut être livré dans le sprint et comment y parvenir.
La planification du sprint est effectuée en collaboration avec toute l’équipe Scrum.
Dans la méthodologie Scrum, le sprint est une période définie au cours de laquelle

tout le travail est réalisé. Cependant, avant de pouvoir passer à l’action, vous devez
planifier le sprint. Vous devez décider de sa durée, de son objectif et de votre point
de départ. La session de planification du sprint lance le sprint en définissant le pro-
gramme et l’objectif. Si elle est bien exécutée, elle crée également un environnement
dans lequel l’équipe est motivée, mise au défi et peut réussir. Les mauvais plans de
sprint peuvent faire dérailler l’équipe en définissant des attentes irréalistes.
Figure 2.2 – Organigramme des tâches
L’Organigramme des Tâches est un outil de gestion de projet qui utilise des
diagrammes arborescences structurés pour designer graphiquement un projet.

2.5 Diagramme de Gantt
Figure 2.3 – Organigramme de Gantt
2.6 Conclusion
Dans ce chapitre nous avons fait l’identification des acteurs, la spécification des
besoins fonctionnels et non fonctionnels puis en faisant un planning bien détaillé
avec la définition d’équipe de projet. Dans le chapitre suivant nous allons présenter
l’architecture de la solution, l’environnement de travail et la conception.

Chapitre 3
Initialisation du projet
3.1 Introduction
Ce chapitre est consacré à l”initialisation du projet et la mise en place de l’envi-
ronnement de développement. L’architecture ainsi que l’environnement matériel et
logiciel.
3.2 Carte d’identité du projet
Figure 3.1 – Carte d’identité du projet
28
CHAPITRE 3. INITIALISATION DU PROJET
3.3 Architecture de la solution

3.3.1 Architecture logique
L’architecture adoptée pour la réalisation de notre solution est une architecture
trois tiers, aussi appelée architecture à trois niveaux ou architecture à trois couches,
est l’application du modèle plus général qu’est le multi-tiers. L’architecture logique
du système est divisée en trois niveaux ou couches :
• Couche de présentation.
• Couche de traitement.
• Couche d’accès aux données.
3.4 Architecture de la solution

3.4.1 Architecture logique
L’architecture adoptée pour la réalisation de notre solution est une architecture
trois tiers, aussi appelée architecture à trois niveaux ou architecture à trois couches,
est l’application du modèle plus général qu’est le multi-tiers. L’architecture logique
du système est divisée en trois niveaux ou couches :
• Couche de présentation.
• Couche de traitement.
• Couche d’accès aux données.
Figure 3.2 – architecture logique [34]
3.4.2 sArchitecture logicielle

• MVC :
Modèle-vue-contrôleur ou MVC est un motif d’architecture logicielle destiné aux
interfaces graphiques lancé en 1978 et très populaire pour les applications web. Le
motif est composé de trois types de modules ayant trois responsabilités différentes :

les modèles, les vues et les contrôleurs.

• Un modèle (Model) contient les données à afficher.
• Une vue (View) contient la présentation de l’interface graphique.
• Un contrôleur (Controller) contient la logique concernant les actions effectuées
par l’utilisateur.
Figure 3.3 – Architecture logicielle MVC[24]
3.5 Conecption détaillée

Donc ce qui suit, nous allons détaillons la conception à l’aide de la méthodologie
UML
3.5.1 Diagramme de cas d’utilisation global

Un diagramme de cas d’utilisation capture le comportement d’un système, d’un
sous-système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit.
Il scinde la fonctionnalité du système en unités cohérentes, les cas d’utilisation, ayant
un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des
utilisateurs d’un système, ils sont donc une vision orientée utilisateur de ce besoin
au contraire d’une vision informatique.

Figure 3.4 – Diagramme de cas d’utilisation global

3.5.2 Diagramme de classe global

Un diagramme de classes fournit une vue globale d’un système en présentant ses
classes, interfaces et collaborations, et les relations entre elles. Les diagrammes de
classes sont statiques : ils affichent ce qui interagit mais pas ce qui se passe pendant
l’interaction.
Figure 3.5 – Diagramme de classe global

3.5.3 Diagramme de paquetage

Les diagrammes de package (ou diagramme de paquetages) sont des diagrammes
structurels utilisés pour représenter l’organisation et la disposition de divers éléments
modélisés sous forme de paquetages. Un paquetage est un regroupement d’éléments
UML apparentés, tels que des diagrammes, des documents, des classes ou même
d’autres paquetages.
Figure 3.6 – Diagramme de paquetage
3.5.4 Diagramme de déploiement

Les diagrammes de déploiement sont utilisés pour décrire l’architecture physique
d’un système. Ils montrent la distribution des composants logiciels sur la base d’unité
d’exécution. La figure présente le diagramme de déploiement de l’application.
Figure 3.7 – Diagramme de déploiement

3.5.5 Diagramme de composants

Dans UML, les diagrammes de composants représentent la structure du système
logiciel, qui décrit les composants du logiciel, leurs interfaces et leurs dépendances.
Vous pouvez utiliser des diagrammes de composants pour modéliser des systèmes
logiciels à un haut niveau ou pour afficher des composants à un niveau inférieur, au
niveau du package.
Figure 3.8 – Diagramme de composants

3.6 Environnement de travail

On présente dans cette section l’environnement matériel, ainsi que l’environne-
ment technique utilisé pour le développement et la mise en place de notre application.
3.6.1 Environnement matériel

Dans la réalisation de notre application nous avons utilisé :
PC : ASUS i3 7éme génération
Mémoire RAM : 8GO
Type de système : Système d’exploitation 64 bits, processeur x64
Figure 3.9 – Environnement matériel
3.6.2 Environnement technique

Au cours du développement de notre application, nous sommes utilisées des dif-
férents logiciels et des langages suivants :
a) Environnement vagrant :
vagrant : Est un logiciel libre et open-source pour la création et la configuration des
environnements de développement virtuel. Il peut être considéré comme un wrapper
autour de logiciels de virtualisation comme Virtual Box.
Figure 3.10 – Vagrant[19]

git : Est un logiciel de gestion de versions décentralisé. C’est un logiciel libre

créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la
licence publique générale GNU version 2. En 2016, il s’agit du logiciel de gestion de
versions le plus populaire qui est utilisé par plus de douze millions de personnes .
Figure 3.11 – git[31]
Virtuel Box : Oracle VM Virtual Box (anciennement Virtual Box) est un logiciel
libre de virtualisation publié par Oracle.
Figure 3.12 – Virtuel Box[20]
Mysql community :
• Mysql server : MySQL est un système de gestion de bases de données relation-
nelles. Il est distribué sous une double licence GPL et propriétaire.
• Mysql workbench : MySQL Workbench est un logiciel de gestion et d’administra-
tion de bases de données MySQL créé en 2004.
Figure 3.13 – Mysql workbench[32]
b) Environnement Mobile :
Android studio : est un environnement de développement pour développer des ap-

plications mobiles Android. Il est basé sur IntelliJ IDEA et utilise le moteur de pro-
duction Gradel. Il peut être téléchargé sous les systèmes d’exploitation Windows,
macOS, Chrome OS et Linux .
Figure 3.14 – Android Studio[23]
Apache : Le logiciel libre Apache HTTP Server (Apache) est un serveur HTTP
créé et maintenu au sein de la fondation Apache. Jusqu’en avril 20193, ce fut le
serveur HTTP le plus populaire du World Wide Web. Il est distribué selon les termes
de la licence Apache.
Figure 3.15 – Apache[26]
c) Environnement Data science :

Python : Est un langage de programmation interprété, multi-paradigme et mul-
tiplateformes. Il favorise la programmation impérative structurée, fonctionnelle et
orientée objet. Il est doté d’un typage dynamique fort, d’une gestion automatique
de la mémoire par ramasse-miettes et d’un système de gestion d’exceptions .
Figure 3.16 – Python[22]
Bibliothèque : En informatique, une bibliothèque ou librairie logicielle (ou encore,

bibliothèque de programmes) est un ensemble de fonctions utilitaires, regroupées et

mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire. Les fonc-
tions sont regroupées de par leur appartenance à un même domaine conceptuel.
Framework Flask : Est un micro Framework open-source de développement web

en Python. Il est classé comme micro Framework car il est très léger. Flask a pour
objectif de garder un noyau simple mais extensible. Il n’intègre pas de système
d’authentification, pas de couche d’abstraction de base de données, ni d’outil de va-
lidation de formulaires. Cependant, de nombreuses extensions permettent d’ajouter
facilement des fonctionnalités. Il est distribué sous licence BSD.
Figure 3.17 – Frameworkflask
d) Environnement Framework :
Laravel : Est un Framework web open-source écrit en PHP1 respectant le principe
modèle-vue-contrôleur et entièrement développé en programmation orientée objet.
Laravel est distribué sous licence MIT, avec ses sources hébergées sur GitHub.
Figure 3.18 – Laravel [21]
Composer : Est un logiciel gestionnaire de dépendances libre écrit en PHP. Il

permet à ses utilisateurs de déclarer et d’installer les bibliothèques dont le projet
principal a besoin.

Figure 3.19 – Composer [25]
Composer : • Visuel code : Est un éditeur de code extensible développé par

Microsoft pour Windows, Linux et macOS
Figure 3.20 – Visuel code [28]
• Notepad++ : Est un éditeur de texte libre générique .
Figure 3.21 – Notepad ++[29]
Langage de programmation :
JS : Est un langage de programmation de scripts principalement employé dans les
pages web interactives et à ce titre est une partie essentielle des applications web.
Avec les technologies HTML et CSS, JavaScript est parfois considéré comme l’une
des technologies cœur du World Wide Web .
PHP7 : Hypertext Preprocessor, est un langage de programmation libre, principale-
ment utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais
pouvant également fonctionner comme n’importe quel langage interprété de façon
locale. PHP est un langage impératif orienté objet.

Figure 3.22 – Php 7[27]
SQL : sigle de Structured Query Language, en français langage de requête struc-

turée) est un langage informatique normalisé servant à exploiter des bases de don-
nées relationnelles. La partie langage de manipulation des données de SQL permet
de rechercher, d’ajouter, de modifier ou de supprimer des données dans les bases de
données relationnelles.
Création d’interface :
Html : Le Hypertext Markup Language, généralement abrégé HTML ou dans sa

dernière version HTML5, est le langage de balisage conçu pour représenter les pages
web.
Css : Cascading Style Sheets, forment un langage informatique qui décrit la présen-
tation des documents HTML et XML.
XML : Extensible Markup Language, généralement appelé XML, « langage de

balisage extensible1 » en français, est un métalangage informatique de balisage géné-
rique qui est un sous-ensemble du Standard Generalized Markup Language (SGML).
StarUML : StarUML est un logiciel de modélisation UML, qui a été « cédé comme
open source » par son éditeur, à la fin de son exploitation commerciale, sous une
licence modifiée de GNU GPL.
Figure 3.23 – StarUML [30]
Trello : est un outil de gestion de projet en ligne.

Figure 3.24 – Trello [9]
Overleaf est un éditeur LaTeX en ligne, collaboratif en temps réel.
Figure 3.25 – overleaf [33]
3.7 Conclusion
Au cours de ce chapitre, on décrit l’architecture de la solution et conception dé-
taillée nous avons aussi présenté l’environnement de travail. Dans le chapitre suivant
nous allons définir mise en œuvre de release 1.

Chapitre 4
Mise en œuvre du release 1
4.1 Introduction
Dans ce chapitre, nous allons présenter la réalisation du premier release, en or-
ganisant le travail sur les phases principales qui sont l’analyse, la conception et la
réalisation et les tests fonctionnels.
4.2 Sprint1 : gestion d’accès

4.2.1 Backlog du sprint 1 de gestion d’accès
Table 4.1 – Backlog du sprint 1
ID Feature USER STORY Priorité

1 S’authentifier En tant qu’utilisateur je veux connecter 1
pour accéder à l’espace.
2 S’inscrire En tant que utilisateur je veux inscrit 1
pour participer à l’application
4.2.2 Tableau de tâches

Créez un tableau et tracez trois colonnes : « A faire », « En cours » et « Terminé
». Écrivez chaque tâche sur un post-it et placez-les dans la colonne « A faire ».
Chaque participant de l’équipe se dirige vers le tableau, choisit une tâche / un post-
it, et la déplace de « A faire » à « En cours ». Chaque membre de l’équipe commence
à travailler sur la tâche choisie. Tant que la tâche n’est pas terminée, vous devez la
garder sur le tableau. Si la tâche est terminée, déplacez le post-it dans la colonne «
Terminé ».
Définissez une limite dans le nombre de post-it qui devraient être dans « En cours
42
CHAPITRE 4. MISE EN ŒUVRE DU RELEASE 1
» afin de réguler la charge de travail.

« A faire » : toutes les tâches qui n’ont pas encore été commencées et qui doivent
être réalisées.
« En cours » : les tâches qui ont été commencées.
« Terminé » : les tâches terminées. [9]
Figure 4.1 – Tableau de tâches de sprint 1
4.2.3 Analyse
a) Identification des acteurs et des cas d’utilisation
• Utilisateur :
S’authentifier
S’inscrire
b) Description des cas d’utilisation : fiche de cas d’utilisation
Pour chaque cas d’utilisation, on réalise une fiche descriptive comportant géné-
ralement les 3 volets suivants :
i. Titre
ii. Résumé de cas
iii. Acteur
iv. Prés-condition
v. Post-condition : Les post-conditions indiquent un résultat vérifiable après l’arrêt
du cas d’utilisation témoignant du bon fonctionnement.
vi. Description des scénarios : Les scénarios explicitent la chronologie des actions qui
seront réalisées par l’utilisateur et le système. Il existe 2 parties :
1. Le scénario nominal : déroulement idéal des actions (quand tout va pour le

mieux).
2. Les scénarios alternatifs : éventuelles étapes différentes liées aux choix de

l’utilisateur (cas des étapes liées à des conditions).
Ces scénarios sont décrits en utilisant une description textuelle ou sous forme de

tableau. Ils sont généralement présentés sous forme de liste numérotée : 1, 2, 3, ...
pour le déroulement du scénario nominal et 1a, 1b, 2a, 2b, . . . pour le scénario
alternatif.
Table 4.2 – Tableau descriptif de sprint 1 «S’inscrire»
Titre S’inscrire
Résumé L’utilisateur doit être inscrit pour participer au groupe.
Acteur Utilisateur : Patient ,analyste
Post-condition(s) Utilisateur bien inscrit
Pré-condition(s) Système doit être lancé
Scénario Nominal
1. Utilisateur remplir le formulaire.
2. Système vérifier les champs.
3. exécute requête d’Inscription.
4. Base de donnée vérifier l’attributs unique.
5. Base de donnée enregistrer l’utilisateur.
6. Base de donnée renvoi résultat.
7. Système redirigé l’utilisateur vers espace privée.
Scénario Alternatif 3)a) Système renvoi message d’erreur.

5)a)1- Base de donnée renvoi résultat.
5)a-2-Systéme renvoi message d’erreur.

Table 4.3 – Tableau descriptif de sprint 1 «S’authentifier»
Titre S’authentifier
Résumé L’utilisateur doit être connecté pour accéder à l’application.
Acteur Utilisateur :Adminstrateur , Médecin, Patient ,analyste
Post-condition(s) utilisateur connecté.
Pré-condition(s) Système doit être lancée
Scénario Nominal
1. Utilsateur remplir login et password
2. Système vérifier
3. Systéme exécute requête de connexion.
4. Base de donnée collecte les données.
5. Base de donnée renvoi les résultats.
6. Systéme redirigé l’utilisateur vers espace privée.
Scénario Alternatif 3)a) Système renvoi un message d’erreur en cas de fausse rem-
plir
6)a) Système renvoi un message d’erreur.
c) Structuration du modèle de cas d’utilisation
Figure 4.2 – Cas d’utilisation «Gestion d’accès»

4.2.4 Conception
a) Conception statique de sprint
• Diagramme de classe
Figure 4.3 – Diagramme de classe d’utilisateur de sprint 1
• Dictionnaire

Table 4.4 – la description des classes du sprint 1
Attributs Signification Type

Utilisateur
id L’identifiant unique d’utilisateur INT
nom Nom de l’utilisateur TEXT
prenom Prénom de l’utilisateur TEXT
tel téléphone de l’utilisateur INT
email email de l’utilisateur TEXT
pseudo Pseudo de l’utilisateur TEXT
adresse Adresse de l’utilisateur TEXT
password Password de l’utilisateur TEXT
profil Profil de l’utilisateur INT
avatar Avatar de l’utilisateur TEXT
datei ns Date d’insertion de l’utilisateur TEXT
etat Etat de l’utilisateur INT
Patient
id L’identifiant unique de patient INT
clé le clé unique de patient INT
DateN Date naissance de patient Date
age Age de patient INT
etatc ivil Etatc ivildepatient TEXT
datev isite Date visite de patient TEXT
typem aladie Type maladie de patient TEXT
diagnostique Diagnostique de patient TEXT
sexe Sexe de patient TEXT
compter endu Compte rendu de patient TEXT
datei ns Date d’insertion du patient TEXT
etat Etat du patient INT
iduser L’identifiant unique d’utilisateur INT
idanalyse L’identifiant unique d’analyse INT
idord L’identifiant unique d’ordonnance INT

Médecin
id L’identifiant unique de médecin INT
imagem ed Image de médecin INT
assurance Assurance de médecin INT
heure heure d’ouverture et fermeture cabinet de TEXT
médecin
datei ns Date d’insertion de médecin TEXT
idspécialité L’identifiant unique de spécialité INT
idhop L’identifiant unique d’hôpital INT
b) Conception dynamiques du sprint •Diagramme de package
Figure 4.4 – Diagramme de package de sprint 1
• Diagramme de séquence
Les diagrammes de séquences sont la représentation graphique des interactions
entre les acteurs et le système selon un ordre chronologique dans la formulation Uni-
fied Modeling Language.
L’utilité du diagramme de séquence :

Le diagramme de séquence permet de montrer les interactions d’objets dans le cadre
d’un scénario d’un Diagramme des cas d’utilisation. Dans un souci de simplification,
on représente l’acteur principal à gauche du diagramme, et les acteurs secondaires
éventuels à droite du système. Le but étant de décrire comment se déroulent les
actions entre les acteurs ou objets.

Le diagramme de séquence « s’inscrire », en effet après être connecté, l’utilisa-

teur peut s’inscrire. Le système à son tour affichera une interface contenante des
champs (). Une fois les différents champs sont saisis par l’utilisateur, notre système
renvoi a la base de données les informations, Lebas de données faire la vérification et
après l’enregistrement des informations saisies. Enfin, le système retourne résultat
concernant la réussite de l’inscription et le redirigé vers l’espace privée
Figure 4.5 – Diagramme de séquence « S’inscrire »
Le diagramme de séquence « Se connecter », décrit les scenarios possibles d’une

opération d’identification. En effet après être connecté, l’utilisateur doit d’identifier
pour accéder à toutes les fonctionnalités de notre application. Le système à son
tour affichera un formulaire de connexion à remplir (login et password), une fois le
formulaire est rempli par l’utilisateur, notre système consulte la base de données pour
vérifier l’existence des informations saisies. Si login et le password sont correctes, le
système redirige l’utilisateur à l’espace privé de l’application si non retourner un
message d’erreur.

Figure 4.6 – Diagramme de séquence « S’authentifier »
• Diagramme d’activité
Le diagramme d’activité est un diagramme comportemental d’UML, permettant
de représenter le déclenchement d’événements en fonction des états du système et de
modéliser des comportements parallélisables (multi-threads ou multi-processus). Le
diagramme d’activité est également utilisé pour décrire un flux de travail (workflow).
Dans la phase de conception, les diagrammes d’activités sont particulièrement

adaptés à la description des cas d’utilisation. Plus précisément, ils viennent illustrer
et consolider la description textuelle des cas d’utilisation. De plus, leur représenta-
tion sous forme d’organigrammes les rend facilement intelligibles et beaucoup plus
accessibles que les diagrammes d’états-transitions. On parle généralement dans ce
cas de modélisation de workflow. On se concentre ici sur les activités telles que les
voient les acteurs qui collaborent avec le système dans le cadre d’un processus métier.
La modélisation du flot d’objets est souvent importante dans ce type d’utilisation
des diagrammes d’activités.

Figure 4.7 – Diagramme d’activité de sprint 1 "S’inscrire"
Figure 4.8 – Diagramme d’activité de sprint 1 "S’authentifier"
4.3 Réalisation
4.3.1 Interface d’inscription
• Interface Web :
• Interface Mobile :

Figure 4.9 – Capture d’écran d’interface "Inscription" de patient
4.3.2 Interface de connexion

• Interface Web :

Figure 4.10 – Capture d’écran d’interface "Login" d’administrateur
• Interface Mobile :
Figure 4.11 – Capture d’écran d’interface "Login" de patient

4.4 Test et validation

Le principe de Scrum est de valider chaque sprint avant de passer au suivant
afin de s’assurer du bon fonctionnement de chaque fonctionnalité. Pour cela, il était
nécessaire de faire les tests unitaires pour chaque Sprint et valider notre travail.
Nous avons établi les tests d’intégration des sprints qui consiste à tester le travail
effectué après avoir fusionner les parties en une seule entité logicielle afin de s’assurer
que ceux-ci s’intègrent parfaitement dans leur environnement d’exécution.
En fin, après avoir développé l’intégrité du système, nous avons effectué des tests
globaux sur les fonctionnalités du système avec différent scénarios. Le but du test
de vérification est de s’assurer que le produit qui sera livré aux clients ne présente
pas des bugs et est bien conforme au cahier des charges.
Table 4.5 – Tableau de test et validation de sprint 1
Cas de test Démarche de test Comportement attendu Résultat

S’inscrire L’Utilisateur doit remplir for- Affichage de message d’erreur en conforme
mulaire d’inscription pour par- cas des informations fausses rem-
ticiper plir
S’authentifier L’utilisateur doit entrer Affichage de message d’erreur en conforme
pseudo et password pour cas des informations fausses si
accéder à son espace non affichage de l’espace privé
4.5 Sprint1 : Administration

1 Gérer Hôpitaux En tant qu’administrateur je veux 1
ajouter hôpital et modifier hôpital
2 Gérer médecins En tant qu’administrateur je veux 1
ajouter médecin, supprimer médecin et
affecter médecin à l’hôpital
3 Gérer cadres médi- En tant qu’administrateur je veux 1
caux ajouter cadre médical, Modifier cadre
médical et supprimer cadre médical.
4 Gérer pharmacies En tant que administrateur je veux 1
ajouter pharmacie et supprimer phar-
macie

4.5.2 Analyse
• Administrateur : il est responsable des différents paramétrages de l’applica-

tion. Son rôle est de gérer les hôpitaux, les médecins, les pharmacies et les cadres
médicaux. b) Description des cas d’utilisation : fiche de cas d’utilisation
Table 4.7 – Tableau descriptif de sprint 2 « ajouter hôpital »
Titre Ajouter
Résumé Ajout hôpital
Acteur Administrateur
Post-condition(s) utilisateur ajouté
Pré-condition(s) L’administrateur doit être authentique
Scénario Nominal
1. Administrateur remplir formulaire
2. Le système vérifié le formulaire
3. le système ajouté hôpital
4. Base de donnée enregistré l’ajout
5. Base de donnée renvoi résultat
6. Le système afficher le message d’ajout avec succès
Scénario Alternatif 2)a)-Le système renvoi message d’erreur en cas de fausse rem-
plir

Table 4.8 – Tableau descriptif de sprint 2 « modifier cadre médical »
Titre Modifier
Résumé Modifier cadre médical
Post-condition(s) champ modifié
Scénario Nominal
1. Administrateur choisir champ à modifier.
2. Execution requête.
3. Base de donnée collecte les informations.
4. Base de donnée renvoi résultat d’anciens données.
5. Le système afficher formulaire contenant les anciennes
données.
6. Le système vérifier les informations.
7. L’administrateur modifier les informations.
8. Le Système modifier les nouvelles données.
9. Base de donnée renvoi résultat de modification.
10. Base de donnée renvoi résultat a système.
11. Le Système renvoi un message (modifier avec succès).
plir

Table 4.9 – Tableau descriptif de sprint 2« supprimer pharmacie »
Titre Supprimer
Résumé Supprimer pharmacie
Post-condition(s) Pharmacie supprimée
Scénario Nominal
1. choisir pharmacie supprimer.
2. le système demande de la confirmation.
3. l’administrateur confirmer la suppression.
4. le système supprimer pharmacie choisi
5. le Base de donnée supprimer.
6. le Base de donnée renvoi résultat
7. le système supprimer pharmacie avec succès
Scénario Alternatif 3)a) l’administrateur annuler la demande.
Table 4.10 – Tableau descriptif de sprint 2« Affecter médecin à l’hôpital »
Titre Affecter
Résumé Affecter médecin à l’hôpital
Post-condition(s) médecin affecter à l’hôpital
Scénario Nominal
1. Administrateur remplir formulaire
2. Le système vérifié les champs
3. le système affecter médecin à l’hôpital
4. Base de donnée enregistré l’affectation
6. Le système afficher le message d’affectation avec succès
plir

b) Structuration du modèle de cas d’utilisation
Figure 4.13 – Cas d’utilisation « Administration »
4.5.3 Conception
a) Conception statique de sprint • Diagramme de classe
Figure 4.14 – Diagramme de classe de sprint 2 « Administrateur »

• Dictionnaire

Utilisateur
id L’identifiant unique d’administrateur INT
Pharmacie
id L’identifiant unique de pharmacie INT
nom Nom de pharmacie TEXT
adresse Adresse de pharamcie TEXT
Hôpitaux
id L’identifiant unique d’hôpital INT
nom Nom d’hôpital TEXT
adresse Adresse d’hôpital TEXT
numf ax Numéro d’hôpital INT
datei ns Date d’insertion d’hôpital TEXT
Cadre M
id L’identifiant unique d’hôpital INT
nom Nom de cadre médical TEXT
adresse Adresse de cadre médical TEXT
numt el Numéro de cadre médical INT
datei ns Date d’insertion de cadre médical TEXT

b) Conception dynamiques du sprint

• Diagramme de package de sprint 2
• Conception détaillée
Figure 4.16 – Conception détaillée de sprint 2

Diagramme de séquence « Ajouter Hôpital », Après être connecté l’administrateur
cliquer sur le bouton ajouter. Le système affiche le formulaire d’ajout, l’administra-
teur remplit le formulaire, Le système vérifie les champs puis envoyer les données
dans la donnée dans la base de donnée et redirige l’administrateur vers le liste des
hôpitaux si non afficher un message d’erreur.
Figure 4.17 – Diagramme de séquence « Ajouter Hôpital »
Diagramme de séquence « modifier cadre médical », Après s’être connecté L’ad-

ministrateur cliquer sur le bouton modifier, Le système collecte les informations
concernant ce cadre médical et afficher formulaire, l’administrateur choisir un élé-
ment à modifie, le système vérifie les champs puis fait la mise à jour des champs
dans la base de donnée et affiche un message montrant que le champ à modifier avec
succès ou si non affiche un message d’erreur.

Figure 4.18 – Diagramme de séquence « Modifier Cadre médical »
Diagramme de séquence « Supprimer pharmacie », Après s’être connecté, l’ad-

ministrateur choisir un élément à supprimer, cliquer sur le bouton supprimer et
demande une confirmation le système affiche un message de confirmation. Lors de
confirmation le système envoi une demande de suppression et retourne un résultat
suppression avec succès. Tout s’ignoré lors d’une seule cliquer sur le bouton annuler.

Figure 4.19 – Diagramme de séquence « Supprimer pharmacie »
Diagramme de séquence de « Affecter médecin à l’hôpital », après avoir connecté,

l’administrateur remplir formulaire par de données concernant médecin, le système
vérifié les champs, si les champs sont corrects le base de donné enregistré les don-
nées et le système afficher un message « médecin affecter avec succès » et redirigé
l’administrateur vers liste des médecins si non afficher un message d’erreur.
Figure 4.20 – diagramme d’activité " Ajouter hôpital"

Figure 4.21 – diagramme d’activité " modifier cadre médical"
Figure 4.22 – diagramme d’activité " supprimer pharmacie"

4.6 Réalisation

Ajouter l’administrateur doit remplir Affichage de message d’erreur en conforme
formulaire pour ajouter un uti- cas des informations fausses rem-
lisateur plir
Supprimer L’administrateur doit choisi La suppression annuler quand conforme
l’utilisateur à supprimer pour l’administrateur annuler la de-
supprimer l’utilisateur mande
Modifier L’administrateur afficher liste Affichage message d’erreur en cas conforme
des utilisateurs pour modifier de fausse remplir
l’utilisateur a choisi
Affecter L’administrateur doit remplir Affichage de message d’erreur en conforme
formulaire pour affecter utili- cas des informations fausses rem-
sateur à l’hôpital plir
4.8 Conclusion
Ce dernier chapitre présente le release 1, ce release a pour deux sprint chaque
sprint à pour le backlog de sprint, l’analyse de chaque sprint et s’intéresse de la
réalisation et le test et validation.

Chapitre 5
5.1 Introduction
Dans ce chapitre, nous allons présenter la réalisation du deuxième release, en
organisant le travail sur les phases principales qui sont l’analyse, la conception et la
5.2 Sprint 3 : « Médecin »

5.2.1 Backlog du sprint 3

1 Gestion des patients En tant que médecin je veux Deman- 1
der l’accès et l’historique médical de pa-
tient et consulter patient
2 Gestion des ordon- En tant que médecin je veux ajouter , 1
nance supprimer et consulter ordonnance
3 Gestion des analyses En tant que médecin je veux demander, 1
ajouter et consulter analyse
4 Gestion des consulta- En tant que médecin je veux ajouter , 2
tions supprimer et consulter patient en ligne
5 Modifier profile En tant que médecin jeux modifier mon 1
profile.
66
5.2.3 Analyse
• Médecin : est un acteur principal. Son rôle est de gérer patients, les consul-
tations, les ordonnances, les analyses, demander l’accès à l’historique médical de
patient et modifier leur profile.

Table 5.2 – Tableau descriptif de sprint 3 « Modifier profil »
Titre Modifier
Résumé Modifier profil
Acteur Médecin
Post-condition(s) champ modifié
Pré-condition(s) Le médecin doit être authentique
Scénario Nominal
1. médecin demande profil de médecin
2. Systéme afficher profil
3. Médecin remplir formulaire"champ a modifié"
4. systéme envoi résultat au base de donnée
5. Base de donnée collect les informations nécessaires.
6. Base de donnée renvoi résultat"champ modifié"
7. Systéme affiché resultat " champ modifié avec succès"
pli.
Table 5.3 – Tableau descriptif de sprint 3 « Consulter ordonnance »
Titre Consulter
Résumé Le médecin doit être consulter le compte pour gérer l’ordon-
nance.
Acteur Médecin
Post-condition(s) Liste ordonnance affichée.

Scénario Nominal
1. medecin demande liste d’ordonnance.
2. systéme afficher la liste
3. Base de donnée collecte les informations
4. Base de donnée renvoi résultat.
5. Systéme afficher liste utilisateur
Scénario Alternatif 4)a)- Le système renvoi table vide

Table 5.4 – Tableau descriptif de sprint 3 « Supprimer consultation »
Titre Supprimer
Résumé Supprimer consultation
Acteur Médecin
Post-condition(s) Consultation supprimée

Scénario Nominal
1. choisir consultation a supprimée.
3. le médecin confirmer la suppression.
4. le système supprimer consultation choisi
5. le Base de donnée supprimer.
7. le système supprimer consultation avec succès
Scénario Alternatif 3)a) le médecin annuler la demande.

Table 5.5 – Tableau descriptif de sprint 3 « Demande l’accès »
Titre Demande l’accès

Résumé Demander l’accès à l’historique médical de patient
Acteur Médecin
Post-condition(s) Demande acceptée

Scénario Nominal
1. Entrer clé unique de patient
2. Le système vérifié
3. Base de donnée vérifié
4. Base de donnée collecte les données
6. Le système renvoi l’acceptation
Scénario Alternatif 5)a) demande refusée

6)a) le système renvoi un message d’erreur « refuser la de-
mande »

Table 5.6 – Tableau descriptif de sprint 3 « Ajouter analyse »
Titre Ajouter
Résumé Ajout analyse
Acteur Médecin
Post-condition(s) analyse ajouté

Scénario Nominal
1. Médecin remplir formulaire
3. le système ajouté analyse
4. Base de donnée enregistré l’ajout
6. Le système afficher le message d’ajout avec succès
plir
Figure 5.2 – Cas d’utilisation de sprint 3

5.2.4 Conception
Figure 5.3 – Diagramme de classe de sprint 3
• Dictionnaire


Utilisateur
Médecin
id L’identifiant unique de médecin INT
assurance assurance de médecin TEXT
heure Heure d’ouverture et fermeture de médecin TEXT
date-ins Date d’insertion de médecin TEXT
idspéciaité L’identifiant unique de spécialité INT
idhop L’identifiant unique d’hôpital INT
Spécialité
id L’identifiant unique de spécialité INT
nom-specialite Nom de spécialité TEXT
image Image de spécialité TEXT
datei ns Date d’insertion d’hôpital TEXT

b) Conception dynamiques du sprint

• Diagramme de package de sprint 3

Diagramme de séquence « modifier profil », Après s’être connecté Le médecin clique
sur le bouton modifier, Le système collecte les informations concernant leur profil
et afficher formulaire, le médecin choisir un élément à modifie, le système vérifie les
champs puis fait la mise à jour des champs dans la base de donnée et affiche un
message montrant que le champ à modifier avec succès ou si non affiche un message
d’erreur.
Figure 5.6 – Diagramme de séquence « Modifier profil »
Diagramme de séquence « Ajouter analyse », Après être connecté le médecin cli-

quer sur le bouton ajouter. Le système affiche le formulaire d’ajout, l’administrateur
remplit le formulaire, Le système vérifie les champs puis envoyer les données dans la
donnée dans la base de donnée et redirige médecin vers le liste des analyses si non
afficher un message d’erreur.

Figure 5.7 – Diagramme de séquence « Ajouter analyse »
Diagramme de séquence « Consulter ordonnance », Après être connecté le méde-

cin demande une consultation des analyses. Le système envoyer la demande au base
de donnée, le base de donnée collecte les données et envoyé au base de donnée après
le système renvoi résultat au médecin sous forme tableau.

Figure 5.8 – Diagramme de séquence « Consulter ordonnance »
Diagramme de séquence « Supprimer consultation », Après s’être connecté, le

médecin choisir un élément à supprimer, cliquer sur le bouton supprimer et demande
une confirmation le système affiche un message de confirmation. Lors de confirmation
le système envoi une demande de suppression et retourne un résultat suppression
avec succès. Tout s’ignoré lors d’une seule cliquer sur le bouton annuler.

Figure 5.9 – Diagramme de séquence « Supprimer consultation »
Diagramme de séquence « demande l’accès », Le médecin entré clé unique de

patient, système vérifier la clé et envoyer la demande d’accès vers base de donnée,
après base de donnée vérifié et collecte les données et enfin renvoi résultat au système
et système renvoi résultat d’acceptation au médecin.
Figure 5.10 – Diagramme de séquence « demande l’accès »

Figure 5.11 – Diagramme d’activité « ajouter consultation »
Figure 5.12 – Diagramme d’activité « diagramme d’activité "supprimer consulta-

tion"»

Figure 5.13 – Diagramme d’activité « demande l’accès à l’historique médical de

patient »
5.3 Réalisation

Ajouter ana- Le médecin doit remplir formu- Affichage message d’erreur en cas conforme
lyse laire pour ajouter un analyse de fausse remplir
Supprimer Le médecin doit choisi la La suppression annulée quand le conforme
consultation consultation à supprimer pour médecin annuler la demande de
supprimer la consultation avec suppression
sucée
Modifier pro- Le médecin afficher profil pour Affichage message d’erreur en cas conforme
fil modifier champ a choisi de fausse remplir
Consulter or- Le médecin afficher liste des or- Affichage table vide conforme
donnance donnances pour consulter
Demander Le médecin doit demander Affichage message d’erreur en cas conforme
l’accès l’accès pour accéder au histo- le patient refuser la demande
rique de patient

5.5 Sprint 4 « Patient »

5.5.1 Bocklog du sprint 4

1 Prendre rendez- En tant que patient je veux choisir un 1
vous médecin et prendre un rendez-vous
2 Contacter médecin En tant que patient je veux contacter 3
un médecin pour faire une consultation
en ligne textuelle
3 Accepter la de- En tant que patient je veux accepter la 1
mande demande de médecin pour l’accéder au
mon dossier médical
4 Recevoir les ordon- En tant que patient je veux recevoir 1
nances mes ordonnances et pour connaître mes
traitements des médicaments
5 Recevoir les ana- En tant que patient je veux recevoir 1
lyses mes analyses et pour connaître mes
analyses
6 Chercher médecin En tant que patient je veux chercher un 1
médecin
7 accès à l’historique En tant que patient je veux accéder à 2
(suivi état santé) l’application pour consulter ma histo-
rique personnelle
Figure 5.14 – Tableau de tâches de sprint4

5.5.3 Analyse
• Patient : est un acteur principal. Son rôle est pris rendez-vous, Contacter mé-
decin, Accepter la demande d’accès, Recevoir les ordonnances, recevoir les analyses
et accès à l’historique (suivi état santé).
Table 5.10 – Tableau descriptif de sprint4 « Prendre un rendez-vous »
Titre Prendre rendez-vous

Résumé Le patient doit être consulte le compte pour prendre un
rendez-vous
Acteur Patient
Post-condition(s) Patient prise un rendez-vous
Pré-condition(s) Le patient doit être authentique

Scénario Nominal
1. patient demande liste des médecins
2. système afficher la liste de spécialité
3. patient choisir spécialité
4. Système envoi résultat au table de médecin
5. base de donnée collecte les informations
6. base de donnée renvoi résultat
7. système renvoi résultat au patient
8. Patient choisir médecin
9. système renvoi un formulaire
10. Patient choisir date et heure de rendez-vous
11. système envoi donnée
12. base de donnée fait l’enregistrement
13. base de donnée renvoi un résultat
14. système envoi résultat "rendez-vous accepté"
Scénario Alternatif 14)a) rapporté le rendez-vous

14)b) refusé le rendez-vous

Table 5.11 – Tableau descriptive de sprint4 « Contacter médecin textuelle »
Titre Contacter
Résumé Le patient doit être consulter le compte pour contacter médecin
Acteur Patient
Post-condition(s) Patient contacter médecin textuelle

Scénario Nominal
1. patient demande liste des médecins
2. système afficher la liste de spécialité
3. patient choisir spécialité
4. système envoi donnée
5. Base de donnée collecte les informations
6. Base de donnée envoyé résultat
7. système redirigé patient
8. Patient choisir médecin
9. Système afficher formulaire
10. Patient remplir formulaire
11. système envoyer l’état santé de patient
12. Base de donnée vérifier les informations
13. Base de donnée envoyé les informations au table communica-
tion et renvoi résultat
14. Système renvoi résultat
Scénario Alternatif 12)a) Base de donnée renvoi un message d’erreur

13)a) renvoi message d’erreur
14)a) Système renvoi message d’erreur

Table 5.12 – Tableau descriptive de sprint4 « Chercher Médecin »
Titre Chercher médecin

Résumé Le patient doit être consulter le compte pour chercher médecin
Acteur Patient
Post-condition(s) Médecin cherché

Scénario Nominal
1. Patient demande au système de chercher médecin
2. Le système affiche liste des médecins
3. patient chercher médecin
4. le système envoi résultat au base de donnée
5. le base de donnée collecte les informations nécessaires
6. le base de donnée renvoi la réponse de collection au système
7. le système affiche la résultat
Scénario Alternatif 7)1) le système affiche un message d’erreur « le médecin n’a pas
trouvé »

Table 5.13 – Tableau descriptive de sprint4 « accès à l’historique (suivi état santé)
»
Titre Suivi état santé

Résumé Patient accès à l’historique pour suivi état santé
Acteur Patient
Post-condition(s) Suivi état santé

Scénario Nominal
1. Patient demande historique personnelle
2. Système vérifier les données
3. Système envoi donnée
4. Base de donnée collecte les informations de table analyse
5. Système affiché les analyses
6. Base de donnée collecte les informations de table ordonnance
7. Système affiché les ordonnances
8. Base de donnée collecte les informations de table rendez-vous
9. Système affiché les rendez-vous de patient
Scénario Alternatif 5)a) Système renvoi table analyse vide

7)a) Système renvoi table ordonnances vide
9)a) Système renvoi table rendez-vous vide


5.5.4 Conception


• Dictionnaire

Utilisateur
Patient
id L’identifiant unique de patient INT
clé le clé unique de patient INT
DateN Date naissance de patient Date
age Age de patient INT
etatc ivil Etatc ivildepatient TEXT
datev isite Date visite de patient TEXT
typem aladie Type maladie de patient TEXT
sexe Sexe de patient TEXT
compter endu Compte rendu de patient TEXT
datei ns Date d’insertion du patient TEXT
etat Etat du patient INT
idord L’identifiant unique d’ordonnance INT


Analyse
id L’identifiant unique d’analyse INT
noml abo Nom de laboratoire TEXT
codec nam Code cnam de patient TEXT
valeurr Valeur référence de laboratoire TEXT
datet rans Date transaction des analyses Date
datei ns Date d’insertion d’analyse TEXT
idmed L’identifiant unique de médecin INT
Rendez-vous
id L’identifiant unique de rendez-vous INT
date Date de rendez-vous TEXT
codec nam Code cnam de patient TEXT
heure Heure de rendez-vous TEXT
datei ns Date d’insertion de rendez-vous TEXT
idpatient L’identifiant unique de patient INT
consultation
id L’identifiant unique de consultation INT
observation Observation de patient TEXT
traitement Traitement de patient TEXT
demandes Demandes de patient TEXT
datei ns Date d’insertion de consultation TEXT


Ordonnance
id L’identifiant unique d’ordonnance INT
codec onventionnel Code conventionnel d’ordonnance TEXT
code Code de patient dans leurs ordonnances TEXT
duréet raitement Durée traitement de médicament TEXT
nomm édicament Nom de médicament TEXT
datei ns Date d’insertion d’ordonnance TEXT
Communication
id L’identifiant unique de communication INT
msg Message de consultation TEXT
température Température de patient INT
tension Tension de patient INT
glycémie Glycémie de patient INT
poids Poids de patient INT
battement battement de patient INT
problème Les autres maladies de patient TEXT
long Longueur de patient INT
datei ns Date d’insertion de communication TEXT
b) Conception dynamiques du sprint • Diagramme de package

Diagramme de séquence « Prise rendez-vous », Après être authentifié patient de-
mande liste des médecins, le système redirige le patient vers l’interface des spécia-
lités, le patient choisir une spécialité, le système envoi donnée, le patient choisir un
médecin, directement le système envoi les données vers médecin, le base de don-
née de table médecin collecte les informations et renvoi résultat, après le système
renvoi résultat au patient, le patient choisir médecin, le système afficher formulaire
de rendez-vous, le patient choisir date et heure, le système envoi données, base de
donnée enregistré et renvoi résultat au système , enfin système renvoi résultat «
rendez-vous accepté » ou « rendez-vous refusé » si le médecin refusé le rendez-vous.
Figure 5.19 – Diagramme de séquence « Prise rendez-vous »

Diagramme de séquence « Contacter Médecin », Après être authentifier patient

demande liste des médecins, système affiche liste des spécialités, après le patient
choisir une spécialité, le système envoi les données, base de donnée collecte les infor-
mations et envoyer un résultat au systèmes, le système renvoi un résultat au patient,
après le patient choisir un médecin, le systèmes afficher un formulaire, le patient rem-
plir le formulaire, le systèmes envoyé l’état santé de patient au médecin, Enfin base
de donnée fait l’enregistrement et le système afficher un résultat « consultation fait
avec sucée ».
Figure 5.20 – Diagramme de séquence « Contacter médecin textuelle »

Diagramme de séquence « Chercher Médecin », Après être connecté, le patient

demande liste des médecins, système affiche liste des médecins, après le patient
chercher médecin, le système envoi résultat vers base de donnée, le base de don-
née collecte les informations nécessaires et renvoi la réponse de collection, en fin le
système affiche le résultat.
Figure 5.21 – Diagramme de séquence « Chercher Médecin »

5.6 Réalisation

Prendre Le patient doit choisir spécia- Affichage message d’erreur en cas conforme
rendez-vous lité médecin , date et l’heure de fausse remplir
pour prendre un rendez-vous
Contacter Le patient doit choisir médecin Affichage message en cas le méde- conforme
médecin et remplir formulaire pour faire cin rapporter la conversation tex-
une consultation en ligne tuelle
Suivi état Le patient doit consulter l’ap- Affichage liste vide conforme
santé plication pour suivi leur état
santé
Accepter la Le patient doit accepter la de- Refuser la partage de demande conforme
demande mande de patient pour accéder
à leur historique
5.8 Conclusion
Ce dernier chapitre présente le release 2, ce release a pour deux sprint chaque
sprint à pour le backlog de sprint, l’analyse de chaque sprint et s’intéresse de la
réalisation et le test et validation.

Chapitre 6
6.1 Introduction
Dans ce chapitre, nous allons présenter la réalisation du troisième release, or-
ganisant le travail sur les phases principales qui sont l’analyse, la conception et la
6.2 Sprint5 : Analyste

6.2.1 Backlog du sprint 5

1 Gérer les recom- En tant que analyste je veux créer , 2
mandations chercher , supprimer et modifier les re-
commandations pour gérer les recom-
mandations
2 Prévisualisation les En tant que analyste je veux pré visua- 3
statistiques liser les statistiques
96
6.2.3 Analyse
• Analyste : est un acteur secondaire. Son rôle est de gérer recommandations et

pré visualiser les statistiques.
Table 6.2 – Tableau descriptive « Créer recommandation »
Titre Créer
Résumé Créer recommandation
Acteur Analyste
Post-condition(s) Recommandation crée
Pré-condition(s) Analyste doit être authentique

Scénario Nominal
1. Analyste remplir formulaire
3. le système envoi requête de création au base de donnée
4. le base de donnée ajoute un enregistrement
5. Base de donnée renvoi résultat de requête de création recom-
mandation au système
6. Le système afficher le message de création avec succès
Scénario Alternatif 2)a)-Le système renvoi message d’erreur en cas de fausse remplir

Table 6.3 – Tableau descriptive « Modifier recommandation »
Titre Modifier
Résumé Modifier recommandation
Acteur Analyste
Post-condition(s) Recommandation modifiée

Scénario Nominal
1. Analysre choisir champ a modifié.
2. Execution requête.
3. Base de donnée collecte les informations.
4. Base de donnée renvoi résultat d’anciens données.
5. Le système afficher formulaire contenant les anciennes don-
nées.
6. Le système vérifier les informations.
7. l’analyste modifier les informations.
8. Le Système modifier les nouvelles données.
9. Base de donnée renvoi résultat de modification.
10. Base de donnée renvoi résultat a système.
11. Le Système renvoi un message (modifier avec succès).
Scénario Alternatif 6)a) Système renvoi un message d’erreur en cas de fausse remplir

Table 6.4 – Tableau descriptive « Supprimer recommandation »
Titre Supprimer
Résumé Supprimer recommandation
Acteur Analyste
Post-condition(s) Recommandation supprimée

Scénario Nominal
1. Choisir recommandation a supprimée.
3. l’analyste confirmer la suppression.
4. le système supprimer recommandation choisi
5. Base de donnée supprimer.
7. le système supprimer consultation avec succès
Scénario Alternatif 3)a) l’analyste annuler la demande.

Table 6.5 – Tableau descriptive « Chercher recommandation »
Titre Chercher
Résumé Chercher recommandation
Acteur Analyste
Post-condition(s) Recommandation trouvée

Scénario Nominal
1. L’analyste demande au système de chercher recommandation
2. Le système affiche la page de recherche
3. L’analyste saisit le nom de recommandation à rechercher
4. le système envoi résultat au base de donnée
5. le base de donnée collecte les informations nécessaires
6. le base de donnée renvoi la réponse de collection au système
sous forme de table
7. le système affiche la résultat
Scénario Alternatif 7.1 le système affiche un tableau vide
Figure 6.2 – Diagramme de cas d’utilisation de sprint 5

6.2.4 Conception
• Dictionnaire


Utilisateur
Recommandation
id L’identifiant unique de recommandation INT
titre : Titre de recommandation TEXT
description Description de recommandation Date
domaine Domaine de recommandation TEXT
spécification Spécification de recommandation TEXT
retenu Retenu de recommandation TEXT
c) Conception dynamiques du sprint


Diagramme de séquence « modifier recommandation », Après s’être connecté Le mé-
decin clique sur le bouton modifier, Le système collecte les informations concernant
les recommandations et afficher formulaire, l’analyste choisir un élément à modifie,
le système vérifie les champs puis fait la mise à jour des champs dans la base de
donnée et affiche un message montrant que le champ à modifier avec succès ou si
non affiche un message d’erreur.
Figure 6.5 – Diagramme de séquence « Modifier recommandation »
Diagramme de séquence « Supprimer recommandation », Après s’être connecté,

analyste choisir un élément à supprimer, clique sur le bouton supprimer et demande
une confirmation le système affiche un message de confirmation. Lors de confirmation
le système envoi une demande de suppression et retourne un résultat suppression
avec succès. Tout s’ignoré lors d’une seule cliquet sur le bouton annuler.

Figure 6.6 – Diagramme de séquence « Supprimer recommandation »
Diagramme de séquence « Créer recommandation », Après être connecté l’ana-

lyste clique sur le bouton créer. Le système affiche le formulaire de création, l’analyste
remplit le formulaire, Le système vérifie les champs puis envoyer les données dans la
donnée vers la base de donnée, après base de donnée fait l’enregistrement et renvoi
résultat « créer recommandation » vers le système et le système renvoi un message
de création avec succès.

Figure 6.7 – Diagramme de séquence « Créer recommandation »
Diagramme de séquence « Chercher recommandation », Après être connecté le

médecin demande à chercher patient. Le système affiche le page des recommanda-
tions, le médecin saisir le nom de recommandation à rechercher, Le système envoi
résultat au base de de donnée, le base de donnée collecte les informations nécessaires
et renvoi la réponse de collection, le système affiche résultat de recherche.

Figure 6.8 – Diagramme de séquence « Chercher recommandation »
Figure 6.9 – Diagramme d’activité « supprimer recommandation »

Figure 6.10 – Diagramme de séquence « Créer recommandation »
Figure 6.11 – Diagramme de séquence «Modifier recommandation »

6.3 Réalisation
Table 6.7 – Tableau test et validation de sprint 5

Créer recom- L’analyste doit remplir formu- Affichage message d’erreur en cas conforme
mandation laire pour créer une recomman- de fausse remplir
dation
Supprimer L’analyste doit choisi la recom- La suppression annulée quand conforme
recommanda- mandation à supprimer pour l’analyste annuler la demande de
tion supprimer la recommandation suppression
avec sucée
Modifier L’analyste afficher liste des re- Affichage message d’erreur en cas conforme
recommanda- commandations pour modifier de fausse remplir
tion recommandation a choisi
chercher L’analyste afficher liste des re- Affichage table vide conforme
recommanda- commandations pour consulter
tion
6.5 Conclusion
Ce dernier chapitre présente le release 3, ce release a pour 1 sprint chaque sprint
à pour le backlog de sprint, l’analyse de chaque sprint et s’intéresse de la réalisation
et le test et validation.

Conclusion générale
En guise de conclusion, en va rappeler que notre projet de fin d’étude vise à réa-
liser une application web mobile qui facilite les échanges des données et des services
entre les cadres médicaux. On va donner une idée brève sur tous les contenus de
notre travail.
Le présent rapport détaille toutes les étapes par laquelle nous sommes passées pour
arriver au résultat attendu.Tout d’abord nous avons comprendre le contexte général
du projet commencé par la présentation générale du projet qui contient la présen-
tation du sujet,la problématique et critique des solutions existantes puis la solution
proposé.Après nous avons procédé au choix de la démarche du projet qui est la mé-
thode Scrum la plus adaptable de notre projet et enfin d’expliquer les principes et
les rôles du Scrum.
Ensuite,nous avons défini les différent acteurs de notre application, les besoins
fonctionnels puis les besoins non fonctionnels.Après,nous avons préparé par la suite
le backlog produit, en respectant les priorités des besoins suite à une discussion avec
l’équipe Scrum et enfin l’organigramme des tâches tel que le planification et le dia-
gramme de gantt.
Aprés on a effectué l’architecture du projet qui incluse la carte d’identité et l’archi-
tecture de la solution ainsi que la conception détaillée et l’environnement du travail.
Finalement, on a effectué la mise en ouevre du release 1,2 et 3 d’où release 1 et 2

chaqu’un contient 2 sprints et release 3 contient 1 sprint, et chaque sprint contient
le backlog produit, le tableau de tâches ainsi que l’analyse et la conception et ter-
minant par ma réalisation et test de validation.
Ce projet est une bonne occasion pour avoir une connaissance approfondie au
niveau de développement des sites web mobile ayant une meilleur qualité d’interface.
En fin Cette application peut être améliorée par d’autre fonctionnalité et hébergé
pour qu’elle soit accessible par les internautes.
109
Webographie
[1] https ://dhtmlx.com/docs/products/dhtmlxSuite/

Dernière visite le 22/02/2021
[2] https ://www.google.com/forms/

[3] https ://waytolearnx.com/2020/06/difference-entre-mvc-et-mvvm.html

[4] https ://www.flaticon.com/

Dernière visite 17/03/2021
[5] https ://themeforest.net

[6] https ://www.med.tn

Dernière visite 27/04/2021
[7] https ://play.google.com/store/apps/details ?id=com.cliniconline

[8] https ://console.cloud.google.com/home/dashboard ?hl=frproject=blockchain-

312912supportedpurview=project
[9] https ://trello.com/

[10] https ://www.journaldunet.fr/web-tech/guide-de-l-entreprise-digitale/1443834-

scrum-presentation-et-avantage-de-la-methode-agile-star/
110
CHAPITRE 6. BIBLIOGRAPHY
[11] https ://www.atlassian.com/fr/agile/scrum/sprint-planning

[12] https ://laurent-audibert.developpez.com/Cours-UML/ ?page=diagramme-

cas-utilisation : :text=Un
[13] https ://lms.fun-mooc.fr/c4x/usousse/74001S02/asset/Lecon2 .1.pdf

Dernièrevisitele07/05/2021
[14] https ://www.lucidchart.com/pages/fr/diagramme-package-uml : :text=Les

[15] https ://laurent-audibert.developpez.com/Cours-UML/ ?page=diagramme-

activites
[16] https ://blockchainfrance.net/decouvrir-la-blockchain/c-est-quoi-la-blockchain/

[17] https ://bitconseil.fr/blockchain-sante-presentation-cas-usage/

[18] http ://ittrends.tech/agilite-au-secours-ils-sont-devenus-fous/ / le dernière

visite le 05/03/2021
[19] https ://www.vagrantup.com

[20] https ://zidsoft.com/ ?gclid=CjwKCAjwtpGGBhBJEiwAyRZX2jRO0miKacdB1CBo T Xd2
[21] https ://laravel.com(Dernière visite le 18/04/2021)
[22] https ://www.python.org/downloads/(Dernière visite le 27/03/2021)
[23]https ://developer.android.com/studio ?hl=frgclid=CjwKCAjwtpGGBhBJEiwAyRZX2sekF

hoCVDUQAvDB wEgclsrc = aw.ds
(Dernièrevisitele20/02/2021)
[24] https ://www.irif.fr/ carton/Enseignement/InterfacesGraphiques/Cours/Swing/mvc.html

(Dernière visite le 11/03/2021)

CHAPITRE 6. BIBLIOGRAPHY
[25] https ://getcomposer.org (Dernière visite le 18/04/2021)
[26] https ://httpd.apache.org/download.cgi (Dernière visite le 20/02/2021)
[27]https ://www.scriptcase.net/ ?gclid=CjwKCAjw2ZaGBhBoEiwA8pfPr 1GzsRf deyRHXhv

F m6oY T BoC8U QAvDB wE(Dernièrevisitele17/02/2021)
[28] https ://code.visualstudio.com (Dernière visite le 20/04/2021)
[29] https ://www.01net.com/telecharger/windows/Internet/editeurd es ite/f iches/29119html(D
[30] https ://staruml.io/download (Dernière visite le 16/02/2021)
[31] https ://git-scm.com/downloads (Dernière visite le 17/02/2021)
[32] https ://www.mysql.com/fr/products/workbench/( Dernière visite le 28/02/2021)
[33] https ://fr.overleaf.com/project (Dernière visite le 18/06/2021)
[34] https ://www.developpez.net/forums/d1583930/general-developpement/alm/architecture/

entre-architecture-physique-architecture-logique/
Dérniere visite le 12/03/2021

Acronymes
PHP : HyperText Préprocesseur
CSS : Cascading Style Sheets
MVC : Modèle Vue contrôleur
UML : Unified Modeling Language
Js : Java Script
SQL : langage de requête structurée
XML : Extensible Markup Language
HTML : Hypertext Markup Language
Annexe A
Annexe
Enquête : Une enquête est une opération qui a pour but la découverte de faits,
l’amélioration des connaissances ou la résolution de doutes et de problèmes. Concrè-
tement, il s’agit d’une recherche poussée d’informations, avec le but de l’exhaustivité
dans la découverte des informations inconnues au début de l’enquête et parfois la
volonté de publication des informations collectées.
Analyse de l’enquête
Figure A.1 – capture 1 de statistique de l’enquête de question 1
1
ANNEXE A. ANNEXE

ANNEXE A. ANNEXE

ANNEXE A. ANNEXE

Pfepfe

Transféré par

Droits d'auteur :

Formats disponibles

Pfepfe

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pfepfe

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l‘Enseignement Supérieur et de la Recherche Scientifique

Faculté des Sciences Juridiques, Économiques et de Gestion de

Realisé par : Sabrine Khemiri

Encadré par : Mr.Mongi Boulehmi

Année universitaire : 2020-2021

Table des figures vii

1 Présentation générale du projet 3

2 Analyse et spécification des besoins 18

3.3 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Mise en œuvre du release 1 42

5 Mise en œuvre du release 2 66

5.4 Test et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6 Mise en œuvre du release 3 96

1.1 Capture d’écran de l’Accueil de l’application « Med »[6] . . . . . . . . 6

2.1 Liste des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Carte d’identité du projet . . . . . . . . . . . . . . . . . . . . . . . . 28

3.14 Android Studio[23] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Tableau de tâches de sprint 1 . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Tableau de tâches de sprint 3 . . . . . . . . . . . . . . . . . . . . . . 67

5.9 Diagramme de séquence « Supprimer consultation » . . . . . . . . . . 78

6.1 Tableau de tâches de sprint 5 . . . . . . . . . . . . . . . . . . . . . . 97

A.1 capture 1 de statistique de l’enquête de question 1 . . . . . . . . . . . 1

1.1 Analyse technique de l’application « Med » . . . . . . . . . . . . . . . 5

2.1 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.13 Tableau descriptive de sprint4 « accès à l’historique (suivi état santé) » 85

6.1 Backlog du sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Le secteur de la santé fait face à de nombreuses problématiques que certaines en-

Plusieurs acteurs de la santé s’intéressent de près à la création d’un registre

Nous essayerons de présenter dans ce qui suit l’organisation de notre rapport :

• Le premier chapitre Présentation Générale du Projet est un chapitre introduc-

Sabrine Khemiri 2 Blockchain Médical

1.2 Présentation du Projet

L’application se demandée s’intitule Blockchain Médical. Elle a pour objectif de

o Axe Gestion du projet : utilisation de la méthode agile Scrum.

o Axe modélisation conceptuelle : utilisation du langage de modélisation UML

o Axe de développement : utilisation du langage PHP7, Android, Python, Lare-

1.2.2 Critique des solutions existantes

1.2.2.1 Application similaire « Med »

Analyse fonctionnelle de « Med »

Sabrine Khemiri 4 Blockchain Médical

Table 1.1 – Analyse technique de l’application « Med »

Sabrine Khemiri 5 Blockchain Médical

Figure 1.1 – Capture d’écran de l’Accueil de l’application « Med »[6]

Sabrine Khemiri 6 Blockchain Médical

Figure 1.2 – Capture d’écran de l’interface des spécialités de l’application « Med

Sabrine Khemiri 7 Blockchain Médical

Sabrine Khemiri 8 Blockchain Médical

1.2.3 Application similaire « DOSSIER Médicaux »

Table 1.2 – Analyse technique de l’application « DOOSIER Médicaux »

Sabrine Khemiri 9 Blockchain Médical

Figure 1.4 – Capture d’écran de l’interface d’inscription de l’application « DOS-

Sabrine Khemiri 10 Blockchain Médical

Figure 1.5 – Capture d’écran de l’interface d’inscription de l’application « DOS-

Sabrine Khemiri 11 Blockchain Médical

Figure 1.6 – Capture d’écran de l’interface de menu de l’application « DOOSIER

Sabrine Khemiri 12 Blockchain Médical