SlideShare une entreprise Scribd logo
1  sur  121
Télécharger pour lire hors ligne
Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique
Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique
Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique
Dédicace
À MES CHERS PARENTS (Mamia & Rachid)
Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma
considération pour les sacrifices que vous avez consentis pour mon instruction
et mon bien-être. Je vous remercie pour tout le soutien et l’amour que vous me
portez depuis mon enfance et j’espère que votre bénédiction m’accompagne
toujours. Que ce modeste travail soit l’exaucement de vos vœux tant formulés,
le fruit de vos innombrables sacrifices, bien que je ne vous en acquitterai
jamais assez. Puisse Dieu, le Très Haut, vous accorder santé, bonheur et longue
vie et faire en sorte que jamais je ne vous déçoive.
A ma chère sœur Olfa
Ma chère sœur présente dans tous mes moments d’examens par son soutien
moral et ses belles surprises sucrées. Je te souhaite un avenir plein de joie, de
bonheur, de réussite et de sérénité. Je t’exprime à travers ce travail mes
sentiments de fraternité et d’amour.
A mon cher frère Ala
Aucun mot ne pourrait exprimer l’attachement, l’amour et la tendresse que
j’éprouve pour vous. Je prie le Bon Dieu de me donner la force et les moyens de
toujours prendre soin de vous.
Enfin, une dédicace spéciale à une Personne spéciale qui se reconnaitra
Soumaya Nebli
Dédicace
A ma très chère mère Rbeh
Affable, honorable, aimable : Tu représentes pour moi le symbole de la bonté
par excellence, la source de tendresse et l’exemple du dévouement qui n’a pas
cessé de m’encourager et de prier pour moi.
A mon très cher père Noureddine
Mon père qui a toujours me soutenir, me conseiller, m’assister et m’indique le
bon chemin. L’amour qui il me voue est irremplaçable …. Ses sacrifices pour
mon éducation et mes études sont énormes, je lui dois beaucoup et je lui suis
que reconnaissante.
A mon très cher frère Achref, son épouse Yassmine Et leur
petit garçon Amen Allah
Mon cher frère qui m’est le père et la mère, les mots ne suffisent guère pour
exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mon
ange gardien et mon fidèle compagnon dans les moments les plus délicats de
cette vie mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur,
de santé et de réussite.
A ma très chère soeur Yossra
En témoignage de l’attachement, de l’amour et de l’affection que je porte pour
toi. Tu es toujours dans mon cœur. Je te remercie pour ton hospitalité sans égal
et ton affection si sincère. Je te dédie ce travail avec tous mes vœux de bonheur,
de santé et de réussite.
Ibtissem Slimeni
Remerciements
Avant d’entamer ce rapport, nous profitons de l’occasion pour
exprimer nos vifs remerciements à toute personne ayant contribué, de
près ou de loin, à l’accomplissement de ce travail.
Le Seigneur Dieu tout puissant, pour m’avoir accordé vie, santé et
paix de l’esprit sans quoi je n’aurai pu achever nous projet de fin
d'étude
Nous souhaitons remercier notre encadrant Mme Ismahen chahbi,
qui n’a pas cessé de nous encourager pendant la réalisation de ce
travail de fin d’études ainsi pour sa générosité en matière de
formation et d’encadrement.
M. Izhar Mahjoub, Mohamed kTARi pour nous avoir offert
l’opportunité d’effectuer ce stage, ainsi pour leurs suivis et
encouragements, leurs entières disponibilités à nous fournir leur
confiance et leur assistance la plus attentionnée.
Nous tenons à remercier vers nos familles et nos amis de nous avoir
soutenus et encouragés tout au long de notre projet.
Finalement nous remercions tous les enseignants de l’École Supérieur
d’Économie Numérique pour nos trois années de licence.
Soumaya Nebli & Ibtissem Slimeni
Table des matières
Introduction générale ....................................................................................................... 1
Chapitre I : Étude de projet............................................................................................... 2
Introduction ............................................................................................................................. 2
I. Cadre du projet...................................................................................................................................... 2
1. Description du contexte de projet : .................................................................................................. 3
II. L’état de l’art ......................................................................................................................................... 4
1. OpenMRS .......................................................................................................................................... 4
2. Critique.............................................................................................................................................. 5
III. Méthode de modélisation et de conception ......................................................................................... 5
1. Méthode agile ................................................................................................................................... 5
2. SCRUM............................................................................................................................................... 6
IV. Langage de modélisation UML (Unified Modeling Language)............................................................... 9
Conclusion................................................................................................................................ 9
Chapitre II : Planification et Architecture..........................................................................10
Introduction ........................................................................................................................... 10
I. Capture des besoins : .......................................................................................................................... 10
1. Identification des acteurs................................................................................................................ 10
2. Analyse des besoins fonctionnels.................................................................................................... 10
3. Analyse des besoins non fonctionnels ............................................................................................ 11
II. Structure et découpage du projet ............................................................................................................ 11
1. Identification de l’équipe SCRUM ................................................................................................... 11
2. Le backlog du produit...................................................................................................................... 11
3. Planification des releases................................................................................................................ 12
4. Diagramme du cas d’utilisation global ............................................................................................ 13
Conclusion.............................................................................................................................. 13
Chapitre III : Sprint 1 : Gestion de personnel .....................................................................14
Introduction ........................................................................................................................... 14
I. Spécification des besoins..................................................................................................................... 14
1. Le sprint backlog ............................................................................................................................. 14
II. Diagramme des cas d’utilisation du premier Sprint ............................................................................ 16
1. Classification des cas d’utilisation par acteur ................................................................................. 16
2. Diagramme du cas d’utilisation du premier sprint.......................................................................... 16
III. Analyse des cas d’utilisation................................................................................................................ 17
1. Analyse du cas « s’authentifier »..................................................................................................... 17
2. Analyse du cas « gérer les utilisateurs».......................................................................................... 18
3. Analyse du cas «gérer rendez-vous»................................................................................................... 20
4. Analyse du cas «gérer fiche patient» .................................................................................................. 23
IV. Conception des cas d’utilisation.......................................................................................................... 27
1. Modèle d’analyse du cas d’utilisation «s’authentifier»................................................................. 27
2. Modèle d’analyse du cas d’utilisation « générer le site»..................................................................... 29
3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous»........................................................... 32
4. Modèle d’analyse du cas d’utilisation «gérer fiche patient» .............................................................. 37
5. Diagramme de Classe globale du premier sprint ................................................................................. 41
V. Codage...................................................................................................................................................... 42
VI. Test.......................................................................................................................................................... 43
Conclusion.............................................................................................................................. 44
Chapitre IV : Sprint 2 : Gérer la consultation et l’ordonnance ...........................................45
Introduction ........................................................................................................................... 45
I. Spécification des besoins..................................................................................................................... 45
1. Le sprint backlog ............................................................................................................................. 45
II. Diagramme du cas d’utilisation du deuxième sprint ............................................................................... 46
1. Répartition des cas d’utilisation par acteur .................................................................................... 47
III. Analyse des cas d'utilisation.................................................................................................................... 48
1. analyse des cas d'utilisation «gérer la consultation»........................................................................... 48
2. Analyse du cas d’utilisation «gérer antécédent»:............................................................................... 51
3. Analyse du cas d’utilisation «gérer examen»....................................................................................... 55
4. analyse des cas d'utilisation «gérer données anthropométriques» .................................................... 58
5. analyse des cas d'utilisation «gérer ordonnance»............................................................................... 62
IV. Conception de cas d'utilisation ............................................................................................................... 65
1. Modèle d’analyse du cas d’utilisation «gérer la consultation»........................................................... 65
2. Diagramme de classe globale de deuxième sprint.............................................................................. 88
V. Codage...................................................................................................................................................... 89
VI. Test.......................................................................................................................................................... 90
Conclusion.............................................................................................................................. 92
Chapitre V : Sprint 3: Gérer le dossier médical .................................................................93
Introduction ........................................................................................................................... 93
I. Spécification des besoins........................................................................................................................... 93
1. Sprint Backlog ...................................................................................................................................... 93
II. Diagramme des cas d’utilisation du troisième Sprint............................................................................... 94
1. Classification des cas d’utilisation par acteur ...................................................................................... 94
2. Diagramme de cas d’utilisation du Troisième sprint............................................................................ 94
III. Analyse des cas d’utilisation.................................................................................................................... 95
1. Analyse des cas d’utilisation «gérer le dossier médical» ..................................................................... 95
IV. Conception du cas d'utilisation ............................................................................................................... 97
1. Modèle d’analyse du cas d’utilisation «consulter dossier médical» .............................................. 97
2. Modèle d’analyse du cas d’utilisation du cas «imprimer dossier médical»......................................... 98
3. Diagramme de classe global du troisième sprint ............................................................................... 100
V. Codage.................................................................................................................................................... 101
VI. Test........................................................................................................................................................ 101
Conclusion.............................................................................................................................101
Chapitre VI : phase de clôture ........................................................................................102
Introduction ..........................................................................................................................102
I. Environnement de développement................................................................................................... 102
1. Environnement matériel ............................................................................................................... 102
2. Environnement logiciel.................................................................................................................. 102
3. Technologies et Langage de programmation utilisée ................................................................... 103
II. Style architectural.............................................................................................................................. 104
III. Elaboration du diagramme de déploiement...................................................................................... 105
1. Diagramme de déploiement .............................................................................................................. 106
2. Diagramme de Gantt.......................................................................................................................... 106
Conclusion.............................................................................................................................106
Conclusion générale......................................................................................................107
Bibliographie.................................................................................................................108
Neto graphie .................................................................................................................108
Liste des figures
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting...................................... 3
Figure2 : Scrum en rugby........................................................................................................... 6
Figure3: Le processus SCRUM ........................................................................................................................ 7
Figure 4: exemple de plan de release........................................................................................................... 13
Figure 5 : diagramme du cas d’utilisation global.......................................................................................... 13
Figure 6 : diagramme du cas d’utilisation du premier sprint ....................................................................... 16
Figure 7 : Diagramme de séquence système du cas « S’authentifier »........................................................ 17
Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur »................................................. 18
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»............................................... 19
Figure10 : Diagramme de séquence système du cas « supprimer utilisateur» ........................... 20
Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous ».............................................................. 20
Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous » ...................................... 21
Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous » ................................... 22
Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous » ................................... 23
Figure 15 : diagramme du cas d’utilisation « gérer patient ».................................................... 24
Figure16 : Diagramme de séquence système du cas « ajouter patient ».................................................... 25
Figure 18 : Diagramme de séquence système du cas « supprimer patient ».............................................. 27
Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier »......................................................... 28
Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter utilisateur
du cas « ajouter utilisateur »........................................................................................................................ 29
Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur» ................................................... 29
Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur » .............................................. 30
Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « modifier
utilisateur » .................................................................................................................................................. 30
Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur» .............................................. 30
Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du cas « supprimer
utilisateur » .................................................................................................................................................. 31
Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur ».......................................... 32
Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter rendez-
vous » ........................................................................................................................................................... 32
Figure 32 : Modèle de classe d’analyse d’utilisation «ajouter rendez-vous ».............................................. 33
Figure 33: Diagramme de séquence détaillé du cas d’utilisation « ajouter rendez-vous»......................... 33
Figure34 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« modifier rendez-vous »..................................................................................... 34
Figure 35 : Modèle d’analyse d’utilisation « modifier rendez-vous »......................................... 34
Figure 37 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation«
supprimer rendez-vous »............................................................................................................................. 35
Figure 38 : Modèle de classe d’analyse d’utilisation « supprimer rendez-vous »........................................ 36
Figure 40 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation :
« ajouter patient »........................................................................................................................................ 37
Figure 41 : Modèle de classe d’analyse d’utilisation « ajouter patient»...................................................... 37
Figure 43: Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier patient »...................................................................................................................................... 38
Figure 44 : Modèle de classe d’analyse d’utilisation « modifier patient ».................................................. 39
Figure 45 : Diagramme de séquence détaillé du cas « modifier patient ».................................................. 39
Figure 46 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer patient ».................................................................................................................................. 40
Figure 47 : Modèle de classe d’analyse d’utilisation « supprimer patient » ............................................... 40
Figure 48 : Diagramme de séquence détaillé du cas « supprimer patient » ............................................... 41
Figure 49 : diagramme de classe globale du premier sprint ...................................................... 41
Figure 50 : page d’authentification .............................................................................................................. 43
Figure 51 : page de la fiche patient .............................................................................................................. 43
Figure 52: page de rendez-vous .................................................................................................................. 44
Figure 53: Diagramme du cas d’utilisation global du deuxième sprint ....................................................... 47
Figure 54: cas d’utilisation du cas « gérer la consultation »......................................................................... 48
Figure 56 : Diagramme de séquence système du cas « ajouter diagnostics » ............................................. 49
Figure 57 : Diagramme de séquence système du cas « modifier diagnostics » ........................................... 50
Figure 58 : Diagramme de séquence système du cas « supprimer diagnostics » ....................................... 51
Figure 59 : cas d’utilisation du cas « gérer antécédent».............................................................................. 51
Figure 60: Diagramme de séquence système du cas « ajouter antécédent ».............................................. 52
Figure 61: Diagramme de séquence système du cas « modifier antécédent »............................................ 53
Figure 62: Diagramme de séquence système du cas « supprimer antécédents » ....................................... 54
Figure 63: Diagramme du cas d’utilisation « gérer examen »...................................................................... 55
Figure 64 : Diagramme de séquence système du cas « ajouter examen » .................................................. 56
Figure 65: Diagramme de séquence système du cas « modifier examen » ................................................. 57
Figure 66: Diagramme de séquence système du cas «supprimer examen » ............................................... 58
Figure 67 : diagramme du cas d’utilisation «gérer données anthropométriques ».................................... 58
Figure 68: Diagramme de séquence système du cas «ajouter données anthropométriques»................... 59
Figure 69: Diagramme de séquence système du cas «modifier données anthropométriques»................. 60
Figure 70: Diagramme de séquence système du cas «supprimer données anthropométriques»............. 61
Figure 72 : Diagramme de séquence système du cas « ajouter ordonnance »............................................ 63
Figure 73 : Diagramme de séquence système du cas « consulter l’ordonnance »...................................... 64
Figure 74 : Diagramme de séquence système du cas « supprimer l’ordonnance ».................................... 65
Figure 75 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«ajouter diagnostic ».................................................................................................................................... 65
Figure 76: Modèle de classe d’analyse d’utilisation «ajouter diagnostic » ................................................. 66
Figure 77 : Diagramme de séquence détaillée du cas «ajouter diagnostic » ............................................... 66
Figure 78: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier diagnostic».................................................................................................................................. 67
Figure 79 : Modèle de classe d’analyse d’utilisation « modifier diagnostic» .............................................. 67
Figure 80: Diagramme de séquence détaillée du cas d’utilisation « modifier diagnostic» ......................... 68
Figure 81: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer diagnostic »............................................................................................................................. 68
Figure 82 : Modèle de classe d’analyse d’utilisation « supprimer diagnostic» ........................................... 69
Figure83 : Diagramme de séquence détaillée du cas d’utilisation « supprimer diagnostic » ..................... 69
Figure 84: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter antécédent».................................................................................................................................. 70
Figure85 : Modèle de classe d’analyse d’utilisation « ajouter antécédent » .............................................. 70
Figure 86 : Diagramme de séquence détaillée du cas « ajouter antécédent » ............................................ 71
Figure87 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«modifier antécédent»................................................................................................................................. 71
Figure88 : Modèle de classe d’analyse d’utilisation « modifier antécédent » ............................................ 72
Figure 89 : Diagramme de séquence détaillée du cas « modifier antécédent » .......................................... 72
Figure 90 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer antécédent»............................................................................................................................ 73
Figure 91 : Modèle de classe d’analyse d’utilisation «supprimer antécédent » ......................................... 73
Figure 92 : Diagramme de séquence détaillée du cas « supprimer antécédent » ...................................... 74
Figure 93 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter examen » ...................................................................................................................................... 74
Figure 94 : Modèle de classe d’analyse d’utilisation « ajouter examen »................................................... 75
Figure 95 : Diagramme de séquence détaillée de cas « ajouter examen ».................................................. 75
Figure 96 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier examen » .................................................................................................................................... 76
Figure 97 : Modèle de classe d’analyse d’utilisation « modifier examen »................................................. 76
Figure 98 : Diagramme de séquence détaillée de cas « modifier examen »............................................... 77
Figure 99 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer examen ».................................................................................................................................. 77
Figure 100 : Modèle de classe d’analyse d’utilisation « supprimer examen »............................................ 78
Figure 101 : Diagramme de séquence détaillée de cas « supprimer examen ».......................................... 78
Figure102 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«ajouter données anthropométriques»....................................................................................................... 79
Figure 103 : Modèle de classe d’analyse d’utilisation «ajouter données anthropométriques » ................ 79
Figure 104 : Diagramme de séquence détaillée de cas «ajouter données anthropométriques » ............... 80
Figure105 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«modifier données anthropométriques».................................................................................................... 80
Figure 106: Modèle de classe d’analyse d’utilisation «modifier données anthropométriques » ............... 81
Figure107 : Diagramme de séquence détaillée de cas « modifier données anthropométriques» ............. 81
Figure 108: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«supprimer données anthropométriques» ................................................................................................. 82
Figure109 : Modèle de classe d’analyse d’utilisation «supprimer données anthropométriques » ............ 82
Figure 110 : Diagramme de séquence détaillée de cas « supprimer données anthropométriques» .......... 83
Figure 111 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter ordonnance»................................................................................................................................. 83
Figure 112 : Modèle de classe d’analyse d’utilisation « ajouter ordonnance » .......................................... 84
Figure 113: Diagramme de séquence détaillée du cas « ajouter ordonnance »......................................... 84
Figure 114 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« consulter ordonnance» ............................................................................................................................ 85
Figure 115 : Modèle de classe d’analyse d’utilisation « consulter ordonnance »....................................... 85
Figure 116 : Diagramme de séquence détaillée du cas «consulter ordonnance »....................................... 86
Figure 117: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer ordonnance»........................................................................................................................... 86
Figure 118 : Modèle de classe d’analyse d’utilisation « supprimer ordonnance » ..................................... 87
Figure 119: Diagramme de séquence détaillée du cas «supprimer ordonnance » ..................................... 87
Figure 120 : Diagramme de classe globale de deuxième sprint ................................................................... 88
Figure 121: page de consultation ............................................................................................................... 90
Figure 122 : page d’ordonnance.................................................................................................................. 91
Figure 123: page diagnostic......................................................................................................................... 91
Figure 124: page d’examen .......................................................................................................................... 92
Figure 125: Diagramme du cas d’utilisation du troisième sprint ................................................................. 94
Figure 126 : Diagramme de séquence système du cas « consulter dossier médical »................................ 95
Figure 127 : Diagramme de séquence système du cas «imprimer dossier médical»................................... 96
Figure 128 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« consulter dossier médical»........................................................................................................................ 97
Figure 129 : Modèle de classe d’analyse d’utilisation « consulter dossier médical» .................................. 97
Figure 130 : diagramme de séquence détaillée du cas «consulter dossier médical» .................................. 98
Figure 131 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« imprimer dossier médical »...................................................................................................................... 98
Figure 132 : Modèle de classe d’analyse d’utilisation «imprimer dossier médical» ................................... 99
Figure 133: Diagramme de séquence détaillée du cas «imprimer dossier médical»................................... 99
Figure 134: diagramme de classe global du troisième sprint..................................................................... 100
Figure 135: page dossier médical............................................................................................................... 101
Figure 136: niveau de l’architecture........................................................................................................... 105
Figure 137 : Diagramme de déploiement................................................................................................... 106
Figure 138: Diagramme de Gantt............................................................................................................... 106
Liste des tableaux
Tableau 1: tableau de backlog initial................................................................................12
Tableau 2: Backlog du premier sprint ...............................................................................15
Tableau 3: classification des cas d'utilisation par acteur ...................................................16
Tableau 4: description textuelle du cas «S’authentifier»...................................................17
Tableau 5: description textuelle du cas «ajouter utilisateur» ............................................18
Tableau 6 : Description textuelle du cas « modifier utilisateur».......................................19
Tableau 8: description textuelle du cas « ajouter un rendez-vous »..................................21
Tableau 9 : Description textuelle du cas « modifier un rendez-vous » .............................22
Tableau 10 : Description textuelle du cas « supprimer un rendez-vous » ...........................23
Tableau 11 : Description textuelle du cas « ajouter patient » .........................................24
Tableau 12 : Description textuelle du cas « modifier patient » .........................................25
Tableau 13 : Description textuelle du cas « supprimer patient »........................................26
Tableau 14: table «app user»...........................................................................................42
Tableau 15: table «user profil» ........................................................................................42
Tableau 16 : table «rendez-vous».....................................................................................42
Tableau 17: table «patient » ...........................................................................................42
Tableau 18 : Backlog du deuxième Sprint .........................................................................46
Tableau 19: tableau de répartition du deuxième sprint.....................................................47
Tableau 20 : Description textuelle du cas « ajouter diagnostics »......................................48
Tableau 21 : Description textuelle du cas « modifier diagnostics »....................................49
Tableau 22 : Description textuelle du cas « supprimer diagnostics » .................................50
Tableau 23 : Description textuelle du cas « ajouter antécédent »......................................52
Tableau 24 : Description textuelle du cas « modifier antécédents »...................................53
Tableau 25 : Description textuelle du cas « supprimer antécédent » ................................54
Tableau 26 : Description textuelle du cas « ajouter examen »...........................................55
Tableau 27 : Description textuelle du cas « modifier examen»..........................................56
Tableau 28 : Description textuelle du cas « supprimer examen » ......................................57
Tableau 29 : Description textuelle du cas « ajouter données anthropométriques» ............59
Tableau 30 : Description textuelle du cas « modifier données anthropométriques»...........60
Tableau 31 : Description textuelle du cas « supprimer données anthropométriques»........61
Tableau 32 : Description textuelle du cas « ajouter ordonnance ».....................................62
Tableau 33 : Description textuelle du cas « consulter ordonnance » ................................63
Tableau 34 : Description textuelle du cas « supprimer ordonnance »..............................64
Tableau 35 : table « consultation » ..................................................................................89
Tableau 36: table « ordonnance » ...................................................................................89
Tableau 37: table « diagnostic » ......................................................................................89
Tableau 38 : table « antécédent » ....................................................................................89
Tableau 39: table « examen » .........................................................................................90
Tableau 40 : Backlog du troisième sprint..........................................................................93
Tableau 41: Classification des cas d’utilisation par acteur.................................................94
Tableau 42: Description textuelle du cas « consulter dossier médical » ............................95
Tableau 43 : Description textuelle du cas «imprimer dossier médical » .............................96
Tableau 44 : table « dossier médical »............................................................................101
1
Introduction générale
Les technologies de l’information participent aujourd’hui à l’amélioration de la qualité des
soins. En jouant d’une manière positive sur la tenue des dossiers médicaux, en facilitant
l’échange et le partage des données utiles à la décision médicale, tout en augmentant la
disponibilité et la rapidité d’accès à ces informations.
L’E-santé apparaît de plus en plus comme la solution à mettre en place pour pallier les
difficultés de notre système de soins qui est confronté aujourd’hui à plusieurs défis majeurs
tels que l’amélioration de suivi des patients et la confidentialité des données personnelles.
Dans ce cadre naît notre projet de fin d’étude effectuée au sein de la boîte de développement
ATH Consulting qui consiste à développer une application destinée à un médecin cardiologue
que nous envisageons intégrer dans l’outil OpenMRS. En effet, cette application permet
d’automatiser le protocole de soin des patients.
Le présent rapport est organisé en quatre chapitres :
-Dans le premier chapitre intitulé « Étude de projet », nous allons décrire le cadre général de
notre travail tout en présentant l’organisme d’accueil, l’étude de l’existant, l’outil OpenMRS
et la méthode de conception utilisée.
-Dans le deuxième chapitre intitulé « Planification et Architecture», nous allons présenter
les acteurs, les besoins fonctionnels et les besoins non fonctionnels de notre application.
-Le troisième chapitre intitulé « la gestion du personnel », le quatrième chapitre intitulé
«gérer la consultation et l’ordonnance» et le cinquième chapitre intitulé « gérer le dossier
médical » représente le corps de notre projet. En effet, ces trois chapitres seront appliqués
pour le développement de trois sprints du notre système tout en respectant les principes
fondamentaux de Scrum.
- Le dernier chapitre constitue « la phase de clôture » de notre travail. Il décrit les outils
utilisés pour la conception, et le développement de notre application.
Nous finissons par une conclusion générale, dans laquelle nous résumons notre travail, et nous
présentons l’apport de ce projet de fin d’études ainsi que les perspectives de notre application.
2
Chapitre I : Étude de projet
Introduction :
Dans ce chapitre, nous allons commencer par décrire le cadre de notre projet. Ensuite, nous
allons présenter la société au sein de laquelle nous avons effectué notre projet de fin d’études.
Enfin, nous allons décrire la méthode de gestion de projet SCRUM.
I. Cadre du projet :
Notre projet de fin d’études s’inscrit dans le cadre de l’obtention du diplôme de licence
appliquée en Commerce Électronique de l’École Supérieure d’Économie Numérique
(ESEN). Ainsi, nous avons développé une application qui permet de faciliter le processus
de soins.
 Présentation d’organisme d’accueil :
Notre stage de fin d’études a été effectué au sein de la boîte de développement (ATH
Consulting) que nous allons décrire dans la suite.
Historique :
 HIMSS (Healthcare Information and Management Systems Society) est une
organisation à but non lucratif dont le but est de promouvoir la meilleure utilisation
des technologies de l’information et des systèmes de gestion dans l’industrie des soins
de santé créent en 1961.
 64000 particuliers, 640 membres corporatifs (fournisseurs du soin de santé, étudiants,
fournisseurs de TIC, consultants et autres intervenants de l’industrie des TIC en santé).
 450 organisations à but non lucratif.
 5327 organisations de santé analysées annuellement dans le monde (2011).
 Europe : 15000 visiteurs par mois sur les sites européens du HIMSS.
 Autrement dit que HIMSS est une solution informatique de santé, systèmes de santé
électriques d’enregistrement EMR-EHR.
3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.
3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.
3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.
4
b. Critique de l’existant:
Durant la phase de l’étude de l’existant, nous avons détecté les anomalies suivantes :
o Absence d’un moyen de recherche rapide pour chercher une fiche, la secrétaire doit
faire une recherche manuelle fiche par fiche par nom de patient ce qui entraîne une
perte de temps.
o La gestion du rendez-vous se fait d’une manière manuelle ce qui provoque le risque
d’oublier ou de chevauchement des rendez-vous.
o Probabilité de perte de documentation.
o Pas de possibilité du partage des dossiers médicaux entre médecins.
c. Solution proposée :
o Pour palier aux problèmes cités ci-dessous, nous allons proposer un outil qui permettra
d’automatiser le processus de soins. ATH Consulting nous a proposé comme sujet de
projet de fin d’études de développer une plate-forme destinée à un médecin cardiologue
que nous envisageons intégrer dans l’outil l’OpenMRS. L’outil développé permettra
de standardiser les traitements médicaux et le partage électronique des données de
santé. En outre, il permettra aussi d’assurer la confidentialité des données
personnelles.
II. L’état de l’art :
1. OpenMRS :
Le système de gestion de dossier médical (OpenMRS) a été introduit en 2004 en tant que
plate-forme de système de gestion dossier médical open source destiné aux pays en
développement.
OpenMRS est soutenu par des équipes centrales de partenaires in Health, Regenstrief
Institue. [1]
Mission :
La mission d’OpenMRS est d’améliorer la prestation des soins de santé dans des
environnements aux ressources limitées en coordonnant une communauté mondiale qui crée
une robuste, évolutive, axée l’utilisateur, open source plate-forme de système de dossier
médical. [2]
Il existe d’autres outils similaires à OpenMRS dont on peut citer CliniSys :
CliniSys constitue un ensemble de solutions de gestion administrative et médicale qui
couvrent les différentes activités des établissements de santé, conçu avec une équipe
d’informaticiens et de professionnels de santé, et offre un haut degré d’adaptation selon la
5
spécialité et l’organisation de chaque établissement. CliniSys est installée actuellement dans
la majorité des polycliniques en Tunisie. [3]
2. Critique :
CliniSys est un logiciel médical utilisé dans la majorité de polycliniques. Il permet
d’échanger des informations de santé et des dossiers médicaux à l’intérieur de
polyclinique mais le problème est qu’on ne peut pas échanger l’information de santé ni le
dossier médical à l’extérieure d’une clinique.
Ce problème est résolu par le logiciel nommé l’OpenMRS.
III. Méthode de modélisation et de conception :
1. Méthode agile :
« Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion des
projets informatiques. Elles reposent sur des cycles de développement itératifs et
adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment
d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du
projet. » [4]
Les quatre utilités fondamentales agiles :
• L’interaction entre acteurs plutôt que les processus et les outils.
• Un produit opérationnel plutôt qu’une documentation pléthorique.
• La collaboration avec le client plutôt que la négociation du contrat.
• La réactivité face au changement plutôt que le suivi d'un plan. [5]
Les 12 principes de méthodes agiles :
1- Satisfaire le client en livrant tôt et régulièrement des logiciels utiles qui offrent une
véritable valeur ajoutée
2-Accepter le changement même tard dans le développement
3-Livrer fréquemment une application qui fonctionne
4-Collaborer quotidiennement entre clients et développeurs
5- Bâtir le projet autour des personnes motivées en leur fournissant
environnement et support et en leur faisant confiance
6
6-Communiquer par des conversations en face à face
7-Mesurer la progression avec le logiciel qui fonctionne
8-Garder un rythme de travail durable
9-Rechercher l’excellence technique et la qualité de la conception
10-Laisser l’équipe s’auto-organiser
11-Rechercher la simplicité
12-A intervalles réguliers, réfléchir aux moyens de devenir plus efficaces. [5]
Les principales méthodes agiles :
Nous différencions surtout :
 SCRUM
 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Crystal Clear
Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases,
nous avons opté SCRUM comme une méthodologie de conception et du développement.
2. SCRUM :
Le SCRUM est une méthode de gestion de projet .Elle a pour but d’améliorer la productivité
des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une mêlée. C’est une
technique de reprise du jeu après faute qui permet une équipe sur des bons rails par un effort
collectif. Cette méthode a été principalement conçue pour le développement des logiciels
informatiques. [6]
Figure2 : Scrum en rugby
7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
8
 Le Scrum master :
Le Scrum master est un leader au service de l’équipe SCRUM. Il aide tout le monde à changer
ces interactions pour maximiser la valeur créée par l’équipe SCRUM.
Le Scrum Master remplit leur rôle en s’assurant que l’équipe SCRUM adhère à la théorie aux
pratiques et aux règles de Scrum. [7]
 L’équipe de développement (Team) :
C’est l’équipe qui participe au projet. Elle est constituée de professionnels qui livrent à
chaque sprint un incrément « terminé » et potentiellement livrable du produit.
Ces équipes sont structurées par l’entreprise à organiser et gérer leur propre travail. [7]
Les artéfacts de Scrum :
Les artéfacts de Scrum sont conçus principalement pour maximiser la transparence
d’informations et des opportunités pour l’adaptation.
 Le Product Backlog : (Carnet de produit)
Ensemble des fonctionnalités (User Story) qui constitue le produit souhaité. Il doit être
priorisé pour permettre de développer les éléments de plus haute importance en
premier. [8]
 Le Sprint Backlog : (Carnet d’itération)
Sous-ensemble des éléments du Backlog de produit. Les éléments constituent les user
stories à développer au cours du sprint et sont préalablement détaillés pour pouvoir
être estimés par l’équipe de développement. Il est également priorisé.
 Burndown Charts : (Graphique d’avancement) :
Le Burndown Chart est un diagramme qui permet de visualiser l’avancement des
sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des
tâches en cours dans le Sprint. [9]
Il possède en abscisse le temps et en ordonnée les points d’histoire.
Planification d’un projet par Scrum :
 Sprint Planning : (Planification d’itération)
Le Sprint Planning permet de définir le Sprint Backlog.
Le Sprint Backlog est un sous-ensemble du Product Backlog.
Le Sprint Backlog correspond à un accord mutuel entre le product Owner et l’équipe
mais c’est le Product Owner qui décidé. [10]
 Daily Scrum Meeting (Mêlée quotidienne) :
La Mêlée Quotidienne (Daily Scrum) est l’un des premiers d’inspection et
d’adaptation dans Scrum. L’équipe de développement communique pour synchroniser
ses travaux et créer un plan pour les prochaines 24 heures. [11]
9
 Sprint Review (Revue d'itération):
La revue de Sprint est un évènement qui regroupe de nombreuses parties prenantes et
personnes expérimentées. Les revues de Sprint ont de nombreux résultats possibles, y compris
l’arrêt du projet. Dans la plupart des cas, l’Équipe est autorisée à commencer un autre Sprint.
Il me semble que les équipes matures peuvent déjà établir le but de leur prochain Sprint lors
de cette Revue. Elles trouvent que cela aide à maintenir le rythme d’un Sprint à l’autre.
L’objectif de la revue de sprint est le produit que l’Équipe a construit. [11]
 Rétrospective de sprint :
La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de
planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois.
Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum
Master s’assure que la réunion a eu lieu et que les participants en comprennent le but. [7]
IV. Langage de modélisation UML (Unified Modeling Language) :
« UNIFIED MODELING LANGUAGE » UML se définit comme un langage de
modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et
documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et
communiquer des points de vue.
UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit d’une simple
notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont
porteurs de sens au même titre que les mots d’un langage. [12]
Conclusion :
Au cours de ce chapitre, nous avons présenté l’organisme d’accueil « ATH Consulting ».
Ensuite, nous avons établi l’étude de l’existant qui nous a permis de mieux comprendre la
problématique afin de trouver la solution adéquate.
Enfin, nous avons opté pour le choix de la méthode de travail utilisée SCRUM. Nous avons
aussi présenté brièvement le langage de modélisation UML qui sera utilisé pour
l’élaboration des différents diagrammes de conception.
10
Chapitre II : Planification et Architecture
Introduction :
Dans ce chapitre, nous allons présenter les acteurs et leurs rôles, ainsi que les besoins
fonctionnels et les besoins non fonctionnels. Ensuite, nous identifierons l’équipe de SCRUM
et son rôle, par la suite nous décrivons le Backlog du produit. Enfin, nous présenterons la
planification des releases.
I. Capture des besoins :
La spécification des besoins représente la première phase du cycle de développement
d’un logiciel.
Elle sert à identifier les acteurs réactifs du système.
1. Identification des acteurs :
« Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositifs matériels ou autre système) qui interagit directement avec le système
étudié. »[12]
Les acteurs de notre système sont :
 La secrétaire : qui peut gérer les rendez-vous des patients et créer les fiches patients.
 Le médecin : peut créer les dossiers médicaux, générer des ordonnances patients et
planifier les activités faites la secrétaire.
 Administrateur : qui peut ajouter ou bien modifier ou supprimer un utilisateur
2. Analyse des besoins fonctionnels :
 Générer le site : l’administrateur peut accéder à une plate-forme et peut ajouter
ou modifier ou éliminer un utilisateur.
 Gérer les rendez-vous :
o La prise du rendez-vous s’effectue directement ou via notre
plate-forme en précisant la date, l’heure, le nom et le prénom
du patient selon la disponibilité du médecin.
 Gérer le patient :
o la secrétaire remplit les informations du patient.
o Les observations médicales notées par le médecin qui
doivent comprendre les antécédents du patient.
 Gérer consultation : c’est le médecin qui se charge de l’enregistrement des
ordonnances, des différents diagnostics, des antécédents (personnels, antécédents
11
familiaux), les données anthropométriques, ainsi que les examens (examens
physiques, examens complémentaires…).
 Gérer l’ordonnance : permet au médecin d’ajouter, de consulter ou bien
supprimer une ordonnance.
 Gérer le dossier médical :
o le dossier médical comprend l’historique des interventions
médicales subis par les patients (les médicaments qui lui ont
été prescrits, les résultats d’analyse, les antécédents
familiaux…)
3. Analyse des besoins non fonctionnels :
 Ergonomie : l’application doit offrir une interface conviviale exploitable par
l’utilisateur simple dans l’utilisation.
 Rapidité : le temps du chargement d’une page demandée par l’utilisateur ne
doit pas prendre plus que 30 secondes.
 Disponibilité : possibilité d’accès à l’application et à n’importe quelle
information 24h/24h et 7j/7j sauf en période de maintenance
 Sécurité et la confidentialité : l’accès à l’application doivent être sécurisé par
le login et le mot de passe.
II. Structure et découpage du projet :
1. Identification de l’équipe SCRUM :
L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la flexibilité, la
créativité et la productivité. Elle doit s’auto-organiser en choisit la meilleure façon
d’accomplir le travail. Elle doit avoir toutes les compétences nécessaires au
développement du produit.
Scrum définit trois rôles qui sont :
Le Product Owner (le propriétaire du produit : M.Izhar mahjoub): c’est la
personne qui a une vision du produit à accomplir, usuellement, c’est un expert dans
le domaine.
Le Scrum Master (le directeur du produit : M. Mohamed Ktari): c’est la personne
qui doit étayer le bon déroulement des différents sprints d’une release.
Le Scrum Team (l’équipe de Scrum : Soumaya &Ibtissem) : représenté par les
personnes qui sont chargées d’implémenter les besoins du client.
2. Le backlog du produit : c’est l’ensemble de fonctionnalités (User Story) du
produit que l’on veut développer comme nous avons déjà présenté.
Un User Story s’écrit comme suit :
12
- En tant que < utilisateur>
- Je désire < fonctionnalité>
- Pour pouvoir < résultat>
Pour chaque User Story on présente le rang, l’estimation, l’importance et la description
comme illustrée dans le tableau suivant :
ID En tant que Je désire Pour pouvoir Importance
1 Utilisateur +
administrateur
S’authentifier Accéder à la plate-
forme
+++
2 Administrateur Gérer les utilisateurs
de la plate-forme
Ajouter, modifier
et supprimer un
utilisateur
++++
3 Secrétaire Gérer le rendez-vous
et les patients
Pour planifier la
liste des rendez-
vous et pouvoir
ajouter, modifier et
supprimer des
patients
+++
4 Médecin Gérer consultation et
le dossier médical
Actualiser les
informations
existantes et
ajouter le résumé
de chaque
consultation, ainsi
que peut consulter
le dossier médical
+++++
Tableau 1: tableau de backlog initial
3. Planification des releases :
Un release correspond à la livraison d'une version. Par habitude, on parle de release pour
considérer la période du temps qui va du début du travail sur cette version jusqu'à sa livraison
et qui passe par une série de sprints successifs. [12]
La réunion de planification des releases est l’évènement le plus important dans Scrum.
L’objectif de cette réunion est de faire le planning de travail et d’identifier le backlog des
releases.
Tous les projets nécessitent des plans, afin de prévoir à peu près ce que va contenir un produit
ou à quelle date il sortira sur le marché.
Selon la méthodologie agile Scrum, la planification de releases aux mêmes points visés
puisqu’elle donne à l’équipe et aux parties prenantes des informations sur le contenu des
sprints constituant la release.
13
Figure 4: exemple de plan de release
4. Diagramme du cas d’utilisation global :
Figure 5 : diagramme du cas d’utilisation global
Conclusion :
Dans ce chapitre, nous avons identifié le rôle de chaque acteur en le représentant dans le
diagramme du cas d’utilisation global. Nous avons aussi présenté l’équipe du projet et défini
notre backlog du produit en nous basant sur les besoins fonctionnels et non fonctionnels.
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
sécretaire
médecin
administrateur
gérer patient
gérer rendez-vous
gérer consultation
gérer dossier
médical
gérer les utilisateurs
s'authentifier
14
Chapitre III : Sprint 1 : Gestion de personnel
Introduction :
Le sprint s’exprime comme un cœur de scrum. Il s’agit d’une unité du temps durant
laquelle un incrément du produit sera réalisé.
Dans ce chapitre, nous allons présenter le premier sprint.
I. Spécification des besoins :
Au sein de ce sprint, les users stories vont appliquer les quatre étapes du cycle scrum,
analyse, conception, développement et les tests.
1. Le sprint backlog :
Durant le premier chapitre, le sprint backlog est présent au cours de la réunion de
planification : il s’agit d’une série des tâches que l’équipe scrum doit réaliser durant le sprint
dans l’objectif d’arriver à la réalisation de la tâche au bout du temps escompté afin de
pouvoir enchaînée sur le sprint suivant.
Le tableau suivant présent toutes les fonctionnalités qui seront développées de ce sprint :
ID
U.S
User Story ID
tâche
Tâche Affectation
1 En tant qu’utilisateur
et administrateur, je
veux « authentifier»
1.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse, de
séquence détaillée du cas
« s’authentifier »
Soumaya
Nebli
2 En tant
qu’administrateur je
veux « gérer les
utilisateurs »
2.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée
«ajouter utilisateur »
Soumaya
Nebli
2.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence
détaillée «modifier utilisateur »
Soumaya
Nebli
2.3 Réaliser le diagramme du cas Soumaya
15
d’utilisation, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence, diagramme
de séquence détaillée « supprimer
utilisateur »
Nebli
3 En tant qu’utilisateur
je veux gérer
« rendez-vous »
3.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « ajouter un rendez-vous »
Soumaya
Nebli
3.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas «modifier un rendez-vous »
Soumaya
nebli
3.3 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas «supprimer un rendez-vous »
Ibtissem
Slimeni
4 En tant qu’utilisateur
je veux « gérer la
fiche du patient »
4.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « ajouter fiche patient »
Ibtissem
Slimeni
4.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « modifier fiche patient »
Ibtissem
Slimeni
4.3 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « supprimer fiche patient »
Tableau 2: Backlog du premier sprint
16
II. Diagramme des cas d’utilisation du premier Sprint :
Au début de chaque itération, nous allons schématiser la spécification fonctionnelle
par un diagramme du cas d’utilisation. Celle-ci servira comme une vue d’ensemble du
système et présentera les liens et les interactions entre les utilisateurs et les
fonctionnalités.
1. Classification des cas d’utilisation par acteur :
Ce tableau englobe les acteurs par leurs fonctionnalités :
Acteur Cas d’utilisation
Administrateur
Secrétaire
Médecin
 ajouter utilisateur
 modifier utilisateur
 supprimer utilisateur
 ajouter rendez-vous
 modifier rendez-vous
 supprimer rendez-vous
 ajouter patient
 modifier patient
 supprimer patient
Tableau 3: classification des cas d'utilisation par acteur
2. Diagramme du cas d’utilisation du premier sprint:
L’administrateur peut accéder à la plate-forme en utilisant un login et un mot de passe pour
ajouter, modifier et supprimer un utilisateur. Comme présenté dans la figure suivante:
Figure 6 : diagramme du cas d’utilisation du premier sprint
<<include>>
adminstrateur gérer les utilisateurs
ajouter user
modifier user
s'authentifier
supprimer user
17
III. Analyse des cas d’utilisation :
1. Analyse du cas « s’authentifier » :
1.1. Description textuelle du cas d’utilisation « s’authentifier » :
CU : s’authentifier
Acteur : administrateur et utilisateur (médecin, secrétaire)
Pré-condition :l’utilisateur doit être dans la base de données et possède des identifiants.
Post-condition : la première interface de l’application affichée
Scénario nominal : 1. L’utilisateur demande l’interface d’authentification.
2. Le système affiche l’interface demandée.
3. L’utilisateur saisit login et mot de passe.
4. Le système vérifie les informations saisies par l’utilisateur.
5. Le système affiche l’interface demandée.
Scénario alternatif : 4.1. l’utilisateur n’a pas saisi le bon paramètre d’authentification
4.2. l’utilisateur n’existe pas dans la base de données
Tableau 4: description textuelle du cas «S’authentifier»
1.2. Diagramme de séquence système du cas « S’authentifier » :
Chaque utilisateur doit s’authentifier, en créant son login et son mot de passe et sa catégorie
pour accéder à sa plate-forme. Le système affiche un message en cas d’erreur.
Figure 7 : Diagramme de séquence système du cas « S’authentifier »
s'authentifier
saisir login et mot de passe
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface demandée
vérifier
utilisateur
système
données invalides
données valides
alt
loop
saisir login et mot de passe
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface demandée
vérifier
18
2. Analyse du cas « gérer les utilisateurs» :
Administrateur peut accéder à la plate-forme, le système affiche les listes de fonctionnalités
qui permettent de l’utilisateur de choisir l’une des fonctionnalités « ajouter » ou « modifier »
ou « supprimer » utilisateurs :
2.1. Description textuelle cas d’utilisation « ajouter utilisateur » :
Cu Ajouter utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Utilisateur ajouté
Scénario nominal 1. L’administrateur clique sur ajouter utilisateur
2. Le système affiche le formulaire
3. L’administrateur remplit le formulaire
4. Le système vérifie
5. Le système enregistre le nouvel utilisateur
6. Le système affiche utilisateur ajouté
Scénario alternatif 4.1 donnée manquante
Tableau 5: description textuelle du cas «ajouter utilisateur»
2.2. Diagramme de séquence système du cas «ajouter utilisateur» :
La figure 8 illustre le diagramme de séquence du premier cas dans notre sprint.
L’administrateur doit s’authentifie avec son login et son mot de passe afin d’ajouter un
utilisateur à sa plate-forme. Si les champs sont remplis, le système affiche un message de
succès ou il affiche un message de retour à l’interface précédente.
Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur »
ajouter user
afficher utilisateur ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ajouter utilisateur
administrateur
systéme
ref
s'authentifier()
données invalides
données valides
alt
afficher utilisateur ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ajouter utilisateur
19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
20
2.5. Description textuelle du cas d’utilisation «supprimer utilisateur» :
Cu Supprimer utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Utilisateur supprimé
Scénario nominal 1. L’administrateur choisit l’utilisateur qu’il veut supprimer
2. Le système supprime l’utilisateur sélectionné
3. Le système affiche la suppression effectuée
Scénario alternatif Aucune
Tableau 7 : Description textuelle du cas « supprimer utilisateur »
2.6. Diagramme de séquence système du cas «supprimer utilisateur» :
L’administrateur a aussi le droit de supprimer un ou plusieurs utilisateurs.
Figure10 : Diagramme de séquence système du cas « supprimer utilisateur»
3. Analyse du cas «gérer rendez-vous» :
3.1. Diagramme du cas d’utilisation « gérer rendez-vous » :
L’utilisateur peut gérer un rendez-vous en ajoutant, modifiant ou annulant ce dernier.
Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous »
supprimer user
supprimer
afficher utilisateur supprimer
cliquer sur supprimer
adminstrateur
systeme
ref
s'authentifier()
supprimer
afficher utilisateur supprimer
cliquer sur supprimer
<<include>>
secrétaire
gérer rendez-vous
ajouter rendez-vous
modifier rendez-vous
supprimer rendez vous
s'authentifier
21
3.2. Description textuelle cas d’utilisation « ajouter rendez-vous» :
CU : gérer le rendez-vous : ajouter
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous ajouté
Scénario nominal :
1. l’utilisateur clique sur gérer rendez-vous
2. le système affiche le formulaire de rendez-vous
3. l’utilisateur remplit le formulaire présenté
4. le système vérifie si tous les champs remplis
5. le système affiche un message « rendez-vous ajouté »
Scénario alternatif : 4.1. le rendez- vous invalide
Tableau 8: description textuelle du cas « ajouter un rendez-vous »
3.3. Diagramme de séquence système du cas « ajouter rendez-vous» :
La figure 12 illustre le diagramme de séquence qui consiste à ajouter un rendez-vous. Si le
patient existe déjà, le système affiche un message d’erreur.
Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous »
ajouter rendez-vous
ajouter
vérifier
affiche le formulaire
remplir le formulaire présenté
rendez-vous ajouté
retour vers le formulaire
cliquer sur gérer le rendez-vous
utilisateur
système
ref
s'authentifier()
rendez-vous invalide
rendez-vous valide
alt
ajouter
vérifier
affiche le formulaire
remplir le formulaire présenté
rendez-vous ajouté
retour vers le formulaire
cliquer sur gérer le rendez-vous
22
3.4. Description textuelle cas d’utilisation « modifier un rendez-vous» :
CU : gérer le rendez-vous : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous modifié
Scénario nominal :
1. l’utilisateur clique sur gérer rendez-vous
2. le système affiche les listes de rendez-vous
3. l’utilisateur choisir le rendez-vous à modifier
4. le système affiche le formulaire
5. l’utilisateur saisit les nouvelles données
6. le système vérifie les champs remplis
7. l e système affiche un message « rendez-vous modifié »
Scénario alternatif : 6.1 : le rendez-vous réservé
Tableau 9 : Description textuelle du cas « modifier un rendez-vous »
3.5. Diagramme de séquence système du cas «modifier rendez-vous» :
La figure 13 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un ou
plusieurs rendez-vous. Si le rendez-vous n’est pas réservé, le système modifié le rendez-vous
sinon retour vers le formulaire.
Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous »
modifier rendez-vous
modifier
vérifier
saisir les nouvelles données
afficher le formulaire
rendez vous modifié
retour vers le formulaire
choisir le rendez-vous à modifier
afficher la liste du rendez-vous
cliquer sur gérer le rendez-vous
utilisateur
système
ref
s'authentifier()
rendez-vous invalide
rendez-vous valide
alt
modifier
vérifier
saisir les nouvelles données
afficher le formulaire
rendez vous modifié
retour vers le formulaire
choisir le rendez-vous à modifier
afficher la liste du rendez-vous
cliquer sur gérer le rendez-vous
23
3.6. Description textuelle cas d’utilisation « supprimer un rendez-vous» :
CU : rendez-vous : supprimer
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous supprimé
Scénario nominal :
1. l’utilisateur clique sur gérer le rendez-vous
2. le système affiche une liste de rendez-vous
3. l’utilisateur sélectionne le rendez-vous à supprimer
4. le système supprimer le rendez-vous
Scénario alternatif : aucun
Tableau 10 : Description textuelle du cas « supprimer un rendez-vous »
3.7. Diagramme de séquence système du cas « supprimer rendez-vous» :
La figure 14 illustre le diagramme de séquence qui permet à l’administrateur du supprimer
les rendez-vous.
Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous »
4. Analyse du cas «gérer fiche patient» :
L’utilisateur clique sur la rubrique fiche patient, le système affiche un formulaire à
remplir qui permet à l’utilisateur d’ajouter, modifier ou supprimer un patient.
supprimer rendez vous
supprimer
cliquer sur gérer le rendez-vous
afficher la liste du rendez-vous
sélectionner le rendez-vous à supprimer
afficher le rendez-vous supprimé
utilisateur
système
ref
s'authentifier()
supprimer
cliquer sur gérer le rendez-vous
afficher la liste du rendez-vous
sélectionner le rendez-vous à supprimer
afficher le rendez-vous supprimé
24
4.1. Classification du cas d’utilisation «gérer patient » :
Figure 15 : diagramme du cas d’utilisation « gérer patient »
4.2. Description textuelle cas d’utilisation « ajouter patient » :
CU : gérer le patient: ajouter
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient ajouté
Scénario nominal :
1. l’utilisateur clique sur ajouter patient
2. le système affiche l’interface demandée
3. l’utilisateur remplit le formulaire du patient
4. le système vérifie les champs et l’existence de patient
5. le système enregistre le nouveau patient
6. le système affiche patient enregistré
Scénario alternatif : 4.1 les champs ne sont pas bien remplis
5.1 le patient existe déjà dans la base
Tableau 11 : Description textuelle du cas « ajouter patient »
<<include>>
Secrétaire
gérer patient
ajouter patient
modifier patient
s'authentifier
supprimer patient
25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »
25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »
25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »
26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »
26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »
26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »
27
4.7. Diagramme de séquence système du cas « supprimer patient » :
Figure 18 : Diagramme de séquence système du cas « supprimer patient »
IV. Conception des cas d’utilisation :
Nous allons préparer les diagrammes Traçabilité entre le modèle de cas
d’utilisation et le modèle d’analyse du cas d’utilisation pour passer aux
diagrammes des séquences détaillés et les diagrammes des classes d’objets du
premier sprint.
1. Modèle d’analyse du cas d’utilisation «s’authentifier» :
1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « s’authentifier » :
Figure 19: Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation du cas « S'authentifier »
supprimer patient
supprimer
sélectionner le patient à supprimer
afficher liste du patient
cliquer sur fiche patient
afficher patient supprimé
utilisateur
système
supprimer
sélectionner le patient à supprimer
afficher liste du patient
cliquer sur fiche patient
afficher patient supprimé
<<trace>>
<participate><participate><participate>
utilisateur
s'authentifier
S'authentifier
contrôleur login user profil
interface autherntificationadministrateur
28
1.2 Modèle de classe d’analyse d’utilisation « s’authentifier » :
Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier »
1.3 Diagramme de séquence détaillé du cas d’utilisation « s’authentifier » :
Figure 21: diagramme de séquence détaillé du cas « S'authentifier »
uti l i sateur i nterface authenti fi cati on
contrôl eur l ogi n
user profi l
s'authentifier
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface d'accueil
vérifier
envoyer les données
saisir login et mot de passe
utilisateur interface _s'authentifier s'authentifier user profilinterface d'accueil
login ou mot de passe incorrect
login ou mot de passe correct
alt
loop
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface d'accueil
vérifier
envoyer les données
saisir login et mot de passe
29
2. Modèle d’analyse du cas d’utilisation « générer le site» :
2.1. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter
utilisateur » :
Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation «
ajouter utilisateur du cas « ajouter utilisateur »
2.2. Modèle de classe d’analyse d’utilisation « ajouter utilisateur» :
Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur»
<<trace>>
<participate><participate><participate>
administrateur
ajouter utilisateur Ajouter utilisateur
contrôleur new user user profilinterface formulaire
adminsitrateur
interface formulaire
contrôleur new useruser profil
30
2.3. Diagramme de séquence détaillé du cas d’utilisation « ajouter utilisateur» :
Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur »
2.4. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation
« modifier utilisateur » :
Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation
« modifier utilisateur »
2.5. Modèle de classe d’analyse d’utilisation « modifier utilisateur» :
Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur»
ajouter user
afficher utilisateur ajouté
réponse
retour vers formulaire
envoyer données
envoyer le formulaire
envoyer la demande
demander l'interface d'ajout
ajouter
vérifier
remplir le formulaire
administrateur Interface utilisateur e_utilisateurc_new user
ref
s'authentifier()
données manquantes
données remplis
alt
afficher utilisateur ajouté
réponse
retour vers formulaire
envoyer données
envoyer le formulaire
envoyer la demande
demander l'interface d'ajout
ajouter
vérifier
remplir le formulaire
<<trace>>
<participate>
<participate><participate>
administrateur
modifier
utilisateur
Modifier utilisateur
contrôleur edit user
user profilinterface modification
adm i nsi trateur
i nterface m odi fi cati on
contrôl eur edi t user
user profi l
31
2.6. Diagramme de séquence détaillé du cas d’utilisation « modifier utilisateur» :
Figure 27 : Diagramme de séquence détaillée du cas « modifier utilisateur »
2.7. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation «
supprimer utilisateur» :
Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du
cas « supprimer utilisateur »
modifier user
modifier
afficher nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher le formulaire de modification
réponse
vérifier
sélectionner sur l' utilisateur à modifier
envoyer la demande
administrateur Interface utilisateur user profilcontrôleur liste utilisateur
ref
s'authentifier()
données manquantes
données remplis
alt
modifier
afficher nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher le formulaire de modification
réponse
vérifier
sélectionner sur l' utilisateur à modifier
envoyer la demande
<<trace>>
<participate><participate><participate>
administrateur
supprimer
utilisateur
Supprimer
utilisateur
contrôleur liste
utilisateur
user profilinterface liste utilisateur
32
2.8. Modèle de classe d’analyse d’utilisation « supprimer utilisateur» :
Figure 29 : Modèle de classe d’analyse d’utilisation « supprimer utilisateur»
2.9. Diagramme de séquence détaillé du cas d’utilisation « supprimer utilisateur» :
Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur »
3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous» :
3.1 .Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter
rendez-vous » :
Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas
d’utilisation « ajouter rendez-vous »
adminsitrateur
interface liste utilisateur
contrôleur liste
utilisateuruser profil
supprimer user
choisir l'utilisateur à supprimer
réponse
afficher utilisateur supprimé
envoyer requête
envoyer demande
administrateur I_liste_utilisateur e_utilisateurc_utilisateur
ref
s'authentifier()
choisir l'utilisateur à supprimer
réponse
afficher utilisateur supprimé
envoyer requête
envoyer demande
<<trace>>
<participate><participate><participate>
utilisateur
ajouter rendez-
vous
Ajouter Rendez-
vous
controlleur
rendez-vous
rednez-vous
interface rendez-vous
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE
Rapport PFE

Contenu connexe

Tendances

Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...Hajer Dahech
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectAmine MEGDICHE
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
rapport de stage
rapport de stagerapport de stage
rapport de stageMarouane Gh
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidKhaled Fayala
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelBelwafi Bilel
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etudesihem-med
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRSkander Driss
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileNader Somrani
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5YounessLaaouane
 
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiquesERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiquesMohamed Aziz Chetoui
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCGhodbane Heni
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementNassim Bahri
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueYosra ADDALI
 

Tendances (20)

Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
rapport de stage
rapport de stagerapport de stage
rapport de stage
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme Android
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIR
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
 
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiquesERP médical pour la TRANSTU : module de gestion pharmaceutiques
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 

Similaire à Rapport PFE

Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileRim ENNOUR
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Karim Ben Alaya
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesMajdi SAIBI
 
rapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdfrapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdfSyrinaGaddour
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIAAhmed BEN JEMIA
 
Mise en place d'une stratégie de marketing digital
Mise en place d'une stratégie de marketing digital Mise en place d'une stratégie de marketing digital
Mise en place d'une stratégie de marketing digital Karim Ben Alaya
 
Etiquetage morphosyntaxique de l’arabe avec Nooj
Etiquetage morphosyntaxique de l’arabe avec NoojEtiquetage morphosyntaxique de l’arabe avec Nooj
Etiquetage morphosyntaxique de l’arabe avec NoojDhifallah OTHMEN
 
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08bouzidi26
 
Rapport restaurant le-roi
Rapport restaurant le-roiRapport restaurant le-roi
Rapport restaurant le-roiMarwa Bhouri
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachAyoub Mkharbach
 
Développement et conception d'une application de générateur des QR Code Dynam...
Développement et conception d'une application de générateur des QR Code Dynam...Développement et conception d'une application de générateur des QR Code Dynam...
Développement et conception d'une application de générateur des QR Code Dynam...shili khadija
 
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Ibtihel El Bache
 
Ms.ELN.Alat+Khelifi.pdf
Ms.ELN.Alat+Khelifi.pdfMs.ELN.Alat+Khelifi.pdf
Ms.ELN.Alat+Khelifi.pdfRsifProject
 
MALLAT_BOURUIS
MALLAT_BOURUISMALLAT_BOURUIS
MALLAT_BOURUISAli Mallat
 
Essai de mesure de la performance des etablissements de soins de sante de base
Essai de mesure de la performance des etablissements de soins de sante de baseEssai de mesure de la performance des etablissements de soins de sante de base
Essai de mesure de la performance des etablissements de soins de sante de baseKhabou Mohammed
 
Visualisation graphique des preuves Électroniques (complet)
Visualisation graphique des preuves Électroniques (complet)Visualisation graphique des preuves Électroniques (complet)
Visualisation graphique des preuves Électroniques (complet)Olga Ambani
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdfBader Nassiri
 
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...Abdelmadjid Djebbari
 

Similaire à Rapport PFE (20)

Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
rapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdfrapport-finale-ZoubairWassim.pdf
rapport-finale-ZoubairWassim.pdf
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
 
Mise en place d'une stratégie de marketing digital
Mise en place d'une stratégie de marketing digital Mise en place d'une stratégie de marketing digital
Mise en place d'une stratégie de marketing digital
 
Etiquetage morphosyntaxique de l’arabe avec Nooj
Etiquetage morphosyntaxique de l’arabe avec NoojEtiquetage morphosyntaxique de l’arabe avec Nooj
Etiquetage morphosyntaxique de l’arabe avec Nooj
 
Rapport final
Rapport finalRapport final
Rapport final
 
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
 
Rapport restaurant le-roi
Rapport restaurant le-roiRapport restaurant le-roi
Rapport restaurant le-roi
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Développement et conception d'une application de générateur des QR Code Dynam...
Développement et conception d'une application de générateur des QR Code Dynam...Développement et conception d'une application de générateur des QR Code Dynam...
Développement et conception d'une application de générateur des QR Code Dynam...
 
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
 
Ms.ELN.Alat+Khelifi.pdf
Ms.ELN.Alat+Khelifi.pdfMs.ELN.Alat+Khelifi.pdf
Ms.ELN.Alat+Khelifi.pdf
 
MALLAT_BOURUIS
MALLAT_BOURUISMALLAT_BOURUIS
MALLAT_BOURUIS
 
Essai de mesure de la performance des etablissements de soins de sante de base
Essai de mesure de la performance des etablissements de soins de sante de baseEssai de mesure de la performance des etablissements de soins de sante de base
Essai de mesure de la performance des etablissements de soins de sante de base
 
Visualisation graphique des preuves Électroniques (complet)
Visualisation graphique des preuves Électroniques (complet)Visualisation graphique des preuves Électroniques (complet)
Visualisation graphique des preuves Électroniques (complet)
 
Garde page
Garde pageGarde page
Garde page
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
 
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...
Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsph...
 

Plus de IbtissemSlimeni

Convertir :cinquième étape de la méthode des 6C dans la stratégie digitale
Convertir :cinquième  étape de la  méthode  des  6C dans la stratégie digitaleConvertir :cinquième  étape de la  méthode  des  6C dans la stratégie digitale
Convertir :cinquième étape de la méthode des 6C dans la stratégie digitaleIbtissemSlimeni
 
Cas kleinelec dans le cadre : Knowledge Management
Cas kleinelec  dans le cadre : Knowledge Management Cas kleinelec  dans le cadre : Knowledge Management
Cas kleinelec dans le cadre : Knowledge Management IbtissemSlimeni
 
Mise en place d'un dispositif de veille dans le cadre PACKTEK
Mise en place d'un dispositif de veille dans le cadre PACKTEKMise en place d'un dispositif de veille dans le cadre PACKTEK
Mise en place d'un dispositif de veille dans le cadre PACKTEKIbtissemSlimeni
 
Mise en place d 'une structure d'IE bonnes pratiques_points de vigilance
Mise en place d 'une structure  d'IE  bonnes pratiques_points de vigilanceMise en place d 'une structure  d'IE  bonnes pratiques_points de vigilance
Mise en place d 'une structure d'IE bonnes pratiques_points de vigilanceIbtissemSlimeni
 
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattention
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattentionUne des-fonctions-primordiales-du-leadership-est-de-diriger-lattention
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattentionIbtissemSlimeni
 
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...IbtissemSlimeni
 
LinkedIn et E-recrutement
LinkedIn et E-recrutementLinkedIn et E-recrutement
LinkedIn et E-recrutementIbtissemSlimeni
 

Plus de IbtissemSlimeni (13)

Convertir :cinquième étape de la méthode des 6C dans la stratégie digitale
Convertir :cinquième  étape de la  méthode  des  6C dans la stratégie digitaleConvertir :cinquième  étape de la  méthode  des  6C dans la stratégie digitale
Convertir :cinquième étape de la méthode des 6C dans la stratégie digitale
 
outils de veille
 outils de veille outils de veille
outils de veille
 
Cas kleinelec dans le cadre : Knowledge Management
Cas kleinelec  dans le cadre : Knowledge Management Cas kleinelec  dans le cadre : Knowledge Management
Cas kleinelec dans le cadre : Knowledge Management
 
Synergie KM_BI_IE
Synergie KM_BI_IESynergie KM_BI_IE
Synergie KM_BI_IE
 
Mise en place d'un dispositif de veille dans le cadre PACKTEK
Mise en place d'un dispositif de veille dans le cadre PACKTEKMise en place d'un dispositif de veille dans le cadre PACKTEK
Mise en place d'un dispositif de veille dans le cadre PACKTEK
 
Money & Banking
Money & Banking Money & Banking
Money & Banking
 
Mise en place d 'une structure d'IE bonnes pratiques_points de vigilance
Mise en place d 'une structure  d'IE  bonnes pratiques_points de vigilanceMise en place d 'une structure  d'IE  bonnes pratiques_points de vigilance
Mise en place d 'une structure d'IE bonnes pratiques_points de vigilance
 
entreprise Unimed
entreprise Unimed entreprise Unimed
entreprise Unimed
 
Langage corporel
Langage corporelLangage corporel
Langage corporel
 
Workplace offices
Workplace officesWorkplace offices
Workplace offices
 
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattention
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattentionUne des-fonctions-primordiales-du-leadership-est-de-diriger-lattention
Une des-fonctions-primordiales-du-leadership-est-de-diriger-lattention
 
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...
La situation-de-la-veille-informationnelle-dans-les-organisations - gouvernem...
 
LinkedIn et E-recrutement
LinkedIn et E-recrutementLinkedIn et E-recrutement
LinkedIn et E-recrutement
 

Rapport PFE

  • 1. Code: 422 Année Universitaire: 2016-2017 Université de la Manouba École Supérieure d’Économie Numérique Rapport De projet de fin d'études Sujet : Conception et développement d’une application e-santé à intégrer dans OpenMRS Élaboré par: Soumaya Nebli Ibtissem Slimeni Organisme d'accueil ATH CONSULTING Encadré par : ESEN Mme ISMAHEN CHAHBI Société M. IZHAR MAHJOUB Présenté en vue de l'obtention du diplôme de Licence Appliquée en Commerce Electronique Code: 422 Année Universitaire: 2016-2017 Université de la Manouba École Supérieure d’Économie Numérique Rapport De projet de fin d'études Sujet : Conception et développement d’une application e-santé à intégrer dans OpenMRS Élaboré par: Soumaya Nebli Ibtissem Slimeni Organisme d'accueil ATH CONSULTING Encadré par : ESEN Mme ISMAHEN CHAHBI Société M. IZHAR MAHJOUB Présenté en vue de l'obtention du diplôme de Licence Appliquée en Commerce Electronique Code: 422 Année Universitaire: 2016-2017 Université de la Manouba École Supérieure d’Économie Numérique Rapport De projet de fin d'études Sujet : Conception et développement d’une application e-santé à intégrer dans OpenMRS Élaboré par: Soumaya Nebli Ibtissem Slimeni Organisme d'accueil ATH CONSULTING Encadré par : ESEN Mme ISMAHEN CHAHBI Société M. IZHAR MAHJOUB Présenté en vue de l'obtention du diplôme de Licence Appliquée en Commerce Electronique
  • 2. Dédicace À MES CHERS PARENTS (Mamia & Rachid) Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma considération pour les sacrifices que vous avez consentis pour mon instruction et mon bien-être. Je vous remercie pour tout le soutien et l’amour que vous me portez depuis mon enfance et j’espère que votre bénédiction m’accompagne toujours. Que ce modeste travail soit l’exaucement de vos vœux tant formulés, le fruit de vos innombrables sacrifices, bien que je ne vous en acquitterai jamais assez. Puisse Dieu, le Très Haut, vous accorder santé, bonheur et longue vie et faire en sorte que jamais je ne vous déçoive. A ma chère sœur Olfa Ma chère sœur présente dans tous mes moments d’examens par son soutien moral et ses belles surprises sucrées. Je te souhaite un avenir plein de joie, de bonheur, de réussite et de sérénité. Je t’exprime à travers ce travail mes sentiments de fraternité et d’amour. A mon cher frère Ala Aucun mot ne pourrait exprimer l’attachement, l’amour et la tendresse que j’éprouve pour vous. Je prie le Bon Dieu de me donner la force et les moyens de toujours prendre soin de vous. Enfin, une dédicace spéciale à une Personne spéciale qui se reconnaitra Soumaya Nebli
  • 3. Dédicace A ma très chère mère Rbeh Affable, honorable, aimable : Tu représentes pour moi le symbole de la bonté par excellence, la source de tendresse et l’exemple du dévouement qui n’a pas cessé de m’encourager et de prier pour moi. A mon très cher père Noureddine Mon père qui a toujours me soutenir, me conseiller, m’assister et m’indique le bon chemin. L’amour qui il me voue est irremplaçable …. Ses sacrifices pour mon éducation et mes études sont énormes, je lui dois beaucoup et je lui suis que reconnaissante. A mon très cher frère Achref, son épouse Yassmine Et leur petit garçon Amen Allah Mon cher frère qui m’est le père et la mère, les mots ne suffisent guère pour exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mon ange gardien et mon fidèle compagnon dans les moments les plus délicats de cette vie mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. A ma très chère soeur Yossra En témoignage de l’attachement, de l’amour et de l’affection que je porte pour toi. Tu es toujours dans mon cœur. Je te remercie pour ton hospitalité sans égal et ton affection si sincère. Je te dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. Ibtissem Slimeni
  • 4. Remerciements Avant d’entamer ce rapport, nous profitons de l’occasion pour exprimer nos vifs remerciements à toute personne ayant contribué, de près ou de loin, à l’accomplissement de ce travail. Le Seigneur Dieu tout puissant, pour m’avoir accordé vie, santé et paix de l’esprit sans quoi je n’aurai pu achever nous projet de fin d'étude Nous souhaitons remercier notre encadrant Mme Ismahen chahbi, qui n’a pas cessé de nous encourager pendant la réalisation de ce travail de fin d’études ainsi pour sa générosité en matière de formation et d’encadrement. M. Izhar Mahjoub, Mohamed kTARi pour nous avoir offert l’opportunité d’effectuer ce stage, ainsi pour leurs suivis et encouragements, leurs entières disponibilités à nous fournir leur confiance et leur assistance la plus attentionnée. Nous tenons à remercier vers nos familles et nos amis de nous avoir soutenus et encouragés tout au long de notre projet. Finalement nous remercions tous les enseignants de l’École Supérieur d’Économie Numérique pour nos trois années de licence. Soumaya Nebli & Ibtissem Slimeni
  • 5. Table des matières Introduction générale ....................................................................................................... 1 Chapitre I : Étude de projet............................................................................................... 2 Introduction ............................................................................................................................. 2 I. Cadre du projet...................................................................................................................................... 2 1. Description du contexte de projet : .................................................................................................. 3 II. L’état de l’art ......................................................................................................................................... 4 1. OpenMRS .......................................................................................................................................... 4 2. Critique.............................................................................................................................................. 5 III. Méthode de modélisation et de conception ......................................................................................... 5 1. Méthode agile ................................................................................................................................... 5 2. SCRUM............................................................................................................................................... 6 IV. Langage de modélisation UML (Unified Modeling Language)............................................................... 9 Conclusion................................................................................................................................ 9 Chapitre II : Planification et Architecture..........................................................................10 Introduction ........................................................................................................................... 10 I. Capture des besoins : .......................................................................................................................... 10 1. Identification des acteurs................................................................................................................ 10 2. Analyse des besoins fonctionnels.................................................................................................... 10 3. Analyse des besoins non fonctionnels ............................................................................................ 11 II. Structure et découpage du projet ............................................................................................................ 11 1. Identification de l’équipe SCRUM ................................................................................................... 11 2. Le backlog du produit...................................................................................................................... 11 3. Planification des releases................................................................................................................ 12 4. Diagramme du cas d’utilisation global ............................................................................................ 13 Conclusion.............................................................................................................................. 13 Chapitre III : Sprint 1 : Gestion de personnel .....................................................................14 Introduction ........................................................................................................................... 14 I. Spécification des besoins..................................................................................................................... 14 1. Le sprint backlog ............................................................................................................................. 14 II. Diagramme des cas d’utilisation du premier Sprint ............................................................................ 16 1. Classification des cas d’utilisation par acteur ................................................................................. 16 2. Diagramme du cas d’utilisation du premier sprint.......................................................................... 16 III. Analyse des cas d’utilisation................................................................................................................ 17 1. Analyse du cas « s’authentifier »..................................................................................................... 17 2. Analyse du cas « gérer les utilisateurs».......................................................................................... 18 3. Analyse du cas «gérer rendez-vous»................................................................................................... 20 4. Analyse du cas «gérer fiche patient» .................................................................................................. 23 IV. Conception des cas d’utilisation.......................................................................................................... 27 1. Modèle d’analyse du cas d’utilisation «s’authentifier»................................................................. 27 2. Modèle d’analyse du cas d’utilisation « générer le site»..................................................................... 29 3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous»........................................................... 32
  • 6. 4. Modèle d’analyse du cas d’utilisation «gérer fiche patient» .............................................................. 37 5. Diagramme de Classe globale du premier sprint ................................................................................. 41 V. Codage...................................................................................................................................................... 42 VI. Test.......................................................................................................................................................... 43 Conclusion.............................................................................................................................. 44 Chapitre IV : Sprint 2 : Gérer la consultation et l’ordonnance ...........................................45 Introduction ........................................................................................................................... 45 I. Spécification des besoins..................................................................................................................... 45 1. Le sprint backlog ............................................................................................................................. 45 II. Diagramme du cas d’utilisation du deuxième sprint ............................................................................... 46 1. Répartition des cas d’utilisation par acteur .................................................................................... 47 III. Analyse des cas d'utilisation.................................................................................................................... 48 1. analyse des cas d'utilisation «gérer la consultation»........................................................................... 48 2. Analyse du cas d’utilisation «gérer antécédent»:............................................................................... 51 3. Analyse du cas d’utilisation «gérer examen»....................................................................................... 55 4. analyse des cas d'utilisation «gérer données anthropométriques» .................................................... 58 5. analyse des cas d'utilisation «gérer ordonnance»............................................................................... 62 IV. Conception de cas d'utilisation ............................................................................................................... 65 1. Modèle d’analyse du cas d’utilisation «gérer la consultation»........................................................... 65 2. Diagramme de classe globale de deuxième sprint.............................................................................. 88 V. Codage...................................................................................................................................................... 89 VI. Test.......................................................................................................................................................... 90 Conclusion.............................................................................................................................. 92 Chapitre V : Sprint 3: Gérer le dossier médical .................................................................93 Introduction ........................................................................................................................... 93 I. Spécification des besoins........................................................................................................................... 93 1. Sprint Backlog ...................................................................................................................................... 93 II. Diagramme des cas d’utilisation du troisième Sprint............................................................................... 94 1. Classification des cas d’utilisation par acteur ...................................................................................... 94 2. Diagramme de cas d’utilisation du Troisième sprint............................................................................ 94 III. Analyse des cas d’utilisation.................................................................................................................... 95 1. Analyse des cas d’utilisation «gérer le dossier médical» ..................................................................... 95 IV. Conception du cas d'utilisation ............................................................................................................... 97 1. Modèle d’analyse du cas d’utilisation «consulter dossier médical» .............................................. 97 2. Modèle d’analyse du cas d’utilisation du cas «imprimer dossier médical»......................................... 98 3. Diagramme de classe global du troisième sprint ............................................................................... 100 V. Codage.................................................................................................................................................... 101 VI. Test........................................................................................................................................................ 101 Conclusion.............................................................................................................................101 Chapitre VI : phase de clôture ........................................................................................102 Introduction ..........................................................................................................................102 I. Environnement de développement................................................................................................... 102 1. Environnement matériel ............................................................................................................... 102 2. Environnement logiciel.................................................................................................................. 102
  • 7. 3. Technologies et Langage de programmation utilisée ................................................................... 103 II. Style architectural.............................................................................................................................. 104 III. Elaboration du diagramme de déploiement...................................................................................... 105 1. Diagramme de déploiement .............................................................................................................. 106 2. Diagramme de Gantt.......................................................................................................................... 106 Conclusion.............................................................................................................................106 Conclusion générale......................................................................................................107 Bibliographie.................................................................................................................108 Neto graphie .................................................................................................................108
  • 8. Liste des figures Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting...................................... 3 Figure2 : Scrum en rugby........................................................................................................... 6 Figure3: Le processus SCRUM ........................................................................................................................ 7 Figure 4: exemple de plan de release........................................................................................................... 13 Figure 5 : diagramme du cas d’utilisation global.......................................................................................... 13 Figure 6 : diagramme du cas d’utilisation du premier sprint ....................................................................... 16 Figure 7 : Diagramme de séquence système du cas « S’authentifier »........................................................ 17 Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur »................................................. 18 Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»............................................... 19 Figure10 : Diagramme de séquence système du cas « supprimer utilisateur» ........................... 20 Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous ».............................................................. 20 Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous » ...................................... 21 Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous » ................................... 22 Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous » ................................... 23 Figure 15 : diagramme du cas d’utilisation « gérer patient ».................................................... 24 Figure16 : Diagramme de séquence système du cas « ajouter patient ».................................................... 25 Figure 18 : Diagramme de séquence système du cas « supprimer patient ».............................................. 27 Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier »......................................................... 28 Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter utilisateur du cas « ajouter utilisateur »........................................................................................................................ 29 Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur» ................................................... 29 Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur » .............................................. 30 Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « modifier utilisateur » .................................................................................................................................................. 30 Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur» .............................................. 30 Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du cas « supprimer utilisateur » .................................................................................................................................................. 31 Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur ».......................................... 32 Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter rendez- vous » ........................................................................................................................................................... 32 Figure 32 : Modèle de classe d’analyse d’utilisation «ajouter rendez-vous ».............................................. 33 Figure 33: Diagramme de séquence détaillé du cas d’utilisation « ajouter rendez-vous»......................... 33 Figure34 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation« modifier rendez-vous »..................................................................................... 34 Figure 35 : Modèle d’analyse d’utilisation « modifier rendez-vous »......................................... 34 Figure 37 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation« supprimer rendez-vous »............................................................................................................................. 35 Figure 38 : Modèle de classe d’analyse d’utilisation « supprimer rendez-vous »........................................ 36 Figure 40 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation : « ajouter patient »........................................................................................................................................ 37 Figure 41 : Modèle de classe d’analyse d’utilisation « ajouter patient»...................................................... 37 Figure 43: Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation « modifier patient »...................................................................................................................................... 38 Figure 44 : Modèle de classe d’analyse d’utilisation « modifier patient ».................................................. 39
  • 9. Figure 45 : Diagramme de séquence détaillé du cas « modifier patient ».................................................. 39 Figure 46 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer patient ».................................................................................................................................. 40 Figure 47 : Modèle de classe d’analyse d’utilisation « supprimer patient » ............................................... 40 Figure 48 : Diagramme de séquence détaillé du cas « supprimer patient » ............................................... 41 Figure 49 : diagramme de classe globale du premier sprint ...................................................... 41 Figure 50 : page d’authentification .............................................................................................................. 43 Figure 51 : page de la fiche patient .............................................................................................................. 43 Figure 52: page de rendez-vous .................................................................................................................. 44 Figure 53: Diagramme du cas d’utilisation global du deuxième sprint ....................................................... 47 Figure 54: cas d’utilisation du cas « gérer la consultation »......................................................................... 48 Figure 56 : Diagramme de séquence système du cas « ajouter diagnostics » ............................................. 49 Figure 57 : Diagramme de séquence système du cas « modifier diagnostics » ........................................... 50 Figure 58 : Diagramme de séquence système du cas « supprimer diagnostics » ....................................... 51 Figure 59 : cas d’utilisation du cas « gérer antécédent».............................................................................. 51 Figure 60: Diagramme de séquence système du cas « ajouter antécédent ».............................................. 52 Figure 61: Diagramme de séquence système du cas « modifier antécédent »............................................ 53 Figure 62: Diagramme de séquence système du cas « supprimer antécédents » ....................................... 54 Figure 63: Diagramme du cas d’utilisation « gérer examen »...................................................................... 55 Figure 64 : Diagramme de séquence système du cas « ajouter examen » .................................................. 56 Figure 65: Diagramme de séquence système du cas « modifier examen » ................................................. 57 Figure 66: Diagramme de séquence système du cas «supprimer examen » ............................................... 58 Figure 67 : diagramme du cas d’utilisation «gérer données anthropométriques ».................................... 58 Figure 68: Diagramme de séquence système du cas «ajouter données anthropométriques»................... 59 Figure 69: Diagramme de séquence système du cas «modifier données anthropométriques»................. 60 Figure 70: Diagramme de séquence système du cas «supprimer données anthropométriques»............. 61 Figure 72 : Diagramme de séquence système du cas « ajouter ordonnance »............................................ 63 Figure 73 : Diagramme de séquence système du cas « consulter l’ordonnance »...................................... 64 Figure 74 : Diagramme de séquence système du cas « supprimer l’ordonnance ».................................... 65 Figure 75 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation «ajouter diagnostic ».................................................................................................................................... 65 Figure 76: Modèle de classe d’analyse d’utilisation «ajouter diagnostic » ................................................. 66 Figure 77 : Diagramme de séquence détaillée du cas «ajouter diagnostic » ............................................... 66 Figure 78: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « modifier diagnostic».................................................................................................................................. 67 Figure 79 : Modèle de classe d’analyse d’utilisation « modifier diagnostic» .............................................. 67 Figure 80: Diagramme de séquence détaillée du cas d’utilisation « modifier diagnostic» ......................... 68 Figure 81: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer diagnostic »............................................................................................................................. 68 Figure 82 : Modèle de classe d’analyse d’utilisation « supprimer diagnostic» ........................................... 69 Figure83 : Diagramme de séquence détaillée du cas d’utilisation « supprimer diagnostic » ..................... 69 Figure 84: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « ajouter antécédent».................................................................................................................................. 70 Figure85 : Modèle de classe d’analyse d’utilisation « ajouter antécédent » .............................................. 70 Figure 86 : Diagramme de séquence détaillée du cas « ajouter antécédent » ............................................ 71 Figure87 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation «modifier antécédent»................................................................................................................................. 71 Figure88 : Modèle de classe d’analyse d’utilisation « modifier antécédent » ............................................ 72 Figure 89 : Diagramme de séquence détaillée du cas « modifier antécédent » .......................................... 72
  • 10. Figure 90 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer antécédent»............................................................................................................................ 73 Figure 91 : Modèle de classe d’analyse d’utilisation «supprimer antécédent » ......................................... 73 Figure 92 : Diagramme de séquence détaillée du cas « supprimer antécédent » ...................................... 74 Figure 93 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « ajouter examen » ...................................................................................................................................... 74 Figure 94 : Modèle de classe d’analyse d’utilisation « ajouter examen »................................................... 75 Figure 95 : Diagramme de séquence détaillée de cas « ajouter examen ».................................................. 75 Figure 96 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « modifier examen » .................................................................................................................................... 76 Figure 97 : Modèle de classe d’analyse d’utilisation « modifier examen »................................................. 76 Figure 98 : Diagramme de séquence détaillée de cas « modifier examen »............................................... 77 Figure 99 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer examen ».................................................................................................................................. 77 Figure 100 : Modèle de classe d’analyse d’utilisation « supprimer examen »............................................ 78 Figure 101 : Diagramme de séquence détaillée de cas « supprimer examen ».......................................... 78 Figure102 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation «ajouter données anthropométriques»....................................................................................................... 79 Figure 103 : Modèle de classe d’analyse d’utilisation «ajouter données anthropométriques » ................ 79 Figure 104 : Diagramme de séquence détaillée de cas «ajouter données anthropométriques » ............... 80 Figure105 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation «modifier données anthropométriques».................................................................................................... 80 Figure 106: Modèle de classe d’analyse d’utilisation «modifier données anthropométriques » ............... 81 Figure107 : Diagramme de séquence détaillée de cas « modifier données anthropométriques» ............. 81 Figure 108: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation «supprimer données anthropométriques» ................................................................................................. 82 Figure109 : Modèle de classe d’analyse d’utilisation «supprimer données anthropométriques » ............ 82 Figure 110 : Diagramme de séquence détaillée de cas « supprimer données anthropométriques» .......... 83 Figure 111 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « ajouter ordonnance»................................................................................................................................. 83 Figure 112 : Modèle de classe d’analyse d’utilisation « ajouter ordonnance » .......................................... 84 Figure 113: Diagramme de séquence détaillée du cas « ajouter ordonnance »......................................... 84 Figure 114 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « consulter ordonnance» ............................................................................................................................ 85 Figure 115 : Modèle de classe d’analyse d’utilisation « consulter ordonnance »....................................... 85 Figure 116 : Diagramme de séquence détaillée du cas «consulter ordonnance »....................................... 86 Figure 117: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « supprimer ordonnance»........................................................................................................................... 86 Figure 118 : Modèle de classe d’analyse d’utilisation « supprimer ordonnance » ..................................... 87 Figure 119: Diagramme de séquence détaillée du cas «supprimer ordonnance » ..................................... 87 Figure 120 : Diagramme de classe globale de deuxième sprint ................................................................... 88 Figure 121: page de consultation ............................................................................................................... 90 Figure 122 : page d’ordonnance.................................................................................................................. 91 Figure 123: page diagnostic......................................................................................................................... 91 Figure 124: page d’examen .......................................................................................................................... 92 Figure 125: Diagramme du cas d’utilisation du troisième sprint ................................................................. 94 Figure 126 : Diagramme de séquence système du cas « consulter dossier médical »................................ 95 Figure 127 : Diagramme de séquence système du cas «imprimer dossier médical»................................... 96 Figure 128 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « consulter dossier médical»........................................................................................................................ 97
  • 11. Figure 129 : Modèle de classe d’analyse d’utilisation « consulter dossier médical» .................................. 97 Figure 130 : diagramme de séquence détaillée du cas «consulter dossier médical» .................................. 98 Figure 131 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « imprimer dossier médical »...................................................................................................................... 98 Figure 132 : Modèle de classe d’analyse d’utilisation «imprimer dossier médical» ................................... 99 Figure 133: Diagramme de séquence détaillée du cas «imprimer dossier médical»................................... 99 Figure 134: diagramme de classe global du troisième sprint..................................................................... 100 Figure 135: page dossier médical............................................................................................................... 101 Figure 136: niveau de l’architecture........................................................................................................... 105 Figure 137 : Diagramme de déploiement................................................................................................... 106 Figure 138: Diagramme de Gantt............................................................................................................... 106
  • 12. Liste des tableaux Tableau 1: tableau de backlog initial................................................................................12 Tableau 2: Backlog du premier sprint ...............................................................................15 Tableau 3: classification des cas d'utilisation par acteur ...................................................16 Tableau 4: description textuelle du cas «S’authentifier»...................................................17 Tableau 5: description textuelle du cas «ajouter utilisateur» ............................................18 Tableau 6 : Description textuelle du cas « modifier utilisateur».......................................19 Tableau 8: description textuelle du cas « ajouter un rendez-vous »..................................21 Tableau 9 : Description textuelle du cas « modifier un rendez-vous » .............................22 Tableau 10 : Description textuelle du cas « supprimer un rendez-vous » ...........................23 Tableau 11 : Description textuelle du cas « ajouter patient » .........................................24 Tableau 12 : Description textuelle du cas « modifier patient » .........................................25 Tableau 13 : Description textuelle du cas « supprimer patient »........................................26 Tableau 14: table «app user»...........................................................................................42 Tableau 15: table «user profil» ........................................................................................42 Tableau 16 : table «rendez-vous».....................................................................................42 Tableau 17: table «patient » ...........................................................................................42 Tableau 18 : Backlog du deuxième Sprint .........................................................................46 Tableau 19: tableau de répartition du deuxième sprint.....................................................47 Tableau 20 : Description textuelle du cas « ajouter diagnostics »......................................48 Tableau 21 : Description textuelle du cas « modifier diagnostics »....................................49 Tableau 22 : Description textuelle du cas « supprimer diagnostics » .................................50 Tableau 23 : Description textuelle du cas « ajouter antécédent »......................................52 Tableau 24 : Description textuelle du cas « modifier antécédents »...................................53 Tableau 25 : Description textuelle du cas « supprimer antécédent » ................................54 Tableau 26 : Description textuelle du cas « ajouter examen »...........................................55 Tableau 27 : Description textuelle du cas « modifier examen»..........................................56 Tableau 28 : Description textuelle du cas « supprimer examen » ......................................57 Tableau 29 : Description textuelle du cas « ajouter données anthropométriques» ............59
  • 13. Tableau 30 : Description textuelle du cas « modifier données anthropométriques»...........60 Tableau 31 : Description textuelle du cas « supprimer données anthropométriques»........61 Tableau 32 : Description textuelle du cas « ajouter ordonnance ».....................................62 Tableau 33 : Description textuelle du cas « consulter ordonnance » ................................63 Tableau 34 : Description textuelle du cas « supprimer ordonnance »..............................64 Tableau 35 : table « consultation » ..................................................................................89 Tableau 36: table « ordonnance » ...................................................................................89 Tableau 37: table « diagnostic » ......................................................................................89 Tableau 38 : table « antécédent » ....................................................................................89 Tableau 39: table « examen » .........................................................................................90 Tableau 40 : Backlog du troisième sprint..........................................................................93 Tableau 41: Classification des cas d’utilisation par acteur.................................................94 Tableau 42: Description textuelle du cas « consulter dossier médical » ............................95 Tableau 43 : Description textuelle du cas «imprimer dossier médical » .............................96 Tableau 44 : table « dossier médical »............................................................................101
  • 14. 1 Introduction générale Les technologies de l’information participent aujourd’hui à l’amélioration de la qualité des soins. En jouant d’une manière positive sur la tenue des dossiers médicaux, en facilitant l’échange et le partage des données utiles à la décision médicale, tout en augmentant la disponibilité et la rapidité d’accès à ces informations. L’E-santé apparaît de plus en plus comme la solution à mettre en place pour pallier les difficultés de notre système de soins qui est confronté aujourd’hui à plusieurs défis majeurs tels que l’amélioration de suivi des patients et la confidentialité des données personnelles. Dans ce cadre naît notre projet de fin d’étude effectuée au sein de la boîte de développement ATH Consulting qui consiste à développer une application destinée à un médecin cardiologue que nous envisageons intégrer dans l’outil OpenMRS. En effet, cette application permet d’automatiser le protocole de soin des patients. Le présent rapport est organisé en quatre chapitres : -Dans le premier chapitre intitulé « Étude de projet », nous allons décrire le cadre général de notre travail tout en présentant l’organisme d’accueil, l’étude de l’existant, l’outil OpenMRS et la méthode de conception utilisée. -Dans le deuxième chapitre intitulé « Planification et Architecture», nous allons présenter les acteurs, les besoins fonctionnels et les besoins non fonctionnels de notre application. -Le troisième chapitre intitulé « la gestion du personnel », le quatrième chapitre intitulé «gérer la consultation et l’ordonnance» et le cinquième chapitre intitulé « gérer le dossier médical » représente le corps de notre projet. En effet, ces trois chapitres seront appliqués pour le développement de trois sprints du notre système tout en respectant les principes fondamentaux de Scrum. - Le dernier chapitre constitue « la phase de clôture » de notre travail. Il décrit les outils utilisés pour la conception, et le développement de notre application. Nous finissons par une conclusion générale, dans laquelle nous résumons notre travail, et nous présentons l’apport de ce projet de fin d’études ainsi que les perspectives de notre application.
  • 15. 2 Chapitre I : Étude de projet Introduction : Dans ce chapitre, nous allons commencer par décrire le cadre de notre projet. Ensuite, nous allons présenter la société au sein de laquelle nous avons effectué notre projet de fin d’études. Enfin, nous allons décrire la méthode de gestion de projet SCRUM. I. Cadre du projet : Notre projet de fin d’études s’inscrit dans le cadre de l’obtention du diplôme de licence appliquée en Commerce Électronique de l’École Supérieure d’Économie Numérique (ESEN). Ainsi, nous avons développé une application qui permet de faciliter le processus de soins.  Présentation d’organisme d’accueil : Notre stage de fin d’études a été effectué au sein de la boîte de développement (ATH Consulting) que nous allons décrire dans la suite. Historique :  HIMSS (Healthcare Information and Management Systems Society) est une organisation à but non lucratif dont le but est de promouvoir la meilleure utilisation des technologies de l’information et des systèmes de gestion dans l’industrie des soins de santé créent en 1961.  64000 particuliers, 640 membres corporatifs (fournisseurs du soin de santé, étudiants, fournisseurs de TIC, consultants et autres intervenants de l’industrie des TIC en santé).  450 organisations à but non lucratif.  5327 organisations de santé analysées annuellement dans le monde (2011).  Europe : 15000 visiteurs par mois sur les sites européens du HIMSS.  Autrement dit que HIMSS est une solution informatique de santé, systèmes de santé électriques d’enregistrement EMR-EHR.
  • 16. 3 Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting  ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des systèmes d’information de santé.  ATH Consulting est le premier membre africain du « Certified Consultant Program du HIMSS ». Services :  Audit et analyse des systèmes d’information de santé.  Définition des stratégies et organisation des systèmes d’information.  Rédaction des schémas directeurs et cahiers des charges.  Étude de faisabilité financière.  Réalisation d’études du marché et recherche des solutions. 1. Description du contexte de projet : a. Etude de l’existant : Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin de dégager les problèmes du système existant et proposer une solution. o Les traitements des dossiers médicaux de patient sont manuels. o Absence d’échange entre les médecins de dossiers médicaux numériques des patients. o Chaque médecin a son propre protocole de soin. o Absence de confidentialité médicale. 3 Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting  ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des systèmes d’information de santé.  ATH Consulting est le premier membre africain du « Certified Consultant Program du HIMSS ». Services :  Audit et analyse des systèmes d’information de santé.  Définition des stratégies et organisation des systèmes d’information.  Rédaction des schémas directeurs et cahiers des charges.  Étude de faisabilité financière.  Réalisation d’études du marché et recherche des solutions. 1. Description du contexte de projet : a. Etude de l’existant : Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin de dégager les problèmes du système existant et proposer une solution. o Les traitements des dossiers médicaux de patient sont manuels. o Absence d’échange entre les médecins de dossiers médicaux numériques des patients. o Chaque médecin a son propre protocole de soin. o Absence de confidentialité médicale. 3 Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting  ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des systèmes d’information de santé.  ATH Consulting est le premier membre africain du « Certified Consultant Program du HIMSS ». Services :  Audit et analyse des systèmes d’information de santé.  Définition des stratégies et organisation des systèmes d’information.  Rédaction des schémas directeurs et cahiers des charges.  Étude de faisabilité financière.  Réalisation d’études du marché et recherche des solutions. 1. Description du contexte de projet : a. Etude de l’existant : Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin de dégager les problèmes du système existant et proposer une solution. o Les traitements des dossiers médicaux de patient sont manuels. o Absence d’échange entre les médecins de dossiers médicaux numériques des patients. o Chaque médecin a son propre protocole de soin. o Absence de confidentialité médicale.
  • 17. 4 b. Critique de l’existant: Durant la phase de l’étude de l’existant, nous avons détecté les anomalies suivantes : o Absence d’un moyen de recherche rapide pour chercher une fiche, la secrétaire doit faire une recherche manuelle fiche par fiche par nom de patient ce qui entraîne une perte de temps. o La gestion du rendez-vous se fait d’une manière manuelle ce qui provoque le risque d’oublier ou de chevauchement des rendez-vous. o Probabilité de perte de documentation. o Pas de possibilité du partage des dossiers médicaux entre médecins. c. Solution proposée : o Pour palier aux problèmes cités ci-dessous, nous allons proposer un outil qui permettra d’automatiser le processus de soins. ATH Consulting nous a proposé comme sujet de projet de fin d’études de développer une plate-forme destinée à un médecin cardiologue que nous envisageons intégrer dans l’outil l’OpenMRS. L’outil développé permettra de standardiser les traitements médicaux et le partage électronique des données de santé. En outre, il permettra aussi d’assurer la confidentialité des données personnelles. II. L’état de l’art : 1. OpenMRS : Le système de gestion de dossier médical (OpenMRS) a été introduit en 2004 en tant que plate-forme de système de gestion dossier médical open source destiné aux pays en développement. OpenMRS est soutenu par des équipes centrales de partenaires in Health, Regenstrief Institue. [1] Mission : La mission d’OpenMRS est d’améliorer la prestation des soins de santé dans des environnements aux ressources limitées en coordonnant une communauté mondiale qui crée une robuste, évolutive, axée l’utilisateur, open source plate-forme de système de dossier médical. [2] Il existe d’autres outils similaires à OpenMRS dont on peut citer CliniSys : CliniSys constitue un ensemble de solutions de gestion administrative et médicale qui couvrent les différentes activités des établissements de santé, conçu avec une équipe d’informaticiens et de professionnels de santé, et offre un haut degré d’adaptation selon la
  • 18. 5 spécialité et l’organisation de chaque établissement. CliniSys est installée actuellement dans la majorité des polycliniques en Tunisie. [3] 2. Critique : CliniSys est un logiciel médical utilisé dans la majorité de polycliniques. Il permet d’échanger des informations de santé et des dossiers médicaux à l’intérieur de polyclinique mais le problème est qu’on ne peut pas échanger l’information de santé ni le dossier médical à l’extérieure d’une clinique. Ce problème est résolu par le logiciel nommé l’OpenMRS. III. Méthode de modélisation et de conception : 1. Méthode agile : « Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion des projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du projet. » [4] Les quatre utilités fondamentales agiles : • L’interaction entre acteurs plutôt que les processus et les outils. • Un produit opérationnel plutôt qu’une documentation pléthorique. • La collaboration avec le client plutôt que la négociation du contrat. • La réactivité face au changement plutôt que le suivi d'un plan. [5] Les 12 principes de méthodes agiles : 1- Satisfaire le client en livrant tôt et régulièrement des logiciels utiles qui offrent une véritable valeur ajoutée 2-Accepter le changement même tard dans le développement 3-Livrer fréquemment une application qui fonctionne 4-Collaborer quotidiennement entre clients et développeurs 5- Bâtir le projet autour des personnes motivées en leur fournissant environnement et support et en leur faisant confiance
  • 19. 6 6-Communiquer par des conversations en face à face 7-Mesurer la progression avec le logiciel qui fonctionne 8-Garder un rythme de travail durable 9-Rechercher l’excellence technique et la qualité de la conception 10-Laisser l’équipe s’auto-organiser 11-Rechercher la simplicité 12-A intervalles réguliers, réfléchir aux moyens de devenir plus efficaces. [5] Les principales méthodes agiles : Nous différencions surtout :  SCRUM  Extreme Programming (XP)  Adaptive Software Development (ASD)  Crystal Clear Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases, nous avons opté SCRUM comme une méthodologie de conception et du développement. 2. SCRUM : Le SCRUM est une méthode de gestion de projet .Elle a pour but d’améliorer la productivité des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une mêlée. C’est une technique de reprise du jeu après faute qui permet une équipe sur des bons rails par un effort collectif. Cette méthode a été principalement conçue pour le développement des logiciels informatiques. [6] Figure2 : Scrum en rugby
  • 20. 7 Pourquoi SCRUM : La méthodologie SCRUM est le moyen parfait de communication entre les différents membres du projet pour constater le progrès du projet, et permettre de savoir les difficultés rencontrées par les différentes parties. Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes. Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs, l'efficacité, la réduction du temps et sur la communication excellente entre les divers acteurs du projet. Le principe de base de SCRUM est :  Dégager dans un premier temps le maximum des fonctionnalités pour former le backlog du produit.  Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer lesquelles seront réalisé dans chaque itération.  Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser, dans des itérations nommées Sprints.  Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément. Figure3: Le processus SCRUM Les acteurs SCRUM :  Le Product Owner : Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe de développement. [7] Le Product Owner est la seule personne responsable de gérer Product backlog. [7] 7 Pourquoi SCRUM : La méthodologie SCRUM est le moyen parfait de communication entre les différents membres du projet pour constater le progrès du projet, et permettre de savoir les difficultés rencontrées par les différentes parties. Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes. Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs, l'efficacité, la réduction du temps et sur la communication excellente entre les divers acteurs du projet. Le principe de base de SCRUM est :  Dégager dans un premier temps le maximum des fonctionnalités pour former le backlog du produit.  Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer lesquelles seront réalisé dans chaque itération.  Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser, dans des itérations nommées Sprints.  Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément. Figure3: Le processus SCRUM Les acteurs SCRUM :  Le Product Owner : Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe de développement. [7] Le Product Owner est la seule personne responsable de gérer Product backlog. [7] 7 Pourquoi SCRUM : La méthodologie SCRUM est le moyen parfait de communication entre les différents membres du projet pour constater le progrès du projet, et permettre de savoir les difficultés rencontrées par les différentes parties. Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes. Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs, l'efficacité, la réduction du temps et sur la communication excellente entre les divers acteurs du projet. Le principe de base de SCRUM est :  Dégager dans un premier temps le maximum des fonctionnalités pour former le backlog du produit.  Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer lesquelles seront réalisé dans chaque itération.  Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser, dans des itérations nommées Sprints.  Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément. Figure3: Le processus SCRUM Les acteurs SCRUM :  Le Product Owner : Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe de développement. [7] Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
  • 21. 8  Le Scrum master : Le Scrum master est un leader au service de l’équipe SCRUM. Il aide tout le monde à changer ces interactions pour maximiser la valeur créée par l’équipe SCRUM. Le Scrum Master remplit leur rôle en s’assurant que l’équipe SCRUM adhère à la théorie aux pratiques et aux règles de Scrum. [7]  L’équipe de développement (Team) : C’est l’équipe qui participe au projet. Elle est constituée de professionnels qui livrent à chaque sprint un incrément « terminé » et potentiellement livrable du produit. Ces équipes sont structurées par l’entreprise à organiser et gérer leur propre travail. [7] Les artéfacts de Scrum : Les artéfacts de Scrum sont conçus principalement pour maximiser la transparence d’informations et des opportunités pour l’adaptation.  Le Product Backlog : (Carnet de produit) Ensemble des fonctionnalités (User Story) qui constitue le produit souhaité. Il doit être priorisé pour permettre de développer les éléments de plus haute importance en premier. [8]  Le Sprint Backlog : (Carnet d’itération) Sous-ensemble des éléments du Backlog de produit. Les éléments constituent les user stories à développer au cours du sprint et sont préalablement détaillés pour pouvoir être estimés par l’équipe de développement. Il est également priorisé.  Burndown Charts : (Graphique d’avancement) : Le Burndown Chart est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint. [9] Il possède en abscisse le temps et en ordonnée les points d’histoire. Planification d’un projet par Scrum :  Sprint Planning : (Planification d’itération) Le Sprint Planning permet de définir le Sprint Backlog. Le Sprint Backlog est un sous-ensemble du Product Backlog. Le Sprint Backlog correspond à un accord mutuel entre le product Owner et l’équipe mais c’est le Product Owner qui décidé. [10]  Daily Scrum Meeting (Mêlée quotidienne) : La Mêlée Quotidienne (Daily Scrum) est l’un des premiers d’inspection et d’adaptation dans Scrum. L’équipe de développement communique pour synchroniser ses travaux et créer un plan pour les prochaines 24 heures. [11]
  • 22. 9  Sprint Review (Revue d'itération): La revue de Sprint est un évènement qui regroupe de nombreuses parties prenantes et personnes expérimentées. Les revues de Sprint ont de nombreux résultats possibles, y compris l’arrêt du projet. Dans la plupart des cas, l’Équipe est autorisée à commencer un autre Sprint. Il me semble que les équipes matures peuvent déjà établir le but de leur prochain Sprint lors de cette Revue. Elles trouvent que cela aide à maintenir le rythme d’un Sprint à l’autre. L’objectif de la revue de sprint est le produit que l’Équipe a construit. [11]  Rétrospective de sprint : La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois. Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum Master s’assure que la réunion a eu lieu et que les participants en comprennent le but. [7] IV. Langage de modélisation UML (Unified Modeling Language) : « UNIFIED MODELING LANGUAGE » UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit d’une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage. [12] Conclusion : Au cours de ce chapitre, nous avons présenté l’organisme d’accueil « ATH Consulting ». Ensuite, nous avons établi l’étude de l’existant qui nous a permis de mieux comprendre la problématique afin de trouver la solution adéquate. Enfin, nous avons opté pour le choix de la méthode de travail utilisée SCRUM. Nous avons aussi présenté brièvement le langage de modélisation UML qui sera utilisé pour l’élaboration des différents diagrammes de conception.
  • 23. 10 Chapitre II : Planification et Architecture Introduction : Dans ce chapitre, nous allons présenter les acteurs et leurs rôles, ainsi que les besoins fonctionnels et les besoins non fonctionnels. Ensuite, nous identifierons l’équipe de SCRUM et son rôle, par la suite nous décrivons le Backlog du produit. Enfin, nous présenterons la planification des releases. I. Capture des besoins : La spécification des besoins représente la première phase du cycle de développement d’un logiciel. Elle sert à identifier les acteurs réactifs du système. 1. Identification des acteurs : « Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositifs matériels ou autre système) qui interagit directement avec le système étudié. »[12] Les acteurs de notre système sont :  La secrétaire : qui peut gérer les rendez-vous des patients et créer les fiches patients.  Le médecin : peut créer les dossiers médicaux, générer des ordonnances patients et planifier les activités faites la secrétaire.  Administrateur : qui peut ajouter ou bien modifier ou supprimer un utilisateur 2. Analyse des besoins fonctionnels :  Générer le site : l’administrateur peut accéder à une plate-forme et peut ajouter ou modifier ou éliminer un utilisateur.  Gérer les rendez-vous : o La prise du rendez-vous s’effectue directement ou via notre plate-forme en précisant la date, l’heure, le nom et le prénom du patient selon la disponibilité du médecin.  Gérer le patient : o la secrétaire remplit les informations du patient. o Les observations médicales notées par le médecin qui doivent comprendre les antécédents du patient.  Gérer consultation : c’est le médecin qui se charge de l’enregistrement des ordonnances, des différents diagnostics, des antécédents (personnels, antécédents
  • 24. 11 familiaux), les données anthropométriques, ainsi que les examens (examens physiques, examens complémentaires…).  Gérer l’ordonnance : permet au médecin d’ajouter, de consulter ou bien supprimer une ordonnance.  Gérer le dossier médical : o le dossier médical comprend l’historique des interventions médicales subis par les patients (les médicaments qui lui ont été prescrits, les résultats d’analyse, les antécédents familiaux…) 3. Analyse des besoins non fonctionnels :  Ergonomie : l’application doit offrir une interface conviviale exploitable par l’utilisateur simple dans l’utilisation.  Rapidité : le temps du chargement d’une page demandée par l’utilisateur ne doit pas prendre plus que 30 secondes.  Disponibilité : possibilité d’accès à l’application et à n’importe quelle information 24h/24h et 7j/7j sauf en période de maintenance  Sécurité et la confidentialité : l’accès à l’application doivent être sécurisé par le login et le mot de passe. II. Structure et découpage du projet : 1. Identification de l’équipe SCRUM : L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la flexibilité, la créativité et la productivité. Elle doit s’auto-organiser en choisit la meilleure façon d’accomplir le travail. Elle doit avoir toutes les compétences nécessaires au développement du produit. Scrum définit trois rôles qui sont : Le Product Owner (le propriétaire du produit : M.Izhar mahjoub): c’est la personne qui a une vision du produit à accomplir, usuellement, c’est un expert dans le domaine. Le Scrum Master (le directeur du produit : M. Mohamed Ktari): c’est la personne qui doit étayer le bon déroulement des différents sprints d’une release. Le Scrum Team (l’équipe de Scrum : Soumaya &Ibtissem) : représenté par les personnes qui sont chargées d’implémenter les besoins du client. 2. Le backlog du produit : c’est l’ensemble de fonctionnalités (User Story) du produit que l’on veut développer comme nous avons déjà présenté. Un User Story s’écrit comme suit :
  • 25. 12 - En tant que < utilisateur> - Je désire < fonctionnalité> - Pour pouvoir < résultat> Pour chaque User Story on présente le rang, l’estimation, l’importance et la description comme illustrée dans le tableau suivant : ID En tant que Je désire Pour pouvoir Importance 1 Utilisateur + administrateur S’authentifier Accéder à la plate- forme +++ 2 Administrateur Gérer les utilisateurs de la plate-forme Ajouter, modifier et supprimer un utilisateur ++++ 3 Secrétaire Gérer le rendez-vous et les patients Pour planifier la liste des rendez- vous et pouvoir ajouter, modifier et supprimer des patients +++ 4 Médecin Gérer consultation et le dossier médical Actualiser les informations existantes et ajouter le résumé de chaque consultation, ainsi que peut consulter le dossier médical +++++ Tableau 1: tableau de backlog initial 3. Planification des releases : Un release correspond à la livraison d'une version. Par habitude, on parle de release pour considérer la période du temps qui va du début du travail sur cette version jusqu'à sa livraison et qui passe par une série de sprints successifs. [12] La réunion de planification des releases est l’évènement le plus important dans Scrum. L’objectif de cette réunion est de faire le planning de travail et d’identifier le backlog des releases. Tous les projets nécessitent des plans, afin de prévoir à peu près ce que va contenir un produit ou à quelle date il sortira sur le marché. Selon la méthodologie agile Scrum, la planification de releases aux mêmes points visés puisqu’elle donne à l’équipe et aux parties prenantes des informations sur le contenu des sprints constituant la release.
  • 26. 13 Figure 4: exemple de plan de release 4. Diagramme du cas d’utilisation global : Figure 5 : diagramme du cas d’utilisation global Conclusion : Dans ce chapitre, nous avons identifié le rôle de chaque acteur en le représentant dans le diagramme du cas d’utilisation global. Nous avons aussi présenté l’équipe du projet et défini notre backlog du produit en nous basant sur les besoins fonctionnels et non fonctionnels. <<include>> <<include>> <<include>> <<include>> <<include>> sécretaire médecin administrateur gérer patient gérer rendez-vous gérer consultation gérer dossier médical gérer les utilisateurs s'authentifier
  • 27. 14 Chapitre III : Sprint 1 : Gestion de personnel Introduction : Le sprint s’exprime comme un cœur de scrum. Il s’agit d’une unité du temps durant laquelle un incrément du produit sera réalisé. Dans ce chapitre, nous allons présenter le premier sprint. I. Spécification des besoins : Au sein de ce sprint, les users stories vont appliquer les quatre étapes du cycle scrum, analyse, conception, développement et les tests. 1. Le sprint backlog : Durant le premier chapitre, le sprint backlog est présent au cours de la réunion de planification : il s’agit d’une série des tâches que l’équipe scrum doit réaliser durant le sprint dans l’objectif d’arriver à la réalisation de la tâche au bout du temps escompté afin de pouvoir enchaînée sur le sprint suivant. Le tableau suivant présent toutes les fonctionnalités qui seront développées de ce sprint : ID U.S User Story ID tâche Tâche Affectation 1 En tant qu’utilisateur et administrateur, je veux « authentifier» 1.1 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, de séquence détaillée du cas « s’authentifier » Soumaya Nebli 2 En tant qu’administrateur je veux « gérer les utilisateurs » 2.1 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée «ajouter utilisateur » Soumaya Nebli 2.2 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée «modifier utilisateur » Soumaya Nebli 2.3 Réaliser le diagramme du cas Soumaya
  • 28. 15 d’utilisation, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence, diagramme de séquence détaillée « supprimer utilisateur » Nebli 3 En tant qu’utilisateur je veux gérer « rendez-vous » 3.1 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas « ajouter un rendez-vous » Soumaya Nebli 3.2 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas «modifier un rendez-vous » Soumaya nebli 3.3 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas «supprimer un rendez-vous » Ibtissem Slimeni 4 En tant qu’utilisateur je veux « gérer la fiche du patient » 4.1 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas « ajouter fiche patient » Ibtissem Slimeni 4.2 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas « modifier fiche patient » Ibtissem Slimeni 4.3 Réaliser le diagramme du cas d’utilisation, diagramme de séquence, la traçabilité entre diagramme du cas d’utilisation et diagramme de classes d’analyse, diagramme de séquence détaillée du cas « supprimer fiche patient » Tableau 2: Backlog du premier sprint
  • 29. 16 II. Diagramme des cas d’utilisation du premier Sprint : Au début de chaque itération, nous allons schématiser la spécification fonctionnelle par un diagramme du cas d’utilisation. Celle-ci servira comme une vue d’ensemble du système et présentera les liens et les interactions entre les utilisateurs et les fonctionnalités. 1. Classification des cas d’utilisation par acteur : Ce tableau englobe les acteurs par leurs fonctionnalités : Acteur Cas d’utilisation Administrateur Secrétaire Médecin  ajouter utilisateur  modifier utilisateur  supprimer utilisateur  ajouter rendez-vous  modifier rendez-vous  supprimer rendez-vous  ajouter patient  modifier patient  supprimer patient Tableau 3: classification des cas d'utilisation par acteur 2. Diagramme du cas d’utilisation du premier sprint: L’administrateur peut accéder à la plate-forme en utilisant un login et un mot de passe pour ajouter, modifier et supprimer un utilisateur. Comme présenté dans la figure suivante: Figure 6 : diagramme du cas d’utilisation du premier sprint <<include>> adminstrateur gérer les utilisateurs ajouter user modifier user s'authentifier supprimer user
  • 30. 17 III. Analyse des cas d’utilisation : 1. Analyse du cas « s’authentifier » : 1.1. Description textuelle du cas d’utilisation « s’authentifier » : CU : s’authentifier Acteur : administrateur et utilisateur (médecin, secrétaire) Pré-condition :l’utilisateur doit être dans la base de données et possède des identifiants. Post-condition : la première interface de l’application affichée Scénario nominal : 1. L’utilisateur demande l’interface d’authentification. 2. Le système affiche l’interface demandée. 3. L’utilisateur saisit login et mot de passe. 4. Le système vérifie les informations saisies par l’utilisateur. 5. Le système affiche l’interface demandée. Scénario alternatif : 4.1. l’utilisateur n’a pas saisi le bon paramètre d’authentification 4.2. l’utilisateur n’existe pas dans la base de données Tableau 4: description textuelle du cas «S’authentifier» 1.2. Diagramme de séquence système du cas « S’authentifier » : Chaque utilisateur doit s’authentifier, en créant son login et son mot de passe et sa catégorie pour accéder à sa plate-forme. Le système affiche un message en cas d’erreur. Figure 7 : Diagramme de séquence système du cas « S’authentifier » s'authentifier saisir login et mot de passe afficher l'interface demandée demander l'interface d'authentification retour vers l'interface authentification afficher l'interface demandée vérifier utilisateur système données invalides données valides alt loop saisir login et mot de passe afficher l'interface demandée demander l'interface d'authentification retour vers l'interface authentification afficher l'interface demandée vérifier
  • 31. 18 2. Analyse du cas « gérer les utilisateurs» : Administrateur peut accéder à la plate-forme, le système affiche les listes de fonctionnalités qui permettent de l’utilisateur de choisir l’une des fonctionnalités « ajouter » ou « modifier » ou « supprimer » utilisateurs : 2.1. Description textuelle cas d’utilisation « ajouter utilisateur » : Cu Ajouter utilisateur Acteur Administrateur Pré- condition S’authentifier Post –condition Utilisateur ajouté Scénario nominal 1. L’administrateur clique sur ajouter utilisateur 2. Le système affiche le formulaire 3. L’administrateur remplit le formulaire 4. Le système vérifie 5. Le système enregistre le nouvel utilisateur 6. Le système affiche utilisateur ajouté Scénario alternatif 4.1 donnée manquante Tableau 5: description textuelle du cas «ajouter utilisateur» 2.2. Diagramme de séquence système du cas «ajouter utilisateur» : La figure 8 illustre le diagramme de séquence du premier cas dans notre sprint. L’administrateur doit s’authentifie avec son login et son mot de passe afin d’ajouter un utilisateur à sa plate-forme. Si les champs sont remplis, le système affiche un message de succès ou il affiche un message de retour à l’interface précédente. Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur » ajouter user afficher utilisateur ajouté ajouter retour vers le formulaire vérifier remplir le formulaire afficher le formulaire cliquer sur ajouter utilisateur administrateur systéme ref s'authentifier() données invalides données valides alt afficher utilisateur ajouté ajouter retour vers le formulaire vérifier remplir le formulaire afficher le formulaire cliquer sur ajouter utilisateur
  • 32. 19 2.3. Description textuelle cas d’utilisation «modifier utilisateur» : Cu Modifier utilisateur Acteur Administrateur Pré- condition S’authentifier Post –condition Modification enregistrée Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier 2. Le système affiche le formulaire de modification 3. L’administrateur saisit la nouvelle donnée 4. Le système vérifie et enregistre la modification 5. Le système affiche la nouvelle donnée Scénario alternatif 4.1 donnée manquante Tableau 6 : Description textuelle du cas « modifier utilisateur» 2.4. Diagramme de séquence système du cas « modifier utilisateur» : La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder à sa plate-forme afin de modifier l’utilisateur. Figure 9 : Diagramme de séquence système du cas « modifier utilisateur» 19 2.3. Description textuelle cas d’utilisation «modifier utilisateur» : Cu Modifier utilisateur Acteur Administrateur Pré- condition S’authentifier Post –condition Modification enregistrée Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier 2. Le système affiche le formulaire de modification 3. L’administrateur saisit la nouvelle donnée 4. Le système vérifie et enregistre la modification 5. Le système affiche la nouvelle donnée Scénario alternatif 4.1 donnée manquante Tableau 6 : Description textuelle du cas « modifier utilisateur» 2.4. Diagramme de séquence système du cas « modifier utilisateur» : La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder à sa plate-forme afin de modifier l’utilisateur. Figure 9 : Diagramme de séquence système du cas « modifier utilisateur» 19 2.3. Description textuelle cas d’utilisation «modifier utilisateur» : Cu Modifier utilisateur Acteur Administrateur Pré- condition S’authentifier Post –condition Modification enregistrée Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier 2. Le système affiche le formulaire de modification 3. L’administrateur saisit la nouvelle donnée 4. Le système vérifie et enregistre la modification 5. Le système affiche la nouvelle donnée Scénario alternatif 4.1 donnée manquante Tableau 6 : Description textuelle du cas « modifier utilisateur» 2.4. Diagramme de séquence système du cas « modifier utilisateur» : La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder à sa plate-forme afin de modifier l’utilisateur. Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
  • 33. 20 2.5. Description textuelle du cas d’utilisation «supprimer utilisateur» : Cu Supprimer utilisateur Acteur Administrateur Pré- condition S’authentifier Post –condition Utilisateur supprimé Scénario nominal 1. L’administrateur choisit l’utilisateur qu’il veut supprimer 2. Le système supprime l’utilisateur sélectionné 3. Le système affiche la suppression effectuée Scénario alternatif Aucune Tableau 7 : Description textuelle du cas « supprimer utilisateur » 2.6. Diagramme de séquence système du cas «supprimer utilisateur» : L’administrateur a aussi le droit de supprimer un ou plusieurs utilisateurs. Figure10 : Diagramme de séquence système du cas « supprimer utilisateur» 3. Analyse du cas «gérer rendez-vous» : 3.1. Diagramme du cas d’utilisation « gérer rendez-vous » : L’utilisateur peut gérer un rendez-vous en ajoutant, modifiant ou annulant ce dernier. Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous » supprimer user supprimer afficher utilisateur supprimer cliquer sur supprimer adminstrateur systeme ref s'authentifier() supprimer afficher utilisateur supprimer cliquer sur supprimer <<include>> secrétaire gérer rendez-vous ajouter rendez-vous modifier rendez-vous supprimer rendez vous s'authentifier
  • 34. 21 3.2. Description textuelle cas d’utilisation « ajouter rendez-vous» : CU : gérer le rendez-vous : ajouter Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : rendez-vous ajouté Scénario nominal : 1. l’utilisateur clique sur gérer rendez-vous 2. le système affiche le formulaire de rendez-vous 3. l’utilisateur remplit le formulaire présenté 4. le système vérifie si tous les champs remplis 5. le système affiche un message « rendez-vous ajouté » Scénario alternatif : 4.1. le rendez- vous invalide Tableau 8: description textuelle du cas « ajouter un rendez-vous » 3.3. Diagramme de séquence système du cas « ajouter rendez-vous» : La figure 12 illustre le diagramme de séquence qui consiste à ajouter un rendez-vous. Si le patient existe déjà, le système affiche un message d’erreur. Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous » ajouter rendez-vous ajouter vérifier affiche le formulaire remplir le formulaire présenté rendez-vous ajouté retour vers le formulaire cliquer sur gérer le rendez-vous utilisateur système ref s'authentifier() rendez-vous invalide rendez-vous valide alt ajouter vérifier affiche le formulaire remplir le formulaire présenté rendez-vous ajouté retour vers le formulaire cliquer sur gérer le rendez-vous
  • 35. 22 3.4. Description textuelle cas d’utilisation « modifier un rendez-vous» : CU : gérer le rendez-vous : modifier Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : rendez-vous modifié Scénario nominal : 1. l’utilisateur clique sur gérer rendez-vous 2. le système affiche les listes de rendez-vous 3. l’utilisateur choisir le rendez-vous à modifier 4. le système affiche le formulaire 5. l’utilisateur saisit les nouvelles données 6. le système vérifie les champs remplis 7. l e système affiche un message « rendez-vous modifié » Scénario alternatif : 6.1 : le rendez-vous réservé Tableau 9 : Description textuelle du cas « modifier un rendez-vous » 3.5. Diagramme de séquence système du cas «modifier rendez-vous» : La figure 13 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un ou plusieurs rendez-vous. Si le rendez-vous n’est pas réservé, le système modifié le rendez-vous sinon retour vers le formulaire. Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous » modifier rendez-vous modifier vérifier saisir les nouvelles données afficher le formulaire rendez vous modifié retour vers le formulaire choisir le rendez-vous à modifier afficher la liste du rendez-vous cliquer sur gérer le rendez-vous utilisateur système ref s'authentifier() rendez-vous invalide rendez-vous valide alt modifier vérifier saisir les nouvelles données afficher le formulaire rendez vous modifié retour vers le formulaire choisir le rendez-vous à modifier afficher la liste du rendez-vous cliquer sur gérer le rendez-vous
  • 36. 23 3.6. Description textuelle cas d’utilisation « supprimer un rendez-vous» : CU : rendez-vous : supprimer Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : rendez-vous supprimé Scénario nominal : 1. l’utilisateur clique sur gérer le rendez-vous 2. le système affiche une liste de rendez-vous 3. l’utilisateur sélectionne le rendez-vous à supprimer 4. le système supprimer le rendez-vous Scénario alternatif : aucun Tableau 10 : Description textuelle du cas « supprimer un rendez-vous » 3.7. Diagramme de séquence système du cas « supprimer rendez-vous» : La figure 14 illustre le diagramme de séquence qui permet à l’administrateur du supprimer les rendez-vous. Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous » 4. Analyse du cas «gérer fiche patient» : L’utilisateur clique sur la rubrique fiche patient, le système affiche un formulaire à remplir qui permet à l’utilisateur d’ajouter, modifier ou supprimer un patient. supprimer rendez vous supprimer cliquer sur gérer le rendez-vous afficher la liste du rendez-vous sélectionner le rendez-vous à supprimer afficher le rendez-vous supprimé utilisateur système ref s'authentifier() supprimer cliquer sur gérer le rendez-vous afficher la liste du rendez-vous sélectionner le rendez-vous à supprimer afficher le rendez-vous supprimé
  • 37. 24 4.1. Classification du cas d’utilisation «gérer patient » : Figure 15 : diagramme du cas d’utilisation « gérer patient » 4.2. Description textuelle cas d’utilisation « ajouter patient » : CU : gérer le patient: ajouter Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : patient ajouté Scénario nominal : 1. l’utilisateur clique sur ajouter patient 2. le système affiche l’interface demandée 3. l’utilisateur remplit le formulaire du patient 4. le système vérifie les champs et l’existence de patient 5. le système enregistre le nouveau patient 6. le système affiche patient enregistré Scénario alternatif : 4.1 les champs ne sont pas bien remplis 5.1 le patient existe déjà dans la base Tableau 11 : Description textuelle du cas « ajouter patient » <<include>> Secrétaire gérer patient ajouter patient modifier patient s'authentifier supprimer patient
  • 38. 25 4.3. Diagramme de séquence système du cas « ajouter patient » : La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient. Figure16 : Diagramme de séquence système du cas « ajouter patient » 4.4. Description textuelle cas d’utilisation « modifier le patient » : CU : gérer le patient : modifier Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : patient modifié Scénario nominal : 1. l’utilisateur clique sur fiche patient 2. le system affiche la liste du patient enregistré 3. l’utilisateur sélectionne le patient à modifier 4. le système affiche la fiche du patient 5. l’utilisateur saisit les nouvelles données 6. le système enregistre la modification 7. le système affiche la nouvelle donnée Scénario alternatif : 4.1 le patient n’est pas enregistré. Tableau 12 : Description textuelle du cas « modifier patient » 25 4.3. Diagramme de séquence système du cas « ajouter patient » : La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient. Figure16 : Diagramme de séquence système du cas « ajouter patient » 4.4. Description textuelle cas d’utilisation « modifier le patient » : CU : gérer le patient : modifier Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : patient modifié Scénario nominal : 1. l’utilisateur clique sur fiche patient 2. le system affiche la liste du patient enregistré 3. l’utilisateur sélectionne le patient à modifier 4. le système affiche la fiche du patient 5. l’utilisateur saisit les nouvelles données 6. le système enregistre la modification 7. le système affiche la nouvelle donnée Scénario alternatif : 4.1 le patient n’est pas enregistré. Tableau 12 : Description textuelle du cas « modifier patient » 25 4.3. Diagramme de séquence système du cas « ajouter patient » : La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient. Figure16 : Diagramme de séquence système du cas « ajouter patient » 4.4. Description textuelle cas d’utilisation « modifier le patient » : CU : gérer le patient : modifier Acteur : médecin, secrétaire Pré-condition : s’authentifier Post-condition : patient modifié Scénario nominal : 1. l’utilisateur clique sur fiche patient 2. le system affiche la liste du patient enregistré 3. l’utilisateur sélectionne le patient à modifier 4. le système affiche la fiche du patient 5. l’utilisateur saisit les nouvelles données 6. le système enregistre la modification 7. le système affiche la nouvelle donnée Scénario alternatif : 4.1 le patient n’est pas enregistré. Tableau 12 : Description textuelle du cas « modifier patient »
  • 39. 26 4.5. Diagramme de séquence système du cas « modifier patient » : La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un patient. Figure 17 : Diagramme de séquence système du cas « modifier patient » 4.6. Description textuelle du cas « supprimer patient » : Cu Supprimer patient Acteur Utilisateur (secrétaire, médecin) Pré- condition S’authentifier Post –condition Patient supprimé Scénario nominal 1. l’utilisateur clique sur fiche patient 2. le système affiche liste du patient 3. Utilisateur sélectionne le patient à supprimer 4. Le système supprime le patient sélectionné 5. Le système afficher suppression effectuée Scénario alternatif Aucun Tableau 13 : Description textuelle du cas « supprimer patient » 26 4.5. Diagramme de séquence système du cas « modifier patient » : La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un patient. Figure 17 : Diagramme de séquence système du cas « modifier patient » 4.6. Description textuelle du cas « supprimer patient » : Cu Supprimer patient Acteur Utilisateur (secrétaire, médecin) Pré- condition S’authentifier Post –condition Patient supprimé Scénario nominal 1. l’utilisateur clique sur fiche patient 2. le système affiche liste du patient 3. Utilisateur sélectionne le patient à supprimer 4. Le système supprime le patient sélectionné 5. Le système afficher suppression effectuée Scénario alternatif Aucun Tableau 13 : Description textuelle du cas « supprimer patient » 26 4.5. Diagramme de séquence système du cas « modifier patient » : La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un patient. Figure 17 : Diagramme de séquence système du cas « modifier patient » 4.6. Description textuelle du cas « supprimer patient » : Cu Supprimer patient Acteur Utilisateur (secrétaire, médecin) Pré- condition S’authentifier Post –condition Patient supprimé Scénario nominal 1. l’utilisateur clique sur fiche patient 2. le système affiche liste du patient 3. Utilisateur sélectionne le patient à supprimer 4. Le système supprime le patient sélectionné 5. Le système afficher suppression effectuée Scénario alternatif Aucun Tableau 13 : Description textuelle du cas « supprimer patient »
  • 40. 27 4.7. Diagramme de séquence système du cas « supprimer patient » : Figure 18 : Diagramme de séquence système du cas « supprimer patient » IV. Conception des cas d’utilisation : Nous allons préparer les diagrammes Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation pour passer aux diagrammes des séquences détaillés et les diagrammes des classes d’objets du premier sprint. 1. Modèle d’analyse du cas d’utilisation «s’authentifier» : 1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « s’authentifier » : Figure 19: Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation du cas « S'authentifier » supprimer patient supprimer sélectionner le patient à supprimer afficher liste du patient cliquer sur fiche patient afficher patient supprimé utilisateur système supprimer sélectionner le patient à supprimer afficher liste du patient cliquer sur fiche patient afficher patient supprimé <<trace>> <participate><participate><participate> utilisateur s'authentifier S'authentifier contrôleur login user profil interface autherntificationadministrateur
  • 41. 28 1.2 Modèle de classe d’analyse d’utilisation « s’authentifier » : Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier » 1.3 Diagramme de séquence détaillé du cas d’utilisation « s’authentifier » : Figure 21: diagramme de séquence détaillé du cas « S'authentifier » uti l i sateur i nterface authenti fi cati on contrôl eur l ogi n user profi l s'authentifier afficher l'interface demandée demander l'interface d'authentification retour vers l'interface authentification afficher l'interface d'accueil vérifier envoyer les données saisir login et mot de passe utilisateur interface _s'authentifier s'authentifier user profilinterface d'accueil login ou mot de passe incorrect login ou mot de passe correct alt loop afficher l'interface demandée demander l'interface d'authentification retour vers l'interface authentification afficher l'interface d'accueil vérifier envoyer les données saisir login et mot de passe
  • 42. 29 2. Modèle d’analyse du cas d’utilisation « générer le site» : 2.1. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter utilisateur » : Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter utilisateur du cas « ajouter utilisateur » 2.2. Modèle de classe d’analyse d’utilisation « ajouter utilisateur» : Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur» <<trace>> <participate><participate><participate> administrateur ajouter utilisateur Ajouter utilisateur contrôleur new user user profilinterface formulaire adminsitrateur interface formulaire contrôleur new useruser profil
  • 43. 30 2.3. Diagramme de séquence détaillé du cas d’utilisation « ajouter utilisateur» : Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur » 2.4. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « modifier utilisateur » : Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « modifier utilisateur » 2.5. Modèle de classe d’analyse d’utilisation « modifier utilisateur» : Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur» ajouter user afficher utilisateur ajouté réponse retour vers formulaire envoyer données envoyer le formulaire envoyer la demande demander l'interface d'ajout ajouter vérifier remplir le formulaire administrateur Interface utilisateur e_utilisateurc_new user ref s'authentifier() données manquantes données remplis alt afficher utilisateur ajouté réponse retour vers formulaire envoyer données envoyer le formulaire envoyer la demande demander l'interface d'ajout ajouter vérifier remplir le formulaire <<trace>> <participate> <participate><participate> administrateur modifier utilisateur Modifier utilisateur contrôleur edit user user profilinterface modification adm i nsi trateur i nterface m odi fi cati on contrôl eur edi t user user profi l
  • 44. 31 2.6. Diagramme de séquence détaillé du cas d’utilisation « modifier utilisateur» : Figure 27 : Diagramme de séquence détaillée du cas « modifier utilisateur » 2.7. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « supprimer utilisateur» : Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du cas « supprimer utilisateur » modifier user modifier afficher nouvelle donnée réponse retour vers formulaire envoyer donnée saisir nouvelle donnée afficher le formulaire de modification réponse vérifier sélectionner sur l' utilisateur à modifier envoyer la demande administrateur Interface utilisateur user profilcontrôleur liste utilisateur ref s'authentifier() données manquantes données remplis alt modifier afficher nouvelle donnée réponse retour vers formulaire envoyer donnée saisir nouvelle donnée afficher le formulaire de modification réponse vérifier sélectionner sur l' utilisateur à modifier envoyer la demande <<trace>> <participate><participate><participate> administrateur supprimer utilisateur Supprimer utilisateur contrôleur liste utilisateur user profilinterface liste utilisateur
  • 45. 32 2.8. Modèle de classe d’analyse d’utilisation « supprimer utilisateur» : Figure 29 : Modèle de classe d’analyse d’utilisation « supprimer utilisateur» 2.9. Diagramme de séquence détaillé du cas d’utilisation « supprimer utilisateur» : Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur » 3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous» : 3.1 .Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter rendez-vous » : Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter rendez-vous » adminsitrateur interface liste utilisateur contrôleur liste utilisateuruser profil supprimer user choisir l'utilisateur à supprimer réponse afficher utilisateur supprimé envoyer requête envoyer demande administrateur I_liste_utilisateur e_utilisateurc_utilisateur ref s'authentifier() choisir l'utilisateur à supprimer réponse afficher utilisateur supprimé envoyer requête envoyer demande <<trace>> <participate><participate><participate> utilisateur ajouter rendez- vous Ajouter Rendez- vous controlleur rendez-vous rednez-vous interface rendez-vous