Vous êtes sur la page 1sur 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 : Hamed KOLSI Ingénieur Informatique


Encadrant académique : Sahbi BAHROUN 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 : Hamed KOLSI Ingénieur Informatique


Encadrant académique : Sahbi BAHROUN 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 • Développement et • Efficacité pour les


membres de l’équipe. test pour des courtes projets de petite taille,

• Développement itérations. car il ne fonctionne

progressif. • Simplicité de processus. bien qu’avec une petite


équipe.
• Contrôle quotidien de • Augmentation de la
travail. productivité. • Énorme effet inverse
sur le développement
• Responsabilité
du projet Si l’un des
collective de l’équipe.
membres de l’équipe
quitte,

RUP

• Promu par Rational. • Il est itératif. • Il est coûteux à

• Le RUP est une • Il spécifie le dialogue personnaliser.

méthodologie et à entre les différents


la fois un outil prêt à intervenants du
l’emploi (documents projet : les plannings,
types partagés dans un les prototypes, les
référentiel Web). livrables...

8
Chapitre 1. Présentation générale et étude de l’existant

XP

• Il est un ensemble • Il est itératif. • Il est assez difficile dans


de "Bests Practices" • Il concentre sa mise en œuvre :
de Développement plus sur l’aspect quels intervenants, quels
(transfert de technique : processus livrables ?
compétences, travail développement,
en équipes... prototypes, tests...
• Il s’adapte bien avec des
projets de moins de 10
personnes.

2TUP

• Il s’articule autour de • Il est itératif. • Il n’exige pas de


l’architecture. • Il donne une large place documents types.

• Suit un cycle de à la technologie et à la


développement en Y. gestion du risque.

• Vise des projets de • Il définit les profils


toutes tailles. des intervenants, les
plannings, les livrables
et les prototypes.

• Il apporte une réponse


aux contraintes
de changements
imposées aux systèmes
informatiques.

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 Story


Value Point

1 S’authentifierAdministrateur Entrer mon login Gérer toutes les 90 5


et mot de passe fonctionnalités

2 Gérer les Administrateur Créer, Gérer les 90 5


utilisateurs modifier,supprimer utilisateurs
ou afficher les
utilisateurs

3 Affecter Administrateur Créer, Affecter les rôles 60 5


les rôles modifier,supprimer
ou afficher les
rôles

4 Gérer les Administrateur Afficher et Gérer les profiles 20 3


profiles modifier les
profiles

5 Gérer les Administrateur Bloquer un Bloquer un 20 2


comptes utilisateur utilisateur
utilisateurs

6 Gérer les Médecin Gérer les patients Créer, 60 8


patients modifier,supprimer
un patient

7 Consulter Médecin Voir les Suivre les 60 8


les rendez-vous rendez-vous
rendez-vous réservés par les
patients

8 Consulter Médecin Voir les Suivre les 60 8


les rendez-vous rendez-vous
rendez-vous réservés par les
patients

22
Chapitre 2. Sprint 0 :Analyse et spécification des besoins

9 Gérer Médecin générer contrôler 40 5


horaire disponibilité ses propres
disponible rendez-vous et les
permissions de
réservation par
les patients

10 Consulter Patient voir les Confirmer la 40 5


notification notifications réservation de
envoyé par le rendez-vous
système souhaité

11 Consulter Patient voir l’historique Avoir une 40 5


consultation de ses connaissance
consultations sur sa santé

12 Gérer Développeur développer tous utiliser les Web 90 8


les Web les Web services services dans la
services partie Web

13 Gérer les Administrateur Créer, Gérer les 90 10


départements modier,supprimer utilisateurs
ou afficher les
utilisateurs

14 Gérer les Utilisateur Choisir les Gérer les 20 10


préférences préférences par préférences
défaut

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 26/02/2017 25/03/2017


module d’authentification
et la gestion des modules
d’utilisateurs, des rôles, des
permissions

2 Sprint 2 : Réalisation du 26/03/2017 24/04/2017


module de gestion des
Rendez-vous côté médecin et
côté patient et la gestion des
flux des communications

3 Sprint 3 : Réalisation 25/04/2017 26/05/2017


du module de contrôle
des patients, médecins ,
départements et consultations

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é

1) L’utilisateur clique sur le lien login,


2) le système génère la page d’authentification,
Scénario nominal 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 Non validité des coordonnées : lorsque le mot de passe est


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

1) L’administrateur affiche la liste des utilisateurs déjà


inscrits,
Scénario nominal 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 E1 : Si l’utilisateur que vient être ajouté par l’administrateur


d’exception 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é

1) L’administrateur affiche la liste des utilisateurs déjà


inscrits,
Scénario nominal

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 E1 : Si l’identifiant saisi est non existant, la page n’affiche


d’exception 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é

1) L’administrateur accède à la page de gestion des membres,

Scénario nominal 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 E1 : Si l’identifiant saisi est non existant, la page n’affiche


d’exception 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 Conforme
d’authentification • demander la page • le système affiche la
de l’utilisateur d’authentification, page de connexion,

• saisir le login et le mot • l’utilisateur est redirigé


de passe, vers la page d’accueil.

• cliquer sur se connecter.

Test d’ajout d’un Conforme


nouvel utilisateur • demander la page de • la page de gestion des
gestion des utilisateurs, utilisateurs s’affiche,

• cliquer sur New User, • la page d’ajout des

• remplir le formulaire utilisateurs s’affiche,

convenablement, • l’utilisateur est ajouté.

• cliquer sur Valider.

Test de Conforme
modification • Demander la page de • Affichage de la page de
utilisateur gestion des utilisateurs, gestion des utilisateurs,

• Cliquer sur "Edit User", • Affichage de la page

• Remplir le formulaire de modification des

convenablement, utilisateurs,

• Cliquer sur Save. • Modification de


l’utilisateur.

49
Chapitre 3. Réalisation du Sprint 1

Test de Suppression Conforme


utilisateur • Demander la page de • Affichage de la page de
gestion des utilisateurs, gestion des utilisateurs,

• Cliquer sur "Delete • Apparition d’une


User", fenêtre (Pop-Up),

• Cliquer sur "OK". • Suppression de


l’utilisateur.

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é

1) Le patient accède à l’agenda,


2) le patient clique sur la date désirée,
Scénario nominal 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 E1 : Si les champs sont vides , un message de validation sera généré.


d’exception 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

1) Le patient accède à l’agenda,


2) le patient clique sur le rendez-vous déjà réservé,
Scénario nominal 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 E1 :Si le délai de rendez-vous pris est déjà dépassé, le système affiche
d’exception 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é

1) Le patient saisit son login et son mot de passe,


2) le patient accède à son espace personnel,
Scénario nominal 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

1) Le médecin saisit son login et son mot de passe,


2) le médecin clique sur "availibility" dans le menu,
Scénario nominal 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 Conforme


d’un nouveau RDV • Accéder à l’interface de • Affichage de la page
Calendrier, d’accès au calendrier,

• Cliquer sur New • Affichage de la page


appointment, d’ajout d’un nouveau

• Accéder à l’interface RDV,

d’ajout d’un • Génération de message


rendez-vous, du confirmation,

• Remplir le formulaire • le rendez-vous est


convenablement, réservé.

• Cliquer sur Valider.

70
Chapitre 4. Réalisation du Sprint 2

Test de Génération Conforme


de slots vides • Accéder à la page de • Affichage de la page
calendrier , d’accès au calendrier,

• Cliquer sur availability • Affichage de la page


dans le menu, d’ajout de solts

• Cliquer sur générer disponibles,

availability, • Succés de génération.

• Séléctionner l’horaire
désiré,

• Cliquer sur Valider.

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

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet médecins,
Scénario nominal 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 E1 : Si les champs sont vides , un message de validation sera généré.


d’exception

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é

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet médecins,
Scénario nominal 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 E1 : Si les champs sont vides, un message de validation sera généré


d’exception

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é

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet médecins,
Scénario nominal 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 E1 : Si l’administrateur essaye de supprimer un compte de médecin, il doit tout


d’exception 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

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet patients,
Scénario nominal 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 E1 : Si l’administrateur ne remplit pas tous les champs obligatoires d’ajout d’un
d’exception 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é

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet patients,
Scénario nominal 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 E1 : Si les champs sont vides , un message de validation sera généré.


d’exception

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é

1) L’administrateur saisit son login et son mot de passe,


2) l’administrateur clique sur l’onglet patients,
Scénario nominal 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 E1 : Si l’administrateur essaye de supprimer un compte de patient, il doit tout


d’exception 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 Conforme


médecin • Demander la page des médecins, • Affichage de la page de

• la page de gestion des médecins médecins,

s’affiche, • Génération de la page

• Cliquer sur l’icône "Add pop-up d’ajout de

Provider", médecin,

• l’administrateur remplit le • Ajout du médecin.

formulaire convenablement,

• Cliquer sur "Save".

Test de Conforme
modification • Demander la page de gestion des • Affichage de la page de
médecin médecins, gestion des médecins,

• Cliquer sur "Edit Provider", • Affichage de la page

• Remplir le formulaire de modification des

convenablement, médecins,

• Cliquer sur "Save". • Modification du


médecin.

87
Chapitre 5. Réalisation du Sprint 3

Test de Suppression Conforme


médecin • Demandre la page de gestion des • Affichage de la page de
médecins, gestion des médecins,

• Cliquer sur "Delete Provider", • Apparition d’une

• l’administrateur clique sur "OK". fenêtre (Pop-Up),

• Suppression du
médecin.

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
PÌl›
Ayw˜wnkt˜ ¤ TyqybWt˜ wl`˜ ¨ xdnhm˜ TynVw˜ ­ AhK˜ Ylˆ šwOl˜ rt˜ Š¤rK› CAV ¨ r§rqt˜ @¡zž
Ÿ› ºAbV± ¤ YRrm˜ Ÿykmt˜ SPA “ybW ºAKž Y˜ Š¤rKm˜ @¡ ‘dh§ .A›wl`m˜ œ\ž ¤ Ay›rb˜ TFdn¡ QAOt
Entity Framework Core ¤
w˜ žA ºAKž³ .Net Core Ylˆ Š¤rKm˜ @¡ dntsy. dyˆ wm˜ @± T}A ¤ ™S ™} w
Scrum ‰§CAKm˜ ­C  Tq§rV Ylˆ Amtˆ³A Š¤rKm˜ @¡ zž . AžAyb˜ ­dˆA’ ºAKž³
Scrum, SPA, Entity Framework Core,.NET CORE : y Af› Aml•

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 : ¨ž¤rtk˜¯ d§rb˜ 71 706 698 :H•Af˜ 71 706 164 : Ah˜ TžA§C 2080 ¨ž¤CAb˜  A§r˜ w hž 2
2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn