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

Contenu connexe

Tendances

Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr
 
PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...
Rami Raddaoui
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
Addi Ait-Mlouk
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
Madjid Meddah
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
Nazih Heni
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
Mohamed Aziz Chetoui
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)
Nawres Farhat
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
Karim Ben Alaya
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
FaissoilMkavavo
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
Amine MEGDICHE
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
Bilel Khaled ☁
 

Tendances (20)

Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Pfe
PfePfe
Pfe
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
 

Similaire à Outpatient Department System (OPD)

Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Houssem Eddine Jebri
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
Adem Amen Allah Thabti
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Mohamed Amine Mahmoudi
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
ahmed oumezzine
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
Ilef Ben Slima
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
Donia Hammami
 
iRecruite
iRecruiteiRecruite
iRecruite
Donia Hammami
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
Abdelhalim KADDOUR GUETTAOUI
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
younes elmorabit
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
Mohamed Arar
 

Similaire à Outpatient Department System (OPD) (20)

Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
iRecruite
iRecruiteiRecruite
iRecruite
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
 
Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 

Dernier

QCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdfQCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdf
ffffourissou
 
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Alternative - Complément  au Tramway et 3ème lien de la ville de Québec  Alternative - Complément  au Tramway et 3ème lien de la ville de Québec
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Daniel Bedard
 
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
Institut de l'Elevage - Idele
 
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
Institut de l'Elevage - Idele
 
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Daniel Bedard
 
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
Institut de l'Elevage - Idele
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
idelewebmestre
 
PROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estivalPROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estival
idelewebmestre
 
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
Institut de l'Elevage - Idele
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
idelewebmestre
 
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
Institut de l'Elevage - Idele
 

Dernier (11)

QCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdfQCM de révision pour la haute qualité.pdf
QCM de révision pour la haute qualité.pdf
 
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
Alternative - Complément  au Tramway et 3ème lien de la ville de Québec  Alternative - Complément  au Tramway et 3ème lien de la ville de Québec
Alternative - Complément au Tramway et 3ème lien de la ville de Québec
 
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
02_UMT STAR_un nouveau biomarqueur de résilience basé sur les métabolites du ...
 
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
04_UMT STAR_Étude de nouveaux caractères en lien avec la santé et le bien-êtr...
 
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)Alternative - Complément au Tramway  et 3 ème lien de la ville de Quebec (PDF)
Alternative - Complément au Tramway et 3 ème lien de la ville de Quebec (PDF)
 
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
01_UMT STAR_étude de la résilience et des compromis entre résilience et effic...
 
Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024Note Agro-climatique et prairies n°4 - Juin 2024
Note Agro-climatique et prairies n°4 - Juin 2024
 
PROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estivalPROVINLAIT - Bâtiment et bien-être estival
PROVINLAIT - Bâtiment et bien-être estival
 
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
03_UMT STAR_compromis entre résistance au parasitisme et efficience alimentai...
 
Rénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdfRénovation des prairies sans labour est-ce possible en bio.pdf
Rénovation des prairies sans labour est-ce possible en bio.pdf
 
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
05_UMT STAR_Vers une indexation de la longévité fonctionnelle en ovin lait
 

Outpatient Department System (OPD)

  • 1. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
  • 2.
  • 3. République Tunisienne Ministère de l’Enseignement Supérieur et de la Recherche Scientifique Université de Tunis El Manar Institut Supérieur d’Informatique d’El Manar Rapport de Projet de Fin d’Études Présenté en vue de l’obtention du Diplôme National d’Ingénieur en Sciences Appliquées et Technologiques Spécialité : Génie Logiciel et Systèmes d’Information Par Zohra BEN AHMED Conception et Mise en place d’une Application Web SPA pour les Établissements Médicaux Encadrant professionnel : Encadrant académique : Hamed KOLSI Sahbi BAHROUN Ingénieur Informatique Docteur en Informatique Réalisé au sein de Cynapsys Tunisie Année Universitaire 2016 - 2017
  • 4. J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant professionnel, Hamed KOLSI Le J’autorise l’étudiant à faire le dépôt initial du mémoire ou de l’essai aux fins d’évaluation. Encadrant académique, Sahbi BAHROUN Le
  • 5. Dédicaces À mes trè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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 4.4 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.5.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5 Réalisation du Sprint 3 72 5.1 Backlog du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1 Diagramme de cas d’utilisation raffiné «Contrôler médecin» . . . . . . . . . . 73 5.2.2 Diagramme de cas d’utilisation raffiné «Suivre patient» . . . . . . . . . . . . 76 5.2.3 Prototype des IHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.4 Codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Conclusion générale 89 Bibliographie 90 Annexes 93 v
  • 10. Table des figures 1.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
  • 11. 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
  • 12. 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
  • 13. Liste des tableaux 1.1 Étude comparative entre les approches agiles . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Le Backlog Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2 Description du cas d’utilisation « S’authentifier » . . . . . . . . . . . . . . . . . . . . 32 3.3 Description du sous cas d’utilisation « Ajouter utilisateur » . . . . . . . . . . . . . . 33 3.4 Description du sous cas d’utilisation « Modifier utilisateur » . . . . . . . . . . . . . . 34 3.5 Description du sous cas d’utilisation « Créer rôle » . . . . . . . . . . . . . . . . . . . 35 3.6 Tests fonctionnels du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2 Description du sous cas d’utilisation « Créer rendez-vous » . . . . . . . . . . . . . . . 59 4.3 Description du sous cas d’utilisation « Annuler rendez-vous » . . . . . . . . . . . . . 59 4.4 Description du sous cas d’utilisation « Gérer Calendrier » . . . . . . . . . . . . . . . 60 4.5 Description du sous cas d’utilisation « Générer disponibilité » . . . . . . . . . . . . . 60 4.6 Tests fonctionnels du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2 Description du sous cas d’utilisation « Ajouter médecin » . . . . . . . . . . . . . . . 74 5.3 Description du sous cas d’utilisation « Modifier médecin » . . . . . . . . . . . . . . . 75 5.4 Description du sous cas d’utilisation « Supprimer médecin » . . . . . . . . . . . . . . 75 5.5 Description du sous cas d’utilisation « Ajouter patient » . . . . . . . . . . . . . . . . 76 5.6 Description du sous cas d’utilisation « Modifier patient » . . . . . . . . . . . . . . . . 77 5.7 Description du sous cas d’utilisation « Supprimer patient » . . . . . . . . . . . . . . 77 5.8 Tests fonctionnels du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 ix
  • 14. Liste des abréviations — AG = Agile Modeling — API = Application Programming Interface — CRUD = Create Read Update Delete — DI = Dependancy Iinjection — EDI = Environnement de Développement Intégré — EF = Entity Framework — HTTP = HyperText Transfer Protocol — IHM = Interface Homme Machine — JSON = JavaScript Oobject Notation — MVC = Model View Control — PFE = Projet Fin d’Etude — RDV = Rendez Vous — REST = REpresentational State Transfer — RUP = Rational Unified Process — SPA = Single Page Application — TFS = Team Founsation Server — UML = Unified Modeling Language — URI = Uniform Resource Identifier — VS = Visual Studio — XP = eXtreme Programming x
  • 15. Introduction générale Laxdémarche mé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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. Chapitre 1. Présentation générale et étude de l’existant début du projet. Le tableau 1.1 illustre une étude comparative de différentes méthodologies agiles. Tableau 1.1: Étude comparative entre les approches agiles Description Points forts Points faibles Scrum • Hiérarchisation des membres de l’équipe. • Développement progressif. • Contrôle quotidien de travail. • Développement et test pour des courtes itérations. • Simplicité de processus. • Augmentation de la productivité. • Responsabilité collective de l’équipe. • Efficacité pour les projets de petite taille, car il ne fonctionne bien qu’avec une petite équipe. • Énorme effet inverse sur le développement du projet Si l’un des membres de l’équipe quitte, RUP • Promu par Rational. • Le RUP est une méthodologie et à la fois un outil prêt à l’emploi (documents types partagés dans un référentiel Web). • Il est itératif. • Il spécifie le dialogue entre les différents intervenants du projet : les plannings, les prototypes, les livrables... • Il est coûteux à personnaliser. 8
  • 23. Chapitre 1. Présentation générale et étude de l’existant XP • Il est un ensemble de "Bests Practices" de Développement (transfert de compétences, travail en équipes... • Il s’adapte bien avec des projets de moins de 10 personnes. • Il est itératif. • Il concentre plus sur l’aspect technique : processus développement, prototypes, tests... • Il est assez difficile dans sa mise en œuvre : quels intervenants, quels livrables ? 2TUP • Il s’articule autour de l’architecture. • Suit un cycle de développement en Y. • Vise des projets de toutes tailles. • Il est itératif. • Il donne une large place à la technologie et à la gestion du risque. • Il définit les profils des intervenants, les plannings, les livrables et les prototypes. • Il apporte une réponse aux contraintes de changements imposées aux systèmes informatiques. • Il n’exige pas de documents types. 1.6.2 Méthode adoptée Dans cette partie, nous présentons notre méthode de développement adoptée. Notre choix s’est porté sur la méthode Scrum [10] car elle répond aux caractéristiques des méthodes agiles définies 9
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. Chapitre 2 Sprint 0 :Analyse et spécification des besoins Plan 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 Modélisation des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 20 3 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 20 4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . 20 5 Architecture Adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  • 31. Chapitre 2. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. Chapitre 2. Sprint 0 :Analyse et spécification des besoins Tableau 2.1: Le Backlog Produit ID Titre En tant que Je souhaite Afin de Business Value Story Point 1 S’authentifierAdministrateur Entrer mon login et mot de passe Gérer toutes les fonctionnalités 90 5 2 Gérer les utilisateurs Administrateur Créer, modifier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 5 3 Affecter les rôles Administrateur Créer, modifier,supprimer ou afficher les rôles Affecter les rôles 60 5 4 Gérer les profiles Administrateur Afficher et modifier les profiles Gérer les profiles 20 3 5 Gérer les comptes utilisateurs Administrateur Bloquer un utilisateur Bloquer un utilisateur 20 2 6 Gérer les patients Médecin Gérer les patients Créer, modifier,supprimer un patient 60 8 7 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 8 Consulter les rendez-vous Médecin Voir les rendez-vous Suivre les rendez-vous réservés par les patients 60 8 22
  • 37. Chapitre 2. Sprint 0 :Analyse et spécification des besoins 9 Gérer horaire disponible Médecin générer disponibilité contrôler ses propres rendez-vous et les permissions de réservation par les patients 40 5 10 Consulter notification Patient voir les notifications envoyé par le système Confirmer la réservation de rendez-vous souhaité 40 5 11 Consulter consultation Patient voir l’historique de ses consultations Avoir une connaissance sur sa santé 40 5 12 Gérer les Web services Développeur développer tous les Web services utiliser les Web services dans la partie Web 90 8 13 Gérer les départements Administrateur Créer, modier,supprimer ou afficher les utilisateurs Gérer les utilisateurs 90 10 14 Gérer les préférences Utilisateur Choisir les préférences par défaut Gérer les préférences 20 10 2.4.3 Planification des sprints Une fois que le Backlog du produit est suffisamment complet et ordonnancé, nous avons établi, lors de la réunion de planification des sprints, les durées prévisionnelles du travail à effectuer durant chaque sprint. Après avoir évalué le travail estimé et dû au fait que notre équipe est considérée comme une petite équipe, les sprints que nous avons définis durent entre trois et quatre semaines. le tableau 2.2 présente la planification des sprints. 23
  • 38. Chapitre 2. Sprint 0 :Analyse et spécification des besoins Tableau 2.2: Planification des sprints ID Nom Sprint Date Début Date Fin 1 Sprint 1 : Réalisation du module d’authentification et la gestion des modules d’utilisateurs, des rôles, des permissions 26/02/2017 25/03/2017 2 Sprint 2 : Réalisation du module de gestion des Rendez-vous côté médecin et côté patient et la gestion des flux des communications 26/03/2017 24/04/2017 3 Sprint 3 : Réalisation du module de contrôle des patients, médecins , départements et consultations 25/04/2017 26/05/2017 2.5 Architecture Adoptée Figure 2.2: La logique Modèle-Vue-Contrôleur Web API 24
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. Chapitre 3. Réalisation du Sprint 1 Figure 3.1: Raffinement de cas d’utilisation «S’authentfier» Description textuelle du cas d’utilisation «S’authentifier» Le tableau 3.2 montre la description textuelle du cas d’utilisation «S’authentifier». Tableau 3.2: Description du cas d’utilisation « S’authentifier » Titre Authentification Acteurs Utilisateur Pré conditions utilisateur inscrit Post conditions utilisateur connecté Scénario nominal 1) L’utilisateur clique sur le lien login, 2) le système génère la page d’authentification, 3) l’utilisateur saisit les droits d’accès (nom d’utilisateur, mot de passe), 4) le système valide les informations de login et de mot de passe par rapport à celles qu’il a mémorisées, 5) le système ramène l’utilisateur à la page principale de l’application. 32
  • 47. Chapitre 3. Réalisation du Sprint 1 Scénario alternatif Non validité des coordonnées : lorsque le mot de passe est erroné, le système affiche un message d’erreur et demande à l’utilisateur de saisir à nouveau son mot de passe,ou bien lorsque l’utilisateur fournit un login inconnu, le système affiche un message d’erreur et propose à l’utilisateur de saisir un autre login. 3.2.2 Diagramme de cas d’utilisation raffiné «Gestion des utilisateurs» La figure 3.2 illustre le raffinement de cas d’utilisation «Gestion des utilisteurs». Figure 3.2: Raffinement de cas d’utilisation «Gestion des utilisateurs» 3.2.2.1 Description du sous cas d’utilisation «Ajouter utilisateur» Tableau 3.3: Description du sous cas d’utilisation « Ajouter utilisateur » 33
  • 48. Chapitre 3. Réalisation du Sprint 1 Résumé L’administrateur de notre application peut ajouter plusieurs utilisateurs (médecins, patients, ..) ayant chacun un rôle spécifique. Pré conditions L’administrateur est authentifié Post conditions L’utilisateur peut se connecter avec le nouveau compte créé Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 2) l’administrateur clique sur le bouton ajouter, 3) l’administrateur saisit le login, le mot de passe et les différents paramètres pour chaque utilisateur, 4) le système affecte un ID unique automatiquement pour chaque utilisateur, 5) le système valide le nouvel ajout. Scénario d’exception E1 : Si l’utilisateur que vient être ajouté par l’administrateur est déjà existant, le système affiche un message d’erreur. E2 : Si les champs sont vides, l’ajout ne sera pas effectué car l’opération est impossible L’enchaînement reprend à l’étape 1 du scénario nominal 3.2.2.2 Description du sous cas d’utilisation « Modifier utilisateur » Tableau 3.4: Description du sous cas d’utilisation « Modifier utilisateur » Résumé L’administrateur peut modifier les informations personnelles des membres (médecins, patients...) avec leurs profils et droits d’accès ayant chacun un rôle spécifique. Pré conditions Utilisateur déjà existant et l’administrateur est authentifié Post conditions Utilisateur modifié Scénario nominal 1) L’administrateur affiche la liste des utilisateurs déjà inscrits, 34
  • 49. Chapitre 3. Réalisation du Sprint 1 2) l’administrateur saisit l’ID de l’utilisateur qui vise à le modifier, 3) le système génère le résultat de la recherche, 4) l’administrateur tape les nouvelles informations relatives à l’utilisateur et met à jour les droits d’accès, 5) le système valide la mise à jour. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.2.3 Description du sous cas d’utilisation «Créer rôle» Tableau 3.5: Description du sous cas d’utilisation « Créer rôle » Résumé L’administrateur doit créer les différents rôles qui constituent une base pour l’autorisation. Pré conditions Rôle non crée et administrateur authentifié Post conditions Utilisateur affecté à un rôle bien déterminé Scénario nominal 1) L’administrateur accède à la page de gestion des membres, 2) l’administrateur crée les rôles qui représentent une condition pour que chaque utilisateur accède à son espace privé, 3) l’administrateur affecte un rôle à chaque utilisateur inscrit ce qui garantit une sécurité au moment de l’authentification. Scénario d’exception E1 : Si l’identifiant saisi est non existant, la page n’affiche aucun résultat pour effectuer l’opération de la suppression L’enchaînement reprend à l’étape 2 du scénario nominal 3.2.3 Prototype des IHM Après avoir étudié les tâches du sprint 1, nous avons établi quelques maquettes afin de les valider avec le product owner. La figure 3.3 représente un prototype d’interface de la page de gestion de la liste des rôles dans laquelle l’administrateur peut gérer les rôles. 35
  • 50. 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
  • 51. Chapitre 3. Réalisation du Sprint 1 Figure 3.5: Diagramme de classe 37
  • 52. 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
  • 53. Chapitre 3. Réalisation du Sprint 1 Figure 3.6: Diagramme de Modèle physique de données 39
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. 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
  • 62. 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
  • 63. Chapitre 3. Réalisation du Sprint 1 Tableau 3.6: Tests fonctionnels du sprint 1 Cas de test Démarches Comportements attendus Résultat Test d’authentification de l’utilisateur • demander la page d’authentification, • saisir le login et le mot de passe, • cliquer sur se connecter. • le système affiche la page de connexion, • l’utilisateur est redirigé vers la page d’accueil. Conforme Test d’ajout d’un nouvel utilisateur • demander la page de gestion des utilisateurs, • cliquer sur New User, • remplir le formulaire convenablement, • cliquer sur Valider. • la page de gestion des utilisateurs s’affiche, • la page d’ajout des utilisateurs s’affiche, • l’utilisateur est ajouté. Conforme Test de modification utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Edit User", • Remplir le formulaire convenablement, • Cliquer sur Save. • Affichage de la page de gestion des utilisateurs, • Affichage de la page de modification des utilisateurs, • Modification de l’utilisateur. Conforme 49
  • 64. Chapitre 3. Réalisation du Sprint 1 Test de Suppression utilisateur • Demander la page de gestion des utilisateurs, • Cliquer sur "Delete User", • Cliquer sur "OK". • Affichage de la page de gestion des utilisateurs, • Apparition d’une fenêtre (Pop-Up), • Suppression de l’utilisateur. Conforme Après avoir vérifié le bon fonctionnement du code et des fonctionnalités, le premier livrable a été testé par le Product Owner.Ainsi,il nous a transmis la liste des améliorations,des fonctionnalités à ajouter et des bugs à signaler. 3.5 Rétrospective Dans cette partie, je vais citer les différentes rétrospectives dégagées par le Product Owner. Ce qui a marché • CRUD utilisateurs • CRUD rôle • Module d’authentification Ce qui n’a pas marché • Rien Ce qui doit être amélioré • Détailler les profils d’utilisateur un peu plus. Conclusion Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons passé par la spécification, la conception, le codage et les tests. Dans le chapitre suivant nous entamons le deuxième sprint 50
  • 65. 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
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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
  • 71. 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
  • 72. 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
  • 73. Chapitre 4. Réalisation du Sprint 2 Tableau 4.2: Description du sous cas d’utilisation « Créer rendez-vous » Résumé Dans ce cas d’utilisation, le patient prend en charge la gestion de ses propres RDV et le médecin reçoit la liste des RDV des patients concernés. En fait, le patient peut créer, modifier ou annuler un RDV. Pré conditions Date de rendez-vous disponible et non prise par un autre patient. Post conditions Date de rendez-vous fixée, Un nouveau RDV sera ajouté Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur la date désirée, 3) une fenêtre de création d’un nouveau rendez-vous s’affiche, 4) le patient saisit les différents informations nécessaires, 5) une fenêtre de confirmation s’affiche en cas ou la date est valable, 6) un mail de confirmation est envoyé au patient, 7) le rendez-vous réservé sera affecté à la date approprié sur l’agenda. Scénario d’exception E1 : Si les champs sont vides , un message de validation sera généré. E2 : Si la date choisie sera occupé, un message d’erreur sera affiché et le patient choisit une autre date L’enchaînement reprend à l’étape 1 du scénario nominal 4.3.1.2 Description du sous cas d’utilisation «Annuler rendez-vous » Tableau 4.3: Description du sous cas d’utilisation « Annuler rendez-vous » Résumé Un patient peut annuler un rendez-vous à tout moment et cette fonction apporte une meilleure flexibilité pour la gestion personnelle des rendez-vous. Pré conditions Rendez-vous déjà existant. Post conditions Rendez-vous non existant Scénario nominal 1) Le patient accède à l’agenda, 2) le patient clique sur le rendez-vous déjà réservé, 3) une fenêtre s’affiche pour l’annulation de rendez-vous, 4) le patient clique sur "cancel appointement", 5) le rendez-vous est annulée et il s’affiche avec la couleur gris. 59
  • 74. Chapitre 4. Réalisation du Sprint 2 Scénario d’exception E1 :Si le délai de rendez-vous pris est déjà dépassé, le système affiche un message d’erreur et le patient ne peut appliquer aucune action d’annulation. 4.3.1.3 Description du sous cas d’utilisation «Gérer Calendrier » Tableau 4.4: Description du sous cas d’utilisation « Gérer Calendrier » Résumé La gestion des RDV se focalise sur l’usage d’un agenda qui s’affiche comme un Dashboard pour le patient. Pré conditions Patient authentifié. Post conditions Calendrier affiché Scénario nominal 1) Le patient saisit son login et son mot de passe, 2) le patient accède à son espace personnel, 3) le patient peut afficher ou créer un nouveau RDV à partir du calendrier. Tableau 4.5: Description du sous cas d’utilisation « Générer disponibilité » Résumé La génération de disponibilité est indispensable pour la réservation d’un rendez-vous. Pré conditions Médecin authentifié . Post conditions Créneaux générés Scénario nominal 1) Le médecin saisit son login et son mot de passe, 2) le médecin clique sur "availibility" dans le menu, 3) le médecin clique sur "generate availibility", 4) le médecin choisit la date de début , de fin, intervalle pour la durée de rendez-vous et le temps et clique sur "Generate". 4.3.2 Prototype des IHM Après avoir étudié les tâches du sprint 2, nous avons établi quelques maquettes afin de les valider avec le Product Owner. La figure 4.6 présenté ci-dessous indique le prototype de Suivi par 60
  • 75. 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
  • 76. 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
  • 77. 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
  • 78. 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