Ben Abdallah 3 EB

Table des matières
Introduction générale 1
1 Cadre général du projet 3

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . 3
3.2 Fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Mission et outils d’Arabsoft . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Organigramme de l’organisme d’accueil . . . . . . . . . . . . . . . . . . 5
4 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Critiquer de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Méthodes Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Comparaison entre les méthodes classiques et les méthodes agiles . . . . 11
5.3 La méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Langage de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Phase de planification 13
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7
8 Table des matières
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Pilotage du projet avec la méthodologie SCRUM . . . . . . . . . . . . . 15
2.5 Organigramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . 17
3 Prototypage des interfaces de platforme . . . . . . . . . . . . . . . . . . . . . . 19
4 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Architecture de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Sprint 1 31
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Tableau des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Raffinement du cas d’utilisation «S’inscrire» . . . . . . . . . . . . . . . 33
4.2 Raffinement du cas d’utilisation «S’authentifier» . . . . . . . . . . . . . 34
4.3 Raffinement du cas d’utilisation «Gestion des comptes » . . . . . . . . . 36
5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 Conception statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Réalisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Sprint 2 49
Table des matières 9
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3 Tableau des taches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Raffinement du cas d’utilisation «Gestion des dossiers médicaux» . . . . 51
4.2 Raffinement du cas d’utilisation «Gestion fiche patient» . . . . . . . . . 54
4.3 Raffinement du cas d’utilisation «Gestion des consulations » . . . . . . . 58
5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5 Sprint 3 79
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3 Tableau des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4 Phase d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1 Raffinement du cas d’utilisation «Gestion des ordonnaces » . . . . . . . 81
4.2 Raffinement du cas d’utilisation «Gestion des certificats » . . . . . . . . 86
4.3 Raffinement du cas d’utilisation «Gestion des rendez-vous» . . . . . . . 90
5 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Conclusion 113
Table des figures
1.1 Logo de ARABSOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Organigramme ARABSOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Processus Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 L’équipe SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Organigramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Diagramme de cas d‘utilisation global . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Logo de Balsamiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Prototypage de l’interface de l’authentification . . . . . . . . . . . . . . . . . . . 19
2.5 Prototypage de l’interface de l’inscription . . . . . . . . . . . . . . . . . . . . . 20
2.6 Prototypage de l’interface de gestion des consultations . . . . . . . . . . . . . . . 20
2.7 Prototypage de l’interface de gestion des dossiers médicaux . . . . . . . . . . . 21
2.8 Prototypage de l’interface de gestion des ordonnances . . . . . . . . . . . . . . 21
2.9 Prototypage de l’interface de gestion des certificats . . . . . . . . . . . . . . . . 22
2.10 Prototypage de l’interface de gestion des rendez-vous . . . . . . . . . . . . . . . 22
2.11 Logo Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.12 Logo postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.13 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.14 Logo NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.15 Logo MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.16 Logo Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.17 Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.18 Draw.io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11
12 Table des figures
2.19 Logo Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.20 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.21 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 Les tâches du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Diagramme de cas d’utilisation «s’inscrire» . . . . . . . . . . . . . . . . . . . . 33
3.3 Diagramme de cas d’utilisation «S’authentifier» . . . . . . . . . . . . . . . . . . 35
3.4 Diagramme de cas d’utilisation «Gestion des comptes» . . . . . . . . . . . . . . 37
3.5 Diagramme de classe de sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Diagramme de séquence « s’inscrire » . . . . . . . . . . . . . . . . . . . . . . . 41
3.7 Diagramme de séquence « s’authentifier » . . . . . . . . . . . . . . . . . . . . . 42
3.8 Diagramme de séquence « consulter la liste des comptes » . . . . . . . . . . . . 43
3.9 Diagramme de séquence « Modifier compte » . . . . . . . . . . . . . . . . . . . 44
3.10 Diagramme de séquence «Supprimer compte » . . . . . . . . . . . . . . . . . . 45
3.11 Interface inscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.12 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.13 Interface gestion des comptes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.14 Succès d’ajout compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Tableau des taches du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Diagramme de cas d’utilisation «Gestion des dossiers médicaux »pour l’acteur «
Médecin » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Diagramme de cas d’utilisation «Gestion des dossiers médical » pour l’acteur
«Secrétaire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Diagramme de cas d’utilisation «Gestion les fiche» pour l’acteur «Secrétaire » . . 54
4.5 Diagramme de cas d’utilisation «Gestion les fiche» pour l’acteur «Médecin » . . 54
4.6 Diagramme de cas d’utilisation «Gestion des consultations» . . . . . . . . . . . 59
4.8 Diagramme de séquence «Consulter liste des dossiers médicaux» . . . . . . . . . 65
4.9 Diagramme de séquence « Supprimer dossier médical» . . . . . . . . . . . . . . 66
4.10 Diagramme de séquence « Ajouter Fiche patient » . . . . . . . . . . . . . . . . . 67
4.11 Diagramme de séquence «Modifier fiche patient» . . . . . . . . . . . . . . . . . 68
Table des figures 13
4.12 Diagramme de séquence «Supprimer fiche patient» . . . . . . . . . . . . . . . . 69

4.13 Diagramme de séquence « Consulter fiche patient» . . . . . . . . . . . . . . . . 70
4.14 Diagramme de séquence « Ajouter consultation » . . . . . . . . . . . . . . . . . 71
4.15 Diagramme de séquence « Consulter liste des consultations » . . . . . . . . . . . 72
4.16 Diagramme de séquence «Modifier consultation » . . . . . . . . . . . . . . . . . 73
4.17 Diagramme de séquence «Supprimer consultation » . . . . . . . . . . . . . . . . 74
4.18 Interface de consultation de la liste des dossier médical pour l’acteur médecin . . 75
4.19 Interface de consultation de la liste des dossier médical pour l’acteur secrétaire . 75
4.20 Interface d’ajout des fiches patientes . . . . . . . . . . . . . . . . . . . . . . . . 76
4.21 Interface de consultation de la pour fiche patient l’acteur médecin . . . . . . . . 76
4.22 Interface de consultation de la pour fiche patient l’acteur médecin . . . . . . . . 77
4.23 Interface d’ajout des consultations . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.24 Interface de consultation de la liste des consultation . . . . . . . . . . . . . . . . 78
5.1 Les tâches du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.2 Diagramme de cas d’utilisation «Gestion des ordonnace» . . . . . . . . . . . . . 81
5.3 Diagramme de cas d’utilisation «Gestion des certificats » . . . . . . . . . . . . . 86
5.4 Diagramme de cas d’utilisation «Gestion des rendez-vous » . . . . . . . . . . . 90
5.5 Diagramme de cas d’utilisation «Gestion des rendez-vous » . . . . . . . . . . . 91
5.7 Diagramme de séquence «Ajouter ordonnance » . . . . . . . . . . . . . . . . . . 96
5.8 Diagramme de séquence « Modifier ordonnance » . . . . . . . . . . . . . . . . . 97
5.9 Diagramme de séquence « Supprimer ordonnance » . . . . . . . . . . . . . . . . 98
5.10 Diagramme de séquence « consulter ordonnance » . . . . . . . . . . . . . . . . . 99
5.11 Diagramme de séquence « Ajouter certificat » . . . . . . . . . . . . . . . . . . . 100
5.12 Diagramme de séquence « Modifier ordonnance » . . . . . . . . . . . . . . . . . 101
5.13 Diagramme de séquence « Supprimer certificat » . . . . . . . . . . . . . . . . . 102
5.14 Diagramme de séquence « Consulter certificat » . . . . . . . . . . . . . . . . . . 103
5.15 Diagramme de séquence « Ajouter rendez-vous » . . . . . . . . . . . . . . . . . 104
5.16 Diagramme de séquence « Modifier rendez-vous » . . . . . . . . . . . . . . . . . 105
5.17 Diagramme de séquence « Supprimer rendez-vous » . . . . . . . . . . . . . . . . 106
14 Table des figures
5.18 Diagramme de séquence « Consulter rendez-vous » . . . . . . . . . . . . . . . . 107

5.19 Interface d’ajout des ordonnances . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.20 Interface de consultation de la liste des ordonnances . . . . . . . . . . . . . . . . 108
5.21 Interface d’ajout des certificats . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.22 Interface de consultation de la liste des certificats . . . . . . . . . . . . . . . . . 109
5.23 Interface d’ajout des rendez-vous . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.24 Interface de consultation de la liste des rendez-vous pour l’acteur « Secrétaire » . 110
5.25 Interface de consultation de la liste des rendez-vous pour l’acteur « Médecin » . 111
Liste des tableaux
1.1 Tableau fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Tableau Mission et outils d’Arabsoft . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Tableau de artéfacts d’un projet SCRUM . . . . . . . . . . . . . . . . . . . . . 11
2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Scénarios d’exécution du cas d’utilisation «S’inscrire» . . . . . . . . . . . . . . 34
3.3 Scénarios d’exécution du cas d’utilisation «S’authentifier» . . . . . . . . . . . . 36
3.4 Scénarios d’exécution du cas d’utilisation «Consulter la liste des comptes» . . . . 37
3.5 Scénarios d’exécution du cas d’utilisation «Modifier compte» . . . . . . . . . . . 38
3.6 Scénarios d’exécution du cas d’utilisation «Supprimer Compte» . . . . . . . . . 39

4.2 Scénarios d’exécution du cas d’utilisation «consulter des dossiers médicaux» . . 52
4.3 Scénarios d’exécution du cas d’utilisation «supprimer dossier médical» . . . . . 53
4.4 Scénarios d’exécution du cas d’utilisation «Ajouter fiche patient » . . . . . . . . 55
4.5 Scénarios d’exécution du cas d’utilisation «Consulter fiche patient » . . . . . . . 56
4.6 Scénarios d’exécution du cas d’utilisation «Modifier fiche patient » . . . . . . . . 57
4.7 Scénarios d’exécution du cas d’utilisation « Supprimer fiche patient » . . . . . . 58
4.8 Scénarios d’exécution du cas d’utilisation «Ajouter consultation » . . . . . . . . 60
4.9 Scénarios d’exécution du cas d’utilisation «Consulter la liste des consultation » . 61
15
16 Liste des tableaux
4.10 Scénarios d’exécution du cas d’utilisation « Modifier consultation » . . . . . . . 62

4.11 Scénarios d’exécution du cas d’utilisation «Supprimer consultation» . . . . . . . 63

5.2 Scénarios d’exécution du cas d’utilisation «Ajouter ordonnance » . . . . . . . . . 82
5.3 Scénarios d’exécution du cas d’utilisation «Consulter des ordonnances» . . . . . 83
5.4 Scénarios d’exécution du cas d’utilisation «Supprimer ordonnance» . . . . . . . 84
5.5 Scénarios d’exécution du cas d’utilisation «Modifier ordonnance » . . . . . . . . 85
5.6 Scénarios d’exécution du cas d’utilisation «Ajouter certificat » . . . . . . . . . . 87
5.7 Scénarios d’exécution du cas d’utilisation «Modifier certificat » . . . . . . . . . 88
5.8 Scénarios d’exécution du cas d’utilisation «supprimer certificat» . . . . . . . . . 89
5.9 Scénarios d’exécution du cas d’utilisation «consulter certificat » . . . . . . . . . 90
5.10 Scénarios d’exécution du cas d’utilisation «Ajouter rendez-vous » . . . . . . . . 91
5.11 Scénarios d’exécution du cas d’utilisation « Consulter rendez-vous » . . . . . . . 92
5.12 Scénarios d’exécution du cas d’utilisation « Modifier rendez-vous » . . . . . . . 93
5.13 Scénarios d’exécution du cas d’utilisation « Supprimer rendez-vous » . . . . . . 94
Introduction générale
Avec l’évolution des demandes des utilisateurs et l’émergence de nouvelles technologies pour
stocker l’information et y accéder quand on le souhaite, de nombreux particuliers sont intéressés
à investir dans le domaine des applications de gestion et chaque entreprise souhaite maîtriser la
gestion de ces systèmes d’information.
L’évolution rapide des technologies de l’information et de la communication a ouvert de nou-

velles perspectives dans le domaine de la gestion des dossiers médicaux. Dans ce contexte, ce
projet de fin d’études vise à concevoir et développer une plateforme innovante de gestion de
dossiers médicaux. Cette plateforme permettra de centraliser, sécuriser et faciliter l’accès aux in-
formations médicales des patients, tout en optimisant les processus de travail des professionnels
de la santé. L’objectif ultime est d’améliorer la qualité des soins et de favoriser la collaboration
entre les différents acteurs du domaine médical.
Les cabinets médicaux jouent un rôle essentiel dans la prestation de soins de santé à la popu-
lation. Cependant, la gestion manuelle des dossiers médicaux peut s’avérer fastidieuse, chrono-
phage et sujette aux erreurs. Dans un monde de plus en plus numérisé, il est primordial d’adopter
des solutions technologiques efficaces pour faciliter cette gestion.
Le rapport sera composé de cinq chapitres :
- Le premier chapitre est constituée de la présentation générale de projet, la solution pro-

posée et la méthodologie utilisée.
- Le deuxième chapitre s‘intitule «Phase de planification » est composeé l‘identification des

acteurs, besoins fonctionnels et non fonctionnels ainsi que le Backlog du produit, l‘organigramme
des taches et l‘architecture du projet.
- Le troisième chapitre s‘intitule «Sprint 1», le rôle de ce chapitre est de présenter le pre-
mier sprint d’où nous allons élaborer l’analyse, la conception, la réalisation et les tests du sprint 1.
1
2 Introduction
- Le quatrième chapitre s’intitule «Sprint 2», le rôle de ce chapitre est de présenter le

deuxième sprint d’où nous allons élaborer l‘analyse, la conception, la réalisation et les tests
du sprint 2.
- Le cinquième chapitre s’intitule «Sprint 3», le rôle de ce chapitre est de présenter le troi-
sième sprint d’où nous allons élaborer l‘analyse, la conception, la réalisation et les tests du sprint
3.
- Le rapport se termine par une conclusion générale qui va récapituler tout ce qui a été énoncé
dans le rapport.
Chapitre 1
Cadre général du projet

1 Introduction
Dans ce chapitre, nous allons évoquer brièvement l’historique de l’organisme d’accueil, ses
missions et son organisation. Par la suite, nous allons introduire le contexte du projet et faire une
étude de l’existant. Enfin, nous allons nous intéresser à la présentation de la solution proposée et
la méthode du travail adoptée.
2 Cadre du projet
Ce travail est effectué dans le cadre de projet de fin d’étude en vue de l’obtention de Diplôme
de licence en Informatique Décisionnelle à la Faculté des Sciences Juridiques, Économiques
et de Gestion de Jendouba.
Ce projet est réalisé au sein de la société ARABSOFT durant trois mois. Son objectif prin-
cipal est le développement d’une plateforme de gestion des dossiers médicaux .
3 Organisme d’accueil
Nous allons présenter, dans cette section, l’organisme d’accueil.
3.1 Présentation de l’organisme d’accueil

La société Arabsoft a été créée en 1985 avec un effectif de 8 employés et disposant actuelle-
ment d’une équipe dépassant les 130 employés .
3
4 Chapitre 1. Cadre général du projet
La société Arabsoft a connu dès sa première année d’existence une croissance rapide qui
l’a propulsée au rang de leader nationale en ingénierie de software anticipant ainsi l’évolution
inévitable de l’ensemble de marché.[1]
F IGURE 1.1 – Logo de ARABSOFT
3.2 Fiche signalétique
Raison sociale Arabsoft

Date de création de la so- 1985
ciété
Nom et Prénom du respon- Mohamed Triki
sable
Potentiel Technicitié 130 employés dont 115 représentant l’ef-
fectif -Technique (concepteurs, dévelop-
peurs, formateurs)
TABLE 1.1 – Tableau fiche signalétique
3.3 Mission et outils d’Arabsoft

La société Arabsoft a pour mission d’effectuer l’étude, la conception, le développement de
logiciels sectoriels spécifique, le développement de logiciels standards, le développement de
sites WEB dynamiques, la formation sur les logiciels conçus et distribués et le déploiement
de solutions en architectures clients/serveurs et n -tiers. Depuis 1996, et dans un souci d’être
toujours en tête, la société Arabsoft a opté pour une stratégie d’utilisation de nouveaux concepts
de conception et développement dont nous pouvons citer :
3. Organisme d’accueil 5
Les méthodologies de Merise, UML.

conception
Les outils de conceptions DESIGNER 2000, AMC DESI-
GNER, RATIONAL ROSE.
Les systèmes d’exploitation UNIX, SOLARIS, LI-
maîtrisés et utilisés NUX,WINDOWS NT, WINDOWS
2000, WINDOWS XP.
Les outils de développe- 130 employés dont 115 représen-
ments pour le Web tant l’effectif -Technique (concep-
teurs, développeurs, formateurs)
Les outils de développe- SP, ASP, PHP, JAVA
ments pour le Web SCRIPT,COLD FUSION STUDIO,
J DEVELOPER.
Communication Réseau Ethernet, TPC/IP, WIRE-
LESS, etc
TABLE 1.2 – Tableau Mission et outils d’Arabsoft
3.4 Organigramme de l’organisme d’accueil

L’organisation de ARABSOFT est modélisée par l’organigramme présenté dans la figure
1.2 :
F IGURE 1.2 – Organigramme ARABSOFT

4. Analyse de l’existant 7
4 Analyse de l’existant
Pour mieux nous situer dans notre projet, nous allons étudier l’existant et le critiquer.
4.1 Description de l’existant
La gestion des dossiers médicaux et des rendez-vous dans de nombreux cabinets médicaux
se fait encore de manière manuelle et sur papier. .
4.2 Critiquer de l’existant
Critiquer de l’existant nous a permis d’identifier les lacunes suivantes dans la gestion des
dossiers médical :
— Absence d’accès direct a l’information des patients

— Il existe des nombreux dossiers médicaux sur papier .
— Perte de temps.
— Risque perte des dossiers médicaux.
— Manque de sécurité de l’information.
— Gestion non automatique des rondez-vous.
4.3 Solution proposée
L’étude des existants a montré de nombreux problèmes, nous proposons donc une solution
qui pourrait aboutir au développement d’une plateforme de gestion des dossiers médicaux.
Cette plateforme a pour objectif de :
— Gestion et suivi les fiches patients.

— Gestion et suivi les consultations .
— Gestion et suivi les certificats.
— Gestion et suivi les ordonnances.
— Gestion et suivi les dossiers médicales.
— Facilite de la gestion les rendez-vous.
— Réduire le temps d’accès au données.
— Amélioration de la fiabilité et de la sécurité des donnes.
5 Méthodologie de travail
Avant de mener à bien un projet informatique, il est nécessaire de choisir une méthodologie
de travail et un processus de suivi pour aboutir à un logiciel fiable.Au niveau de cette section.
5.1 Méthodes Agiles

Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit
collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en
prenant en compte l’évolution des besoins des clients . Une méthode agile assure une meilleure
communication avec le client et une meilleure visibilité de produit livrable .Elle permet aussi de
gérer la qualité en continu et de détecter des problèmes le plus tôt au fur et à mesure, permettant
ainsi d’entreprendre des actions correctrices sans trop des pénalités dans les couts et les délais.[2]
• Méthode SCRUM
La méthode SCRUM définit un cadre pour la réalisation de projets complexes. Initialement

conçue pour le développement de projets de type "Software", cette méthode peut s’appliquer à
tout type de projet, du plus simple au plus innovant, et ce de manière très simple.
Le principe de la méthodologie SCRUM est de développer un logiciel de manière progressi-
vement en maintenant une liste totalement transparente des demandes de changement ou des
correctifs à mettre en œuvre. Avec des versions très fréquentes, le client reçoit un logiciel fonc-
tionnel à chaque itération. Plus le projet avance, plus le logiciel est complet et il a toujours de
plus en plus de fonctionnalités. Comme on peut le voir sur cette figure, pour mettre en place la
méthode SCRUM, il faut d’abord définir les différentes fonctionnalités de notre application qui
composent le portefeuille de produits.[3]
5. Méthodologie de travail 9
F IGURE 1.3 – Processus Scrum
• Les acteurs d’un projet SCRUM
L’équipe SCRUM est pluridisciplinaire et autogéré. Elle est composée de trois rôles (Fig 1.3)
:
F IGURE 1.4 – L’équipe SCRUM
1/ Product Owner
C’est la personne chargée de définir la vision du produit, de prioriser les fonctionnalités à déve-
lopper, et de s’assurer que l’équipe de développement travaille sur les tâches les plus importantes
pour atteindre les objectifs commerciaux de l’entreprise.
2/ Le Scrum Master
C’est le garant du respect de la méthodologie SCRUM et de l’application des bonnes pratiques
associées. Il facilite la communication entre les membres de l’équipe et s’assure que les rituels
SCRUM sont respectés.
3/ L’équipe de développement
C’est le groupe de personnes responsables de la création du produit ou du service. Cette équipe
est auto-organisée et travaille de manière collaborative pour fournir des résultats de qualité.
• Les événements d’un projet SCRUM
1/ Sprint
Il s’agit d’une itération de courte durée, qui prend généralement 2 à 4 semaines, au cours de
laquelle nous devons livrer un incrément de la solution finale. Chaque sprint a une durée fixe,
un objectif et un périmètre (Sprint Backlog) qui peut être renégocié entre l’équipe et le Product
Owner.[4]
2/ Sprint Planning
La planification du sprint est une cérémonie Scrum qui lance le sprint. Elle a pour objectif de
définir ce qui peut être livré dans le sprint et comment y parvenir. La planification du sprint est
effectuée en collaboration avec toute l’équipe Scrum.[5]
3/ Daily Scrum
C’est une réunion de 15 minutes au cours duquel le Scrum master, le Product Owner et l’équipe
rappellent le travail effectué au cours des dernières 24 heures et planifient ce qui doit être fait
dans les prochaines 24 heures.[6]
4/ Sprint Review
C’est une réunion effectue à la fin du chaque sprint. Au sein de cette réunion l’équipe Scrum
présente les éléments de Product Backlog qui a été réalisé au cours de sprint. [7]
5/ Sprint Rétrospective
Cette réunion est interne à l’équipe Scrum et dure 3 heures pour un sprint d’un mois. Le but est
l’adaptation aux changements qui peuvent survenir et l’amélioration continue du processus de
réalisation.
5. Méthodologie de travail 11
5.2 Comparaison entre les méthodes classiques et les méthodes agiles
La comparaison entre les méthodes classiques et les méthodes agiles est présenté dans le
tableau 1.1.
Caractéristiques Approche classique Approche Agile

Cycle de vie en cascade ou on v , Phases itératif et incrémentale
séquentielles .
Documentation Produit en quantité important Réduit au strict nécessaire
Équipe Equipe avec ressources spé- Equipe responsabilisée, sou-
cialisés dirigées par un chef tenue par le chef de projet
de projet
Planification Prédictive Adaptative
Qualité Contrôle qualité à la fin de Contrôle qualité permanant
cycle de développement . le au niveau du produit et du
client découvre le produit fini processus , le client visualise
les résultats tot et fréquement
Gestion des risques Processus district et rigou- Getion des risque intégrée
reux de gestion des risques. dans le processus global
Mesure des succès Respect des engagements ini- Satisfaction du client par la li-
tiaux en termes de couts, de vraison de valeur souhaitée
budget et de niveau de qualité
TABLE 1.3 – Tableau de artéfacts d’un projet SCRUM
5.3 La méthode adoptée
Dans cette partie, nous présentons notre méthode de développement adoptée. Notre choix
s’est porté sur la méthode Scrum car elle répond aux caractéristiques des méthodes agiles défi-
nies dans la section précédente. Nous avons choisi la méthode Scrum pour les raisons suivantes :
• Développer et tester les courtes itérations.
• Produire le maximum du travail dans la durée la plus courte.
• Augmenter de la productivité.
• Adapter le logiciel crée suivant l’évolution du projet.
6 Langage de modélisation
Pour concevoir notre application, nous avons choisi UML [Unified Modeling Language] qui
est un langage de modélisation, qui permet de définir les modèles objets à travers un ensemble
de diagrammes.
En effet, c’est la méthode la plus convenable à notre projet qui se base sur le principe de la
programmation orientée objet. Ce langage possède une variété de diagrammes qui couvrent nos
besoins.
7 Conclusion
Dans le premier chapitre introductif, nous avons présenté la société Arabsoft et le cadre de
notre projet, puis nous avons proposé une solution qui peut répondre à nos besoins. Dans le pro-
chain chapitre, nous allons commencer la planification de notre projet.
Chapitre 2
Phase de planification
1 Introduction
Ce chapitre sera consacré a la réalisation de la première phase de la méthodologie Scrum
«Sprint 0» qui présente les fonctionnalités de base du projet, le diagramme des cas d’utilisation
global et le Product Backlog qui va nous permettre de planifier les releases.
2 Analyse des besoins

Cette section destinée a la spécification des besoins fonctionnels et non fonctionnels de la
solution ainsi que l’identification des acteurs.
2.1 Identification des acteurs

Avant de spécifier les besoins de notre client, la première tâche consiste à définir ce qui est
inclut ou pas dans le système. Nous devons identifier les différentes entités intervenantes sur le
système. Ces entités sont appelées acteurs qui jouent un rôle essentiel dans tous les projets infor-
matiques. Les acteurs qui vont interagir avec ce projet sont classifiés en trois catégories :
— Administrateur : L’administrateur joue un rôle primordiale et fondamental,il a pour rôle

la gestion des comptes de utilisateurs.
— Médecin : C’est le responsable de la gestion des consultations, des ordonnances, des

certificats. Consulter fiche patiente et les dossiers médicaux.
— Secrétaire : C’est le responsable de la gestion les rendez-vous ,gestion fiches patientes et

gestion dossiers médicaux.
13
14 Chapitre 2. Phase de planification
2.2 Besoins fonctionnels

Les exigences fonctionnelles (selon Tab 2.1) présentent les services et fonctionnalités que la
solution offre aux utilisateurs.
Fonctionnalités Description
Inscrire La création d’un profil permet aux utilisateurs d’accé-
der à la plateforme
Authentification Le système permet aux médecins et aux secrétaires
de s’authentifier après l’inscription pour la sécurité et
l’accès à la plateforme
Gestion des comptes Le système permet à l’administrateur de consulter,
modifier et supprimer des comptes des médecins et
aux secrétaires
Gestion des consultation Cette fonctionnalité permet aux médecin de consulter,
ajouter, modifier et supprimer les consultations
Gestion des ordonnances Cette fonctionnalité permet aux médecin de consulter,
ajouter, modifier et supprimer les ordonnances
Gestion des certificats Cette fonctionnalité permet aux médecin de consulter,
ajouter, modifier et supprimer les certificats
Gestion des dossiers médicaux Cette fonctionnalité Permets aux médecins et Secré-
taire de consulter les dossiers médicaux et permet aux
secrétaires ajouter, modifier et supprimer les certifi-
cats.
Gestion des fiches patientes Cette fonctionnalité permet Permets aux médecins
et Secrétaire de consulter les fiches patientes et per-
met aux secrétaires ajouter ,modifier et supprimer les
fiches patientes.
Gestion des rendez-vous Cette fonctionnalité Permets aux médecins et Secré-
taire de consulter les rendez-vous et permet aux secré-
taires ajouter, modifier et supprimer les rendez-vous .
TABLE 2.1 – Les besoins fonctionnels

2. Analyse des besoins 15
2.3 Besoins non fonctionnels

A part les besoins fondamentaux, Les besoins non fonctionnels décrivent toutes les contraintes
auxquelles est soumis le système pour sa réalisation et son bon fonctionnement.
— L’ergonomie des interfaces et la facilité d’utilisation : Design de la plateforme doit

être trés confortable et élégant et simple pour l’utilisateur.
— La performance : doit assurer la rapidité des activités et leurs fiabilités et être capable
de manipuler un grand nombre d’enregistrements.
— La maintenabilité : Le code doit être suffisamment clair pour permettre des éventuelles
évolutions, améliorations ou corrections.
— La sécurité : Le plateforme doit garantir à l’utilisateur l’intégrité et la confidentialité de
ses données.
2.4 Pilotage du projet avec la méthodologie SCRUM

a- Equipe SCRUM
Notre équipe de projet se compose de 3 membres :

— Product master : Mouhamed Gaith Ayadi.
— Product owner : ZIDI Mouadh.
— Team members : Ben abdallah Eya.
b- Le Product Backlog
Dans lequel le Product Owner crée une liste hiérarchisée de fonctionnalités appelée user story
qui pourrait être liée au produit.Cette liste évolue et change de priorité à chaque sprint.
Un Product Backlog inclut les champs suivants :
— Identifiant : c’est un nombre unique et auto-incrémenté pour chaque user story.
— Thème : c’est le sujet auquel une user story est reliée.
— User story : c’est une description courte de la tâche à réaliser.
— Priorité : c’est l’importance attribué par le product owner à cette tâche.

Le tableau suivant (Tab 2.2) présente le Backlog du produit.
TABLE 2.2 – Backlog du produit

2. Analyse des besoins 17
2.5 Organigramme des tâches

La figure ci-dessous présente l’organigramme des tâches
F IGURE 2.1 – Organigramme des tâches
2.6 Diagramme de cas d’utilisation global

Afin de présenter officiellement les fonctionnalités de notre système, nous utilisons le dia-
gramme du langage de modélisation UML.
La figure ci-dessous (Fig 2.2) représente le diagramme du cas d’utilisation général de notre
platforme. Ce diagramme illustre les différents acteurs ainsi que les cas d’utilisations affectés à
chacun de ces acteurs.
F IGURE 2.2 – Diagramme de cas d‘utilisation global

3. Prototypage des interfaces de platforme 19
3 Prototypage des interfaces de platforme

Nous avons créé des maquettes pour les interfaces de platforme, pour avoir une idée et une
vision graphique et ergonomique dés le début avec l’outil de prototypage Balsamiq (Fig 2.4).
F IGURE 2.3 – Logo de Balsamiq
Nous présentons ci-dessous quelques maquettes prévisionnelles des interfaces de platforme.
La figure 2.4 présente le Prototypage de l’interface de l’authentification .
F IGURE 2.4 – Prototypage de l’interface de l’authentification

La figure 2.5 présente le Prototypage de l’interface de l’inscription .
F IGURE 2.5 – Prototypage de l’interface de l’inscription
La figure 2.6 présente le Prototypage de l’interface de gestion des consultations .
F IGURE 2.6 – Prototypage de l’interface de gestion des consultations .

3. Prototypage des interfaces de platforme 21
La figure 2.7 présente le Prototypage de l’interface de gestion des dossiers médicaux .
F IGURE 2.7 – Prototypage de l’interface de gestion des dossiers médicaux
La figure 2.8 présente le Prototypage de l’interface de gestion des ordonnances .
F IGURE 2.8 – Prototypage de l’interface de gestion des ordonnances

La figure 2.9 présente le Prototypage de l’interface de gestion des certificats .
F IGURE 2.9 – Prototypage de l’interface de gestion des certificats
La figure 2.10 présente le Prototypage de l’interface de gestion des rendez-vous .
F IGURE 2.10 – Prototypage de l’interface de gestion des rendez-vous
4 Environnement de travail
Dans cette partie nous présentons l’environnement matériel et l’environnement technique
pour la réalisation de notre application.
4. Environnement de travail 23
4.1 Environnement matériel

Pour réaliser le projet, nous avons utilisé comme environnement matériel une machine qui
possède les caractéristiques suivantes :
TABLE 2.3 – Environnement matériel
4.2 Environnement logiciel

Dans cette partie, nous allons aborder les outils et les technologies qui ont servi à la réalisation
de notre plateforme.
a- Visual Studio Code
Visual Studio Code (Fig 2.11) est un éditeur de code open-source, gratuit et multiplateforme
(Windows, Mac et Linux), développé par Microsoft. Il fournit aux développeurs à la fois un en-
vironnement de développement intégré avec des outils permettant de faire avancer les projets
techniques, de l’édition, à la construction, jusqu’au débogage.[8]
F IGURE 2.11 – Logo Visual Studio Code
b- Postman
Postman (Fig 2.12) est un outil de devéloppement d’API qui sert à la création , le test, la
documentation, le contrôle, et la publication de la documentation des APIs des utilisateurs.[9]
F IGURE 2.12 – Logo postman
c- Angular
Angular(Fig 2.13) Angular est un framework qui permet de développer la partie frontale des
applications, Il est basé sur typeScript et lui-même est basé sur javascript, en plus c’est un Les
tendances technologiques fournissent les meilleurs solutions coté design.[10]
F IGURE 2.13 – Logo Angular
d - NodeJS
NodeJS (Fig 2.14) est la Framework que nous avons choisi pour développer notre partie backend
4. Environnement de travail 25
. Node.js est un environnement bas niveau permettant l’exécution de JavaScript côté serveur.
L’un des points forts de NodeJS c’est qu’il élimine l’attente et continue simplement avec la re-
quête suivante. Node.js exécute une programmation asynchrone à un seul thread, non bloquante,
qui est très économe en mémoire.[11]
F IGURE 2.14 – Logo NodeJS
f- MySQL
MySQL(Fig 2.15) MySQL est un système de gestion de bases de données relationnelles. Il est
distribué sous une double licence GPL et propriétaire. Le SQL dans "MySQL" signifie "Structu-
red Query Language" : le langage standard pour les traitements de bases de données.[12]
F IGURE 2.15 – Logo MySQL
g- Overleaf
Overleaf (Fig 2.16) est un éditeur LaTeX en ligne, collaboratif en temps réel.[13]
F IGURE 2.16 – Logo Overleaf

h- Trello
Trello (Fig 2.17) est un outil de gestion de projet en ligne.Il repose sur une organisation des pro-
jets en planches listant des cartes, chacune représentant des tâches. Les cartes sont assignables à
des utilisateurs et sont mobiles d’une planche à l’autre, traduisant leur avancement.[14]
F IGURE 2.17 – Trello
i-Draw.io
Draw.io (Fig 2.18) est une application gratuite en ligne, accessible via son navigateur (protocole
https) qui permet de dessiner des diagrammes ou des organigrammes. Cet outil vous propose de
concevoir toutes sortes de diagrammes, de dessins vectoriels, de les enregistrer au format XML
puis de les exporter. Draw.io est un veritable couteau suisse de la frise chronologique, de la carte
mentale et des diagrammes de tout genre.[15]
F IGURE 2.18 – Draw.io
j-Github
Github (Fig 2.19) est une plateforme open source de gestion de versions et de collaboration des-
tinée aux développeurs de logiciels. Livrée en tant que logiciel à la demande (SaaS, Software as
a Service), la solution GitHub a été lancée en 2008. Elle repose sur Git, un système de gestion de
code open source créé par Linus Torvalds dans le but d’accélérer le développement logiciel.[16]
NB : Lien de mon projet ( Front PFE [17] et Back PFE[18]).
F IGURE 2.19 – Logo Github

5. Architecture de la solution 27
5 Architecture de la solution
5.1 Architecture logicielle

L’architecture MVC (selon Fig 2.19) est l’une des architectures logicielles les plus utilisées
pour les application Web, elle se compose de 3 modules :
Modèle : (accès et mise à jour) noyau de l’application qui gère les données, permet de récu-
pérer les informations de la base de données, de les organiser pour qu’elles puissent ensuite être
traitées par le contrôleur.
Vue : composant graphique de l’interface qui permet de présenter les données du modèle à
l’utilisateur.
Contrôleur : composant responsable des prises de décision, gère la logique du code qui
prend des décisions, il est l’intermédiaire entre le modèle et la vue.
F IGURE 2.20 – Architecture logicielle
5.2 Architecture logique

Les fonctionnalités relatives aux besoins spécifiques de notre solution exigent une mise en
place d’une architecture bien étudiée afin d’assurer une meilleure performance.
C’est pour cette raison que dans notre projet, nous avons opté pour une architecture trois tiers
qui sert principalement à concevoir l’application en trois couches logicielles :
• La couche de présentation des données correspond à l’affichage et assure le dialogue avec

l’utilisateur.
• La couche de traitement qui assure à son tour la mise en œuvre des différentes règles et la
gestion de la logique applicative.
• La couche d’accès aux données correspond aux données qui sont destinées à être conser-
vées.
La figure ci-contre présente un schéma clair de l’architecture 3-tiers :
F IGURE 2.21 – Architecture logique

6. Conclusion 29
6 Conclusion
Dans ce chapitre, nous avons identifié les besoins fonctionnels et non fonctionnels des notre
système, ainsi que les acteurs. Ensuite, nous détaillons la première étape de la méthodologie
que nous avons choisie, à savoir l’identification de l’équipe de travail et la Backlog du produit
des sprints. Ensuite, nous introduisons l’environnement. matériel et logiciel que nous utiliserons
pour développer notre plateforme. Dans le chapitre suivant nous entamons le développement du
premier release.
Chapitre 3
Sprint 1
1 Introduction
Ce chapitre fait l’objet d’une présentation du premier sprint. L’étude de se sprint couvre
l’analyse, la conception, la réalisation et les tests.
2 Backlog du sprint
Le sprint est une période qui dure entre une et quatre semaines, au bout de cette période
l’équipe doit réaliser un incrément de produit livrable. Un nouveau sprint démarre lorsque le
précédent est terminé.
Le tableau ci-dessous présente le backlog de notre premier sprint
31
32 Chapitre 3. Sprint 1
ID Thème User Story

1 S’inscrire En tant que médecins ou secritaire je dois m’inscrire afin
que j’accède aux fonctionnalités offerte par la plateforme
2 s’authentifier En tant que administrator , médecins ou secritaire , je dois
m’authentifier afin que la plateforme doive être sécurisée
3 Gestion des
— En tant que administrateur, je dois gérer les comptes
comptes
des médecins ou secritaire
— En tant que administrateur je peux consulter la liste
des comptes
— En tant que administrateur, je peux supprimer des
comptes
— En tant que administrateur, je peux modifier des
comptes
TABLE 3.1 – Backlog du sprint 1
3 Tableau des tâches

Pour Scrum, le tableau des tâches (Fig 3.1) est un affichage visuel de la progression de
l’équipe Scrum au cours d’un sprint. Il est divisé en trois colonnes :
• À réaliser : Les tâches à réaliser
• En cours : Les tâches en cours
• Terminée : Les tâches réalisées
F IGURE 3.1 – Les tâches du sprint 1

4. Phase d’analyse 33
4 Phase d’analyse
Dans cette partie nous présentons la phase d’analyse qui répond à la question « que fait le
système ». La réponse de cette question se traduit par la présentation du diagramme des cas d’uti-
lisation puis la description textuelle de chacun d’entre eux.
4.1 Raffinement du cas d’utilisation «S’inscrire»

La figure 3.2 illustre le raffinement du cas d’utilisation «S’inscrire»
F IGURE 3.2 – Diagramme de cas d’utilisation «s’inscrire»
Les scénarios d’exécution du cas d’utilisation «s’inscrire» sont décrits par le tableau suivant
représentant la fiche descriptive du cas
Cas d’utilisation S’inscrire

Acteur médecins - secritaire
Pré condition Interface d’inscription consultée
Post condition Utilisateur inscrit
Scénario nominale
— Le Utilisateur demande la page d’ins-
cription
— Le système affiche la page demandée
— Le Utilisateur remplit le formulaire
d’inscription
— Le système vérifie les données saisies
— Le système ajoute le Utilisateur dans la
base de données
— Le système renvoie un message de la fin
e l’étape d’inscription avec sucées
Scénario alternatif
— Le système affiche un message d’erreur
informant le Utilisateur qu’il a laissé des
champs vides
TABLE 3.2 – Scénarios d’exécution du cas d’utilisation «S’inscrire»
4.2 Raffinement du cas d’utilisation «S’authentifier»

La figure 3.3 illustre le raffinement du cas d’utilisation «S’authentifier»
F IGURE 3.3 – Diagramme de cas d’utilisation «S’authentifier»
Les scénarios d’exécution du cas d’utilisation «S’authentifier» sont décrits par le tableau sui-
vant représentant la fiche descriptive du cas
Cas d’utilisation S’authentifier

Acteur administrateur – Médecins - Secritaire
Pré condition L’utilisateur doit être créé dans la base de don-
nées et connaître ses identifiants
Post condition Utilisateur authentifié
Scénario nominale
— L’utilisateur demande la page d’authen-
tification
— Le système lui affiche la page deman-
dée.
— L’utilisateur saisit son login et son mot
de passe
— L’utilisateur valide l’authentification
— Le système vérifie les informations sai-
sies par L’utilisateur
— Le système affiche la page d’accueil
— L’utilisateur n’a pas saisi les bons iden-
tifiants : Le système affiche un message
d’erreur informant l’utilisateur que son
login ou mot de passe sont incorrects
TABLE 3.3 – Scénarios d’exécution du cas d’utilisation «S’authentifier»
4.3 Raffinement du cas d’utilisation «Gestion des comptes »

La figure 3.4 illustre le raffinement du cas d’utilisation «Gestion des comptes »
F IGURE 3.4 – Diagramme de cas d’utilisation «Gestion des comptes»
Cas d’utilisation Consulter la liste des comptes

Acteur Administrateur
Pré condition administrateur authentifié
Post condition Comptes affichés
Scénario nominale
— L’ administrateur s’authentifie
— Le système affiche l’interface où les
comptes sont listés
— Aucun compte trouvé : Le système af-
fiche un message d’erreur "Table est
vide "
TABLE 3.4 – Scénarios d’exécution du cas d’utilisation «Consulter la liste des comptes»
Cas d’utilisation Modifier compte

Pré condition Administrateur authentifié , Comptes affichés
Post condition Compte modifié
Scénario nominale
— Le système affiche la liste des Utilisa-
teur
— L’ administrator choisir le compte et
clique sur le bouton «Modifier »
— Le système affiche formulaire de la mo-
dification .
— L’ administrator clique sur le bouton
«validé»
— Le système affiche un message indi-
quant que la modification s’est déroulée
avec succès
— Le IT manager saisit des données ou er-
ronées : Le système affiche un message
d’erreur.
TABLE 3.5 – Scénarios d’exécution du cas d’utilisation «Modifier compte»

5. Conception 39
Cas d’utilisation Supprimer compte

Pré condition Administrateur authentifié , Comptes affichés
Post condition Compte supprimé
Scénario nominale
— L’administrateur choisier le compte a
supprimer.
— L’administrateur clique sur le bouton
«Delete» pour supprimer le compte.
— Le système affiche message de confir-
mation supprision.
— Le système effectue la suppression.
— Le système affiche un message suppri-
mer avec sucées.
TABLE 3.6 – Scénarios d’exécution du cas d’utilisation «Supprimer Compte»
5 Conception
5.1 Conception statique

Diagramme de classe de Sprint 1
Une classe est un ensemble de fonctions et de données (attributs) qui sont liées ensemble par
un champ sémantique. Les classes sont utilisées dans la programmation orientée objet Une classe
est représentée par un rectangle séparé en trois parties :
— La première partie contient le nom de la classe

— La seconde contient les attributs de la classe
— La dernière contient les méthodes de la classe
La Fig 3.5 présente le diagramme de classe de sprint 1.

F IGURE 3.5 – Diagramme de classe de sprint 1
5.2 Conception dynamique

Diagrammes de séquence de Sprint 1
Pour notre plateforme , nous allons élaborer les diagrammes de séquence pour déterminer la
dynamique du système. Ce diagramme met en valeur les échanges de messages entre acteurs et
objets de manière chronologique.
Le principe de ce diagramme est de détailler de séquence système, il permet de découper le

système en trois objets :
— Interface
— Contrôle
— Entité
Diagramme de séquence "S’inscrire" Ce scénario commence avec l’utilisateur Demande d’af-

fichage du registre. tant que le formulaire est Affiché, l’utilisateur remplit les champs demandés.
les champs obligatoires non vide. Si tout est correct, le système envoie les données saisies à la
base de données. Les données à enregistrer, à la fin montrent le message d’enregistrement succès.
La figure ci-dessous illustre le diagramme de séquence associé à ce scénario
5. Conception 41
La Fig 3.6 présente le Diagramme de séquence «S’inscrire» .
F IGURE 3.6 – Diagramme de séquence « s’inscrire »

Diagramme de séquence « Authentification » Ce diagramme décrit les scénarios possibles

lors de l’authentification. L’utilisateur doit s’identifier par son email et votre mot de passe via
le serveur d’application qui prend en charge la vérification et consulter la base de données, si
accepté, vous aurez accès au système et au l’application depuis le menu correspondant, sinon le
serveur d’application affiche un message d’erreur .
La Fig 3.7 présente le Diagramme de séquence « S’authentifier ».
F IGURE 3.7 – Diagramme de séquence « s’authentifier »

5. Conception 43
Diagramme de séquence « consulter compte utilisateur » Ce scénario décrit l’opération de

requête de la liste des comptes utilisateurs .
La Fig 3.8 présente le Diagramme de séquence « consulter la liste des comptes ».
F IGURE 3.8 – Diagramme de séquence « consulter la liste des comptes »

Diagramme de séquence "Modifier compte " Ce scénario commence avec le adminstrateur

demande d’affichage du formulaire du modification compte et modifier les champs . les champs
obligatoires non vide. Si tout est correct, le système envoie les données à la base de données .Les
données à enregistrer, à la fin montrent le message d’modification succès
La Fig 3.9 présente le Diagramme de séquence « Modifier compte ».
F IGURE 3.9 – Diagramme de séquence « Modifier compte »

5. Conception 45
Diagramme de séquence "Supprimer compte " Ce scénario commence avec le administrateur

consulter liste des comptes et choisir le le comptes a supprimer et confirmer le supprision . le
système envoie demande à la base de données .Le compte à supprimée, à la fin montrent le
message d’supprission succès
La Fig 3.10 présente le Diagramme de séquence «Supprimer compte ».
F IGURE 3.10 – Diagramme de séquence «Supprimer compte »

6 Réalisation du sprint 1
Dans cette partie, nous présentons les différentes interfaces réalisées au cours de ce Sprint,
dont on présente :
L’ Interface inscription présenté par la figure 3.11.
F IGURE 3.11 – Interface inscription
L’ Interface d’authentification présenté par la figure 3.12
F IGURE 3.12 – Interface d’authentification

7. Tests 47
l’ Interface gestion des comptes présenté par la figure 3.13
F IGURE 3.13 – Interface gestion des comptes
7 Tests
Le test est une étape essentielle et fondamentale dans le processus Scrum qui ne peut être
mise en doute. Ainsi, ils nous aident à réaliser une évaluation sur les objectifs déterminés au
début du sprint et les résultats en cours. La méthodologie Scrum nous permet de tester chaque
augmentation à sa fin pour valider le développement de ladite augmentation, dans le but de ga-
rantir une qualité de produit optimale.
Par exemple, La figure 3.14 présente le succès de l’inscription d’un utilisateur .

F IGURE 3.14 – Succès d’ajout compte
8 Conclusion
Au cours de ce chapitre, avons présenté le premier sprint. Pour ce faire, nous passons par
la présentation du Product Backlog, son analyse, sa conception et sa mise en œuvre. Dans le
chapitre suivant, nous commençons le deuxième sprint.
Chapitre 4
Sprint 2
1 Introduction
Au cours de ce chapitre, nous avons commencé le deuxième sprint. Pour ce faire, on com-
mence par le backlog de sprint, puis on passe aux parties analyse et conception, pour enfin finir
par les parties réalisation et test.
2 Backlog du sprint
Le tableau ci-dessous présente le backlog de notre deuxieme sprint
49

1 Gestion les
— - En tant que médecin ou secrétaires, je peux consul-
dossiers
ter la liste des dossiers médicaux.
médicaux
— - En tant que secrétaires, je peux supprimer des dos-
siers médicaux.
2 Gestion
— - En tant que secrétaire, je peux ajouter des fiches
les fiches
patientes.
patientes
— - En tant que médecin ou secrétaires, je peux consul-
ter la liste des fiches.
— - En tant que secrétaires, je peux modifier des fiches
patientes.
— - En tant que secrétaires, je peux supprimer des
fiches patientes.
3 Gestion les
— - En tant que médecin, je peux ajouter des consulta-
consulta-
tions En tant que médecin, je peux consulter la liste
tions
des consultations
— - En tant que médecin, je peux modifier consulta-
tions
— - En tant que médecin, je peux supprimer des consul-
tations

3. Tableau des taches 51
3 Tableau des taches

La figure ci-dessous présente le tableau des taches du sprint 2 :
F IGURE 4.1 – Tableau des taches du sprint 2
4 Phase d’analyse
4.1 Raffinement du cas d’utilisation «Gestion des dossiers médicaux»

La figure 4.2 illustre le raffinement du cas d’utilisation «Gestion des dossiers médicaux» pour
l’acteur « Médecin »
F IGURE 4.2 – Diagramme de cas d’utilisation «Gestion des dossiers médicaux »pour l’acteur «
Médecin »
La figure 4.3 illustre le raffinement du cas d’utilisation « Gestion des dossiers médical» pour
l’acteur «secrétaire »
F IGURE 4.3 – Diagramme de cas d’utilisation «Gestion des dossiers médical » pour l’acteur
«Secrétaire »
Les scénarios d’exécution du cas d’utilisation «Gestion des dossiers médical» sont décrits
par les tableaux suivants représentant la fiche descriptive du cas :
Cas d’utilisation Consulter des dossiers médical

Acteur Secrétaire - Médecin
Pré condition Utlisateur authentifié
Post condition liste des dossiers médicaux affichés
Scénario nominale
— L’Utilisateur s’authentifie.
— L’Utilisateur demande de consulter liste
des dossiers médicaux.
— Le système affiche liste des dossiers mé-
dicaux.
— Le système affiche page vide
TABLE 4.2 – Scénarios d’exécution du cas d’utilisation «consulter des dossiers médicaux»
Cas d’utilisation supprimer dossiers médical

Acteur Secrétaire
Pré condition Secrétaire authentifié ,liste des dossiers médicaux affichés
Post condition dossier médical supprimée
Scénario nominale
— l’Secrétaire s’authentifie.
— L’Secrétaire demande de consulter liste des dossiers
médicaux.
— Le système affiche liste des dossiers médicaux.
— L’Secrétaire choisit le dossier médical à supprimer.
— L’ Secrétaire clique sur le bouton «supprimer ».
— le systéme afficher un message pour confirmer le
suppression.
— L’ Secrétaire clique sur le bouton « Oui ». pour
confirmer système effectue la suppression.
— Le système affiche un message « supprimer avec
succès ».
— L’ Secrétaire clique sur bouton « No » anuuler le
suppression.
— le systéme afficher un message « No Data ».
TABLE 4.3 – Scénarios d’exécution du cas d’utilisation «supprimer dossier médical»

4.2 Raffinement du cas d’utilisation «Gestion fiche patient»
La figure 4.4 illustre le raffinement du cas d’utilisation «Gestion fiche patient»pour l’acteur
«secrétaire »
F IGURE 4.4 – Diagramme de cas d’utilisation «Gestion les fiche» pour l’acteur «Secrétaire »
La figure 4.5 illustre le raffinement du cas d’utilisation « Gestion fiche patient»pour l’acteur
«Médecin »
F IGURE 4.5 – Diagramme de cas d’utilisation «Gestion les fiche» pour l’acteur «Médecin »
Les scénarios d’exécution du cas d’utilisation «Gestion les fiche patients » sont décrits par
les tableaux suivants représentant la fiche descriptive du cas.
Cas d’utilisation Ajouter patient

Acteur Sécretaire
Pré-condition sécretaire authentifié
Post-condition Patient ajoutée
Scénario nominale
— L’sécretaire demande le formulaire d’ajout pa-
tient.
— Le système affiche le formulaire.
— L’sécretaire remplit les champs et clique sur
button « Enregistrer».
— Le système vérifie les donnes saisies.
— Le système enregistre la nouvelle Patient.
— Le système renvoie un message de d’ajout
avec sucées.
— La secrétaire oubliée se remplit tous les
champs : le système affiche un message d’er-
reur "il faut remplir les champs"
— La sécretaire quitte la page .
TABLE 4.4 – Scénarios d’exécution du cas d’utilisation «Ajouter fiche patient »

Cas d’utilisation Consulter fiche patient

Pré-condition L’utilisateur authentifié , l’utilisateur consulter liste
des dossiers médicaux
Post-condition Fiche patient affichées
Scénario nominale
— L’Utilisateur consulte la liste les dossiers mé-
dicaux .
— L’Utilisateur choisit le dossier médical .
— Le système affiche le fiche patient (les infor-
mations).
— le systéme affiche message d’erreur "NO data
"
TABLE 4.5 – Scénarios d’exécution du cas d’utilisation «Consulter fiche patient »

Cas d’utilisation Modifier fiche patient

Acteur Secrétaire
Pré-condition Secrétaire authentifié , liste des dossiers médicaux af-
fichées
Post-condition
Fiche patient modifiée
Scénario nominale
— Le système affiche liste des dossiers médi-
caux.
— L’Secrétaire choisit le dossier médical .
— Le système affiche le fiche patient (les infor-
mations).
— L’Secrétaire clique sur modifier.
— Le système affiche le formulaire de modifica-
tion de fiche patient.
— L’Secrétaire modifier les informations et
clique sur validé.
— Le système effectue la modification.
— Le système affiche un message indiquant que
la modification s’est déroulée avec succès.
— Les données saisies sont manquantes : Le sys-
tème affiche un message d’erreur "vérifier les
champs "
TABLE 4.6 – Scénarios d’exécution du cas d’utilisation «Modifier fiche patient »

Cas d’utilisation Supprimer fiche patient

Acteur Secrétaire
Pré-condition Secrétaire authentifié , liste des dossiers médical affi-
chées ,fiche patient affichées,
Post-condition fiche patient supprimée
Scénario nominale
— L’Secrétaire choisit le fiche patient à suppri-
mer
— L’Secrétaire clique sur le bouton «supprimer »
— le systéme afficher un message pour confirmer
le suppression
— L’ Secrétaire clique sur le bouton « Oui » pour
confirmer suppression
— Le système effectue la suppression
— Le système affiche un message «suppimer
avec succès» .
— L’ Secrétaire clique sur bouton « No » anuuler
le suppression .
TABLE 4.7 – Scénarios d’exécution du cas d’utilisation « Supprimer fiche patient »
4.3 Raffinement du cas d’utilisation «Gestion des consulations »

La figure 4.6 illustre le raffinement du cas d’utilisation «Gestion des consultations».
F IGURE 4.6 – Diagramme de cas d’utilisation «Gestion des consultations»
Les scénarios d’exécution du cas d’utilisation «Gestion des consultations » sont décrits par
les tableaux suivants représentant la fiche descriptive du cas
Cas d’utilisation Ajouter consulations

Acteur Médecin
Pré condition Médecin authentifié
Post condition consulations ajoutée
Scénario nominale
— le médecin demande le formulaire d’ajout
consultation
— Le système affiche le formulaire consultation
— le médecin remplit les champs et clique sur
button « Enregistrer»
— Le système vérifie les donnes saisies
— Le système enregistre la nouvelle consulations
avec sucées
— le médecin oubliée se remplit tous les
reur "il faut remplir les champs".
TABLE 4.8 – Scénarios d’exécution du cas d’utilisation «Ajouter consultation »

Cas d’utilisation Consulter la liste des consultation

Acteur Médecin
Pré condition Médecin authentifié
Post condition Liste de consultation affichées
Scénario nominale
— Le médecin consulte la liste les dossiers
médical .
— Le système affiche liste des dossiers mé-
dical .
— le système afficher message d’erreur
"No data !"
TABLE 4.9 – Scénarios d’exécution du cas d’utilisation «Consulter la liste des consultation »
Cas d’utilisation Modifier consultation

Acteur Médecin
Pré condition Médecin authentifié,liste des dossier médical ,Liste
des ordonnnces affichées
Post condition Ressource logicielle modifiée
Scénario nominale
— Le système affiche liste des ordonnnces.
— L’Médecin choisit la consultation à modifier.
tion de consultation.
— L’Médecin modifier les informations et clique
sur validé.
— Le système vérifie les données saisies.
la modification s’est déroulée avec succès.
— L’Médecin oubliée se remplit tous les
champs : le système affiche un message
d’erreur "vérifier les champs"
— L’Médecin quitte la page .
TABLE 4.10 – Scénarios d’exécution du cas d’utilisation « Modifier consultation »

5. Conception 63
Cas d’utilisation Supprimer consultation

Acteur Le médecin
Pré condition Le médecin authentifié
liste de consultation affichées
Post-condition consultation supprimée
Scénario nominale
— Le médecin choisit le consultation à suppri-
mer.
— Le médecin clique sur le bouton «supprimer ».
le suppression.
— Le médecin clique sur le bouton « Oui » pour
confirmer suppression.
avec succès».
le suppression.
TABLE 4.11 – Scénarios d’exécution du cas d’utilisation «Supprimer consultation»
5 Conception

La figure 4.5 représente le diagramme de classes utilisé pour le développement du sprint 2


5. Conception 65

— Diagramme de séquence « consulter des dossiers médicaux » Ce scénario décrit l’opéra-

tion de requête de la liste des dossiers médicaux
La figure 4.8 représente le Diagramme de séquence «Consulter dossier médicaux »
F IGURE 4.8 – Diagramme de séquence «Consulter liste des dossiers médicaux»

Diagramme de séquence "Supprimer dossie médical " Ce scénario commence avec l’secré-
taire consulter liste des dossiers médical et choisir le dossier a supprimer et confirmer le suppri-
sion . le système envoie demande à la base de données .Le fiche à supprimer, à la fin montrent le
La figure 4.9 représente le Diagramme de séquence « Supprimer dossier médical »
F IGURE 4.9 – Diagramme de séquence « Supprimer dossier médical»

5. Conception 67
Diagramme de séquence "Ajouter fiche patient " Ce scénario commence avec l’secrétaire
demande d’affichage du formulaire et remplit les champs demandés. les champs obligatoires non
vide. le système envoie les données saisies à la base de données .Les données à enregistrer, à la
fin montrent le message d’enregistrement succès
La figure 4.10 représente le Diagramme de séquence «Ajouter Fiche patient »
F IGURE 4.10 – Diagramme de séquence « Ajouter Fiche patient »

Diagramme de séquence "Modifier fiche patient " Ce scénario commence avec l’secrétaire
demande d’affichage du formulaire du modification fiche patient et modifier les champs . les
champs obligatoires non vide. le système envoie les données à la base de données .Les données
à enregistrer, à la fin montrent le message d’modification succès
La figure 4.11 représente le Diagramme de séquence «Modifier fiche patient »
F IGURE 4.11 – Diagramme de séquence «Modifier fiche patient»

5. Conception 69
Diagramme de séquence "Supprimer fiche patient " Ce scénario commence avec l’secrétaire
consulter liste des dossiers médicaux et choisir le fiche a supprimer et confirmer le supprision . le
système envoie demande à la base de données .Le fiche à supprimer, à la fin montrent le message
d’supprission succès
La figure 4.12 représente le Diagramme de séquence «Supprimer fiche patient»
F IGURE 4.12 – Diagramme de séquence «Supprimer fiche patient»

— Diagramme de séquence « Consulter fiche patient » Ce scénario décrit l’opération de

requête de la liste des comptes utilisateurs
La figure 4.13 représente le Diagramme de séquence «Consulter fiche patient»
F IGURE 4.13 – Diagramme de séquence « Consulter fiche patient»

5. Conception 71
Diagramme de séquence "Ajouter consultation " Ce scénario commence avec le médecin

vide.le système envoie les données saisies à la base de données .Les données à enregistrer, à la
La figure 4.14 représente le Diagramme de séquence «Ajouter consultation »
F IGURE 4.14 – Diagramme de séquence « Ajouter consultation »

— Diagramme de séquence « Consulter consultation » Ce scénario décrit l’opération de

requête de la liste des comptes utilisateurs
La figure 4.15 représente le Diagramme de séquence «Consulter liste des consultations »
F IGURE 4.15 – Diagramme de séquence « Consulter liste des consultations »

5. Conception 73
Diagramme de séquence "Modifier consultation " Ce scénario commence avec le médecin

demande d’affichage du formulaire du modification consultation et modifier les champs . les
champs obligatoires non vide. Si tout est correct, le système envoie les données à la base de
données .Les données à enregistrer, à la fin montrent le message d’modification succès
La figure 4.16 représente le Diagramme de séquence «Modifier consultation »
F IGURE 4.16 – Diagramme de séquence «Modifier consultation »

Diagramme de séquence "supprimer consultation " Ce scénario commence avec le médecin

choisir de supprimer une consultation ,si le médecin clique sur button "OUI" pour confirmer sup-
prision le systémé affiche message de succés si non message d’erreur .
La figure 4.17 représente le Diagramme de séquence «Supprimer consultation »
F IGURE 4.17 – Diagramme de séquence «Supprimer consultation »

6. Réalisation du sprint 2 75
Dans cette partie, nous présentons les différentes interfaces réalisées au cours de ce Sprint
dont :
L’ Interface de consultation de la liste des dossiers médical pour l’acteur médecin(Fig 4.18).
F IGURE 4.18 – Interface de consultation de la liste des dossier médical pour l’acteur médecin
L’Interface de consultation de la liste des dossiers médical pour l’acteur secrétaire (Fig
4.19).
F IGURE 4.19 – Interface de consultation de la liste des dossier médical pour l’acteur secrétaire
L’Interface d’ajout des fiches patientes (Fig 4.20)
F IGURE 4.20 – Interface d’ajout des fiches patientes
F IGURE 4.21 – Interface de consultation de la pour fiche patient l’acteur médecin

L’ Interface de consultation de la fiche patient pour l’acteur médecin (Fig 4.22)
F IGURE 4.22 – Interface de consultation de la pour fiche patient l’acteur médecin
L’ Interface d’ajout des consultations(Fig 4.23)
F IGURE 4.23 – Interface d’ajout des consultations

L’ Interface de consultation de la liste des consultations (Fig 4.24)
F IGURE 4.24 – Interface de consultation de la liste des consultation
7 Tests
Nous avons testé l’ajout de consultation et fiche patiente avec postmen comme la figure (fi-
gure 3.14) dans sprint 1
8 Conclusion
Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons
passé par la présentation du Backlog product, l’analyse, la conception et la réalisation. Dans le
chapitre suivant nous entamons le troisième sprint.
Chapitre 5
Sprint 3
1 Introduction
Au cours de ce chapitre, nous avons commencé le troisième sprint . Pour ce faire, on com-
mence par le backlog de sprint, puis on passe aux parties analyse et conception, pourenfin finir
par les parties réalisation et test
2 Backlog du sprint 3
Le tableau ci-dessous présente le backlog de notre troisiéme sprint
79

1 Gestion des or-
donnances En tant que médecin, je peux ajouter des ordonnances.
En tant que médecin, je peux consulter la liste des ordonnances.
En tant que médecin, je peux modifier des ordonnances.
En tant que médecin, je peux supprimer des ordonnances.
2 Gestion des cer-
tificats En tant que médecin, je peux ajouter des certificats
En tant que médecin, je peux consulter la liste des certificats
En tant que médecin, je peux modifier des certificats
En tant que médecin, je peux supprimer des certificats
3 Gestion des
rendez-vous En tant que secrétaire, je peux ajouter des rendez-vous.
En tant que médecin ou secrétaires, je peux consulter les rendez-
vous.
En tant que secrétaire, je peux modifier les rendez-vous.
En tant que secrétaire, je peux supprimer des rendez-vous.

3. Tableau des tâches 81
3 Tableau des tâches

La figure ci-dessous présente le tableau des tâches du sprint 2 :
F IGURE 5.1 – Les tâches du sprint 2
4 Phase d’analyse
4.1 Raffinement du cas d’utilisation «Gestion des ordonnaces »

La figure 5.2 illustre le raffinement du cas d’utilisation « Gestion des ordonnaces »
F IGURE 5.2 – Diagramme de cas d’utilisation «Gestion des ordonnace»

Les scénarios d’exécution du cas d’utilisation «Gestion des ordonnances» sont décrits par les
tableaux suivants représentant la fiche descriptive du cas :
Cas d’utilisation Ajouter ordonnance

Acteur Médecin
Pré-condition Médecin authentifié,liste des dossiers médicaux affi-
chés
Post-condition Ordonnance ajoutée
Scénario nominale
— le Médecin demande le formulaire d’ajout Or-
donnance
— Le système affiche le formulaire
— le Médecin remplit les champs et clique sur
button « Enregistrer»
— Le système enregistre la nouvelle ordonnance
avec sucées
— le Médecin oubliée se remplit tous les
— le Médecin quitte la page .
TABLE 5.2 – Scénarios d’exécution du cas d’utilisation «Ajouter ordonnance »

Cas d’utilisation Consulter liste des ordonnance

Acteur Médecin
Pré condition Médecin authentifié, liste des dossiers médicaux affi-
chés
Post condition liste des ordonnances affichés
Scénario nominale
— Le Médecin demande de consulter liste des
dossiers médicaux.
— Le système affiche liste des dossiers médi-
caux.
— le Médecin demande de consulter liste des or-
donnances.
— Le système affiche liste des ordonnance.
— Le système affiche message d’erreur "table est
vide"
TABLE 5.3 – Scénarios d’exécution du cas d’utilisation «Consulter des ordonnances»

Cas d’utilisation supprimer ordonnance

Acteur Le Médecin
Pré condition Le Médecin authentifié ,liste des dossiers médicaux
affichés,liste des ordonnance affichés
Post condition ordonnance supprimer
Scénario nominale
— Le système affiche liste des ordonnances.
— Le Médecin choisit ordonnance à supprimer
— Le Médecin clique sur le bouton «supprimer »
le suppression
— Le Médecin clique sur le bouton « Oui » pour
confirmer système effectue la suppression
— Le système affiche un message « supprimer
avec succès »
— Le médecin clique sur bouton « No » anuuler
le suppression
TABLE 5.4 – Scénarios d’exécution du cas d’utilisation «Supprimer ordonnance»

Cas d’utilisation Modifier ordonnance

Acteur Le Médecin
Pré-condition Le Médecin authentifié , liste des dossiers médicaux
affichés,liste des ordonnances affichés
Post-condition ordonnance modifiée
Scénario nominale
— Le système affiche liste des ordonnances.
— Le Médecin choisit le ordonnance à modifier
tion de ordonnance
— Le Médecin modifier les informations et
clique sur validé
— Le système effectue la modification
la modification s’est déroulée avec succès .
— Le Médecin oubliée se remplit tous les
reur "Vérifier les champs"
— Le Médecin quitte la page .
TABLE 5.5 – Scénarios d’exécution du cas d’utilisation «Modifier ordonnance »

4.2 Raffinement du cas d’utilisation «Gestion des certificats »

La figure 5.3 illustre le raffinement du cas d’utilisation « Gestion des certificats »
F IGURE 5.3 – Diagramme de cas d’utilisation «Gestion des certificats »
Les scénarios d’exécution du cas d’utilisation «Gestion des certificats» sont décrits par les
Cas d’utilisation Ajouter certificats

Acteur Médecin
Pré-condition Médecin authentifié , liste des dossiers médicaux affi-
chés
Post-condition certificat ajoutée
Scénario nominale
— le Médecin demande le formulaire d’ajout cer-
tificats
— Le système affiche le formulaire d’ajouter
— le Médecin remplit les champs et clique sur
button «Enregistrer»
— Le système enregistre la nouvelle certificats
avec sucées
— le Médecin oubliée se remplit tous les
— le Médecin quitte la page .
TABLE 5.6 – Scénarios d’exécution du cas d’utilisation «Ajouter certificat »

Cas d’utilisation Modifier certificat

Acteur Le Médecin
Pré-condition Le Médecin authentifié , liste des dossiers médicaux
affichés,liste des certificats affichés
Post-condition Certificat modifiée
Scénario nominale
— Le système affiche liste des certificats.
— Le Médecin choisit le certificat à modifier
tion de certificat
— Le Médecin modifier les informations et
clique sur validé
— Le système effectue la modification
— Le Médecin oubliée se remplit tous les
reur "Vérifier les champs"
— Le Médecin quitte la page .
TABLE 5.7 – Scénarios d’exécution du cas d’utilisation «Modifier certificat »

Cas d’utilisation supprimer certificat

Acteur Le Médecin
Pré condition Le Médecin authentifié , liste des dossiers médicaux
affichés, liste des certificat affichés
Post condition certificat supprimer
Scénario nominale
— Le système affiche liste des certificats.
— Le Médecin choisit certificat à supprimer
— Le Médecin clique sur le bouton «supprimer »
le suppression
— Le Médecin clique sur le bouton « Oui » pour
confirmer système effectue la suppression
— Le système affiche un message « supprimer
avec succès »
— Le médecin clique sur bouton « No » anuuler
le suppression
TABLE 5.8 – Scénarios d’exécution du cas d’utilisation «supprimer certificat»

Cas d’utilisation Consulter liste des certificats

Acteur Médecin
Pré condition Médecin authentifié, liste des dossiers médicaux affichés
Post condition liste des certificat affichés
Scénario nominale
— Le Médecin demande de consulter liste des dossiers médi-
cal
— Le système affiche liste des dossiers médica
— le Médecin demande de consulter liste des certificats
— Le système affiche liste des dossiers médical
— Le système affiche message d’erreur "table vide"
TABLE 5.9 – Scénarios d’exécution du cas d’utilisation «consulter certificat »
4.3 Raffinement du cas d’utilisation «Gestion des rendez-vous»

La figure 5.4 illustre le raffinement du cas d’utilisation « Gestion des certificats » pour acteur
«Médecin »
F IGURE 5.4 – Diagramme de cas d’utilisation «Gestion des rendez-vous »
La figure 5.4 illustre le raffinement du cas d’utilisation « Gestion des rendez-vous » pour
acteur «Secrétaire »
F IGURE 5.5 – Diagramme de cas d’utilisation «Gestion des rendez-vous »
Les scénarios d’exécution du cas d’utilisation «Gestion des rendez-vous» sont décrits par les
Cas d’utilisation Ajouter rendez-vous

Acteur Sécretaire
Pré-condition sécretaire authentifié
Post-condition rendez-vous ajoutée
Scénario nominale
— L’sécretaire demande le formulaire d’ajout rendez-vous.
— Le système affiche le formulaire d’ajout rendez-vous.
— L’sécretaire remplit les champs et clique sur button « En-
registrer».
— Le système enregistre la nouvelle rendez-vous.
— Le système renvoie un message de d’ajout avec sucées.
— L’secrétaire oubliée se remplit tous les champs : le système
affiche un message d’erreur "il faut remplir les champs"
TABLE 5.10 – Scénarios d’exécution du cas d’utilisation «Ajouter rendez-vous »

Cas d’utilisation Consulter liste rendez-vous

Pré-condition L’utilisateur authentifié
Post-condition liste rendez-vous affichés
Scénario nominale
— L’Utilisateur demande consulte la liste
des rendez-vous.
— Le système affiche liste des rendez-
vous.
— le systéme affiche me message d’erreur
’table est vide ’
TABLE 5.11 – Scénarios d’exécution du cas d’utilisation « Consulter rendez-vous »
NB : Scénarios d’exécution du cas d’utilisation « Consulter rendez-vous pour aujourd’hui

»les mêmes scénarios consulter rendez-vous.
Cas d’utilisation Modifier rendez-vous

Acteur Secrétaire
Pré-condition Secrétaire authentifié , liste des rendez-vous affichées
Post-condition rendez-vous modifiée
Scénario nominale
— Le système affiche liste des rendez-vous.
— L’Secrétaire choisit le rendez-vous à modifier.
tion de rendez-vous.
— L’Secrétaire modifier les informations et va-
lidé.
— L’secrétaire oubliée se remplit tous les
reur "vérifier les champs "
TABLE 5.12 – Scénarios d’exécution du cas d’utilisation « Modifier rendez-vous »
NB : Scénarios d’exécution du cas d’utilisation « Modifier rendez-vous pour aujourd’hui»

les mêmes scénarios modifier rendez-vous.
Cas d’utilisation Supprimer rendez-vous

Acteur Secrétaire
Pré-condition Secrétaire authentifié , liste des rendez-vous affichées
Post-condition rendez-vous supprimée
Scénario nominale
— Le système affiche liste des rendez-vous.
— L’Secrétaire choisit le rendez-vous à suppri-
mer.
— L’Secrétaire clique sur le bouton «supprimer
».
le suppression.
— L’ Secrétaire clique sur le bouton « Oui » pour
confirmer suppression.
avec succès».
le suppression .
TABLE 5.13 – Scénarios d’exécution du cas d’utilisation « Supprimer rendez-vous »
NB : Scénarios d’exécution du cas d’utilisation «Supprimer rendez-vous pour aujourd’hui »

les mêmes scénarios Supprimer rendez-vous.

La figure 5.6 représente le diagramme de classes utilisé pour le développement du sprint 2


5 Conception

Diagramme de séquence "Ajouter ordonnance " Ce scénario commence avec le médecin

vide. Si tout est correct, le système envoie les données saisies à la base de données.Les données
à enregistrer, à la fin montrent le message d’enregistrement,succès si non message d’erreur
La figure 5.7 représente le Diagramme de séquence «Ajouter ordonnance »
F IGURE 5.7 – Diagramme de séquence «Ajouter ordonnance »

5. Conception 97
Diagramme de séquence "Modifier ordonnance " Ce scénario commence avec le médecin de-
mande d’affichage du formulaire du modification consultation et modifier les champs. les champs
données à enregistrer, à la fin montrent le message d’modification succès, sinon message d’erreur
La figure 5.8 représente le Diagramme de séquence « Modifier ordonnance »
F IGURE 5.8 – Diagramme de séquence « Modifier ordonnance »

Diagramme de séquence "Supprimer ordonnance " Ce scénario commence avec le médecin

consulter liste des rendez-vous et choisir le rendez-vous a supprimer et confirmer le supprision.
le système envoie demande à la base de données. Le fiche à supprimer, à la fin montrent le
message d’supprission succès La figure 5.9 représente le Diagramme de séquence « Supprimer
ordonnance »
F IGURE 5.9 – Diagramme de séquence « Supprimer ordonnance »

5. Conception 99
— Diagramme de séquence « consulter consultation » Ce scénario décrit l’opération de re-

quête de la liste des ordonnance
La figure 5.10 représente le Diagramme de séquence «consulter ordonnance »
F IGURE 5.10 – Diagramme de séquence « consulter ordonnance »

Diagramme de séquence "Ajouter certificat " Ce scénario commence avec le médecin de-
mande d’affichage du formulaire et remplit les champs demandés. les champs obligatoires non
vide. Si tout est correct, le système envoie les données saisies à la base de données .Les données
à enregistrer, à la fin montrent le message d’enregistrement ,succès si non message d’erreur
La figure 5.11 représente le Diagramme de séquence «Ajouter certificat»
F IGURE 5.11 – Diagramme de séquence « Ajouter certificat »

5. Conception 101
Diagramme de séquence "Modifier certificat " Ce scénario commence avec le médecin de-
mande d’affichage du formulaire du modification consultation et modifier les champs . les champs
données à enregistrer, à la fin montrent le message d’modification succès, sinon message d’erreur
La figure 5.12 représente le Diagramme de séquence «Modifier certificat »
F IGURE 5.12 – Diagramme de séquence « Modifier ordonnance »

Diagramme de séquence "Supprimer certificat " Ce scénario commence avec le médecin

consulter liste des rendez-vous et choisir le rendez-vous a supprimer et confirmer le supprision
. le système envoie demande à la base de données .Le fiche à supprimer, à la fin montrent le
La figure 5.13 représente le Diagramme de séquence « supprimer certificat »
F IGURE 5.13 – Diagramme de séquence « Supprimer certificat »

5. Conception 103
— Diagramme de séquence « consulter certificat » Ce scénario décrit l’opération de requête

de la liste des certificats
La figure 5.14 représente le Diagramme de séquence «consulter certificat »
F IGURE 5.14 – Diagramme de séquence « Consulter certificat »
Diagramme de séquence "Ajouter rendez-vous " Ce scénario commence avec l’secrétaire

vide. , le système envoie les données saisies à la base de données .Les données à enregistrer, à la
La figure 5.15 représente le Diagramme de séquence « Ajouter rendez-vous »
F IGURE 5.15 – Diagramme de séquence « Ajouter rendez-vous »

5. Conception 105
Diagramme de séquence "Modifier rendez-vous " Ce scénario commence avec l’secrétaire

demande d’affichage du formulaire du modification rendez-vous et modifier les champs . les
champs obligatoires non vide. le système envoie les données à la base de données .Les données
à enregistrer, à la fin montrent le message d’modification succès La figure 5.16 représente le
Diagramme de séquence « Modifier rendez-vous »
F IGURE 5.16 – Diagramme de séquence « Modifier rendez-vous »
NB : Diagramme de séquance «Modifer rendez-vous pour aujourd’hui » le même diagramme de

séquance modifier rendez-vous.
Diagramme de séquence "Supprimer rendez-vous " Ce scénario commence avec l’secrétaire

consulter liste des rendez-vous et choisir le rendez-vous a supprimer et confirmer le supprision.le
système envoie demande à la base de données.Le fiche à supprimer, à la fin montrent le message
d’supprission succès
La figure 5.17 représente le Diagramme de séquence « Supprimer rendez-vous »
F IGURE 5.17 – Diagramme de séquence « Supprimer rendez-vous »
NB : Diagramme de séquance «Supprimer rendez-vous pour aujourd’hui » le même diagramme

de séquance supprimer rendez-vous.
5. Conception 107
— Diagramme de séquence « consulter rendez-vous » Ce scénario décrit l’opération de re-

quête de la liste des rendez-vous
La figure 5.18 représente le Diagramme de séquence «consulter rendez-vous »
F IGURE 5.18 – Diagramme de séquence « Consulter rendez-vous »
NB : Diagramme de séquance «consulter rendez-vous pour aujourd’hui » le même diagramme

de séquance consulter rendez-vous.
Dans cette partie, nous présentons les différentes interfaces réalisées au cours de ce Sprint
dont :
L’ Interface d’ajout des ordonnances (Fig 5.19).
F IGURE 5.19 – Interface d’ajout des ordonnances
L’Interface de consultation de la liste des ordonnances (Fig 5.20).
F IGURE 5.20 – Interface de consultation de la liste des ordonnances

L’Interface d’ajout des certificats (Fig 5.21)
F IGURE 5.21 – Interface d’ajout des certificats
L’ Interface de consultation liste des certificats (Fig 5.22)
F IGURE 5.22 – Interface de consultation de la liste des certificats
L’ Interface d’ajout des rendez-vous (Fig 5.23)

F IGURE 5.23 – Interface d’ajout des rendez-vous
L’ Interface de consultation de la liste des rendez-vous (Fig 5.24,Fig 5.25)

NB : Interface de consultation de la liste des rendez-vous pour aujourd’hui les mêmes Interface
de consultation de la liste des rendez-vous
F IGURE 5.24 – Interface de consultation de la liste des rendez-vous pour l’acteur « Secrétaire »
.
7. Tests 111
F IGURE 5.25 – Interface de consultation de la liste des rendez-vous pour l’acteur « Médecin »
7 Tests
Nous avons testé l’ajout de ordonnance, certificat et rendez-vous avec postmen comme la
figure (figure 3.14) dans sprint 1
8 Conclusion
Au cours de ce chapitre, nous avons présenté le troisième sprint. Pour ce faire, nous avons
passé par la présentation du backlog product, l’analyse, la conception et la réalisation.
Conclusion et perspectives
Ce rapport représente le fruit du travail effectué au sein de la société Arabsoft dans le cadre
de notre projet de fin d’études pour l’obtention du diplôme de Licence en Informatique.
Décisionnelle à la Faculté des Sciences Juridiques, Économiques et de Gestion de Jendouba .
Nous commençons par comprendre le contexte général du projet et les différentes exigences
du futur système, tout au long de notre travail nous essayons de construire notre plateforme
incrément par incrément en utilisant la méthodologie Scrum, puis nous identifions les besoins
fonctionnels et non fonctionnels, le Product Backlog a été préparé.
Malgré les contraintes de temps et les difficultés rencontrées, nous avons réussi à réaliser la
quasi-totalité de notre plateforme.
Pour conclure, notre travail ne s’arrête pas à ce niveau, en effet, ce projet peut améliorer :
• Améliorer notre plate-forme en ajoutant d’autres fonctionnalités.
• Développer une application mobile.
113
Bibliographie
[1] Site officiel http ://www.arabsoft.com.tn/

[2] Site ideematic.com, Les méthodes agiles, https ://www.ideematic.com/actualites/2015/01/methodes-
agiles-definition
[3] Site tupleap.org ,Scrum, https ://www.tuleap.org/fr/agile/comprendre-methode-agilescrum-
10-minutes
[4] Site , Introduction aux méthodes agiles et Scrum | L’Agiliste
[5] Site , https ://blog-gestion-de-projet.com/agilite-et-scrum-fondamentaux/artefactsscrum/
[6] Site, https ://wiki.sfeir.com/agilite/scrum/evenements-scrum/
[7] Site, https ://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf
[8] https ://code.visualstudio.com/docs
[9] https ://blog.webnet.fr/presentation-de-postman-outil-multifonction-pour-api-web/
[10] https ://fr.wikipedia.org/wiki/Angular
[11] https ://nodejs.org/en/docs/
[12] https ://www.computerhope.com/jargon/d/drawio.html
[14] https ://fr.wikipedia.org/wiki/Overleaf
[13] https ://trello.com/en
[15] https ://www.computerhope.com/jargon/d/drawio.html
[16] https ://www.lemagit.fr/definition/GitHub
[17] https ://github.com/eyaabenabdallah30/FrontPFE.git
[18] https ://github.com/eyaabenabdallah30/backPFE.git
115

Ben Abdallah 3 EB

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ben Abdallah 3 EB

Transféré par

Droits d'auteur :

Formats disponibles

Table des matières

1 Cadre général du projet 3

2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1 Logo de ARABSOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Organigramme des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.19 Logo Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Les tâches du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Tableau des taches du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.12 Diagramme de séquence «Supprimer fiche patient» . . . . . . . . . . . . . . . . 69

5.1 Les tâches du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.18 Diagramme de séquence « Consulter rendez-vous » . . . . . . . . . . . . . . . . 107

1.1 Tableau fiche signalétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.10 Scénarios d’exécution du cas d’utilisation « Modifier consultation » . . . . . . . 62

5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

L’évolution rapide des technologies de l’information et de la communication a ouvert de nou-

Le rapport sera composé de cinq chapitres :

- Le premier chapitre est constituée de la présentation générale de projet, la solution pro-

- Le deuxième chapitre s‘intitule «Phase de planification » est composeé l‘identification des

- Le quatrième chapitre s’intitule «Sprint 2», le rôle de ce chapitre est de présenter le

Cadre général du projet

3.1 Présentation de l’organisme d’accueil

F IGURE 1.1 – Logo de ARABSOFT

3.2 Fiche signalétique

Raison sociale Arabsoft

TABLE 1.1 – Tableau fiche signalétique

3.3 Mission et outils d’Arabsoft

Les méthodologies de Merise, UML.

TABLE 1.2 – Tableau Mission et outils d’Arabsoft

3.4 Organigramme de l’organisme d’accueil

F IGURE 1.2 – Organigramme ARABSOFT

4.1 Description de l’existant

4.2 Critiquer de l’existant

— Absence d’accès direct a l’information des patients

4.3 Solution proposée

— Gestion et suivi les fiches patients.

5.1 Méthodes Agiles

La méthode SCRUM définit un cadre pour la réalisation de projets complexes. Initialement

F IGURE 1.3 – Processus Scrum

• Les acteurs d’un projet SCRUM

F IGURE 1.4 – L’équipe SCRUM

• Les événements d’un projet SCRUM

5.2 Comparaison entre les méthodes classiques et les méthodes agiles

Caractéristiques Approche classique Approche Agile

TABLE 1.3 – Tableau de artéfacts d’un projet SCRUM

5.3 La méthode adoptée

2 Analyse des besoins

2.1 Identification des acteurs

— Administrateur : L’administrateur joue un rôle primordiale et fondamental,il a pour rôle

— Médecin : C’est le responsable de la gestion des consultations, des ordonnances, des

— Secrétaire : C’est le responsable de la gestion les rendez-vous ,gestion fiches patientes et

2.2 Besoins fonctionnels

TABLE 2.1 – Les besoins fonctionnels

2.3 Besoins non fonctionnels

— L’ergonomie des interfaces et la facilité d’utilisation : Design de la plateforme doit

2.4 Pilotage du projet avec la méthodologie SCRUM

Notre équipe de projet se compose de 3 membres :

— Product owner : ZIDI Mouadh.

— Team members : Ben abdallah Eya.

— Identifiant : c’est un nombre unique et auto-incrémenté pour chaque user story.

— Thème : c’est le sujet auquel une user story est reliée.