Outpatient Department System (OPD)

République Tunisienne
Ministère de l’Enseignement Supérieur
et de la Recherche Scientiﬁque
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 ﬁns 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 ﬁns 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é à ﬁnaliser 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 conﬁance 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éciﬁcation des besoins 16
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Identiﬁcation 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.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
iv

4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
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.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 "Modiﬁer un médecin" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.11 Interface "Liste des patients" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.12 Interface "Ajouter un patient" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.13 Interface "Modiﬁer 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.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
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
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

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

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

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

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

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

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 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 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

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

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

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

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

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

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

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

• 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

2.2 Modélisation des besoins fonctionnels
Nous allons maintenant représenter ces diﬀé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

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

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
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

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
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

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

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 aﬃchant 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 ﬁgure 2.4 représente l’architecture d’Angular2.
25

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 diﬀérents
composants.
• Pipe : Elément permettant de formatter une donnée (équivalent au ﬁlter 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

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

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 aﬃcher 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 ﬁgure 2.7 présente le diagramme de déploiement de la plate-forme Lazarus.
28

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éciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

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

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

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

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

Figure 3.3: Prototype "Liste des rôles"
La ﬁgure 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 ﬁgure 3.5 illustre le diagramme de classes de notre
application.
36

Figure 3.5: Diagramme de classe
37

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

Figure 3.6: Diagramme de Modèle physique de données
39

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

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

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

Diagramme de séquence de ’supprimer un utilisateur’
La ﬁgure 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’authentiﬁer puis consulter la
liste des utilisateurs et pourra supprimer un utilisateur.
43

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

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

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

À 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

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

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
• Cliquer sur "Edit User",
• Remplir le formulaire
convenablement,
• Cliquer sur Save.
• Affichage de la page de
• Affichage de la page
de modification des
utilisateurs,
• Modification de
l’utilisateur.
Conforme
49

Test de Suppression
utilisateur • Demander la page de
• Cliquer sur "Delete
User",
• Cliquer sur "OK".
• Affichage de la page de
• 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éciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

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

Figure 4.1: Diagramme "Generic Repository Pattern and Unit of Work workﬂow"
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 eﬀectuer 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

Pour notre application, nous avons généré le schéma à partir de la solution. la ﬁgure 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

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

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 superﬂue) 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éciﬁant le type du contenu (content-type). REST suit
les règles suivantes :
56

• 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

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

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

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

calendrier.
Figure 4.6: Prototype "Suivi par calendrier"
La ﬁgure 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

Diagramme de séquence de ’Réserver rendez-vous’
La ﬁgure 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

Diagramme de séquence ’Annuler rendez-vous’
La ﬁgure 4.10 illustre le diagramme de séquence pour annuler un rendez-vous.
Figure 4.9: Diagramme de séquence «Annuler rendez-vous»
63

Diagramme de séquence de ’Générer disponibilité’
La ﬁgure 4.10 illustre le diagramme de séquence générer disponibilité.
Figure 4.10: Diagramme de séquence «Générer disponibilité»
64

Outpatient Department System (OPD)

Outpatient Department System (OPD)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Outpatient Department System (OPD)

Similaire à Outpatient Department System (OPD) (20)

Dernier

Dernier (9)

Outpatient Department System (OPD)