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