Ce document est un rapport de projet de fin d'études pour une application e-santé intégrée à OpenMRS, élaboré par Soumaya Nebli et Ibtissem Slimeni à l'Université de la Manouba. Il détaille la planification, la conception, le développement et la validation de l'application à travers plusieurs sprints en utilisant la méthode agile Scrum. Le rapport comprend également des remerciements et des dédicaces aux personnes ayant soutenu les auteurs durant leur parcours académique.

1. Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique
Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique
Code: 422 Année Universitaire: 2016-2017
Université de la Manouba
École Supérieure d’Économie Numérique
Rapport
De projet de fin d'études
Sujet :
Conception et développement d’une application e-santé à intégrer
dans OpenMRS
Élaboré par:
Soumaya Nebli
Ibtissem Slimeni
Organisme d'accueil
ATH CONSULTING
Encadré par :
ESEN Mme ISMAHEN CHAHBI
Société M. IZHAR MAHJOUB
Présenté en vue de l'obtention du diplôme de
Licence Appliquée en Commerce Electronique

2. Dédicace
À MES CHERS PARENTS (Mamia & Rachid)
Aucune dédicace ne saurait exprimer mon respect, mon amour éternel et ma
considération pour les sacrifices que vous avez consentis pour mon instruction
et mon bien-être. Je vous remercie pour tout le soutien et l’amour que vous me
portez depuis mon enfance et j’espère que votre bénédiction m’accompagne
toujours. Que ce modeste travail soit l’exaucement de vos vœux tant formulés,
le fruit de vos innombrables sacrifices, bien que je ne vous en acquitterai
jamais assez. Puisse Dieu, le Très Haut, vous accorder santé, bonheur et longue
vie et faire en sorte que jamais je ne vous déçoive.
A ma chère sœur Olfa
Ma chère sœur présente dans tous mes moments d’examens par son soutien
moral et ses belles surprises sucrées. Je te souhaite un avenir plein de joie, de
bonheur, de réussite et de sérénité. Je t’exprime à travers ce travail mes
sentiments de fraternité et d’amour.
A mon cher frère Ala
Aucun mot ne pourrait exprimer l’attachement, l’amour et la tendresse que
j’éprouve pour vous. Je prie le Bon Dieu de me donner la force et les moyens de
toujours prendre soin de vous.
Enfin, une dédicace spéciale à une Personne spéciale qui se reconnaitra
Soumaya Nebli

3. Dédicace
A ma très chère mère Rbeh
Affable, honorable, aimable : Tu représentes pour moi le symbole de la bonté
par excellence, la source de tendresse et l’exemple du dévouement qui n’a pas
cessé de m’encourager et de prier pour moi.
A mon très cher père Noureddine
Mon père qui a toujours me soutenir, me conseiller, m’assister et m’indique le
bon chemin. L’amour qui il me voue est irremplaçable …. Ses sacrifices pour
mon éducation et mes études sont énormes, je lui dois beaucoup et je lui suis
que reconnaissante.
A mon très cher frère Achref, son épouse Yassmine Et leur
petit garçon Amen Allah
Mon cher frère qui m’est le père et la mère, les mots ne suffisent guère pour
exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mon
ange gardien et mon fidèle compagnon dans les moments les plus délicats de
cette vie mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur,
de santé et de réussite.
A ma très chère soeur Yossra
En témoignage de l’attachement, de l’amour et de l’affection que je porte pour
toi. Tu es toujours dans mon cœur. Je te remercie pour ton hospitalité sans égal
et ton affection si sincère. Je te dédie ce travail avec tous mes vœux de bonheur,
de santé et de réussite.
Ibtissem Slimeni

4. Remerciements
Avant d’entamer ce rapport, nous profitons de l’occasion pour
exprimer nos vifs remerciements à toute personne ayant contribué, de
près ou de loin, à l’accomplissement de ce travail.
Le Seigneur Dieu tout puissant, pour m’avoir accordé vie, santé et
paix de l’esprit sans quoi je n’aurai pu achever nous projet de fin
d'étude
Nous souhaitons remercier notre encadrant Mme Ismahen chahbi,
qui n’a pas cessé de nous encourager pendant la réalisation de ce
travail de fin d’études ainsi pour sa générosité en matière de
formation et d’encadrement.
M. Izhar Mahjoub, Mohamed kTARi pour nous avoir offert
l’opportunité d’effectuer ce stage, ainsi pour leurs suivis et
encouragements, leurs entières disponibilités à nous fournir leur
confiance et leur assistance la plus attentionnée.
Nous tenons à remercier vers nos familles et nos amis de nous avoir
soutenus et encouragés tout au long de notre projet.
Finalement nous remercions tous les enseignants de l’École Supérieur
d’Économie Numérique pour nos trois années de licence.
Soumaya Nebli & Ibtissem Slimeni

5. Table des matières
Introduction générale ....................................................................................................... 1
Chapitre I : Étude de projet............................................................................................... 2
Introduction ............................................................................................................................. 2
I. Cadre du projet...................................................................................................................................... 2
1. Description du contexte de projet : .................................................................................................. 3
II. L’état de l’art ......................................................................................................................................... 4
1. OpenMRS .......................................................................................................................................... 4
2. Critique.............................................................................................................................................. 5
III. Méthode de modélisation et de conception ......................................................................................... 5
1. Méthode agile ................................................................................................................................... 5
2. SCRUM............................................................................................................................................... 6
IV. Langage de modélisation UML (Unified Modeling Language)............................................................... 9
Conclusion................................................................................................................................ 9
Chapitre II : Planification et Architecture..........................................................................10
Introduction ........................................................................................................................... 10
I. Capture des besoins : .......................................................................................................................... 10
1. Identification des acteurs................................................................................................................ 10
2. Analyse des besoins fonctionnels.................................................................................................... 10
3. Analyse des besoins non fonctionnels ............................................................................................ 11
II. Structure et découpage du projet ............................................................................................................ 11
1. Identification de l’équipe SCRUM ................................................................................................... 11
2. Le backlog du produit...................................................................................................................... 11
3. Planification des releases................................................................................................................ 12
4. Diagramme du cas d’utilisation global ............................................................................................ 13
Conclusion.............................................................................................................................. 13
Chapitre III : Sprint 1 : Gestion de personnel .....................................................................14
Introduction ........................................................................................................................... 14
I. Spécification des besoins..................................................................................................................... 14
1. Le sprint backlog ............................................................................................................................. 14
II. Diagramme des cas d’utilisation du premier Sprint ............................................................................ 16
1. Classification des cas d’utilisation par acteur ................................................................................. 16
2. Diagramme du cas d’utilisation du premier sprint.......................................................................... 16
III. Analyse des cas d’utilisation................................................................................................................ 17
1. Analyse du cas « s’authentifier »..................................................................................................... 17
2. Analyse du cas « gérer les utilisateurs».......................................................................................... 18
3. Analyse du cas «gérer rendez-vous»................................................................................................... 20
4. Analyse du cas «gérer fiche patient» .................................................................................................. 23
IV. Conception des cas d’utilisation.......................................................................................................... 27
1. Modèle d’analyse du cas d’utilisation «s’authentifier»................................................................. 27
2. Modèle d’analyse du cas d’utilisation « générer le site»..................................................................... 29
3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous»........................................................... 32

6. 4. Modèle d’analyse du cas d’utilisation «gérer fiche patient» .............................................................. 37
5. Diagramme de Classe globale du premier sprint ................................................................................. 41
V. Codage...................................................................................................................................................... 42
VI. Test.......................................................................................................................................................... 43
Conclusion.............................................................................................................................. 44
Chapitre IV : Sprint 2 : Gérer la consultation et l’ordonnance ...........................................45
Introduction ........................................................................................................................... 45
I. Spécification des besoins..................................................................................................................... 45
1. Le sprint backlog ............................................................................................................................. 45
II. Diagramme du cas d’utilisation du deuxième sprint ............................................................................... 46
1. Répartition des cas d’utilisation par acteur .................................................................................... 47
III. Analyse des cas d'utilisation.................................................................................................................... 48
1. analyse des cas d'utilisation «gérer la consultation»........................................................................... 48
2. Analyse du cas d’utilisation «gérer antécédent»:............................................................................... 51
3. Analyse du cas d’utilisation «gérer examen»....................................................................................... 55
4. analyse des cas d'utilisation «gérer données anthropométriques» .................................................... 58
5. analyse des cas d'utilisation «gérer ordonnance»............................................................................... 62
IV. Conception de cas d'utilisation ............................................................................................................... 65
1. Modèle d’analyse du cas d’utilisation «gérer la consultation»........................................................... 65
2. Diagramme de classe globale de deuxième sprint.............................................................................. 88
V. Codage...................................................................................................................................................... 89
VI. Test.......................................................................................................................................................... 90
Conclusion.............................................................................................................................. 92
Chapitre V : Sprint 3: Gérer le dossier médical .................................................................93
Introduction ........................................................................................................................... 93
I. Spécification des besoins........................................................................................................................... 93
1. Sprint Backlog ...................................................................................................................................... 93
II. Diagramme des cas d’utilisation du troisième Sprint............................................................................... 94
1. Classification des cas d’utilisation par acteur ...................................................................................... 94
2. Diagramme de cas d’utilisation du Troisième sprint............................................................................ 94
III. Analyse des cas d’utilisation.................................................................................................................... 95
1. Analyse des cas d’utilisation «gérer le dossier médical» ..................................................................... 95
IV. Conception du cas d'utilisation ............................................................................................................... 97
1. Modèle d’analyse du cas d’utilisation «consulter dossier médical» .............................................. 97
2. Modèle d’analyse du cas d’utilisation du cas «imprimer dossier médical»......................................... 98
3. Diagramme de classe global du troisième sprint ............................................................................... 100
V. Codage.................................................................................................................................................... 101
VI. Test........................................................................................................................................................ 101
Conclusion.............................................................................................................................101
Chapitre VI : phase de clôture ........................................................................................102
Introduction ..........................................................................................................................102
I. Environnement de développement................................................................................................... 102
1. Environnement matériel ............................................................................................................... 102
2. Environnement logiciel.................................................................................................................. 102

7. 3. Technologies et Langage de programmation utilisée ................................................................... 103
II. Style architectural.............................................................................................................................. 104
III. Elaboration du diagramme de déploiement...................................................................................... 105
1. Diagramme de déploiement .............................................................................................................. 106
2. Diagramme de Gantt.......................................................................................................................... 106
Conclusion.............................................................................................................................106
Conclusion générale......................................................................................................107
Bibliographie.................................................................................................................108
Neto graphie .................................................................................................................108

8. Liste des figures
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting...................................... 3
Figure2 : Scrum en rugby........................................................................................................... 6
Figure3: Le processus SCRUM ........................................................................................................................ 7
Figure 4: exemple de plan de release........................................................................................................... 13
Figure 5 : diagramme du cas d’utilisation global.......................................................................................... 13
Figure 6 : diagramme du cas d’utilisation du premier sprint ....................................................................... 16
Figure 7 : Diagramme de séquence système du cas « S’authentifier »........................................................ 17
Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur »................................................. 18
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»............................................... 19
Figure10 : Diagramme de séquence système du cas « supprimer utilisateur» ........................... 20
Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous ».............................................................. 20
Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous » ...................................... 21
Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous » ................................... 22
Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous » ................................... 23
Figure 15 : diagramme du cas d’utilisation « gérer patient ».................................................... 24
Figure16 : Diagramme de séquence système du cas « ajouter patient ».................................................... 25
Figure 18 : Diagramme de séquence système du cas « supprimer patient ».............................................. 27
Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier »......................................................... 28
Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter utilisateur
du cas « ajouter utilisateur »........................................................................................................................ 29
Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur» ................................................... 29
Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur » .............................................. 30
Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « modifier
utilisateur » .................................................................................................................................................. 30
Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur» .............................................. 30
Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du cas « supprimer
utilisateur » .................................................................................................................................................. 31
Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur ».......................................... 32
Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter rendez-
vous » ........................................................................................................................................................... 32
Figure 32 : Modèle de classe d’analyse d’utilisation «ajouter rendez-vous ».............................................. 33
Figure 33: Diagramme de séquence détaillé du cas d’utilisation « ajouter rendez-vous»......................... 33
Figure34 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« modifier rendez-vous »..................................................................................... 34
Figure 35 : Modèle d’analyse d’utilisation « modifier rendez-vous »......................................... 34
Figure 37 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation«
supprimer rendez-vous »............................................................................................................................. 35
Figure 38 : Modèle de classe d’analyse d’utilisation « supprimer rendez-vous »........................................ 36
Figure 40 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation :
« ajouter patient »........................................................................................................................................ 37
Figure 41 : Modèle de classe d’analyse d’utilisation « ajouter patient»...................................................... 37
Figure 43: Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier patient »...................................................................................................................................... 38
Figure 44 : Modèle de classe d’analyse d’utilisation « modifier patient ».................................................. 39

9. Figure 45 : Diagramme de séquence détaillé du cas « modifier patient ».................................................. 39
Figure 46 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer patient ».................................................................................................................................. 40
Figure 47 : Modèle de classe d’analyse d’utilisation « supprimer patient » ............................................... 40
Figure 48 : Diagramme de séquence détaillé du cas « supprimer patient » ............................................... 41
Figure 49 : diagramme de classe globale du premier sprint ...................................................... 41
Figure 50 : page d’authentification .............................................................................................................. 43
Figure 51 : page de la fiche patient .............................................................................................................. 43
Figure 52: page de rendez-vous .................................................................................................................. 44
Figure 53: Diagramme du cas d’utilisation global du deuxième sprint ....................................................... 47
Figure 54: cas d’utilisation du cas « gérer la consultation »......................................................................... 48
Figure 56 : Diagramme de séquence système du cas « ajouter diagnostics » ............................................. 49
Figure 57 : Diagramme de séquence système du cas « modifier diagnostics » ........................................... 50
Figure 58 : Diagramme de séquence système du cas « supprimer diagnostics » ....................................... 51
Figure 59 : cas d’utilisation du cas « gérer antécédent».............................................................................. 51
Figure 60: Diagramme de séquence système du cas « ajouter antécédent ».............................................. 52
Figure 61: Diagramme de séquence système du cas « modifier antécédent »............................................ 53
Figure 62: Diagramme de séquence système du cas « supprimer antécédents » ....................................... 54
Figure 63: Diagramme du cas d’utilisation « gérer examen »...................................................................... 55
Figure 64 : Diagramme de séquence système du cas « ajouter examen » .................................................. 56
Figure 65: Diagramme de séquence système du cas « modifier examen » ................................................. 57
Figure 66: Diagramme de séquence système du cas «supprimer examen » ............................................... 58
Figure 67 : diagramme du cas d’utilisation «gérer données anthropométriques ».................................... 58
Figure 68: Diagramme de séquence système du cas «ajouter données anthropométriques»................... 59
Figure 69: Diagramme de séquence système du cas «modifier données anthropométriques»................. 60
Figure 70: Diagramme de séquence système du cas «supprimer données anthropométriques»............. 61
Figure 72 : Diagramme de séquence système du cas « ajouter ordonnance »............................................ 63
Figure 73 : Diagramme de séquence système du cas « consulter l’ordonnance »...................................... 64
Figure 74 : Diagramme de séquence système du cas « supprimer l’ordonnance ».................................... 65
Figure 75 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«ajouter diagnostic ».................................................................................................................................... 65
Figure 76: Modèle de classe d’analyse d’utilisation «ajouter diagnostic » ................................................. 66
Figure 77 : Diagramme de séquence détaillée du cas «ajouter diagnostic » ............................................... 66
Figure 78: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier diagnostic».................................................................................................................................. 67
Figure 79 : Modèle de classe d’analyse d’utilisation « modifier diagnostic» .............................................. 67
Figure 80: Diagramme de séquence détaillée du cas d’utilisation « modifier diagnostic» ......................... 68
Figure 81: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer diagnostic »............................................................................................................................. 68
Figure 82 : Modèle de classe d’analyse d’utilisation « supprimer diagnostic» ........................................... 69
Figure83 : Diagramme de séquence détaillée du cas d’utilisation « supprimer diagnostic » ..................... 69
Figure 84: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter antécédent».................................................................................................................................. 70
Figure85 : Modèle de classe d’analyse d’utilisation « ajouter antécédent » .............................................. 70
Figure 86 : Diagramme de séquence détaillée du cas « ajouter antécédent » ............................................ 71
Figure87 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«modifier antécédent»................................................................................................................................. 71
Figure88 : Modèle de classe d’analyse d’utilisation « modifier antécédent » ............................................ 72
Figure 89 : Diagramme de séquence détaillée du cas « modifier antécédent » .......................................... 72

10. Figure 90 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer antécédent»............................................................................................................................ 73
Figure 91 : Modèle de classe d’analyse d’utilisation «supprimer antécédent » ......................................... 73
Figure 92 : Diagramme de séquence détaillée du cas « supprimer antécédent » ...................................... 74
Figure 93 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter examen » ...................................................................................................................................... 74
Figure 94 : Modèle de classe d’analyse d’utilisation « ajouter examen »................................................... 75
Figure 95 : Diagramme de séquence détaillée de cas « ajouter examen ».................................................. 75
Figure 96 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« modifier examen » .................................................................................................................................... 76
Figure 97 : Modèle de classe d’analyse d’utilisation « modifier examen »................................................. 76
Figure 98 : Diagramme de séquence détaillée de cas « modifier examen »............................................... 77
Figure 99 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer examen ».................................................................................................................................. 77
Figure 100 : Modèle de classe d’analyse d’utilisation « supprimer examen »............................................ 78
Figure 101 : Diagramme de séquence détaillée de cas « supprimer examen ».......................................... 78
Figure102 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«ajouter données anthropométriques»....................................................................................................... 79
Figure 103 : Modèle de classe d’analyse d’utilisation «ajouter données anthropométriques » ................ 79
Figure 104 : Diagramme de séquence détaillée de cas «ajouter données anthropométriques » ............... 80
Figure105 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«modifier données anthropométriques».................................................................................................... 80
Figure 106: Modèle de classe d’analyse d’utilisation «modifier données anthropométriques » ............... 81
Figure107 : Diagramme de séquence détaillée de cas « modifier données anthropométriques» ............. 81
Figure 108: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
«supprimer données anthropométriques» ................................................................................................. 82
Figure109 : Modèle de classe d’analyse d’utilisation «supprimer données anthropométriques » ............ 82
Figure 110 : Diagramme de séquence détaillée de cas « supprimer données anthropométriques» .......... 83
Figure 111 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« ajouter ordonnance»................................................................................................................................. 83
Figure 112 : Modèle de classe d’analyse d’utilisation « ajouter ordonnance » .......................................... 84
Figure 113: Diagramme de séquence détaillée du cas « ajouter ordonnance »......................................... 84
Figure 114 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« consulter ordonnance» ............................................................................................................................ 85
Figure 115 : Modèle de classe d’analyse d’utilisation « consulter ordonnance »....................................... 85
Figure 116 : Diagramme de séquence détaillée du cas «consulter ordonnance »....................................... 86
Figure 117: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« supprimer ordonnance»........................................................................................................................... 86
Figure 118 : Modèle de classe d’analyse d’utilisation « supprimer ordonnance » ..................................... 87
Figure 119: Diagramme de séquence détaillée du cas «supprimer ordonnance » ..................................... 87
Figure 120 : Diagramme de classe globale de deuxième sprint ................................................................... 88
Figure 121: page de consultation ............................................................................................................... 90
Figure 122 : page d’ordonnance.................................................................................................................. 91
Figure 123: page diagnostic......................................................................................................................... 91
Figure 124: page d’examen .......................................................................................................................... 92
Figure 125: Diagramme du cas d’utilisation du troisième sprint ................................................................. 94
Figure 126 : Diagramme de séquence système du cas « consulter dossier médical »................................ 95
Figure 127 : Diagramme de séquence système du cas «imprimer dossier médical»................................... 96
Figure 128 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« consulter dossier médical»........................................................................................................................ 97

11. Figure 129 : Modèle de classe d’analyse d’utilisation « consulter dossier médical» .................................. 97
Figure 130 : diagramme de séquence détaillée du cas «consulter dossier médical» .................................. 98
Figure 131 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation
« imprimer dossier médical »...................................................................................................................... 98
Figure 132 : Modèle de classe d’analyse d’utilisation «imprimer dossier médical» ................................... 99
Figure 133: Diagramme de séquence détaillée du cas «imprimer dossier médical»................................... 99
Figure 134: diagramme de classe global du troisième sprint..................................................................... 100
Figure 135: page dossier médical............................................................................................................... 101
Figure 136: niveau de l’architecture........................................................................................................... 105
Figure 137 : Diagramme de déploiement................................................................................................... 106
Figure 138: Diagramme de Gantt............................................................................................................... 106

12. Liste des tableaux
Tableau 1: tableau de backlog initial................................................................................12
Tableau 2: Backlog du premier sprint ...............................................................................15
Tableau 3: classification des cas d'utilisation par acteur ...................................................16
Tableau 4: description textuelle du cas «S’authentifier»...................................................17
Tableau 5: description textuelle du cas «ajouter utilisateur» ............................................18
Tableau 6 : Description textuelle du cas « modifier utilisateur».......................................19
Tableau 8: description textuelle du cas « ajouter un rendez-vous »..................................21
Tableau 9 : Description textuelle du cas « modifier un rendez-vous » .............................22
Tableau 10 : Description textuelle du cas « supprimer un rendez-vous » ...........................23
Tableau 11 : Description textuelle du cas « ajouter patient » .........................................24
Tableau 12 : Description textuelle du cas « modifier patient » .........................................25
Tableau 13 : Description textuelle du cas « supprimer patient »........................................26
Tableau 14: table «app user»...........................................................................................42
Tableau 15: table «user profil» ........................................................................................42
Tableau 16 : table «rendez-vous».....................................................................................42
Tableau 17: table «patient » ...........................................................................................42
Tableau 18 : Backlog du deuxième Sprint .........................................................................46
Tableau 19: tableau de répartition du deuxième sprint.....................................................47
Tableau 20 : Description textuelle du cas « ajouter diagnostics »......................................48
Tableau 21 : Description textuelle du cas « modifier diagnostics »....................................49
Tableau 22 : Description textuelle du cas « supprimer diagnostics » .................................50
Tableau 23 : Description textuelle du cas « ajouter antécédent »......................................52
Tableau 24 : Description textuelle du cas « modifier antécédents »...................................53
Tableau 25 : Description textuelle du cas « supprimer antécédent » ................................54
Tableau 26 : Description textuelle du cas « ajouter examen »...........................................55
Tableau 27 : Description textuelle du cas « modifier examen»..........................................56
Tableau 28 : Description textuelle du cas « supprimer examen » ......................................57
Tableau 29 : Description textuelle du cas « ajouter données anthropométriques» ............59

13. Tableau 30 : Description textuelle du cas « modifier données anthropométriques»...........60
Tableau 31 : Description textuelle du cas « supprimer données anthropométriques»........61
Tableau 32 : Description textuelle du cas « ajouter ordonnance ».....................................62
Tableau 33 : Description textuelle du cas « consulter ordonnance » ................................63
Tableau 34 : Description textuelle du cas « supprimer ordonnance »..............................64
Tableau 35 : table « consultation » ..................................................................................89
Tableau 36: table « ordonnance » ...................................................................................89
Tableau 37: table « diagnostic » ......................................................................................89
Tableau 38 : table « antécédent » ....................................................................................89
Tableau 39: table « examen » .........................................................................................90
Tableau 40 : Backlog du troisième sprint..........................................................................93
Tableau 41: Classification des cas d’utilisation par acteur.................................................94
Tableau 42: Description textuelle du cas « consulter dossier médical » ............................95
Tableau 43 : Description textuelle du cas «imprimer dossier médical » .............................96
Tableau 44 : table « dossier médical »............................................................................101

14. 1
Introduction générale
Les technologies de l’information participent aujourd’hui à l’amélioration de la qualité des
soins. En jouant d’une manière positive sur la tenue des dossiers médicaux, en facilitant
l’échange et le partage des données utiles à la décision médicale, tout en augmentant la
disponibilité et la rapidité d’accès à ces informations.
L’E-santé apparaît de plus en plus comme la solution à mettre en place pour pallier les
difficultés de notre système de soins qui est confronté aujourd’hui à plusieurs défis majeurs
tels que l’amélioration de suivi des patients et la confidentialité des données personnelles.
Dans ce cadre naît notre projet de fin d’étude effectuée au sein de la boîte de développement
ATH Consulting qui consiste à développer une application destinée à un médecin cardiologue
que nous envisageons intégrer dans l’outil OpenMRS. En effet, cette application permet
d’automatiser le protocole de soin des patients.
Le présent rapport est organisé en quatre chapitres :
-Dans le premier chapitre intitulé « Étude de projet », nous allons décrire le cadre général de
notre travail tout en présentant l’organisme d’accueil, l’étude de l’existant, l’outil OpenMRS
et la méthode de conception utilisée.
-Dans le deuxième chapitre intitulé « Planification et Architecture», nous allons présenter
les acteurs, les besoins fonctionnels et les besoins non fonctionnels de notre application.
-Le troisième chapitre intitulé « la gestion du personnel », le quatrième chapitre intitulé
«gérer la consultation et l’ordonnance» et le cinquième chapitre intitulé « gérer le dossier
médical » représente le corps de notre projet. En effet, ces trois chapitres seront appliqués
pour le développement de trois sprints du notre système tout en respectant les principes
fondamentaux de Scrum.
- Le dernier chapitre constitue « la phase de clôture » de notre travail. Il décrit les outils
utilisés pour la conception, et le développement de notre application.
Nous finissons par une conclusion générale, dans laquelle nous résumons notre travail, et nous
présentons l’apport de ce projet de fin d’études ainsi que les perspectives de notre application.

15. 2
Chapitre I : Étude de projet
Introduction :
Dans ce chapitre, nous allons commencer par décrire le cadre de notre projet. Ensuite, nous
allons présenter la société au sein de laquelle nous avons effectué notre projet de fin d’études.
Enfin, nous allons décrire la méthode de gestion de projet SCRUM.
I. Cadre du projet :
Notre projet de fin d’études s’inscrit dans le cadre de l’obtention du diplôme de licence
appliquée en Commerce Électronique de l’École Supérieure d’Économie Numérique
(ESEN). Ainsi, nous avons développé une application qui permet de faciliter le processus
de soins.
 Présentation d’organisme d’accueil :
Notre stage de fin d’études a été effectué au sein de la boîte de développement (ATH
Consulting) que nous allons décrire dans la suite.
Historique :
 HIMSS (Healthcare Information and Management Systems Society) est une
organisation à but non lucratif dont le but est de promouvoir la meilleure utilisation
des technologies de l’information et des systèmes de gestion dans l’industrie des soins
de santé créent en 1961.
 64000 particuliers, 640 membres corporatifs (fournisseurs du soin de santé, étudiants,
fournisseurs de TIC, consultants et autres intervenants de l’industrie des TIC en santé).
 450 organisations à but non lucratif.
 5327 organisations de santé analysées annuellement dans le monde (2011).
 Europe : 15000 visiteurs par mois sur les sites européens du HIMSS.
 Autrement dit que HIMSS est une solution informatique de santé, systèmes de santé
électriques d’enregistrement EMR-EHR.

16. 3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.
3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.
3
Figure1 : évolution du HIMSS et l’apparence de l’ATH Consulting
 ATH Consulting est un acteur majeur du Health IT dans la région de l’Afrique du
Nord. Aussi qu’ATH Consulting est un acteur majeur de la politique nationale des
systèmes d’information de santé.
 ATH Consulting est le premier membre africain du « Certified Consultant Program du
HIMSS ».
Services :
 Audit et analyse des systèmes d’information de santé.
 Définition des stratégies et organisation des systèmes d’information.
 Rédaction des schémas directeurs et cahiers des charges.
 Étude de faisabilité financière.
 Réalisation d’études du marché et recherche des solutions.
1. Description du contexte de projet :
a. Etude de l’existant :
Pour mieux comprendre le système actuel, il faut passer par la phase étude de l’existant afin
de dégager les problèmes du système existant et proposer une solution.
o Les traitements des dossiers médicaux de patient sont manuels.
o Absence d’échange entre les médecins de dossiers médicaux numériques des patients.
o Chaque médecin a son propre protocole de soin.
o Absence de confidentialité médicale.

17. 4
b. Critique de l’existant:
Durant la phase de l’étude de l’existant, nous avons détecté les anomalies suivantes :
o Absence d’un moyen de recherche rapide pour chercher une fiche, la secrétaire doit
faire une recherche manuelle fiche par fiche par nom de patient ce qui entraîne une
perte de temps.
o La gestion du rendez-vous se fait d’une manière manuelle ce qui provoque le risque
d’oublier ou de chevauchement des rendez-vous.
o Probabilité de perte de documentation.
o Pas de possibilité du partage des dossiers médicaux entre médecins.
c. Solution proposée :
o Pour palier aux problèmes cités ci-dessous, nous allons proposer un outil qui permettra
d’automatiser le processus de soins. ATH Consulting nous a proposé comme sujet de
projet de fin d’études de développer une plate-forme destinée à un médecin cardiologue
que nous envisageons intégrer dans l’outil l’OpenMRS. L’outil développé permettra
de standardiser les traitements médicaux et le partage électronique des données de
santé. En outre, il permettra aussi d’assurer la confidentialité des données
personnelles.
II. L’état de l’art :
1. OpenMRS :
Le système de gestion de dossier médical (OpenMRS) a été introduit en 2004 en tant que
plate-forme de système de gestion dossier médical open source destiné aux pays en
développement.
OpenMRS est soutenu par des équipes centrales de partenaires in Health, Regenstrief
Institue. [1]
Mission :
La mission d’OpenMRS est d’améliorer la prestation des soins de santé dans des
environnements aux ressources limitées en coordonnant une communauté mondiale qui crée
une robuste, évolutive, axée l’utilisateur, open source plate-forme de système de dossier
médical. [2]
Il existe d’autres outils similaires à OpenMRS dont on peut citer CliniSys :
CliniSys constitue un ensemble de solutions de gestion administrative et médicale qui
couvrent les différentes activités des établissements de santé, conçu avec une équipe
d’informaticiens et de professionnels de santé, et offre un haut degré d’adaptation selon la

18. 5
spécialité et l’organisation de chaque établissement. CliniSys est installée actuellement dans
la majorité des polycliniques en Tunisie. [3]
2. Critique :
CliniSys est un logiciel médical utilisé dans la majorité de polycliniques. Il permet
d’échanger des informations de santé et des dossiers médicaux à l’intérieur de
polyclinique mais le problème est qu’on ne peut pas échanger l’information de santé ni le
dossier médical à l’extérieure d’une clinique.
Ce problème est résolu par le logiciel nommé l’OpenMRS.
III. Méthode de modélisation et de conception :
1. Méthode agile :
« Les méthodes agiles sont des méthodologies essentiellement dédiées à la gestion des
projets informatiques. Elles reposent sur des cycles de développement itératifs et
adaptatifs en fonction des besoins évolutifs du client. Elles permettent notamment
d'impliquer l'ensemble des collaborateurs ainsi que le client dans le développement du
projet. » [4]
Les quatre utilités fondamentales agiles :
• L’interaction entre acteurs plutôt que les processus et les outils.
• Un produit opérationnel plutôt qu’une documentation pléthorique.
• La collaboration avec le client plutôt que la négociation du contrat.
• La réactivité face au changement plutôt que le suivi d'un plan. [5]
Les 12 principes de méthodes agiles :
1- Satisfaire le client en livrant tôt et régulièrement des logiciels utiles qui offrent une
véritable valeur ajoutée
2-Accepter le changement même tard dans le développement
3-Livrer fréquemment une application qui fonctionne
4-Collaborer quotidiennement entre clients et développeurs
5- Bâtir le projet autour des personnes motivées en leur fournissant
environnement et support et en leur faisant confiance

19. 6
6-Communiquer par des conversations en face à face
7-Mesurer la progression avec le logiciel qui fonctionne
8-Garder un rythme de travail durable
9-Rechercher l’excellence technique et la qualité de la conception
10-Laisser l’équipe s’auto-organiser
11-Rechercher la simplicité
12-A intervalles réguliers, réfléchir aux moyens de devenir plus efficaces. [5]
Les principales méthodes agiles :
Nous différencions surtout :
 SCRUM
 Extreme Programming (XP)
 Adaptive Software Development (ASD)
 Crystal Clear
Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases,
nous avons opté SCRUM comme une méthodologie de conception et du développement.
2. SCRUM :
Le SCRUM est une méthode de gestion de projet .Elle a pour but d’améliorer la productivité
des équipes. Ce terme est inspiré du terme Scrum en rugby qui désigne une mêlée. C’est une
technique de reprise du jeu après faute qui permet une équipe sur des bons rails par un effort
collectif. Cette méthode a été principalement conçue pour le développement des logiciels
informatiques. [6]
Figure2 : Scrum en rugby

20. 7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]
7
Pourquoi SCRUM :
La méthodologie SCRUM est le moyen parfait de communication entre les différents
membres du projet pour constater le progrès du projet, et permettre de savoir les
difficultés rencontrées par les différentes parties.
Scrum permet aussi de minimiser le temps sur les tâches en elles-mêmes.
Donc scrum est une méthode complète .Elle se concentre sur la qualité, les objectifs,
l'efficacité, la réduction du temps et sur la communication excellente entre les divers
acteurs du projet.
Le principe de base de SCRUM est :
 Dégager dans un premier temps le maximum des fonctionnalités pour former le
backlog du produit.
 Présenter dans un deuxième temps les priorités des fonctionnalités et déterminer
lesquelles seront réalisé dans chaque itération.
 Par la suite, concentrer l’équipe de façon itérative sur l’ensemble de fonctionnalités à
réaliser, dans des itérations nommées Sprints.
 Le Sprint conduit à la livraison d’un produit partiel fonctionnel nommé incrément.
Figure3: Le processus SCRUM
Les acteurs SCRUM :
 Le Product Owner :
Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe
de développement. [7]
Le Product Owner est la seule personne responsable de gérer Product backlog. [7]

21. 8
 Le Scrum master :
Le Scrum master est un leader au service de l’équipe SCRUM. Il aide tout le monde à changer
ces interactions pour maximiser la valeur créée par l’équipe SCRUM.
Le Scrum Master remplit leur rôle en s’assurant que l’équipe SCRUM adhère à la théorie aux
pratiques et aux règles de Scrum. [7]
 L’équipe de développement (Team) :
C’est l’équipe qui participe au projet. Elle est constituée de professionnels qui livrent à
chaque sprint un incrément « terminé » et potentiellement livrable du produit.
Ces équipes sont structurées par l’entreprise à organiser et gérer leur propre travail. [7]
Les artéfacts de Scrum :
Les artéfacts de Scrum sont conçus principalement pour maximiser la transparence
d’informations et des opportunités pour l’adaptation.
 Le Product Backlog : (Carnet de produit)
Ensemble des fonctionnalités (User Story) qui constitue le produit souhaité. Il doit être
priorisé pour permettre de développer les éléments de plus haute importance en
premier. [8]
 Le Sprint Backlog : (Carnet d’itération)
Sous-ensemble des éléments du Backlog de produit. Les éléments constituent les user
stories à développer au cours du sprint et sont préalablement détaillés pour pouvoir
être estimés par l’équipe de développement. Il est également priorisé.
 Burndown Charts : (Graphique d’avancement) :
Le Burndown Chart est un diagramme qui permet de visualiser l’avancement des
sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des
tâches en cours dans le Sprint. [9]
Il possède en abscisse le temps et en ordonnée les points d’histoire.
Planification d’un projet par Scrum :
 Sprint Planning : (Planification d’itération)
Le Sprint Planning permet de définir le Sprint Backlog.
Le Sprint Backlog est un sous-ensemble du Product Backlog.
Le Sprint Backlog correspond à un accord mutuel entre le product Owner et l’équipe
mais c’est le Product Owner qui décidé. [10]
 Daily Scrum Meeting (Mêlée quotidienne) :
La Mêlée Quotidienne (Daily Scrum) est l’un des premiers d’inspection et
d’adaptation dans Scrum. L’équipe de développement communique pour synchroniser
ses travaux et créer un plan pour les prochaines 24 heures. [11]

22. 9
 Sprint Review (Revue d'itération):
La revue de Sprint est un évènement qui regroupe de nombreuses parties prenantes et
personnes expérimentées. Les revues de Sprint ont de nombreux résultats possibles, y compris
l’arrêt du projet. Dans la plupart des cas, l’Équipe est autorisée à commencer un autre Sprint.
Il me semble que les équipes matures peuvent déjà établir le but de leur prochain Sprint lors
de cette Revue. Elles trouvent que cela aide à maintenir le rythme d’un Sprint à l’autre.
L’objectif de la revue de sprint est le produit que l’Équipe a construit. [11]
 Rétrospective de sprint :
La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de
planification de sprint. C’est une réunion limitée à trois heures pour les sprints d’un mois.
Pour les Sprints moins longs, la réunion dure habituellement moins longtemps. Le Scrum
Master s’assure que la réunion a eu lieu et que les participants en comprennent le but. [7]
IV. Langage de modélisation UML (Unified Modeling Language) :
« UNIFIED MODELING LANGUAGE » UML se définit comme un langage de
modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et
documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et
communiquer des points de vue.
UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit d’une simple
notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont
porteurs de sens au même titre que les mots d’un langage. [12]
Conclusion :
Au cours de ce chapitre, nous avons présenté l’organisme d’accueil « ATH Consulting ».
Ensuite, nous avons établi l’étude de l’existant qui nous a permis de mieux comprendre la
problématique afin de trouver la solution adéquate.
Enfin, nous avons opté pour le choix de la méthode de travail utilisée SCRUM. Nous avons
aussi présenté brièvement le langage de modélisation UML qui sera utilisé pour
l’élaboration des différents diagrammes de conception.

23. 10
Chapitre II : Planification et Architecture
Introduction :
Dans ce chapitre, nous allons présenter les acteurs et leurs rôles, ainsi que les besoins
fonctionnels et les besoins non fonctionnels. Ensuite, nous identifierons l’équipe de SCRUM
et son rôle, par la suite nous décrivons le Backlog du produit. Enfin, nous présenterons la
planification des releases.
I. Capture des besoins :
La spécification des besoins représente la première phase du cycle de développement
d’un logiciel.
Elle sert à identifier les acteurs réactifs du système.
1. Identification des acteurs :
« Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositifs matériels ou autre système) qui interagit directement avec le système
étudié. »[12]
Les acteurs de notre système sont :
 La secrétaire : qui peut gérer les rendez-vous des patients et créer les fiches patients.
 Le médecin : peut créer les dossiers médicaux, générer des ordonnances patients et
planifier les activités faites la secrétaire.
 Administrateur : qui peut ajouter ou bien modifier ou supprimer un utilisateur
2. Analyse des besoins fonctionnels :
 Générer le site : l’administrateur peut accéder à une plate-forme et peut ajouter
ou modifier ou éliminer un utilisateur.
 Gérer les rendez-vous :
o La prise du rendez-vous s’effectue directement ou via notre
plate-forme en précisant la date, l’heure, le nom et le prénom
du patient selon la disponibilité du médecin.
 Gérer le patient :
o la secrétaire remplit les informations du patient.
o Les observations médicales notées par le médecin qui
doivent comprendre les antécédents du patient.
 Gérer consultation : c’est le médecin qui se charge de l’enregistrement des
ordonnances, des différents diagnostics, des antécédents (personnels, antécédents

24. 11
familiaux), les données anthropométriques, ainsi que les examens (examens
physiques, examens complémentaires…).
 Gérer l’ordonnance : permet au médecin d’ajouter, de consulter ou bien
supprimer une ordonnance.
 Gérer le dossier médical :
o le dossier médical comprend l’historique des interventions
médicales subis par les patients (les médicaments qui lui ont
été prescrits, les résultats d’analyse, les antécédents
familiaux…)
3. Analyse des besoins non fonctionnels :
 Ergonomie : l’application doit offrir une interface conviviale exploitable par
l’utilisateur simple dans l’utilisation.
 Rapidité : le temps du chargement d’une page demandée par l’utilisateur ne
doit pas prendre plus que 30 secondes.
 Disponibilité : possibilité d’accès à l’application et à n’importe quelle
information 24h/24h et 7j/7j sauf en période de maintenance
 Sécurité et la confidentialité : l’accès à l’application doivent être sécurisé par
le login et le mot de passe.
II. Structure et découpage du projet :
1. Identification de l’équipe SCRUM :
L’équipe a un rôle capital dans Scrum : elle permet d’optimiser la flexibilité, la
créativité et la productivité. Elle doit s’auto-organiser en choisit la meilleure façon
d’accomplir le travail. Elle doit avoir toutes les compétences nécessaires au
développement du produit.
Scrum définit trois rôles qui sont :
Le Product Owner (le propriétaire du produit : M.Izhar mahjoub): c’est la
personne qui a une vision du produit à accomplir, usuellement, c’est un expert dans
le domaine.
Le Scrum Master (le directeur du produit : M. Mohamed Ktari): c’est la personne
qui doit étayer le bon déroulement des différents sprints d’une release.
Le Scrum Team (l’équipe de Scrum : Soumaya &Ibtissem) : représenté par les
personnes qui sont chargées d’implémenter les besoins du client.
2. Le backlog du produit : c’est l’ensemble de fonctionnalités (User Story) du
produit que l’on veut développer comme nous avons déjà présenté.
Un User Story s’écrit comme suit :

25. 12
- En tant que < utilisateur>
- Je désire < fonctionnalité>
- Pour pouvoir < résultat>
Pour chaque User Story on présente le rang, l’estimation, l’importance et la description
comme illustrée dans le tableau suivant :
ID En tant que Je désire Pour pouvoir Importance
1 Utilisateur +
administrateur
S’authentifier Accéder à la plate-
forme
+++
2 Administrateur Gérer les utilisateurs
de la plate-forme
Ajouter, modifier
et supprimer un
utilisateur
++++
3 Secrétaire Gérer le rendez-vous
et les patients
Pour planifier la
liste des rendez-
vous et pouvoir
ajouter, modifier et
supprimer des
patients
+++
4 Médecin Gérer consultation et
le dossier médical
Actualiser les
informations
existantes et
ajouter le résumé
de chaque
consultation, ainsi
que peut consulter
le dossier médical
+++++
Tableau 1: tableau de backlog initial
3. Planification des releases :
Un release correspond à la livraison d'une version. Par habitude, on parle de release pour
considérer la période du temps qui va du début du travail sur cette version jusqu'à sa livraison
et qui passe par une série de sprints successifs. [12]
La réunion de planification des releases est l’évènement le plus important dans Scrum.
L’objectif de cette réunion est de faire le planning de travail et d’identifier le backlog des
releases.
Tous les projets nécessitent des plans, afin de prévoir à peu près ce que va contenir un produit
ou à quelle date il sortira sur le marché.
Selon la méthodologie agile Scrum, la planification de releases aux mêmes points visés
puisqu’elle donne à l’équipe et aux parties prenantes des informations sur le contenu des
sprints constituant la release.

26. 13
Figure 4: exemple de plan de release
4. Diagramme du cas d’utilisation global :
Figure 5 : diagramme du cas d’utilisation global
Conclusion :
Dans ce chapitre, nous avons identifié le rôle de chaque acteur en le représentant dans le
diagramme du cas d’utilisation global. Nous avons aussi présenté l’équipe du projet et défini
notre backlog du produit en nous basant sur les besoins fonctionnels et non fonctionnels.
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
sécretaire
médecin
administrateur
gérer patient
gérer rendez-vous
gérer consultation
gérer dossier
médical
gérer les utilisateurs
s'authentifier

27. 14
Chapitre III : Sprint 1 : Gestion de personnel
Introduction :
Le sprint s’exprime comme un cœur de scrum. Il s’agit d’une unité du temps durant
laquelle un incrément du produit sera réalisé.
Dans ce chapitre, nous allons présenter le premier sprint.
I. Spécification des besoins :
Au sein de ce sprint, les users stories vont appliquer les quatre étapes du cycle scrum,
analyse, conception, développement et les tests.
1. Le sprint backlog :
Durant le premier chapitre, le sprint backlog est présent au cours de la réunion de
planification : il s’agit d’une série des tâches que l’équipe scrum doit réaliser durant le sprint
dans l’objectif d’arriver à la réalisation de la tâche au bout du temps escompté afin de
pouvoir enchaînée sur le sprint suivant.
Le tableau suivant présent toutes les fonctionnalités qui seront développées de ce sprint :
ID
U.S
User Story ID
tâche
Tâche Affectation
1 En tant qu’utilisateur
et administrateur, je
veux « authentifier»
1.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse, de
séquence détaillée du cas
« s’authentifier »
Soumaya
Nebli
2 En tant
qu’administrateur je
veux « gérer les
utilisateurs »
2.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée
«ajouter utilisateur »
Soumaya
Nebli
2.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence
détaillée «modifier utilisateur »
Soumaya
Nebli
2.3 Réaliser le diagramme du cas Soumaya

28. 15
d’utilisation, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence, diagramme
de séquence détaillée « supprimer
utilisateur »
Nebli
3 En tant qu’utilisateur
je veux gérer
« rendez-vous »
3.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « ajouter un rendez-vous »
Soumaya
Nebli
3.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas «modifier un rendez-vous »
Soumaya
nebli
3.3 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas «supprimer un rendez-vous »
Ibtissem
Slimeni
4 En tant qu’utilisateur
je veux « gérer la
fiche du patient »
4.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « ajouter fiche patient »
Ibtissem
Slimeni
4.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « modifier fiche patient »
Ibtissem
Slimeni
4.3 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence, la traçabilité entre
diagramme du cas d’utilisation et
diagramme de classes d’analyse,
diagramme de séquence détaillée du
cas « supprimer fiche patient »
Tableau 2: Backlog du premier sprint

29. 16
II. Diagramme des cas d’utilisation du premier Sprint :
Au début de chaque itération, nous allons schématiser la spécification fonctionnelle
par un diagramme du cas d’utilisation. Celle-ci servira comme une vue d’ensemble du
système et présentera les liens et les interactions entre les utilisateurs et les
fonctionnalités.
1. Classification des cas d’utilisation par acteur :
Ce tableau englobe les acteurs par leurs fonctionnalités :
Acteur Cas d’utilisation
Administrateur
Secrétaire
Médecin
 ajouter utilisateur
 modifier utilisateur
 supprimer utilisateur
 ajouter rendez-vous
 modifier rendez-vous
 supprimer rendez-vous
 ajouter patient
 modifier patient
 supprimer patient
Tableau 3: classification des cas d'utilisation par acteur
2. Diagramme du cas d’utilisation du premier sprint:
L’administrateur peut accéder à la plate-forme en utilisant un login et un mot de passe pour
ajouter, modifier et supprimer un utilisateur. Comme présenté dans la figure suivante:
Figure 6 : diagramme du cas d’utilisation du premier sprint
<<include>>
adminstrateur gérer les utilisateurs
ajouter user
modifier user
s'authentifier
supprimer user

30. 17
III. Analyse des cas d’utilisation :
1. Analyse du cas « s’authentifier » :
1.1. Description textuelle du cas d’utilisation « s’authentifier » :
CU : s’authentifier
Acteur : administrateur et utilisateur (médecin, secrétaire)
Pré-condition :l’utilisateur doit être dans la base de données et possède des identifiants.
Post-condition : la première interface de l’application affichée
Scénario nominal : 1. L’utilisateur demande l’interface d’authentification.
2. Le système affiche l’interface demandée.
3. L’utilisateur saisit login et mot de passe.
4. Le système vérifie les informations saisies par l’utilisateur.
5. Le système affiche l’interface demandée.
Scénario alternatif : 4.1. l’utilisateur n’a pas saisi le bon paramètre d’authentification
4.2. l’utilisateur n’existe pas dans la base de données
Tableau 4: description textuelle du cas «S’authentifier»
1.2. Diagramme de séquence système du cas « S’authentifier » :
Chaque utilisateur doit s’authentifier, en créant son login et son mot de passe et sa catégorie
pour accéder à sa plate-forme. Le système affiche un message en cas d’erreur.
Figure 7 : Diagramme de séquence système du cas « S’authentifier »
s'authentifier
saisir login et mot de passe
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface demandée
vérifier
utilisateur
système
données invalides
données valides
alt
loop
saisir login et mot de passe
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface demandée
vérifier

31. 18
2. Analyse du cas « gérer les utilisateurs» :
Administrateur peut accéder à la plate-forme, le système affiche les listes de fonctionnalités
qui permettent de l’utilisateur de choisir l’une des fonctionnalités « ajouter » ou « modifier »
ou « supprimer » utilisateurs :
2.1. Description textuelle cas d’utilisation « ajouter utilisateur » :
Cu Ajouter utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Utilisateur ajouté
Scénario nominal 1. L’administrateur clique sur ajouter utilisateur
2. Le système affiche le formulaire
3. L’administrateur remplit le formulaire
4. Le système vérifie
5. Le système enregistre le nouvel utilisateur
6. Le système affiche utilisateur ajouté
Scénario alternatif 4.1 donnée manquante
Tableau 5: description textuelle du cas «ajouter utilisateur»
2.2. Diagramme de séquence système du cas «ajouter utilisateur» :
La figure 8 illustre le diagramme de séquence du premier cas dans notre sprint.
L’administrateur doit s’authentifie avec son login et son mot de passe afin d’ajouter un
utilisateur à sa plate-forme. Si les champs sont remplis, le système affiche un message de
succès ou il affiche un message de retour à l’interface précédente.
Figure 8 : Diagramme de séquence système du cas « ajouter utilisateur »
ajouter user
afficher utilisateur ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ajouter utilisateur
administrateur
systéme
ref
s'authentifier()
données invalides
données valides
alt
afficher utilisateur ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ajouter utilisateur

32. 19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»
19
2.3. Description textuelle cas d’utilisation «modifier utilisateur» :
Cu Modifier utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Modification enregistrée
Scénario nominal 1. L’administrateur choisit l’utilisateur à modifier
2. Le système affiche le formulaire de modification
3. L’administrateur saisit la nouvelle donnée
4. Le système vérifie et enregistre la modification
5. Le système affiche la nouvelle donnée
Scénario alternatif 4.1 donnée manquante
Tableau 6 : Description textuelle du cas « modifier utilisateur»
2.4. Diagramme de séquence système du cas « modifier utilisateur» :
La figure 9 illustre le diagramme de séquence du premier cas. L’administrateur peut accéder
à sa plate-forme afin de modifier l’utilisateur.
Figure 9 : Diagramme de séquence système du cas « modifier utilisateur»

33. 20
2.5. Description textuelle du cas d’utilisation «supprimer utilisateur» :
Cu Supprimer utilisateur
Acteur Administrateur
Pré- condition S’authentifier
Post –condition Utilisateur supprimé
Scénario nominal 1. L’administrateur choisit l’utilisateur qu’il veut supprimer
2. Le système supprime l’utilisateur sélectionné
3. Le système affiche la suppression effectuée
Scénario alternatif Aucune
Tableau 7 : Description textuelle du cas « supprimer utilisateur »
2.6. Diagramme de séquence système du cas «supprimer utilisateur» :
L’administrateur a aussi le droit de supprimer un ou plusieurs utilisateurs.
Figure10 : Diagramme de séquence système du cas « supprimer utilisateur»
3. Analyse du cas «gérer rendez-vous» :
3.1. Diagramme du cas d’utilisation « gérer rendez-vous » :
L’utilisateur peut gérer un rendez-vous en ajoutant, modifiant ou annulant ce dernier.
Figure11 : Diagramme du cas d’utilisation « gérer rendez-vous »
supprimer user
supprimer
afficher utilisateur supprimer
cliquer sur supprimer
adminstrateur
systeme
ref
s'authentifier()
supprimer
afficher utilisateur supprimer
cliquer sur supprimer
<<include>>
secrétaire
gérer rendez-vous
ajouter rendez-vous
modifier rendez-vous
supprimer rendez vous
s'authentifier

34. 21
3.2. Description textuelle cas d’utilisation « ajouter rendez-vous» :
CU : gérer le rendez-vous : ajouter
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous ajouté
Scénario nominal :
1. l’utilisateur clique sur gérer rendez-vous
2. le système affiche le formulaire de rendez-vous
3. l’utilisateur remplit le formulaire présenté
4. le système vérifie si tous les champs remplis
5. le système affiche un message « rendez-vous ajouté »
Scénario alternatif : 4.1. le rendez- vous invalide
Tableau 8: description textuelle du cas « ajouter un rendez-vous »
3.3. Diagramme de séquence système du cas « ajouter rendez-vous» :
La figure 12 illustre le diagramme de séquence qui consiste à ajouter un rendez-vous. Si le
patient existe déjà, le système affiche un message d’erreur.
Figure12 : Diagramme de séquence système du cas « ajouter un rendez-vous »
ajouter rendez-vous
ajouter
vérifier
affiche le formulaire
remplir le formulaire présenté
rendez-vous ajouté
retour vers le formulaire
cliquer sur gérer le rendez-vous
utilisateur
système
ref
s'authentifier()
rendez-vous invalide
rendez-vous valide
alt
ajouter
vérifier
affiche le formulaire
remplir le formulaire présenté
rendez-vous ajouté
retour vers le formulaire
cliquer sur gérer le rendez-vous

35. 22
3.4. Description textuelle cas d’utilisation « modifier un rendez-vous» :
CU : gérer le rendez-vous : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous modifié
Scénario nominal :
1. l’utilisateur clique sur gérer rendez-vous
2. le système affiche les listes de rendez-vous
3. l’utilisateur choisir le rendez-vous à modifier
4. le système affiche le formulaire
5. l’utilisateur saisit les nouvelles données
6. le système vérifie les champs remplis
7. l e système affiche un message « rendez-vous modifié »
Scénario alternatif : 6.1 : le rendez-vous réservé
Tableau 9 : Description textuelle du cas « modifier un rendez-vous »
3.5. Diagramme de séquence système du cas «modifier rendez-vous» :
La figure 13 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un ou
plusieurs rendez-vous. Si le rendez-vous n’est pas réservé, le système modifié le rendez-vous
sinon retour vers le formulaire.
Figure 13 : Diagramme de séquence système du cas « modifier un rendez-vous »
modifier rendez-vous
modifier
vérifier
saisir les nouvelles données
afficher le formulaire
rendez vous modifié
retour vers le formulaire
choisir le rendez-vous à modifier
afficher la liste du rendez-vous
cliquer sur gérer le rendez-vous
utilisateur
système
ref
s'authentifier()
rendez-vous invalide
rendez-vous valide
alt
modifier
vérifier
saisir les nouvelles données
afficher le formulaire
rendez vous modifié
retour vers le formulaire
choisir le rendez-vous à modifier
afficher la liste du rendez-vous
cliquer sur gérer le rendez-vous

36. 23
3.6. Description textuelle cas d’utilisation « supprimer un rendez-vous» :
CU : rendez-vous : supprimer
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : rendez-vous supprimé
Scénario nominal :
1. l’utilisateur clique sur gérer le rendez-vous
2. le système affiche une liste de rendez-vous
3. l’utilisateur sélectionne le rendez-vous à supprimer
4. le système supprimer le rendez-vous
Scénario alternatif : aucun
Tableau 10 : Description textuelle du cas « supprimer un rendez-vous »
3.7. Diagramme de séquence système du cas « supprimer rendez-vous» :
La figure 14 illustre le diagramme de séquence qui permet à l’administrateur du supprimer
les rendez-vous.
Figure14 : Diagramme de séquence système du cas «supprimer un rendez-vous »
4. Analyse du cas «gérer fiche patient» :
L’utilisateur clique sur la rubrique fiche patient, le système affiche un formulaire à
remplir qui permet à l’utilisateur d’ajouter, modifier ou supprimer un patient.
supprimer rendez vous
supprimer
cliquer sur gérer le rendez-vous
afficher la liste du rendez-vous
sélectionner le rendez-vous à supprimer
afficher le rendez-vous supprimé
utilisateur
système
ref
s'authentifier()
supprimer
cliquer sur gérer le rendez-vous
afficher la liste du rendez-vous
sélectionner le rendez-vous à supprimer
afficher le rendez-vous supprimé

37. 24
4.1. Classification du cas d’utilisation «gérer patient » :
Figure 15 : diagramme du cas d’utilisation « gérer patient »
4.2. Description textuelle cas d’utilisation « ajouter patient » :
CU : gérer le patient: ajouter
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient ajouté
Scénario nominal :
1. l’utilisateur clique sur ajouter patient
2. le système affiche l’interface demandée
3. l’utilisateur remplit le formulaire du patient
4. le système vérifie les champs et l’existence de patient
5. le système enregistre le nouveau patient
6. le système affiche patient enregistré
Scénario alternatif : 4.1 les champs ne sont pas bien remplis
5.1 le patient existe déjà dans la base
Tableau 11 : Description textuelle du cas « ajouter patient »
<<include>>
Secrétaire
gérer patient
ajouter patient
modifier patient
s'authentifier
supprimer patient

38. 25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »
25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »
25
4.3. Diagramme de séquence système du cas « ajouter patient » :
La figure 16 illustre le diagramme de séquence qui permet à l’utilisateur d’ajouter un patient.
Figure16 : Diagramme de séquence système du cas « ajouter patient »
4.4. Description textuelle cas d’utilisation « modifier le patient » :
CU : gérer le patient : modifier
Acteur : médecin, secrétaire
Pré-condition : s’authentifier
Post-condition : patient modifié
Scénario nominal :
1. l’utilisateur clique sur fiche patient
2. le system affiche la liste du patient enregistré
3. l’utilisateur sélectionne le patient à modifier
4. le système affiche la fiche du patient
5. l’utilisateur saisit les nouvelles données
6. le système enregistre la modification
7. le système affiche la nouvelle donnée
Scénario alternatif : 4.1 le patient n’est pas enregistré.
Tableau 12 : Description textuelle du cas « modifier patient »

39. 26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »
26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »
26
4.5. Diagramme de séquence système du cas « modifier patient » :
La figure 17 illustre le diagramme de séquence qui permet à l’utilisateur de modifier un
patient.
Figure 17 : Diagramme de séquence système du cas « modifier patient »
4.6. Description textuelle du cas « supprimer patient » :
Cu Supprimer patient
Acteur Utilisateur (secrétaire, médecin)
Pré- condition S’authentifier
Post –condition Patient supprimé
Scénario nominal 1. l’utilisateur clique sur fiche patient
2. le système affiche liste du patient
3. Utilisateur sélectionne le patient à supprimer
4. Le système supprime le patient sélectionné
5. Le système afficher suppression effectuée
Scénario alternatif Aucun
Tableau 13 : Description textuelle du cas « supprimer patient »

40. 27
4.7. Diagramme de séquence système du cas « supprimer patient » :
Figure 18 : Diagramme de séquence système du cas « supprimer patient »
IV. Conception des cas d’utilisation :
Nous allons préparer les diagrammes Traçabilité entre le modèle de cas
d’utilisation et le modèle d’analyse du cas d’utilisation pour passer aux
diagrammes des séquences détaillés et les diagrammes des classes d’objets du
premier sprint.
1. Modèle d’analyse du cas d’utilisation «s’authentifier» :
1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « s’authentifier » :
Figure 19: Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation du cas « S'authentifier »
supprimer patient
supprimer
sélectionner le patient à supprimer
afficher liste du patient
cliquer sur fiche patient
afficher patient supprimé
utilisateur
système
supprimer
sélectionner le patient à supprimer
afficher liste du patient
cliquer sur fiche patient
afficher patient supprimé
<<trace>>
<participate><participate><participate>
utilisateur
s'authentifier
S'authentifier
contrôleur login user profil
interface autherntificationadministrateur

41. 28
1.2 Modèle de classe d’analyse d’utilisation « s’authentifier » :
Figure20 : modèle de classe d’analyse d’utilisation « s’authentifier »
1.3 Diagramme de séquence détaillé du cas d’utilisation « s’authentifier » :
Figure 21: diagramme de séquence détaillé du cas « S'authentifier »
uti l i sateur i nterface authenti fi cati on
contrôl eur l ogi n
user profi l
s'authentifier
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface d'accueil
vérifier
envoyer les données
saisir login et mot de passe
utilisateur interface _s'authentifier s'authentifier user profilinterface d'accueil
login ou mot de passe incorrect
login ou mot de passe correct
alt
loop
afficher l'interface demandée
demander l'interface d'authentification
retour vers l'interface authentification
afficher l'interface d'accueil
vérifier
envoyer les données
saisir login et mot de passe

42. 29
2. Modèle d’analyse du cas d’utilisation « générer le site» :
2.1. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter
utilisateur » :
Figure 22 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation «
ajouter utilisateur du cas « ajouter utilisateur »
2.2. Modèle de classe d’analyse d’utilisation « ajouter utilisateur» :
Figure23: modèle de classe d’analyse d’utilisation « ajouter utilisateur»
<<trace>>
<participate><participate><participate>
administrateur
ajouter utilisateur Ajouter utilisateur
contrôleur new user user profilinterface formulaire
adminsitrateur
interface formulaire
contrôleur new useruser profil

43. 30
2.3. Diagramme de séquence détaillé du cas d’utilisation « ajouter utilisateur» :
Figure 24 : Diagramme de séquence détaillée du cas « ajouter utilisateur »
2.4. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation
« modifier utilisateur » :
Figure25 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation
« modifier utilisateur »
2.5. Modèle de classe d’analyse d’utilisation « modifier utilisateur» :
Figure 26 : Modèle de classe d’analyse d’utilisation « modifier utilisateur»
ajouter user
afficher utilisateur ajouté
réponse
retour vers formulaire
envoyer données
envoyer le formulaire
envoyer la demande
demander l'interface d'ajout
ajouter
vérifier
remplir le formulaire
administrateur Interface utilisateur e_utilisateurc_new user
ref
s'authentifier()
données manquantes
données remplis
alt
afficher utilisateur ajouté
réponse
retour vers formulaire
envoyer données
envoyer le formulaire
envoyer la demande
demander l'interface d'ajout
ajouter
vérifier
remplir le formulaire
<<trace>>
<participate>
<participate><participate>
administrateur
modifier
utilisateur
Modifier utilisateur
contrôleur edit user
user profilinterface modification
adm i nsi trateur
i nterface m odi fi cati on
contrôl eur edi t user
user profi l

44. 31
2.6. Diagramme de séquence détaillé du cas d’utilisation « modifier utilisateur» :
Figure 27 : Diagramme de séquence détaillée du cas « modifier utilisateur »
2.7. Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation «
supprimer utilisateur» :
Figure 28 : Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation du
cas « supprimer utilisateur »
modifier user
modifier
afficher nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher le formulaire de modification
réponse
vérifier
sélectionner sur l' utilisateur à modifier
envoyer la demande
administrateur Interface utilisateur user profilcontrôleur liste utilisateur
ref
s'authentifier()
données manquantes
données remplis
alt
modifier
afficher nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher le formulaire de modification
réponse
vérifier
sélectionner sur l' utilisateur à modifier
envoyer la demande
<<trace>>
<participate><participate><participate>
administrateur
supprimer
utilisateur
Supprimer
utilisateur
contrôleur liste
utilisateur
user profilinterface liste utilisateur

45. 32
2.8. Modèle de classe d’analyse d’utilisation « supprimer utilisateur» :
Figure 29 : Modèle de classe d’analyse d’utilisation « supprimer utilisateur»
2.9. Diagramme de séquence détaillé du cas d’utilisation « supprimer utilisateur» :
Figure 30 : diagramme de séquence détaillée du cas « supprimer utilisateur »
3. Modèle d’analyse du cas d’utilisation «gérer le rendez-vous» :
3.1 .Traçabilité entre le modèle du cas et modèle d’analyse du cas d’utilisation « ajouter
rendez-vous » :
Figure 31 : Traçabilité entre le modèle du cas et modèle d’analyse du cas
d’utilisation « ajouter rendez-vous »
adminsitrateur
interface liste utilisateur
contrôleur liste
utilisateuruser profil
supprimer user
choisir l'utilisateur à supprimer
réponse
afficher utilisateur supprimé
envoyer requête
envoyer demande
administrateur I_liste_utilisateur e_utilisateurc_utilisateur
ref
s'authentifier()
choisir l'utilisateur à supprimer
réponse
afficher utilisateur supprimé
envoyer requête
envoyer demande
<<trace>>
<participate><participate><participate>
utilisateur
ajouter rendez-
vous
Ajouter Rendez-
vous
controlleur
rendez-vous
rednez-vous
interface rendez-vous

46. 33
3.2. Modèle de classe d’analyse d’utilisation «ajouter rendez-vous» :
Figure 32 : Modèle de classe d’analyse d’utilisation «ajouter rendez-vous »
3.3. Diagramme de séquence détaillé du cas d’utilisation « ajouter un rendez-vous» :
Figure 33: Diagramme de séquence détaillé du cas d’utilisation « ajouter rendez-vous»
utilisateur
interface rendez-vous
contrôleur
rendez-vous
rendez-vous
ajouter rdv detaille
rendez-vous ajouté
réponse
envoyer requête
retour vers formulaire
retour vers inetrface
vérifier
envoyer données
remplir formulaire
afficher la formulaire
demande l'interface d'ajouter
utilisateur I_rendez vous c_rendez vous e_rendez vous
ref
s'authentifier()
données manquantes
donner correcte
alt
rendez-vous réservé
pas de réservation
alt
rendez-vous ajouté
réponse
envoyer requête
retour vers formulaire
retour vers inetrface
vérifier
envoyer données
remplir formulaire
afficher la formulaire
demande l'interface d'ajouter

47. 34
3.4. Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« modifier rendez-vous » :
Figure34 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« modifier rendez-vous »
3.5. Modèle de classe d’analyse d’utilisation « modifier rendez-vous » :
Figure 35 : Modèle d’analyse d’utilisation « modifier rendez-vous »
<<trace>>
<participate>
<participate>
<participate>
utilisateur
modifier rendez-
vous
Modifier Rendez-
vous
contrôleur
rendez-vous
rendez-vousinterface modification
utilisateur
interface modifcation
contrôleur
rendez-vous
rendez-vous

48. 35
3.6. Diagramme de séquence détaillé du cas d’utilisation« modifier rendez-vous »
Figure 36 : Diagramme de séquence détaillé du cas « modifier rendez-vous »
3.7. Traçabilité entre modèles du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« supprimer rendez-vous » :
Figure 37 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« supprimer rendez-vous »
modifier rendez-vous
retour vers l'interface
vérifier
envoyer demande
réponse
modification
envoyer donnée
retour vers la formulaire
demander l'interface de modification
afficher le formulaire
saisir la nouvelle donnée
rendez vous modifié
utilisateur I_rendez vous c_rendez vous e_rendez vous
ref
s'authentifier()
données manquantes
donnée correcte
alt
réservation
pas de réservation
alt
retour vers l'interface
vérifier
envoyer demande
réponse
modification
envoyer donnée
retour vers la formulaire
demander l'interface de modification
afficher le formulaire
saisir la nouvelle donnée
rendez vous modifié
<<trace>>
<participate><participate>
<participate>
utilisateur
supprimer rendez
-vous
supprimer Rendez-
vous
contrôleur
rendez-vous
rendez-vousinterface liste
rendez-vous

49. 36
3.8. Modèle de classe d’analyse d’utilisation « supprimer rendez-vous » :
Figure 38 : Modèle de classe d’analyse d’utilisation « supprimer rendez-vous »
3.9. Diagramme de séquence détaillé du cas d’utilisation« supprimer un rendez-vous » :
Figure 39: Digramme de séquence détaillé du cas « supprimer rendez-vous »
uti l i sateur
i nterface l i ste
rendez-vous
contrôl eur
rendez-vous
rendez-vous
supprimer rendez-vous
choisir le rendez-vous à supprimer
afficher la liste du rendez-vous
réponse
rendez-vous supprimé
envoyer requête SQL
envoyer la demande
sélectionner le rendez-vous à suprimer
utilisateur I_liste rendez vous c_rendez vous e_rendez vous
ref
s'authentifier()
choisir le rendez-vous à supprimer
afficher la liste du rendez-vous
réponse
rendez-vous supprimé
envoyer requête SQL
envoyer la demande
sélectionner le rendez-vous à suprimer

50. 37
4. Modèle d’analyse du cas d’utilisation «gérer fiche patient» :
4.1. Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation« ajouter patient » :
Figure 40 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation : « ajouter patient »
4.2. Modèle de classe d’analyse d’utilisation « ajouter patient» :
Figure 41 : Modèle de classe d’analyse d’utilisation « ajouter patient»
<<trace>>
<participate><participate><participate>
utilisateur
ajouter patient Ajouter patient
contrôleur patient patientinterface fiche patient
utilisateur
interface fiche patient
contrôleur patientpatient

51. 38
4.3. Diagramme de séquence détaillé du cas d’utilisation « ajouter patient » :
Figure 42: Diagramme de séquence détaillé du cas « ajouter patient »
4.4. Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier patient » :
Figure 43: Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier patient »
ajouter patient
patient enregistré
réponse
envoyer requête
patient existe déjà
retour vers le formulaire
envoyer donnée
remplir le formulaire
afficher le formulaire
cliquer sur ajouter patient
vérifier
utilisateur interface fiche patient e_patientc_patient
ref
s'authentifier()
données manquantes
sinon
alt
patient existe
patient n'existe pas
alt
patient enregistré
réponse
envoyer requête
patient existe déjà
retour vers le formulaire
envoyer donnée
remplir le formulaire
afficher le formulaire
cliquer sur ajouter patient
vérifier
<<trace>>
<participate>
<participate><participate>
utilisateur
modifier patient
Modifier Patient
contrôleur patient patientinterface modification

52. 39
4.5. Modèle de classe d’analyse d’utilisation « modifier patient » :
Figure 44 : Modèle de classe d’analyse d’utilisation « modifier patient »
4.6. Diagramme de séquence détaillé du cas « modifier patient » :
Figure 45 : Diagramme de séquence détaillé du cas « modifier patient »
utilisateur
interface modification
contrôleur patientpatient
modifier patient
afficher la nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher fiche patient
vérifier
sélectionner le patient à modifier
envoyer requête
utilisateur I_fiche patient e_patientc_patient
ref
s'authentifier()
données manquantes
données remplis
alt
afficher la nouvelle donnée
réponse
retour vers formulaire
envoyer donnée
saisir nouvelle donnée
afficher fiche patient
vérifier
sélectionner le patient à modifier
envoyer requête

53. 40
4.7. Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer patient » :
Figure 46 : Traçabilité entre modèle du cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer patient »
4.8. Modèle de classe d’analyse d’utilisation « supprimer patient » :
Figure 47 : Modèle de classe d’analyse d’utilisation « supprimer patient »
<<trace>>
<participate><participate><participate>
utilisateur
supprimer patient supprimer Patient
contrôleur patient patientinterface fiche patient
uti l i sateur
i nterface l i st pati ent
contrôl eur pati entpati ent

54. 41
4.9. Diagramme de séquence détaillé du cas « supprimer patient » :
Figure 48 : Diagramme de séquence détaillé du cas « supprimer patient »
5. Diagramme de Classe globale du premier sprint :
La figure 49 illustre le diagramme de classe global de premier sprint.
La classe « user_profil » est liée à la classe « app_user» par une association plusieurs à
plusieurs et la classe « app_user » est liée à la classe « rendez-vous » par une association de 1
plusieurs et la classe « rendez-vous » est liée à la classe « patient » par une association 1 à
plusieurs.
Figure 49 : diagramme de classe globale du premier sprint
supprimer patient
patient supprimé
réponse
envoyer demande
sélectionner le patient à supprimer
envoyer requête
utilisateur i_liste patient e_patientc_patient
ref
s'authentifier()
patient supprimé
réponse
envoyer demande
sélectionner le patient à supprimer
envoyer requête
gérer
posséder
1..*
1..1
1..1
1..*
1..*
1..*
app_user
-
-
-
-
id user
login
mot de passe
id user profil
: int
: string
: String
: int
+ connecter ()
...
rendez-vous
-
-
-
-
Id rendez-vous
id patient
date
heure
: int
: int
: Date
: Date
+
+
+
ajouter ()
modifier ()
annuler ()
...
patient
-
-
-
-
-
-
-
id patient
nom
prénom
date de naissance
num tél
adresse
numéro dossier
: int
: String
: String
: Date
: int
: String
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
user_profil
-
-
id user profil
rôle
: int
: String
app_user_user_profil
-
-
id user
id user profil
: int
: int

55. 42
V. Codage :
La phase du codage consiste à implémenter « les user stories ».
Après avoir construit le diagramme de classe pour ce sprint en appliquant les règles du
passage vers le schéma logique de l’application, nous allons présenter le schéma de la base de
données suivant :
 Schéma de la base de données «app user»
Attribue Type Contrainte
Id user Int PRIMERY KEY
Login String
Mot passe String
Id user profil Int FRAIGERY KEY
Tableau 14: table «app user»
 Schéma de la base de données « user profil» :
Attribue Type Contrainte
User-profil-id Int PRIMERY KEY
Rôle String
Tableau 15: table «user profil»
 Schéma de la base de données «rendez-vous» :
Attribue Type Contrainte
Id Int PRIMERY KEY
Date Date
Heure Date
Id patient Int FRAIGERY KEY
Tableau 16 : table «rendez-vous»
 Schéma de la base de données «patient» :
Attribue Type Contrainte
Id Int PRIMERY KEY
Nom String
Prénom String
Date de naissance Date
Numéro de dossier Int
Numéro de tel Int
Adresse String
Tableau 17: table «patient »

56. 43
VI. Test :
Chaque sprint doit se terminer par la phase de test. Ces tests sont les seuls garants d’une
version de qualité, car ils permettent de valider les résultats acquis lors de l’étape de
développement.
 Interface authentification :
La figure 50 illustre l’interface d'authentification qui permet aux utilisateurs d'accéder à
l’application après avoir saisi un login et un mot passe.
Figure 50 : page d’authentification
 Interface secrétaire :
Les figures 51et 52 illustrent l’interface réservée à la secrétaire. En effet, cette dernière il a
l'accès seulement ou deux rubriques qui sont l'interface de rendez-vous et l'interface de
patient.
 Interface de patient :
La figure 51 permet aux utilisateurs (secrétaire médecin) d'ajouter, modifier ou
supprimer un ou plusieurs patients.
Figure 51 : page de la fiche patient
43
VI. Test :
Chaque sprint doit se terminer par la phase de test. Ces tests sont les seuls garants d’une
version de qualité, car ils permettent de valider les résultats acquis lors de l’étape de
développement.
 Interface authentification :
La figure 50 illustre l’interface d'authentification qui permet aux utilisateurs d'accéder à
l’application après avoir saisi un login et un mot passe.
Figure 50 : page d’authentification
 Interface secrétaire :
Les figures 51et 52 illustrent l’interface réservée à la secrétaire. En effet, cette dernière il a
l'accès seulement ou deux rubriques qui sont l'interface de rendez-vous et l'interface de
patient.
 Interface de patient :
La figure 51 permet aux utilisateurs (secrétaire médecin) d'ajouter, modifier ou
supprimer un ou plusieurs patients.
Figure 51 : page de la fiche patient
43
VI. Test :
Chaque sprint doit se terminer par la phase de test. Ces tests sont les seuls garants d’une
version de qualité, car ils permettent de valider les résultats acquis lors de l’étape de
développement.
 Interface authentification :
La figure 50 illustre l’interface d'authentification qui permet aux utilisateurs d'accéder à
l’application après avoir saisi un login et un mot passe.
Figure 50 : page d’authentification
 Interface secrétaire :
Les figures 51et 52 illustrent l’interface réservée à la secrétaire. En effet, cette dernière il a
l'accès seulement ou deux rubriques qui sont l'interface de rendez-vous et l'interface de
patient.
 Interface de patient :
La figure 51 permet aux utilisateurs (secrétaire médecin) d'ajouter, modifier ou
supprimer un ou plusieurs patients.
Figure 51 : page de la fiche patient

57. 44
 Interface de rendez-vous :
À partir de cette interface, l'utilisateur (secrétaire médecin) peut ajouter, modifier ou
bien supprimer un ou plusieurs rendez-vous.
Figure 52: page de rendez-vous
Conclusion :
Dans ce chapitre, nous avons réussi à réaliser, à analyser et à tester notre premier
sprint « gestion de personnel ».
Dans le prochain chapitre, nous allons détailler le sprint 2 du projet en passant par toutes les
étapes définies par scrum.
44
 Interface de rendez-vous :
À partir de cette interface, l'utilisateur (secrétaire médecin) peut ajouter, modifier ou
bien supprimer un ou plusieurs rendez-vous.
Figure 52: page de rendez-vous
Conclusion :
Dans ce chapitre, nous avons réussi à réaliser, à analyser et à tester notre premier
sprint « gestion de personnel ».
Dans le prochain chapitre, nous allons détailler le sprint 2 du projet en passant par toutes les
étapes définies par scrum.
44
 Interface de rendez-vous :
À partir de cette interface, l'utilisateur (secrétaire médecin) peut ajouter, modifier ou
bien supprimer un ou plusieurs rendez-vous.
Figure 52: page de rendez-vous
Conclusion :
Dans ce chapitre, nous avons réussi à réaliser, à analyser et à tester notre premier
sprint « gestion de personnel ».
Dans le prochain chapitre, nous allons détailler le sprint 2 du projet en passant par toutes les
étapes définies par scrum.

58. 45
Chapitre IV : Sprint 2 : Gérer la consultation et
l’ordonnance
Introduction :
Dans ce chapitre, nous allons décrire le deuxième sprint qui représente la phase la plus
importante de l’application.
Ainsi, nous allons commencer par expliquer « les user stories ».Ensuite, nous allons faire
une description des scénarios de chaque histoire d’utilisateur et une conception initiale du
module.
I. Spécification des besoins :
Au sein de ce sprint, les user stories vont appliquer les quatre étapes du cycle scrum.
1. Le sprint backlog :
Le tableau ci-dessous illustre le backlog de notre deuxième sprint.
ID user story User Story ID tâche Tâche Affectation
1 En tant que, médecin,
je veux « gérer la
consultation »
1.1 Réaliser les
diagrammes du cas
d’utilisation, de
séquence, la
traçabilité entre le
modèle de cas
d’utilisation et le
modèle d’analyse du
cas d’utilisation, de
séquence détaillée
du cas « choisir les
diagnostics »
Soumaya
Nebli
1.2 Réaliser les
diagrammes du cas
d’utilisation, de
séquence, la
traçabilité entre le
modèle de cas
d’utilisation et le
modèle d’analyse du
cas d’utilisation, de
séquence détaillée
du cas « gérer les
antécédents »
Ibtissem
slimeni

59. 46
1.3 Réaliser les
diagrammes du cas
d’utilisation, de
séquence, Traçabilité
entre le modèle de
cas d’utilisation et le
modèle d’analyse du
cas d’utilisation, de
séquence détaillée
du cas « gérer les
examens »
Soumaya
Nebli
1.4 Réaliser les
diagrammes du cas
d’utilisation, de
séquence, Traçabilité
entre le modèle de
cas d’utilisation et le
modèle d’analyse du
cas d’utilisation, de
séquence détaillée
du cas « gérer
données
anthropométriques »
Ibtissem
slimeni
1.5 Réaliser les
diagrammes du cas
d’utilisation, de
séquence, Traçabilité
entre le modèle de
cas d’utilisation et le
modèle d’analyse du
cas d’utilisation, de
séquence détaillée
du cas « gérer
ordonnance »
Soumaya
nebli
Tableau 18 : Backlog du deuxième Sprint
II. Diagramme du cas d’utilisation du deuxième sprint :
Dans cette section, nous allons déterminer les diagnostics, les antécédents, les types
examens, l’ordonnance et les données anthropométriques. En effet, nous allons regrouper
plusieurs « user stories ».

60. 47
1. Répartition des cas d’utilisation par acteur :
Acteur Cas d’utilisation
Médecin
 Ajouter diagnostic
 Modifier diagnostic
 Supprimer diagnostic
 Ajouter antécédents
 Modifier antécédent
 Supprimer antécédent
 Ajouter examen
 Modifier examen
 Supprimer examen
 Ajouter données anthropométriques
 Modifier données anthropométriques
 Supprimer données anthropométriques
 Ajouter ordonnance
 Consulter ordonnance
 Supprimer ordonnance
Tableau 19: tableau de répartition du deuxième sprint
2. Diagramme du cas d’utilisation du deuxième sprint :
La figure 53 illustre le diagramme du cas d’utilisation du deuxième cas dans notre sprint.
Le médecin effectue la consultation et l’ordonnance.
Figure 53: Diagramme du cas d’utilisation global du deuxième sprint
<<include>>
<<include>>
médecin
sécretaire
gérer diagnostic
gérer consultation
gérer ordonnance
gérer les examens
gérer les
antécédents
ajouterconsulter
s'authentifier
gérer données
anthropométriques
supprimer

61. 48
III. Analyse des cas d'utilisation :
1. analyse des cas d'utilisation «gérer la consultation» :
La consultation effectuée par le médecin, elle contient des données secrètes du patient. Elle
comporte les fonctionnalités suivantes : gérer les diagnostics, gérer les antécédents et gérer
les examens et gérer les données anthropométriques.
Figure 54: cas d’utilisation du cas « gérer la consultation »
1.1. Analyse du cas d’utilisation « choisir les diagnostics»:
Figure 55 : cas d’utilisation du cas « choisir les diagnostics»
1.2. Description textuelle du cas « ajouter diagnostics » :
CU ajouter diagnostic
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Diagnostic ajouté
Scénario nominal 1. Le médecin clique sur diagnostic
2. Le système affiche la liste de diagnostic
3. Le médecin remplit les champs et clique sur ajouter
4. Le système affiche le formulaire
5. Le système vérifie
6. Le système enregistre le diagnostic ajouté
Scénario alternatif 4.2. les champs ne sont pas remplis
Tableau 20 : Description textuelle du cas « ajouter diagnostics »
<<include>>
médecin
gérer diganostic
gérer antécédent
gérer examen
s'authentifier
gérer consultation
gérer données
anthropométriques
<<include>>
gérer les diagnostics s'authentifier
supprimermodifierajouter
médecin

62. 49
1.3. Diagramme de séquence système du cas « ajouter diagnostics » :
La figure 56 illustre le diagramme de séquence « ajouter diagnostic » associé au médecin qui
permet d’affecter un diagnostic dans la consultation ce qui peut être déterminé par la maladie
du patient.
Figure 56 : Diagramme de séquence système du cas « ajouter diagnostics »
1.4. Description textuelle du cas «modifier diagnostics » :
CU modifier diagnostic
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Diagnostic modifié
Scénario nominal
1. Le médecin clique sur diagnostic
2. Le système affiche la liste de diagnostic
3. Le médecin sélectionne le diagnostic à modifier
4. Le système affiche le formulaire de diagnostic
5. Le médecin saisit le nouveau diagnostic
6. Le système vérifie
7. Le système affiche la nouvelle donnée.
Scénario alternatif 4.1 champs manquants
Tableau 21 : Description textuelle du cas « modifier diagnostics »
ajouter diagnostic
ajouter
afficher le formulaire
cliquer sur ajouter
afficher le nouveaux diagnostic
retour vers le fourmulaire
vérifier
remplir le formulaire
afficher la liste de diagnostic
cliquer sur diagnostic
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
ajouter
afficher le formulaire
cliquer sur ajouter
afficher le nouveaux diagnostic
retour vers le fourmulaire
vérifier
remplir le formulaire
afficher la liste de diagnostic
cliquer sur diagnostic

63. 50
1.5. Diagramme de séquence système du cas « modifier diagnostics » :
Figure 57 : Diagramme de séquence système du cas « modifier diagnostics »
1.6. Description textuelle du cas « supprimer diagnostics » :
CU supprimer diagnostic
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Diagnostic supprimé
Scénario nominal
1. Le médecin clique sur diagnostic
2. Le système affiche la liste de diagnostic
3. Le médecin sélectionne le diagnostic à supprimer
4. Le médecin clique sur supprimer
5. Le système supprimer le diagnostic à supprimer
Scénario alternatif 4.1. champs manquants
Tableau 22 : Description textuelle du cas « supprimer diagnostics »
modifier diagnostic
afficher le formulaire de modification
sélectionner le diagnostic à modifier
cliquer sur diagnostic
afficher la liste de diagnostic
saisir les nouvelles données
vérifier
retour vers le fourmulaire
modifier
afficher les nouvelles données
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
afficher le formulaire de modification
sélectionner le diagnostic à modifier
cliquer sur diagnostic
afficher la liste de diagnostic
saisir les nouvelles données
vérifier
retour vers le fourmulaire
modifier
afficher les nouvelles données

64. 51
1.7. Diagramme de séquence système du cas « supprimer diagnostics » :
Figure 58 : Diagramme de séquence système du cas « supprimer diagnostics »
2. Analyse du cas d’utilisation «gérer antécédent»:
2.1. Raffinement du cas d’utilisation « gérer antécédent»:
Figure 59 : cas d’utilisation du cas « gérer antécédent»
supprimer diagnostic
diagnostic supprimé
supprimer
afficher la liste de diagnostic
cliquer sur diagnostic
sélectionner le diagnostic à supprimer
médecin
système
ref
s'authentifier()
diagnostic supprimé
supprimer
afficher la liste de diagnostic
cliquer sur diagnostic
sélectionner le diagnostic à supprimer
<<include>>
gérer antécédent
ajouter modifier supprimer
s'authentifier
médecin

65. 52
2.2. Description textuelle du cas « ajouter antécédent» :
CU Ajouter Antécédent
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Antécédent ajouté
Scénario nominal
1. Le médecin clique sur antécédent
2. Le système affiche la liste d’antécédent
3. Le médecin clique sur ajouter
4. Le système affiche le formulaire
5. Le médecin remplit le formulaire
6. Le système vérifie
7. Le système enregistre l’antécédent ajouté
Scénario alternatif 6.1 champs manquants
Tableau 23 : Description textuelle du cas « ajouter antécédent »
2.3. Diagramme de séquence système du cas « ajouter antécédent» :
Figure 60: Diagramme de séquence système du cas « ajouter antécédent »
ajouter antécédent
afficher le nouvel antécédent
ajouter
retour vers le fourmulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur antécédent
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
afficher le nouvel antécédent
ajouter
retour vers le fourmulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur antécédent

66. 53
2.4. Description textuelle du cas « modifier antécédent» :
CU modifier Antécédent
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Antécédent modifié
Scénario nominal 1. Le médecin clique antécédent
2. Le système affiche la liste d’antécédent
3. Le médecin sélectionne l’antécédent à modifier
4. Le système affiche le formulaire de modification
5. Le médecin saisit la nouvelle donnée
6. Le système vérifie
7. Le système enregistre l’antécédent modifié
Scénario alternatif 6.1 champs manquantes
Tableau 24 : Description textuelle du cas « modifier antécédents »
2.5. Diagramme de séquence système du cas « modifier antécédent» :
Figure 61: Diagramme de séquence système du cas « modifier antécédent »
modifier antécédent
afficher le formulaire de modification
sélectionner le diagnostic à modifier
cliquer sur antécédent
affiche la liste des antécédents
saisir les nouvelles données
vérifier
retour vers le fourmulaire
modifier
afficher les nouvelles données
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
afficher le formulaire de modification
sélectionner le diagnostic à modifier
cliquer sur antécédent
affiche la liste des antécédents
saisir les nouvelles données
vérifier
retour vers le fourmulaire
modifier
afficher les nouvelles données

67. 54
2.6. Description textuelle du cas « supprimer antécédent» :
CU Supprimer Antécédent
Acteur Médecin
Pré-condition S’authentifier + patient déjà enregistré
Post-condition Antécédent supprimé
Scénario nominal 1. Le médecin clique sur antécédent
2. Le système affiche la liste d’antécédent
3. Le médecin sélectionne l’antécédent à supprimer
4. Le médecin clique sur supprimer
5. Le système supprimer l’antécédent sélectionné
Scénario alternatif aucun
Tableau 25 : Description textuelle du cas « supprimer antécédent »
2.7. Diagramme de séquence système du cas « supprimer antécédents» :
Figure 62: Diagramme de séquence système du cas « supprimer antécédents »
supprimer antécédent
antécédent supprimé
reponse
envoyer requête
envoyer données
sélectionner l'antécédent à supprimer
afficher la liste d'antécédent
cliquer sur antécédent
médecin liste antécédent Antécédent antécédent
ref
s'authentifier()
antécédent supprimé
reponse
envoyer requête
envoyer données
sélectionner l'antécédent à supprimer
afficher la liste d'antécédent
cliquer sur antécédent

68. 55
3. Analyse du cas d’utilisation «gérer examen» :
3.1. Raffinement du cas d’utilisation « gérer examen» :
Figure 63: Diagramme du cas d’utilisation « gérer examen »
3.2. Description textuelle du cas « ajouter examen » :
CU Ajouter examen
Acteur Médecin
Pré-condition S’authentifier
Post-condition Examen ajouté
Scénario nominal 1. Le médecin clique sur examen
2. Le système affiche la liste d’examen
3. Le médecin clique sur ajouter
4. Le système affiche le formulaire
5. Le médecin remplir le formulaire
6. Le système vérifie
7. Examen ajouté
Scénario alternatif 6.1 Champs manquants
Tableau 26 : Description textuelle du cas « ajouter examen »
<<include>>
médecin
gérer examen
ajouter
supprimer
modifier
s'authentifier

69. 56
3.3. Diagramme de séquence système du cas « ajouter examen» :
Figure 64 : Diagramme de séquence système du cas « ajouter examen »
3.4. Description textuelle du cas « modifier examen » :
Cu Modifier examen
Acteur Médecin
Pré- condition S’authentifier
Post-condition Examen modifié
Scénario nominal 1. le médecin clique sur examen
2. le système affiche la liste d’examen
3. le médecin sélectionne l’examen à modifier
4. le système affiche le formulaire de modification
5. le médecin saisit les nouvelles données
6. le système vérifie
7. le système affiche examen modifié
Scénario alternatif 6.1 champs manquants
Tableau 27 : Description textuelle du cas « modifier examen»
ajouter examen
afficher les neauveau données
ajouter
reouter ver la fourmulaire
vérifier
remplir le formulaire
afficher la liste d'examen
cliquer sur examen
cliquer sur ajouter
afficher la formulaire
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
afficher les neauveau données
ajouter
reouter ver la fourmulaire
vérifier
remplir le formulaire
afficher la liste d'examen
cliquer sur examen
cliquer sur ajouter
afficher la formulaire

70. 57
3.5. Diagramme de séquence système du cas « modifier examen »
Figure 65: Diagramme de séquence système du cas « modifier examen »
3.6. Description textuelle du cas « supprimer examen » :
CU Supprimer examen
Acteur Médecin
Pré-condition S’authentifier
Post-condition Examen supprimé
Scénario nominal 1. Le médecin clique sur examen
2. Le système affiche la liste d’examen
3. Le médecin sélectionne l’examen à supprimer
4. Le système supprime l’examen sélectionné
Scénario alternatif Aucun
Tableau 28 : Description textuelle du cas « supprimer examen »
modifier examen
modifier
afficher le formulaire de modification
sélectionner l'examen à modifier
cliquer sur,examen
afficher la liste d'examen
saisir les nouvelles donneés
vérifier
retour vers le fourmulaire
afficher les nouvelles données
médecin
système
ref
s'authentifier()
données manquantes
données remplis
alt
modifier
afficher le formulaire de modification
sélectionner l'examen à modifier
cliquer sur,examen
afficher la liste d'examen
saisir les nouvelles donneés
vérifier
retour vers le fourmulaire
afficher les nouvelles données

71. 58
3.7. Diagramme de séquence système du cas « supprimer examen » :
Figure 66: Diagramme de séquence système du cas «supprimer examen »
4. analyse des cas d'utilisation «gérer données anthropométriques» :
4.1. Raffinement du cas d’utilisation «gérer données anthropométriques » :
Figure 67 : diagramme du cas d’utilisation «gérer données anthropométriques »
supp examen
examen supprimé
supprimer
afficher la liste d'examen
cliquer sur examen
sélectionner l'examen supprimer
médecin
système
ref
s'authentifier()
examen supprimé
supprimer
afficher la liste d'examen
cliquer sur examen
sélectionner l'examen supprimer
<<include>>
gérer données anthropométriques
supprimermodifer
ajouter
s'authentifier
médecin

72. 59
4.2. Description textuelle du cas «ajouter données anthropométriques » :
CU Ajouter données anthropométriques
Acteur Médecin
Pré-condition S’authentifier
Post-condition donnée anthropométrique ajoutée
Scénario nominal 1. Le médecin clique sur données anthropométriques
2. Le système affiche les listes données anthropométriques
3. Le médecin clique sur ajouter
4. Le système affiche le formulaire
5. Le médecin remplit le formulaire
6. Le système vérifie
7. Le système affiche données anthropométriques modifiées
Scénario alternatif 6.1 données manquantes
Tableau 29 : Description textuelle du cas « ajouter données anthropométriques»
4.3. Diagramme de séquence système du cas « ajouter données anthropométriques » :
Figure 68: Diagramme de séquence système du cas «ajouter données anthropométriques»
ajouter données anthropométriques
afficher le formulaire
cliquer sur ajouter
cliquer sur données anthropométriques
affichela liste de données
anthropométriques
remplir le formulaire
vérifier
reouter ver la fourmulaire
ajouter
afficher le nouveau donnée
médecin
système
ref
s'authentifier()
données monquantes
données remplis
alt
afficher le formulaire
cliquer sur ajouter
cliquer sur données anthropométriques
affichela liste de données
anthropométriques
remplir le formulaire
vérifier
reouter ver la fourmulaire
ajouter
afficher le nouveau donnée

73. 60
4.4. Description textuelle du cas «modifier données anthropométriques» :
CU Modifier données anthropométriques
Acteur Médecin
Pré-condition S’authentifier
Post-condition donnée anthropométrique modifiée
Scénario nominal 1. Le médecin clique sur données anthropométriques
2. Le système affiche les listes données anthropométriques
3. Le médecin sélectionne les données anthropométriques à modifier
4. Le système affiche le formulaire de modification
5. Le médecin saisit les nouvelles données
6. Le système vérifie
7. Le système affiche données anthropométriques modifiées
Scénario alternatif 6.1 données manquantes
Tableau 30 : Description textuelle du cas « modifier données anthropométriques»
4.5. Diagramme de séquence système du cas « modifier données anthropométriques » :
Figure 69: Diagramme de séquence système du cas «modifier données
anthropométriques»
modifier données anthropométriques
afficher le nouveau donnée
modifier
retour vers le fourmulaire
veéifier
saisir les nouvelles données
affichela liste de données
anthropométriques
cliquer sur données anthropométriques
sélectionner les données à modifier
afficher le formulaire de modification
médecin
système
ref
s'authentifier()
données monquente
données remplis
alt
afficher le nouveau donnée
modifier
retour vers le fourmulaire
veéifier
saisir les nouvelles données
affichela liste de données
anthropométriques
cliquer sur données anthropométriques
sélectionner les données à modifier
afficher le formulaire de modification

74. 61
4.6. Description textuelle du cas «supprimer données anthropométriques » :
CU Supprimer données anthropométriques
Acteur Médecin
Pré-condition S’authentifier
Post-condition donnée anthropométrique supprimée
Scénario nominal 1. Le médecin clique sur données anthropométriques
2. Le système affiche les listes données anthropométriques
3. Le médecin sélectionne les données anthropométriques à
supprimer
4. Le système supprime les données anthropométriques sélectionnées
Scénario alternatif Aucun
Tableau 31 : Description textuelle du cas « supprimer données anthropométriques»
4.7. Diagramme de séquence système du cas « supprimer données anthropométriques » :
Figure 70: Diagramme de séquence système du cas «supprimer données
anthropométriques»
supprimer données anthropométriques
selectionne donnée à supprimer
cliquer sur données anthropométriques
afficher les liste de données
anthropométriques
supprimer
donées supprimé
médecin
système
ref
s'authentifier()
selectionne donnée à supprimer
cliquer sur données anthropométriques
afficher les liste de données
anthropométriques
supprimer
donées supprimé

75. 62
5. analyse des cas d'utilisation «gérer ordonnance» :
La gestion d’ordonnance s’effectue par le médecin qu’il peut ajouter une ordonnance ou
consulter ou supprimer.
5.1. Raffinement du cas d’utilisation « gérer ordonnance » :
Figure 71 : Diagramme du cas d’utilisation « gérer ordonnance »
5.2. Description textuelle du cas «ajouter ordonnance » :
CU Ajouter ordonnance
Acteur Médecin
Pré-condition S’authentifier
Post-condition Ordonnance supprimée
Scénario nominal 1. Le médecin clique sur ordonnance
2. Le système affiche la liste d’ordonnance
3. Le médecin clique sur ajouter
4. Le système affiche le formulaire
5. Le médecin remplit le formulaire
6. Le système vérifie
7. Le système ajoute la nouvelle ordonnance
Scénario alternatif Aucun
Tableau 32 : Description textuelle du cas « ajouter ordonnance »
<<include>>
médecin
s'authentifier
consulter
ajouter
gérer ordonnance
supprimer

76. 63
5.3. Diagramme de séquence système du cas « ajouter ordonnance » :
Figure 72 : Diagramme de séquence système du cas « ajouter ordonnance »
5.4. Description textuelle du cas « consulter ordonnance » :
CU Consulter ordonnance
Acteur Médecin
Pré-condition S’authentifier
Post-condition Ordonnance supprimée
Scénario nominal 1. Le médecin cliqué sur ordonnance
2. Le système affiche la liste d’ordonnance
3. Le médecin sélectionne l’ordonnance à consulter
4. Le système affiche l’ordonnance sélectionne
Scénario alternatif Aucun
Tableau 33 : Description textuelle du cas « consulter ordonnance »
ajouter ordonnance
ordonnance ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ordonnance
afficher la liste d'ordonnance
cliquer sur ajouter
médecin
système
ref
s'authentifier()
données manquantes
Condition
alt
ordonnance ajouté
ajouter
retour vers le formulaire
vérifier
remplir le formulaire
afficher le formulaire
cliquer sur ordonnance
afficher la liste d'ordonnance
cliquer sur ajouter

77. 64
5.5. Diagramme de séquence système du cas « consulter ordonnance» :
Figure 73 : Diagramme de séquence système du cas « consulter l’ordonnance »
5.6. Description textuelle du cas «supprimer ordonnance » :
CU Supprimer ordonnance
Acteur Médecin
Pré-condition S’authentifier
Post-condition Ordonnance supprimée
Scénario nominal 1. Le médecin clique sur ordonnance
2. Le système affiche les listes d’ordonnance
3. Le médecin sélectionne l’ordonnance à supprimer
4. Le système supprime l’ordonnance sélectionnée
Scénario alternatif Aucun
Tableau 34 : Description textuelle du cas « supprimer ordonnance »
consulter ordonnance
afficherl'ordonnance sélectionnée
sélectionner l'ordonnance qu'il veut
consulter
afficher la liste d'ordoonance
cliquer sur ordonnance
médecin
système
ref
s'authentifier()
afficherl'ordonnance sélectionnée
sélectionner l'ordonnance qu'il veut
consulter
afficher la liste d'ordoonance
cliquer sur ordonnance

78. 65
5.7. Diagramme de séquence système du cas «supprimer ordonnance» :
Figure 74 : Diagramme de séquence système du cas « supprimer l’ordonnance »
IV. Conception de cas d'utilisation :
Nous orienterons dans cette partie la traçabilité entre le modèle du cas d’utilisation et le
modèle d’analyse et les diagrammes séquences détaillées. Après, nous nous fournissons le
diagramme de classe globale du deuxième sprint.
1. Modèle d’analyse du cas d’utilisation «gérer la consultation» :
1.1. Conception du cas d’utilisation « gérer diagnostic » :
1.1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation «ajouter diagnostic »
Figure 75 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation «ajouter diagnostic »
suppri mer ordonnance
sél ecti onner l 'ordonnance à suppri mer
cl i quer sur ordonnance
affi cher l a l i ste d'ordonnance
suppri mer
ordonnance suppri mé
médeci n
système
ref
s'authenti fi er()
sél ecti onner l 'ordonnance à suppri mer
cl i quer sur ordonnance
affi cher l a l i ste d'ordonnance
suppri mer
ordonnance suppri mé
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
ajouter
diagnostic Ajouter diagnostic
diagnostic formulaire Diagnostic

79. 66
1.1.2. Modèle de classe d’analyse d’utilisation «ajouter diagnostic » :
Figure 76: Modèle de classe d’analyse d’utilisation «ajouter diagnostic »
1.1.3. Diagramme de séquence détaillée du cas d’utilisation « ajouter diagnostic » :
Figure 77 : Diagramme de séquence détaillée du cas «ajouter diagnostic »
médeci n
i nterfacedi agnosti c
contrôl eurformul ai redi agnosti c
ajouter diagnostic
diagnostic ajouté
réponse
envoyer requête
retour vers la fourmulaire
vérifier
envoyer données
remplir le fourmulaire réponse
envoyer la demande
cliquer sur ajouter diagnostic
afficher la liste de diagnostic
cliquer sur diagnostic
médecin liste diagnostic diagnostic Diagnostic
ref
s'authentifier()
données manquantes
données remplie
alt
diagnostic ajouté
réponse
envoyer requête
retour vers la fourmulaire
vérifier
envoyer données
remplir le fourmulaire réponse
envoyer la demande
cliquer sur ajouter diagnostic
afficher la liste de diagnostic
cliquer sur diagnostic

80. 67
1.1.4. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier diagnostic » :
Figure 78: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier diagnostic»
1.1.5. Modèle de classe d’analyse d’utilisation « modifier diagnostic» :
Figure 79 : Modèle de classe d’analyse d’utilisation « modifier diagnostic»
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
modiifer
diagnostic modifier diagnostic
interface de modification formulaire Diagnostic
médecin
interface de modification
contrôleurformulairediagnostic

81. 68
1.1.6. Diagramme de séquence détaillée du cas d’utilisation « modifier diagnostic» :
Figure 80: Diagramme de séquence détaillée du cas d’utilisation « modifier diagnostic»
1.1.7. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer diagnostic » :
Figure 81: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer diagnostic »
modifier diagnostic
afficher le formulaire de modification
cliquer sur diagnostic
afficher la liste de diagnostic
sélectionner le diagnostic à modifier
saisir les nouvelles donneées
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
diagnostic modifié
médecin liste diagnostic diagnostic Diagnostic
ref
s'authentifier()
données manquantes
données remplis
alt
afficher le formulaire de modification
cliquer sur diagnostic
afficher la liste de diagnostic
sélectionner le diagnostic à modifier
saisir les nouvelles donneées
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
diagnostic modifié
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
supprimer
diagnostic Supprimer
diagnostic
interface de diagnostic
formulaire Diagnostic

82. 69
1.1.8 Modèle de classe d’analyse d’utilisation « supprimer diagnostic» :
Figure 82 : Modèle de classe d’analyse d’utilisation « supprimer diagnostic»
1.1.9. Diagramme de séquence détaillée du cas d’utilisation « supprimer diagnostic» :
Figure83 : Diagramme de séquence détaillée du cas d’utilisation « supprimer
diagnostic »
médeci n
i nterface de di agnsoti c
contrôl eur formul ai redi agnosti c
supprimer diagnostic
diagnostic supprimé
réponse
envoyer requête
envoyer données
sélectionner le diagnostic à supprimer
afficher la liste de diagnostic
cliquer sur diagnostic
médecin liste diagnostic diagnostic Diagnostic
ref
s'authentifier()
diagnostic supprimé
réponse
envoyer requête
envoyer données
sélectionner le diagnostic à supprimer
afficher la liste de diagnostic
cliquer sur diagnostic

83. 70
1.2. Conception du cas d’utilisation« gérer antécédent» :
1.2.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « ajouter antécédent» :
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»
1.2.2. Modèle de classe d’analyse d’utilisation « ajouter antécédent» :
Figure85 : Modèle de classe d’analyse d’utilisation « ajouter antécédent »
<trace>
<participate><participate><participate>
médecin
ajouter
antécédent
ajouter antécédent
Antécédent antécédentinterface ajouter antécédent
médecin
interface liste antécédent
controlleur antécédent
Antécédent

84. 71
1.2.3. Diagramme de séquence détaillée du cas « ajouter antécédent» :
Figure 86 : Diagramme de séquence détaillée du cas « ajouter antécédent »
1.2.4 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier antécédent» :
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»
ajouter antécédent
antécédent ajouté
réponse
envoyer requête
retour vers le fourmulaire
vérifier
envoyer données
remplir le fourmulaire réponse
envoyer la demande
cliquer sur ajouter
afficher la liste d'antécédent
cliquer sur antécédent
médecin liste antécédent antécédent Antécédent
ref
s'authentifier()
données manquantes
données remplie
alt
antécédent ajouté
réponse
envoyer requête
retour vers le fourmulaire
vérifier
envoyer données
remplir le fourmulaire réponse
envoyer la demande
cliquer sur ajouter
afficher la liste d'antécédent
cliquer sur antécédent
<trac>
<participate><participate><participate>
médecin
modifier
antécédent
Modifier antécédent
Antécédent antécédentinterface de modification
antécédent

85. 72
1.2.5 Modèle de classe d’analyse d’utilisation « modifier antécédent» :
Figure88 : Modèle de classe d’analyse d’utilisation « modifier antécédent »
1.2.6. Diagramme de séquence détaillée du cas « modifier antécédent» :
Figure 89 : Diagramme de séquence détaillée du cas « modifier antécédent »
médecin
interface de modification
antécédent
controlleur antécédent
Antécédent
modifier antécédent
afficher le formulaire de modification
cliquer sur antécédent
afficher la liste antécédent
sélectionner antécédent à modifier
saisir les nouvelles donneées
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
antécédent modifié
médecin liste antécédent antécédent Antécédent
ref
s'authentifier()
données manquantes
données remplis
alt
afficher le formulaire de modification
cliquer sur antécédent
afficher la liste antécédent
sélectionner antécédent à modifier
saisir les nouvelles donneées
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
antécédent modifié

86. 73
1.2.7. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer antécédent» :
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»
1.2.8. Modèle de classe d’analyse d’utilisation «supprimer antécédent» :
Figure 91 : Modèle de classe d’analyse d’utilisation «supprimer antécédent »
<trac>
<participate><participate><participate>
médecin
supprimer
antécédent
Supprimer antécédent
Antécédent antécédentliste des antécédents
médecin
interface de supression antécédent
controlleur antécédent
Antécédent

87. 74
1.2.9. Diagramme de séquence détaillée du cas « supprimer antécédent» :
Figure 92 : Diagramme de séquence détaillée du cas « supprimer antécédent »
1.3. Conception du cas d’utilisation « gérer examens » :
1.3.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « ajouter examen » :
Figure 93 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « ajouter examen »
supprimer antécédent
antécédent supprimé
reponse
envoyer requête
envoyer données
sélectionner l'antécédent à supprimer
afficher la liste d'antécédent
cliquer sur antécédent
médecin liste antécédent Antécédent antécédent
ref
s'authentifier()
antécédent supprimé
reponse
envoyer requête
envoyer données
sélectionner l'antécédent à supprimer
afficher la liste d'antécédent
cliquer sur antécédent
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
ajouter examen
Ajouter examen
interface examen formulaire examens

88. 75
1.3.2. Modèle de classe d’analyse d’utilisation « ajouter examen» :
Figure 94 : Modèle de classe d’analyse d’utilisation « ajouter examen »
1.3.3. Diagramme de séquence détaillée de cas « ajouter examen » :
Figure 95 : Diagramme de séquence détaillée de cas « ajouter examen »
médecin
interface examen
contrôleur formulaireexamens
ajouter examen
cliquer sur examen
afficher la liste d'examen
cliquer sur ajouter
envoyer la demande
réponseremplir le fourmulaire
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
examen ajouté
médecin liste examen examen Examen
ref
s'authentifier()
données manquantes
données remplis
alt
cliquer sur examen
afficher la liste d'examen
cliquer sur ajouter
envoyer la demande
réponseremplir le fourmulaire
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
examen ajouté

89. 76
1.3.4 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier examen » :
Figure 96 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « modifier examen »
1.3.5. Modèle de classe d’analyse d’utilisation « modifier examen» :
Figure 97 : Modèle de classe d’analyse d’utilisation « modifier examen »
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
modifier
examen Modifier examen
interface de modification formulaire examens
médecin
interface examen
contrôleur formulaireexamens

90. 77
1.3.6. Diagramme de séquence détaillée de cas « modifier examen » :
Figure 98 : Diagramme de séquence détaillée de cas « modifier examen »
1.3.7. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer examen» :
Figure 99 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer examen »
modifier examen
afficher la formulaire de modification
cliquer sur examen
afficher la liste d'examen
sélectionner l'examen à modifier
saisir la nouvelle donnée
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
examen modifié
médecin liste examen examen Examen
ref
s'authentifier()
données manquantes
données remplis
alt
afficher la formulaire de modification
cliquer sur examen
afficher la liste d'examen
sélectionner l'examen à modifier
saisir la nouvelle donnée
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
examen modifié
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
supprimer
examen Supprimer examen
interface examen formulaire examens

91. 78
1.3.8. Modèle de classe d’analyse d’utilisation « supprimer examen» :
Figure 100 : Modèle de classe d’analyse d’utilisation « supprimer examen »
1.3.9. Diagramme de séquence détaillée de cas « supprimer examen» :
Figure 101 : Diagramme de séquence détaillée de cas « supprimer examen »
médecin
interface examen
contrôleur formulaireexamen
supprimer examen
cliquer sur examen
afficher la liste d'examen
sélectionner examen à supprimer
envoyer données
envoyer requête
réponse
examen supprimé
médecin liste examen Examen examen
ref
s'authentifier()
cliquer sur examen
afficher la liste d'examen
sélectionner examen à supprimer
envoyer données
envoyer requête
réponse
examen supprimé

92. 79
1.4. Conception du cas d’utilisation « gérer données anthropométriques» :
1.4.1. 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» :
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»
1.4.2. Modèle de classe d’analyse d’utilisation «ajouter données anthropométriques» :
Figure 103 : Modèle de classe d’analyse d’utilisation «ajouter données
anthropométriques »
<<trace>>
<<participate>><<participate>>
<<participate>>
médecin
ajouter données
anthropométriques Ajouter données
anthropométriques
données anthropométriques formulaire
Données anthropométriques
médecin
interface données
anthropométriques
contrôleurformulairedonnées anthropométriques

93. 80
1.4.3. Diagramme de séquence détaillée de cas « ajouter données anthropométriques» :
Figure 104 : Diagramme de séquence détaillée de cas «ajouter données
anthropométriques »
1.4.4. 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» :
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»
ajouter données anthropométriques
cliquer sur données anthropométriques
afficher la liste de données
cliquer sur ajouter données
envoyer la demande
réponseremplir le fourmulaire
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
données anthropométriques ajouté
médecin liste données
anthropométriques
données
anthropométriques
Données
anthropométriques
ref
s'authentifier()
donnnées manquantes
données remplis
alt
cliquer sur données anthropométriques
afficher la liste de données
cliquer sur ajouter données
envoyer la demande
réponseremplir le fourmulaire
envoyer données
vérifier
retour vers le fourmulaire
envoyer requête
réponse
données anthropométriques ajouté
<<trace>>
<<participate>>
<<participate>><<participate>>
médecin
modifier données
anthropométriques Modifier données
anthropométriques
interface données anthropométriques
de modification
formulaire Données anthropométriques

94. 81
1.4.5. Modèle de classe d’analyse d’utilisation «modifier données anthropométriques» :
Figure 106: Modèle de classe d’analyse d’utilisation «modifier données
anthropométriques »
1.4.6. Diagramme de séquence détaillée de cas « modifier données anthropométriques» :
Figure107 : Diagramme de séquence détaillée de cas « modifier données
anthropométriques»
médecin
interface données
anthropométriques de
modification
contrôleurformulairedonnées anthropométriques
modifier données anthropométriques
données anthropométriques modifié
réponse
envoyer requête
retour vers le fourmulaire
vérifier
envoyer données
saisir la nouvelle donnée
sélectionner donnnées à modifier
afficher la liste de donnnées
cliquer sur donnnées anthropométriques
afficher le formulaire de modification
méedecin I liste donnnées
anthropométriques
donnnées
anthropométriques
Donnnées
anthropométriques
ref
s'authentifier()
données manquantes
données remplis
alt
données anthropométriques modifié
réponse
envoyer requête
retour vers le fourmulaire
vérifier
envoyer données
saisir la nouvelle donnée
sélectionner donnnées à modifier
afficher la liste de donnnées
cliquer sur donnnées anthropométriques
afficher le formulaire de modification

95. 82
1.4.7. 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» :
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»
1.4.8. Modèle de classe d’analyse d’utilisation «supprimer données
anthropométriques» :
Figure109 : Modèle de classe d’analyse d’utilisation «supprimer données
anthropométriques »
<<trace>>
<<participate>>
<<participate>><<participate>>
médecin
supprimer
données
anthropométriques
supprimer données
anthropométriques
interface de données
anthropométriques formulaire
données anthropométriques
médecin
interface données
anthropométriques
contrôleurformulairedonnées anthropométriques

96. 83
1.4.9. Diagramme de séquence détaillée de cas « supprimer données
anthropométriques» :
Figure 110 : Diagramme de séquence détaillée de cas « supprimer données
anthropométriques»
1.5. Conception du cas d’utilisation « gérer ordonnance » :
1.5.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « ajouter ordonnance » :
Figure 111 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « ajouter ordonnance»
supprimer données anthropométriques
données supprimé
réponse
envoyer requête
envoyer données
sélectionner données à supprimer
afficher la liste de données
cliquer sur données anthropométriques
médecin liste données
anthropométriques
données
anthropométriques
Données
anthropométriques
ref
s'authentifier()
données supprimé
réponse
envoyer requête
envoyer données
sélectionner données à supprimer
afficher la liste de données
cliquer sur données anthropométriques
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
ajouter
ordonnance Ajouter ordonnance
interface ordonnance formulaire ordonnace

97. 84
1.5.2. Modèle de classe d’analyse d’utilisation «ajouter ordonnance » :
Figure 112 : Modèle de classe d’analyse d’utilisation « ajouter ordonnance »
1.5.3. Diagramme de séquence détaillée de cas d’utilisation « ajouter ordonnance » :
Figure 113: Diagramme de séquence détaillée du cas « ajouter ordonnance »
médecin
interface ordonnance
contrôleur formulaireordonnance
ajouter ordonnance
ordonnance ajouté
réponse
envoyer requête
envoyer les données
saisir la description
afficher l'interface demandée
demander l'interface d'ordonnance
médecin i_consultation c_ordonnance ordonnance
ref
s'authentifier()
ordonnance ajouté
réponse
envoyer requête
envoyer les données
saisir la description
afficher l'interface demandée
demander l'interface d'ordonnance

98. 85
1.5.4. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « consulter ordonnance » :
Figure 114 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « consulter ordonnance»
1.5.5. Modèle de classe d’analyse d’utilisation « consulter ordonnance » :
Figure 115 : Modèle de classe d’analyse d’utilisation « consulter ordonnance »
<<trace>>
<<participate>>
<<participate>>
<<participate>
>
médecin
consulter
ordonnance Consulter
ordonnance
interface liste ordonnance
formulaire ordonnace
médecin
interface liste ordonnance
contrôleur formulaireordonnance

99. 86
1.5.6. Diagramme de séquence détaillée du cas d’utilisation « consulter ordonnance» :
La figure 116 illustre le diagramme de séquence du cas «consulter ordonnance ». Lorsque
médecin clique sur ordonnance le système affiche la liste d’ordonnance crée par le médecin.
Figure 116 : Diagramme de séquence détaillée du cas «consulter ordonnance »
1.5.7. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer ordonnance » :
Figure 117: Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation « supprimer ordonnance»
consulter ordonnace
envoyer requête
envoyer demande
sélectonner l'ordonnace qu' il veut
consulter
afficher la liste d'ordonnace
cliquer sur ordonnance
réponse
afficher l'ordonnance
médecin liste ordonnance Ordonnance ordonnance
ref
s'authentifier()
envoyer requête
envoyer demande
sélectonner l'ordonnace qu' il veut
consulter
afficher la liste d'ordonnace
cliquer sur ordonnance
réponse
afficher l'ordonnance
<trac>
<participate><participate><participate>
médecin
supprimer
ordonnance
Supprimer ordonnance
ordonnnance Ordonnanceliste ordonnance

100. 87
1.5.8. Modèle de classe d’analyse d’utilisation « supprimer ordonnance » :
Figure 118 : Modèle de classe d’analyse d’utilisation « supprimer ordonnance »
1.5.9. Diagramme de séquence détaillée du cas d’utilisation «supprimer ordonnance» :
Figure 119: Diagramme de séquence détaillée du cas «supprimer ordonnance »
médecin
interface liste ordonnance
controlleur ordonnance
ordonnance
supprimer ordonnance
cliquer sur ordonnance
afficher la liste d'ordonnance
sélectionner l'ordonnance à supprimer
envoyer données
envoyer requête
réponse
ordonnance supprimé
méedecin liste ordonnance Ordonnance ordonnance
ref
s'authentifier()
cliquer sur ordonnance
afficher la liste d'ordonnance
sélectionner l'ordonnance à supprimer
envoyer données
envoyer requête
réponse
ordonnance supprimé

101. 88
2. Diagramme de classe globale de deuxième sprint :
Suite à tout le travail de spécification et de conception, nous pouvons maintenant
construire le nouvel incrément de notre diagramme des classes en ajoutant les différents
éléments (classes, associations, attribut, etc.) déduits à partir des activités précédentes.
Figure 120 : Diagramme de classe globale de deuxième sprint
appartenir
1..1
1..1
appartenir
appartenir
posséder
appartenir
posséder
posséder
gérer
posséder
posséder
1..*
1..*
1..1
1..*
1..1
1..*
1..1
1..*
1..1
1..1
1..1
1..*
1..1
1..*
1..1
0..*
1..1
1..1
1..*
1..1
app_user
-
-
-
-
id app user
id user profil
login
mot de passe
: int
: int
: String
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
user profil
-
-
id user profil
rôle
: int
: String
rendez-vous
-
-
-
-
id rendez-vous
date
heure
id patient
: int
: Date
: Date
: int
+
+
+
ajouter ()
modifier ()
annuler ()
...
antécédent
-
-
-
-
id antécédent
description
nom
id catégorie antécédent
: int
: String
: String
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
...
catégorie antécédent
-
-
-
id catégorie antécédent
type
description
: int
: String
: String
consultation
-
-
-
-
-
-
-
-
id consultation
id motif de consultation
id rendez-vous
id antécédent
id examen
id ordonnance
date de consultation
id diagnostic
: int
: int
: int
: int
: int
: int
: Date
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
...
fiche patient
-
-
-
-
-
-
-
id patient
nom
prénom
date de naissance
num dossier
num tél
adresse
: int
: String
: String
: Date
: String
: int
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
données anthropométriques
-
-
-
-
id données anthropométriques
poid
PMC
pourcentage de masse
: int
: String
: String
: String
+
+
+
ajouter ()
modifer ()
supprimer ()
...
examen
-
-
-
-
-
-
-
id examen
description examen abdominal
descriptionExamenCardio vascullaires
description examen neurologiques
description constantes vitales
descriptionExamen pleuro-pulmonaire
id données anthropométriques
: int
: String
: String
: String
: String
: String
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
ordonnance
-
-
id ordonnance
description
: int
: String
+
+
+
ajouter ()
consulter ()
supprimer ()
app user user profil
-
-
id app user
id user profil
: int
: int diagnostic
-
-
id
type
: int
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
motif de consultation
-
-
id
type
: int
: String
+ ajouter ()

102. 89
V. Codage :
 Schéma de la base de données «Consultation» :
Attribue Type Contrainte
Id consultation Int PRAIMERY KEY
Id rendez-vous Int FRAYGERY KEY
Date de consultation Date
Id-diagnostic Int FRAYGERY KEY
Id-examen Int FRAYGERY KEY
Id-antécédent Int FRAYGERY KEY
Id-ordonnance Int FRAYGERY KEY
Id motif de consultation Int FRAYGERY KEY
Tableau 35 : table « consultation »
 Schéma de la base de données «ordonnance» :
Attribue Type Contrainte
Id Int PRIMERY KEY
Description String
Tableau 36: table « ordonnance »
 Schéma de la base de données «diagnostic» :
Attribue Type Contrainte
Id Int PRIMERY KEY
Type String
Tableau 37: table « diagnostic »
 Schéma de la base de données «antécédent» :
Attribue Type Contrainte
Id Int PRIMERY KEY
Description String
Nom String
Id catégorie Int FRAYGERY KEY
Tableau 38 : table « antécédent »

103. 90
 Schéma de la base de données «examen» :
Attribue Type Contrainte
Id Int PRIMARY KEY
Description examen abdominal String
Description examen cardio- vasculaire String
Description examen neurologique String
Description examen constantes vitale String
Description examen pleuro-pulmonaire String
Id donnée anthropométrique Int FRAYGERY KEY
Tableau 39: table « examen »
VI. Test :
 Interface consultation :
La figure 121 montre l’interface accessible juste par le médecin après avoir son
authentification pour pouvoir gérer la consultation ainsi que l’activité fait par le secrétaire.
Figure 121: page de consultation
90
 Schéma de la base de données «examen» :
Attribue Type Contrainte
Id Int PRIMARY KEY
Description examen abdominal String
Description examen cardio- vasculaire String
Description examen neurologique String
Description examen constantes vitale String
Description examen pleuro-pulmonaire String
Id donnée anthropométrique Int FRAYGERY KEY
Tableau 39: table « examen »
VI. Test :
 Interface consultation :
La figure 121 montre l’interface accessible juste par le médecin après avoir son
authentification pour pouvoir gérer la consultation ainsi que l’activité fait par le secrétaire.
Figure 121: page de consultation
90
 Schéma de la base de données «examen» :
Attribue Type Contrainte
Id Int PRIMARY KEY
Description examen abdominal String
Description examen cardio- vasculaire String
Description examen neurologique String
Description examen constantes vitale String
Description examen pleuro-pulmonaire String
Id donnée anthropométrique Int FRAYGERY KEY
Tableau 39: table « examen »
VI. Test :
 Interface consultation :
La figure 121 montre l’interface accessible juste par le médecin après avoir son
authentification pour pouvoir gérer la consultation ainsi que l’activité fait par le secrétaire.
Figure 121: page de consultation

104. 91
 Interface ordonnance :
La figure 122 illustre l’interface d’ordonnance qui permet au médecin de saisie le
médicament nécessaire au patient, il peut aussi L'imprimer ou bien convertir au PDF :
Figure 122 : page d’ordonnance
 Interface diagnostic :
La figure 123 montre l’interface de diagnostic qui permet au médecin de choisir le
diagnostic nécessaire au patient :
Figure 123: page diagnostic
91
 Interface ordonnance :
La figure 122 illustre l’interface d’ordonnance qui permet au médecin de saisie le
médicament nécessaire au patient, il peut aussi L'imprimer ou bien convertir au PDF :
Figure 122 : page d’ordonnance
 Interface diagnostic :
La figure 123 montre l’interface de diagnostic qui permet au médecin de choisir le
diagnostic nécessaire au patient :
Figure 123: page diagnostic
91
 Interface ordonnance :
La figure 122 illustre l’interface d’ordonnance qui permet au médecin de saisie le
médicament nécessaire au patient, il peut aussi L'imprimer ou bien convertir au PDF :
Figure 122 : page d’ordonnance
 Interface diagnostic :
La figure 123 montre l’interface de diagnostic qui permet au médecin de choisir le
diagnostic nécessaire au patient :
Figure 123: page diagnostic

105. 92
 Interface examen :
La figure 124 montre l’interface d’examen qui permet au médecin de choisir les
examens nécessaires au patient :
Figure 124: page d’examen
Conclusion :
Au cours du ce chapitre, nous avons réussi à développer le deuxième sprint afin d’atteindre un
produit complet et fonctionnel.
Dans le chapitre suivant, notre effort sera dédié pour produire un nouveau sprint recouvrant
les fonctionnalités du cas d’utilisation « gérer le dossier médical ».
92
 Interface examen :
La figure 124 montre l’interface d’examen qui permet au médecin de choisir les
examens nécessaires au patient :
Figure 124: page d’examen
Conclusion :
Au cours du ce chapitre, nous avons réussi à développer le deuxième sprint afin d’atteindre un
produit complet et fonctionnel.
Dans le chapitre suivant, notre effort sera dédié pour produire un nouveau sprint recouvrant
les fonctionnalités du cas d’utilisation « gérer le dossier médical ».
92
 Interface examen :
La figure 124 montre l’interface d’examen qui permet au médecin de choisir les
examens nécessaires au patient :
Figure 124: page d’examen
Conclusion :
Au cours du ce chapitre, nous avons réussi à développer le deuxième sprint afin d’atteindre un
produit complet et fonctionnel.
Dans le chapitre suivant, notre effort sera dédié pour produire un nouveau sprint recouvrant
les fonctionnalités du cas d’utilisation « gérer le dossier médical ».

106. 93
Chapitre V : Sprint 3: Gérer le dossier médical
Introduction :
Dans ce chapitre, nous présenterons le troisième sprint qui représente la phase de « gérer le
dossier médical ».
Nous allons commencer par expliquer « les user Stories ». Par la suite, nous donnons une
description des scénarios de chaque histoire d’utilisateur, une conception initiale du module,
le développement et test.
I. Spécification des besoins :
Au sein de ce sprint, les user stories vont appliquer les quatre étapes du cycle scrum.
1. Sprint Backlog :
Le tableau ci-dessous clarifie le backlog de notre troisième sprint qui se présente comme
suit :
ID User
Story
User Story ID
tâche
Tâche Affectation
1 En tant que
médecin, je
veux « gérer le
dossier
médical »
1.1 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence système, la
traçabilité entre diagramme
de cas d’utilisation et
diagramme de classes
d’analyse, diagramme de
séquence détaillée du
cas « consulter dossier
médical »
Ibtissem
Slimeni
1.2 Réaliser le diagramme du cas
d’utilisation, diagramme de
séquence système, la
traçabilité entre diagramme
de cas d’utilisation et
diagramme de classes
d’analyse, diagramme de
séquence détaillée du
cas « imprimer dossier
médical»
Soumaya
Nebli
Tableau 40 : Backlog du troisième sprint

107. 94
II. Diagramme des cas d’utilisation du troisième Sprint :
Au début de chaque itération, nous allons schématiser la spécification fonctionnelle par un
diagramme de cas d’utilisation. Celle-ci servira une vue d’ensemble du système et présentera
les liens et interactions entre les utilisateurs et les fonctionnalités.
1. Classification des cas d’utilisation par acteur :
Le Tableau suivant comporte une classification de toutes les fonctionnalités par acteur :
Acteur Cas d’utilisation
Médecin
 Consulter dossier médical
 Imprimer dossier médical
Tableau 41: Classification des cas d’utilisation par acteur
2. Diagramme de cas d’utilisation du Troisième sprint :
La figure 125 illustre le diagramme du cas d’utilisation du troisième sprint qui permet au
médecin de consulter ou bien imprimer le dossier médical.
Figure 125: Diagramme du cas d’utilisation du troisième sprint
<extend> <extend>
<<include>>
médecin
dossier medical s'authentifier
consulter imprimer

108. 95
III. Analyse des cas d’utilisation :
1. Analyse des cas d’utilisation «gérer le dossier médical» :
1.1. Analyse du cas d’utilisation «consulter dossier médical» :
1.1. 1. Description textuelle du cas «consulter dossier médical» :
CU Consulter dossier médical
Acteur Médecin
Pré-condition S’authentifier
Post-condition Consulté dossier médical
Scénario nominal 1. Le médecin clique sur dossier médical
2. Le système affiche la liste de dossier médical
3. Le médecin sélectionne le dossier médical qu’il veut consulter
4. Le système affiche le dossier médical sélectionne
Scénario alternatif Aucun
Tableau 42: Description textuelle du cas « consulter dossier médical »
1.1.2. Diagramme de séquence système du cas « consulter dossier médical » :
Figure 126 : Diagramme de séquence système du cas « consulter dossier médical »
consulter dossier médical
cliquer dossier médical
afficher la liste de dossier medical
sélectionner le dossier qu'il veut
consulter
afficher dossier selectionné
médecin
système
ref
s'authentifier()
cliquer dossier médical
afficher la liste de dossier medical
sélectionner le dossier qu'il veut
consulter
afficher dossier selectionné

109. 96
1.2. Analyse du cas d’utilisation «imprimer dossier médical» :
1.2.1. Description textuelle du cas «imprimer dossier médical» :
CU Imprimer dossier médical
Acteur Médecin
Pré-condition S’authentifier
Post-condition Consulté dossier médical
Scénario nominal 1. Le médecin clique sur dossier médical
2. Le système affiche la liste de dossier médical
3. Le médecin sélectionne le dossier médical qu’il veut imprime
4. Le système affiche le dossier médical sélectionné
5. Le médecin clique sur imprimer
6. Le système imprime le dossier médical imprimé
Scénario alternatif Aucun
Tableau 43 : Description textuelle du cas «imprimer dossier médical »
1.2.2. Diagramme de séquence système du cas «imprimer dossier médical :
Figure 127 : Diagramme de séquence système du cas «imprimer dossier médical»
imprimer dossier medical
dossier médical imprimé
cliquer sur imprimer
afficher le dossier sélectionné
sélectionner le dossier médical à imprimer
cliquer sur dossier médical
afficher la liste de dossier médical
médecin
système
ref
s'authentifier()
dossier médical imprimé
cliquer sur imprimer
afficher le dossier sélectionné
sélectionner le dossier médical à imprimer
cliquer sur dossier médical
afficher la liste de dossier médical

110. 97
IV. Conception du cas d'utilisation :
1. Modèle d’analyse du cas d’utilisation «consulter dossier
médical» :
1.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation «consulter dossier médical» :
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»
1.2. Modèle de classe d’analyse d’utilisation « consulter dossier médical» :
Figure 129 : Modèle de classe d’analyse d’utilisation « consulter dossier médical»
<trace>
<participate><participate><participate>
médecin
imprimer dossier
medical
imprimer Dossier
Medical
controleur dossier medical
dossier medicalinerface dossier medical
médecin
interface liste dossier médical
controleur dossier médical
dossier médical

111. 98
1.3. Diagramme de séquence détaillée du cas «consulter dossier médical» :
Figure 130 : diagramme de séquence détaillée du cas «consulter dossier médical»
2. Modèle d’analyse du cas d’utilisation du cas «imprimer dossier médical» :
2.1. Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas
d’utilisation «imprimer dossier médical» :
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 »
consulter dossier médical
afficher dossier médical
réponse
envoyer requête
envoyer demande
sélectionner le dossier médical qu'il veut
consulter
afficher le dossier médical
cliquer sur dossier médical
médecin Iliste dossier médical Dossier medecal dossier medical
ref s'authentifier()
afficher dossier médical
réponse
envoyer requête
envoyer demande
sélectionner le dossier médical qu'il veut
consulter
afficher le dossier médical
cliquer sur dossier médical
<trace>
<participate><participate><participate>
médecin
imprimer dossier
medical
imprimer Dossier
Medical
controleur dossier medical
dossier medicalinerface dossier medical

112. 99
2.2. Modèle de classe d’analyse d’utilisation « imprimer dossier médical» :
Figure 132 : Modèle de classe d’analyse d’utilisation «imprimer dossier médical»
2.3. Digramme de séquence détaillée du cas «imprimer dossier médical» :
La figure 133 illustre le diagramme de séquence. Le médecin peut imprimer le dossier
médical.
Figure 133: Diagramme de séquence détaillée du cas «imprimer dossier médical»
médecin
interface dossier médical
controlleur dossier médical
dossier médical
imprimer dossier médical
envoyer requête
envoyer demande
cliquer sur imprimer
réponse
cliquer sur dossier médical
afficher la liste de dossier médical
sélectionner le dossier médical à imprimer
envoyer demande
réponse
dossier médical imprimé
méedecin liste dossier medical dossier medical Dossier medical
ref
s'authentifier()
envoyer requête
envoyer demande
cliquer sur imprimer
réponse
cliquer sur dossier médical
afficher la liste de dossier médical
sélectionner le dossier médical à imprimer
envoyer demande
réponse
dossier médical imprimé

113. 100
3. Diagramme de classe global du troisième sprint:
Figure 134: diagramme de classe global du troisième sprint
1..1
1..*
posséder
appartenir
1..*
1..*
1..1
1..*
1..1
1..*
1..1
1..*
1..1
1..1
1..1
1..*
1..1
0..*
1..1
1..1
1..*
1..1
1..*
1..1
1..1
1..1
appartenir
appartenir
posséder
appartenir
posséder
posséder
gérer
posséder
posséder
app_user
-
-
-
-
id app user
id user profil
login
mot de passe
: int
: int
: String
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
user profil
-
-
id user profil
rôle
: int
: String
rendez-vous
-
-
-
-
id rendez-vous
date
heure
id patient
: int
: Date
: Date
: int
+
+
+
ajouter ()
modifier ()
annuler ()
...
antécédent
-
-
-
-
id antécédent
description
nom
id catégorie antécédent
: int
: String
: String
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
...
catégorie antécédent
-
-
-
id catégorie antécédent
type
description
: int
: String
: String
consultation
-
-
-
-
-
-
-
-
id consultation
id antécédent
id examen
id ordonnance
date de consultation
id renddz-vous
id motif de consultation
id diagnostic
: int
: int
: int
: int
: Date
: int
: int
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
...
fiche patient
-
-
-
-
-
-
-
id patient
nom
prénom
date de naissance
num dossier
num tél
adresse
: int
: String
: String
: Date
: String
: int
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
données anthropométriques
-
-
-
-
id données anthropométriques
poid
PMC
pourcentage de masse
: int
: String
: String
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
...
examen
-
-
-
-
-
-
-
id examen
description examen abdominal
descriptionExamenCardio vascullaires
description examen neurologiques
description constantes vitales
descriptionExamen pleuro-pulmonaire
id données anthropométriques
: int
: String
: String
: String
: String
: String
: int
+
+
+
ajouter ()
modifier ()
supprimer ()
...
ordonnance
-
-
id ordonnance
description
: int
: String
+
+
+
ajouter ()
consulter ()
supprimer ()
app user user profil
-
-
id app user
id user profil
: int
: int
diagnostic
-
-
id diagnostic
type
: int
: String
+
+
+
ajouter ()
modifier ()
supprimer ()
dossier médical
-
-
-
id
id consultation
id patient
: int
: int
: int
+ consulter ()
motif de consultation
-
-
id motif de consltation
type
: int
: String
+ ajouter ()
...

114. 101
V. Codage :
 Schéma de la base de données «dossier médical » :
Attribue Type Contrainte
Id Int PRIMERY KEY
Id patient Int FRAIGERY KEY
Id consultation Int FRAIGER KEY
Tableau 44 : table « dossier médical »
VI. Test :
 Interface du dossier médical :
Figure 135: page dossier médical
Conclusion :
A ce niveau, nous avons réussi à développer le dernier sprint de notre application pour arriver
à un produit complet et fonctionnel.
Il nous reste uniquement une dernière étape qui comporte l’implémentation de l’application.
101
V. Codage :
 Schéma de la base de données «dossier médical » :
Attribue Type Contrainte
Id Int PRIMERY KEY
Id patient Int FRAIGERY KEY
Id consultation Int FRAIGER KEY
Tableau 44 : table « dossier médical »
VI. Test :
 Interface du dossier médical :
Figure 135: page dossier médical
Conclusion :
A ce niveau, nous avons réussi à développer le dernier sprint de notre application pour arriver
à un produit complet et fonctionnel.
Il nous reste uniquement une dernière étape qui comporte l’implémentation de l’application.
101
V. Codage :
 Schéma de la base de données «dossier médical » :
Attribue Type Contrainte
Id Int PRIMERY KEY
Id patient Int FRAIGERY KEY
Id consultation Int FRAIGER KEY
Tableau 44 : table « dossier médical »
VI. Test :
 Interface du dossier médical :
Figure 135: page dossier médical
Conclusion :
A ce niveau, nous avons réussi à développer le dernier sprint de notre application pour arriver
à un produit complet et fonctionnel.
Il nous reste uniquement une dernière étape qui comporte l’implémentation de l’application.

115. 102
Chapitre VI : phase de clôture
Introduction :
Dans ce dernier chapitre, nous allons présenter la phase de clôture qui est la dernière phase
dans le cycle de développement d’un logiciel avec Scrum.
La phase de clôture est plus connue sous le nom du sprint de stabilisation.
Il s’agira de définir les différents outils technologiques et l’environnement du développement
auxquels nous avons eu recours.
Nous présenterons le diagramme de déploiement qui permet de décrire l’architecture de
notre plate-forme, aussi qu’une schématisation des différentes tâches effectuées au cours du
notre stage.
I. Environnement de développement :
1. Environnement matériel :
Pour le développement de notre application, nous avons utilisé :
Ordinateur 1 2
Propriétaire Soumaya nebli Ibtissem slimeni
Processus Core i3 Pentium
RAM 4 GO 4 GO
Disque dur 500 GO 500 GO
Système d’exploitation Windows 10 professionnel
32bits
Windows 10 professionnel
64bits
2. Environnement logiciel :
MYSQL : est un système de gestion de bases de données
relationnelles (SGBDR) qui permet de gérer les bases de données.
Word : est un logiciel du traitement du texte qui permet la création, la
modification et la mise en forme des documents qu’on veut transmettre ou imprimer.
102
Chapitre VI : phase de clôture
Introduction :
Dans ce dernier chapitre, nous allons présenter la phase de clôture qui est la dernière phase
dans le cycle de développement d’un logiciel avec Scrum.
La phase de clôture est plus connue sous le nom du sprint de stabilisation.
Il s’agira de définir les différents outils technologiques et l’environnement du développement
auxquels nous avons eu recours.
Nous présenterons le diagramme de déploiement qui permet de décrire l’architecture de
notre plate-forme, aussi qu’une schématisation des différentes tâches effectuées au cours du
notre stage.
I. Environnement de développement :
1. Environnement matériel :
Pour le développement de notre application, nous avons utilisé :
Ordinateur 1 2
Propriétaire Soumaya nebli Ibtissem slimeni
Processus Core i3 Pentium
RAM 4 GO 4 GO
Disque dur 500 GO 500 GO
Système d’exploitation Windows 10 professionnel
32bits
Windows 10 professionnel
64bits
2. Environnement logiciel :
MYSQL : est un système de gestion de bases de données
relationnelles (SGBDR) qui permet de gérer les bases de données.
Word : est un logiciel du traitement du texte qui permet la création, la
modification et la mise en forme des documents qu’on veut transmettre ou imprimer.
102
Chapitre VI : phase de clôture
Introduction :
Dans ce dernier chapitre, nous allons présenter la phase de clôture qui est la dernière phase
dans le cycle de développement d’un logiciel avec Scrum.
La phase de clôture est plus connue sous le nom du sprint de stabilisation.
Il s’agira de définir les différents outils technologiques et l’environnement du développement
auxquels nous avons eu recours.
Nous présenterons le diagramme de déploiement qui permet de décrire l’architecture de
notre plate-forme, aussi qu’une schématisation des différentes tâches effectuées au cours du
notre stage.
I. Environnement de développement :
1. Environnement matériel :
Pour le développement de notre application, nous avons utilisé :
Ordinateur 1 2
Propriétaire Soumaya nebli Ibtissem slimeni
Processus Core i3 Pentium
RAM 4 GO 4 GO
Disque dur 500 GO 500 GO
Système d’exploitation Windows 10 professionnel
32bits
Windows 10 professionnel
64bits
2. Environnement logiciel :
MYSQL : est un système de gestion de bases de données
relationnelles (SGBDR) qui permet de gérer les bases de données.
Word : est un logiciel du traitement du texte qui permet la création, la
modification et la mise en forme des documents qu’on veut transmettre ou imprimer.

116. 103
Eclipse : est un environnement de développement dont se fait la création
des projets de développement en mettant en œuvre n’importe quel langage de
programmation.
Il est principalement écrit en java.
GANTT Project : est un logiciel qui permet de modéliser la
planification des différentes missions nécessaires à un projet.
Tomcat : est un serveur d’application java. Il permet de générer des
applications web.
Power AMC : est un outil de modélisation qui permet d’élaborer des
modèles de données (merise, UML) et qui permet aussi de faire le lien entre données et
processus.
3. Technologies et Langage de programmation utilisée :
J2EE (JAVA Entreprise Edition) : est une plate-forme de développement
qui permet de développer des applications web.
Hibernate : est un Framework de persistance qui permet de
représenter une base de données en objet java.
103
Eclipse : est un environnement de développement dont se fait la création
des projets de développement en mettant en œuvre n’importe quel langage de
programmation.
Il est principalement écrit en java.
GANTT Project : est un logiciel qui permet de modéliser la
planification des différentes missions nécessaires à un projet.
Tomcat : est un serveur d’application java. Il permet de générer des
applications web.
Power AMC : est un outil de modélisation qui permet d’élaborer des
modèles de données (merise, UML) et qui permet aussi de faire le lien entre données et
processus.
3. Technologies et Langage de programmation utilisée :
J2EE (JAVA Entreprise Edition) : est une plate-forme de développement
qui permet de développer des applications web.
Hibernate : est un Framework de persistance qui permet de
représenter une base de données en objet java.
103
Eclipse : est un environnement de développement dont se fait la création
des projets de développement en mettant en œuvre n’importe quel langage de
programmation.
Il est principalement écrit en java.
GANTT Project : est un logiciel qui permet de modéliser la
planification des différentes missions nécessaires à un projet.
Tomcat : est un serveur d’application java. Il permet de générer des
applications web.
Power AMC : est un outil de modélisation qui permet d’élaborer des
modèles de données (merise, UML) et qui permet aussi de faire le lien entre données et
processus.
3. Technologies et Langage de programmation utilisée :
J2EE (JAVA Entreprise Edition) : est une plate-forme de développement
qui permet de développer des applications web.
Hibernate : est un Framework de persistance qui permet de
représenter une base de données en objet java.

117. 104
JSP (Java Server Page) : est une technologie java qui permet de
générer une page web dynamique.
CSS : (Cascading Style Sheets) : est un langage de style utilisé pour
améliorer les pages HTML.
JavaScript (JS) : est un langage de Script, suivant Java essentiellement utilisée
pour le web.
JQuery : est une bibliothèque JavaScript qui permet de faciliter des
fonctionnalités de JavaScript.
II. Style architectural :
L’architecture MVC (Modèle, Vue et Contrôleur) est un concept qui intervient dans la
réalisation d’une application. Elle est responsable de la répartition des données (Modèle), de
l’affichage (Vue) et des actions (Contrôleur).
 La vue :
La vue représente l’interface d’utilisateur. Il permet d’afficher seulement les données fournies
par les modèles.
 Le modèle :
Le modèle représente les données et les règles métiers. Il permet de gérer les données de
session ou les fonctionnalités de base de données.
104
JSP (Java Server Page) : est une technologie java qui permet de
générer une page web dynamique.
CSS : (Cascading Style Sheets) : est un langage de style utilisé pour
améliorer les pages HTML.
JavaScript (JS) : est un langage de Script, suivant Java essentiellement utilisée
pour le web.
JQuery : est une bibliothèque JavaScript qui permet de faciliter des
fonctionnalités de JavaScript.
II. Style architectural :
L’architecture MVC (Modèle, Vue et Contrôleur) est un concept qui intervient dans la
réalisation d’une application. Elle est responsable de la répartition des données (Modèle), de
l’affichage (Vue) et des actions (Contrôleur).
 La vue :
La vue représente l’interface d’utilisateur. Il permet d’afficher seulement les données fournies
par les modèles.
 Le modèle :
Le modèle représente les données et les règles métiers. Il permet de gérer les données de
session ou les fonctionnalités de base de données.
104
JSP (Java Server Page) : est une technologie java qui permet de
générer une page web dynamique.
CSS : (Cascading Style Sheets) : est un langage de style utilisé pour
améliorer les pages HTML.
JavaScript (JS) : est un langage de Script, suivant Java essentiellement utilisée
pour le web.
JQuery : est une bibliothèque JavaScript qui permet de faciliter des
fonctionnalités de JavaScript.
II. Style architectural :
L’architecture MVC (Modèle, Vue et Contrôleur) est un concept qui intervient dans la
réalisation d’une application. Elle est responsable de la répartition des données (Modèle), de
l’affichage (Vue) et des actions (Contrôleur).
 La vue :
La vue représente l’interface d’utilisateur. Il permet d’afficher seulement les données fournies
par les modèles.
 Le modèle :
Le modèle représente les données et les règles métiers. Il permet de gérer les données de
session ou les fonctionnalités de base de données.

118. 105
 Le contrôleur :
Le contrôle permet la récupération des données d’utilisateur (modèle) et déclencher les
traitements appropriés (vue).
Comme se présente dans la figure suivant :
Figure 136: niveau de l’architecture
III. Elaboration du diagramme de déploiement :
« Les diagrammes de déploiement modélisent l’architecture physique d’un système. Les
diagrammes de déploiement affichent les relations entre les composants logiciels et
matériels du système et la distribution physique du traitement. » [13]
105
 Le contrôleur :
Le contrôle permet la récupération des données d’utilisateur (modèle) et déclencher les
traitements appropriés (vue).
Comme se présente dans la figure suivant :
Figure 136: niveau de l’architecture
III. Elaboration du diagramme de déploiement :
« Les diagrammes de déploiement modélisent l’architecture physique d’un système. Les
diagrammes de déploiement affichent les relations entre les composants logiciels et
matériels du système et la distribution physique du traitement. » [13]
105
 Le contrôleur :
Le contrôle permet la récupération des données d’utilisateur (modèle) et déclencher les
traitements appropriés (vue).
Comme se présente dans la figure suivant :
Figure 136: niveau de l’architecture
III. Elaboration du diagramme de déploiement :
« Les diagrammes de déploiement modélisent l’architecture physique d’un système. Les
diagrammes de déploiement affichent les relations entre les composants logiciels et
matériels du système et la distribution physique du traitement. » [13]

119. 106
1. Diagramme de déploiement :
Figure 137 : Diagramme de déploiement
2. Diagramme de Gantt :
« Le diagramme de Gantt, couramment utilisé en gestion du projet, est l'un des outils les plus
efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches)
qui constituent un projet » [14]
Figure 138: Diagramme de Gantt
Conclusion :
Dans ce chapitre, nous avons présenté les différents travaux qui aident à un bon déroulement
de projet selon le cycle de développement Scrum. Par la suite, nous avons aussi décrit les
technologies adoptées .Enfin, nous avons présenté le diagramme de déploiement de notre
plate-forme et le diagramme de Gantt.
<HTTP>
<JDBC>
pc
navigateur web
serveur d'application
TomCat
serveur de base de données
MYSQL
utilisateur
106
1. Diagramme de déploiement :
Figure 137 : Diagramme de déploiement
2. Diagramme de Gantt :
« Le diagramme de Gantt, couramment utilisé en gestion du projet, est l'un des outils les plus
efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches)
qui constituent un projet » [14]
Figure 138: Diagramme de Gantt
Conclusion :
Dans ce chapitre, nous avons présenté les différents travaux qui aident à un bon déroulement
de projet selon le cycle de développement Scrum. Par la suite, nous avons aussi décrit les
technologies adoptées .Enfin, nous avons présenté le diagramme de déploiement de notre
plate-forme et le diagramme de Gantt.
<HTTP>
<JDBC>
pc
navigateur web
serveur d'application
TomCat
serveur de base de données
MYSQL
utilisateur
106
1. Diagramme de déploiement :
Figure 137 : Diagramme de déploiement
2. Diagramme de Gantt :
« Le diagramme de Gantt, couramment utilisé en gestion du projet, est l'un des outils les plus
efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches)
qui constituent un projet » [14]
Figure 138: Diagramme de Gantt
Conclusion :
Dans ce chapitre, nous avons présenté les différents travaux qui aident à un bon déroulement
de projet selon le cycle de développement Scrum. Par la suite, nous avons aussi décrit les
technologies adoptées .Enfin, nous avons présenté le diagramme de déploiement de notre
plate-forme et le diagramme de Gantt.
<HTTP>
<JDBC>
pc
navigateur web
serveur d'application
TomCat
serveur de base de données
MYSQL
utilisateur

120. 107
Conclusion générale
Dans le cadre du projet de fin d’études pour l’acquisition de la licence appliquée en commerce
électronique à l’ESEN (École Supérieur d’ Économie numérique).
Nous avons effectué notre stage au sein de la boîte de développement ATH Consulting.
Le projet consiste à concevoir et réaliser une application web qui permet de développer une
plate-forme de gestion de cabinet de cardiologue.
Nous avons commencé dans un premier lieu par comprendre le contexte général de notre
application, qui s’est déroulé au sein de la société.
Nous avons poursuivi par l’étude de l’existant grâce à laquelle nous avons déterminé les
exigences et besoins du projet.
Nous avons appliqué les méthodes agiles dans la gestion et suivi du projet et nous avons
choisi la méthode scrum qui se base sur le principe des sprints.
Dans le cas de notre projet, nous avons passé par 3 sprints, les sprints se divisent comme suit :
on a commencé par les user stories et leurs spécificités, nous avons poursuivi par la
schématisation en diagrammes des cas d’utilisation liée aux fonctionnalités de l’application,
ensuite, nous avons décrit l’enchaînement des scénarios, enfin, nous avons terminé par la
conception, l’implémentation et le test.
Ce projet nous a permis de mettre en œuvre nos connaissances acquises au cours des trois
années d’études à l’ESEN.
La réalisation de ce projet était pour nous une expérience très enrichissante qui nous a
rapprochés au monde professionnel et au monde du développement.

121. 108
Bibliographie
[12] Pascal Roques, UML2 en action de l’analyse des besoins à la conception, 4Eme
Edition
Eyrolles ,2007
Neto graphie
[1] http://openmrs.org/about/ [accès le 15/03/2017]
[2] http://openmrs.org/about/mission/[accès le 15/03/2017]
[3] http://www.csys.com.tn/SiteWebCsys/index.html [Accès le 15/03/2017]
[4] http://ineumann.developpez.com/tutoriels/alm/agile_scrum/ [Accès le 16/03/2017]
[5]http://eric.quinton.free.fr/IMG/pdf/formation_UML-PHP-3.pdf [Accès le 20/04/2017]
[6] http://jerome.lenaou.free.fr/wp-content/uploads/Gestion_de_projet.pdf [Accès le 16/03/2017]
[7] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-FR.pdf [Accès le 17/03/2017]
[8] http://www.icauda.com/files/memento-scrum-equipe.pdf [Accès le 17/03/2017]
[9] http://geekandmore.fr/tag/scrum/ [Accès le 17/03/2017]
[10] https://www.areyouagile.com/pdf/pratiques_de_lagilite_2_1_15.pdf [Accès le 17/03/2017]
[11] http://media.agile42.com/do-better-scrum/DoBetterScrum-v3.02_FRs.pdf [Accès le 17/03/2017]
[13]http://www.ibm.com/support/knowledgecenter/fr/SS5JSH_9.1.2/com.ibm.xtools.modeler.
doc/topics/cdepd.html [Accès le 30/03/2017]
[14] http://www.gantt.com/fr/index.htm[Accès le 30/03/2017