Ben Ahmed Zohra, profile picture
Téléchargé parBen Ahmed Zohra
3,590 vues

Outpatient Department System (OPD)

Ce document présente le rapport de projet de fin d'études de Zohra Ben Ahmed sur la conception et la mise en place d'une application web SPA pour les établissements médicaux, dans le cadre de l'obtention d'un diplôme d'ingénieur en génie logiciel et systèmes d'information. Le projet a été réalisé au sein de Cynapsys Tunisie sous l'encadrement de Hamed Kolsi et Sahbi Bahroun, et couvre les phases de développement en utilisant des méthodes agiles comme Scrum. Le rapport inclut une étude de l'existant, la définition des besoins, la modélisation et la réalisation du projet à travers plusieurs sprints.

Intégrer la présentation

Téléchargé 62 fois
1 / 109
2 / 109
Plus lue
3 / 109
4 / 109
5 / 109
6 / 109
7 / 109
Plus lue
8 / 109
Plus lue
9 / 109
10 / 109
11 / 109
12 / 109
13 / 109
14 / 109
15 / 109
16 / 109
17 / 109
18 / 109
19 / 109
20 / 109
21 / 109
22 / 109
23 / 109
24 / 109
25 / 109
26 / 109
27 / 109
28 / 109
29 / 109
30 / 109
31 / 109
32 / 109
33 / 109
34 / 109
35 / 109
36 / 109
37 / 109
38 / 109
39 / 109
40 / 109
41 / 109
42 / 109
43 / 109
44 / 109
45 / 109
46 / 109
47 / 109
48 / 109
49 / 109
50 / 109
51 / 109
52 / 109
53 / 109
54 / 109
55 / 109
56 / 109
57 / 109
58 / 109
59 / 109
60 / 109
61 / 109
62 / 109
63 / 109
64 / 109
65 / 109
66 / 109
67 / 109
68 / 109
69 / 109
70 / 109
71 / 109
72 / 109
73 / 109
74 / 109
75 / 109
76 / 109
77 / 109
78 / 109
79 / 109
80 / 109
81 / 109
82 / 109
83 / 109
84 / 109
85 / 109
86 / 109
87 / 109
88 / 109
89 / 109
90 / 109
91 / 109
92 / 109
93 / 109
94 / 109
95 / 109
96 / 109
97 / 109
98 / 109
99 / 109
100 / 109
101 / 109
102 / 109
103 / 109
104 / 109
105 / 109
106 / 109
107 / 109
108 / 109
109 / 109
République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant professionnel, Hamed KOLSI Le J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant académique, Sahbi BAHROUN Le
Dédicaces À mes très chers parents Raoudha et Radhouane En témoignage de mon affection, de mon profond respect et de ma reconnaissance pour tous les efforts et les sacrifices qu’ils ont consentis pour ma réussite et mon bonheur. Chers parents aucune dédicace au monde ne suffira jamais à vous témoigner toute ma gratitude et mon amour. Que Dieu vous prête bonne santé et longue vie. À mes sœurs Bochra et Amira et mon frère Mohamed avec qui j’ai tous partagé Une vie pleine de succès et de bonheur. Pour l’amour dont vous m’avez toujours comblé, ainsi que pour le bien être que vous m’avez toujours assuré. Veuillez trouver ici, l’expression de mon affection et attachement. Que Dieu vous garde et vous réserve. À ceux qui m’ont soutenu, encouragé, qui ont apprécié mon effort et créé le milieu favorable, l’ambiance joyeuse et l’atmosphère joviale pour me procurer ce travail. À toutes ces personnes adorables, je dédie ce modeste travail avec mes vifs remerciements et les expressions respectueuses de ma profonde gratitude. Zohra BEN AHMED i
Remerciements C’est un plaisir et un moment très agréable de rendre hommage et de formuler des remerciements aux personnes qui, d’une manière ou d’une autre ont apporté leur soutien et contribué à finaliser ce travail. Mes remerciements s’adressent d’abord à tout le personnel de Cynapsys Tunisie . Je leur exprime ma reconnaissance et ma haute considération pour leur bienveillance, leur accueil et leurs conseils précieux. Je remercie spécialement Monsieur Hamed KOLSI pour m’avoir accordé leur confiance dans ce projet. Ils ont tous laissé leurs empreintes dans ce présent rapport à travers leurs conseils et recommandations. J’adresse aussi mes profonds remerciements à Monsieur Sahbi BAHROUN qui a accepté de diriger, de lire et porter des correctifs à ce travail sans oublier ses conseils et suggestions éclairés. Mes vifs remerciements s’adressent aux membres de jury qui ont accepté d’évaluer mon travail. J’associe à ces remerciements tous les enseignants de l’Institut Supérieur d’Informatique d’El Manar (ISI) qui ont contribué à ma formation. Je suis reconnaissante à toute personne qui a contribué de près ou de loin à la réalisation de ce projet. Qu’ils trouvent ici l’expression de ma haute gratitude. ii
Table des matières Introduction générale 1 1 Présentation générale et étude de l’existant 2 1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Cynapsys IT Hotspot en bref . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Directions de Cynapsys Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6.2 Méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.1 Langage de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.2 Plateforme de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.3 Framework de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.8 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.9 Conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Sprint 0 :Analyse et spécification des besoins 16 2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 iii
2.3 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.1 Les rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5 Architecture Adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.6 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.1 Outils matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3 Réalisation du Sprint 1 30 3.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.1 Diagramme de cas d’utilisation raffiné «S’authentfier» . . . . . . . . . . . . . 31 3.2.2 Diagramme de cas d’utilisation raffiné «Gestion des utilisateurs» . . . . . . . 33 3.2.3 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.5 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4 Réalisation du Sprint 2 51 4.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Réalisation du module de gestion des rendez-vous . . . . . . . . . . . . . . . . . . . . 52 4.2.1 Mise en oeuvre des patrons de conception Repository et unitofwork dans ASP.NET Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.2 Mise en oeuvre des services web . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1 Diagramme de cas d’utilisation raffiné «Suivi des rendez-vous» . . . . . . . . 57 4.3.2 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 iv
4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5 Réalisation du Sprint 3 72 5.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1 Diagramme de cas d’utilisation raffiné «Contrôler médecin» . . . . . . . . . . 73 5.2.2 Diagramme de cas d’utilisation raffiné «Suivre patient» . . . . . . . . . . . . 76 5.2.3 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Conclusion générale 89 Bibliographie 90 Annexes 93 v
Table des figures 1.1 Présentation de Cynapsys IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Pôles de Cynapsys[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Cycle de vie SCRUM [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 La logique Modèle-Vue-Contrôleur Web API . . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Modèle MVC [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4 Architecture Angular2 [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 Architecture WebAPI avec EFCore [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 Architecture globale de l’application [6] . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.7 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1 Raffinement de cas d’utilisation «S’authentfier» . . . . . . . . . . . . . . . . . . . . . 32 3.2 Raffinement de cas d’utilisation «Gestion des utilisateurs» . . . . . . . . . . . . . . . 33 3.3 Prototype "Liste des rôles" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 Prototype "Liste des utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.6 Diagramme de Modèle physique de données . . . . . . . . . . . . . . . . . . . . . . . 39 3.7 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . . . . . . . . . . . . 40 3.8 Diagramme de séquence «Ajouter Utilisateur» . . . . . . . . . . . . . . . . . . . . . . 41 3.9 Diagramme de séquence «Modifier Utilisateur» . . . . . . . . . . . . . . . . . . . . . 42 3.10 Diagramme de séquence «Supprimer Utilisateur» . . . . . . . . . . . . . . . . . . . . 43 3.11 Diagramme d’activité "Gestion des profils et des droits d’accés " . . . . . . . . . . . 44 3.12 Interface "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.13 Interface "Consulter la liste des utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . 45 3.14 Interface "Ajouter un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.15 Interface "Modifier un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.16 Interface "Supprimer un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.17 Interface "Ajouter un rôle " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 vi
Table des figures 3.18 Interface "Modifier un rôle " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.19 Interface "Afficher profile " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.1 Diagramme "Generic Repository Pattern and Unit of Work workflow" . . . . . . . . 53 4.2 Extrait de code de la classe IRepository . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3 Diagramme Repository pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4 Extrait de code de la classe IUnitofwork . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5 Raffinement de cas d’utilisation «Suivi des rendez-vous» . . . . . . . . . . . . . . . . 58 4.6 Prototype "Suivi par calendrier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.7 Prototype "Prise de rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.8 Diagramme de séquence «Réserver rendez-vous » . . . . . . . . . . . . . . . . . . . . 62 4.9 Diagramme de séquence «Annuler rendez-vous» . . . . . . . . . . . . . . . . . . . . . 63 4.10 Diagramme de séquence «Générer disponibilité» . . . . . . . . . . . . . . . . . . . . . 64 4.11 Interface "Réserver un rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.12 Interface "Confirmation de réservation de rendez-vous" . . . . . . . . . . . . . . . . . 66 4.13 Interface "Annuler rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.14 Interface "Liste des Rendez-Vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.15 Interface "Historique des rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.16 Interface "Notification de confirmation de rendez-vous par mail" . . . . . . . . . . . 68 4.17 Interface "Liste des plannings pour un médecin" . . . . . . . . . . . . . . . . . . . . 68 4.18 Interface "Génération de temps disponible" . . . . . . . . . . . . . . . . . . . . . . . 69 4.19 Interface "La liste de temps disponible" . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.20 Interface "Notification par message" . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Raffinement de cas d’utilisation «Contrôler médecin» . . . . . . . . . . . . . . . . . 74 5.2 Raffinement de cas d’utilisation «Suivre patient» . . . . . . . . . . . . . . . . . . . . 76 5.3 Prototype "Gestion des patients" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Diagramme de séquence " Ajouter un médecin" . . . . . . . . . . . . . . . . . . . . . 79 5.5 Diagramme de séquence " Modifier un médecin" . . . . . . . . . . . . . . . . . . . . 80 5.6 Diagramme de séquence " Supprimer un médecin" . . . . . . . . . . . . . . . . . . . 81 5.7 Interface "Liste des médecins" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.8 Interface "Profil d’un médecin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 vii
5.9 Interface "Ajouter un nouveau médecin" . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.10 Interface "Modifier un médecin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.11 Interface "Liste des patients" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.12 Interface "Ajouter un patient" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.13 Interface "Modifier un patient" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.14 Interface "Liste des patients personnalisée" . . . . . . . . . . . . . . . . . . . . . . . 85 5.15 Interface "Créer consultation pour patient" . . . . . . . . . . . . . . . . . . . . . . . 86 5.16 Interface "Gérer les départements" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 viii
Liste des tableaux 1.1 Étude comparative entre les approches agiles . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Le Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Description du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . . . . . . 32 3.3 Description du sous cas d’utilisation « Ajouter utilisateur » . . . . . . . . . . . . . . 33 3.4 Description du sous cas d’utilisation « Modifier utilisateur » . . . . . . . . . . . . . . 34 3.5 Description du sous cas d’utilisation « Créer rôle » . . . . . . . . . . . . . . . . . . . 35 3.6 Tests fonctionnels du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Description du sous cas d’utilisation « Créer rendez-vous » . . . . . . . . . . . . . . . 59 4.3 Description du sous cas d’utilisation « Annuler rendez-vous » . . . . . . . . . . . . . 59 4.4 Description du sous cas d’utilisation « Gérer Calendrier » . . . . . . . . . . . . . . . 60 4.5 Description du sous cas d’utilisation « Générer disponibilité » . . . . . . . . . . . . . 60 4.6 Tests fonctionnels du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Description du sous cas d’utilisation « Ajouter médecin » . . . . . . . . . . . . . . . 74 5.3 Description du sous cas d’utilisation « Modifier médecin » . . . . . . . . . . . . . . . 75 5.4 Description du sous cas d’utilisation « Supprimer médecin » . . . . . . . . . . . . . . 75 5.5 Description du sous cas d’utilisation « Ajouter patient » . . . . . . . . . . . . . . . . 76 5.6 Description du sous cas d’utilisation « Modifier patient » . . . . . . . . . . . . . . . . 77 5.7 Description du sous cas d’utilisation « Supprimer patient » . . . . . . . . . . . . . . 77 5.8 Tests fonctionnels du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 ix
Liste des abréviations — AG = Agile Modeling — API = Application Programming Interface — CRUD = Create Read Update Delete — DI = Dependancy Iinjection — EDI = Environnement de Développement Intégré — EF = Entity Framework — HTTP = HyperText Transfer Protocol — IHM = Interface Homme Machine — JSON = JavaScript Oobject Notation — MVC = Model View Control — PFE = Projet Fin d’Etude — RDV = Rendez Vous — REST = REpresentational State Transfer — RUP = Rational Unified Process — SPA = Single Page Application — TFS = Team Founsation Server — UML = Unified Modeling Language — URI = Uniform Resource Identifier — VS = Visual Studio — XP = eXtreme Programming x
Introduction générale Laxdémarche médicale est fondée sur l’observation du malade. La mémoire du médecin était autrefois suffisante pour enregistrer les données relatives aux patientsxet servir l’exercice médical. Les données médicalesxétaient rassemblées sous forme d’articles médicaux et administratives, avec la multiplication des effets de l’environnement, de nos jours la bonne tenue d’un dossier exige des moyens informatiques. L’automatisationxduxsystèmexd’informationxconsiste à structurerxet gérer un ensemble de données dont le but de lesxorganiser et d’avoir des résultats rapides. C’est dans ce cadre que s’inscrit notre projet de fin d’études qui a pour objectif la mise en place d’une application Web SPA intitulée « Lazarus » permettant essentiellement la réservation des rendez-vous afin d’augmenter la fiabilité, l’efficacité de l’effort humain et faciliter les tâches pénibles au sein des établissements médicaux Ce rapport présente l’ensemble des étapes suivies pour développer l’application. Il contient cinq chapitres organisés comme suit : Le premier chapitre intitulé « Présentation générale et étude de l’existant » est consacré à la présentation du contexte du projet, de l’organisme d’accueil avec la description du client pour lequel nous avons développé notre solution. Puis nous définirons le choix de la méthodologie de développement adoptée et nous finirons par présenter les outils utilisés ainsi que les différents environnements de développement. Le deuxième chapitre, « Sprint 0 : Analyse et spécification des besoins», s’articule autour de l’identification des acteurs et description des besoins fonctionnels et non fonctionnels. Puis, nous élaborons le Backlog du produit et nous terminons par la présentation des architectures physique et logique. Les chapitres 3, 4 et 5 décrivent respectivement la réalisation des Sprints 1, 2 et 3. Nous commençons par la spécification du sprint, ensuite nous présentons la phase conceptuelle qui sera matérialisée par l’élaboration du diagramme de classes ainsi que celle des diagrammes de séquence, puis nous présentons la phase d’implémentation par la description des interfaces de l’application et nous finissons par la réalisation des tests et des rétrospectives. 1
Chapitre 1 Présentation générale et étude de l’existant Plan 1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 3 2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 12 8 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . 14 9 Conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapitre 1. Présentation générale et étude de l’existant Introduction Ce chapitre a pour objectif de situer notre projet dans son contexte général. Nous commencerons par une présentation de l’organisme d’accueil Cynapsys IT Hotspot et par la suite nous détaillerons la description du sujet, les objectifs ainsi qu’une étude théorique des technologies utilisées. Nous finirons par présenter les outils utilisés ainsi que les différents environnements de développement. 1.1 Présentation de l’organisme d’accueil 1.1.1 Cynapsys IT Hotspot en bref Cynapsys est une entreprise de services numériques, Fondée en 2004 en Tunisie. Elle est une entreprise de prestation de services en technologie de l’information. Elle est spécialisée dans le domaine de l’assistance et le développement spécifique de logiciel pour la télécommunication, les équipements, la finance et l’industrie [1]. Le groupe Cynapsys conçoit, développe et déploie des solutions applicatives métiers à travers ses locaux à Paris, Frankfurt, Alger, Tunis et bientôt Abidjan [7]. Ayant acquis une grande expérience dans la gestion des projets off-shore et Nearshore. Cynapsys est totalement exportatrice [1]. En effet, elle a développé une bonne connaissance du marché européen, principalement la France et l’Allemagne [7]. Elle s’appuie sur la puissance des normes internationales. Depuis 2007, des décisions de la direction ont été prises en vue de la certification de management de la qualité CMMI niveau 2 et 3 et ISO 9001- v 20084, afin d’optimiser ses processus internes et de donner à ses clients le meilleur rapport qualité/prix [1]. Elle est Microsoft et Oracle Partner. Ensuite elle est l’une des rares entreprises, membre de l’union internationale de Télécom. Le management de l’entreprise adossé à ces compétences a permis à Cynapsys d’avoir la confiance de plus de 60 clients de 14 pays à travers le monde [1]. Figure 1.1: Présentation de Cynapsys IT 3
Chapitre 1. Présentation générale et étude de l’existant 1.1.2 Directions de Cynapsys Tunis Cynapsys est organisée en trois directions : une direction commerciale, une direction technique et une direction administrative. La direction technique comporté trois principaux pôles. La figure 1.2 illustre les pôles de Cynapsys IT Hotspot. Figure 1.2: Pôles de Cynapsys[1] Le pôle J2EE Open source a pour tâche la réalisation des applications sur demande en utilisant la technologie Java/J2EE. Et le pôle systèmes embarqués a pour rôle le développement des applications embarquées. Enfin le pôle Microsoft .Net, dans laquelle nous avons menu notre travail. Ce pôle est chargé du développement des applications en utilisant la technologie.NET. 1.2 Problématique Durant ce stage, il nous a été demandé de faire la conception, le développement et l’intégration d’une application Web qui permet essentiellement la prise de rende-vous et la gestion liés aux patients, médecins,consultations.. Le sujetxest certes intéressant carxl’application dont nous parlons peut avoir une vraie valeur ajoutéexdans la vie de chacun d’entre nous et ses perspectives d’évolution sont énormes surtout avec le progrès permanent de laxtechnologie. D’autre part pour la réalisation d’un tel projet, nous avons été confrontés à plusieurs difficultésxtechniques etxdécisionnelles. Mis à part le développement proprement dit de l’application, la première étape consistait à nous familiariser avec les nouvelles technologies .Net Core/Angular2, puis de choisir les outils les plus récents et envisageables à l’aboutissement du projet . Par la suite, nous avonsxentamé la modélisation et le 4
Chapitre 1. Présentation générale et étude de l’existant développement de l’application, pour cela nousxavons opté pour la méthode agile Scrumxafin d’avoir une meilleure adaptation aux besoins évolutifs et aussi pourxgarantir le respect des délais. Ensuite, nous passons à la création de la base de données générée par la migration àxpartir des classes dexnotre application. Afin de garantirxle succès d’une telle application, il faut surtout insisterxsur la pertinence des informations et la rapiditéxdu service proposé c’est pourquoixnous avons pensé à mettre en place une application Web pour gérer les CRUD de notre base de données et ainsi faciliter sa mise à jour afin de garantirxla précision des informations fournies. Nous avons également penséxà garantir l’innovation, dans notre cas la prise de rendez-vous, qui éliminera l’obstacle des horaires à respecter car elle sera désormais possible à tout moment. Du coté médecin, il génère la disponibilité des créneaux et contrôle le planning des rendez-vous . 1.3 Présentation du Projet Dans cette partie, nous allons tout d’abord étudier l’application existante. Cette étude nous permettra de spécifier progressivement notre projet et de ressortir quelques critiques à partir desquelles nous présenterons notre solution proposée. 1.3.1 Étude de l’existant Le potentiel du marché de l’e-santé ne cesse de croître, en témoignent le nombre croissant d’outils et d’applications mis à disposition sur le marché. Ce potentiel se mesure notamment par la croissance et la multiplicité des applications métiers destinées aux professionnels de santé. Dans cette partie, nous allons essayer de faire une étude comparative des logiciels qui existent au marché, cette étude permettra de : — S’inspirer des expériences similaires à notre projet et qui ont été déjà réalisées. Cette inspiration sera concrétisée dans l’outil qu’on devra réaliser. — Localiser notre système par rapport aux systèmes déjà existants. — Préciser ce que notre application doit faire. Plusieurs applications Open Source ou propriétaire existent aujourd’hui dans le domaine des systèmes d’informations hospitaliers. On a choisi parmi ces logiciels : Doctolib Doctolib a pour objectif d’améliorer le quotidienxdes professionnels de santé et des patients. Pour lesxpatients, il permet de trouver un praticien près de chez soi et de prendrexrendez-vous en quelques 5
Chapitre 1. Présentation générale et étude de l’existant clics mais on relève la difficulté de prise de rendez-vous en cas d’urgence si le particien choisi n’est pas disponible et aussi le manque d’internationalisation de l’application. med.tn med.tn estxune plateformexinnovante qui permet de trouverxrapidement un médecin ouxun dentiste proche et de prendre rendez-vousxen ligne gratuitement et en un clic mais on note le manque d’accès aux informations des patients par les médecins et aussi le grand nombre d’autorisation d’accès que l’application demande qui s’avère très gênant pour l’utilisateur. 1.3.2 Critique de l’existant La gestion de chaque établissement médical peut avoir quelques difficultés. Celles-ci peuvent se résumer dans : • Desxproblèmesxde gestionxdesxrendez-vous avec les patients. • La répétitionxdes informations relatives aux patients. • Le manque de confidentialité de l’information. 1.4 Objectifs Notre projet a pour objectif d’améliorer le fonctionnement de tous établissements de type médical, en intégrant les données médicales et administratives afin d’y remédier à tous ces problèmes, on peut assigner à notre étude les objectifs suivants : • Diminuer le coût de la fonction secrétariat des cabinets. • Faciliter la recherche et l’accès aux informations. • Permettre la prise de rendez-vous autonome (self-service). • Permettre le gain de temps. • Augmenter le chiffre d’affaire des cabinets. 1.5 Solution proposée Vu les besoins préliminaires, nous proposons une approchexde solution qui consiste à concevoir et à développer une application qui facilitera les insuffisances et les défaillances énumérées précédemment. On propose alors de concevoir une nouvelle application "Single page application" permettant l’organisation et l’automatisation des tâches qui ne peuvent être exercées sans l’appui 6
Chapitre 1. Présentation générale et étude de l’existant d’un réseau de communication pour diffuser les informations. Cette application permettra en outre d’assurer une meilleure communication et cohérence de l’information, optimiser le temps d’accès aux différentes données, éviter les tâches pénibles et ennuyeuses et permettra également aux patients un meilleur suivi de leurs rendez-vous dans un service médical de même pour les praticiens concernés. Ce type d’application métier s’avère très utile non seulement afin de subvenir aux besoins des patients mais il peut aussi représenter un réel avantage pour les médecins. Il s’agit de rapprocher le médecin de ses patients et de le rendre plus disponible et surtout accessible en cas de besoin. 1.6 Méthode de développement Selon des estimations, plus que 80 % des projets [8] qui utilisent des méthodologies traditionnelles connaissent des retards et des dépassements budgétaires parce que ces méthodologies visent à prédire la façon dont les procédures devraient se passer selon un planning préétabli. Notre projet suit le principe de développement itératif basé sur l’écoute du client, c’est pour cette raison que notre choix s’est orienté vers les méthodes agiles de développement et de gestion de projet. 1.6.1 Méthode Agile Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté AG) [9] visent à réduire le cycle de vie du logiciel et par conséquent accélérer sa réalisation en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement. L’origine des méthodes agiles est liée à l’instabilité de l’environnement technologique et au fait que le client est souvent dans l’incapacité de définir ses besoins de manière exhaustive dès le début du projet.Le terme «agile» fait ainsi référence à la capacité d’adaptation aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile dont la traduction est la suivante : • individus et interactions plutôt que processus et outils, • développement logiciel plutôt que documentation exhaustive, • collaboration avec le client plutôt que négociation contractuelle, • ouverture au changement plutôt que suivi d’un plan rigide. Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une première mise en production de son logiciel. Ainsi, il est possible d’associer les utilisateurs dès le 7
Chapitre 1. Présentation générale et étude de l’existant début du projet. Le tableau 1.1 illustre une étude comparative de différentes méthodologies agiles. Tableau 1.1: Étude comparative entre les approches agiles Description Points forts Points faibles Scrum • Hiérarchisation des membres de l’équipe. • Développement progressif. • Contrôle quotidien de travail. • Développement et test pour des courtes itérations. • Simplicité de processus. • Augmentation de la productivité. • Responsabilité collective de l’équipe. • Efficacité pour les projets de petite taille, car il ne fonctionne bien qu’avec une petite équipe. • Énorme effet inverse sur le développement du projet Si l’un des membres de l’équipe quitte, RUP • Promu par Rational. • Le RUP est une méthodologie et à la fois un outil prêt à l’emploi (documents types partagés dans un référentiel Web). • Il est itératif. • Il spécifie le dialogue entre les différents intervenants du projet : les plannings, les prototypes, les livrables... • Il est coûteux à personnaliser. 8
Chapitre 1. Présentation générale et étude de l’existant XP • Il est un ensemble de "Bests Practices" de Développement (transfert de compétences, travail en équipes... • Il s’adapte bien avec des projets de moins de 10 personnes. • Il est itératif. • Il concentre plus sur l’aspect technique : processus développement, prototypes, tests... • Il est assez difficile dans sa mise en œuvre : quels intervenants, quels livrables ? 2TUP • Il s’articule autour de l’architecture. • Suit un cycle de développement en Y. • Vise des projets de toutes tailles. • Il est itératif. • Il donne une large place à la technologie et à la gestion du risque. • Il définit les profils des intervenants, les plannings, les livrables et les prototypes. • Il apporte une réponse aux contraintes de changements imposées aux systèmes informatiques. • Il n’exige pas de documents types. 1.6.2 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 [10] car elle répond aux caractéristiques des méthodes agiles définies 9
Chapitre 1. Présentation générale et étude de l’existant dans la section précédente. Nous avons choisi la méthode Scrum pour les raisons suivantes : • elle est utilisée pour développer et tester les courtes itérations, • elle permet de produire la plus grande valeur métier dans la durée la plus courte, • elle permet l’augmentation de la productivité, • elle permet d’adapter le logiciel crée suivant l’évolution du projet. 1.6.3 Scrum C’est une méthode de développement agile orientée projet informatique dont les ressources sont régulièrement actualisées. Elle est basée sur les principes des méthodes agiles précédemment définis. Comme toutes les méthodes agiles, elle privilégie la livraison rapide d’un prototype, opérationnel par définition ,afin d’avoir un retour rapide des clients et des donneurs d’ordre pour minimiser les pertes de temps [11]. Les concepts de la méthode Scrum sont les suivants : 1.6.3.1 Le Sprint Le Sprint est une période qui varie entre deux et quatre semaines au maximum. Au bout de cette période, l’équipe délivre un incrément du produit potentiellement livrable. Une fois la durée est fixée, elle reste constante pendant toute la durée du développement. 1.6.3.2 Le chiffrage des tâches L’avantage de la méthode Scrum apparaît dans cette phase du projet. Le chiffrage consiste à estimer, pour chaque tâche, un degré de complexité ou bien combien ça coûte en termes d’effort. 1.6.3.3 Le Planning Poker Le planning poker est l’outil d’estimation fréquemment utilisé pour le développement des applications informatiques avec les méthodes agiles, notamment Scrum. L’équipe de développement logiciel utilise le planning poker pour produire des estimations de la complexité relative des fonctionnalités à développer [12]. 1.6.3.4 Scrum meeting Le Scrum Meeting n’est pas une réunion pendant laquelle nous cherchons à résoudre les problèmes, mais uniquement à les identifier et les exprimer. Le Scrum Master a pour rôle d’apporter 10
Chapitre 1. Présentation générale et étude de l’existant des solutions ou de déléguer à un autre membre de l’équipe la résolution des problèmes soulevés durant le Scrum Meeting. 1.6.3.5 Calcul de vélocité Une fois que tous les items de Backlog de produit ont été estimés, nous attribuons un certain nombre d’items à réaliser aux sprints successifs. 1.6.3.6 Revue de sprint À la fin du sprint, tout le monde se réunit pour effectuer la revue du sprint. L’objectif de la revue du sprint est de valider le logiciel qui a été produit pendant le sprint. L’équipe commence par énoncer les items du Backlog de produit qu’elle a réalisés. 1.6.3.7 Rétrospective de sprint La rétrospective du sprint est faite en interne à l’équipe. L’objectif est de détecter les erreurs commises et de prendre des décisions pour les améliorer. 1.6.3.8 Cycle de vie de la méthode SCRUM Comme indiqué dans la figure 1.3, pour mettre en place la méthode SCRUM, il faut dégager dans un premier lieu le maximum de fonctionnalités à réaliser pour former le Backlog du produit. En second lieu, définir les priorités des fonctionnalités et choisir lesquelles seront réalisées dans chaque itération. Par la suite, focaliser l’équipe de façon itérative sur l’ensemble des fonctionnalités à réaliser dans des itérations appelées Sprints. Un sprint aboutit toujours à la livraison d’un produit partiel fonctionnel appelé incrément. Ainsi, vers la fin de chaque Sprint, une réunion aura lieu pour effectuer la revue de l’itération. L’objectif de cette réunion consiste à valider l’incrément qui été produit pendant l’itération. 11
Chapitre 1. Présentation générale et étude de l’existant Figure 1.3: Cycle de vie SCRUM [2] 1.7 Environnement de développement Les choix techniques concernant les langages de développement ont été imposé par le Scrum Master dès le début du projet. 1.7.1 Langage de développement • C# [13] : Le développement de l’application se base sur le C# qui est un langage de programmation dérivé du langage C et inspiré du langage C++. Nous avons choisi ce langage vu ses majeurs avantages : simple, moderne, orienté objet. Il a été conçu pour générer des applications d’entreprise. • Type Script [14] : TypeScriptxest un langage de programmationxlibre etxopen-sourcexdéveloppé par Microsoft qui a pour but d’améliorer et de sécuriserxla production de code JavaScript. Il a été créé par Anders Hejlsberg en 2012 avec l’ajout de nouvelles fonctionnalités au langage JavaScript. • Linq [15] : Est un composant du framework .NET de Microsoft qui ajoute des capacitésxd’interrogation sur des données aux langagesx.NET en utilisant une syntaxe proche de celle de SQL 12
Chapitre 1. Présentation générale et étude de l’existant 1.7.2 Plateforme de développement • Visual Studio 2017 Professionnel [16] : à destinationxdes équipesxplus petites, Visual StudioxProfessionnel permet de développer desxapplications de qualité surxdes périphériques et des services, à l’aide d’unexsolution unique et avec une expériencexde développement cohérente. L’EDI dispose des outils pour la création des applications natives Windows Store, Windows Modile, Android, iOS, des applications Office, des applications Web, etc. • TFS [17] : Un système de gestion back-end pour développeurs Visual studio et Eclipse de Microsoft. TFS fournit des contrôles pour la gestion des exigences, des projets, des laboratoires et des rejets et utilise Team Foundation Version Contrôle ou Git pour la gestion du code source. Proposé comme une suite logicielle installée localement ou d’un service basé sur le cloud, TFS est utilisé pour gérer des équipes de programmeurs travaillant sur le même projet de logiciel . • Git [18] : C’est un logiciel de gestion de sources et de contrôle de versions. Ce type de programmes a plusieurs fonctions, notamment : — garder un historique des différentes versions des fichiers — permettre le retour à une version antérieure quelconque, — garder un historique des modifications avec leur nature, leur date, leur auteur, etc, — permettre un accès souple à ces fichiers en local ou via un réseau, — permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les mêmes fichiers • Postman [19] : Postman est une application permettant avec un navigateur Web de lancer des appels d’API et de les tester. Postman permet d’envoyer des requêtes vers l’API de site en lui ajoutant des en-têtes clés / valeurs puis il permet de formater le résultat sur plusieurs formats tels que JSON, XML, HTML et autres. 1.7.3 Framework de développement • Le Framework .NET CORE [20] : Le .NET Core est unexversion modulaire dux.NET Framework portable sur plusieurs plateformes pour optimiser le partage et la réutilisation du code. En outre, le .NET Core estxopen source et 13
Chapitre 1. Présentation générale et étude de l’existant acceptexles contributions de la Communauté. Cette rubrique répond aux questions courantesxsur le .NET Core. En outre, elle indique comment accéder et contribuer aux packages open source. • Entity Framework Core ( EF Core) [21] : Entity Frameworkx(EF) Core est une versionxlégère, extensible et multiplate-formexde la technologie d’accès aux donnéesxEntity Framework. EF Core est unxmappeur objet-relationnel (ORM) qui permet xaux développeursx.NET de travaillerxavec une base de données utilisant desxobjets .NET. Il élimine la nécessité de la plupart des codes d’accès aux données que les développeurs ont généralement besoin d’écrire. • Angular2 Framework [22] : Angular 2 est un frameworkxJavaScript open source pour créerxdes applications Webxen HTML et JavaScript et a été conçu comme une première approchexmobile. Angular2 comprendxdes éléments de programmationxréactive, nous utilisons donc lesx"Observables" pour créer des servicesxet des composants qui peuvent réagir aux changementsxde données dans notre application. Elles font partie de la bibliothèquexd’extensions réactives JavaScriptx(RxJS) et sont définies comme unexfonctionnalité inclusexdans la version ES7. 1.8 Langage de modélisation UML La conception de notre projet est basée sur le concept objet et articulée autour d’UML [23] (Unified Modeling Language) qui est par définition un langage de modélisation unifié et standardisé pour la conception des systèmes informatiques. UML a été choisi car il n’impose pas de méthode de travail particulière. Il peut être intégré à n’importe quel processus de développement logiciel puisqu’il présente une sorte de boîte à outils qui permet d’améliorer progressivement les méthodes de travail tout en préservant les modes de fonctionnement. Ce langage de modélisation est très intuitif, plus simple et cohérent que les autres méthodes. Il présente les différents points de vue de modélisation qui permettent de visualiser et de manipuler les éléments de la modélisation. En plus, il permet de limiter de nombreux risques d’erreurs. Nous avons utilisé pour ce fait l’outil Visual paradigm [24] car il permet la création des diagrammes UML et des modèles qui en sont à l’origine. 1.9 Conduite de projet La clé principale de réussite d’un projet avec la définition de la méthodologie de gestion de gestion de projet et le bon planning (Siegel, 2000). En effet, le planning aide à bien subdiviser le 14
Chapitre 1. Présentation générale et étude de l’existant travail et séparer les tâches à réaliser. Il offre une meilleur estimation et gestion de temps nécessaire pour chaque tâche (Bourque, 2014). En effet, il donne assez de visibilité qui permet d’estimer la date approximative d’achèvement des activités les plus importantes (Siegel, 2000). Nous avons utilisé le diagramme de Gantt pour bien visualiser le diagramme de temps relatif à notre méthodologie de travail. Nous avons donc estimé de réaliser notre application SPA dans une durée de 4 mois, démarrant de premier février jusqu’à fin Mai. Cependant, la planification est prévisionnelle et peu importe la façon dont un projet a été planifier, il y aura toujours des changements sur la route. Gantt Chart facilite la représentation graphique de l’avancement d’un projet. Nous avons utilisé ce diagramme afin de planifier de façon optimale et de communiquer le planning établi. La figure 1.4 illustre le diagramme de Gantt prévisionnel de notre projet. Figure 1.4: Diagramme de Gantt Conclusion Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil Cynapsys IT Hotspot , ses principales activités et compétences. Par ailleurs, nous avons dégagé le contexte général du projet et nous avons présenté le choix de la méthodologie de développement. Ensuite, nous avons présenté la méthodologie de développement Scrum utilisée pour mettre en place notre solution ainsi que les différentes plateformes utilisées. Dans le chapitre suivant, nous exposerons la première étape de notre projet à savoir l’analyse et la spécification des besoins. 15
Chapitre 2 Sprint 0 :Analyse et spécification des besoins Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 20 3 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 20 4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 20 5 Architecture Adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Introduction Dans ce chapitre, nous allons commencer par l’identification des acteurs. Ensuite, nous allons éliciter les besoins fonctionnels et non fonctionnels. Puis, dans une deuxième section, nous allons entamer la modélisation des besoins fonctionnels. Par la suite, nous allons élaborer le Backlog du produit et nous allons planifier les sprints. Pour conclure, nous allons présenter l’environnement matériel du projet. 2.1 Capture des besoins 2.1.1 Identification des acteurs Un acteur est une entité externe au système. Il représente une personne ou un autre système informatique qui attend un ou plusieurs services offerts par une interface d’accès. Il interagit avec le système par envoi ou réception des messages. Par ailleurs, notre application va intervenir les différents acteurs suivants : • L’administrateur : Il possède le droit d’accéder aux différentes rubriques de l’application afin d’ajouter des nouveaux utilisateurs et d’attribuer des droits d’accès et un rôle bien déterminé pour chaque utilisateur au niveau de son profil afin de lui permettre ou pas d’agir sur certaines données au niveau d’un module donné dans un établissement donné. • Le patient : Le patient peut accéder au planning des visites via internet afin de demander un RDV, il peut modifier ou annuler un RDV tout en recevant un mail de confirmation. • Le médecin : Le médecin peut gérer le planning de consultation quotidien. Il peut ajouter, modifier ou supprimer au niveau de la gestion des Rendez-vous, il peut gérer les solts de temps disponibles pour que le patient puisse réserver un RDV durant l’horaire convenable. Chaque médecin peut être associé à un service et un département bien déterminé . 2.1.2 Besoins fonctionnels L’analyse fonctionnelle [23] est une démarche qui consiste à caractériser les fonctions offertes par un produit pour satisfaire les besoins d’un utilisateur. En effet, chacun de ces besoins reflète 17
Chapitre 2. Sprint 0 :Analyse et spécification des besoins les attentes des différents utilisateurs envers le système conçu. Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de notre projet pour les différents modules de notre application. • Authentification : Chaque utilisateur (médecin, patient, administrateur), possède un login et un mot de passe spécifique qui lui permet de vérifier son identité, afin d’autoriser l’accès de cette entité à des ressources en toute sécurité. • Gestion des comptes utilisateurs : Cette fonctionnalité est assurée par l’administration de notre système qui est capable de gérer l’ensemble des utilisateurs. • Affectation des rôles : Tout utilisateur de ce système doit posséder un rôle qui est affecté par l’administrateur. En revanche, on a favorisé l’implémentation des permissions qui sont plus avantageux que les rôles. • Suivi des patients : Le médecin prend en charge la gestion de ses patients sans avoir besoin d’un secrétaire et qui lui facilite ses différents tâches. • Contrôle des médecins : L’administrateur doit associer un compte pour chaque médecin désirant adhérer à cette application tout en associant les informations spécifiques comme l’Id de service et le nom de département. • Suivi par calendrier : Elle concerne tout patient inscrit qui peut avoir à sa disposition tout un historique de ses rendez-vous déjà pris soit en tant que liste view ou sur un calendrier. • Affectation des départements : Cette partie concerne la création des différents départements existants dans un établissement pouvant être affecté à un médecin. • Suivi des RDV : Le patient a la possibilité de prendre un rendez-vous et il peut consulter l’état de sa demande de rendez-vous (En attente, acceptée ou refusée), de plus le médecin peut accepter ou refuser une demande de rendez-vous selon sa disponibilité. • Affichage de l’historique des rendez-vous : Le médecin peut consulter l’historique des demandes qu’il a acceptées et refusées. 18
Chapitre 2. Sprint 0 :Analyse et spécification des besoins • Générer la disponibilité : Chaque médecin doit générer ses créneaux en spécifiant l’horaire de disponibilité avec la possibilité de basculer un temps de réservation et le désactiver. • Envoyer notification : Après la réservation de rendez-vous, le patient recevra un mail de confirmation comprenant les différentes informations relatives au planning, de même pour le médecin concerné. 2.1.3 Besoins non fonctionnels En plus des fonctionnalités capitales citées précédemment, notre solution doit prendre en considération certaines contraintes additionnelles et répondre à un ensemble de besoins non fonctionnels. Il s’agit des besoins qui caractérisent le système à savoir : • Rapidité : il est clairement établi que la vitesse d’affichage influence fortement l’efficacité de l’application. C’est pour cette raison qu’il faut développer une application fournissant des résultats efficaces et cohérents et dans un temps négligeable suite aux requêtes issues des utilisateurs, • User-Expérience (UX) : l’application devra être plus utilisable, désirable et navigables permettant successivement la facilité d’emploi avec des interfaces consistantes,l’attrait visuel et la rapidité d’obtenir des informations, • Internationalisation : l’application doit être multilingue essentiellement en Anglais, Français et Arabe qui peut constituer un avantage concurrentiel par rapports aux autres produits, • Fiabilité : les résultats apportés par l’application doivent être fiables et reflètent effectivement l’état de la base au moment de son interrogation, c’est-à-dire des données mises à jour, • Disponibilité : l’application doit être disponible à tout instant pour être utilisée par n’importe quel utilisateur, et doit être facilement accessible, • Extensibilité : toute amélioration ou modification doit être facile à réaliser, ainsi notre application devra garantir un degré d’extensibilité à tout développeur souhaitant y contribuer. 19
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 2.2 Modélisation des besoins fonctionnels Nous allons maintenant représenter ces différents besoins sous forme d’un diagramme de cas d’utilisation. 2.3 Diagrammes des cas d’utilisation Nous donnons ci-dessous une vue globale concernant le comportement fonctionnel du système. Ce diagramme permet de représenter les interactions entre les acteurs et les cas d’utilisation du système. Figure 2.1: Diagramme de cas d’utilisation général 2.4 Pilotage du projet avec SCRUM 2.4.1 Les rôles Scrum L’équipe Scrum [11] est constituée d’un propriétaire de produit, de l’équipe de développement et d’un Scrum Master. Les équipes Scrum sont auto-organisées et pluridisciplinaires. Des équipes 20
Chapitre 2. Sprint 0 :Analyse et spécification des besoins auto-organisées choisissent la meilleure manière de réaliser le travail, plutôt que d’être dirigées par des personnes extérieures à l’équipe. Des équipes pluridisciplinaires ont toutes les compétences nécessaires pour réaliser le travail sans dépendre de personnes qui ne faisant pas partie de l’équipe. Le modèle d’équipe de Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité. Nous allons tout d’abord cerner notre équipe Scrum : • Product owner (PO) : Cynapsys Hotspot IT Représente le client du projet. C’est donc lui qui définit les attentes et les besoins du projet. Ainsi, son rôle est de définir les tâches qui permettront de répondre à ces besoins et mettra en place leur priorisation. • Scrum Master (SM) :Hamed Kolsi Le Scrum Master assure globalement le bon déroulement des programmes et il protège l’équipe de tout problème extérieur. Il assure également l’organisation des réunions et la bonne application de la méthode agile. • L’équipe de développement : Zohra BEN AHMED . Dans le cadre de ce projet l’équipe se limite en un seul membre qui est moi-même. 2.4.2 Backlog du produit Le Backlog du produit [25] correspond à une liste priorisée des besoins et des exigences du client. Les éléments du Backlog produit, appelé aussi des histoires utilisateurs, sont formulés en une ou deux phrases décrivant de manière claire et précise la fonctionnalité désirée par le client, généralement, écrit sous la forme suivante : En tant que X, je souhaite Y, an de Z. Le Backlog du produit comprend les champs suivants : • ID : c’est un nombre unique et auto-incrémenté pour chaque histoire • Titre : c’est le résumé du user story, • User Story : c’est une phrase décrivant la fonctionnalité désirée • Business Value : c’est la valeur métier qui dirige la priorisation du développement des histoires utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100, • Story point : c’est l’effort nécessaire à la réalisation d’une histoire utilisateur. il est estimé par l’équipe et il est fixe dans le temps : un point correspond à quatre heures de charge de travail pour une personne. Dans le tableau 2.1, nous présentons la liste des histoires utilisateurs ainsi que leurs estimations. 21
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Tableau 2.1: Le Backlog Produit ID Titre En tant que Je souhaite Afin de Business Value Story Point 1 S’authentifierAdministrateur Entrer mon login et mot de passe Gérer toutes les fonctionnalités 90 5 2 Gérer les utilisateurs Administrateur Créer, modifier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 5 3 Affecter les rôles Administrateur Créer, modifier,supprimer ou afficher les rôles Affecter les rôles 60 5 4 Gérer les profiles Administrateur Afficher et modifier les profiles Gérer les profiles 20 3 5 Gérer les comptes utilisateurs Administrateur Bloquer un utilisateur Bloquer un utilisateur 20 2 6 Gérer les patients Médecin Gérer les patients Créer, modifier,supprimer un patient 60 8 7 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 8 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 22
Chapitre 2. Sprint 0 :Analyse et spécification des besoins 9 Gérer horaire disponible Médecin générer disponibilité contrôler ses propres rendez-vous et les permissions de réservation par les patients 40 5 10 Consulter notification Patient voir les notifications envoyé par le système Confirmer la réservation de rendez-vous souhaité 40 5 11 Consulter consultation Patient voir l’historique de ses consultations Avoir une connaissance sur sa santé 40 5 12 Gérer les Web services Développeur développer tous les Web services utiliser les Web services dans la partie Web 90 8 13 Gérer les départements Administrateur Créer, modier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 10 14 Gérer les préférences Utilisateur Choisir les préférences par défaut Gérer les préférences 20 10 2.4.3 Planification des sprints Une fois que le Backlog du produit est suffisamment complet et ordonnancé, nous avons établi, lors de la réunion de planification des sprints, les durées prévisionnelles du travail à effectuer durant chaque sprint. Après avoir évalué le travail estimé et dû au fait que notre équipe est considérée comme une petite équipe, les sprints que nous avons définis durent entre trois et quatre semaines. le tableau 2.2 présente la planification des sprints. 23
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Tableau 2.2: Planification des sprints ID Nom Sprint Date Début Date Fin 1 Sprint 1 : Réalisation du module d’authentification et la gestion des modules d’utilisateurs, des rôles, des permissions 26/02/2017 25/03/2017 2 Sprint 2 : Réalisation du module de gestion des Rendez-vous côté médecin et côté patient et la gestion des flux des communications 26/03/2017 24/04/2017 3 Sprint 3 : Réalisation du module de contrôle des patients, médecins , départements et consultations 25/04/2017 26/05/2017 2.5 Architecture Adoptée Figure 2.2: La logique Modèle-Vue-Contrôleur Web API 24
Chapitre 2. Sprint 0 :Analyse et spécification des besoins L’architecture de notre application est l’architecture MVC Web API. Il s’agit d’une méthode de conception qui crée une séparation entre la logique métier ou de traitement et la logique de présentation. Le MVC cherche à séparer nettement les couches présentation, traitement et accès aux données. • Le client est ce qui consomme l’API Web (application mobile, navigateur, etc.). Nous utiliserons Postman ou curl pour tester l’application. • Un contrôleur est un objet qui gère les requêtes HTTP et crée la réponse HTTP. • Un modèle est un objet qui représente les données dans notre application. Figure 2.3: Modèle MVC [3] Le modèle MVC permet une séparation des compétences (design, base de données, application), une séparation claire entre les données du programme et la partie graphique affichant les données et une simplicité de mise à jour. Dans notre cas, toute autre application utilisateur ayant une interface utilisateur qui veut simplement accéder à notre service, lorsque la demande est demandée, une action sur notre contrôleur sera invoquée, le contrôleur enverra les données d’entrée et un Le modèle est retourné à la vue. La vue dans notre cas ne serait pas une page aspx, rasoir ou html mais représenterait les données de résultat au format JSON. Architecture Angular2 La figure 2.4 représente l’architecture d’Angular2. 25
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Figure 2.4: Architecture Angular2 [4] Il existe huit blocs principaux de l’application Angular 2 : • Modules : regroupement d’un ensemble de fonctionnalités sous un même Namespace. • Library Modules (barrels) : @angular/core, @angular/http... . • Les composants : Elément graphique composé d’un template et d’une classe • Directives : composants sans template (ngFor, ngIf, ...) • Métadata : Moyen d’indiquer à Angular comment utiliser la classe • Services : Code métier implémenté dans des classes qui seront injectées dans les différents composants. • Pipe : Elément permettant de formatter une donnée (équivalent au filter d’AngularJS). 2.6 Environnement matériel Notre environnement matériel est composé par des outils matériels et par une architecture physique. 2.6.1 Outils matériels Pour réaliser notre travail, nous avons utilisé comme environnement matériel un ordinateur portable avec un système d’exploitation Windows10 de 64 bits, ayant un processeur IntelR Core TM 26
Chapitre 2. Sprint 0 :Analyse et spécification des besoins i5, doté d’une Ram de 4 Go et d’un disque dur de 500 GO. 2.6.2 Architecture physique Notre application se présente sous la forme d’une architecture N-tiers. Le composant Web API de l’application agit comme une interface basée sur HTTP qui accepte les requêtes HTTP d’une application client tierce et effectue des opérations de données. Le diagramme suivant tente d’expliquer l’architecture possible de cette application hypothétique à l’aide de l’API Web. Figure 2.5: Architecture WebAPI avec EFCore [5] Cette application peut exposer sa logique métier aux différentes applications clientes utilisant l’API Web. L’API Web peut utiliser efficacement les Repositories pour découper les couches métier et d’accès aux données de la classe Web API Controller. L’application API Web peut utiliser l’injection Intégrée (DI) pour injecter les dépendances requises dans les objets. Par exemple, l’accès aux données peut être enregistré dans le DI et peut être injecté dans Business Layer, en outre, Business Layer peut être enregistré dans DI et injecté dans le Repository et Repository dans l’API Web. La figure 2.6 montre l’architecture globale de notre application. Cette architecture nous a aidé à développer notre application Web avec les designs patterns recommandés. 27
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Figure 2.6: Architecture globale de l’application [6] 2.6.3 Diagramme de déploiement Le diagramme de déploiement nous permet d’avoir une vue statique qui représente l’utilisation de l’architecture physique, et de la manière à travers laquelle les composants du système sont répartis. • Le serveur d’applicationxest responsable de laxgestion des sessions utilisateurs,xla gestion des patients, la gestion des médecins, gestion des RDV, etc. • Le serveur de données représentexla partie centrale qui gère la base de données et ses accès. • Le serveur webxtransmet à l’utilisateur le résultatxde la requête envoyé. • NodeJs est le responsable du chargement des pages pour les afficher dans le navigateur web, qui est en relation directe avec l’angular2 en utilisant le protocole http. • Entity Framework Core est responsable de la création de la base de données avec la migration automatique qui permet de faire la synchronisation avec le modèle de données. C’est l’approche Code First utilisée, c’est à dire à partir des classes vers la base de données. La figure 2.7 présente le diagramme de déploiement de la plate-forme Lazarus. 28
Chapitre 2. Sprint 0 :Analyse et spécification des besoins Figure 2.7: Diagramme de déploiement Conclusion Dans ce chapitre, nous avons passé en revue par les différentes notions nécessaires à la compréhension de notre sujet. Nous avons identifié les besoins fonctionnels et non fonctionnels de notre système ainsi que les acteurs. Ensuite, nous avons détaillé la première étape de la méthodologie que nous avons choisi à savoir l’identification de l’équipe de travail et la réalisation de backlog du produit. Ainsi, nous avons illustré la planification des sprints pour passer à la troisième étape qui est la mise en œuvre des sprints. Enfin, nous avons présenté l’architecture logique et physique de notre application. Dans le chapitre suivant, nous entamerons le premier sprint. 29
Chapitre 3 Réalisation du Sprint 1 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapitre 3. Réalisation du Sprint 1 Introduction Ce chapitre a pour objectif de fournir un produit livrable, testé et déployé au dernier sprint. En effet,nous exposerons la réalisation du premier sprint réparti en quatre étapes à savoir spécification, conception, codage, test et rétrospective. 3.1 Backlog du Sprint Le sprintxest le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel unxincrément du produit sera réalisé. Avant de se lancer dans un sprint, l’équipexScrum doit obligatoirement définir le but de ce dernier. Ce but doit être défini en terme métier pour qu’il soit compréhensible par les membres en dehors de l’équipe.xIl s’agit de répondre à une question fondamentale «pourquoi faisons-nous ce sprint ?». Le but du premier sprint est de réaliser le module d’authentificationxet la gestion des modules d’utilisateurs, des rôles , desxpermissions et l’affectation des rôles aux utilisateurs.xUne fois, nous avons défini le but de notre sprint, il est le temps de décider quelles histoires de notrexbacklog du produit seront incluses dansxle backlog du sprint. Les estimationsxdes histoires sont définis en jour. Tableau 3.1: Backlog du sprint 1 ID Histoire Estimation 1 Réaliser l’authentification de l’utilisateur 5 2 Ajouter, Modifier , Supprimer et désactiver un utilisateur 7 3 Ajouter,Modifier,Supprimer et affecter les rôles 5 4 Contrôler les permissions 3 3.2 Spécification Dans cette section, nous allons élaborer le raffinement du cas d’utilisation et nous allons présenter un description détaillée. 3.2.1 Diagramme de cas d’utilisation raffiné «S’authentfier» La figure 3.1 illustre le raffinement de cas d’utilisation «S’authentifier». 31
Chapitre 3. Réalisation du Sprint 1 Figure 3.1: Raffinement de cas d’utilisation «S’authentfier» Description textuelle du cas d’utilisation «S’authentifier» Le tableau 3.2 montre la description textuelle du cas d’utilisation «S’authentifier». Tableau 3.2: Description du cas d’utilisation « S’authentifier » Titre Authentification Acteurs Utilisateur Pré conditions utilisateur inscrit Post conditions utilisateur connecté Scénario nominal 1) L’utilisateur clique sur le lien login, 2) le système génère la page d’authentification, 3) l’utilisateur saisit les droits d’accès (nom d’utilisateur, mot de passe), 4) le système valide les informations de login et de mot de passe par rapport à celles qu’il a mémorisées, 5) le système ramène l’utilisateur à la page principale de l’application. 32
Chapitre 3. Réalisation du Sprint 1 Scénario alternatif Non validité des coordonnées : lorsque le mot de passe est erroné, le système affiche un message d’erreur et demande à l’utilisateur de saisir à nouveau son mot de passe,ou bien lorsque l’utilisateur fournit un login inconnu, le système affiche un message d’erreur et propose à l’utilisateur de saisir un autre login. 3.2.2 Diagramme de cas d’utilisation raffiné «Gestion des utilisateurs» La figure 3.2 illustre le raffinement de cas d’utilisation «Gestion des utilisteurs». Figure 3.2: Raffinement de cas d’utilisation «Gestion des utilisateurs» 3.2.2.1 Description du sous cas d’utilisation «Ajouter utilisateur» Tableau 3.3: Description du sous cas d’utilisation « Ajouter utilisateur » 33
Chapitre 3. Réalisation du Sprint 1 Résumé L’administrateur de notre application peut ajouter plusieurs utilisateurs (médecins, patients, ..) ayant chacun un rôle spécifique. Pré conditions L’administrateur est authentifié Post conditions L’utilisateur peut se connecter avec le nouveau compte créé Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 2) l’administrateur clique sur le bouton ajouter, 3) l’administrateur saisit le login, le mot de passe et les différents paramètres pour chaque utilisateur, 4) le système affecte un ID unique automatiquement pour chaque utilisateur, 5) le système valide le nouvel ajout. Scénario d’exception E1 : Si l’utilisateur que vient être ajouté par l’administrateur est déjà existant, le système affiche un message d’erreur. E2 : Si les champs sont vides, l’ajout ne sera pas effectué car l’opération est impossible L’enchaînement reprend à l’étape 1 du scénario nominal 3.2.2.2 Description du sous cas d’utilisation « Modifier utilisateur » Tableau 3.4: Description du sous cas d’utilisation « Modifier utilisateur » Résumé L’administrateur peut modifier les informations personnelles des membres (médecins, patients...) avec leurs profils et droits d’accès ayant chacun un rôle spécifique. Pré conditions Utilisateur déjà existant et l’administrateur est authentifié Post conditions Utilisateur modifié Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 34
Chapitre 3. Réalisation du Sprint 1 2) l’administrateur saisit l’ID de l’utilisateur qui vise à le modifier, 3) le système génère le résultat de la recherche, 4) l’administrateur tape les nouvelles informations relatives à l’utilisateur et met à jour les droits d’accès, 5) le système valide la mise à jour. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.2.3 Description du sous cas d’utilisation «Créer rôle» Tableau 3.5: Description du sous cas d’utilisation « Créer rôle » Résumé L’administrateur doit créer les différents rôles qui constituent une base pour l’autorisation. Pré conditions Rôle non crée et administrateur authentifié Post conditions Utilisateur affecté à un rôle bien déterminé Scénario nominal 1) L’administrateur accède à la page de gestion des membres, 2) l’administrateur crée les rôles qui représentent une condition pour que chaque utilisateur accède à son espace privé, 3) l’administrateur affecte un rôle à chaque utilisateur inscrit ce qui garantit une sécurité au moment de l’authentification. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.3 Prototype des IHM Après avoir étudié les tâches du sprint 1, nous avons établi quelques maquettes afin de les valider avec le product owner. La figure 3.3 représente un prototype d’interface de la page de gestion de la liste des rôles dans laquelle l’administrateur peut gérer les rôles. 35
Chapitre 3. Réalisation du Sprint 1 Figure 3.3: Prototype "Liste des rôles" La figure 3.4 représente le prototype de gestion des utilisateurs. Figure 3.4: Prototype "Liste des utilisateurs" 3.2.4 Conception Dans cette partie, nous allons représenter le diagramme de classes de notre projet ainsi que les diagrammes de séquence pour ce sprint. La figure 3.5 illustre le diagramme de classes de notre application. 36
Chapitre 3. Réalisation du Sprint 1 Figure 3.5: Diagramme de classe 37
Chapitre 3. Réalisation du Sprint 1 Description du diagramme de classe Notre diagramme de classes comporte douze tables. Les plus importantes sont les suivantes : • La classe Rôles : est une classe qui définit le rôle affecté à chaque utilisateur, d’où un utilisateur peut avoir un seul rôle et un rôle peut être affecté à plusieurs utilisateurs. • La classe Permission : est une classe qui valide les informations d’identification de l’utilisateur et gère les paramètres utilisateurs. Cette classe ne peut pas être héritée. • La classe profile : un utilisateur peut avoir au maximum un profile que décrit ses propres informations. • La classe utilisateur : est une classe qui représente l’utilisateur de notre application quelque soit administrateur, praticien ou patient. Elle regroupe toutes leurs fonctionnalités, un utilisateur peut en faite s’authentifier et modifier ses propres informations. • Les classes médecin et patient : sont des classes qui héritent de la classe mère utilisateur et qui représentent les acteurs de notre application. • La classe Rendez-vous : Avant de pouvoir prendre un rendez-vous, le patient doit vérifier la disponibilité d’un médecin déjà sélectionné afin de pouvoir confirmer le rendez-vous • La classe Notification : Après avoir fixé un rendez-vous, le patient reçoit une notification automatique par mail de confirmation en cas de non confirmation de présence, de même pour le médecin. • La classe Département : chaque médecin doit être affecté à un département bien déterminé selon sa spécialité. Ce diagramme de classes sera utilisé dans la réalisation de tous les sprints. Modèle physique des données MPD La figure 3.6 illustre le diagramme de modèle physique de données. 38
Chapitre 3. Réalisation du Sprint 1 Figure 3.6: Diagramme de Modèle physique de données 39
Chapitre 3. Réalisation du Sprint 1 3.2.5 Diagrammes de séquences Nous allons maintenant représenter les interactions pour le cas d’utilisation « S’authentifier » sous forme de diagrammes de séquence. La figure 3.7 illustre le diagramme de séquence pour authentifier un utilisateur . Figure 3.7: Diagramme de séquence « S’authentifier » Nous allons maintenant représenter les interactions pour le cas d’utilisation « Gérer les utilisateurs» sous forme de diagrammes de séquence. L’administrateur crée les profils des utilisateurs 40
Chapitre 3. Réalisation du Sprint 1 en identifiant le nom d’utilisateur et le mot de passe à chaque usagé pour accéder au système et il lui attribue des droits d’accès. Il peut éventuellement modifier ces profils en cas ou l’utilisateur a oublié son mot de passe ou son nom d’utilisateur ou en cas de modification des droits d’accès. Diagramme de séquence ’ajouter utilisateur’ La figure 3.8 illustre le diagramme de séquence pour ajouter un utilisateur. Figure 3.8: Diagramme de séquence «Ajouter Utilisateur» Après avoir accéder à l’application, l’administrateur doit s’authentifier puis consulter la liste des utilisateurs et pourra ajouter un utilisateur. 41
Chapitre 3. Réalisation du Sprint 1 Diagramme de séquence de ’modifier un utilisateur’ La figure 3.9 illustre le diagramme de séquence pour modifier un utilisateur . Figure 3.9: Diagramme de séquence «Modifier Utilisateur» Après avoir s’authentifier, l’administrateur peut consulter la liste des utilisateurs et modifier un utilisateur. 42
Chapitre 3. Réalisation du Sprint 1 Diagramme de séquence de ’supprimer un utilisateur’ La figure 3.10 illustre le diagramme de séquence pour supprimer un utilisateur . Figure 3.10: Diagramme de séquence «Supprimer Utilisateur» Après avoir accéder à l’application, l’administrateur doit s’authentifier puis consulter la liste des utilisateurs et pourra supprimer un utilisateur. 43
Chapitre 3. Réalisation du Sprint 1 3.2.5.1 Diagramme d’activité La gestion des droits d’accès est liée directement à la gestion des utilisateurs, en effet l’administrateur peut créer des profils qui diffèrent d’un utilisateur à un autre selon les droits attribués. Figure 3.11: Diagramme d’activité "Gestion des profils et des droits d’accés " 44
Chapitre 3. Réalisation du Sprint 1 3.3 Code Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures d’écran. La figure 3.12 représente l’interface d’authentification pour l’utilisateur afin de manipuler les fonctionnalités de l’application SPA. Figure 3.12: Interface "S’authentifier" La figure 3.13 représente l’interface pour consulter la liste des utilisateurs. Figure 3.13: Interface "Consulter la liste des utilisateurs" À travers cette interface, l’administrateur peut gérer les utilisateurs. Il peut consulter, ajouter , modifier ou supprimer un utilisateur. Dans ce qui suit, nous allons détailler les scénarios 45
Chapitre 3. Réalisation du Sprint 1 de la gestion des utilisateurs sous forme des captures d’écran. La figure 3.14 représente l’interface d’ajout d’un utilisateur. Figure 3.14: Interface "Ajouter un utilisateur" Dans cette interface, l’administrateur a le droit d’ajouter un nouveau utilisateur. Il doit remplir le formulaire de création d’un utilisateur et valide sa saisie. La figure 3.15 représente l’interface de modification d’un utilisateur. Figure 3.15: Interface "Modifier un utilisateur" 46
Chapitre 3. Réalisation du Sprint 1 À travers la figure 3.15 , l’administrateur peut modifier un utilisateur. La figure 3.16 représente l’interface de suppression d’un utilisateur. Figure 3.16: Interface "Supprimer un utilisateur" Pour supprimer un utilisateur, l’administrateur clique sur le bouton "delete" et automatiquement une fenêtre s’affiche indiquant si l’administrateur veut confirmer la suppression de l’utilisateur. La figure 3.17 représente l’interface de création des rôles qui constituent la base pour l’autorisation. Figure 3.17: Interface "Ajouter un rôle " La figure 3.18 représente l’interface de modification d’un rôle choisi. 47
Chapitre 3. Réalisation du Sprint 1 Figure 3.18: Interface "Modifier un rôle " La figure 3.19 indique l’interface de profile personnel. Figure 3.19: Interface "Afficher profile " 3.4 Test Le test [23] d’un produit logiciel est un processus consistant qui vise à garantir le bon fonctionnement du système à travers une comparaison des comportements attendus et des résultats obtenus. Avant la fin de chaque Sprint nous avons testé les fonctionnalités du module. Ensuite nous avons validé toutes les fonctionnalités avec le Product Owner. Pour ce fait,nous avons élaboré dans le tableau 3.6 présenté ci-dessous un ensemble de cas de scénario de tests fonctionnels relatif au sprint 1. 48
Chapitre 3. Réalisation du Sprint 1 Tableau 3.6: Tests fonctionnels du sprint 1 Cas de test Démarches Comportements attendus Résultat Test d’authentification de l’utilisateur • demander la page d’authentification, • saisir le login et le mot de passe, • cliquer sur se connecter. • le système affiche la page de connexion, • l’utilisateur est redirigé vers la page d’accueil. Conforme Test d’ajout d’un nouvel utilisateur • demander la page de gestion des utilisateurs, • cliquer sur New User, • remplir le formulaire convenablement, • cliquer sur Valider. • la page de gestion des utilisateurs s’affiche, • la page d’ajout des utilisateurs s’affiche, • l’utilisateur est ajouté. Conforme Test de modification utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Edit User", • Remplir le formulaire convenablement, • Cliquer sur Save. • Affichage de la page de gestion des utilisateurs, • Affichage de la page de modification des utilisateurs, • Modification de l’utilisateur. Conforme 49
Chapitre 3. Réalisation du Sprint 1 Test de Suppression utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Delete User", • Cliquer sur "OK". • Affichage de la page de gestion des utilisateurs, • Apparition d’une fenêtre (Pop-Up), • Suppression de l’utilisateur. Conforme Après avoir vérifié le bon fonctionnement du code et des fonctionnalités, le premier livrable a été testé par le Product Owner.Ainsi,il nous a transmis la liste des améliorations,des fonctionnalités à ajouter et des bugs à signaler. 3.5 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • CRUD utilisateurs • CRUD rôle • Module d’authentification Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Détailler les profils d’utilisateur un peu plus. Conclusion Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons passé par la spécification, la conception, le codage et les tests. Dans le chapitre suivant nous entamons le deuxième sprint 50
Chapitre 4 Réalisation du Sprint 2 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2 Réalisation du module de gestion des rendez-vous . . . . . . . . . . . . . 52 3 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapitre 4. Réalisation du Sprint 2 Introduction Après la réalisation du premier sprint, nous entamerons le deuxième sprint. Nous allons présenter dans ce chapitre la réalisation de ce sprint réparti en quatre modules à savoir spécification, conception, codage, test et rétrospective. 4.1 Backlog du Sprint Dans cette partie, nous allons élaborer le backlog du deuxième sprint. Le but de ce dernier est la gestion des rendez-vous médicaux. Les estimations des histoires sont définis en jour. Le tableau 4.1 montre le backlog de notre deuxième sprint Tableau 4.1: Backlog du sprint 2 ID Histoire Estimation 1 Créer un rendez-vous 5 2 Annuler un rendez-vous 7 3 Recevoir notification 5 4 Consulter la liste des rendez-vous 3 5 Gérer calendrier 2 6 Générer disponibilité du médecin 4 7 Consulter la liste de créneaux disponibles 2 4.2 Réalisation du module de gestion des rendez-vous 4.2.1 Mise en oeuvre des patrons de conception Repository et unitofwork dans ASP.NET Core Dans ce projet, nous concevons un modèle Repository commun pour toutes les entités et une classe Unit of work. Le diagramme suivant montre la relation entre le Repository et le contexte de données de Entity Framework Core, dans lequel les contrôleurs MVC interagissent avec le dépôt par une unité de travail plutôt que directement avec le cadre d’entité. 52
Chapitre 4. Réalisation du Sprint 2 Figure 4.1: Diagramme "Generic Repository Pattern and Unit of Work workflow" Implémentation de Repository Pattern Le modèle Repository pattern [26] est utilisé pour créer une couche d’abstraction entre le DAL (Data Access Layer) et le BAL (Business Access Layer) pour effectuer les opérations CRUD. Voici un extrait de code de la classe IRepository.cs. Figure 4.2: Extrait de code de la classe IRepository 53
Chapitre 4. Réalisation du Sprint 2 Pour notre application, nous avons généré le schéma à partir de la solution. la figure 4.3 montre le diagramme de Repository pattern. Figure 4.3: Diagramme Repository pattern Implémentation de "Unit of work Pattern" Le modèle Unit of Work [27] gère les opérations CRUD de la base de données en mémoire sur les entités en tant qu’une transaction. Donc, si l’une des opérations échoue, les opérations db entières seront en panne. Voici un extrait de la classe IUnitofwork.cs. 54
Chapitre 4. Réalisation du Sprint 2 Figure 4.4: Extrait de code de la classe IUnitofwork Avantages des patrons de conceptions repository et unit of work [26] — Gérer les opérations de la base de données dans la mémoire et enregistre plus tard les mises à jour en mémoire en tant que transaction dans la base de données. — Facilite pour que les couches soient lâchement couplées à l’aide d’une injection de dépendance. — Facilite le suivi des tests unitaires ou du développement axé sur les tests. 4.2.2 Mise en oeuvre des services web Un service Web [28] est un composant logiciel identifié par une URL (Uniform Resource Locator), dont ses interfaces publiques sont définies et consultées à travers XML. Les services Web interagissent entre eux à travers des messages XML. Les services Web fournissent un lien entre les différentes applications. Ainsi, les applications peuvent envoyer et recevoir des données en utilisant des technologies différentes (l’interopérabilité). Les services Web utilisent les standards XML et HTTP pour le transfert des données (normalisées). Les services Web permettent de partager des services et des fonctionnalités de manière très efficace. De plus, ils réduisent le temps de développement puisqu’ils permettent d’exploiter des services existants. 55
Chapitre 4. Réalisation du Sprint 2 4.2.2.1 Les caractéristiques d’un Web service Un service Web est caractérisé par : • l’accessibilité via le réseau, • la disposition d’une interface publique contenant un ensemble d’opérations décrites en XML, • le stockage de la description d’un Web service (fonctionnalités, comment l’invoquer et où le trouver) dans un annuaire, • la communication via des messages XML qui sont transportés par les protocoles Internet (HTTP, SMTP, FTP, etc...), • la production des systèmes faiblement couplés. C’est à dire le demandeur du service peut ne pas connaître le fournisseur. Ce dernier peut disparaître sans perturber l’application cliente qui trouvera un autre fournisseur en cherchant dans l’annuaire. 4.2.2.2 REST vs SOAP REST [28] et SOAP [28] sont des architectures qui permettent de fournir des services Web. Par contre, REST est utilisé lorsque nous cherchons la simplicité de la mise en ouvre. REST est lisible (pas d’enveloppe XML superflue) et facile à tester en utilisant un navigateur Web et simple à mettre en oeuvre (un script PHP classique peut souvent être considéré comme RESTful). SOAP reste toujours intégré dans de nombreux outils de développements (possibilité d’export de classes en Web services, possibilité de génération automatique de clients à partir des WSDL) et permet le contrôle sur les types de données attendus. Et puisque nous cherchons la simplicité et la rapidité nous avons choisi l’architecture REST pour nos services Web. 4.2.2.3 Service Web RESTfull L’architecture REST utilise le protocole HTTP, plutôt que de réinventer une sur couche comme SOAP. Nous accèdons à une ressource par son URI unique pour procéder à diverses opérations (GET, POST, PUT, DELETE), supportées nativement par HTTP. REST n’impose pas un format d’échange entre client et serveur. Nous sommes libre de représenter les données en XML,JSON ou dans tout autre dialecte. Les services REST permettent aux clients d’indiquer le format dans lequel ils souhaitent communiquer, sous la forme d’un paramètre supplémentaire dans l’URL, ou plus simplement grâce à l’en-tête HTTP en spécifiant le type du contenu (content-type). REST suit les règles suivantes : 56
Chapitre 4. Réalisation du Sprint 2 • l’URI (identifiant des ressources) : REST se base sur les URI afin d’identifier une ressource. Ainsi une application doit construire ses URI de manière précise, en tenant compte des contraintes REST. Exemple : Non RESTful : GET /getProduct ?id=1 Représentation RESTful : GET/product/1 ; • les verbes HTTP (identifiant des opérations) : REST utilise les méthodes HTTP existantes plutôt que d’inclure les opérations dans l’URI de la ressource. Généralement pour une ressource, il y a quatre opérations fréquentes sont CRUD (Create, Read, Update, Delete) : créer (POST), consulter (GET), mettre à jour (PUT) et supprimer (DELETE), • les réponses HTTP ( représentation des ressources) : La réponse envoyée n’est pas une ressource, c’est la représentation d’une ressource. En plus, une ressource peut avoir plusieurs représentations dans des formats divers : HTML, XML, CSV, JSON, etc. 4.2.2.4 Avantages du REST Le RESTxpermet une indépendance vis à visxdu langage de programmation et de la plateforme sur laquelle ils sont déployé, unexsimplicitéxd’implémentation et aucune intégration du format d’échange dans les messages. Nous avons réalisé tous les web services utilisés dans l’applicationxsingle page en nous basant sur la technologie MVC Web api. Concernant la spécification du format de représentation utilisé dans les résultats des Web services que nous avons réalisés, nous avons choisi JSON parce qu’il est en format texte permet de représenter des données et de les échanger facilement. 4.3 Spécification Dans cette section, nous allons élaborer le raffinement du cas d’utilisation et nous allons présenter des prototypes pour les interfaces graphiques. Par le biais de notre application, le patient peut prendre un rendez-vous désiré en un seul clic avec une meilleure visibilité des plannings des différents médecins prés de chez soi. Après que le rendez-vous est fixé, le médecin prescripteur reçoit une alerte de confirmation et peut gérer sa consultation. 4.3.1 Diagramme de cas d’utilisation raffiné «Suivi des rendez-vous» La figure 4.5 illustre le raffinement de cas d’utilisation «Suivi des rendez-vous». 57
Chapitre 4. Réalisation du Sprint 2 Figure 4.5: Raffinement de cas d’utilisation «Suivi des rendez-vous» 4.3.1.1 Description du sous cas d’utilisation «Créer rendez-vous » Pour prendre un rendez-vous, le patient sélectionne la date et l’heure du rendez-vous souhaité. Après la vérification de la disponibilité du médecin, le rendez-vous est enregistré dans la base de données et un message de confirmation s’affiche au patient. Si la date et/ou l’heure sélectionnée ne correspondent pas à la disponibilité du médecin, le système envoie un message d’erreur au patient pour lui informer que son rendez-vous n’a pas été enregistré et lui demande de choisir une autre date. 58
Chapitre 4. Réalisation du Sprint 2 Tableau 4.2: Description du sous cas d’utilisation « Créer rendez-vous » Résumé Dans ce cas d’utilisation, le patient prend en charge la gestion de ses propres RDV et le médecin reçoit la liste des RDV des patients concernés. En fait, le patient peut créer, modifier ou annuler un RDV. Pré conditions Date de rendez-vous disponible et non prise par un autre patient. Post conditions Date de rendez-vous fixée, Un nouveau RDV sera ajouté Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur la date désirée, 3) une fenêtre de création d’un nouveau rendez-vous s’affiche, 4) le patient saisit les différents informations nécessaires, 5) une fenêtre de confirmation s’affiche en cas ou la date est valable, 6) un mail de confirmation est envoyé au patient, 7) le rendez-vous réservé sera affecté à la date approprié sur l’agenda. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. E2 : Si la date choisie sera occupé, un message d’erreur sera affiché et le patient choisit une autre date L’enchaînement reprend à l’étape 1 du scénario nominal 4.3.1.2 Description du sous cas d’utilisation «Annuler rendez-vous » Tableau 4.3: Description du sous cas d’utilisation « Annuler rendez-vous » Résumé Un patient peut annuler un rendez-vous à tout moment et cette fonction apporte une meilleure flexibilité pour la gestion personnelle des rendez-vous. Pré conditions Rendez-vous déjà existant. Post conditions Rendez-vous non existant Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur le rendez-vous déjà réservé, 3) une fenêtre s’affiche pour l’annulation de rendez-vous, 4) le patient clique sur "cancel appointement", 5) le rendez-vous est annulée et il s’affiche avec la couleur gris. 59
Chapitre 4. Réalisation du Sprint 2 Scénario d’exception E1 :Si le délai de rendez-vous pris est déjà dépassé, le système affiche un message d’erreur et le patient ne peut appliquer aucune action d’annulation. 4.3.1.3 Description du sous cas d’utilisation «Gérer Calendrier » Tableau 4.4: Description du sous cas d’utilisation « Gérer Calendrier » Résumé La gestion des RDV se focalise sur l’usage d’un agenda qui s’affiche comme un Dashboard pour le patient. Pré conditions Patient authentifié. Post conditions Calendrier affiché Scénario nominal 1) Le patient saisit son login et son mot de passe, 2) le patient accède à son espace personnel, 3) le patient peut afficher ou créer un nouveau RDV à partir du calendrier. Tableau 4.5: Description du sous cas d’utilisation « Générer disponibilité » Résumé La génération de disponibilité est indispensable pour la réservation d’un rendez-vous. Pré conditions Médecin authentifié . Post conditions Créneaux générés Scénario nominal 1) Le médecin saisit son login et son mot de passe, 2) le médecin clique sur "availibility" dans le menu, 3) le médecin clique sur "generate availibility", 4) le médecin choisit la date de début , de fin, intervalle pour la durée de rendez-vous et le temps et clique sur "Generate". 4.3.2 Prototype des IHM Après avoir étudié les tâches du sprint 2, nous avons établi quelques maquettes afin de les valider avec le Product Owner. La figure 4.6 présenté ci-dessous indique le prototype de Suivi par 60
Chapitre 4. Réalisation du Sprint 2 calendrier. Figure 4.6: Prototype "Suivi par calendrier" La figure 4.7 représente le prototype de prise de rendez-vous. Figure 4.7: Prototype "Prise de rendez-vous" 4.4 Conception Nous allons maintenant représenter les interactions de ce sprint sous forme de diagrammes de séquence. 61
Chapitre 4. Réalisation du Sprint 2 Diagramme de séquence de ’Réserver rendez-vous’ La figure 4.8 illustre le diagramme de séquence relatif au cas d’utilisation « Réserver un RDV». Figure 4.8: Diagramme de séquence «Réserver rendez-vous » 62
Chapitre 4. Réalisation du Sprint 2 Diagramme de séquence ’Annuler rendez-vous’ La figure 4.10 illustre le diagramme de séquence pour annuler un rendez-vous. Figure 4.9: Diagramme de séquence «Annuler rendez-vous» 63
Chapitre 4. Réalisation du Sprint 2 Diagramme de séquence de ’Générer disponibilité’ La figure 4.10 illustre le diagramme de séquence générer disponibilité. Figure 4.10: Diagramme de séquence «Générer disponibilité» 64
Chapitre 4. Réalisation du Sprint 2 4.5 Code Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures d’écran. Une interface agenda avec vos créneaux disponibles et vos rendez-vous et la possibilité en cliquant simplement sur un créneau libre, d’ajouter un nouveau rendez-vous. La figure 4.11 représente l’interface de réservation d’un nouveau rendez-vous tout en introduisant les différents informations nécessaires ( nom patient, symptômes, médecin préféré, horaire..) avec la possibilité de le marquer comme "critique" en cas d’urgence. Figure 4.11: Interface "Réserver un rendez-vous" Après avoir réservé un rendez-vous , une notification de confirmation de réservation sera déclenchée à condition que la date choisie sera disponible pour le médecin et le patient peut annuler ce rendez-vous. Par ailleurs, le patient peut annuler le rendez-vous déjà réservé. La figure 4.12 représente l’interface de succès de réservation de rendez-vous en affichant le nom de médecin et la date. 65
Chapitre 4. Réalisation du Sprint 2 Figure 4.12: Interface "Confirmation de réservation de rendez-vous" La figure 4.13 représente l’interface d’annulation de rendez-vous. Figure 4.13: Interface "Annuler rendez-vous" Le patient peut afficher par la suite la liste de ses rendez-vous réservés soit dans un "calendarView" soit dans une "listview". Si le rendez-vous est mentionné en vert alors il est encore active et s’il est indiqué en gris ça montre qu’il a été annulé. La figure 4.14 représente l’interface de la liste des rendez-vous déjà pris. 66
Chapitre 4. Réalisation du Sprint 2 Figure 4.14: Interface "Liste des Rendez-Vous" La figure 4.15 représente l’interface la liste des rendez-vous sous forme d’un listview. Figure 4.15: Interface "Historique des rendez-vous" La figure 4.16 représente l’interface de réception de mail de confirmation. 67
Chapitre 4. Réalisation du Sprint 2 Figure 4.16: Interface "Notification de confirmation de rendez-vous par mail" Par ailleurs, le médecin peut suivre la liste de ses rendez-vous dans un calendrier. La figure 4.17 représente l’interface de la liste des rendez-vous déjà pris. Figure 4.17: Interface "Liste des plannings pour un médecin" Pour que le patient puisse réserver un rendez-vous, le médecin doit générer son horaire disponible tout en spécifiant la date de début, la date de fin et la durée de son pause. La figure 4.18 représente l’interface de génération de créneaux disponibles pour chaque médecin. 68
Chapitre 4. Réalisation du Sprint 2 Figure 4.18: Interface "Génération de temps disponible" Le médecin peut afficher par la suite ses horaires disponibles, la durée de chaque consultation. La figure 4.19 représente l’interface de la liste de temps disponible pour chaque médecin. Figure 4.19: Interface "La liste de temps disponible" La figure 4.20 représente l’interface de notification par message pour chaque médecin. 69
Chapitre 4. Réalisation du Sprint 2 Figure 4.20: Interface "Notification par message" 4.5.1 Test Pour ce fait, nous avons élaboré dans le tableau 4.5 un ensemble de cas de scénario de tests fonctionnels relatif au sprint 2. Tableau 4.6: Tests fonctionnels du sprint 2 Cas de test Démarches Comportements attendus Résultat Test de réservation d’un nouveau RDV • Accéder à l’interface de Calendrier, • Cliquer sur New appointment, • Accéder à l’interface d’ajout d’un rendez-vous, • Remplir le formulaire convenablement, • Cliquer sur Valider. • Affichage de la page d’accès au calendrier, • Affichage de la page d’ajout d’un nouveau RDV, • Génération de message du confirmation, • le rendez-vous est réservé. Conforme 70
Chapitre 4. Réalisation du Sprint 2 Test de Génération de slots vides • Accéder à la page de calendrier , • Cliquer sur availability dans le menu, • Cliquer sur générer availability, • Séléctionner l’horaire désiré, • Cliquer sur Valider. • Affichage de la page d’accès au calendrier, • Affichage de la page d’ajout de solts disponibles, • Succés de génération. Conforme 4.6 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • prise rendez-vous. • génération disponibilité. • envoi du mail du confirmation au médecin et patient. • génération d’alerte par message de notification à l’accueil. Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Réservation de rendez-vous automatique selon les symptômes. • Réservation du rendez-vous selon le filtrage du pays . Conclusion Ce chapitre concerne le deuxième sprint à savoir la réalisation du module de gestion des rendez-vous côté Web en passant par la spécification, la conception, le codage, les tests et les rétrospectives. Dans le chapitre suivant nous entamons le troisième sprint. 71
Chapitre 5 Réalisation du Sprint 3 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chapitre 5. Réalisation du Sprint 3 Introduction Après la réalisation du deuxième sprint, nous entamerons le troisième sprint. Nous allons présenter dans ce chapitre la réalisation de ce sprint réparti en quatre modules à savoir spécification, conception, codage, test et rétrospective. 5.1 Backlog du Sprint Dans cette partie, nous allons élaboré le backlog du troisième sprint. Le but de ce dernier est le contrôle des patients , médecins et les consultations concernés. Les estimations des histoires sont définis en jour. Le tableau 5.1 montre le backlog de notre troisième sprint. Tableau 5.1: Backlog du sprint 3 ID Histoire Estimation 1 Consulter la liste des patients 5 2 Enregistrer les profils des patients 7 3 Ajouter , modifier et supprimer les patients 5 4 Consulter la liste des médecins 3 5 Ajouter , modifier et supprimer les médecins 2 6 Consulter les profils des médecins 4 7 Vérifier les consultations 2 7 Gérer les départements 3 5.2 Spécification Dans cette section, nous allons élaborer le raffinement des cas d’utilisation et nous allons présenter des prototypes pour les interfaces graphiques. 5.2.1 Diagramme de cas d’utilisation raffiné «Contrôler médecin» La figure 5.1 illustre le raffinement des cas d’utilisation «Contrôler les médecins». 73
Chapitre 5. Réalisation du Sprint 3 Figure 5.1: Raffinement de cas d’utilisation «Contrôler médecin» Tableau 5.2: Description du sous cas d’utilisation « Ajouter médecin » Résumé L’administrateur se charge d’ajouter des nouveaux médecins. Pré conditions Administrateur authentifié et médecin non existant. Post conditions Médecin crée Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) la liste des médecins s’affiche, 4) l’administrateur clique sur "New Provider", 5) une fenêtre pop-up de création d’un nouveau médecin se déclenche, 6) l’administrateur remplit le formulaire et clique sur "Save", 7) la page de création du profil s’affiche, 8) l’administrateur affecte le département, saisit le service et spécifie le reste des informations personnelles et clique sur le bouton "Save", 9) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. 74
Chapitre 5. Réalisation du Sprint 3 Tableau 5.3: Description du sous cas d’utilisation « Modifier médecin » Résumé L’administrateur peut modifier les informations d’un médecin choisi. Pré conditions Administrateur authentifié et médecin déjà existant. Post conditions Médecin modifié Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) la liste des médecins s’affiche, 4) l’administrateur clique sur l’icône "Edit", 5) une fenêtre pop-up de modification d’un médecin sélectionné se déclenche et les champs sont activés pour changement désirable, 6) l’administrateur remplit le formulaire avec les différents informations nécessaires, 7) L’administrateur clique sur "Save", 8) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si les champs sont vides, un message de validation sera généré Tableau 5.4: Description du sous cas d’utilisation « Supprimer médecin » Résumé L’administrateur peut supprimer un médecin. Pré conditions Administrateur authentifié et médecin déjà existant. Post conditions Médecin supprimé Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) le système affiche la page de la liste des médecins, 4) l’administrateur clique sur le bouton "Supprimer", 5) le système affiche un message pour confirmer la suppression et l’administrateur clique sur «ok», 6) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si l’administrateur essaye de supprimer un compte de médecin, il doit tout d’abord le supprimer de la liste des médecins, sinon un message d’erreur s’affiche. 75
Chapitre 5. Réalisation du Sprint 3 5.2.2 Diagramme de cas d’utilisation raffiné «Suivre patient» La figure 5.2 illustre le raffinement des cas d’utilisation «Suivre patient». Figure 5.2: Raffinement de cas d’utilisation «Suivre patient» Tableau 5.5: Description du sous cas d’utilisation « Ajouter patient » Résumé L’administrateur se charge d’ajouter des nouveaux patients. Pré conditions Administrateur authentifié et médecin non existant. Post conditions Médecin crée Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) la liste des patients s’affiche, 4) l’administrateur clique sur "New Patient", 5) une fenêtre pop-up de création d’un nouveau compte patient se déclenche, 6) l’administrateur remplit le formulaire et clique sur "Save", 7) la page de création du profil s’affiche et l’administrateur spécifie le groupe sanguin et les informations relatives au patient et valide, 8) le système génère la nouvelle liste des patients. 76
Chapitre 5. Réalisation du Sprint 3 Scénario d’exception E1 : Si l’administrateur ne remplit pas tous les champs obligatoires d’ajout d’un patient, un message d’alerte se déclenche. Tableau 5.6: Description du sous cas d’utilisation « Modifier patient » Résumé L’administrateur peut modifier les informations d’un patient choisi. Pré conditions Administrateur authentifié et patient déjà existant. Post conditions Médecin modifié Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) la liste des patients s’affiche, 4) l’administrateur clique sur l’icône "Edit", 5) une fenêtre pop-up de modification d’un patient sélectionné se déclenche et les champs sont activés pour changement désirable, 6) l’administrateur remplit le formulaire avec les différents informations nécessaires, 7) l’administrateur clique sur "Save", 8) le système génére la nouvelle liste des patients. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. Tableau 5.7: Description du sous cas d’utilisation « Supprimer patient » Résumé L’administrateur peut supprimer un patient. Pré conditions Administrateur authentifié et patient déjà existant. Post conditions Patient supprimé Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) l’administrateur demande la page de la liste des patients, 4) le système affiche ce dernier, 5) l’administrateur consulte la liste des patients , 77
Chapitre 5. Réalisation du Sprint 3 6) l’administrateur peut supprimer un patient en cliquant sur le bouton "supprimer", 7) le système affiche un message pour confirmer la suppression et l’administrateur clique sur «ok», 8) l’administrateur retourne à l’affichage de la nouvelle liste des patients. Scénario d’exception E1 : Si l’administrateur essaye de supprimer un compte de patient, il doit tout d’abord le supprimer de la liste des patients, sinon un message d’erreur s’affiche. 5.2.3 Prototype des IHM Après avoir étudié les tâches du sprint 3, nous avons établi quelques maquettes afin de les valider avec le product owner. La figure 5.3 présenté ci-dessous indique le prototype gestion des patients. Figure 5.3: Prototype "Gestion des patients" 5.3 Conception Nous allons maintenant représenter les interactions pour les cas d’utilisation « Contrôler Médecin» et « Suivre Patient» sous forme de diagrammes de séquence. Diagramme de séquence " Ajouter un médecin" La figure 5.4 illustre le diagramme de séquence pour ajouter un médecin. 78
Chapitre 5. Réalisation du Sprint 3 Figure 5.4: Diagramme de séquence " Ajouter un médecin" 79
Chapitre 5. Réalisation du Sprint 3 Diagramme de séquence " Modifier un médecin" La figure 5.5 illustre le diagramme de séquence pour modifier un médecin. Figure 5.5: Diagramme de séquence " Modifier un médecin" 80
Chapitre 5. Réalisation du Sprint 3 Diagramme de séquence " Supprimer un médecin" La figure 5.6 illustre le diagramme de séquence pour supprimer un médecin. Figure 5.6: Diagramme de séquence " Supprimer un médecin" 81
Chapitre 5. Réalisation du Sprint 3 5.4 Codage La figure 5.7 représente l’interface de gestion des médecins qui permet d’afficher toutes les informations nécessaires tout en incluant l’Id du service, le département et les informations personnelles. Figure 5.7: Interface "Liste des médecins" L’administrateur peut par la suite affiche le profil d’un médecin qui désire d’afficher ses détails. La figure 5.8 indique Le profil d’un médecin. Figure 5.8: Interface "Profil d’un médecin" Par ailleurs, l’administrateur peut ajouter, modifier ou supprimer un médecin en cas de besoin. La figure 5.9 représente l’interface d’ajout d’un nouveau médecin. 82
Chapitre 5. Réalisation du Sprint 3 Figure 5.9: Interface "Ajouter un nouveau médecin" La figure 5.10 représente l’interface de modification d’un médecin choisi. Figure 5.10: Interface "Modifier un médecin" L’administrateur peut par la suite gérer les patients adhérant à l’application. Pour Visualiser la liste des patients, il accède à l’accueil et clique sur patient dans le menu de navigation. La figure 83
Chapitre 5. Réalisation du Sprint 3 5.11 représente l’interface de la liste des patients. Figure 5.11: Interface "Liste des patients" Pour ajouter un nouveau patient, l’administrateur clique sur "New patient". La figure 5.12 représente l’interface d’ajout d’un patient. Figure 5.12: Interface "Ajouter un patient" Lorsque l’administrateur veut modifier un patient, il clique sur l’icône "Edit". Une fenêtre pop-up se déclenche pour appliquer les modifications au patient choisi.En autre, il peut soit modifier son profil ou son compte. La figure 5.13 représente l’interface de modification d’un patient. 84
Chapitre 5. Réalisation du Sprint 3 Figure 5.13: Interface "Modifier un patient" D’autre part, un médecin peut juste visualiser les détails des patients et ne peut apporter aucune modification. La figure 5.14 représente l’interface de modification d’un patient. Figure 5.14: Interface "Liste des patients personnalisée" La consultation est une étape postérieure qui se provoque suite à la prise de rendez-vous. La figure 5.15 représente l’interface de création de consultation qui nous donne une idée sur l’état de patient. 85
Chapitre 5. Réalisation du Sprint 3 Figure 5.15: Interface "Créer consultation pour patient" La figure 5.16 représente l’interface de gestion des départements. Figure 5.16: Interface "Gérer les départements" 5.5 Test Les tests fonctionnels [29] vérifient que le produit assure les fonctionnalités spécifiées dans les spécifications fonctionnelles. Avant la fin de chaque Sprint nous testons les fonctionnalités du module. Pour ce fait, nous avons élaboré dans le tableau 5.8 un ensemble de cas de scénario de tests 86
Chapitre 5. Réalisation du Sprint 3 fonctionnels relatif au sprint 3. Tableau 5.8: Tests fonctionnels du sprint 3 Cas de test Démarches Comportements attendus Résultat Test d’ajout de médecin • Demander la page des médecins, • la page de gestion des médecins s’affiche, • Cliquer sur l’icône "Add Provider", • l’administrateur remplit le formulaire convenablement, • Cliquer sur "Save". • Affichage de la page de médecins, • Génération de la page pop-up d’ajout de médecin, • Ajout du médecin. Conforme Test de modification médecin • Demander la page de gestion des médecins, • Cliquer sur "Edit Provider", • Remplir le formulaire convenablement, • Cliquer sur "Save". • Affichage de la page de gestion des médecins, • Affichage de la page de modification des médecins, • Modification du médecin. Conforme 87
Chapitre 5. Réalisation du Sprint 3 Test de Suppression médecin • Demandre la page de gestion des médecins, • Cliquer sur "Delete Provider", • l’administrateur clique sur "OK". • Affichage de la page de gestion des médecins, • Apparition d’une fenêtre (Pop-Up), • Suppression du médecin. Conforme Après avoir vérifié le bon fonctionnement du code et des fonctionnalités, le troisième livrable a été testé par le Product Owner. Ainsi, il nous a transmis la liste des améliorations, des fonctionnalités à ajouter et des bugs à signaler. 5.6 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • CRUD médecins • CRUD patients • CRUD départements Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Ajouter un peu plus de détails sur les patients. Conclusion Au cours de ce dernier chapitre, nous avons présenté le dernier sprint. Pour ce faire, nous avons passé par la spécification, la conception, le codage, les tests et les rétrospectives. 88
Conclusion générale et Perspectives Dans ce rapport, nous avons abordé le domaine de l’e-santé afin de mieux comprendre l’attente d’un utilisateur d’une telle application afin de produire une application SPA de qualité. Cette étude nous a permis de constater la diversité des services pouvant être mis à disposition d’où complexité de se positionner par rapport à cet univers qu’on peut qualifier de novice en Tunisie. La réalisation de ce projet nous a permis de se confronter à plusieurs contraintes à la fois : contraintes de temps , contraintes de qualité et contraintes de technologie, En outre, il nous a permis de nous procurer de nouvelles connaissances aussi bien dans le domaine informatique que sur le plan humain, ce projet nous a permis donc de découvrir et d’adopter des nouvelles technologies tels que Angular2, .Net Core , Web API, C#, Bootstrap, et JavaScript, il nous a permis également de consolider notre expertise en développement. De ce fait, le présent travail se résume dans le développement d’une application Web intitulée « Lazarus » dans un contexte englobant le planning des rendez-vous et une meilleure circulation des informations en terme de relation entre les patients et les médecins. Ainsi, au cours de ce travail nous avons appliqué les différents enchaînements du cycle de vie du projet en se basant sur le paradigme MVC comme schéma de programmation qui propose de séparer l’application en trois parties (Modèle, Vue, Contrôleur). Par ailleurs, ce stage nous a donné la chance de suivre une méthodologie de travail bien étudiée et de manipuler des techniques innovantes et évolutives. Aussi, il nous a permis de tester et d’appliquer nos connaissances théoriques et pratiques acquises au sein de l’Institut Supérieur d’Informatique d’El Manar (ISI) et de les améliorer. De même, il nous a offert l’opportunité de s’initier à la vie professionnelle dans un milieu réel et d’avoir un début d’expérience significatif. Certaines perspectives se dessinent à l’horizon pour l’amélioration de ce travail par l’intégration d’autres fonctionnalités telles que la localisation des cabinets médicaux, la création d’une version mobile Ionic de notre application Web et création d’un module Business Intelligence pour l’aide à la décision. 89
Bibliographie [1] Cynapsys. Présentation de cynapsys it hotspot. Cynapsys IT. Janvier. 2012. [En ligne] Disponible sur : http ://www.cynapsys.de/ [Accès le 01-Avril-2017]. [2] Collab. Image scrum. Collab. Janvier. 2014. [En ligne] Disponible sur : http ://scrummethodology.com/ [Accès le 5-Avril-2017]. [3] A. Mittal. Angular2 tutorial. Code project. [En ligne] Disponible sur : https ://www.codeproject.com/Articles/1186099 [Accès le 09-Avril-2017]. [4] J. Trivedi. Basic architecture of angular 2 applications. C Corner. [En ligne] Disponible sur : http ://www.c-sharpcorner.com/article/basic-architecture-of-angular-2-applications/ [Accès le 25-Mai-2017]. [5] M. Sabnis. Utilisation d’ef core dans asp.net core web api pour effectuer des opérations crud. DotNetCurry. 2017. [En ligne] Disponible sur : http ://www.dotnetcurry.com/entityframework/1348/ef-core-web-api-crud-operations [Accès le 27-Mars-2017]. [6] S. Chauhan. Asp.net core with angular4 development. DotnetTricks. [En ligne] Disponible sur : http ://www.dotnettricks.com/training/asp-net-core-development [Accès le 1-Juin-2017]. [7] tunisiait. Présentation de cynapsys. tunisiait. Janvier. 2017. [En ligne] Disponible sur : http ://www.tunisiait.com [Accès le 01-Avril-2017]. [8] ADO34. La gestion des projets. ACCESS-DEV. Février. 2013. [En ligne] Disponible sur : http ://www.access-dev.com/ [Accès le 1-Avril-2017]. [9] F. Lothen. Méthode agile. Agiliste. Janvier. 2014. [En ligne] Disponible sur : http ://www.agiliste.fr/ches/introductionmethodes-agiles [Accès le 02-Avril-2017]. [10] Dynamique-mag. Scrum. DM. Janvier. 2012. [En ligne] Disponible sur : http ://www.dynamique-mag.com [Accès le 4-Avril-2017]. [11] DynamiqueMag. Documentation scrum. DM. Janvier. 2012. [En ligne] Disponible sur : http ://www.dynamique-mag.com [Accès le 4-Avril-2017]. 90
Bibliographie [12] innovaxion. Innovaxion planing poker. innovaxion. Janvier. 2012. [En ligne] Disponible sur : www.innovaxion.net [Accès le 5-Avril-2017]. [13] B. Wagner. Introduction au langage c et au .net framework. Communauté Microsoft. [En ligne] Disponible sur : https ://docs.microsoft.com [Accès le 3-Juin-2017]. [14] A. Redmond. Typescript javascript qui varie. Communauté TypeScipt. [En ligne] Disponible sur : https ://www.typescriptlang.org/ [Accès le 3-Juin-2017]. [15] A. SCHMITTER. C : Linq. SupInfo. [En ligne] Disponible sur : http ://www.supinfo.com [Accès le 3-Juin-2017]. [16] H. Romaric. Les nouveautés de visual studio 2017. Club des développeurs. 2017. [En ligne] Disponible sur : : http ://rdonfack.developpez.com/tutoriels/dotnet/les-nouveautes-de-visual-studio-2017/ [Accès le 14-Mars-2017]. [17] LoveToKnow. Yourdictionary. LoveToKnow. 2012. [En ligne] Disponible sur : : http ://www.yourdictionary.com/tfs [Accès le 22-Avril-2017]. [18] D. Git. Svn. Club des développeurs. 2017. [En ligne] Disponible sur : https ://git-scm.com/ [Accès le 14-Mars-2017]. [19] Postman. Developing apis is hard. postman makes it easy. Postdot Technologies. [En ligne] Disponible sur : https ://www.getpostman.com/ [Accès le 27-Mai-2017]. [20] C. Microsoft. .net core et open-source. Microsoft. 2017. [En ligne] Disponible sur : https ://msdn.microsoft.com/fr-fr/library/dn878908(v=vs.110).aspx [Accès le 29-Avril-2017]. [21] R. Miller. Entity framework core. Microsoft. 2017. [En ligne] Disponible sur : https ://docs.microsoft.com/en-us/ef/core/index [Accès le 29-Avril-2017]. [22] C. TutorialPoints. Angular2 tutorial. Angular2. [En ligne] Disponible sur : https ://www.tutorialspoint.com/angular2/index.htm [Accès le 27-Avril-2017]. [23] C. UML. Qu’est-ce que uml. UML. 2010. [En ligne] Disponible sur : http ://uml.free.fr [Accès le 6-Avril-2017]. [24] C. Visual. Présentation de visual paradigm. Visual Paradigm. 2012. [En ligne] Disponible sur : http ://lgl.isnetne.ch/Visual-Paradigm-8 [Accès le 22-Avril-2017]. 91
Bibliographie [25] C. atlassian. Présentation backlog du produit. UML. 2015. [En ligne] Disponible sur : https ://fr.atlassian.com/agile/backlogs [Accès le 6-Avril-2017]. [26] S. Chauhan. Implementing repository and unit of work patterns with asp.net mvc. Dotnet Tricks. 2017. [En ligne] Disponible sur : http ://www.dotnettricks.com [Accès le 25-Mars-2017]. [27] S. S. Shekhawat. Crud operations using the generic repository pattern and unit of work in mvc. C Sharp. 2017. [En ligne] Disponible sur : http ://www.c-sharpcorner.com/ [Accès le 25-Mars-2017]. [28] C. Refes. Les web service. Openclassroom. 2017. [En ligne] Disponible sur : https ://openclassrooms.com/courses/les-services-web [Accès le 26-Mars-2017]. [29] M. A. Mostefai. Test fonctionnel. ESI. [En ligne] Disponible sur : http ://fr.slideshare.net/mostefaiamine/gnie-logiciel-lestests [Accès le 24-Mai-2017]. 92
Annexes La figure 5.14 présente l’interface de préférences. Figure 5.14 : Interface de préferences La figure 5.15 présente l’interface de translation de l’application. Figure 5.15 : Interface de internationalisation 93
Annexes La figure 5.16 présente l’interface About de l’application. Figure 5.16 : Interface "A propos" La figure 5.17 présente l’interface de choix de couleur pour l’application. Figure 5.17 : Interface "Color Application" 94
SPA . Entity Framework Core .Net Core . Scrum . Scrum SPA Entity Framework Core .NET CORE : Résumé Ce rapport a été réalisé dans le cadre du projet de fin d’études pour l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques spécialisés en Génie Logiciel et Systèmes d’Information. L’objectif de notre projet est de réaliser une application Web SPA dédiée principalement aux patients et médecins dont le but est d’élaborer une meilleure communication surtout pour la gestion des rendez-vous. Cette application est développée en utilisant le Framework .NET CORE pour la partie Web et Entity Framework CORE pour la partie base de données. Enfin, nous avons adopté la méthode de développement Scrum pour le développer. Mots clés : .NET CORE, Entity Framework Core, Web, SPA, Scrum Abstract This report was produced as part of the graduation project in order to obtain the National Engineering Diploma in Applied Science and Technology specializing in Software Engineering and Information Systems. Our project aim to achieve a Single Page Application SPA dedicated to the patients and doctors in order to facilitate their communication especially for appointements management. This application is developed using the .NET CORE framework for the Web part and Entity Framework Core for DataBase part. Finally, we have adopted the Scrum development methodology to develop our project. Keywords : .NET CORE, Entity Framework Core, Web, SPA, Scrum Cynapsys Tunisie. isi@isim.rnu.tn : 71 706 698 : 71 706 164 : 2080 2 2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn

Contenu connexe

PDF
Rapport_pfe_licence_ISAMM
parEya TAYARI
 
PDF
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
parMohamed Aziz Chetoui
 
PDF
iRecruite
parDonia Hammami
 
DOCX
PFE::Conception et développement du Back Office d'une application mobile de g...
parRami Raddaoui
 
DOCX
application mobile de gestion de panne de BTS
paranis chamkhi
 
PDF
Mémoire PEF application client server gestion des projet collaborative
parMessaoud Hatri
 
PDF
Rapport PFE réalisation d’un Framework Kinect
parAmine MEGDICHE
 
PDF
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
paryounes elmorabit
 
Rapport_pfe_licence_ISAMM
parEya TAYARI
 
ERP médical pour la TRANSTU : module de gestion pharmaceutiques
parMohamed Aziz Chetoui
 
iRecruite
parDonia Hammami
 
PFE::Conception et développement du Back Office d'une application mobile de g...
parRami Raddaoui
 
application mobile de gestion de panne de BTS
paranis chamkhi
 
Mémoire PEF application client server gestion des projet collaborative
parMessaoud Hatri
 
Rapport PFE réalisation d’un Framework Kinect
parAmine MEGDICHE
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
paryounes elmorabit
 

Tendances

PDF
Rapport PFE: Gestion de Parc Informatique
parEric Maxime
 
PPTX
Presentation pfe Système de gestion des rendez-vous médicaux
parFehmi Arbi
 
PDF
Conception et Réalisation Application Web Laravel PFE BTS
parFaissoilMkavavo
 
PDF
Conception et développement d'une marketplace basée sur l'architecture micros...
parAdem Amen Allah Thabti
 
PDF
Rapport du projet fin d'etudes
parTahani RIAHI
 
PDF
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
PDF
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
parRamzi Noumairi
 
PDF
Rapport PFE Ilef Ben Slima
parIlef Ben Slima
 
PDF
Rapport Projet de fin d'etude sur le parc informatique
parHicham Ben
 
PPTX
Présentation PFE: Système de gestion des réclamations et interventions clients
parMohamed Ayoub OUERTATANI
 
PDF
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
parmouafekmazia
 
PDF
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
PDF
Conception et développement d'une application Android pour TUNISAIR
parSkander Driss
 
PDF
RAPPORT DE PROJET DE FIN D’ETUDES
parTombariAhmed
 
PDF
Conception et réalisation d'une application de gestion intégrée au sein de la...
parAddi Ait-Mlouk
 
PDF
Mémoire fin d'étude gestion des interventions
parMohamed Arar
 
PDF
1601896849 rapport fluttercopie
parRamiJOUDI2
 
PDF
Rapport du Projet de Fin d'année Génie informatique
parayoub daoudi
 
PDF
RapportPFE_IngenieurInformatique_ESPRIT
parLina Meddeb
 
PDF
Rapport pfe
parAhmed rebai
 
Rapport PFE: Gestion de Parc Informatique
parEric Maxime
 
Presentation pfe Système de gestion des rendez-vous médicaux
parFehmi Arbi
 
Conception et Réalisation Application Web Laravel PFE BTS
parFaissoilMkavavo
 
Conception et développement d'une marketplace basée sur l'architecture micros...
parAdem Amen Allah Thabti
 
Rapport du projet fin d'etudes
parTahani RIAHI
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
parSalma Gouia
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
parRamzi Noumairi
 
Rapport PFE Ilef Ben Slima
parIlef Ben Slima
 
Rapport Projet de fin d'etude sur le parc informatique
parHicham Ben
 
Présentation PFE: Système de gestion des réclamations et interventions clients
parMohamed Ayoub OUERTATANI
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
parmouafekmazia
 
Rapport pfe talan_2018_donia_hammami
parDonia Hammami
 
Conception et développement d'une application Android pour TUNISAIR
parSkander Driss
 
RAPPORT DE PROJET DE FIN D’ETUDES
parTombariAhmed
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
parAddi Ait-Mlouk
 
Mémoire fin d'étude gestion des interventions
parMohamed Arar
 
1601896849 rapport fluttercopie
parRamiJOUDI2
 
Rapport du Projet de Fin d'année Génie informatique
parayoub daoudi
 
RapportPFE_IngenieurInformatique_ESPRIT
parLina Meddeb
 
Rapport pfe
parAhmed rebai
 

Similaire à Outpatient Department System (OPD)

PDF
rapport pfe: Solution de réservation une table dans un restaurants
parbarbourafedia1
 
PDF
Rapport pfe isi_Big data Analytique
parYosra ADDALI
 
PDF
Rapport_PFE_Seifeddine_ABIDI_ESPRIT_24/25
parSeifeddine ABIDI
 
PDF
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
PDF
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
PDF
pfe_rapport_poste_licence_LFIG.pdf
parnesrine haloui
 
PDF
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
PDF
Masters, Rapport de projet de fin d'étude de Conception et développement d’un...
parmouafekmazia
 
PDF
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
PDF
rapport de projet de fin d'étude_PFE
parDonia Hammami
 
PDF
Gestion des actifs applicatifs
parSafaAballagh
 
PDF
Rapport de projet de fin d"études
parMohamed Boubaya
 
PDF
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
parMohammed JAITI
 
PDF
Fourth year internship report
parSlimane Akaliâ , سليمان أقليع
 
PDF
Rapport de stage - gestion commerciale @REC MEDIA
parREDOUANIAbdessamad
 
PPTX
rapport-pfa-2020-s1-gshshsgbfhsdgsbhshbss.pptx
parHelmiBabay
 
PDF
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
parfehmi arbi
 
PDF
Conception et developpement d'un site web pour la suggestion et notification ...
parMohamed Boubaya
 
PDF
réaliser une plateforme d’automatisation et de génération des rapports de test
parahmed oumezzine
 
PDF
Conception et réalisation d’un Système d’information des étudiants du départe...
parIlyas CHAOUA
 
rapport pfe: Solution de réservation une table dans un restaurants
parbarbourafedia1
 
Rapport pfe isi_Big data Analytique
parYosra ADDALI
 
Rapport_PFE_Seifeddine_ABIDI_ESPRIT_24/25
parSeifeddine ABIDI
 
Conception et développement d'une application de gestion de production et de ...
parMohamed Aziz Chetoui
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
parYasmine Lachheb
 
pfe_rapport_poste_licence_LFIG.pdf
parnesrine haloui
 
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
Masters, Rapport de projet de fin d'étude de Conception et développement d’un...
parmouafekmazia
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
rapport de projet de fin d'étude_PFE
parDonia Hammami
 
Gestion des actifs applicatifs
parSafaAballagh
 
Rapport de projet de fin d"études
parMohamed Boubaya
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
parMohammed JAITI
 
Fourth year internship report
parSlimane Akaliâ , سليمان أقليع
 
Rapport de stage - gestion commerciale @REC MEDIA
parREDOUANIAbdessamad
 
rapport-pfa-2020-s1-gshshsgbfhsdgsbhshbss.pptx
parHelmiBabay
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
parfehmi arbi
 
Conception et developpement d'un site web pour la suggestion et notification ...
parMohamed Boubaya
 
réaliser une plateforme d’automatisation et de génération des rapports de test
parahmed oumezzine
 
Conception et réalisation d’un Système d’information des étudiants du départe...
parIlyas CHAOUA
 

Dernier

PDF
Intelligence artificielle Générative et Robots Humanoïdes - 1ère partie
parJean-Antoine Moreau
 
PDF
Caprinov 2025 - S'adapter aux défis climatiques pour les AOP caprines
parInstitut de l'Elevage - Idele
 
PPTX
Mémoire de Master professionnel (IFTS) TCHALIM.pptx
parTCHALIM
 
PPTX
Presentation des certifications environnementales
parissebox
 
PDF
Bien débuter avec Spring AI - Bases, chatbot et MCP
parFlorian Beaufumé
 
PPTX
Présentation Les 7 principes de la démarche qualité ISO 9001
paryoussefaitoune
 
PPTX
cours raspberry [Enregistrement automatique].pptx
parTCHALIM
 
Intelligence artificielle Générative et Robots Humanoïdes - 1ère partie
parJean-Antoine Moreau
 
Caprinov 2025 - S'adapter aux défis climatiques pour les AOP caprines
parInstitut de l'Elevage - Idele
 
Mémoire de Master professionnel (IFTS) TCHALIM.pptx
parTCHALIM
 
Presentation des certifications environnementales
parissebox
 
Bien débuter avec Spring AI - Bases, chatbot et MCP
parFlorian Beaufumé
 
Présentation Les 7 principes de la démarche qualité ISO 9001
paryoussefaitoune
 
cours raspberry [Enregistrement automatique].pptx
parTCHALIM
 

Outpatient Department System (OPD)

  • 1.
    République Tunisienne Ministère del’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
  • 3.
    République Tunisienne Ministère del’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
  • 4.
    J’autorise l’étudiant àfaire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant professionnel, Hamed KOLSI Le J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant académique, Sahbi BAHROUN Le
  • 5.
    Dédicaces À mes trèschers parents Raoudha et Radhouane En témoignage de mon affection, de mon profond respect et de ma reconnaissance pour tous les efforts et les sacrifices qu’ils ont consentis pour ma réussite et mon bonheur. Chers parents aucune dédicace au monde ne suffira jamais à vous témoigner toute ma gratitude et mon amour. Que Dieu vous prête bonne santé et longue vie. À mes sœurs Bochra et Amira et mon frère Mohamed avec qui j’ai tous partagé Une vie pleine de succès et de bonheur. Pour l’amour dont vous m’avez toujours comblé, ainsi que pour le bien être que vous m’avez toujours assuré. Veuillez trouver ici, l’expression de mon affection et attachement. Que Dieu vous garde et vous réserve. À ceux qui m’ont soutenu, encouragé, qui ont apprécié mon effort et créé le milieu favorable, l’ambiance joyeuse et l’atmosphère joviale pour me procurer ce travail. À toutes ces personnes adorables, je dédie ce modeste travail avec mes vifs remerciements et les expressions respectueuses de ma profonde gratitude. Zohra BEN AHMED i
  • 6.
    Remerciements C’est un plaisiret un moment très agréable de rendre hommage et de formuler des remerciements aux personnes qui, d’une manière ou d’une autre ont apporté leur soutien et contribué à finaliser ce travail. Mes remerciements s’adressent d’abord à tout le personnel de Cynapsys Tunisie . Je leur exprime ma reconnaissance et ma haute considération pour leur bienveillance, leur accueil et leurs conseils précieux. Je remercie spécialement Monsieur Hamed KOLSI pour m’avoir accordé leur confiance dans ce projet. Ils ont tous laissé leurs empreintes dans ce présent rapport à travers leurs conseils et recommandations. J’adresse aussi mes profonds remerciements à Monsieur Sahbi BAHROUN qui a accepté de diriger, de lire et porter des correctifs à ce travail sans oublier ses conseils et suggestions éclairés. Mes vifs remerciements s’adressent aux membres de jury qui ont accepté d’évaluer mon travail. J’associe à ces remerciements tous les enseignants de l’Institut Supérieur d’Informatique d’El Manar (ISI) qui ont contribué à ma formation. Je suis reconnaissante à toute personne qui a contribué de près ou de loin à la réalisation de ce projet. Qu’ils trouvent ici l’expression de ma haute gratitude. ii
  • 7.
    Table des matières Introductiongénérale 1 1 Présentation générale et étude de l’existant 2 1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Cynapsys IT Hotspot en bref . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Directions de Cynapsys Tunis . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6.1 Méthode Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6.2 Méthode adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.1 Langage de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.7.2 Plateforme de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.3 Framework de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.8 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.9 Conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Sprint 0 :Analyse et spécification des besoins 16 2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 iii
  • 8.
    2.3 Diagrammes descas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.1 Les rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5 Architecture Adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.6 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.1 Outils matériels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3 Réalisation du Sprint 1 30 3.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.1 Diagramme de cas d’utilisation raffiné «S’authentfier» . . . . . . . . . . . . . 31 3.2.2 Diagramme de cas d’utilisation raffiné «Gestion des utilisateurs» . . . . . . . 33 3.2.3 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.5 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4 Réalisation du Sprint 2 51 4.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Réalisation du module de gestion des rendez-vous . . . . . . . . . . . . . . . . . . . . 52 4.2.1 Mise en oeuvre des patrons de conception Repository et unitofwork dans ASP.NET Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.2 Mise en oeuvre des services web . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3.1 Diagramme de cas d’utilisation raffiné «Suivi des rendez-vous» . . . . . . . . 57 4.3.2 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 iv
  • 9.
    4.4 Conception .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5 Réalisation du Sprint 3 72 5.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1 Diagramme de cas d’utilisation raffiné «Contrôler médecin» . . . . . . . . . . 73 5.2.2 Diagramme de cas d’utilisation raffiné «Suivre patient» . . . . . . . . . . . . 76 5.2.3 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Conclusion générale 89 Bibliographie 90 Annexes 93 v
  • 10.
    Table des figures 1.1Présentation de Cynapsys IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Pôles de Cynapsys[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Cycle de vie SCRUM [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 La logique Modèle-Vue-Contrôleur Web API . . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Modèle MVC [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4 Architecture Angular2 [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 Architecture WebAPI avec EFCore [5] . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 Architecture globale de l’application [6] . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.7 Diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1 Raffinement de cas d’utilisation «S’authentfier» . . . . . . . . . . . . . . . . . . . . . 32 3.2 Raffinement de cas d’utilisation «Gestion des utilisateurs» . . . . . . . . . . . . . . . 33 3.3 Prototype "Liste des rôles" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4 Prototype "Liste des utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.6 Diagramme de Modèle physique de données . . . . . . . . . . . . . . . . . . . . . . . 39 3.7 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . . . . . . . . . . . . 40 3.8 Diagramme de séquence «Ajouter Utilisateur» . . . . . . . . . . . . . . . . . . . . . . 41 3.9 Diagramme de séquence «Modifier Utilisateur» . . . . . . . . . . . . . . . . . . . . . 42 3.10 Diagramme de séquence «Supprimer Utilisateur» . . . . . . . . . . . . . . . . . . . . 43 3.11 Diagramme d’activité "Gestion des profils et des droits d’accés " . . . . . . . . . . . 44 3.12 Interface "S’authentifier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.13 Interface "Consulter la liste des utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . 45 3.14 Interface "Ajouter un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.15 Interface "Modifier un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.16 Interface "Supprimer un utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.17 Interface "Ajouter un rôle " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 vi
  • 11.
    Table des figures 3.18Interface "Modifier un rôle " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.19 Interface "Afficher profile " . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.1 Diagramme "Generic Repository Pattern and Unit of Work workflow" . . . . . . . . 53 4.2 Extrait de code de la classe IRepository . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3 Diagramme Repository pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4 Extrait de code de la classe IUnitofwork . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5 Raffinement de cas d’utilisation «Suivi des rendez-vous» . . . . . . . . . . . . . . . . 58 4.6 Prototype "Suivi par calendrier" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.7 Prototype "Prise de rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.8 Diagramme de séquence «Réserver rendez-vous » . . . . . . . . . . . . . . . . . . . . 62 4.9 Diagramme de séquence «Annuler rendez-vous» . . . . . . . . . . . . . . . . . . . . . 63 4.10 Diagramme de séquence «Générer disponibilité» . . . . . . . . . . . . . . . . . . . . . 64 4.11 Interface "Réserver un rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.12 Interface "Confirmation de réservation de rendez-vous" . . . . . . . . . . . . . . . . . 66 4.13 Interface "Annuler rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.14 Interface "Liste des Rendez-Vous" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.15 Interface "Historique des rendez-vous" . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.16 Interface "Notification de confirmation de rendez-vous par mail" . . . . . . . . . . . 68 4.17 Interface "Liste des plannings pour un médecin" . . . . . . . . . . . . . . . . . . . . 68 4.18 Interface "Génération de temps disponible" . . . . . . . . . . . . . . . . . . . . . . . 69 4.19 Interface "La liste de temps disponible" . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.20 Interface "Notification par message" . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Raffinement de cas d’utilisation «Contrôler médecin» . . . . . . . . . . . . . . . . . 74 5.2 Raffinement de cas d’utilisation «Suivre patient» . . . . . . . . . . . . . . . . . . . . 76 5.3 Prototype "Gestion des patients" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Diagramme de séquence " Ajouter un médecin" . . . . . . . . . . . . . . . . . . . . . 79 5.5 Diagramme de séquence " Modifier un médecin" . . . . . . . . . . . . . . . . . . . . 80 5.6 Diagramme de séquence " Supprimer un médecin" . . . . . . . . . . . . . . . . . . . 81 5.7 Interface "Liste des médecins" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.8 Interface "Profil d’un médecin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 vii
  • 12.
    5.9 Interface "Ajouterun nouveau médecin" . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.10 Interface "Modifier un médecin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.11 Interface "Liste des patients" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.12 Interface "Ajouter un patient" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.13 Interface "Modifier un patient" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.14 Interface "Liste des patients personnalisée" . . . . . . . . . . . . . . . . . . . . . . . 85 5.15 Interface "Créer consultation pour patient" . . . . . . . . . . . . . . . . . . . . . . . 86 5.16 Interface "Gérer les départements" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 viii
  • 13.
    Liste des tableaux 1.1Étude comparative entre les approches agiles . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Le Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Description du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . . . . . . 32 3.3 Description du sous cas d’utilisation « Ajouter utilisateur » . . . . . . . . . . . . . . 33 3.4 Description du sous cas d’utilisation « Modifier utilisateur » . . . . . . . . . . . . . . 34 3.5 Description du sous cas d’utilisation « Créer rôle » . . . . . . . . . . . . . . . . . . . 35 3.6 Tests fonctionnels du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Description du sous cas d’utilisation « Créer rendez-vous » . . . . . . . . . . . . . . . 59 4.3 Description du sous cas d’utilisation « Annuler rendez-vous » . . . . . . . . . . . . . 59 4.4 Description du sous cas d’utilisation « Gérer Calendrier » . . . . . . . . . . . . . . . 60 4.5 Description du sous cas d’utilisation « Générer disponibilité » . . . . . . . . . . . . . 60 4.6 Tests fonctionnels du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Description du sous cas d’utilisation « Ajouter médecin » . . . . . . . . . . . . . . . 74 5.3 Description du sous cas d’utilisation « Modifier médecin » . . . . . . . . . . . . . . . 75 5.4 Description du sous cas d’utilisation « Supprimer médecin » . . . . . . . . . . . . . . 75 5.5 Description du sous cas d’utilisation « Ajouter patient » . . . . . . . . . . . . . . . . 76 5.6 Description du sous cas d’utilisation « Modifier patient » . . . . . . . . . . . . . . . . 77 5.7 Description du sous cas d’utilisation « Supprimer patient » . . . . . . . . . . . . . . 77 5.8 Tests fonctionnels du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 ix
  • 14.
    Liste des abréviations —AG = Agile Modeling — API = Application Programming Interface — CRUD = Create Read Update Delete — DI = Dependancy Iinjection — EDI = Environnement de Développement Intégré — EF = Entity Framework — HTTP = HyperText Transfer Protocol — IHM = Interface Homme Machine — JSON = JavaScript Oobject Notation — MVC = Model View Control — PFE = Projet Fin d’Etude — RDV = Rendez Vous — REST = REpresentational State Transfer — RUP = Rational Unified Process — SPA = Single Page Application — TFS = Team Founsation Server — UML = Unified Modeling Language — URI = Uniform Resource Identifier — VS = Visual Studio — XP = eXtreme Programming x
  • 15.
    Introduction générale Laxdémarche médicaleest fondée sur l’observation du malade. La mémoire du médecin était autrefois suffisante pour enregistrer les données relatives aux patientsxet servir l’exercice médical. Les données médicalesxétaient rassemblées sous forme d’articles médicaux et administratives, avec la multiplication des effets de l’environnement, de nos jours la bonne tenue d’un dossier exige des moyens informatiques. L’automatisationxduxsystèmexd’informationxconsiste à structurerxet gérer un ensemble de données dont le but de lesxorganiser et d’avoir des résultats rapides. C’est dans ce cadre que s’inscrit notre projet de fin d’études qui a pour objectif la mise en place d’une application Web SPA intitulée « Lazarus » permettant essentiellement la réservation des rendez-vous afin d’augmenter la fiabilité, l’efficacité de l’effort humain et faciliter les tâches pénibles au sein des établissements médicaux Ce rapport présente l’ensemble des étapes suivies pour développer l’application. Il contient cinq chapitres organisés comme suit : Le premier chapitre intitulé « Présentation générale et étude de l’existant » est consacré à la présentation du contexte du projet, de l’organisme d’accueil avec la description du client pour lequel nous avons développé notre solution. Puis nous définirons le choix de la méthodologie de développement adoptée et nous finirons par présenter les outils utilisés ainsi que les différents environnements de développement. Le deuxième chapitre, « Sprint 0 : Analyse et spécification des besoins», s’articule autour de l’identification des acteurs et description des besoins fonctionnels et non fonctionnels. Puis, nous élaborons le Backlog du produit et nous terminons par la présentation des architectures physique et logique. Les chapitres 3, 4 et 5 décrivent respectivement la réalisation des Sprints 1, 2 et 3. Nous commençons par la spécification du sprint, ensuite nous présentons la phase conceptuelle qui sera matérialisée par l’élaboration du diagramme de classes ainsi que celle des diagrammes de séquence, puis nous présentons la phase d’implémentation par la description des interfaces de l’application et nous finissons par la réalisation des tests et des rétrospectives. 1
  • 16.
    Chapitre 1 Présentation généraleet étude de l’existant Plan 1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . 3 2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Présentation du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 Méthode de développement . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 12 8 Langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . 14 9 Conduite de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  • 17.
    Chapitre 1. Présentationgénérale et étude de l’existant Introduction Ce chapitre a pour objectif de situer notre projet dans son contexte général. Nous commencerons par une présentation de l’organisme d’accueil Cynapsys IT Hotspot et par la suite nous détaillerons la description du sujet, les objectifs ainsi qu’une étude théorique des technologies utilisées. Nous finirons par présenter les outils utilisés ainsi que les différents environnements de développement. 1.1 Présentation de l’organisme d’accueil 1.1.1 Cynapsys IT Hotspot en bref Cynapsys est une entreprise de services numériques, Fondée en 2004 en Tunisie. Elle est une entreprise de prestation de services en technologie de l’information. Elle est spécialisée dans le domaine de l’assistance et le développement spécifique de logiciel pour la télécommunication, les équipements, la finance et l’industrie [1]. Le groupe Cynapsys conçoit, développe et déploie des solutions applicatives métiers à travers ses locaux à Paris, Frankfurt, Alger, Tunis et bientôt Abidjan [7]. Ayant acquis une grande expérience dans la gestion des projets off-shore et Nearshore. Cynapsys est totalement exportatrice [1]. En effet, elle a développé une bonne connaissance du marché européen, principalement la France et l’Allemagne [7]. Elle s’appuie sur la puissance des normes internationales. Depuis 2007, des décisions de la direction ont été prises en vue de la certification de management de la qualité CMMI niveau 2 et 3 et ISO 9001- v 20084, afin d’optimiser ses processus internes et de donner à ses clients le meilleur rapport qualité/prix [1]. Elle est Microsoft et Oracle Partner. Ensuite elle est l’une des rares entreprises, membre de l’union internationale de Télécom. Le management de l’entreprise adossé à ces compétences a permis à Cynapsys d’avoir la confiance de plus de 60 clients de 14 pays à travers le monde [1]. Figure 1.1: Présentation de Cynapsys IT 3
  • 18.
    Chapitre 1. Présentationgénérale et étude de l’existant 1.1.2 Directions de Cynapsys Tunis Cynapsys est organisée en trois directions : une direction commerciale, une direction technique et une direction administrative. La direction technique comporté trois principaux pôles. La figure 1.2 illustre les pôles de Cynapsys IT Hotspot. Figure 1.2: Pôles de Cynapsys[1] Le pôle J2EE Open source a pour tâche la réalisation des applications sur demande en utilisant la technologie Java/J2EE. Et le pôle systèmes embarqués a pour rôle le développement des applications embarquées. Enfin le pôle Microsoft .Net, dans laquelle nous avons menu notre travail. Ce pôle est chargé du développement des applications en utilisant la technologie.NET. 1.2 Problématique Durant ce stage, il nous a été demandé de faire la conception, le développement et l’intégration d’une application Web qui permet essentiellement la prise de rende-vous et la gestion liés aux patients, médecins,consultations.. Le sujetxest certes intéressant carxl’application dont nous parlons peut avoir une vraie valeur ajoutéexdans la vie de chacun d’entre nous et ses perspectives d’évolution sont énormes surtout avec le progrès permanent de laxtechnologie. D’autre part pour la réalisation d’un tel projet, nous avons été confrontés à plusieurs difficultésxtechniques etxdécisionnelles. Mis à part le développement proprement dit de l’application, la première étape consistait à nous familiariser avec les nouvelles technologies .Net Core/Angular2, puis de choisir les outils les plus récents et envisageables à l’aboutissement du projet . Par la suite, nous avonsxentamé la modélisation et le 4
  • 19.
    Chapitre 1. Présentationgénérale et étude de l’existant développement de l’application, pour cela nousxavons opté pour la méthode agile Scrumxafin d’avoir une meilleure adaptation aux besoins évolutifs et aussi pourxgarantir le respect des délais. Ensuite, nous passons à la création de la base de données générée par la migration àxpartir des classes dexnotre application. Afin de garantirxle succès d’une telle application, il faut surtout insisterxsur la pertinence des informations et la rapiditéxdu service proposé c’est pourquoixnous avons pensé à mettre en place une application Web pour gérer les CRUD de notre base de données et ainsi faciliter sa mise à jour afin de garantirxla précision des informations fournies. Nous avons également penséxà garantir l’innovation, dans notre cas la prise de rendez-vous, qui éliminera l’obstacle des horaires à respecter car elle sera désormais possible à tout moment. Du coté médecin, il génère la disponibilité des créneaux et contrôle le planning des rendez-vous . 1.3 Présentation du Projet Dans cette partie, nous allons tout d’abord étudier l’application existante. Cette étude nous permettra de spécifier progressivement notre projet et de ressortir quelques critiques à partir desquelles nous présenterons notre solution proposée. 1.3.1 Étude de l’existant Le potentiel du marché de l’e-santé ne cesse de croître, en témoignent le nombre croissant d’outils et d’applications mis à disposition sur le marché. Ce potentiel se mesure notamment par la croissance et la multiplicité des applications métiers destinées aux professionnels de santé. Dans cette partie, nous allons essayer de faire une étude comparative des logiciels qui existent au marché, cette étude permettra de : — S’inspirer des expériences similaires à notre projet et qui ont été déjà réalisées. Cette inspiration sera concrétisée dans l’outil qu’on devra réaliser. — Localiser notre système par rapport aux systèmes déjà existants. — Préciser ce que notre application doit faire. Plusieurs applications Open Source ou propriétaire existent aujourd’hui dans le domaine des systèmes d’informations hospitaliers. On a choisi parmi ces logiciels : Doctolib Doctolib a pour objectif d’améliorer le quotidienxdes professionnels de santé et des patients. Pour lesxpatients, il permet de trouver un praticien près de chez soi et de prendrexrendez-vous en quelques 5
  • 20.
    Chapitre 1. Présentationgénérale et étude de l’existant clics mais on relève la difficulté de prise de rendez-vous en cas d’urgence si le particien choisi n’est pas disponible et aussi le manque d’internationalisation de l’application. med.tn med.tn estxune plateformexinnovante qui permet de trouverxrapidement un médecin ouxun dentiste proche et de prendre rendez-vousxen ligne gratuitement et en un clic mais on note le manque d’accès aux informations des patients par les médecins et aussi le grand nombre d’autorisation d’accès que l’application demande qui s’avère très gênant pour l’utilisateur. 1.3.2 Critique de l’existant La gestion de chaque établissement médical peut avoir quelques difficultés. Celles-ci peuvent se résumer dans : • Desxproblèmesxde gestionxdesxrendez-vous avec les patients. • La répétitionxdes informations relatives aux patients. • Le manque de confidentialité de l’information. 1.4 Objectifs Notre projet a pour objectif d’améliorer le fonctionnement de tous établissements de type médical, en intégrant les données médicales et administratives afin d’y remédier à tous ces problèmes, on peut assigner à notre étude les objectifs suivants : • Diminuer le coût de la fonction secrétariat des cabinets. • Faciliter la recherche et l’accès aux informations. • Permettre la prise de rendez-vous autonome (self-service). • Permettre le gain de temps. • Augmenter le chiffre d’affaire des cabinets. 1.5 Solution proposée Vu les besoins préliminaires, nous proposons une approchexde solution qui consiste à concevoir et à développer une application qui facilitera les insuffisances et les défaillances énumérées précédemment. On propose alors de concevoir une nouvelle application "Single page application" permettant l’organisation et l’automatisation des tâches qui ne peuvent être exercées sans l’appui 6
  • 21.
    Chapitre 1. Présentationgénérale et étude de l’existant d’un réseau de communication pour diffuser les informations. Cette application permettra en outre d’assurer une meilleure communication et cohérence de l’information, optimiser le temps d’accès aux différentes données, éviter les tâches pénibles et ennuyeuses et permettra également aux patients un meilleur suivi de leurs rendez-vous dans un service médical de même pour les praticiens concernés. Ce type d’application métier s’avère très utile non seulement afin de subvenir aux besoins des patients mais il peut aussi représenter un réel avantage pour les médecins. Il s’agit de rapprocher le médecin de ses patients et de le rendre plus disponible et surtout accessible en cas de besoin. 1.6 Méthode de développement Selon des estimations, plus que 80 % des projets [8] qui utilisent des méthodologies traditionnelles connaissent des retards et des dépassements budgétaires parce que ces méthodologies visent à prédire la façon dont les procédures devraient se passer selon un planning préétabli. Notre projet suit le principe de développement itératif basé sur l’écoute du client, c’est pour cette raison que notre choix s’est orienté vers les méthodes agiles de développement et de gestion de projet. 1.6.1 Méthode Agile Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling, noté AG) [9] visent à réduire le cycle de vie du logiciel et par conséquent accélérer sa réalisation en développant une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une écoute client et des tests tout au long du cycle de développement. L’origine des méthodes agiles est liée à l’instabilité de l’environnement technologique et au fait que le client est souvent dans l’incapacité de définir ses besoins de manière exhaustive dès le début du projet.Le terme «agile» fait ainsi référence à la capacité d’adaptation aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile dont la traduction est la suivante : • individus et interactions plutôt que processus et outils, • développement logiciel plutôt que documentation exhaustive, • collaboration avec le client plutôt que négociation contractuelle, • ouverture au changement plutôt que suivi d’un plan rigide. Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient très vite une première mise en production de son logiciel. Ainsi, il est possible d’associer les utilisateurs dès le 7
  • 22.
    Chapitre 1. Présentationgénérale et étude de l’existant début du projet. Le tableau 1.1 illustre une étude comparative de différentes méthodologies agiles. Tableau 1.1: Étude comparative entre les approches agiles Description Points forts Points faibles Scrum • Hiérarchisation des membres de l’équipe. • Développement progressif. • Contrôle quotidien de travail. • Développement et test pour des courtes itérations. • Simplicité de processus. • Augmentation de la productivité. • Responsabilité collective de l’équipe. • Efficacité pour les projets de petite taille, car il ne fonctionne bien qu’avec une petite équipe. • Énorme effet inverse sur le développement du projet Si l’un des membres de l’équipe quitte, RUP • Promu par Rational. • Le RUP est une méthodologie et à la fois un outil prêt à l’emploi (documents types partagés dans un référentiel Web). • Il est itératif. • Il spécifie le dialogue entre les différents intervenants du projet : les plannings, les prototypes, les livrables... • Il est coûteux à personnaliser. 8
  • 23.
    Chapitre 1. Présentationgénérale et étude de l’existant XP • Il est un ensemble de "Bests Practices" de Développement (transfert de compétences, travail en équipes... • Il s’adapte bien avec des projets de moins de 10 personnes. • Il est itératif. • Il concentre plus sur l’aspect technique : processus développement, prototypes, tests... • Il est assez difficile dans sa mise en œuvre : quels intervenants, quels livrables ? 2TUP • Il s’articule autour de l’architecture. • Suit un cycle de développement en Y. • Vise des projets de toutes tailles. • Il est itératif. • Il donne une large place à la technologie et à la gestion du risque. • Il définit les profils des intervenants, les plannings, les livrables et les prototypes. • Il apporte une réponse aux contraintes de changements imposées aux systèmes informatiques. • Il n’exige pas de documents types. 1.6.2 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 [10] car elle répond aux caractéristiques des méthodes agiles définies 9
  • 24.
    Chapitre 1. Présentationgénérale et étude de l’existant dans la section précédente. Nous avons choisi la méthode Scrum pour les raisons suivantes : • elle est utilisée pour développer et tester les courtes itérations, • elle permet de produire la plus grande valeur métier dans la durée la plus courte, • elle permet l’augmentation de la productivité, • elle permet d’adapter le logiciel crée suivant l’évolution du projet. 1.6.3 Scrum C’est une méthode de développement agile orientée projet informatique dont les ressources sont régulièrement actualisées. Elle est basée sur les principes des méthodes agiles précédemment définis. Comme toutes les méthodes agiles, elle privilégie la livraison rapide d’un prototype, opérationnel par définition ,afin d’avoir un retour rapide des clients et des donneurs d’ordre pour minimiser les pertes de temps [11]. Les concepts de la méthode Scrum sont les suivants : 1.6.3.1 Le Sprint Le Sprint est une période qui varie entre deux et quatre semaines au maximum. Au bout de cette période, l’équipe délivre un incrément du produit potentiellement livrable. Une fois la durée est fixée, elle reste constante pendant toute la durée du développement. 1.6.3.2 Le chiffrage des tâches L’avantage de la méthode Scrum apparaît dans cette phase du projet. Le chiffrage consiste à estimer, pour chaque tâche, un degré de complexité ou bien combien ça coûte en termes d’effort. 1.6.3.3 Le Planning Poker Le planning poker est l’outil d’estimation fréquemment utilisé pour le développement des applications informatiques avec les méthodes agiles, notamment Scrum. L’équipe de développement logiciel utilise le planning poker pour produire des estimations de la complexité relative des fonctionnalités à développer [12]. 1.6.3.4 Scrum meeting Le Scrum Meeting n’est pas une réunion pendant laquelle nous cherchons à résoudre les problèmes, mais uniquement à les identifier et les exprimer. Le Scrum Master a pour rôle d’apporter 10
  • 25.
    Chapitre 1. Présentationgénérale et étude de l’existant des solutions ou de déléguer à un autre membre de l’équipe la résolution des problèmes soulevés durant le Scrum Meeting. 1.6.3.5 Calcul de vélocité Une fois que tous les items de Backlog de produit ont été estimés, nous attribuons un certain nombre d’items à réaliser aux sprints successifs. 1.6.3.6 Revue de sprint À la fin du sprint, tout le monde se réunit pour effectuer la revue du sprint. L’objectif de la revue du sprint est de valider le logiciel qui a été produit pendant le sprint. L’équipe commence par énoncer les items du Backlog de produit qu’elle a réalisés. 1.6.3.7 Rétrospective de sprint La rétrospective du sprint est faite en interne à l’équipe. L’objectif est de détecter les erreurs commises et de prendre des décisions pour les améliorer. 1.6.3.8 Cycle de vie de la méthode SCRUM Comme indiqué dans la figure 1.3, pour mettre en place la méthode SCRUM, il faut dégager dans un premier lieu le maximum de fonctionnalités à réaliser pour former le Backlog du produit. En second lieu, définir les priorités des fonctionnalités et choisir lesquelles seront réalisées dans chaque itération. Par la suite, focaliser l’équipe de façon itérative sur l’ensemble des fonctionnalités à réaliser dans des itérations appelées Sprints. Un sprint aboutit toujours à la livraison d’un produit partiel fonctionnel appelé incrément. Ainsi, vers la fin de chaque Sprint, une réunion aura lieu pour effectuer la revue de l’itération. L’objectif de cette réunion consiste à valider l’incrément qui été produit pendant l’itération. 11
  • 26.
    Chapitre 1. Présentationgénérale et étude de l’existant Figure 1.3: Cycle de vie SCRUM [2] 1.7 Environnement de développement Les choix techniques concernant les langages de développement ont été imposé par le Scrum Master dès le début du projet. 1.7.1 Langage de développement • C# [13] : Le développement de l’application se base sur le C# qui est un langage de programmation dérivé du langage C et inspiré du langage C++. Nous avons choisi ce langage vu ses majeurs avantages : simple, moderne, orienté objet. Il a été conçu pour générer des applications d’entreprise. • Type Script [14] : TypeScriptxest un langage de programmationxlibre etxopen-sourcexdéveloppé par Microsoft qui a pour but d’améliorer et de sécuriserxla production de code JavaScript. Il a été créé par Anders Hejlsberg en 2012 avec l’ajout de nouvelles fonctionnalités au langage JavaScript. • Linq [15] : Est un composant du framework .NET de Microsoft qui ajoute des capacitésxd’interrogation sur des données aux langagesx.NET en utilisant une syntaxe proche de celle de SQL 12
  • 27.
    Chapitre 1. Présentationgénérale et étude de l’existant 1.7.2 Plateforme de développement • Visual Studio 2017 Professionnel [16] : à destinationxdes équipesxplus petites, Visual StudioxProfessionnel permet de développer desxapplications de qualité surxdes périphériques et des services, à l’aide d’unexsolution unique et avec une expériencexde développement cohérente. L’EDI dispose des outils pour la création des applications natives Windows Store, Windows Modile, Android, iOS, des applications Office, des applications Web, etc. • TFS [17] : Un système de gestion back-end pour développeurs Visual studio et Eclipse de Microsoft. TFS fournit des contrôles pour la gestion des exigences, des projets, des laboratoires et des rejets et utilise Team Foundation Version Contrôle ou Git pour la gestion du code source. Proposé comme une suite logicielle installée localement ou d’un service basé sur le cloud, TFS est utilisé pour gérer des équipes de programmeurs travaillant sur le même projet de logiciel . • Git [18] : C’est un logiciel de gestion de sources et de contrôle de versions. Ce type de programmes a plusieurs fonctions, notamment : — garder un historique des différentes versions des fichiers — permettre le retour à une version antérieure quelconque, — garder un historique des modifications avec leur nature, leur date, leur auteur, etc, — permettre un accès souple à ces fichiers en local ou via un réseau, — permettre à des utilisateurs distincts et souvent distants de travailler ensemble sur les mêmes fichiers • Postman [19] : Postman est une application permettant avec un navigateur Web de lancer des appels d’API et de les tester. Postman permet d’envoyer des requêtes vers l’API de site en lui ajoutant des en-têtes clés / valeurs puis il permet de formater le résultat sur plusieurs formats tels que JSON, XML, HTML et autres. 1.7.3 Framework de développement • Le Framework .NET CORE [20] : Le .NET Core est unexversion modulaire dux.NET Framework portable sur plusieurs plateformes pour optimiser le partage et la réutilisation du code. En outre, le .NET Core estxopen source et 13
  • 28.
    Chapitre 1. Présentationgénérale et étude de l’existant acceptexles contributions de la Communauté. Cette rubrique répond aux questions courantesxsur le .NET Core. En outre, elle indique comment accéder et contribuer aux packages open source. • Entity Framework Core ( EF Core) [21] : Entity Frameworkx(EF) Core est une versionxlégère, extensible et multiplate-formexde la technologie d’accès aux donnéesxEntity Framework. EF Core est unxmappeur objet-relationnel (ORM) qui permet xaux développeursx.NET de travaillerxavec une base de données utilisant desxobjets .NET. Il élimine la nécessité de la plupart des codes d’accès aux données que les développeurs ont généralement besoin d’écrire. • Angular2 Framework [22] : Angular 2 est un frameworkxJavaScript open source pour créerxdes applications Webxen HTML et JavaScript et a été conçu comme une première approchexmobile. Angular2 comprendxdes éléments de programmationxréactive, nous utilisons donc lesx"Observables" pour créer des servicesxet des composants qui peuvent réagir aux changementsxde données dans notre application. Elles font partie de la bibliothèquexd’extensions réactives JavaScriptx(RxJS) et sont définies comme unexfonctionnalité inclusexdans la version ES7. 1.8 Langage de modélisation UML La conception de notre projet est basée sur le concept objet et articulée autour d’UML [23] (Unified Modeling Language) qui est par définition un langage de modélisation unifié et standardisé pour la conception des systèmes informatiques. UML a été choisi car il n’impose pas de méthode de travail particulière. Il peut être intégré à n’importe quel processus de développement logiciel puisqu’il présente une sorte de boîte à outils qui permet d’améliorer progressivement les méthodes de travail tout en préservant les modes de fonctionnement. Ce langage de modélisation est très intuitif, plus simple et cohérent que les autres méthodes. Il présente les différents points de vue de modélisation qui permettent de visualiser et de manipuler les éléments de la modélisation. En plus, il permet de limiter de nombreux risques d’erreurs. Nous avons utilisé pour ce fait l’outil Visual paradigm [24] car il permet la création des diagrammes UML et des modèles qui en sont à l’origine. 1.9 Conduite de projet La clé principale de réussite d’un projet avec la définition de la méthodologie de gestion de gestion de projet et le bon planning (Siegel, 2000). En effet, le planning aide à bien subdiviser le 14
  • 29.
    Chapitre 1. Présentationgénérale et étude de l’existant travail et séparer les tâches à réaliser. Il offre une meilleur estimation et gestion de temps nécessaire pour chaque tâche (Bourque, 2014). En effet, il donne assez de visibilité qui permet d’estimer la date approximative d’achèvement des activités les plus importantes (Siegel, 2000). Nous avons utilisé le diagramme de Gantt pour bien visualiser le diagramme de temps relatif à notre méthodologie de travail. Nous avons donc estimé de réaliser notre application SPA dans une durée de 4 mois, démarrant de premier février jusqu’à fin Mai. Cependant, la planification est prévisionnelle et peu importe la façon dont un projet a été planifier, il y aura toujours des changements sur la route. Gantt Chart facilite la représentation graphique de l’avancement d’un projet. Nous avons utilisé ce diagramme afin de planifier de façon optimale et de communiquer le planning établi. La figure 1.4 illustre le diagramme de Gantt prévisionnel de notre projet. Figure 1.4: Diagramme de Gantt Conclusion Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil Cynapsys IT Hotspot , ses principales activités et compétences. Par ailleurs, nous avons dégagé le contexte général du projet et nous avons présenté le choix de la méthodologie de développement. Ensuite, nous avons présenté la méthodologie de développement Scrum utilisée pour mettre en place notre solution ainsi que les différentes plateformes utilisées. Dans le chapitre suivant, nous exposerons la première étape de notre projet à savoir l’analyse et la spécification des besoins. 15
  • 30.
    Chapitre 2 Sprint 0:Analyse et spécification des besoins Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 20 3 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 20 4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 20 5 Architecture Adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  • 31.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Introduction Dans ce chapitre, nous allons commencer par l’identification des acteurs. Ensuite, nous allons éliciter les besoins fonctionnels et non fonctionnels. Puis, dans une deuxième section, nous allons entamer la modélisation des besoins fonctionnels. Par la suite, nous allons élaborer le Backlog du produit et nous allons planifier les sprints. Pour conclure, nous allons présenter l’environnement matériel du projet. 2.1 Capture des besoins 2.1.1 Identification des acteurs Un acteur est une entité externe au système. Il représente une personne ou un autre système informatique qui attend un ou plusieurs services offerts par une interface d’accès. Il interagit avec le système par envoi ou réception des messages. Par ailleurs, notre application va intervenir les différents acteurs suivants : • L’administrateur : Il possède le droit d’accéder aux différentes rubriques de l’application afin d’ajouter des nouveaux utilisateurs et d’attribuer des droits d’accès et un rôle bien déterminé pour chaque utilisateur au niveau de son profil afin de lui permettre ou pas d’agir sur certaines données au niveau d’un module donné dans un établissement donné. • Le patient : Le patient peut accéder au planning des visites via internet afin de demander un RDV, il peut modifier ou annuler un RDV tout en recevant un mail de confirmation. • Le médecin : Le médecin peut gérer le planning de consultation quotidien. Il peut ajouter, modifier ou supprimer au niveau de la gestion des Rendez-vous, il peut gérer les solts de temps disponibles pour que le patient puisse réserver un RDV durant l’horaire convenable. Chaque médecin peut être associé à un service et un département bien déterminé . 2.1.2 Besoins fonctionnels L’analyse fonctionnelle [23] est une démarche qui consiste à caractériser les fonctions offertes par un produit pour satisfaire les besoins d’un utilisateur. En effet, chacun de ces besoins reflète 17
  • 32.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins les attentes des différents utilisateurs envers le système conçu. Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de notre projet pour les différents modules de notre application. • Authentification : Chaque utilisateur (médecin, patient, administrateur), possède un login et un mot de passe spécifique qui lui permet de vérifier son identité, afin d’autoriser l’accès de cette entité à des ressources en toute sécurité. • Gestion des comptes utilisateurs : Cette fonctionnalité est assurée par l’administration de notre système qui est capable de gérer l’ensemble des utilisateurs. • Affectation des rôles : Tout utilisateur de ce système doit posséder un rôle qui est affecté par l’administrateur. En revanche, on a favorisé l’implémentation des permissions qui sont plus avantageux que les rôles. • Suivi des patients : Le médecin prend en charge la gestion de ses patients sans avoir besoin d’un secrétaire et qui lui facilite ses différents tâches. • Contrôle des médecins : L’administrateur doit associer un compte pour chaque médecin désirant adhérer à cette application tout en associant les informations spécifiques comme l’Id de service et le nom de département. • Suivi par calendrier : Elle concerne tout patient inscrit qui peut avoir à sa disposition tout un historique de ses rendez-vous déjà pris soit en tant que liste view ou sur un calendrier. • Affectation des départements : Cette partie concerne la création des différents départements existants dans un établissement pouvant être affecté à un médecin. • Suivi des RDV : Le patient a la possibilité de prendre un rendez-vous et il peut consulter l’état de sa demande de rendez-vous (En attente, acceptée ou refusée), de plus le médecin peut accepter ou refuser une demande de rendez-vous selon sa disponibilité. • Affichage de l’historique des rendez-vous : Le médecin peut consulter l’historique des demandes qu’il a acceptées et refusées. 18
  • 33.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins • Générer la disponibilité : Chaque médecin doit générer ses créneaux en spécifiant l’horaire de disponibilité avec la possibilité de basculer un temps de réservation et le désactiver. • Envoyer notification : Après la réservation de rendez-vous, le patient recevra un mail de confirmation comprenant les différentes informations relatives au planning, de même pour le médecin concerné. 2.1.3 Besoins non fonctionnels En plus des fonctionnalités capitales citées précédemment, notre solution doit prendre en considération certaines contraintes additionnelles et répondre à un ensemble de besoins non fonctionnels. Il s’agit des besoins qui caractérisent le système à savoir : • Rapidité : il est clairement établi que la vitesse d’affichage influence fortement l’efficacité de l’application. C’est pour cette raison qu’il faut développer une application fournissant des résultats efficaces et cohérents et dans un temps négligeable suite aux requêtes issues des utilisateurs, • User-Expérience (UX) : l’application devra être plus utilisable, désirable et navigables permettant successivement la facilité d’emploi avec des interfaces consistantes,l’attrait visuel et la rapidité d’obtenir des informations, • Internationalisation : l’application doit être multilingue essentiellement en Anglais, Français et Arabe qui peut constituer un avantage concurrentiel par rapports aux autres produits, • Fiabilité : les résultats apportés par l’application doivent être fiables et reflètent effectivement l’état de la base au moment de son interrogation, c’est-à-dire des données mises à jour, • Disponibilité : l’application doit être disponible à tout instant pour être utilisée par n’importe quel utilisateur, et doit être facilement accessible, • Extensibilité : toute amélioration ou modification doit être facile à réaliser, ainsi notre application devra garantir un degré d’extensibilité à tout développeur souhaitant y contribuer. 19
  • 34.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins 2.2 Modélisation des besoins fonctionnels Nous allons maintenant représenter ces différents besoins sous forme d’un diagramme de cas d’utilisation. 2.3 Diagrammes des cas d’utilisation Nous donnons ci-dessous une vue globale concernant le comportement fonctionnel du système. Ce diagramme permet de représenter les interactions entre les acteurs et les cas d’utilisation du système. Figure 2.1: Diagramme de cas d’utilisation général 2.4 Pilotage du projet avec SCRUM 2.4.1 Les rôles Scrum L’équipe Scrum [11] est constituée d’un propriétaire de produit, de l’équipe de développement et d’un Scrum Master. Les équipes Scrum sont auto-organisées et pluridisciplinaires. Des équipes 20
  • 35.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins auto-organisées choisissent la meilleure manière de réaliser le travail, plutôt que d’être dirigées par des personnes extérieures à l’équipe. Des équipes pluridisciplinaires ont toutes les compétences nécessaires pour réaliser le travail sans dépendre de personnes qui ne faisant pas partie de l’équipe. Le modèle d’équipe de Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité. Nous allons tout d’abord cerner notre équipe Scrum : • Product owner (PO) : Cynapsys Hotspot IT Représente le client du projet. C’est donc lui qui définit les attentes et les besoins du projet. Ainsi, son rôle est de définir les tâches qui permettront de répondre à ces besoins et mettra en place leur priorisation. • Scrum Master (SM) :Hamed Kolsi Le Scrum Master assure globalement le bon déroulement des programmes et il protège l’équipe de tout problème extérieur. Il assure également l’organisation des réunions et la bonne application de la méthode agile. • L’équipe de développement : Zohra BEN AHMED . Dans le cadre de ce projet l’équipe se limite en un seul membre qui est moi-même. 2.4.2 Backlog du produit Le Backlog du produit [25] correspond à une liste priorisée des besoins et des exigences du client. Les éléments du Backlog produit, appelé aussi des histoires utilisateurs, sont formulés en une ou deux phrases décrivant de manière claire et précise la fonctionnalité désirée par le client, généralement, écrit sous la forme suivante : En tant que X, je souhaite Y, an de Z. Le Backlog du produit comprend les champs suivants : • ID : c’est un nombre unique et auto-incrémenté pour chaque histoire • Titre : c’est le résumé du user story, • User Story : c’est une phrase décrivant la fonctionnalité désirée • Business Value : c’est la valeur métier qui dirige la priorisation du développement des histoires utilisateurs suivant les attentes et les besoins du client, allant de 0 à 100, • Story point : c’est l’effort nécessaire à la réalisation d’une histoire utilisateur. il est estimé par l’équipe et il est fixe dans le temps : un point correspond à quatre heures de charge de travail pour une personne. Dans le tableau 2.1, nous présentons la liste des histoires utilisateurs ainsi que leurs estimations. 21
  • 36.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Tableau 2.1: Le Backlog Produit ID Titre En tant que Je souhaite Afin de Business Value Story Point 1 S’authentifierAdministrateur Entrer mon login et mot de passe Gérer toutes les fonctionnalités 90 5 2 Gérer les utilisateurs Administrateur Créer, modifier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 5 3 Affecter les rôles Administrateur Créer, modifier,supprimer ou afficher les rôles Affecter les rôles 60 5 4 Gérer les profiles Administrateur Afficher et modifier les profiles Gérer les profiles 20 3 5 Gérer les comptes utilisateurs Administrateur Bloquer un utilisateur Bloquer un utilisateur 20 2 6 Gérer les patients Médecin Gérer les patients Créer, modifier,supprimer un patient 60 8 7 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 8 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 22
  • 37.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins 9 Gérer horaire disponible Médecin générer disponibilité contrôler ses propres rendez-vous et les permissions de réservation par les patients 40 5 10 Consulter notification Patient voir les notifications envoyé par le système Confirmer la réservation de rendez-vous souhaité 40 5 11 Consulter consultation Patient voir l’historique de ses consultations Avoir une connaissance sur sa santé 40 5 12 Gérer les Web services Développeur développer tous les Web services utiliser les Web services dans la partie Web 90 8 13 Gérer les départements Administrateur Créer, modier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 10 14 Gérer les préférences Utilisateur Choisir les préférences par défaut Gérer les préférences 20 10 2.4.3 Planification des sprints Une fois que le Backlog du produit est suffisamment complet et ordonnancé, nous avons établi, lors de la réunion de planification des sprints, les durées prévisionnelles du travail à effectuer durant chaque sprint. Après avoir évalué le travail estimé et dû au fait que notre équipe est considérée comme une petite équipe, les sprints que nous avons définis durent entre trois et quatre semaines. le tableau 2.2 présente la planification des sprints. 23
  • 38.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Tableau 2.2: Planification des sprints ID Nom Sprint Date Début Date Fin 1 Sprint 1 : Réalisation du module d’authentification et la gestion des modules d’utilisateurs, des rôles, des permissions 26/02/2017 25/03/2017 2 Sprint 2 : Réalisation du module de gestion des Rendez-vous côté médecin et côté patient et la gestion des flux des communications 26/03/2017 24/04/2017 3 Sprint 3 : Réalisation du module de contrôle des patients, médecins , départements et consultations 25/04/2017 26/05/2017 2.5 Architecture Adoptée Figure 2.2: La logique Modèle-Vue-Contrôleur Web API 24
  • 39.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins L’architecture de notre application est l’architecture MVC Web API. Il s’agit d’une méthode de conception qui crée une séparation entre la logique métier ou de traitement et la logique de présentation. Le MVC cherche à séparer nettement les couches présentation, traitement et accès aux données. • Le client est ce qui consomme l’API Web (application mobile, navigateur, etc.). Nous utiliserons Postman ou curl pour tester l’application. • Un contrôleur est un objet qui gère les requêtes HTTP et crée la réponse HTTP. • Un modèle est un objet qui représente les données dans notre application. Figure 2.3: Modèle MVC [3] Le modèle MVC permet une séparation des compétences (design, base de données, application), une séparation claire entre les données du programme et la partie graphique affichant les données et une simplicité de mise à jour. Dans notre cas, toute autre application utilisateur ayant une interface utilisateur qui veut simplement accéder à notre service, lorsque la demande est demandée, une action sur notre contrôleur sera invoquée, le contrôleur enverra les données d’entrée et un Le modèle est retourné à la vue. La vue dans notre cas ne serait pas une page aspx, rasoir ou html mais représenterait les données de résultat au format JSON. Architecture Angular2 La figure 2.4 représente l’architecture d’Angular2. 25
  • 40.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Figure 2.4: Architecture Angular2 [4] Il existe huit blocs principaux de l’application Angular 2 : • Modules : regroupement d’un ensemble de fonctionnalités sous un même Namespace. • Library Modules (barrels) : @angular/core, @angular/http... . • Les composants : Elément graphique composé d’un template et d’une classe • Directives : composants sans template (ngFor, ngIf, ...) • Métadata : Moyen d’indiquer à Angular comment utiliser la classe • Services : Code métier implémenté dans des classes qui seront injectées dans les différents composants. • Pipe : Elément permettant de formatter une donnée (équivalent au filter d’AngularJS). 2.6 Environnement matériel Notre environnement matériel est composé par des outils matériels et par une architecture physique. 2.6.1 Outils matériels Pour réaliser notre travail, nous avons utilisé comme environnement matériel un ordinateur portable avec un système d’exploitation Windows10 de 64 bits, ayant un processeur IntelR Core TM 26
  • 41.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins i5, doté d’une Ram de 4 Go et d’un disque dur de 500 GO. 2.6.2 Architecture physique Notre application se présente sous la forme d’une architecture N-tiers. Le composant Web API de l’application agit comme une interface basée sur HTTP qui accepte les requêtes HTTP d’une application client tierce et effectue des opérations de données. Le diagramme suivant tente d’expliquer l’architecture possible de cette application hypothétique à l’aide de l’API Web. Figure 2.5: Architecture WebAPI avec EFCore [5] Cette application peut exposer sa logique métier aux différentes applications clientes utilisant l’API Web. L’API Web peut utiliser efficacement les Repositories pour découper les couches métier et d’accès aux données de la classe Web API Controller. L’application API Web peut utiliser l’injection Intégrée (DI) pour injecter les dépendances requises dans les objets. Par exemple, l’accès aux données peut être enregistré dans le DI et peut être injecté dans Business Layer, en outre, Business Layer peut être enregistré dans DI et injecté dans le Repository et Repository dans l’API Web. La figure 2.6 montre l’architecture globale de notre application. Cette architecture nous a aidé à développer notre application Web avec les designs patterns recommandés. 27
  • 42.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Figure 2.6: Architecture globale de l’application [6] 2.6.3 Diagramme de déploiement Le diagramme de déploiement nous permet d’avoir une vue statique qui représente l’utilisation de l’architecture physique, et de la manière à travers laquelle les composants du système sont répartis. • Le serveur d’applicationxest responsable de laxgestion des sessions utilisateurs,xla gestion des patients, la gestion des médecins, gestion des RDV, etc. • Le serveur de données représentexla partie centrale qui gère la base de données et ses accès. • Le serveur webxtransmet à l’utilisateur le résultatxde la requête envoyé. • NodeJs est le responsable du chargement des pages pour les afficher dans le navigateur web, qui est en relation directe avec l’angular2 en utilisant le protocole http. • Entity Framework Core est responsable de la création de la base de données avec la migration automatique qui permet de faire la synchronisation avec le modèle de données. C’est l’approche Code First utilisée, c’est à dire à partir des classes vers la base de données. La figure 2.7 présente le diagramme de déploiement de la plate-forme Lazarus. 28
  • 43.
    Chapitre 2. Sprint0 :Analyse et spécification des besoins Figure 2.7: Diagramme de déploiement Conclusion Dans ce chapitre, nous avons passé en revue par les différentes notions nécessaires à la compréhension de notre sujet. Nous avons identifié les besoins fonctionnels et non fonctionnels de notre système ainsi que les acteurs. Ensuite, nous avons détaillé la première étape de la méthodologie que nous avons choisi à savoir l’identification de l’équipe de travail et la réalisation de backlog du produit. Ainsi, nous avons illustré la planification des sprints pour passer à la troisième étape qui est la mise en œuvre des sprints. Enfin, nous avons présenté l’architecture logique et physique de notre application. Dans le chapitre suivant, nous entamerons le premier sprint. 29
  • 44.
    Chapitre 3 Réalisation duSprint 1 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
  • 45.
    Chapitre 3. Réalisationdu Sprint 1 Introduction Ce chapitre a pour objectif de fournir un produit livrable, testé et déployé au dernier sprint. En effet,nous exposerons la réalisation du premier sprint réparti en quatre étapes à savoir spécification, conception, codage, test et rétrospective. 3.1 Backlog du Sprint Le sprintxest le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel unxincrément du produit sera réalisé. Avant de se lancer dans un sprint, l’équipexScrum doit obligatoirement définir le but de ce dernier. Ce but doit être défini en terme métier pour qu’il soit compréhensible par les membres en dehors de l’équipe.xIl s’agit de répondre à une question fondamentale «pourquoi faisons-nous ce sprint ?». Le but du premier sprint est de réaliser le module d’authentificationxet la gestion des modules d’utilisateurs, des rôles , desxpermissions et l’affectation des rôles aux utilisateurs.xUne fois, nous avons défini le but de notre sprint, il est le temps de décider quelles histoires de notrexbacklog du produit seront incluses dansxle backlog du sprint. Les estimationsxdes histoires sont définis en jour. Tableau 3.1: Backlog du sprint 1 ID Histoire Estimation 1 Réaliser l’authentification de l’utilisateur 5 2 Ajouter, Modifier , Supprimer et désactiver un utilisateur 7 3 Ajouter,Modifier,Supprimer et affecter les rôles 5 4 Contrôler les permissions 3 3.2 Spécification Dans cette section, nous allons élaborer le raffinement du cas d’utilisation et nous allons présenter un description détaillée. 3.2.1 Diagramme de cas d’utilisation raffiné «S’authentfier» La figure 3.1 illustre le raffinement de cas d’utilisation «S’authentifier». 31
  • 46.
    Chapitre 3. Réalisationdu Sprint 1 Figure 3.1: Raffinement de cas d’utilisation «S’authentfier» Description textuelle du cas d’utilisation «S’authentifier» Le tableau 3.2 montre la description textuelle du cas d’utilisation «S’authentifier». Tableau 3.2: Description du cas d’utilisation « S’authentifier » Titre Authentification Acteurs Utilisateur Pré conditions utilisateur inscrit Post conditions utilisateur connecté Scénario nominal 1) L’utilisateur clique sur le lien login, 2) le système génère la page d’authentification, 3) l’utilisateur saisit les droits d’accès (nom d’utilisateur, mot de passe), 4) le système valide les informations de login et de mot de passe par rapport à celles qu’il a mémorisées, 5) le système ramène l’utilisateur à la page principale de l’application. 32
  • 47.
    Chapitre 3. Réalisationdu Sprint 1 Scénario alternatif Non validité des coordonnées : lorsque le mot de passe est erroné, le système affiche un message d’erreur et demande à l’utilisateur de saisir à nouveau son mot de passe,ou bien lorsque l’utilisateur fournit un login inconnu, le système affiche un message d’erreur et propose à l’utilisateur de saisir un autre login. 3.2.2 Diagramme de cas d’utilisation raffiné «Gestion des utilisateurs» La figure 3.2 illustre le raffinement de cas d’utilisation «Gestion des utilisteurs». Figure 3.2: Raffinement de cas d’utilisation «Gestion des utilisateurs» 3.2.2.1 Description du sous cas d’utilisation «Ajouter utilisateur» Tableau 3.3: Description du sous cas d’utilisation « Ajouter utilisateur » 33
  • 48.
    Chapitre 3. Réalisationdu Sprint 1 Résumé L’administrateur de notre application peut ajouter plusieurs utilisateurs (médecins, patients, ..) ayant chacun un rôle spécifique. Pré conditions L’administrateur est authentifié Post conditions L’utilisateur peut se connecter avec le nouveau compte créé Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 2) l’administrateur clique sur le bouton ajouter, 3) l’administrateur saisit le login, le mot de passe et les différents paramètres pour chaque utilisateur, 4) le système affecte un ID unique automatiquement pour chaque utilisateur, 5) le système valide le nouvel ajout. Scénario d’exception E1 : Si l’utilisateur que vient être ajouté par l’administrateur est déjà existant, le système affiche un message d’erreur. E2 : Si les champs sont vides, l’ajout ne sera pas effectué car l’opération est impossible L’enchaînement reprend à l’étape 1 du scénario nominal 3.2.2.2 Description du sous cas d’utilisation « Modifier utilisateur » Tableau 3.4: Description du sous cas d’utilisation « Modifier utilisateur » Résumé L’administrateur peut modifier les informations personnelles des membres (médecins, patients...) avec leurs profils et droits d’accès ayant chacun un rôle spécifique. Pré conditions Utilisateur déjà existant et l’administrateur est authentifié Post conditions Utilisateur modifié Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 34
  • 49.
    Chapitre 3. Réalisationdu Sprint 1 2) l’administrateur saisit l’ID de l’utilisateur qui vise à le modifier, 3) le système génère le résultat de la recherche, 4) l’administrateur tape les nouvelles informations relatives à l’utilisateur et met à jour les droits d’accès, 5) le système valide la mise à jour. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.2.3 Description du sous cas d’utilisation «Créer rôle» Tableau 3.5: Description du sous cas d’utilisation « Créer rôle » Résumé L’administrateur doit créer les différents rôles qui constituent une base pour l’autorisation. Pré conditions Rôle non crée et administrateur authentifié Post conditions Utilisateur affecté à un rôle bien déterminé Scénario nominal 1) L’administrateur accède à la page de gestion des membres, 2) l’administrateur crée les rôles qui représentent une condition pour que chaque utilisateur accède à son espace privé, 3) l’administrateur affecte un rôle à chaque utilisateur inscrit ce qui garantit une sécurité au moment de l’authentification. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.3 Prototype des IHM Après avoir étudié les tâches du sprint 1, nous avons établi quelques maquettes afin de les valider avec le product owner. La figure 3.3 représente un prototype d’interface de la page de gestion de la liste des rôles dans laquelle l’administrateur peut gérer les rôles. 35
  • 50.
    Chapitre 3. Réalisationdu Sprint 1 Figure 3.3: Prototype "Liste des rôles" La figure 3.4 représente le prototype de gestion des utilisateurs. Figure 3.4: Prototype "Liste des utilisateurs" 3.2.4 Conception Dans cette partie, nous allons représenter le diagramme de classes de notre projet ainsi que les diagrammes de séquence pour ce sprint. La figure 3.5 illustre le diagramme de classes de notre application. 36
  • 51.
    Chapitre 3. Réalisationdu Sprint 1 Figure 3.5: Diagramme de classe 37
  • 52.
    Chapitre 3. Réalisationdu Sprint 1 Description du diagramme de classe Notre diagramme de classes comporte douze tables. Les plus importantes sont les suivantes : • La classe Rôles : est une classe qui définit le rôle affecté à chaque utilisateur, d’où un utilisateur peut avoir un seul rôle et un rôle peut être affecté à plusieurs utilisateurs. • La classe Permission : est une classe qui valide les informations d’identification de l’utilisateur et gère les paramètres utilisateurs. Cette classe ne peut pas être héritée. • La classe profile : un utilisateur peut avoir au maximum un profile que décrit ses propres informations. • La classe utilisateur : est une classe qui représente l’utilisateur de notre application quelque soit administrateur, praticien ou patient. Elle regroupe toutes leurs fonctionnalités, un utilisateur peut en faite s’authentifier et modifier ses propres informations. • Les classes médecin et patient : sont des classes qui héritent de la classe mère utilisateur et qui représentent les acteurs de notre application. • La classe Rendez-vous : Avant de pouvoir prendre un rendez-vous, le patient doit vérifier la disponibilité d’un médecin déjà sélectionné afin de pouvoir confirmer le rendez-vous • La classe Notification : Après avoir fixé un rendez-vous, le patient reçoit une notification automatique par mail de confirmation en cas de non confirmation de présence, de même pour le médecin. • La classe Département : chaque médecin doit être affecté à un département bien déterminé selon sa spécialité. Ce diagramme de classes sera utilisé dans la réalisation de tous les sprints. Modèle physique des données MPD La figure 3.6 illustre le diagramme de modèle physique de données. 38
  • 53.
    Chapitre 3. Réalisationdu Sprint 1 Figure 3.6: Diagramme de Modèle physique de données 39
  • 54.
    Chapitre 3. Réalisationdu Sprint 1 3.2.5 Diagrammes de séquences Nous allons maintenant représenter les interactions pour le cas d’utilisation « S’authentifier » sous forme de diagrammes de séquence. La figure 3.7 illustre le diagramme de séquence pour authentifier un utilisateur . Figure 3.7: Diagramme de séquence « S’authentifier » Nous allons maintenant représenter les interactions pour le cas d’utilisation « Gérer les utilisateurs» sous forme de diagrammes de séquence. L’administrateur crée les profils des utilisateurs 40
  • 55.
    Chapitre 3. Réalisationdu Sprint 1 en identifiant le nom d’utilisateur et le mot de passe à chaque usagé pour accéder au système et il lui attribue des droits d’accès. Il peut éventuellement modifier ces profils en cas ou l’utilisateur a oublié son mot de passe ou son nom d’utilisateur ou en cas de modification des droits d’accès. Diagramme de séquence ’ajouter utilisateur’ La figure 3.8 illustre le diagramme de séquence pour ajouter un utilisateur. Figure 3.8: Diagramme de séquence «Ajouter Utilisateur» Après avoir accéder à l’application, l’administrateur doit s’authentifier puis consulter la liste des utilisateurs et pourra ajouter un utilisateur. 41
  • 56.
    Chapitre 3. Réalisationdu Sprint 1 Diagramme de séquence de ’modifier un utilisateur’ La figure 3.9 illustre le diagramme de séquence pour modifier un utilisateur . Figure 3.9: Diagramme de séquence «Modifier Utilisateur» Après avoir s’authentifier, l’administrateur peut consulter la liste des utilisateurs et modifier un utilisateur. 42
  • 57.
    Chapitre 3. Réalisationdu Sprint 1 Diagramme de séquence de ’supprimer un utilisateur’ La figure 3.10 illustre le diagramme de séquence pour supprimer un utilisateur . Figure 3.10: Diagramme de séquence «Supprimer Utilisateur» Après avoir accéder à l’application, l’administrateur doit s’authentifier puis consulter la liste des utilisateurs et pourra supprimer un utilisateur. 43
  • 58.
    Chapitre 3. Réalisationdu Sprint 1 3.2.5.1 Diagramme d’activité La gestion des droits d’accès est liée directement à la gestion des utilisateurs, en effet l’administrateur peut créer des profils qui diffèrent d’un utilisateur à un autre selon les droits attribués. Figure 3.11: Diagramme d’activité "Gestion des profils et des droits d’accés " 44
  • 59.
    Chapitre 3. Réalisationdu Sprint 1 3.3 Code Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures d’écran. La figure 3.12 représente l’interface d’authentification pour l’utilisateur afin de manipuler les fonctionnalités de l’application SPA. Figure 3.12: Interface "S’authentifier" La figure 3.13 représente l’interface pour consulter la liste des utilisateurs. Figure 3.13: Interface "Consulter la liste des utilisateurs" À travers cette interface, l’administrateur peut gérer les utilisateurs. Il peut consulter, ajouter , modifier ou supprimer un utilisateur. Dans ce qui suit, nous allons détailler les scénarios 45
  • 60.
    Chapitre 3. Réalisationdu Sprint 1 de la gestion des utilisateurs sous forme des captures d’écran. La figure 3.14 représente l’interface d’ajout d’un utilisateur. Figure 3.14: Interface "Ajouter un utilisateur" Dans cette interface, l’administrateur a le droit d’ajouter un nouveau utilisateur. Il doit remplir le formulaire de création d’un utilisateur et valide sa saisie. La figure 3.15 représente l’interface de modification d’un utilisateur. Figure 3.15: Interface "Modifier un utilisateur" 46
  • 61.
    Chapitre 3. Réalisationdu Sprint 1 À travers la figure 3.15 , l’administrateur peut modifier un utilisateur. La figure 3.16 représente l’interface de suppression d’un utilisateur. Figure 3.16: Interface "Supprimer un utilisateur" Pour supprimer un utilisateur, l’administrateur clique sur le bouton "delete" et automatiquement une fenêtre s’affiche indiquant si l’administrateur veut confirmer la suppression de l’utilisateur. La figure 3.17 représente l’interface de création des rôles qui constituent la base pour l’autorisation. Figure 3.17: Interface "Ajouter un rôle " La figure 3.18 représente l’interface de modification d’un rôle choisi. 47
  • 62.
    Chapitre 3. Réalisationdu Sprint 1 Figure 3.18: Interface "Modifier un rôle " La figure 3.19 indique l’interface de profile personnel. Figure 3.19: Interface "Afficher profile " 3.4 Test Le test [23] d’un produit logiciel est un processus consistant qui vise à garantir le bon fonctionnement du système à travers une comparaison des comportements attendus et des résultats obtenus. Avant la fin de chaque Sprint nous avons testé les fonctionnalités du module. Ensuite nous avons validé toutes les fonctionnalités avec le Product Owner. Pour ce fait,nous avons élaboré dans le tableau 3.6 présenté ci-dessous un ensemble de cas de scénario de tests fonctionnels relatif au sprint 1. 48
  • 63.
    Chapitre 3. Réalisationdu Sprint 1 Tableau 3.6: Tests fonctionnels du sprint 1 Cas de test Démarches Comportements attendus Résultat Test d’authentification de l’utilisateur • demander la page d’authentification, • saisir le login et le mot de passe, • cliquer sur se connecter. • le système affiche la page de connexion, • l’utilisateur est redirigé vers la page d’accueil. Conforme Test d’ajout d’un nouvel utilisateur • demander la page de gestion des utilisateurs, • cliquer sur New User, • remplir le formulaire convenablement, • cliquer sur Valider. • la page de gestion des utilisateurs s’affiche, • la page d’ajout des utilisateurs s’affiche, • l’utilisateur est ajouté. Conforme Test de modification utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Edit User", • Remplir le formulaire convenablement, • Cliquer sur Save. • Affichage de la page de gestion des utilisateurs, • Affichage de la page de modification des utilisateurs, • Modification de l’utilisateur. Conforme 49
  • 64.
    Chapitre 3. Réalisationdu Sprint 1 Test de Suppression utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Delete User", • Cliquer sur "OK". • Affichage de la page de gestion des utilisateurs, • Apparition d’une fenêtre (Pop-Up), • Suppression de l’utilisateur. Conforme Après avoir vérifié le bon fonctionnement du code et des fonctionnalités, le premier livrable a été testé par le Product Owner.Ainsi,il nous a transmis la liste des améliorations,des fonctionnalités à ajouter et des bugs à signaler. 3.5 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • CRUD utilisateurs • CRUD rôle • Module d’authentification Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Détailler les profils d’utilisateur un peu plus. Conclusion Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons passé par la spécification, la conception, le codage et les tests. Dans le chapitre suivant nous entamons le deuxième sprint 50
  • 65.
    Chapitre 4 Réalisation duSprint 2 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2 Réalisation du module de gestion des rendez-vous . . . . . . . . . . . . . 52 3 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
  • 66.
    Chapitre 4. Réalisationdu Sprint 2 Introduction Après la réalisation du premier sprint, nous entamerons le deuxième sprint. Nous allons présenter dans ce chapitre la réalisation de ce sprint réparti en quatre modules à savoir spécification, conception, codage, test et rétrospective. 4.1 Backlog du Sprint Dans cette partie, nous allons élaborer le backlog du deuxième sprint. Le but de ce dernier est la gestion des rendez-vous médicaux. Les estimations des histoires sont définis en jour. Le tableau 4.1 montre le backlog de notre deuxième sprint Tableau 4.1: Backlog du sprint 2 ID Histoire Estimation 1 Créer un rendez-vous 5 2 Annuler un rendez-vous 7 3 Recevoir notification 5 4 Consulter la liste des rendez-vous 3 5 Gérer calendrier 2 6 Générer disponibilité du médecin 4 7 Consulter la liste de créneaux disponibles 2 4.2 Réalisation du module de gestion des rendez-vous 4.2.1 Mise en oeuvre des patrons de conception Repository et unitofwork dans ASP.NET Core Dans ce projet, nous concevons un modèle Repository commun pour toutes les entités et une classe Unit of work. Le diagramme suivant montre la relation entre le Repository et le contexte de données de Entity Framework Core, dans lequel les contrôleurs MVC interagissent avec le dépôt par une unité de travail plutôt que directement avec le cadre d’entité. 52
  • 67.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.1: Diagramme "Generic Repository Pattern and Unit of Work workflow" Implémentation de Repository Pattern Le modèle Repository pattern [26] est utilisé pour créer une couche d’abstraction entre le DAL (Data Access Layer) et le BAL (Business Access Layer) pour effectuer les opérations CRUD. Voici un extrait de code de la classe IRepository.cs. Figure 4.2: Extrait de code de la classe IRepository 53
  • 68.
    Chapitre 4. Réalisationdu Sprint 2 Pour notre application, nous avons généré le schéma à partir de la solution. la figure 4.3 montre le diagramme de Repository pattern. Figure 4.3: Diagramme Repository pattern Implémentation de "Unit of work Pattern" Le modèle Unit of Work [27] gère les opérations CRUD de la base de données en mémoire sur les entités en tant qu’une transaction. Donc, si l’une des opérations échoue, les opérations db entières seront en panne. Voici un extrait de la classe IUnitofwork.cs. 54
  • 69.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.4: Extrait de code de la classe IUnitofwork Avantages des patrons de conceptions repository et unit of work [26] — Gérer les opérations de la base de données dans la mémoire et enregistre plus tard les mises à jour en mémoire en tant que transaction dans la base de données. — Facilite pour que les couches soient lâchement couplées à l’aide d’une injection de dépendance. — Facilite le suivi des tests unitaires ou du développement axé sur les tests. 4.2.2 Mise en oeuvre des services web Un service Web [28] est un composant logiciel identifié par une URL (Uniform Resource Locator), dont ses interfaces publiques sont définies et consultées à travers XML. Les services Web interagissent entre eux à travers des messages XML. Les services Web fournissent un lien entre les différentes applications. Ainsi, les applications peuvent envoyer et recevoir des données en utilisant des technologies différentes (l’interopérabilité). Les services Web utilisent les standards XML et HTTP pour le transfert des données (normalisées). Les services Web permettent de partager des services et des fonctionnalités de manière très efficace. De plus, ils réduisent le temps de développement puisqu’ils permettent d’exploiter des services existants. 55
  • 70.
    Chapitre 4. Réalisationdu Sprint 2 4.2.2.1 Les caractéristiques d’un Web service Un service Web est caractérisé par : • l’accessibilité via le réseau, • la disposition d’une interface publique contenant un ensemble d’opérations décrites en XML, • le stockage de la description d’un Web service (fonctionnalités, comment l’invoquer et où le trouver) dans un annuaire, • la communication via des messages XML qui sont transportés par les protocoles Internet (HTTP, SMTP, FTP, etc...), • la production des systèmes faiblement couplés. C’est à dire le demandeur du service peut ne pas connaître le fournisseur. Ce dernier peut disparaître sans perturber l’application cliente qui trouvera un autre fournisseur en cherchant dans l’annuaire. 4.2.2.2 REST vs SOAP REST [28] et SOAP [28] sont des architectures qui permettent de fournir des services Web. Par contre, REST est utilisé lorsque nous cherchons la simplicité de la mise en ouvre. REST est lisible (pas d’enveloppe XML superflue) et facile à tester en utilisant un navigateur Web et simple à mettre en oeuvre (un script PHP classique peut souvent être considéré comme RESTful). SOAP reste toujours intégré dans de nombreux outils de développements (possibilité d’export de classes en Web services, possibilité de génération automatique de clients à partir des WSDL) et permet le contrôle sur les types de données attendus. Et puisque nous cherchons la simplicité et la rapidité nous avons choisi l’architecture REST pour nos services Web. 4.2.2.3 Service Web RESTfull L’architecture REST utilise le protocole HTTP, plutôt que de réinventer une sur couche comme SOAP. Nous accèdons à une ressource par son URI unique pour procéder à diverses opérations (GET, POST, PUT, DELETE), supportées nativement par HTTP. REST n’impose pas un format d’échange entre client et serveur. Nous sommes libre de représenter les données en XML,JSON ou dans tout autre dialecte. Les services REST permettent aux clients d’indiquer le format dans lequel ils souhaitent communiquer, sous la forme d’un paramètre supplémentaire dans l’URL, ou plus simplement grâce à l’en-tête HTTP en spécifiant le type du contenu (content-type). REST suit les règles suivantes : 56
  • 71.
    Chapitre 4. Réalisationdu Sprint 2 • l’URI (identifiant des ressources) : REST se base sur les URI afin d’identifier une ressource. Ainsi une application doit construire ses URI de manière précise, en tenant compte des contraintes REST. Exemple : Non RESTful : GET /getProduct ?id=1 Représentation RESTful : GET/product/1 ; • les verbes HTTP (identifiant des opérations) : REST utilise les méthodes HTTP existantes plutôt que d’inclure les opérations dans l’URI de la ressource. Généralement pour une ressource, il y a quatre opérations fréquentes sont CRUD (Create, Read, Update, Delete) : créer (POST), consulter (GET), mettre à jour (PUT) et supprimer (DELETE), • les réponses HTTP ( représentation des ressources) : La réponse envoyée n’est pas une ressource, c’est la représentation d’une ressource. En plus, une ressource peut avoir plusieurs représentations dans des formats divers : HTML, XML, CSV, JSON, etc. 4.2.2.4 Avantages du REST Le RESTxpermet une indépendance vis à visxdu langage de programmation et de la plateforme sur laquelle ils sont déployé, unexsimplicitéxd’implémentation et aucune intégration du format d’échange dans les messages. Nous avons réalisé tous les web services utilisés dans l’applicationxsingle page en nous basant sur la technologie MVC Web api. Concernant la spécification du format de représentation utilisé dans les résultats des Web services que nous avons réalisés, nous avons choisi JSON parce qu’il est en format texte permet de représenter des données et de les échanger facilement. 4.3 Spécification Dans cette section, nous allons élaborer le raffinement du cas d’utilisation et nous allons présenter des prototypes pour les interfaces graphiques. Par le biais de notre application, le patient peut prendre un rendez-vous désiré en un seul clic avec une meilleure visibilité des plannings des différents médecins prés de chez soi. Après que le rendez-vous est fixé, le médecin prescripteur reçoit une alerte de confirmation et peut gérer sa consultation. 4.3.1 Diagramme de cas d’utilisation raffiné «Suivi des rendez-vous» La figure 4.5 illustre le raffinement de cas d’utilisation «Suivi des rendez-vous». 57
  • 72.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.5: Raffinement de cas d’utilisation «Suivi des rendez-vous» 4.3.1.1 Description du sous cas d’utilisation «Créer rendez-vous » Pour prendre un rendez-vous, le patient sélectionne la date et l’heure du rendez-vous souhaité. Après la vérification de la disponibilité du médecin, le rendez-vous est enregistré dans la base de données et un message de confirmation s’affiche au patient. Si la date et/ou l’heure sélectionnée ne correspondent pas à la disponibilité du médecin, le système envoie un message d’erreur au patient pour lui informer que son rendez-vous n’a pas été enregistré et lui demande de choisir une autre date. 58
  • 73.
    Chapitre 4. Réalisationdu Sprint 2 Tableau 4.2: Description du sous cas d’utilisation « Créer rendez-vous » Résumé Dans ce cas d’utilisation, le patient prend en charge la gestion de ses propres RDV et le médecin reçoit la liste des RDV des patients concernés. En fait, le patient peut créer, modifier ou annuler un RDV. Pré conditions Date de rendez-vous disponible et non prise par un autre patient. Post conditions Date de rendez-vous fixée, Un nouveau RDV sera ajouté Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur la date désirée, 3) une fenêtre de création d’un nouveau rendez-vous s’affiche, 4) le patient saisit les différents informations nécessaires, 5) une fenêtre de confirmation s’affiche en cas ou la date est valable, 6) un mail de confirmation est envoyé au patient, 7) le rendez-vous réservé sera affecté à la date approprié sur l’agenda. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. E2 : Si la date choisie sera occupé, un message d’erreur sera affiché et le patient choisit une autre date L’enchaînement reprend à l’étape 1 du scénario nominal 4.3.1.2 Description du sous cas d’utilisation «Annuler rendez-vous » Tableau 4.3: Description du sous cas d’utilisation « Annuler rendez-vous » Résumé Un patient peut annuler un rendez-vous à tout moment et cette fonction apporte une meilleure flexibilité pour la gestion personnelle des rendez-vous. Pré conditions Rendez-vous déjà existant. Post conditions Rendez-vous non existant Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur le rendez-vous déjà réservé, 3) une fenêtre s’affiche pour l’annulation de rendez-vous, 4) le patient clique sur "cancel appointement", 5) le rendez-vous est annulée et il s’affiche avec la couleur gris. 59
  • 74.
    Chapitre 4. Réalisationdu Sprint 2 Scénario d’exception E1 :Si le délai de rendez-vous pris est déjà dépassé, le système affiche un message d’erreur et le patient ne peut appliquer aucune action d’annulation. 4.3.1.3 Description du sous cas d’utilisation «Gérer Calendrier » Tableau 4.4: Description du sous cas d’utilisation « Gérer Calendrier » Résumé La gestion des RDV se focalise sur l’usage d’un agenda qui s’affiche comme un Dashboard pour le patient. Pré conditions Patient authentifié. Post conditions Calendrier affiché Scénario nominal 1) Le patient saisit son login et son mot de passe, 2) le patient accède à son espace personnel, 3) le patient peut afficher ou créer un nouveau RDV à partir du calendrier. Tableau 4.5: Description du sous cas d’utilisation « Générer disponibilité » Résumé La génération de disponibilité est indispensable pour la réservation d’un rendez-vous. Pré conditions Médecin authentifié . Post conditions Créneaux générés Scénario nominal 1) Le médecin saisit son login et son mot de passe, 2) le médecin clique sur "availibility" dans le menu, 3) le médecin clique sur "generate availibility", 4) le médecin choisit la date de début , de fin, intervalle pour la durée de rendez-vous et le temps et clique sur "Generate". 4.3.2 Prototype des IHM Après avoir étudié les tâches du sprint 2, nous avons établi quelques maquettes afin de les valider avec le Product Owner. La figure 4.6 présenté ci-dessous indique le prototype de Suivi par 60
  • 75.
    Chapitre 4. Réalisationdu Sprint 2 calendrier. Figure 4.6: Prototype "Suivi par calendrier" La figure 4.7 représente le prototype de prise de rendez-vous. Figure 4.7: Prototype "Prise de rendez-vous" 4.4 Conception Nous allons maintenant représenter les interactions de ce sprint sous forme de diagrammes de séquence. 61
  • 76.
    Chapitre 4. Réalisationdu Sprint 2 Diagramme de séquence de ’Réserver rendez-vous’ La figure 4.8 illustre le diagramme de séquence relatif au cas d’utilisation « Réserver un RDV». Figure 4.8: Diagramme de séquence «Réserver rendez-vous » 62
  • 77.
    Chapitre 4. Réalisationdu Sprint 2 Diagramme de séquence ’Annuler rendez-vous’ La figure 4.10 illustre le diagramme de séquence pour annuler un rendez-vous. Figure 4.9: Diagramme de séquence «Annuler rendez-vous» 63
  • 78.
    Chapitre 4. Réalisationdu Sprint 2 Diagramme de séquence de ’Générer disponibilité’ La figure 4.10 illustre le diagramme de séquence générer disponibilité. Figure 4.10: Diagramme de séquence «Générer disponibilité» 64
  • 79.
    Chapitre 4. Réalisationdu Sprint 2 4.5 Code Dans cette partie, nous allons exposer quelques scénarios d’exécution à travers des captures d’écran. Une interface agenda avec vos créneaux disponibles et vos rendez-vous et la possibilité en cliquant simplement sur un créneau libre, d’ajouter un nouveau rendez-vous. La figure 4.11 représente l’interface de réservation d’un nouveau rendez-vous tout en introduisant les différents informations nécessaires ( nom patient, symptômes, médecin préféré, horaire..) avec la possibilité de le marquer comme "critique" en cas d’urgence. Figure 4.11: Interface "Réserver un rendez-vous" Après avoir réservé un rendez-vous , une notification de confirmation de réservation sera déclenchée à condition que la date choisie sera disponible pour le médecin et le patient peut annuler ce rendez-vous. Par ailleurs, le patient peut annuler le rendez-vous déjà réservé. La figure 4.12 représente l’interface de succès de réservation de rendez-vous en affichant le nom de médecin et la date. 65
  • 80.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.12: Interface "Confirmation de réservation de rendez-vous" La figure 4.13 représente l’interface d’annulation de rendez-vous. Figure 4.13: Interface "Annuler rendez-vous" Le patient peut afficher par la suite la liste de ses rendez-vous réservés soit dans un "calendarView" soit dans une "listview". Si le rendez-vous est mentionné en vert alors il est encore active et s’il est indiqué en gris ça montre qu’il a été annulé. La figure 4.14 représente l’interface de la liste des rendez-vous déjà pris. 66
  • 81.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.14: Interface "Liste des Rendez-Vous" La figure 4.15 représente l’interface la liste des rendez-vous sous forme d’un listview. Figure 4.15: Interface "Historique des rendez-vous" La figure 4.16 représente l’interface de réception de mail de confirmation. 67
  • 82.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.16: Interface "Notification de confirmation de rendez-vous par mail" Par ailleurs, le médecin peut suivre la liste de ses rendez-vous dans un calendrier. La figure 4.17 représente l’interface de la liste des rendez-vous déjà pris. Figure 4.17: Interface "Liste des plannings pour un médecin" Pour que le patient puisse réserver un rendez-vous, le médecin doit générer son horaire disponible tout en spécifiant la date de début, la date de fin et la durée de son pause. La figure 4.18 représente l’interface de génération de créneaux disponibles pour chaque médecin. 68
  • 83.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.18: Interface "Génération de temps disponible" Le médecin peut afficher par la suite ses horaires disponibles, la durée de chaque consultation. La figure 4.19 représente l’interface de la liste de temps disponible pour chaque médecin. Figure 4.19: Interface "La liste de temps disponible" La figure 4.20 représente l’interface de notification par message pour chaque médecin. 69
  • 84.
    Chapitre 4. Réalisationdu Sprint 2 Figure 4.20: Interface "Notification par message" 4.5.1 Test Pour ce fait, nous avons élaboré dans le tableau 4.5 un ensemble de cas de scénario de tests fonctionnels relatif au sprint 2. Tableau 4.6: Tests fonctionnels du sprint 2 Cas de test Démarches Comportements attendus Résultat Test de réservation d’un nouveau RDV • Accéder à l’interface de Calendrier, • Cliquer sur New appointment, • Accéder à l’interface d’ajout d’un rendez-vous, • Remplir le formulaire convenablement, • Cliquer sur Valider. • Affichage de la page d’accès au calendrier, • Affichage de la page d’ajout d’un nouveau RDV, • Génération de message du confirmation, • le rendez-vous est réservé. Conforme 70
  • 85.
    Chapitre 4. Réalisationdu Sprint 2 Test de Génération de slots vides • Accéder à la page de calendrier , • Cliquer sur availability dans le menu, • Cliquer sur générer availability, • Séléctionner l’horaire désiré, • Cliquer sur Valider. • Affichage de la page d’accès au calendrier, • Affichage de la page d’ajout de solts disponibles, • Succés de génération. Conforme 4.6 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • prise rendez-vous. • génération disponibilité. • envoi du mail du confirmation au médecin et patient. • génération d’alerte par message de notification à l’accueil. Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Réservation de rendez-vous automatique selon les symptômes. • Réservation du rendez-vous selon le filtrage du pays . Conclusion Ce chapitre concerne le deuxième sprint à savoir la réalisation du module de gestion des rendez-vous côté Web en passant par la spécification, la conception, le codage, les tests et les rétrospectives. Dans le chapitre suivant nous entamons le troisième sprint. 71
  • 86.
    Chapitre 5 Réalisation duSprint 3 Plan 1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
  • 87.
    Chapitre 5. Réalisationdu Sprint 3 Introduction Après la réalisation du deuxième sprint, nous entamerons le troisième sprint. Nous allons présenter dans ce chapitre la réalisation de ce sprint réparti en quatre modules à savoir spécification, conception, codage, test et rétrospective. 5.1 Backlog du Sprint Dans cette partie, nous allons élaboré le backlog du troisième sprint. Le but de ce dernier est le contrôle des patients , médecins et les consultations concernés. Les estimations des histoires sont définis en jour. Le tableau 5.1 montre le backlog de notre troisième sprint. Tableau 5.1: Backlog du sprint 3 ID Histoire Estimation 1 Consulter la liste des patients 5 2 Enregistrer les profils des patients 7 3 Ajouter , modifier et supprimer les patients 5 4 Consulter la liste des médecins 3 5 Ajouter , modifier et supprimer les médecins 2 6 Consulter les profils des médecins 4 7 Vérifier les consultations 2 7 Gérer les départements 3 5.2 Spécification Dans cette section, nous allons élaborer le raffinement des cas d’utilisation et nous allons présenter des prototypes pour les interfaces graphiques. 5.2.1 Diagramme de cas d’utilisation raffiné «Contrôler médecin» La figure 5.1 illustre le raffinement des cas d’utilisation «Contrôler les médecins». 73
  • 88.
    Chapitre 5. Réalisationdu Sprint 3 Figure 5.1: Raffinement de cas d’utilisation «Contrôler médecin» Tableau 5.2: Description du sous cas d’utilisation « Ajouter médecin » Résumé L’administrateur se charge d’ajouter des nouveaux médecins. Pré conditions Administrateur authentifié et médecin non existant. Post conditions Médecin crée Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) la liste des médecins s’affiche, 4) l’administrateur clique sur "New Provider", 5) une fenêtre pop-up de création d’un nouveau médecin se déclenche, 6) l’administrateur remplit le formulaire et clique sur "Save", 7) la page de création du profil s’affiche, 8) l’administrateur affecte le département, saisit le service et spécifie le reste des informations personnelles et clique sur le bouton "Save", 9) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. 74
  • 89.
    Chapitre 5. Réalisationdu Sprint 3 Tableau 5.3: Description du sous cas d’utilisation « Modifier médecin » Résumé L’administrateur peut modifier les informations d’un médecin choisi. Pré conditions Administrateur authentifié et médecin déjà existant. Post conditions Médecin modifié Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) la liste des médecins s’affiche, 4) l’administrateur clique sur l’icône "Edit", 5) une fenêtre pop-up de modification d’un médecin sélectionné se déclenche et les champs sont activés pour changement désirable, 6) l’administrateur remplit le formulaire avec les différents informations nécessaires, 7) L’administrateur clique sur "Save", 8) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si les champs sont vides, un message de validation sera généré Tableau 5.4: Description du sous cas d’utilisation « Supprimer médecin » Résumé L’administrateur peut supprimer un médecin. Pré conditions Administrateur authentifié et médecin déjà existant. Post conditions Médecin supprimé Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet médecins, 3) le système affiche la page de la liste des médecins, 4) l’administrateur clique sur le bouton "Supprimer", 5) le système affiche un message pour confirmer la suppression et l’administrateur clique sur «ok», 6) le système génère la nouvelle liste des médecins. Scénario d’exception E1 : Si l’administrateur essaye de supprimer un compte de médecin, il doit tout d’abord le supprimer de la liste des médecins, sinon un message d’erreur s’affiche. 75
  • 90.
    Chapitre 5. Réalisationdu Sprint 3 5.2.2 Diagramme de cas d’utilisation raffiné «Suivre patient» La figure 5.2 illustre le raffinement des cas d’utilisation «Suivre patient». Figure 5.2: Raffinement de cas d’utilisation «Suivre patient» Tableau 5.5: Description du sous cas d’utilisation « Ajouter patient » Résumé L’administrateur se charge d’ajouter des nouveaux patients. Pré conditions Administrateur authentifié et médecin non existant. Post conditions Médecin crée Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) la liste des patients s’affiche, 4) l’administrateur clique sur "New Patient", 5) une fenêtre pop-up de création d’un nouveau compte patient se déclenche, 6) l’administrateur remplit le formulaire et clique sur "Save", 7) la page de création du profil s’affiche et l’administrateur spécifie le groupe sanguin et les informations relatives au patient et valide, 8) le système génère la nouvelle liste des patients. 76
  • 91.
    Chapitre 5. Réalisationdu Sprint 3 Scénario d’exception E1 : Si l’administrateur ne remplit pas tous les champs obligatoires d’ajout d’un patient, un message d’alerte se déclenche. Tableau 5.6: Description du sous cas d’utilisation « Modifier patient » Résumé L’administrateur peut modifier les informations d’un patient choisi. Pré conditions Administrateur authentifié et patient déjà existant. Post conditions Médecin modifié Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) la liste des patients s’affiche, 4) l’administrateur clique sur l’icône "Edit", 5) une fenêtre pop-up de modification d’un patient sélectionné se déclenche et les champs sont activés pour changement désirable, 6) l’administrateur remplit le formulaire avec les différents informations nécessaires, 7) l’administrateur clique sur "Save", 8) le système génére la nouvelle liste des patients. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. Tableau 5.7: Description du sous cas d’utilisation « Supprimer patient » Résumé L’administrateur peut supprimer un patient. Pré conditions Administrateur authentifié et patient déjà existant. Post conditions Patient supprimé Scénario nominal 1) L’administrateur saisit son login et son mot de passe, 2) l’administrateur clique sur l’onglet patients, 3) l’administrateur demande la page de la liste des patients, 4) le système affiche ce dernier, 5) l’administrateur consulte la liste des patients , 77
  • 92.
    Chapitre 5. Réalisationdu Sprint 3 6) l’administrateur peut supprimer un patient en cliquant sur le bouton "supprimer", 7) le système affiche un message pour confirmer la suppression et l’administrateur clique sur «ok», 8) l’administrateur retourne à l’affichage de la nouvelle liste des patients. Scénario d’exception E1 : Si l’administrateur essaye de supprimer un compte de patient, il doit tout d’abord le supprimer de la liste des patients, sinon un message d’erreur s’affiche. 5.2.3 Prototype des IHM Après avoir étudié les tâches du sprint 3, nous avons établi quelques maquettes afin de les valider avec le product owner. La figure 5.3 présenté ci-dessous indique le prototype gestion des patients. Figure 5.3: Prototype "Gestion des patients" 5.3 Conception Nous allons maintenant représenter les interactions pour les cas d’utilisation « Contrôler Médecin» et « Suivre Patient» sous forme de diagrammes de séquence. Diagramme de séquence " Ajouter un médecin" La figure 5.4 illustre le diagramme de séquence pour ajouter un médecin. 78
  • 93.
    Chapitre 5. Réalisationdu Sprint 3 Figure 5.4: Diagramme de séquence " Ajouter un médecin" 79
  • 94.
    Chapitre 5. Réalisationdu Sprint 3 Diagramme de séquence " Modifier un médecin" La figure 5.5 illustre le diagramme de séquence pour modifier un médecin. Figure 5.5: Diagramme de séquence " Modifier un médecin" 80
  • 95.
    Chapitre 5. Réalisationdu Sprint 3 Diagramme de séquence " Supprimer un médecin" La figure 5.6 illustre le diagramme de séquence pour supprimer un médecin. Figure 5.6: Diagramme de séquence " Supprimer un médecin" 81
  • 96.
    Chapitre 5. Réalisationdu Sprint 3 5.4 Codage La figure 5.7 représente l’interface de gestion des médecins qui permet d’afficher toutes les informations nécessaires tout en incluant l’Id du service, le département et les informations personnelles. Figure 5.7: Interface "Liste des médecins" L’administrateur peut par la suite affiche le profil d’un médecin qui désire d’afficher ses détails. La figure 5.8 indique Le profil d’un médecin. Figure 5.8: Interface "Profil d’un médecin" Par ailleurs, l’administrateur peut ajouter, modifier ou supprimer un médecin en cas de besoin. La figure 5.9 représente l’interface d’ajout d’un nouveau médecin. 82
  • 97.
    Chapitre 5. Réalisationdu Sprint 3 Figure 5.9: Interface "Ajouter un nouveau médecin" La figure 5.10 représente l’interface de modification d’un médecin choisi. Figure 5.10: Interface "Modifier un médecin" L’administrateur peut par la suite gérer les patients adhérant à l’application. Pour Visualiser la liste des patients, il accède à l’accueil et clique sur patient dans le menu de navigation. La figure 83
  • 98.
    Chapitre 5. Réalisationdu Sprint 3 5.11 représente l’interface de la liste des patients. Figure 5.11: Interface "Liste des patients" Pour ajouter un nouveau patient, l’administrateur clique sur "New patient". La figure 5.12 représente l’interface d’ajout d’un patient. Figure 5.12: Interface "Ajouter un patient" Lorsque l’administrateur veut modifier un patient, il clique sur l’icône "Edit". Une fenêtre pop-up se déclenche pour appliquer les modifications au patient choisi.En autre, il peut soit modifier son profil ou son compte. La figure 5.13 représente l’interface de modification d’un patient. 84
  • 99.
    Chapitre 5. Réalisationdu Sprint 3 Figure 5.13: Interface "Modifier un patient" D’autre part, un médecin peut juste visualiser les détails des patients et ne peut apporter aucune modification. La figure 5.14 représente l’interface de modification d’un patient. Figure 5.14: Interface "Liste des patients personnalisée" La consultation est une étape postérieure qui se provoque suite à la prise de rendez-vous. La figure 5.15 représente l’interface de création de consultation qui nous donne une idée sur l’état de patient. 85
  • 100.
    Chapitre 5. Réalisationdu Sprint 3 Figure 5.15: Interface "Créer consultation pour patient" La figure 5.16 représente l’interface de gestion des départements. Figure 5.16: Interface "Gérer les départements" 5.5 Test Les tests fonctionnels [29] vérifient que le produit assure les fonctionnalités spécifiées dans les spécifications fonctionnelles. Avant la fin de chaque Sprint nous testons les fonctionnalités du module. Pour ce fait, nous avons élaboré dans le tableau 5.8 un ensemble de cas de scénario de tests 86
  • 101.
    Chapitre 5. Réalisationdu Sprint 3 fonctionnels relatif au sprint 3. Tableau 5.8: Tests fonctionnels du sprint 3 Cas de test Démarches Comportements attendus Résultat Test d’ajout de médecin • Demander la page des médecins, • la page de gestion des médecins s’affiche, • Cliquer sur l’icône "Add Provider", • l’administrateur remplit le formulaire convenablement, • Cliquer sur "Save". • Affichage de la page de médecins, • Génération de la page pop-up d’ajout de médecin, • Ajout du médecin. Conforme Test de modification médecin • Demander la page de gestion des médecins, • Cliquer sur "Edit Provider", • Remplir le formulaire convenablement, • Cliquer sur "Save". • Affichage de la page de gestion des médecins, • Affichage de la page de modification des médecins, • Modification du médecin. Conforme 87
  • 102.
    Chapitre 5. Réalisationdu Sprint 3 Test de Suppression médecin • Demandre la page de gestion des médecins, • Cliquer sur "Delete Provider", • l’administrateur clique sur "OK". • Affichage de la page de gestion des médecins, • Apparition d’une fenêtre (Pop-Up), • Suppression du médecin. Conforme Après avoir vérifié le bon fonctionnement du code et des fonctionnalités, le troisième livrable a été testé par le Product Owner. Ainsi, il nous a transmis la liste des améliorations, des fonctionnalités à ajouter et des bugs à signaler. 5.6 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • CRUD médecins • CRUD patients • CRUD départements Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Ajouter un peu plus de détails sur les patients. Conclusion Au cours de ce dernier chapitre, nous avons présenté le dernier sprint. Pour ce faire, nous avons passé par la spécification, la conception, le codage, les tests et les rétrospectives. 88
  • 103.
    Conclusion générale etPerspectives Dans ce rapport, nous avons abordé le domaine de l’e-santé afin de mieux comprendre l’attente d’un utilisateur d’une telle application afin de produire une application SPA de qualité. Cette étude nous a permis de constater la diversité des services pouvant être mis à disposition d’où complexité de se positionner par rapport à cet univers qu’on peut qualifier de novice en Tunisie. La réalisation de ce projet nous a permis de se confronter à plusieurs contraintes à la fois : contraintes de temps , contraintes de qualité et contraintes de technologie, En outre, il nous a permis de nous procurer de nouvelles connaissances aussi bien dans le domaine informatique que sur le plan humain, ce projet nous a permis donc de découvrir et d’adopter des nouvelles technologies tels que Angular2, .Net Core , Web API, C#, Bootstrap, et JavaScript, il nous a permis également de consolider notre expertise en développement. De ce fait, le présent travail se résume dans le développement d’une application Web intitulée « Lazarus » dans un contexte englobant le planning des rendez-vous et une meilleure circulation des informations en terme de relation entre les patients et les médecins. Ainsi, au cours de ce travail nous avons appliqué les différents enchaînements du cycle de vie du projet en se basant sur le paradigme MVC comme schéma de programmation qui propose de séparer l’application en trois parties (Modèle, Vue, Contrôleur). Par ailleurs, ce stage nous a donné la chance de suivre une méthodologie de travail bien étudiée et de manipuler des techniques innovantes et évolutives. Aussi, il nous a permis de tester et d’appliquer nos connaissances théoriques et pratiques acquises au sein de l’Institut Supérieur d’Informatique d’El Manar (ISI) et de les améliorer. De même, il nous a offert l’opportunité de s’initier à la vie professionnelle dans un milieu réel et d’avoir un début d’expérience significatif. Certaines perspectives se dessinent à l’horizon pour l’amélioration de ce travail par l’intégration d’autres fonctionnalités telles que la localisation des cabinets médicaux, la création d’une version mobile Ionic de notre application Web et création d’un module Business Intelligence pour l’aide à la décision. 89
  • 104.
    Bibliographie [1] Cynapsys. Présentationde cynapsys it hotspot. Cynapsys IT. Janvier. 2012. [En ligne] Disponible sur : http ://www.cynapsys.de/ [Accès le 01-Avril-2017]. [2] Collab. Image scrum. Collab. Janvier. 2014. [En ligne] Disponible sur : http ://scrummethodology.com/ [Accès le 5-Avril-2017]. [3] A. Mittal. Angular2 tutorial. Code project. [En ligne] Disponible sur : https ://www.codeproject.com/Articles/1186099 [Accès le 09-Avril-2017]. [4] J. Trivedi. Basic architecture of angular 2 applications. C Corner. [En ligne] Disponible sur : http ://www.c-sharpcorner.com/article/basic-architecture-of-angular-2-applications/ [Accès le 25-Mai-2017]. [5] M. Sabnis. Utilisation d’ef core dans asp.net core web api pour effectuer des opérations crud. DotNetCurry. 2017. [En ligne] Disponible sur : http ://www.dotnetcurry.com/entityframework/1348/ef-core-web-api-crud-operations [Accès le 27-Mars-2017]. [6] S. Chauhan. Asp.net core with angular4 development. DotnetTricks. [En ligne] Disponible sur : http ://www.dotnettricks.com/training/asp-net-core-development [Accès le 1-Juin-2017]. [7] tunisiait. Présentation de cynapsys. tunisiait. Janvier. 2017. [En ligne] Disponible sur : http ://www.tunisiait.com [Accès le 01-Avril-2017]. [8] ADO34. La gestion des projets. ACCESS-DEV. Février. 2013. [En ligne] Disponible sur : http ://www.access-dev.com/ [Accès le 1-Avril-2017]. [9] F. Lothen. Méthode agile. Agiliste. Janvier. 2014. [En ligne] Disponible sur : http ://www.agiliste.fr/ches/introductionmethodes-agiles [Accès le 02-Avril-2017]. [10] Dynamique-mag. Scrum. DM. Janvier. 2012. [En ligne] Disponible sur : http ://www.dynamique-mag.com [Accès le 4-Avril-2017]. [11] DynamiqueMag. Documentation scrum. DM. Janvier. 2012. [En ligne] Disponible sur : http ://www.dynamique-mag.com [Accès le 4-Avril-2017]. 90
  • 105.
    Bibliographie [12] innovaxion. Innovaxionplaning poker. innovaxion. Janvier. 2012. [En ligne] Disponible sur : www.innovaxion.net [Accès le 5-Avril-2017]. [13] B. Wagner. Introduction au langage c et au .net framework. Communauté Microsoft. [En ligne] Disponible sur : https ://docs.microsoft.com [Accès le 3-Juin-2017]. [14] A. Redmond. Typescript javascript qui varie. Communauté TypeScipt. [En ligne] Disponible sur : https ://www.typescriptlang.org/ [Accès le 3-Juin-2017]. [15] A. SCHMITTER. C : Linq. SupInfo. [En ligne] Disponible sur : http ://www.supinfo.com [Accès le 3-Juin-2017]. [16] H. Romaric. Les nouveautés de visual studio 2017. Club des développeurs. 2017. [En ligne] Disponible sur : : http ://rdonfack.developpez.com/tutoriels/dotnet/les-nouveautes-de-visual-studio-2017/ [Accès le 14-Mars-2017]. [17] LoveToKnow. Yourdictionary. LoveToKnow. 2012. [En ligne] Disponible sur : : http ://www.yourdictionary.com/tfs [Accès le 22-Avril-2017]. [18] D. Git. Svn. Club des développeurs. 2017. [En ligne] Disponible sur : https ://git-scm.com/ [Accès le 14-Mars-2017]. [19] Postman. Developing apis is hard. postman makes it easy. Postdot Technologies. [En ligne] Disponible sur : https ://www.getpostman.com/ [Accès le 27-Mai-2017]. [20] C. Microsoft. .net core et open-source. Microsoft. 2017. [En ligne] Disponible sur : https ://msdn.microsoft.com/fr-fr/library/dn878908(v=vs.110).aspx [Accès le 29-Avril-2017]. [21] R. Miller. Entity framework core. Microsoft. 2017. [En ligne] Disponible sur : https ://docs.microsoft.com/en-us/ef/core/index [Accès le 29-Avril-2017]. [22] C. TutorialPoints. Angular2 tutorial. Angular2. [En ligne] Disponible sur : https ://www.tutorialspoint.com/angular2/index.htm [Accès le 27-Avril-2017]. [23] C. UML. Qu’est-ce que uml. UML. 2010. [En ligne] Disponible sur : http ://uml.free.fr [Accès le 6-Avril-2017]. [24] C. Visual. Présentation de visual paradigm. Visual Paradigm. 2012. [En ligne] Disponible sur : http ://lgl.isnetne.ch/Visual-Paradigm-8 [Accès le 22-Avril-2017]. 91
  • 106.
    Bibliographie [25] C. atlassian.Présentation backlog du produit. UML. 2015. [En ligne] Disponible sur : https ://fr.atlassian.com/agile/backlogs [Accès le 6-Avril-2017]. [26] S. Chauhan. Implementing repository and unit of work patterns with asp.net mvc. Dotnet Tricks. 2017. [En ligne] Disponible sur : http ://www.dotnettricks.com [Accès le 25-Mars-2017]. [27] S. S. Shekhawat. Crud operations using the generic repository pattern and unit of work in mvc. C Sharp. 2017. [En ligne] Disponible sur : http ://www.c-sharpcorner.com/ [Accès le 25-Mars-2017]. [28] C. Refes. Les web service. Openclassroom. 2017. [En ligne] Disponible sur : https ://openclassrooms.com/courses/les-services-web [Accès le 26-Mars-2017]. [29] M. A. Mostefai. Test fonctionnel. ESI. [En ligne] Disponible sur : http ://fr.slideshare.net/mostefaiamine/gnie-logiciel-lestests [Accès le 24-Mai-2017]. 92
  • 107.
    Annexes La figure 5.14présente l’interface de préférences. Figure 5.14 : Interface de préferences La figure 5.15 présente l’interface de translation de l’application. Figure 5.15 : Interface de internationalisation 93
  • 108.
    Annexes La figure 5.16présente l’interface About de l’application. Figure 5.16 : Interface "A propos" La figure 5.17 présente l’interface de choix de couleur pour l’application. Figure 5.17 : Interface "Color Application" 94
  • 109.
    SPA . Entity FrameworkCore .Net Core . Scrum . Scrum SPA Entity Framework Core .NET CORE : Résumé Ce rapport a été réalisé dans le cadre du projet de fin d’études pour l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques spécialisés en Génie Logiciel et Systèmes d’Information. L’objectif de notre projet est de réaliser une application Web SPA dédiée principalement aux patients et médecins dont le but est d’élaborer une meilleure communication surtout pour la gestion des rendez-vous. Cette application est développée en utilisant le Framework .NET CORE pour la partie Web et Entity Framework CORE pour la partie base de données. Enfin, nous avons adopté la méthode de développement Scrum pour le développer. Mots clés : .NET CORE, Entity Framework Core, Web, SPA, Scrum Abstract This report was produced as part of the graduation project in order to obtain the National Engineering Diploma in Applied Science and Technology specializing in Software Engineering and Information Systems. Our project aim to achieve a Single Page Application SPA dedicated to the patients and doctors in order to facilitate their communication especially for appointements management. This application is developed using the .NET CORE framework for the Web part and Entity Framework Core for DataBase part. Finally, we have adopted the Scrum development methodology to develop our project. Keywords : .NET CORE, Entity Framework Core, Web, SPA, Scrum Cynapsys Tunisie. isi@isim.rnu.tn : 71 706 698 : 71 706 164 : 2080 2 2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn