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 STAGE DE FIN D’ÉTUDES
Présenté en vue de l’obtention du
Diplôme National de Licence Fondamentale en Sciences et Technologies
Mention : Science de l’Informatique
Spécialité : Science de l’Informatique
Par
Ines HAMROUNI Yasmine LACHHEB
Conception et mise en place d’une
plate-forme de gestion des stagiaires
Encadrant professionnel :
Encadrant académique :
Monsieur Mohamed BAHY
Monsieur Riadh ZAAFRANI
Chef de projet SI
Maître Assistant
Réalisé au sein de la Banque Internationale Arabe de Tunisie BIAT
Année Universitaire 2017 - 2018
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
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 STAGE DE FIN D’ÉTUDES
Présenté en vue de l’obtention du
Diplôme National de Licence Fondamentale en Sciences et Technologies
Mention : Science de l’Informatique
Spécialité : Science de l’Informatique
Par
Ines HAMROUNI Yasmine LACHHEB
Conception et mise en place d’une
plate-forme de gestion des stagiaires
Encadrant professionnel :
Encadrant académique :
Monsieur Mohamed BAHY
Monsieur Riadh ZAAFRANI
Chef de projet SI
Maître Assistant
Réalisé au sein de la Banque Internationale Arabe de Tunisie BIAT
Année Universitaire 2017 - 2018
J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une
soutenance.
Encadrant professionnel, Mohamed BAHY
Signature et cachet
J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une
soutenance.
Encadrant académique, Riadh ZAAFRANI
Signature
Dédicaces
Du profond de mon cœur, je dédie ce travail
À mes chers parents,
Qui demeurent pour moi un modèle d’intégrité et de rigueur.
Aucune dédicace ne saurait être assez éloquente pour exprimer l’amour et le
respect que j’ai toujours pour vous.
Que ce modeste travail soit pour vous une reconnaissance envers tous vos
sacrifices et vos efforts fournis jour et nuit pour faire de moi ce que je suis,
je dois à vous toute ma réussite.
Puisse Dieu, le tout-puissant, vous gratifie d’une longue vie débordante de santé
et de bonheur.
À mes adorables sœurs Amal et Yasmine,
Qui n’ont jamais cessé de m’assister, de me soutenir et de m’encourager.
En témoignage de mon affection fraternelle, mon attachement éternel et ma
reconnaissance.
Je vous aime mes chéries, et je vous souhaite un avenir brillant.
Que Dieu vous bénisse et vous préserve que de la réussite.
À tous ceux que j’aime,
À tous ceux qui m’aiment et me supportent.
Ines HAMROUNI
i
Dédicaces
Aimablement, je dédie ce modeste travail
À mes chers parents,
Ceux qui représentent pour moi un magnifique modèle de labeur et de
persévérance,
nulle dédicace ne peut témoigner de l’amour, de l’estime et du respect que je
leur porte.
À mon frère,
Mon fidèle compagnon, celui qui ne cesse jamais de me rendre heureuse et de
me motiver pour aller en avant.
À mes très chers amis Zied, Alia et Ines
En témoignage de l’amitié et de l’amour qui nous unissent, et des souvenirs des
moments merveilleux que nous avons passés.
À toute ma famille et tous ceux qui m’entourent, que je ne saurai
terminer ma dédicace sans les citer.
Yasmine LACHHEB
ii
Remerciements
Nous avons un grand plaisir de garder cette page en signe de gratitude et de
profonde reconnaissance à tous ceux qui nous ont aidé de près ou de loin à la
réalisation de ce projet.
Nous sommes très reconnaissantes à notre encadrant à l’institut supérieur d’in-
formatique, Monsieur Riadh ZAAFRANI, d’avoir accepté de diriger ce tra-
vail sans oublier ses conseils et sa participation régulière au cheminement de ce
rapport avec rigueur et bienveillance.
Nous tenons à remercier Monsieur Mohamed BAHY, notre encadrant pro-
fessionnel, pour sa disponibilité tout au long de ce stage, ses judicieux conseils et
ses encouragements, qu’il trouve ici notre respectueuse reconnaissance.
Nous tenons à remercier les membres de jury de nous avoir offert l’occasion de
présenter notre projet devant leur honorable assistance et d’avoir accepté d’évaluer
ce travail.
iii
Table des matières
Introduction générale 1
1 Cadre général du projet 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Le Département des Systèmes d’information . . . . . . . . . . . . . . . . 3
1.1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . 4
1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Le concept agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Présentation de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . 6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Étude et analyse globale du projet 9
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . 12
2.2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Sprint0 : Mise en place de l’environnement matériel et logiciel 21
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iv
3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4 Outil de gestion de versions . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5 Outil de manipulation des documents électroniques . . . . . . . . . . . . 24
3.2.6 Environnement de Système de Gestion de Base de Données . . . . . . . . 24
3.3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Protocoles de messagerie utilisés . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.2 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Sprint1 : Authentification et gestion des utilisateurs et des offres 31
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Sprint2 : Traitement des candidatures des stagiaires 48
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
v
5.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.2 Rétrospective du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Sprint3 : Affectation des stagiaires 65
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3.2 Rétrospective du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7 Sprint4 : Gestion des stages et statistiques 81
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
vi
7.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.3.2 Rétrospective du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.4 Phase du clôture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Conclusion générale 97
Bibliographie 98
Annexes 99
Annexe A. Fonctions de manipulation des données . . . . . . . . . . . . . . . . . . . . 99
Annexe B. Exemples de fonctions relatives au système « SI Mailing » . . . . . . . . . 100
Annexe C. Authentification et génération des fichiers PDF . . . . . . . . . . . . . . . 101
vii
Table des figures
1.1 Logo de la Banque Internationale Arabe de Tunisie BIAT . . . . . . . . . . . . . 3
1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Vue globale « Scrum » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Estimation théorique des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 l’architecture 3-tiers de notre application . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Principe des échanges de messages électroniques . . . . . . . . . . . . . . . . . . 29
3.4 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Diagramme de cas d’utilisation global du sprint1 . . . . . . . . . . . . . . . . . . 34
4.2 Raffinement du cas d’utilisation « Gérer utilisateurs » . . . . . . . . . . . . . . . 34
4.3 Diagramme de séquence du cas d’utilisation « S’authentifier » . . . . . . . . . . 38
4.4 Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur » . . . . . . 39
4.5 Diagramme de séquence du cas d’utilisation « Modifier un utilisateur » . . . . . 40
4.6 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.8 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Interface de la liste des offres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11 Interface de modification d’une offre de stage . . . . . . . . . . . . . . . . . . . . 44
4.12 Interface d’un profil utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 Interface du contenu d’une offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Diagramme de cas d’utilisation global du sprint2 . . . . . . . . . . . . . . . . . . 51
5.2 Raffinement du cas d’utilisation « Traiter demandes reçues » . . . . . . . . . . . 51
5.3 Raffinement du cas d’utilisation « Présélectionner candidats » . . . . . . . . . . 53
5.4 Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues » . . . . 55
5.5 Diagramme de séquence du cas d’utilisation « Affecter Candidat » . . . . . . . . 56
viii
Table des figures
5.6 Diagramme de séquence du cas d’utilisation « Afficher profil candidat » . . . . . 57
5.7 Diagramme de classes du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.8 Interface de la liste des demandes reçues et non traitées . . . . . . . . . . . . . . 59
5.9 Interface du profil candidat coté responsable . . . . . . . . . . . . . . . . . . . . 59
5.10 Interface du profil candidat coté encadrant . . . . . . . . . . . . . . . . . . . . . 60
5.11 Interface choisir candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.12 Interface d’affectation des stagiaires . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.13 Mail de réponse à une demande de stage . . . . . . . . . . . . . . . . . . . . . . 62
5.14 Accusé de réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 Diagramme de cas d’utilisation global du sprint3 . . . . . . . . . . . . . . . . . . 68
6.2 Raffinement du cas d’utilisation « Gérer suggestions » . . . . . . . . . . . . . . . 69
6.3 Raffinement du cas d’utilisation « Gérer propositions d’encadrement » . . . . . . 69
6.4 Raffinement du cas d’utilisation « Gérer affectations » . . . . . . . . . . . . . . 71
6.5 Diagramme d’activité du cas d’utilisation « Consulter demandes suivies » . . . . 73
6.6 Diagramme de séquence du cas d’utilisation « Accepter d’encadrer » . . . . . . . 74
6.7 Diagramme de séquence du cas d’utilisation « Accepter prise de fonction » . . . 75
6.8 Diagramme de classes du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.9 Interface de la liste des demandes suivies . . . . . . . . . . . . . . . . . . . . . . 77
6.10 Interface des demandes en attente . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.11 E-mail d’acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.1 Diagramme de cas d’utilisation global du sprint 4 . . . . . . . . . . . . . . . . . 84
7.2 Raffinement du cas d’utilisation « Gérer prolongations » . . . . . . . . . . . . . 85
7.3 Raffinement du cas d’utilisation « Gérer stages encadrés » . . . . . . . . . . . . 86
7.4 Diagramme de séquence du cas d’utilisation « Consulter liste demandes de pro-
longation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.5 Digramme de séquence du cas d’utilisation « Évaluer stagiaire » . . . . . . . . . 89
7.6 Diagramme de classes du sprint4 . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.7 Interface de la liste des stages en cours . . . . . . . . . . . . . . . . . . . . . . . 91
7.8 Interface de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.9 Envoi de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.10 Pop-up de prolongation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.11 Interface de la liste des demandes de prolongation . . . . . . . . . . . . . . . . . 93
ix
Table des figures
7.12 Interface des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.13 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.1 Fonction PL/SQL « addDemande » . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.2 Fonction d’ajout de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.3 Fonction de récupération des stages non prolongés . . . . . . . . . . . . . . . . . 100
A.4 Fonction de vérification de l’existance d’un rapport dans la base de données . . . 100
B.1 Lecture et envoi des e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.2 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
C.1 Code d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C.2 Code de génération du PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
x
Liste des tableaux
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Équipe et rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Description des machines de développement . . . . . . . . . . . . . . . . . . . . 22
4.1 Backlog du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Description textuelle du cas d’utilisation
« Ajouter un utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Description textuelle du cas d’utilisation
« Modifier un profil utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Types d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Test fonctionnel du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Backlog du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Description textuelle du cas d’utilisation
« Affecter candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Description textuelle du cas d’utilisation
« Afficher profil candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Test fonctionnel du deuxième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.5 Rétrospective du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.1 Backlog du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Description textuelle du cas d’utilisation
« Accepter d’encadrer » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3 Description textuelle du cas d’utilisation
« Accepter prise de fonction » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4 Test fonctionnel du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.5 Rétrospective du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1 Backlog du sprint4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
xi
Liste des tableaux
7.2 Description textuelle du cas d’utilisation
« Consulter liste demandes de prolongation » . . . . . . . . . . . . . . . . . . . 85
7.3 Description textuelle du cas d’utilisation
« Évaluer stagiaire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.4 Test fonctionnel du quatième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.5 Rétrospective du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
xii
Glossaires
— AJAX = Asynchronous JavaScript And XML
— BIAT = Banque Internationale Aarabe de Tunisie
— CSS = Cascading Style Sheets
— DC = Document Cloud
— DSI = Département du Systèmes d’Information
— HTML = HyperText Markup Language
— IMAP = Internet Message Access Protocol
— IT = Technologies de l’Information
— JS = Java Script
— MVC = Modèle Vue Contrôleur
— MoSCoW= Must Should Could Won’t
— NT = Nouvelle Technologie
— PDF = Portable Document Format
— PHP = Hypertext Preprocessor
— PL = Procedural Language
— RH = Ressources Humaines
— SASS = Syntactically Awesome StyleSheets
— SE = Système d’Exploitation
— SGBD = Système de Gestion de Base de Données
— SGBDR = Système de Gestion de Base de Données Relationnelle
— SI = Système Informatique
— SMTP = Mail Transfer Protocol
— SQL = Structured Query Language
— UC = Use Case
— UML = Unified Modeling Language
— URL = Uniform Resource Locator
Introduction générale
À l’époque actuelle, et grâce à l’évolution des nouvelles technologies d’information et de
communication, rares sont les personnes qui nient que la digitalisation des documents et la
diffusion de l’information en mode numérique améliorent la flexibilité et l’agilité des entreprises.
Dans cette perspective, la Banque internationale arabe de Tunisie (BIAT), s’est dit prête
à abandonner la manière archaïque de gestion manuelle des stages, et à s’investir afin d’avoir
une solution informatique permettant d’élargir les canaux de communication avec les stagiaires,
et de suivre régulièrement les nombreux changements effectués sur leurs candidatures, ce qui
permettra d’améliorer les conditions de travail au sein du service des ressources humaines. C’est
dans ce contexte que la direction d’ingénierie IT réseau et sécurité de la BIAT, nous a confié la
tâche de mise en place d’une solution permettant la dématérialisation du processus de gestion
des stagiaires, en réalisant une plate-forme qui collabore avec un service de messagerie, ce qui
permettra de simplifier le traitement des demandes des candidats envoyées sous la forme de
courriers électroniques.
Le présent rapport se subdivise en sept chapitres présentant les différents stades par lesquels
nous allons passer pour accomplir ce projet.
Le premier chapitre sert à situer le projet dans son contexte général, à savoir, l’organisme
d’accueil, la description des contraintes conduisant à l’élaboration de cette solution, ainsi que
la spécification de la méthodologie adaptée. Dans le second chapitre, nous allons dévoiler les
besoins métiers et nous allons mettre en place le backlog produit tout en le clôturant avec
une planification des sprints. Dans le troisième chapitre intitulé « Sprint 0 », nous allons nous
intéresser à la présentation de l’environnement de travail ainsi que l’architecture de notre projet.
C’est à ce niveau que nous allons exposer les choix techniques et la description du système « SI
Mailing ». Quand aux trois derniers chapitres, nous allons les consacrer à la présentation des
autres sprints de notre projet. Chaque sprint, comporte trois phases majeures : la phase de la
préparation, celle de la mise en oeuvre et celle dediée à la finalisation.
La dernière partie du rapport sera dédiée à la conclusion générale qui résume les grands
traits de ce travail et présente les perspectives futures de perfectionnement de la plate-forme
élaborée.
1
Chapitre 1
Cadre général du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Chapitre 1. Cadre général du projet
Introduction
Avant d’aborder l’étude approfondie de notre stage de fin d’études, nous allons décrire
brièvement à travers ce premier chapitre l’organisme au sein duquel se déroule notre stage.
Nous allons présenter par la suite une critique de l’existant afin de dévoiler notre solution
proposée, et pour clôturer, nous allons consacrer la dernière partie à la présentation de la
méthodologie adaptée pour la gestion de ce travail.
1.1 Organisme d’accueil
Au bout de quarante années d’existence, la banque internationale arabe de Tunisie « BIAT
», lancée le 24 février 1976, est devenue l’une des plus importantes institutions financières en
Afrique du Nord et un acteur de référence en Tunisie en termes de part de marché et de ré-
sultats financiers. Banque universelle offrant à sa clientèle de particuliers, tunisiens résidents à
l’étranger, professionnels, petites, moyennes, grandes entreprises et institutionnels, une gamme
de produits et services à la fois complète et innovante. La BIAT constitue aujourd’hui un groupe
bancaire diversifié dans les domaines de l’assurance, de la gestion d’actifs, du capital investisse-
ment, de l’intermédiation boursière et du conseil à l’international. Appuyant son développement
sur la proximité et l’engagement sociétal, elle met son expertise au profit de ses clients, de ses
partenaires et de l’économie du pays. [1]
Figure 1.1: Logo de la Banque Internationale Arabe de Tunisie BIAT [1]
1.1.1 Le Département des Systèmes d’information
La BIAT est constituée d’une direction générale qui comporte 11 départements ainsi que 4
pôles renfermant 41 directions. Et parmi ces départements, on trouve le département Systèmes
d’information (DSI), et plus précisément la direction ingénierie IT réseau et sécurité où notre
stage s’est déroulé.
Grâce à ses solutions proposées, Le DSI jouit d’une grande importance au sein de la banque,
il a comme objectifs de :
• Développer des solutions informatiques ;
3
Chapitre 1. Cadre général du projet
• Assurer la bonne planification des ressources, le partage des connaissances et l’enrichis-
sement des compétences ;
• Assurer en permanence la sécurité technique des systèmes informatiques ;
• Produire des applications destinées aux clients et aux différents services de la banque ;
• Exploitation de l’infrastructure informatique au sein de la BIAT.
1.1.2 Organigramme hiérarchique du DSI
Une hiérarchisation du DSI est illustrée dans la figure 1.2 suivante :
Figure 1.2: Organigramme hiérarchique du DSI
1.2 Étude de l’existant
1.2.1 Description de l’existant
Depuis ses débuts, la BIAT accueille plusieurs stagiaires de différentes spécialités pour ac-
complir soit un stage ouvrier, soit un stage de fin d’études dans le but de contribuer activement
à leurs formations.
Actuellement, il est nécessaire que les candidats se présentent au sein de la banque pour
postuler leurs demandes de stage sous la forme d’un dossier contenant un CV, une copier de la
CIN, ses relevés de notes, etc.
Ce dossier est traité, puis archivé par le responsable des ressources humaines dès que le
stagiaire termine son stage.
4
Chapitre 1. Cadre général du projet
Compte tenu de l’absence d’un outil informatique, la sélection des stagiaires et la gestion
de leurs candidatures se fait manuellement.
1.2.2 Problématique
La mission de gestion des stages au sein de la BIAT est devenue très compliquée vu le
nombre important des candidatures reçues.
Ainsi, nous avons recensé une liste de problèmes :
• Recherche fastidieuse des documents des stagiaires ;
• Consultation non périodique des candidatures ;
• Risque d’incohérence et de perte d’informations très élevé ;
• Ralentissement du suivi des stages ;
• Redondance de l’information ;
• Énorme perte de temps ;
• Absence des statistiques ;
• Classement des dossiers compliqué.
1.2.3 Solution proposée
Les problèmes dégagés lors de l’analyse de la situation actuelle rendent nécessaire l’élabo-
ration d’une solution informatisée afin de faciliter la gestion des stagiaires.
Cette solution consiste à développer une plate-forme de gestion collaborative, qui a comme
principaux objectifs :
• De faciliter l’accès et la consultation des informations de chaque stagiaire ;
• De faciliter le contact entre le responsable RH et les stagiaires en réalisant un système
permettant l’échange des e-mails ;
• De garder toujours une trace de chaque dossier et de chaque demande de stage, pour
pouvoir générer par la suite des statistiques.
Étant donné que les stagiaires ne doivent pas avoir un accès direct à la plate-forme pour
des raisons de sécurité, nous avons opté pour les courriers électroniques comme un outil de
communication.
5
Chapitre 1. Cadre général du projet
1.3 Méthodologie de travail
Une méthodologie est essentiellement un outil de planification qui aide à la mise en œuvre
d’un projet, elle nous fournit un cadre et des instructions précises pour gérer efficacement notre
équipe et assurer un bon déroulement des différentes phases du projet.
Pour réussir à mener à bien le processus de développement et par conséquent l’aboutissement
d’un bon résultat, il est important de suivre une méthodologie adaptée.
1.3.1 Le concept agile
Le choix d’une méthodologie appropriée dépend de nombreux paramètres tels que les ca-
ractéristiques du projet et ses contraintes. De ce fait, nous avons choisi d’adapter une méthode
incrémentale et itérative plutôt qu’une méthode classique, vu que le processus de la réalisation
de notre projet était imprévisible et nécessite les réorientations du Product Owner.
Parmi les méthodes basées sur le pragmatisme et le développement itératif, nous pouvons
distinguer les méthodes agiles très populaires en usage aujourd’hui à travers le monde. [2] Une
méthode agile définit un cadre moins rigide que les méthodes traditionnelles, elle met l’accent
sur la pratique de la réalisation du produit plus que sur la théorie, ce qui permet de détecter
les pénalités et les problèmes pour entreprendre des actions correctrices le plus tôt possible.
Grâce à l’agilité, on se retrouve aussi avec un focus sur la simplicité, l’intelligence collective
et également sur la communication et la collaboration concrétisées par la présence du client au
cœur du projet et par l’esprit d’équipe partagé par les acteurs métiers et les développeurs.
1.3.2 Présentation de la méthodologie Scrum
La méthode Scrum fait partie du groupe des méthodes agiles. Elle représente un Frame-
work de gestion et d’organisation de projets, reconnu pour sa flexibilité, son efficacité et son
empirique. L’utilisation de ce Framework vise à satisfaire au mieux les besoins du client en
s’appuyant sur plusieurs points :
La planification des événements :
• Le Sprint :
Il s’agit d’un incrément qui consiste à développer une partie du logiciel en une période
6
Chapitre 1. Cadre général du projet
inférieure à 30 jours. Durant cette itération l’équipe de développement se concentre sur
la réalisation les fonctionnalités demandées ;
• Planification du Sprint (Sprint Planning) :
Avant chaque sprint, une réunion de planification s’organise. Ce planning sélectionne dans
le backlog du produit les exigences les plus prioritaires pour le client ;
• Mêlée quotidienne (Daily Scrum Meetings) :
C’est une réunion quotidienne de 15 minutes qui vise à évaluer l’avancement du travail et
à garder l’équipe concentrée sur l’objectif du sprint ;
• Revue du Sprint (Sprint Review) :
À chaque fin de sprint, l’équipe présente l’incrément logiciel développé au client, celui-ci
valide les différents points du backlog et indique les changements à opérer ; [3]
• Rétrospective du Sprint (Sprint Retrospective) :
C’est une pratique qui permet d’améliorer l’équipe et le processus de développement quo-
tidiennement.
La définition des artefacts Scrum :
• Backlog du produit :
Il s’agit d’un référentiel des exigences et des fonctionnalités, fourni et tenu à jour par le
Product Owner ; [3]
• Backlog du sprint :
Un sous ensemble du backlog produit qui contient les fonctionnalités à mettre en oeuvre
durant le sprint ;
• Incrément du produit :
La sommation de toutes les fonctionnalités terminées pendant un sprint ;
• Le burndown chart du sprint(Sprint Burn-Down Chart) :
Diagramme indiquant les tâches restantes avant la fin du Sprint sur un axe du temps. [3]
La figure 1.3 présente une vue globale du cycle de vie de la méthodologie « Scrum ».
7
Chapitre 1. Cadre général du projet
Figure 1.3: Vue globale « Scrum » [4]
Conclusion
Après avoir présenté l’organisme d’accueil, introduire la solution proposée et expliquer la
méthodologie optée pour le travail, nous allons maintenant essayer de répondre à la question
« qui fait quoi dans le système et comment ? » qui fera l’objet du deuxième chapitre étude et
analyse globale du projet.
8
Chapitre 2
Étude et analyse globale du projet
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapitre 2. Étude et analyse globale du projet
Introduction
Au niveau de ce chapitre, nous allons aborder dans un premier temps la partie de la capture
des besoins, où nous allons identifier les différents acteurs et dégager les besoins fonctionnels
et non fonctionnels auxquels doit répondre notre solution. Dans un second temps, nous allons
modéliser toutes les fonctionnalités par un diagramme de cas d’utilisation global. Enfin, nous
allons piloter notre projet avec la méthodologie Scrum.
2.1 Capture des besoins
2.1.1 Identification des acteurs
Chaque système informatique met des fonctionnalités et des informations pertinantes à la
disposition de ses acteurs qui leur permettent d’interagir avec.
Ces acteurs peuvent être classés comme l’indique le tableau 2.1 :
Tableau 2.1: Identification des acteurs
Acteurs secondaires
SI Mailing Cet acteur n’interagit pas directement avec le système, mais sollicité
pour des informations complémentaires.
Acteurs principaux
Administrateur C’est l’acteur le plus haut dans la hiérarchie dans le système, il gère les
responsables et les encadrants en leur affectant les rôles nécessaires.
Responsable RH Cet acteur se charge principalement de gérer les stages en faisant l’étude
des demandes des stagiaires et des offres déposées par les encadrants.
Encadrant Cet acteur a pour rôle de déposer les offres de stage, d’accepter ou de
refuser les affectations et d’évaluer les stagiaires.
On peut présenter l’environnement de notre système et préciser le nombre d’instances de chacun
de ces acteurs par un diagramme de contexte statique illustré par la figure 2.1 ci-dessous.
10
Chapitre 2. Étude et analyse globale du projet
Figure 2.1: Diagramme de contexte statique
2.1.2 Identification des besoins fonctionnels
La phase de la spécification des besoins fonctionnels est indispensable pour que les résultats
de la réalisation de notre plate-forme soient conformes aux attentes du « Product owner ».
Ainsi, Les différentes fonctionnalités que nous envisageons de mettre en place dans le cadre
de ce projet, peuvent être regroupées dans les points suivants :
• Permettre aux encadrants de gérer les propositions d’encadrement, entre autres l’accep-
tation ou le refus d’une demande en attente ;
• Permettre aux administrateurs de gérer les utilisateurs et leur associer des privilèges ;
• Permettre à tous les utilisateurs de consulter les notifications ainsi que les statistiques ;
• Permettre aux responsables RH et aux encadrants de consulter les demandes refusées et
de visualiser leurs contenus ;
• Permettre aux responsables RH de traiter les différentes demandes reçues envoyées de la
part des stagiaires ;
• Permettre aux responsables RH de gérer les suggestions de stages des encadrants ;
• Permettre aux responsables RH d’accepter ou de refuser d’affecter un candidat ;
• Permettre aux encadrants de présélectionner des candidats dans le but de les encadrer ;
• Permettre aux chacun des encadrants et des responsables RH de consulter les stages
archivés et interrompus ;
• Permettre aux responsables RH d’accepter ou de refuser les demandes de prolongation
des encadrants ;
• Permettre aux encadrants de gérer les stages qu’ils encadrent et de suivre leurs avance-
ments ;
11
Chapitre 2. Étude et analyse globale du projet
• Permettre aux encadrants de déposer, de modifier ou de supprimer des offres de stage ;
• Permettre aux responsables RH de consulter toutes les offres de stages publiées.
2.1.3 Identification des besoins non fonctionnels
Les besoins non fonctionnels permettent l’amélioration de la qualité logicielle de notre sys-
tème. Ils agissent comme des contraintes à prendre en considération pour mettre en place une
solution adéquate à ce qui est attendu, et pour éviter plusieurs incohérences dans le système.
Notre application doit nécessairement répondre aux besoins suivants :
Convivialité :
L’application doit être facile à utiliser. Elle devra offrir des interfaces conviviales, simples et
ergonomiques.
Performance :
Vu l’ampleur des données qu’on va stocker, l’application doit répondre aux besoins des utili-
sateurs d’une manière optimale en termes de temps de réponse, de traitement et de chargement
des données.
Maintenabilité :
Le code doit être lisible, commenté et bien structuré afin d’obéir à l’évolution et aux différents
changements des besoins.
2.2 Modélisation des besoins
c Diagramme de cas d’utilisation global
Le diagramme illustré par la figure 2.2 décrit les différents besoins fonctionnels de notre
application, chaque cas d’utilisation représente une fonctionnalité offerte par le système à ses
utilisateurs.
12
Chapitre 2. Étude et analyse globale du projet
Figure 2.2: Diagramme de cas d’utilisation global
2.3 Pilotage du projet avec Scrum
2.3.1 Équipe et rôles
La méthodologie Scrum fait intervenir trois rôles principaux qui sont :
• Product owner : C’est le représentant des clients, il définit l’ordre dans lequel les
fonctionnalités seront développées ;
• Scrum Master : Il agit comme un « Coach » et non pas comme un dirigeant, son
rôle est d’aider l’équipe à avancer de manière autonome en cherchant en permanence à
s’améliorer ; [5]
• Équipe : l’équipe est constituée des personnes qui seront chargées d’implémenter les
13
Chapitre 2. Étude et analyse globale du projet
besoins du client. Elle doit tout faire pour délivrer le produit dans les délais prévus ;
• Intervenants : ils observent et donnent des conseils à l’équipe.
Ces participants sont illustrés par le tableau 2.2 :
Tableau 2.2: Équipe et rôles Scrum
Personnes Rôles Scrum
Mr. Mohamed BEHY Product Owner
Mr. Mohamed BEHY Scrum Master
ines HAMROUNI, yasmine LACHHEB Équipe
Mr. Riadh ZAAFRANI Intervenant
2.3.2 Backlog du produit
Le backlog du produit est l’artefact le plus important de Scrum, il consiste à présenter la
liste des fonctionnalités ou encore les « User Stories » constituant le produit souhaité. Chaque
fonctionnalité est caractérisée par un numéro ID, un thème, une priorité et une estimation de
l’effort nécessaire à une équipe pour l’implémenter. Nous choisissons de représenter l’estimation
sous la forme de points relatifs en utilisant la suite de Fibonnacci afin d’éviter les confusions
dues aux estimations trop proches et de représenter la priorité suivant la méthode « MoSCoW
» qui a pour signification :
• M : « Must have », toutes les fonctionnalités qui sont indispensables et nécessaires ;
• S : « Should have », les tâches qui sont essentielles, mais pas obligatoires, elles seront
développées une fois que celles de la catégorie Must ont été livrées ;
• C : « Could have », se sont des tâches qu’ont les fait seulement s’il reste assez de temps ;
• W : « Won’t have this time but would like in the future », se sont les tâches supplémen-
taires, très secondaires.
Le tableau 2.3 résume le backlog du produit de notre application.
14
Chapitre 2. Étude et analyse globale du projet
Tableau 2.3: Backlog produit
ID Théme ID User stories Priorité Estimation
1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais m’au-
thentifier pour accéder à mon espace.
M 8
2 Consulter
statistiques
2.1 En tant qu’Utilisateur je voudrais
consulter les statistiques.
S 3
3 Gérer utili-
sateurs
3.1 En tant qu’Administrateur je voudrais
consulter la liste des utilisateurs.
M 2
3.2 En tant qu’Administrateur je voudrais
consulter le profil d’un utilisateur.
S 2
3.3 En tant qu’Administrateur je voudrais
ajouter un profil utilisateur.
M 5
3.4 En tant qu’Administrateur je voudrais
modifier le profil d’un utilisateur.
M 5
3.5 En tant qu’Administrateur je voudrais
supprimer un utilisateur.
M 3
3.6 En tant qu’Administrateur je voudrais
trier la liste des utilisateurs.
W 1
3.7 En tant qu’Administrateur je voudrais
chercher un utilisateur.
C 1
4 Consulter
demandes
refusées
4.1 En tant que Personnel je voudrais
consulter la liste des demandes refusées
S 2
4.2 En tant que Personnel je voudrais
consulter le contenu d’une demande.
C 1
4.3 En tant que Personnel je voudrais cher-
cher une demande.
C 1
5 Consulter
stages archi-
vés
5.1 En tant que Personnel je voudrais
consulter la liste des stages archivés.
M 2
15
Chapitre 2. Étude et analyse globale du projet
5.2 En tant que Personnel je voudrais
consulter le profil d’un stagiaire archivé.
S 1
5.3 En tant que Personnel je voudrais impri-
mer les documents des stagiaires.
W 2
5.4 En tant que Personnel je voudrais cher-
cher un stage archivé.
C 1
6 Consulter
stages inter-
rompus
6.1 En tant que Personnel je voudrais
consulter la liste des stages interrompus.
S 2
6.2 En tant que Personnel je voudrais
consulter le profil du stagiaire inter-
rompu
C 1
7 Traiter
demandes
reçues
7.1 En tant que Responsable RH je voudrais
consulter la liste des demandes non trai-
tées
M 2
7.2 En tant que Responsable RH je voudrais
consulter le contenu d’une demande re-
çue.
M 5
7.3 En tant que Responsable RH je voudrais
affecter un candidat à un sujet.
M 3
7.4 En tant que Responsable RH je voudrais
refuser un candidat.
M 2
7.5 En tant que Responsable RH je voudrais
actualiser la liste des demandes reçues.
M 13
7.6 En tant que Responsable RH je voudrais
télécharger un document du dossier can-
didat.
C 3
7.7 En tant que Responsable RH je voudrais
chercher une demande.
C 1
8 Gérer sug-
gestions
8.1 En tant que Responsable RH je voudrais
consulter les demandes suggérées.
M 2
16
Chapitre 2. Étude et analyse globale du projet
8.2 En tant que Responsable RH je voudrais
consulter le profil d’un stagiaire.
S 1
8.3 En tant que Responsable RH je voudrais
accepter une suggestion d’affectation.
M 5
8.4 En tant que Responsable RH je voudrais
refuser une suggestion d’affectation.
M 2
9 Gérer affec-
tations
9.1 En tant que Responsable RH je voudrais
consulter la liste des demandes suivies.
M 13
9.2 En tant que Responsable RH je voudrais
chercher une demande.
C 1
9.3 En tant que Responsable RH je voudrais
trier les demandes.
W 1
9.4 En tant que Responsable RH je voudrais
visualiser le dossier d’un stagiaire.
S 2
9.5 En tant que Responsable RH je voudrais
accepter une prise de fonction.
M 8
9.6 En tant que Responsable RH je voudrais
refuser une prise de fonction.
M 3
10 Présélectionner
candidat
10.1 En tant qu’Encadrant je voudrais
consulter la liste des candidatures re-
çues.
M 2
10.2 En tant qu’Encadrant je voudrais
consulter le profil d’un candidat.
M 2
10.3 En tant qu’Encadrant je voudrais choisir
un candidat.
M 3
10.4 En tant qu’Encadrant je voudrais cher-
cher un candidat.
C 1
11 Gérer propo-
sitions d’en-
cadrement
11.1 En tant qu’Encadrant je voudrais
consulter la liste des demandes en at-
tente.
M 2
17
Chapitre 2. Étude et analyse globale du projet
11.2 En tant qu’Encadrant je voudrais trier
les demandes en attente.
W 1
11.3 En tant qu’Encadrant je voudrais cher-
cher un candidat.
C 1
11.4 En tant qu’Encadrant je voudrais affi-
cher le profil d’un stagiaire .
S 1
11.5 En tant qu’Encadrant je voudrais accep-
ter d’encadrer un candidat.
M 5
11.6 En tant qu’Encadrant je voudrais refuser
d’encadrer un candidat .
M 3
12 Gérer pro-
longations
12.1 En tant que Responsable RH je voudrais
consulter la liste des demandes de pro-
longation.
M 2
12.2 En tant que Responsable RH je voudrais
consulter les stages prolongés.
M 2
12.3 En tant que Responsable RH je voudrais
consulter les stages non prolongés.
M 2
12.4 En tant que Responsable RH je voudrais
consulter le dossier d’un stagiaire cou-
rant.
S 1
12.5 En tant que Responsable RH je voudrais
télécharger un document du dossier sta-
giaire.
C 2
12.6 En tant que Responsable RH je voudrais
accepter une prolongation.
M 2
12.7 En tant que Responsable RH je voudrais
refuser une prolongation.
M 2
13 Gérer stages
encadrés
13.1 En tant qu’Encadrant je voudrais
consulter les stages en cours d’encadre-
ment.
M 2
18
Chapitre 2. Étude et analyse globale du projet
13.2 En tant qu’Encadrant je voudrais cher-
cher un stage.
C 1
13.3 En tant qu’Encadrant je voudrais
consulter le dossier d’un stagiaire.
S 1
13.4 En tant qu’Encadrant je voudrais inter-
rompre un stage.
M 2
13.5 En tant qu’Encadrant je voudrais de-
mander une prolongation de stage.
M 3
13.6 En tant qu’Encadrant je voudrais éva-
luer un stagiaire.
M 8
14 Gérer sujets
stages
14.1 En tant qu’Encadrant je voudrais
consulter la liste des sujets
M 2
14.2 En tant qu’Encadrant je voudrais cher-
cher un sujet.
C 1
14.3 En tant qu’Encadrant je voudrais ajou-
ter un sujet.
M 3
14.4 En tant qu’Encadrant je voudrais modi-
fier un sujet.
M 3
14.5 En tant qu’Encadrant je voudrais sup-
primer un sujet.
M 2
15 Consulter
notifications
15.1 En tant qu’Utilisateur je voudrais
consulter les notifications reçues
C 5
16 Consulter
offres de
stage
16.1 En tant que Responsable RH je voudrais
consulter les offres proposées.
M 2
16.2 En tant que Responsable RH je voudrais
consulter le contenu d’une offre propo-
sée.
M 2
19
Chapitre 2. Étude et analyse globale du projet
2.3.3 Planification des sprints
La réunion de la planification des sprints est l’un des évènements Scrum le plus important,
puisqu’elle rythme tout le projet et sert à bien dérouler les différents sprints.
À travers cette réunion, nous évoquons le planning de notre travail qui s’est étalé sur une
période de trois mois avec une estimation de deux à trois semaines pour chaque sprint.
La Figure 2.3 représente l’estimation théorique des différents sprints.
Figure 2.3: Estimation théorique des sprints
Conclusion
Tout au long de ce chapitre, nous avons détaillé les différents besoins ainsi que l’interaction
des acteurs avec le système. Par la suite nous avons choisi d’identifier l’équipe de travail et
de définir notre backlog du produit qui nous a permis de préparer un terrain favorable pour
les prochaines phases et de déduire la planification des sprints de notre plate-forme. Dans le
chapitre suivant, nous allons commencer par le sprint0 qui présente notre environnement de
travail et décrit notre acteur système « SI Mailing ».
20
Chapitre 3
Sprint0 : Mise en place de
l’environnement matériel et logiciel
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
Introduction
Ce chapitre est consacré à la présentation de l’architecture matérielle et logicielle de notre
application, des différents outils qui constituent l’environnement de travail et des différentes
technologies que nous allons utiliser tout au long de ce projet. Quant à la dernière partie, elle
sera dédiée à la description de l’élaboration du système «SI Mailing», jouant le rôle d’un acteur
secondaire.
3.1 Environnement materiel
Nous allons identifier dans le tableau 3.1 les outils matériels utilisés pour la réalisation de
notre plate-forme :
Tableau 3.1: Description des machines de développement
Ordinateur portable Lenovo
Processeur Intel R CoreTM
i7-7500U CPU @ 2.70GHz 2.90GHz
Mémoire 8,00 Go
Disque dur 1 To
Circuit graphique NVIDIA R GeForce R 940MX
Système d’exploitation Windows 10 Entreprise 64 bit
Ordinateur portable Asus
Processeur Intel R CoreTM
i7-5500U CPU @ 2.40GHz 2.40GHz
Mémoire 8,00 Go
Disque dur 1 To
Circuit graphique NVIDIA R GeForce R 920M
Système d’exploitation Windows 10 Entreprise 64 bit
22
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
3.2 Environnement logiciel
3.2.1 Système d’exploitation
c Windows 10
Le successeur de Windows 8.1 est un SE de la famille Windows NT
développé par la société américaine Microsoft. [6]
3.2.2 Outils de développement
c PhpStorm
Est un éditeur performant destiné pour PHP, HTML et JS, édité
par JetBrains. Il simplifie l’écriture du code, l’intégration d’un dé-
bogueur et l’interfaçage avec un outil de gestion de versions ou
d’administration de bases de données.
c Oracle SQL Developer
Un environnement de développement intégré multiplate-forme,
fourni gratuitement par Oracle Corporation et utilisant la tech-
nologie Java. C’est un outil graphique permettant d’interroger des
bases de données Oracle à l’aide du langage SQL. [7]
c ShareLaTeX
Un éditeur LaTeX en ligne, permet de créer et de partager un
document latex en temps réel et de le compiler en PDF.
23
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
3.2.3 Outil de conception
c Visual Paradigm for UML
Est un logiciel permettant aux programmeurs de mettre en place
des diagrammes UML. Disposant d’un outil créant des différents
types de schémas comme les diagrammes de cas d’utilisation, de
séquences et plein d’autres diagrammes. [8]
3.2.4 Outil de gestion de versions
c Bitbucket
Est un service web d’hébergement et de gestion de développement
logiciel utilisant les logiciels de gestion de versions Git. Il permet de
mieux collaborer en distribuant les fichiers à chaque développeur
et en sauvegardant l’historique de chaque modification. [9]
3.2.5 Outil de manipulation des documents électroniques
c Adobe Acrobat DC
Est une famille de logiciels mis au point par Adobe, il permet de
manipuler des documents électroniques au format PDF, de gérer
les processus de signatures électroniques et de créer et numériser
des formulaires interactifs.
3.2.6 Environnement de Système de Gestion de Base de Données
c Oracle Database 11g
Est un SGBD relationnel édité par la société Oracle Corporation,
leader mondial des bases de données. Il permet d’assurer la dé-
finition et la manipulation, la sauvegarde et la restauration des
données ainsi que la gestion des accès concurrents.
24
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
3.3 Archiecture du projet
3.3.1 Architecture matérielle
Le choix de l’architecture physique est d’une importance primordiale, il influencera la per-
formance du système.
C’est pour cette raison, que nous optons pour une séparation de notre plate-forme en diffé-
rentes couches. Nous parlons dans ce cas du modèle multi-tiers plus précisément l’architecture
3 tiers qui est également une extension du modèle Client/Serveur.
En utilisant cette architecture, le système est divisé en trois parties dont le rôle de chacune
est défini comme suit :
• Couche présentation
Elle correspond à la partie visible de l’application , appelée Interface Homme Machine.
Son rôle est de réassembler les services offerts par la couche inférieure et les afficher à
l’utilisateur ;
• Couche métier
Appelé aussi Business, c’est la couche qui exécute la logique métier, elle offre des services
à la couche présentation en utilisant les données accessibles à travers la couche inférieure
d’accès aux données ;
• Couche d’accès aux données
Elle correspond au serveur de la base de données. Sur ce troisième tiers, un SGBD est
installé. Nous avons dans notre cas utilisé le SGBDR, ORACLE 11g, qui a pour rôle de
stocker les données indépendamment de la logique applicative.
Figure 3.1: l’architecture 3-tiers de notre application
25
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
3.3.2 Architecture logicielle
L’une des étapes importantes dans le processus de la mise en œuvre d’une application est
le choix adéquat d’un motif de conception puisqu’il facilite la communication, fait gagner en
terme de rapidité et diminue d’une manière éminente les coûts.
Dans ce projet, nous avons opté pour le patron de conception MVC. Son principal intérêt
est la séparation des responsabilités en divisant l’interface graphique d’un programme en trois
entités distinctes ayant chacune un rôle précis lors du traitement de l’information, ce qui rend
l’application plus maintenable et plus évolutive.
Les rôles des trois entités sont les suivants : [10]
• Le modèle : Contient les données manipulées par le programme. Il assure la gestion de
ces données et garantit leur intégrité ;
• La vue : Fait l’interface avec l’utilisateur. Son premier rôle est d’afficher les données
qu’elle a récupéré auprès du modèle et son second rôle est de recevoir toutes les actions
de l’utilisateur. Ses différents événements sont envoyés au contrôleur ;
• Le contrôleur : Chargé de la synchronisation du modèle et de la vue. Il reçoit tous les
événements de l’utilisateur et dénclenche les actions à effectuer.
Figure 3.2: Architecture MVC
26
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
3.4 Choix techniques
c AJAX
Repose sur un ensemble de technologies tels que javascript, xml,
json, html et les requêtes http, destinées à réaliser des transferts
de données et de rapides mises à jour du contenu d’une page Web,
sans procéder au rechargement total de la page.
c Bootstrap
Bootstrap est une collection d’outils utiles à la création du design
des sites et d’applications web. C’est un ensemble qui contient des
codes HTML, CSS ainsi que des extensions JavaScript en option.
[11]
c jQuery
Est un Framework développé en JavaScript, il possède une librairie
qui propose les fonctionnalités de gestion des évènements, d’anima-
tion et de manipulation des feuilles de style.
c HTML5
Un langage de balisage conçu pour représenter des pages web. Son
principal intérêt est le formatage de l’écriture d’un document avec
des balises.
c CSS3
Un langage informatique qui permet de décrire la mise en page des
documents HTML dans le but d’améliorer leur aspect ergonomique
et décoratif.
27
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
c Sass
Un langage de génération de feuilles de style, basé en grande partie
sur CSS3, en ajoutant de nouvelles règles telles que l’utilisation des
variables et la création des fonctions.
c PHP
PHP est un langage de script, utilisé pour produire des pages Web
dynamiques via un serveur http. il offre des nombreuses possibilités
telles que la gestion des sessions utilisateurs, la gestion de fichiers
PDF, la gestion des e-mails en POP et IMAP et le cryptage MD5
et SHA1 [12]
c PL/SQL
Basé sur les paradigmes de programmation procédurale et struc-
turée. Créé par Oracle et utilisé dans le cadre de bases de données
relationnelles. [13]
c UML
Un langage de modélisation unifié qui s’utilise généralement pour
la conception orientée objet. Il est constitué d’un ensemble de dia-
grammes, leur principal rôle est de présenter les logiciels à déve-
lopper sous une forme graphique.
3.5 Description du système « SI Mailing »
Nous consacrons cette section pour montrer la réalisation du système « SI mailing » déclaré
dans la partie précédente comme étant un acteur secondaire interagissant avec notre système
général.
Le recours à l’implémentation de ce système était notre solution pour remédier au problème
de l’extraction des données à partir des pièces-jointes envoyées par les stagiaires sous la forme
d’e-mails.
28
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
Ce système permet aussi de concrétiser le processus d’envoi et de lecture des courriers
électroniques ainsi que la récupération des attachements en utilisant les deux protocoles SMTP
et IMAP.
3.5.1 Protocoles de messagerie utilisés
c SMTP
Entre l’utilisateur et son serveur, l’envoi des e-mails sur les réseaux se fait à l’aide du proto-
cole SMTP. Et pour assurer ce transfert, nous avons eu recours à la bibliothèque « PHPMailer
» disponible en PHP qui fournit une collection de fonctions facilitant la construction et la
génération des e-mails.
c IMAP
Pour amener à bien le processus de la lecture des e-mails et arriver à accéder aux différents
courriers électroniques envoyés de la part des stagiaires, nous avons travaillé avec des fonctions
PHP qui utilisent le protocole IMAP.
Le schéma representé par la figure 3.3 illustre le fonctionnement des protocoles présentés
ci-dessus.
Figure 3.3: Principe des échanges de messages électroniques [14]
3.5.2 PDF interactif
Tous les problèmes rencontrés lors de la recherche d’une solution pour que le candidat puisse
nous envoyer ses informations sans avoir un accès direct à la plate-forme nous ont amenés à
29
Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel
utiliser un formulaire sous la forme d’un PDF interactif. Le formulaire doit être rempli par
chaque candidat, et envoyé par e-mail, dans le but d’en extraire toutes les données nécessaires.
Nous montrons ci-dessous à travers la figure 3.4 notre PDF interactif.
Figure 3.4: PDF interactif
Conclusion
Dans ce chapitre nous avons présenté l’environnement matériel et logiciel que nous avons
préparé pour la mise en place de notre système, l’architecture physique et logicielle, les différents
choix techniques ainsi que le système « SI Mailing ». Dans le chapitre suivant, nous allons
entamer le premier pas de la réalisation du projet : le sprint1.
30
Chapitre 4
Sprint1 : Authentification et gestion
des utilisateurs et des offres
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 32
2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 33
3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 45
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Introduction
Le présent chapitre consiste à décrire les différentes étapes de la réalisation du premier
sprint. En premier lieu, nous allons évoquer les histoires utilisateurs. En second lieu, nous
allons exposer les différents diagrammes d’analyse et de conception et par la suite, nous allons
présenter la phase de réalisation ainsi que les scénarios de test.
4.1 Phase de pré-jeu : préparation
4.1.1 But
Le but de ce premier sprint consiste à mettre en œuvre le processus d’authentification qui
à son tour déclenche l’accomplissement de la fonctionnalité gestion des utilisateurs avec leurs
différents privilèges. Ce sprint vise aussi à mettre en place la fonctionnalité de la gestion des
offres de stages qui sont proposées par l’encadrant et consultables par le responsable RH.
4.1.2 Backlog du sprint
Nous présentons à travers le tableau 4.1 le Backlog de ce sprint ainsi que l’estimation d’effort
par jour de chaque fonctionnalité à réaliser.
Tableau 4.1: Backlog du sprint1
ID Théme ID User stories Effort
1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais
m’authentifier pour accéder à mon es-
pace.
5j
3 Gérer utilisateurs 3.1 En tant qu’Administrateur je vou-
drais consulter la liste des utilisa-
teurs.
1j
3.2 En tant qu’Administrateur je vou-
drais consulter le profil d’un utilisa-
teur.
1j
3.3 En tant qu’Administrateur je vou-
drais ajouter un profil utilisateur.
1.5j
32
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
3.4 En tant qu’Administrateur je vou-
drais modifier le profil d’un utilisa-
teur.
1.5j
3.5 En tant qu’Administrateur je vou-
drais supprimer un utilisateur.
0.5j
3.6 En tant qu’Administrateur je vou-
drais trier la liste des utilisateurs.
0.25j
3.7 En tant qu’Administrateur je vou-
drais chercher un utilisateur.
0.25j
14 Gérer sujets stages 14.1 En tant qu’Encadrant je voudrais
consulter la liste des sujets.
1j
14.2 En tant qu’Encadrant je voudrais
chercher un sujet.
0.25j
14.3 En tant qu’Encadrant je voudrais
ajouter un sujet.
1.5j
14.4 En tant qu’Encadrant je voudrais mo-
difier un sujet.
1.5j
14.5 En tant qu’Encadrant je voudrais
supprimer un sujet.
0.5j
16 Consulter offres de stage 16.1 En tant que Responsable RH je vou-
drais consulter les offres proposées.
1j
16.2 En tant que Responsable RH je vou-
drais consulter le contenu d’une offre
proposée.
1j
4.2 Phase de jeu : mise en oeuvre
4.2.1 Modélisation fonctionnelle
Les besoins à réaliser dans notre premier sprint, ont été spécifiés. Nous passons maintenant à
la présentation des diagrammes de cas d’utilisation qui ont pour but de donner une vue globale
33
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
sur l’ensemble des fonctionnalités fournies par l’application, ainsi que les descriptions textuelles
qui décrivent les scénarios de chaque cas.
4.2.1.1 Diagramme de cas d’utilisation global du sprint1
Figure 4.1: Diagramme de cas d’utilisation global du sprint1
4.2.1.2 Raffinement du cas d’utilisation « Gérer utilisateurs »
Pour gérer les utilisateurs, un administrateur a la possibilité d’effectuer les fonctionnalités
modélisées dans la figure 4.2 ci-dessous.
Figure 4.2: Raffinement du cas d’utilisation « Gérer utilisateurs »
34
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
– Description textuelle du cas d’utilisation « Ajouter un utilisateur »
La description textuelle représentée dans le tableau 4.2 montre le scénario du cas cas d’uti-
lisation « Ajouter un utilisateur » illustré dans la figure 4.2.
Tableau 4.2: Description textuelle du cas d’utilisation
« Ajouter un utilisateur »
Sommaire
Titre : Ajouter un profil utilisateur
Auteur : Administrateur
Description d’enchaînement
Pré-conditions : Authentification et consultation de la liste des utilisateurs
Post-conditions : Profil utilisateur ajouté
Scénario Nominal
1. L’administrateur demande d’ajouter un nouveau profil ;
2. Le système récupère les informations des utilisateurs existants à partir de l’annuaire ;
3. Le système affiche les informations au niveau du formulaire à remplir ;
4. L’administrateur saisit les informations demandées pour l’ajout et confirme l’opé-
ration par un clic sur le bouton « Enregistrer » ;
5. Le système valide le nom utilisateur et le mot de passe et ajoute les informations ;
6. Si valide, le système affiche un message de succès ;
7. FIN.
Scénario Alternatif
1. Si l’administrateur entre des données erronées ;
a. GOTO 3.
2. Si l’utilisateur existe déjà ;
a. le système affiche un message d’avertissement ;
b. GOTO 3.
Scénario d’exceptions
35
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
1. Si l’administrateur ne confirme pas ou annule l’opération d’ajout en cliquant sur le
bouton « Annuler » ;
a. GOTO FIN.
– Description textuelle du cas d’utilisation « Modifier un profil utilisateur »
La description textuelle représentée dans le tableau 4.3 illustre le scénario du cas d’utilisation
« Modifier un profil utilisateur » modélisé dans la figure 4.2.
Tableau 4.3: Description textuelle du cas d’utilisation
« Modifier un profil utilisateur »
Sommaire
Titre : Modifier un profil utilisateur
Auteur : Administrateur
Description d’enchaînement
Pré-conditions : Authentification et consultation de la liste des utilisateurs
Post-conditions : Profil utilisateur modifié
Scénario Nominal
1. L’administrateur choisit le profil qu’il veut modifier ;
2. Le système récupère et affiche les informations du profil utilisateur choisi ;
3. L’administrateur modifie les données et confirme par un clic sur le bouton « Enre-
gistrer » ;
4. Le système valide l’opération et affiche un message de succès de modification ;
5. FIN.
Scénario Alternatif
1. Si l’administrateur n’a pas renseigné au moins un champ ;
a. Le système affiche un message d’avertissement ;
b. GOTO 2.
Scénario d’exceptions
36
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
1. Si l’administrateur refuse de continuer l’opération de modification et l’annule ;
a. GOTO FIN.
4.2.2 Conception
En se basant sur les fonctionnalités modélisées dans la section précédente, nous allons passer
à la conception détaillée des cas d’utilisation principaux. Dans un premier temps, nous allons
élaborer les diagrammes de séquences de quelques cas d’utilisation afin de clarifier le déroule-
ment des événements. Dans un second temps, nous allons détailler le diagramme de classes du
sprint, qui va nous amener au schéma relationnel de notre base de données.
4.2.2.1 diagrammes de séquences détaillés
Pour une bonne compréhension des composantes du premier sprint, il est indispensable
de présenter les diagrammes de séquences des principaux cas d’utilisation. Ces diagrammes
décrivent les scénarios de chaque cas en mettant l’accent sur le facteur chronologique, ainsi que
l’interaction entre les différents objets qui le constituent.
On peut distinguer trois types d’objets illustrés par le tableau 4.4 ci-dessous :
Tableau 4.4: Types d’objets
« Boundary » Représente l’interface affichée à l’utilisateur
« Control » Assure la communication entre le modèle et la vue.
« Model » Représente la persistance des données auprès du système.
– Diagramme de séquence du cas d’utilisation « S’authentifier »
Dans le diagramme de la figure 4.4 ci-dessous, nous détaillons l’interaction entre les utilisa-
teurs et les composants du système afin de pouvoir s’authentifier.
37
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.3: Diagramme de séquence du cas d’utilisation « S’authentifier »
– Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur »
Dans le diagramme de la figure 4.4 ci-dessous, nous détaillons l’interaction entre l’adminis-
trateur et les composants du système utilisés au cours de l’ajout d’un utilisateur.
38
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.4: Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur »
– Diagramme de séquence du cas d’utilisation « Modifier un utilisateur »
Dans le diagramme de la figure 4.5 ci-dessous, nous détaillons l’interaction entre l’adminis-
trateur et les composants du système utilisés au cours de la modification.
39
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.5: Diagramme de séquence du cas d’utilisation « Modifier un utilisateur »
4.2.2.2 diagramme de classes
Le diagramme de séquence présenté dans la partie précédente nous a permis de voir une vue
dynamique de notre système, et afin de pouvoir présenter les différentes entités qui le composent
avec leurs différentes relations d’une manière statique nous avons consacré cette partie pour
définir un diagramme faisant partie des diagrammes structurels d’Uml qui est le diagramme de
classes illustré par la figure 4.6 ci-dessous.
40
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.6: Diagramme de classes du sprint 1
4.2.3 Réalisation
Après avoir présenté la solution conceptuelle, nous exploitons dans ce qui suit le fruit de
notre travail en exposant les différentes interfaces les plus significatives, relatives à ce premier
sprint.
41
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
c Interface d’authentification
Nous commençons par présenter la première interface commune à tous les acteurs de notre
système, celle relative à l’authentification, avec laquelle tous les utilisateurs sont appelés à in-
troduire leurs noms d’utilisateur et leurs mots de passe pour pouvoir accéder chacun à son
espace personnel.
Si les informations sont invalides, le système affiche un message d’erreur, et en cas d’une ten-
tative d’accès à une page de la plateforme via l’URL sans aucune identification, il fait une
redirection automatique vers la page d’authentification (figure 4.7).
Figure 4.7: Interface d’authentification
c Interfaces des listes des utilisateurs et des offres
L’administrateur peut gérer les différents profils disponibles en accédant à la liste des uti-
lisateurs à travers l’interface 4.8, tandis que l’encadrant a la main de gérer et d’examiner la
liste de ses offres présentée dans la figure 4.9. Chacun d’entre eux a la possibilité de faire une
recherche ou un trie sur sa liste selon un critère souhaité.
42
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.8: Interface de la liste des utilisateurs
Figure 4.9: Interface de la liste des offres
c Interface d’ajout d’un utilisateur
Pour ajouter un nouvel utilisateur, l’administrateur clique en premier lieu sur l’icône d’ajout
présentée dans la figure 4.8. Dès que le pop-up s’affiche, ce dernier sélectionne un personnel
parmi ceux qui sont disponibles et remplit par la suite toutes les informations indiquées dans
le formulaire présenté par l’interface 4.10.
43
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Figure 4.10: Interface d’ajout d’un utilisateur
c Interface de modification d’une offre de stage
Dans le cadre de la gestion des offres, un encadrant a le droit de modifier un sujet. La figure
4.11 indique l’interface du pop-up affichant les informations de l’offre à modifier.
Figure 4.11: Interface de modification d’une offre de stage
44
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
c Interfaces du contenu d’un profil utilisateur et d’une offre
À travers les deux interfaces des figures 4.12 et 4.13 ci-dessous, un administrateur a la
possibilité de consulter le profil d’un utilisateur et tout encadrant peut afficher le contenu
d’une offre déjà publiée.
Figure 4.12: Interface d’un profil
utilisateur
Figure 4.13: Interface du contenu d’une
offre
4.3 Phase de post-jeu : finalisation
Après la réalisation du premier sprint, nous passons maintenant à la présentation des tâches
de finalisation. Nous présentons ici l’avancement du travail pour savoir si nous avons pu at-
teindre les objectifs définis et de se préparer pour le sprint suivant.
4.3.1 Test fonctionnel
Il s’agit dans cette section de mettre l’action sur quelques cas de scénarios de tests fonc-
tionnels relatifs au premier sprint en les présentant dans le tableau 6.4 suivant :
Tableau 4.5: Test fonctionnel du premier sprint
Cas de test Démarche Comportement attendu Résultat
Test d’authentifica-
tion
Après l’accès à l’interface
d’authentification, l’utili-
sateur entre ses coordon-
nées et valide.
Redirection vers la page d’ac-
cueil si l’utilisateur existe. Si-
non un message d’erreur s’af-
fiche.
Conforme
45
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Test d’ajout d’un
profil utilisateur
Après l’accès à la liste
des utilisateurs, l’admi-
nistrateur saisit les don-
nées d’un profil et clique
sur le bouton « Enregis-
trer ».
Si le profil utilisateur est déjà
existant, un message d’erreur
d’ajout s’affiche, sinon un mes-
sage succès apparaît.
Conforme
Test de modifica-
tion d’une offre de
stage
Après l’accès à la liste des
offres, l’encadrant sélec-
tionne le sujet à modifier
et clique sur le l’icône de
modification.
Un formulaire contenant les
données du sujet sélectionné
s’affiche dans un pop-up. Dès
sa confirmation, les informa-
tions modifiées s’enregistrent
et un message de succès de mo-
dification s’affiche.
Conforme
Test de suppression
d’une offre de stage
Après l’accès à la liste des
offres, l’encadrant choi-
sit le sujet à supprimer
en cliquant sur l’icône de
suppression.
Un pop-up de confirmation ap-
paraît. Si l’encadrant confirme
l’opération, un message de suc-
cès s’affiche, sinon, en cas d’an-
nulation, le système effectue
une redirection vers la liste des
offres.
Conforme
4.3.2 Rétrospective du sprint 1
Après avoir fait la revue du sprint et la vérification des différentes fonctionnalités demandées,
nous présentons dans ce qui suit l’évaluation de cet incrément à travers le tableau 4.6.
46
Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres
Tableau 4.6: Rétrospective du sprint 1
Rétrospective du sprint 1
Ce qui a bien fonctionné
• Authentification ;
• Ajouter un(e) utilisateur / offre ;
• Modifier un(e) utilisateur / offre ;
• Supprimer un(e) utilisateur / offre ;
• Consulter un profil utilisateur ;
• Consulter un sujet ;
• Chercher un utilisateur / sujet ;
• Consulter une offre de stage ;
• Consulter la liste des offres de stages.
Ce qui n’a pas bien fonctionné rien à mentionner
Ce qui doit être amélioré rien à mentionner
Conclusion
À travers ce chapitre, nous avons présenté la spécification des besoins, la conception illustrée
par des diagrammes de séquences détaillés et un diagramme de classes ainsi que la réalisation
des histoires utilisateurs du premier sprint.
Après avoir testé et validé les fonctionnalités avec le Scrum Master et le Product Owner au
cours de la revue du sprint, nous allons maintenant attaquer la prochaine étape : le sprint 2
47
Chapitre 5
Sprint2 : Traitement des
candidatures des stagiaires
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 49
2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 50
3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 63
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Introduction
Après avoir entamé le premier sprint de notre système, nous allons maintenant passer à la
présentation de notre deuxième sprint. Tout au long de ce chapitre, nous allons nous intéresser
à la phase du traitement des candidatures des stagiaires. Tout d’abord, nous allons présenter la
première phase de préparation, celle de la réalisation et nous allons terminer enfin par la partie
de la finalisation et des tests fonctionnels.
5.1 Phase de pré-jeu : préparation
5.1.1 But
En partant du même principe que le sprint précédent, nous commençons par définir le but
de notre deuxième sprint, qui consiste à mettre en œuvre le processus du « traitement des
candidatures des stagiaires ».
Ce sprint est le plus important et le plus complexe, car il contient les fonctionnalités prin-
cipales du projet, où on doit réaliser le traitement des candidatures ainsi que le processus de la
consultation des notifications.
5.1.2 Backlog du sprint
Avant de commencer le travail, nous allons identifier dans cette partie les fonctionnalités à
réaliser durant cet incrément.
Le tableau 5.1 ci-dessous résume donc le backlog de notre deuxième sprint.
Tableau 5.1: Backlog du sprint2
ID Théme ID User stories Effort
15 Consulter notifications 15.1 En tant qu’Utilisateur je voudrais
consulter les notifications reçues.
2j
7 Traiter demandes reçues 7.1 En tant que Responsable RH je vou-
drais consulter la liste des demandes
non traitées.
1j
7.2 En tant que Responsable RH je vou-
drais consulter le contenu d’une de-
mande reçue.
2j
49
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
7.3 En tant que Responsable RH je vou-
drais affecter un candidat à un sujet.
1j
7.4 En tant que Responsable RH je vou-
drais refuser un candidat.
0.5j
7.5 En tant que Responsable RH je vou-
drais actualiser la liste des demandes
reçues.
5j
7.6 En tant que Responsable RH je vou-
drais télécharger un document du
dossier candidat.
1j
7.7 En tant que Responsable RH je vou-
drais chercher une demande.
0.25j
10 Présélectionner candi-
dats
10.1 En tant qu’Encadrant je voudrais
consulter la liste des candidatures re-
çues.
1j
10.2 En tant qu’Encadrant je voudrais
consulter le profil d’un candidat.
1j
10.3 En tant qu’Encadrant je voudrais
choisir un candidat.
1j
10.4 En tant qu’Encadrant je voudrais
chercher un candidat.
1.25
5.2 Phase de jeu : mise en oeuvre
5.2.1 Modélisation fonctionnelle
La Figure 5.1 ci-dessous, représente le diagramme de cas d’utilisation global qui modélise
les fonctionnalités spécifiques à ce sprint. Et afin de mieux les assimiler nous établissons les
raffinements nécessaires qui nous conduisent vers les descriptions textuelles.
50
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
5.2.1.1 Diagramme de cas d’utilisation global du sprint2
Figure 5.1: Diagramme de cas d’utilisation global du sprint2
5.2.1.2 Raffinement du cas d’utilisation « Traiter demandes reçues »
Afin de traiter les demandes reçues, chaque responsable RH a la possibilité de visualiser la
liste des demandes non traitées, de l’actualiser et d’effectuer toutes les fonctionnalités modélisées
dans la figure 5.2 ci-dessous.
Figure 5.2: Raffinement du cas d’utilisation « Traiter demandes reçues »
– Description textuelle du cas d’utilisation « Affecter candidat »
La description textuelle représentée dans le tableau 5.2 illustre le scénario du cas d’utilisation
« Affecter candidat » modélisé dans la figure 5.2.
51
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Tableau 5.2: Description textuelle du cas d’utilisation
« Affecter candidat »
Sommaire
Titre : Affecter candidat
Auteur : Responsable RH
Description d’enchaînement
Pré-conditions : Authentification, visualiser la liste des demandes non traitées et
consulter le contenu d’une demande
Post-conditions : Candidat affecté
Scénario Nominal
1. Le cas d’utilisation commence lorsque le responsable RH décide d’affecter un sta-
giaire en cliquant sur le bouton « Affecter » ;
2. Le système récupère la liste des sujets disponibles et la met à la disposition du
responsable RH à travers une vue d’affectation renfermant un formulaire ;
3. Le responsable RH remplit le formulaire et confirme en cliquant sur le bouton «
Enregistrer » ;
4. Le système modifie l’état de la demande à « En attente » ;
5. Le système insère les nouvelles informations dans la table des stages et des messages ;
6. En cas de réussite, le système affiche un message de succès ;
7. FIN.
Scénario d’exceptions
1. Si le responsable ne confirme pas l’opération ;
a. GOTO FIN.
5.2.1.3 Raffinement du cas d’utilisation « Présélectionner candidats »
Chaque encadrant a la possibilité de préselectionner un candidat. il peut nottament consul-
terla liste des candidatures reçues et effectuer toutes les fonctionnalités modélisées dans la 5.3
ci-dessous.
52
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.3: Raffinement du cas d’utilisation « Présélectionner candidats »
– Description textuelle du cas d’utilisation « Afficher profil candidat »
La description textuelle représentée dans le tableau 5.3 illustre le scénario du cas d’utilisation
« Afficher profil candidat » modélisé dans la figure 5.3.
Tableau 5.3: Description textuelle du cas d’utilisation
« Afficher profil candidat »
Sommaire
Titre : Afficher profil candidat
Auteur : Encadrant
Description d’enchaînement
Pré-conditions : Authentification et accès à la liste des candidatures reçues
Post-conditions : Profil candidat affiché
Scénario Nominal
53
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
1. L’encadrant clique sur l’icône « Informations » située au niveau de l’interface des
candidatures reçues ;
2. Le système récupère les informations du profil souhaité et les affiche en créant la
nouvelle vue « Profil candidat » ;
3. L’encadrant choisit un candidat en cliquant sur le bouton « Choisir » ;
4. Le système récupère la liste de tous les sujets disponibles et les affiches ;
5. L’encadrant sélectionne un sujet parmi ces derniers et confirme par un clic sur le
bouton « Enregistrer » ;
6. Le système insère les nouvelles informations dans la table des stages ;
7. Le système modifie l’état de la demande à « Suggérée » ;
8. Si valide, le système affiche un message de succès ;
9. FIN.
Scénario d’exceptions
1. Si les différentes modifications sur la base ne s’effectuent pas ;
a. Le systeme affiche un message d’erreur ;
b. GOTO FIN.
5.2.2 Conception
Après avoir terminé les raffinements des cas d’utilisation, nous élaborons les diagrammes de
séquences et d’activités afin de mieux structurer et comprendre les interactions entre les objets
manifestés au niveau de ce sprint.
5.2.2.1 diagramme d’activité
Le diagramme d’activité permet de clarifier et de donner une vision sur le déroulement,
l’enchaînement ainsi que le parallélisme des évènements propre à un cas d’utilisation.
– Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues »
Dans la figure 5.4 nous présentons les activités qui aboutissent à l’actualisation des demandes
reçues.
54
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.4: Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues »
5.2.2.2 diagrammes de séquences détaillés
Pour éclaircir les cas d’utilisation de ce sprint et présenter la succession chronologique des
opérations réalisées par les acteurs de notre système, nous consacrons cette partie pour décrire
les diagrammes de séquences.
– Diagramme de séquence du cas d’utilisation « Affecter Candidat »
Dans la figure 5.5 nous montrons le comportement dynamique du cas d’utilisation « Affecter
Candidat » à travers son diagramme de séquence.
55
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.5: Diagramme de séquence du cas d’utilisation « Affecter Candidat »
– Diagramme de séquence du cas d’utilisation « Afficher profil candidat »
Dans la figure 6.7 nous montrons le comportement dynamique du cas d’utilisation « Afficher
profil candidat » à travers son diagramme de séquence.
56
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.6: Diagramme de séquence du cas d’utilisation « Afficher profil candidat »
5.2.2.3 diagramme de classes
La figure 5.7 représente l’évolution du diagramme de classes par rapport au sprint qui
le précède en indiquant les nouvelles méthodes qui nous ont servi pour arriver à traiter les
demandes de stage.
57
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.7: Diagramme de classes du sprint2
5.2.3 Réalisation
Pour mener à bien notre projet, les interfaces Homme/Machine doivent être faciles à utiliser
tout en obéissant à des conditions d’ergonomie. Nous présentons dans ce qui suit quelques
interfaces pour expliquer les fonctionnalités offertes par le deuxième sprint.
58
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
c Interface de la liste des demandes reçues et non traitées
La Figure 5.8 présente l’interface affichant le tableau des demandes reçues et non traitées,
qui donne la possibilité à une recherche spécifique, à la consultation des détails d’une demande,
et à l’actualisation de la liste afin de la mettre à jour.
Figure 5.8: Interface de la liste des demandes reçues et non traitées
c Interface des profils des candidats
Les interfaces 5.9 et 5.10 présentent les différentes actions sur les profils des candidats. Le
responsable RH a le droit de refuser ou d’affecter une candidature à une offre, par contre l’en-
cadrant n’a qu’à choisir une demande, et chacun d’entre eux peut consulter leurs informations
ainsi que leurs documents.
Figure 5.9: Interface du profil candidat coté responsable
59
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.10: Interface du profil candidat coté encadrant
c Interface choisir candidat
La figure 5.11 présente le pop-up affiché à l’encadrant pour choisir un stagiaire, cette dernière
propose un menu déroulant, contenant les différentes offres de stage qu’il a déposé, avec un volet
pour afficher les informations relatives au sujet suite à sa sélection.
Figure 5.11: Interface choisir candidat
60
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
c Interface d’affectation des stagiaires
Nous présentons dans cette figure 5.12 l’interface dédiée à l’affectation des stagiaires. À
partir de ces formulaires, le responsable RH a la possibilité de choisir une offre dans le but
d’avoir une idée sur ses informations ainsi que de l’assigner au candidat sélectionné, et pour
accomplir l’opération de l’affectation, il doit indiquer la date du rendez-vous, la durée du stage
et facultativement un message de renseignement.
Figure 5.12: Interface d’affectation des stagiaires
c Interface des e-mails
La figure 5.13 montre l’e-mail envoyé automatiquement suite à la réception d’une demande
de stage. En effet pour inciter les stagiaires à remplir notre PDF interactif et envoyer leurs
documents, nous proposons à travers cette interface un guide et un bouton de postulation afin
de fixer l’objet de l’e-mail pour des utilisations futures. Lorsque le stagiaire respecte toutes
les règles du guide et envoie correctement ses fichiers, un accusé de réception 5.14 s’envoie
automatiquement. Sinon il sera averti par un courrier électronique.
61
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Figure 5.13: Mail de réponse à une demande de stage
Figure 5.14: Accusé de réception
62
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
5.3 Phase de post-jeu : finalisation
Nous réservons cette partie pour la finalisation du présent sprint, en présentant un ensemble
de cas de tests validés auprès du Product Owner.
5.3.1 Test fonctionnel
le tableau 5.4 montre les différents tests fonctionnels effectués sur quelques cas d’utilisations
du deuxième sprint.
Tableau 5.4: Test fonctionnel du deuxième sprint
Cas de test Démarche Comportement attendu Résultat
Test d’affectation
d’un candidat
Après l’accès à la liste
des demandes non trai-
tées, le responsable RH
consulte le contenu d’une
demande, clique sur «
Affecter » et enregistre
l’opération après avoir
rempli le formulaire.
Lors de l’enregistrement, S’il
y a un champ vide dans le
formulaire un message d’erreur
s’affiche, sinon une redirection
vers la liste des demandes non
traitées est effectuée et un mes-
sage de succès d’affectation est
affiché.
Conforme
Test de choix d’un
candidat
Aprés l’accés à la liste des
candidatures reçues l’en-
cadrant choisit de consul-
ter le profil d’un candi-
dat, clique sur le bouton
« Choisir » et lui associe
un sujet.
Un message indiquant la sug-
gestion avec succès est affiché.
Conforme
5.3.2 Rétrospective du sprint 2
La vérification de tout ce qui a été réalisé au niveau de ce présent sprint, a généré l’évaluation
présentée dans le tableau 5.5.
63
Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires
Tableau 5.5: Rétrospective du sprint 2
Rétrospective du sprint 2
Ce qui a bien fonctionné
• Actualiser demandes reçues ;
• Consulter contenu demandes ;
• Affecter / Refuser candidat ;
• Choisir candidat.
Ce qui n’a pas bien fonctionné rien à mentionner
Ce qui doit être amélioré la notification en temps réel
Conclusion
À travers ce chapitre, nous sommes arrivées à clôturer le deuxième sprint des traitements des
candidatures par la revue d’un second livrable fonctionnel, bien testé et validé par le propriétaire
du produit. De ce fait, nous sommes amenées à étudier les étapes de la mise en œuvre du
prochain sprint que nous allons détailler dans le chapitre suivant.
64
Chapitre 6
Sprint3 : Affectation des stagiaires
Plan
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 66
2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 68
3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 79
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapitre 6. Sprint3 : Affectation des stagiaires
Introduction
Après avoir achevé l’étude et la réalisation du deuxième sprint, nous allons passer à la
présentation des différentes tâches effectuées pour arriver à affecter les candidats à des offres
de stages. Cela constitue l’objet de ce troisième incrément qui suit les mêmes principes des
sprints précédents : nous allons mettre en place son backlog après l’explication de son but et
nous allons évoquer la phase d’analyse, de conception ainsi que celle de la réalisation.
6.1 Phase de pré-jeu : préparation
6.1.1 But
Le but de ce troisième sprint est d’entamer le processus d’affectation des candidats en
passant en revue les différents états des demandes. Nous mettons en place la conception et la
réalisation de toutes les fonctionnalités qui conduisent soit à l’acceptation d’un stagiaire tout
en lui créant sa prise de fonction soit au refus de sa candidature.
6.1.2 Backlog du sprint
La planification des différentes fonctionnalités qui constituent le présent incrément est pré-
sentée dans le tableau 6.1 du backlog du sprint
Tableau 6.1: Backlog du sprint3
ID Théme ID User stories Effort
4 Consulter demandes re-
fusées
4.1 En tant que Personnel je voudrais
consulter la liste des demandes refu-
sées.
1j
4.2 En tant que Personnel je voudrais
consulter le contenu d’une demande.
0.5j
4.3 En tant que Personnel je voudrais
chercher une demande.
0.25j
8 Gérer suggestions 8.1 En tant que Responsable RH je vou-
drais consulter les demandes suggé-
rées.
1.5j
66
Chapitre 6. Sprint3 : Affectation des stagiaires
8.2 En tant que Responsable RH je vou-
drais consulter le profil d’un stagiaire.
0.5j
8.3 En tant que Responsable RH je vou-
drais accepter une suggestion d’affec-
tation.
1j
8.4 En tant que Responsable RH je vou-
drais refuser une suggestion d’affecta-
tion.
0.5j
9 Gérer affectations 9.1 En tant que Responsable RH je vou-
drais consulter la liste des demandes
suivies.
2.5j
9.2 En tant que Responsable RH je vou-
drais chercher une demande.
0.25
9.3 En tant que Responsable RH je vou-
drais trier les demandes.
0.25j
9.4 En tant que Responsable RH je vou-
drais visualiser le dossier d’un sta-
giaire.
0.5j
9.5 En tant que Responsable RH je vou-
drais accepter une prise de fonction.
3j
9.6 En tant que Responsable RH je vou-
drais refuser une prise de fonction.
1j
11 Gérer propositions d’En-
cadrement
11.1 En tant qu’Encadrant je voudrais
consulter la liste des demandes en at-
tente.
1j
11.2 En tant qu’Encadrant je voudrais
trier les demandes en attente.
0.25j
11.3 En tant qu’Encadrant je voudrais
chercher un candidat.
0.25j
11.4 En tant qu’Encadrant je voudrais af-
ficher le profil d’un stagiaire .
0.5j
67
Chapitre 6. Sprint3 : Affectation des stagiaires
11.5 En tant qu’Encadrant je voudrais ac-
cepter d’encadrer un candidat.
1.5j
11.6 En tant qu’Encadrant je voudrais re-
fuser d’encadrer un candidat.
1j
6.2 Phase de jeu : mise en oeuvre
6.2.1 Modélisation fonctionnelle
Pour livrer une description sur quelques scénarios possibles liés au troisième sprint, nous
réservons cette partie pour présenter le diagramme de cas d’utilisation global et ses raffinements.
6.2.1.1 Diagramme du cas d’utilisation global du sprint3
Figure 6.1: Diagramme de cas d’utilisation global du sprint3
6.2.1.2 Raffinement de cas d’utilisation « Gérer suggestions »
Nous présentons au niveau de la figure 6.2 le raffinement du cas d’utilisation « Gérer sugges-
tions » dont le responsable RH a la possibilité d’effectuer toutes les fonctionnalités modélisées
ci-dessous.
68
Chapitre 6. Sprint3 : Affectation des stagiaires
Figure 6.2: Raffinement du cas d’utilisation « Gérer suggestions »
6.2.1.3 Raffinement du cas d’utilisation« Gérer propositions d’encadrement »
Le diagramme de la figure 6.3 présente le raffinement du cas d’utilisation « Gérer propo-
sitions d’encadrement » en modélisant toutes les fonctionnalités qui sont à la disposition des
encadrants.
Figure 6.3: Raffinement du cas d’utilisation « Gérer propositions d’encadrement »
– Description textuelle du cas d’utilisation « Accepter d’encadrer »
La description textuelle représentée dans le tableau 6.2 montre le scénario du cas d’utilisation
« Accepter d’encadrer » illustré dans la figure 6.3.
Tableau 6.2: Description textuelle du cas d’utilisation
« Accepter d’encadrer »
Sommaire
69
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

Contenu connexe

Tendances

Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
BadrElattaoui
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Ramzi Noumairi
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
Donia Hammami
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
Ghizlane ALOZADE
 
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
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingRapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Mohamed Cherkaoui
 
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: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)
Ines Ben Kahla
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
Oussama Djerba
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
Mohamed Amine Mahmoudi
 
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
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
Nadir Haouari
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
Nadir Haouari
 
Rapport pfe licence
Rapport pfe licenceRapport pfe licence
Rapport pfe licence
Fatima Zahra Fagroud
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudes
Tahani RIAHI
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 

Tendances (20)

Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
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
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-ConsultingRapport PFE - Mise en place d'OpenERP pour IT-Consulting
Rapport PFE - Mise en place d'OpenERP pour IT-Consulting
 
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: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
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
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
 
Rapport pfe licence
Rapport pfe licenceRapport pfe licence
Rapport pfe licence
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudes
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 

Similaire à Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

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
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
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
 
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
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
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
 
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
 
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
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 
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
 
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
 
Report Master
Report MasterReport Master
Report Master
Bilel Trabelsi
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
SafaAballagh
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
iRecruite
iRecruiteiRecruite
iRecruite
Donia Hammami
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
JihenBenfredj
 

Similaire à Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires (20)

Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
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 ...
 
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...
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
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...
 
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...
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
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
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Report Master
Report MasterReport Master
Report Master
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
iRecruite
iRecruiteiRecruite
iRecruite
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdfRapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
Rapport_PFE__Sesame__SAF INEZ_V0 (2).pdf
 

Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des stagiaires

  • 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 STAGE DE FIN D’ÉTUDES Présenté en vue de l’obtention du Diplôme National de Licence Fondamentale en Sciences et Technologies Mention : Science de l’Informatique Spécialité : Science de l’Informatique Par Ines HAMROUNI Yasmine LACHHEB Conception et mise en place d’une plate-forme de gestion des stagiaires Encadrant professionnel : Encadrant académique : Monsieur Mohamed BAHY Monsieur Riadh ZAAFRANI Chef de projet SI Maître Assistant Réalisé au sein de la Banque Internationale Arabe de Tunisie BIAT Année Universitaire 2017 - 2018
  • 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 STAGE DE FIN D’ÉTUDES Présenté en vue de l’obtention du Diplôme National de Licence Fondamentale en Sciences et Technologies Mention : Science de l’Informatique Spécialité : Science de l’Informatique Par Ines HAMROUNI Yasmine LACHHEB Conception et mise en place d’une plate-forme de gestion des stagiaires Encadrant professionnel : Encadrant académique : Monsieur Mohamed BAHY Monsieur Riadh ZAAFRANI Chef de projet SI Maître Assistant Réalisé au sein de la Banque Internationale Arabe de Tunisie BIAT Année Universitaire 2017 - 2018
  • 4. J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une soutenance. Encadrant professionnel, Mohamed BAHY Signature et cachet J’autorise les deux étudiantes à déposer leur rapport de stage en vue d’une soutenance. Encadrant académique, Riadh ZAAFRANI Signature
  • 5. Dédicaces Du profond de mon cœur, je dédie ce travail À mes chers parents, Qui demeurent pour moi un modèle d’intégrité et de rigueur. Aucune dédicace ne saurait être assez éloquente pour exprimer l’amour et le respect que j’ai toujours pour vous. Que ce modeste travail soit pour vous une reconnaissance envers tous vos sacrifices et vos efforts fournis jour et nuit pour faire de moi ce que je suis, je dois à vous toute ma réussite. Puisse Dieu, le tout-puissant, vous gratifie d’une longue vie débordante de santé et de bonheur. À mes adorables sœurs Amal et Yasmine, Qui n’ont jamais cessé de m’assister, de me soutenir et de m’encourager. En témoignage de mon affection fraternelle, mon attachement éternel et ma reconnaissance. Je vous aime mes chéries, et je vous souhaite un avenir brillant. Que Dieu vous bénisse et vous préserve que de la réussite. À tous ceux que j’aime, À tous ceux qui m’aiment et me supportent. Ines HAMROUNI i
  • 6. Dédicaces Aimablement, je dédie ce modeste travail À mes chers parents, Ceux qui représentent pour moi un magnifique modèle de labeur et de persévérance, nulle dédicace ne peut témoigner de l’amour, de l’estime et du respect que je leur porte. À mon frère, Mon fidèle compagnon, celui qui ne cesse jamais de me rendre heureuse et de me motiver pour aller en avant. À mes très chers amis Zied, Alia et Ines En témoignage de l’amitié et de l’amour qui nous unissent, et des souvenirs des moments merveilleux que nous avons passés. À toute ma famille et tous ceux qui m’entourent, que je ne saurai terminer ma dédicace sans les citer. Yasmine LACHHEB ii
  • 7. Remerciements Nous avons un grand plaisir de garder cette page en signe de gratitude et de profonde reconnaissance à tous ceux qui nous ont aidé de près ou de loin à la réalisation de ce projet. Nous sommes très reconnaissantes à notre encadrant à l’institut supérieur d’in- formatique, Monsieur Riadh ZAAFRANI, d’avoir accepté de diriger ce tra- vail sans oublier ses conseils et sa participation régulière au cheminement de ce rapport avec rigueur et bienveillance. Nous tenons à remercier Monsieur Mohamed BAHY, notre encadrant pro- fessionnel, pour sa disponibilité tout au long de ce stage, ses judicieux conseils et ses encouragements, qu’il trouve ici notre respectueuse reconnaissance. Nous tenons à remercier les membres de jury de nous avoir offert l’occasion de présenter notre projet devant leur honorable assistance et d’avoir accepté d’évaluer ce travail. iii
  • 8. Table des matières Introduction générale 1 1 Cadre général du projet 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Le Département des Systèmes d’information . . . . . . . . . . . . . . . . 3 1.1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . 4 1.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1 Description de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1 Le concept agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2 Présentation de la méthodologie Scrum . . . . . . . . . . . . . . . . . . . 6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Étude et analyse globale du projet 9 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.2 Identification des besoins fonctionnels . . . . . . . . . . . . . . . . . . . . 11 2.1.3 Identification des besoins non fonctionnels . . . . . . . . . . . . . . . . . 12 2.2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 Sprint0 : Mise en place de l’environnement matériel et logiciel 21 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 iv
  • 9. 3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.1 Système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3 Outil de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4 Outil de gestion de versions . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.5 Outil de manipulation des documents électroniques . . . . . . . . . . . . 24 3.2.6 Environnement de Système de Gestion de Base de Données . . . . . . . . 24 3.3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.1 Architecture matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.3.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.1 Protocoles de messagerie utilisés . . . . . . . . . . . . . . . . . . . . . . . 29 3.5.2 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4 Sprint1 : Authentification et gestion des utilisateurs et des offres 31 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.2 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5 Sprint2 : Traitement des candidatures des stagiaires 48 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 v
  • 10. 5.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.2 Rétrospective du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6 Sprint3 : Affectation des stagiaires 65 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3.2 Rétrospective du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7 Sprint4 : Gestion des stages et statistiques 81 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7.1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7.1.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7.1.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7.2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.2.1 Modélisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.2.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.2.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 vi
  • 11. 7.3.1 Test fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.3.2 Rétrospective du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.4 Phase du clôture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Conclusion générale 97 Bibliographie 98 Annexes 99 Annexe A. Fonctions de manipulation des données . . . . . . . . . . . . . . . . . . . . 99 Annexe B. Exemples de fonctions relatives au système « SI Mailing » . . . . . . . . . 100 Annexe C. Authentification et génération des fichiers PDF . . . . . . . . . . . . . . . 101 vii
  • 12. Table des figures 1.1 Logo de la Banque Internationale Arabe de Tunisie BIAT . . . . . . . . . . . . . 3 1.2 Organigramme hiérarchique du DSI . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Vue globale « Scrum » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Diagramme de contexte statique . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Estimation théorique des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1 l’architecture 3-tiers de notre application . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Principe des échanges de messages électroniques . . . . . . . . . . . . . . . . . . 29 3.4 PDF interactif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1 Diagramme de cas d’utilisation global du sprint1 . . . . . . . . . . . . . . . . . . 34 4.2 Raffinement du cas d’utilisation « Gérer utilisateurs » . . . . . . . . . . . . . . . 34 4.3 Diagramme de séquence du cas d’utilisation « S’authentifier » . . . . . . . . . . 38 4.4 Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur » . . . . . . 39 4.5 Diagramme de séquence du cas d’utilisation « Modifier un utilisateur » . . . . . 40 4.6 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.7 Interface d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.8 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.9 Interface de la liste des offres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.10 Interface d’ajout d’un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.11 Interface de modification d’une offre de stage . . . . . . . . . . . . . . . . . . . . 44 4.12 Interface d’un profil utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.13 Interface du contenu d’une offre . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1 Diagramme de cas d’utilisation global du sprint2 . . . . . . . . . . . . . . . . . . 51 5.2 Raffinement du cas d’utilisation « Traiter demandes reçues » . . . . . . . . . . . 51 5.3 Raffinement du cas d’utilisation « Présélectionner candidats » . . . . . . . . . . 53 5.4 Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues » . . . . 55 5.5 Diagramme de séquence du cas d’utilisation « Affecter Candidat » . . . . . . . . 56 viii
  • 13. Table des figures 5.6 Diagramme de séquence du cas d’utilisation « Afficher profil candidat » . . . . . 57 5.7 Diagramme de classes du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.8 Interface de la liste des demandes reçues et non traitées . . . . . . . . . . . . . . 59 5.9 Interface du profil candidat coté responsable . . . . . . . . . . . . . . . . . . . . 59 5.10 Interface du profil candidat coté encadrant . . . . . . . . . . . . . . . . . . . . . 60 5.11 Interface choisir candidat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.12 Interface d’affectation des stagiaires . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.13 Mail de réponse à une demande de stage . . . . . . . . . . . . . . . . . . . . . . 62 5.14 Accusé de réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1 Diagramme de cas d’utilisation global du sprint3 . . . . . . . . . . . . . . . . . . 68 6.2 Raffinement du cas d’utilisation « Gérer suggestions » . . . . . . . . . . . . . . . 69 6.3 Raffinement du cas d’utilisation « Gérer propositions d’encadrement » . . . . . . 69 6.4 Raffinement du cas d’utilisation « Gérer affectations » . . . . . . . . . . . . . . 71 6.5 Diagramme d’activité du cas d’utilisation « Consulter demandes suivies » . . . . 73 6.6 Diagramme de séquence du cas d’utilisation « Accepter d’encadrer » . . . . . . . 74 6.7 Diagramme de séquence du cas d’utilisation « Accepter prise de fonction » . . . 75 6.8 Diagramme de classes du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.9 Interface de la liste des demandes suivies . . . . . . . . . . . . . . . . . . . . . . 77 6.10 Interface des demandes en attente . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.11 E-mail d’acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.1 Diagramme de cas d’utilisation global du sprint 4 . . . . . . . . . . . . . . . . . 84 7.2 Raffinement du cas d’utilisation « Gérer prolongations » . . . . . . . . . . . . . 85 7.3 Raffinement du cas d’utilisation « Gérer stages encadrés » . . . . . . . . . . . . 86 7.4 Diagramme de séquence du cas d’utilisation « Consulter liste demandes de pro- longation » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.5 Digramme de séquence du cas d’utilisation « Évaluer stagiaire » . . . . . . . . . 89 7.6 Diagramme de classes du sprint4 . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.7 Interface de la liste des stages en cours . . . . . . . . . . . . . . . . . . . . . . . 91 7.8 Interface de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.9 Envoi de la fiche d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.10 Pop-up de prolongation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.11 Interface de la liste des demandes de prolongation . . . . . . . . . . . . . . . . . 93 ix
  • 14. Table des figures 7.12 Interface des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.13 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.1 Fonction PL/SQL « addDemande » . . . . . . . . . . . . . . . . . . . . . . . . . 99 A.2 Fonction d’ajout de documents . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.3 Fonction de récupération des stages non prolongés . . . . . . . . . . . . . . . . . 100 A.4 Fonction de vérification de l’existance d’un rapport dans la base de données . . . 100 B.1 Lecture et envoi des e-mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 B.2 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 C.1 Code d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.2 Code de génération du PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 x
  • 15. Liste des tableaux 2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 Équipe et rôles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Description des machines de développement . . . . . . . . . . . . . . . . . . . . 22 4.1 Backlog du sprint1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Description textuelle du cas d’utilisation « Ajouter un utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3 Description textuelle du cas d’utilisation « Modifier un profil utilisateur » . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4 Types d’objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5 Test fonctionnel du premier sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.6 Rétrospective du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1 Backlog du sprint2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2 Description textuelle du cas d’utilisation « Affecter candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3 Description textuelle du cas d’utilisation « Afficher profil candidat » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.4 Test fonctionnel du deuxième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.5 Rétrospective du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.1 Backlog du sprint3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.2 Description textuelle du cas d’utilisation « Accepter d’encadrer » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.3 Description textuelle du cas d’utilisation « Accepter prise de fonction » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.4 Test fonctionnel du troisième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.5 Rétrospective du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.1 Backlog du sprint4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 xi
  • 16. Liste des tableaux 7.2 Description textuelle du cas d’utilisation « Consulter liste demandes de prolongation » . . . . . . . . . . . . . . . . . . . 85 7.3 Description textuelle du cas d’utilisation « Évaluer stagiaire » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.4 Test fonctionnel du quatième sprint . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.5 Rétrospective du sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 xii
  • 17. Glossaires — AJAX = Asynchronous JavaScript And XML — BIAT = Banque Internationale Aarabe de Tunisie — CSS = Cascading Style Sheets — DC = Document Cloud — DSI = Département du Systèmes d’Information — HTML = HyperText Markup Language — IMAP = Internet Message Access Protocol — IT = Technologies de l’Information — JS = Java Script — MVC = Modèle Vue Contrôleur — MoSCoW= Must Should Could Won’t — NT = Nouvelle Technologie — PDF = Portable Document Format — PHP = Hypertext Preprocessor — PL = Procedural Language — RH = Ressources Humaines — SASS = Syntactically Awesome StyleSheets — SE = Système d’Exploitation — SGBD = Système de Gestion de Base de Données — SGBDR = Système de Gestion de Base de Données Relationnelle — SI = Système Informatique — SMTP = Mail Transfer Protocol — SQL = Structured Query Language — UC = Use Case — UML = Unified Modeling Language — URL = Uniform Resource Locator
  • 18. Introduction générale À l’époque actuelle, et grâce à l’évolution des nouvelles technologies d’information et de communication, rares sont les personnes qui nient que la digitalisation des documents et la diffusion de l’information en mode numérique améliorent la flexibilité et l’agilité des entreprises. Dans cette perspective, la Banque internationale arabe de Tunisie (BIAT), s’est dit prête à abandonner la manière archaïque de gestion manuelle des stages, et à s’investir afin d’avoir une solution informatique permettant d’élargir les canaux de communication avec les stagiaires, et de suivre régulièrement les nombreux changements effectués sur leurs candidatures, ce qui permettra d’améliorer les conditions de travail au sein du service des ressources humaines. C’est dans ce contexte que la direction d’ingénierie IT réseau et sécurité de la BIAT, nous a confié la tâche de mise en place d’une solution permettant la dématérialisation du processus de gestion des stagiaires, en réalisant une plate-forme qui collabore avec un service de messagerie, ce qui permettra de simplifier le traitement des demandes des candidats envoyées sous la forme de courriers électroniques. Le présent rapport se subdivise en sept chapitres présentant les différents stades par lesquels nous allons passer pour accomplir ce projet. Le premier chapitre sert à situer le projet dans son contexte général, à savoir, l’organisme d’accueil, la description des contraintes conduisant à l’élaboration de cette solution, ainsi que la spécification de la méthodologie adaptée. Dans le second chapitre, nous allons dévoiler les besoins métiers et nous allons mettre en place le backlog produit tout en le clôturant avec une planification des sprints. Dans le troisième chapitre intitulé « Sprint 0 », nous allons nous intéresser à la présentation de l’environnement de travail ainsi que l’architecture de notre projet. C’est à ce niveau que nous allons exposer les choix techniques et la description du système « SI Mailing ». Quand aux trois derniers chapitres, nous allons les consacrer à la présentation des autres sprints de notre projet. Chaque sprint, comporte trois phases majeures : la phase de la préparation, celle de la mise en oeuvre et celle dediée à la finalisation. La dernière partie du rapport sera dédiée à la conclusion générale qui résume les grands traits de ce travail et présente les perspectives futures de perfectionnement de la plate-forme élaborée. 1
  • 19. Chapitre 1 Cadre général du projet Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  • 20. Chapitre 1. Cadre général du projet Introduction Avant d’aborder l’étude approfondie de notre stage de fin d’études, nous allons décrire brièvement à travers ce premier chapitre l’organisme au sein duquel se déroule notre stage. Nous allons présenter par la suite une critique de l’existant afin de dévoiler notre solution proposée, et pour clôturer, nous allons consacrer la dernière partie à la présentation de la méthodologie adaptée pour la gestion de ce travail. 1.1 Organisme d’accueil Au bout de quarante années d’existence, la banque internationale arabe de Tunisie « BIAT », lancée le 24 février 1976, est devenue l’une des plus importantes institutions financières en Afrique du Nord et un acteur de référence en Tunisie en termes de part de marché et de ré- sultats financiers. Banque universelle offrant à sa clientèle de particuliers, tunisiens résidents à l’étranger, professionnels, petites, moyennes, grandes entreprises et institutionnels, une gamme de produits et services à la fois complète et innovante. La BIAT constitue aujourd’hui un groupe bancaire diversifié dans les domaines de l’assurance, de la gestion d’actifs, du capital investisse- ment, de l’intermédiation boursière et du conseil à l’international. Appuyant son développement sur la proximité et l’engagement sociétal, elle met son expertise au profit de ses clients, de ses partenaires et de l’économie du pays. [1] Figure 1.1: Logo de la Banque Internationale Arabe de Tunisie BIAT [1] 1.1.1 Le Département des Systèmes d’information La BIAT est constituée d’une direction générale qui comporte 11 départements ainsi que 4 pôles renfermant 41 directions. Et parmi ces départements, on trouve le département Systèmes d’information (DSI), et plus précisément la direction ingénierie IT réseau et sécurité où notre stage s’est déroulé. Grâce à ses solutions proposées, Le DSI jouit d’une grande importance au sein de la banque, il a comme objectifs de : • Développer des solutions informatiques ; 3
  • 21. Chapitre 1. Cadre général du projet • Assurer la bonne planification des ressources, le partage des connaissances et l’enrichis- sement des compétences ; • Assurer en permanence la sécurité technique des systèmes informatiques ; • Produire des applications destinées aux clients et aux différents services de la banque ; • Exploitation de l’infrastructure informatique au sein de la BIAT. 1.1.2 Organigramme hiérarchique du DSI Une hiérarchisation du DSI est illustrée dans la figure 1.2 suivante : Figure 1.2: Organigramme hiérarchique du DSI 1.2 Étude de l’existant 1.2.1 Description de l’existant Depuis ses débuts, la BIAT accueille plusieurs stagiaires de différentes spécialités pour ac- complir soit un stage ouvrier, soit un stage de fin d’études dans le but de contribuer activement à leurs formations. Actuellement, il est nécessaire que les candidats se présentent au sein de la banque pour postuler leurs demandes de stage sous la forme d’un dossier contenant un CV, une copier de la CIN, ses relevés de notes, etc. Ce dossier est traité, puis archivé par le responsable des ressources humaines dès que le stagiaire termine son stage. 4
  • 22. Chapitre 1. Cadre général du projet Compte tenu de l’absence d’un outil informatique, la sélection des stagiaires et la gestion de leurs candidatures se fait manuellement. 1.2.2 Problématique La mission de gestion des stages au sein de la BIAT est devenue très compliquée vu le nombre important des candidatures reçues. Ainsi, nous avons recensé une liste de problèmes : • Recherche fastidieuse des documents des stagiaires ; • Consultation non périodique des candidatures ; • Risque d’incohérence et de perte d’informations très élevé ; • Ralentissement du suivi des stages ; • Redondance de l’information ; • Énorme perte de temps ; • Absence des statistiques ; • Classement des dossiers compliqué. 1.2.3 Solution proposée Les problèmes dégagés lors de l’analyse de la situation actuelle rendent nécessaire l’élabo- ration d’une solution informatisée afin de faciliter la gestion des stagiaires. Cette solution consiste à développer une plate-forme de gestion collaborative, qui a comme principaux objectifs : • De faciliter l’accès et la consultation des informations de chaque stagiaire ; • De faciliter le contact entre le responsable RH et les stagiaires en réalisant un système permettant l’échange des e-mails ; • De garder toujours une trace de chaque dossier et de chaque demande de stage, pour pouvoir générer par la suite des statistiques. Étant donné que les stagiaires ne doivent pas avoir un accès direct à la plate-forme pour des raisons de sécurité, nous avons opté pour les courriers électroniques comme un outil de communication. 5
  • 23. Chapitre 1. Cadre général du projet 1.3 Méthodologie de travail Une méthodologie est essentiellement un outil de planification qui aide à la mise en œuvre d’un projet, elle nous fournit un cadre et des instructions précises pour gérer efficacement notre équipe et assurer un bon déroulement des différentes phases du projet. Pour réussir à mener à bien le processus de développement et par conséquent l’aboutissement d’un bon résultat, il est important de suivre une méthodologie adaptée. 1.3.1 Le concept agile Le choix d’une méthodologie appropriée dépend de nombreux paramètres tels que les ca- ractéristiques du projet et ses contraintes. De ce fait, nous avons choisi d’adapter une méthode incrémentale et itérative plutôt qu’une méthode classique, vu que le processus de la réalisation de notre projet était imprévisible et nécessite les réorientations du Product Owner. Parmi les méthodes basées sur le pragmatisme et le développement itératif, nous pouvons distinguer les méthodes agiles très populaires en usage aujourd’hui à travers le monde. [2] Une méthode agile définit un cadre moins rigide que les méthodes traditionnelles, elle met l’accent sur la pratique de la réalisation du produit plus que sur la théorie, ce qui permet de détecter les pénalités et les problèmes pour entreprendre des actions correctrices le plus tôt possible. Grâce à l’agilité, on se retrouve aussi avec un focus sur la simplicité, l’intelligence collective et également sur la communication et la collaboration concrétisées par la présence du client au cœur du projet et par l’esprit d’équipe partagé par les acteurs métiers et les développeurs. 1.3.2 Présentation de la méthodologie Scrum La méthode Scrum fait partie du groupe des méthodes agiles. Elle représente un Frame- work de gestion et d’organisation de projets, reconnu pour sa flexibilité, son efficacité et son empirique. L’utilisation de ce Framework vise à satisfaire au mieux les besoins du client en s’appuyant sur plusieurs points : La planification des événements : • Le Sprint : Il s’agit d’un incrément qui consiste à développer une partie du logiciel en une période 6
  • 24. Chapitre 1. Cadre général du projet inférieure à 30 jours. Durant cette itération l’équipe de développement se concentre sur la réalisation les fonctionnalités demandées ; • Planification du Sprint (Sprint Planning) : Avant chaque sprint, une réunion de planification s’organise. Ce planning sélectionne dans le backlog du produit les exigences les plus prioritaires pour le client ; • Mêlée quotidienne (Daily Scrum Meetings) : C’est une réunion quotidienne de 15 minutes qui vise à évaluer l’avancement du travail et à garder l’équipe concentrée sur l’objectif du sprint ; • Revue du Sprint (Sprint Review) : À chaque fin de sprint, l’équipe présente l’incrément logiciel développé au client, celui-ci valide les différents points du backlog et indique les changements à opérer ; [3] • Rétrospective du Sprint (Sprint Retrospective) : C’est une pratique qui permet d’améliorer l’équipe et le processus de développement quo- tidiennement. La définition des artefacts Scrum : • Backlog du produit : Il s’agit d’un référentiel des exigences et des fonctionnalités, fourni et tenu à jour par le Product Owner ; [3] • Backlog du sprint : Un sous ensemble du backlog produit qui contient les fonctionnalités à mettre en oeuvre durant le sprint ; • Incrément du produit : La sommation de toutes les fonctionnalités terminées pendant un sprint ; • Le burndown chart du sprint(Sprint Burn-Down Chart) : Diagramme indiquant les tâches restantes avant la fin du Sprint sur un axe du temps. [3] La figure 1.3 présente une vue globale du cycle de vie de la méthodologie « Scrum ». 7
  • 25. Chapitre 1. Cadre général du projet Figure 1.3: Vue globale « Scrum » [4] Conclusion Après avoir présenté l’organisme d’accueil, introduire la solution proposée et expliquer la méthodologie optée pour le travail, nous allons maintenant essayer de répondre à la question « qui fait quoi dans le système et comment ? » qui fera l’objet du deuxième chapitre étude et analyse globale du projet. 8
  • 26. Chapitre 2 Étude et analyse globale du projet Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Modélisation des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . 13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  • 27. Chapitre 2. Étude et analyse globale du projet Introduction Au niveau de ce chapitre, nous allons aborder dans un premier temps la partie de la capture des besoins, où nous allons identifier les différents acteurs et dégager les besoins fonctionnels et non fonctionnels auxquels doit répondre notre solution. Dans un second temps, nous allons modéliser toutes les fonctionnalités par un diagramme de cas d’utilisation global. Enfin, nous allons piloter notre projet avec la méthodologie Scrum. 2.1 Capture des besoins 2.1.1 Identification des acteurs Chaque système informatique met des fonctionnalités et des informations pertinantes à la disposition de ses acteurs qui leur permettent d’interagir avec. Ces acteurs peuvent être classés comme l’indique le tableau 2.1 : Tableau 2.1: Identification des acteurs Acteurs secondaires SI Mailing Cet acteur n’interagit pas directement avec le système, mais sollicité pour des informations complémentaires. Acteurs principaux Administrateur C’est l’acteur le plus haut dans la hiérarchie dans le système, il gère les responsables et les encadrants en leur affectant les rôles nécessaires. Responsable RH Cet acteur se charge principalement de gérer les stages en faisant l’étude des demandes des stagiaires et des offres déposées par les encadrants. Encadrant Cet acteur a pour rôle de déposer les offres de stage, d’accepter ou de refuser les affectations et d’évaluer les stagiaires. On peut présenter l’environnement de notre système et préciser le nombre d’instances de chacun de ces acteurs par un diagramme de contexte statique illustré par la figure 2.1 ci-dessous. 10
  • 28. Chapitre 2. Étude et analyse globale du projet Figure 2.1: Diagramme de contexte statique 2.1.2 Identification des besoins fonctionnels La phase de la spécification des besoins fonctionnels est indispensable pour que les résultats de la réalisation de notre plate-forme soient conformes aux attentes du « Product owner ». Ainsi, Les différentes fonctionnalités que nous envisageons de mettre en place dans le cadre de ce projet, peuvent être regroupées dans les points suivants : • Permettre aux encadrants de gérer les propositions d’encadrement, entre autres l’accep- tation ou le refus d’une demande en attente ; • Permettre aux administrateurs de gérer les utilisateurs et leur associer des privilèges ; • Permettre à tous les utilisateurs de consulter les notifications ainsi que les statistiques ; • Permettre aux responsables RH et aux encadrants de consulter les demandes refusées et de visualiser leurs contenus ; • Permettre aux responsables RH de traiter les différentes demandes reçues envoyées de la part des stagiaires ; • Permettre aux responsables RH de gérer les suggestions de stages des encadrants ; • Permettre aux responsables RH d’accepter ou de refuser d’affecter un candidat ; • Permettre aux encadrants de présélectionner des candidats dans le but de les encadrer ; • Permettre aux chacun des encadrants et des responsables RH de consulter les stages archivés et interrompus ; • Permettre aux responsables RH d’accepter ou de refuser les demandes de prolongation des encadrants ; • Permettre aux encadrants de gérer les stages qu’ils encadrent et de suivre leurs avance- ments ; 11
  • 29. Chapitre 2. Étude et analyse globale du projet • Permettre aux encadrants de déposer, de modifier ou de supprimer des offres de stage ; • Permettre aux responsables RH de consulter toutes les offres de stages publiées. 2.1.3 Identification des besoins non fonctionnels Les besoins non fonctionnels permettent l’amélioration de la qualité logicielle de notre sys- tème. Ils agissent comme des contraintes à prendre en considération pour mettre en place une solution adéquate à ce qui est attendu, et pour éviter plusieurs incohérences dans le système. Notre application doit nécessairement répondre aux besoins suivants : Convivialité : L’application doit être facile à utiliser. Elle devra offrir des interfaces conviviales, simples et ergonomiques. Performance : Vu l’ampleur des données qu’on va stocker, l’application doit répondre aux besoins des utili- sateurs d’une manière optimale en termes de temps de réponse, de traitement et de chargement des données. Maintenabilité : Le code doit être lisible, commenté et bien structuré afin d’obéir à l’évolution et aux différents changements des besoins. 2.2 Modélisation des besoins c Diagramme de cas d’utilisation global Le diagramme illustré par la figure 2.2 décrit les différents besoins fonctionnels de notre application, chaque cas d’utilisation représente une fonctionnalité offerte par le système à ses utilisateurs. 12
  • 30. Chapitre 2. Étude et analyse globale du projet Figure 2.2: Diagramme de cas d’utilisation global 2.3 Pilotage du projet avec Scrum 2.3.1 Équipe et rôles La méthodologie Scrum fait intervenir trois rôles principaux qui sont : • Product owner : C’est le représentant des clients, il définit l’ordre dans lequel les fonctionnalités seront développées ; • Scrum Master : Il agit comme un « Coach » et non pas comme un dirigeant, son rôle est d’aider l’équipe à avancer de manière autonome en cherchant en permanence à s’améliorer ; [5] • Équipe : l’équipe est constituée des personnes qui seront chargées d’implémenter les 13
  • 31. Chapitre 2. Étude et analyse globale du projet besoins du client. Elle doit tout faire pour délivrer le produit dans les délais prévus ; • Intervenants : ils observent et donnent des conseils à l’équipe. Ces participants sont illustrés par le tableau 2.2 : Tableau 2.2: Équipe et rôles Scrum Personnes Rôles Scrum Mr. Mohamed BEHY Product Owner Mr. Mohamed BEHY Scrum Master ines HAMROUNI, yasmine LACHHEB Équipe Mr. Riadh ZAAFRANI Intervenant 2.3.2 Backlog du produit Le backlog du produit est l’artefact le plus important de Scrum, il consiste à présenter la liste des fonctionnalités ou encore les « User Stories » constituant le produit souhaité. Chaque fonctionnalité est caractérisée par un numéro ID, un thème, une priorité et une estimation de l’effort nécessaire à une équipe pour l’implémenter. Nous choisissons de représenter l’estimation sous la forme de points relatifs en utilisant la suite de Fibonnacci afin d’éviter les confusions dues aux estimations trop proches et de représenter la priorité suivant la méthode « MoSCoW » qui a pour signification : • M : « Must have », toutes les fonctionnalités qui sont indispensables et nécessaires ; • S : « Should have », les tâches qui sont essentielles, mais pas obligatoires, elles seront développées une fois que celles de la catégorie Must ont été livrées ; • C : « Could have », se sont des tâches qu’ont les fait seulement s’il reste assez de temps ; • W : « Won’t have this time but would like in the future », se sont les tâches supplémen- taires, très secondaires. Le tableau 2.3 résume le backlog du produit de notre application. 14
  • 32. Chapitre 2. Étude et analyse globale du projet Tableau 2.3: Backlog produit ID Théme ID User stories Priorité Estimation 1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais m’au- thentifier pour accéder à mon espace. M 8 2 Consulter statistiques 2.1 En tant qu’Utilisateur je voudrais consulter les statistiques. S 3 3 Gérer utili- sateurs 3.1 En tant qu’Administrateur je voudrais consulter la liste des utilisateurs. M 2 3.2 En tant qu’Administrateur je voudrais consulter le profil d’un utilisateur. S 2 3.3 En tant qu’Administrateur je voudrais ajouter un profil utilisateur. M 5 3.4 En tant qu’Administrateur je voudrais modifier le profil d’un utilisateur. M 5 3.5 En tant qu’Administrateur je voudrais supprimer un utilisateur. M 3 3.6 En tant qu’Administrateur je voudrais trier la liste des utilisateurs. W 1 3.7 En tant qu’Administrateur je voudrais chercher un utilisateur. C 1 4 Consulter demandes refusées 4.1 En tant que Personnel je voudrais consulter la liste des demandes refusées S 2 4.2 En tant que Personnel je voudrais consulter le contenu d’une demande. C 1 4.3 En tant que Personnel je voudrais cher- cher une demande. C 1 5 Consulter stages archi- vés 5.1 En tant que Personnel je voudrais consulter la liste des stages archivés. M 2 15
  • 33. Chapitre 2. Étude et analyse globale du projet 5.2 En tant que Personnel je voudrais consulter le profil d’un stagiaire archivé. S 1 5.3 En tant que Personnel je voudrais impri- mer les documents des stagiaires. W 2 5.4 En tant que Personnel je voudrais cher- cher un stage archivé. C 1 6 Consulter stages inter- rompus 6.1 En tant que Personnel je voudrais consulter la liste des stages interrompus. S 2 6.2 En tant que Personnel je voudrais consulter le profil du stagiaire inter- rompu C 1 7 Traiter demandes reçues 7.1 En tant que Responsable RH je voudrais consulter la liste des demandes non trai- tées M 2 7.2 En tant que Responsable RH je voudrais consulter le contenu d’une demande re- çue. M 5 7.3 En tant que Responsable RH je voudrais affecter un candidat à un sujet. M 3 7.4 En tant que Responsable RH je voudrais refuser un candidat. M 2 7.5 En tant que Responsable RH je voudrais actualiser la liste des demandes reçues. M 13 7.6 En tant que Responsable RH je voudrais télécharger un document du dossier can- didat. C 3 7.7 En tant que Responsable RH je voudrais chercher une demande. C 1 8 Gérer sug- gestions 8.1 En tant que Responsable RH je voudrais consulter les demandes suggérées. M 2 16
  • 34. Chapitre 2. Étude et analyse globale du projet 8.2 En tant que Responsable RH je voudrais consulter le profil d’un stagiaire. S 1 8.3 En tant que Responsable RH je voudrais accepter une suggestion d’affectation. M 5 8.4 En tant que Responsable RH je voudrais refuser une suggestion d’affectation. M 2 9 Gérer affec- tations 9.1 En tant que Responsable RH je voudrais consulter la liste des demandes suivies. M 13 9.2 En tant que Responsable RH je voudrais chercher une demande. C 1 9.3 En tant que Responsable RH je voudrais trier les demandes. W 1 9.4 En tant que Responsable RH je voudrais visualiser le dossier d’un stagiaire. S 2 9.5 En tant que Responsable RH je voudrais accepter une prise de fonction. M 8 9.6 En tant que Responsable RH je voudrais refuser une prise de fonction. M 3 10 Présélectionner candidat 10.1 En tant qu’Encadrant je voudrais consulter la liste des candidatures re- çues. M 2 10.2 En tant qu’Encadrant je voudrais consulter le profil d’un candidat. M 2 10.3 En tant qu’Encadrant je voudrais choisir un candidat. M 3 10.4 En tant qu’Encadrant je voudrais cher- cher un candidat. C 1 11 Gérer propo- sitions d’en- cadrement 11.1 En tant qu’Encadrant je voudrais consulter la liste des demandes en at- tente. M 2 17
  • 35. Chapitre 2. Étude et analyse globale du projet 11.2 En tant qu’Encadrant je voudrais trier les demandes en attente. W 1 11.3 En tant qu’Encadrant je voudrais cher- cher un candidat. C 1 11.4 En tant qu’Encadrant je voudrais affi- cher le profil d’un stagiaire . S 1 11.5 En tant qu’Encadrant je voudrais accep- ter d’encadrer un candidat. M 5 11.6 En tant qu’Encadrant je voudrais refuser d’encadrer un candidat . M 3 12 Gérer pro- longations 12.1 En tant que Responsable RH je voudrais consulter la liste des demandes de pro- longation. M 2 12.2 En tant que Responsable RH je voudrais consulter les stages prolongés. M 2 12.3 En tant que Responsable RH je voudrais consulter les stages non prolongés. M 2 12.4 En tant que Responsable RH je voudrais consulter le dossier d’un stagiaire cou- rant. S 1 12.5 En tant que Responsable RH je voudrais télécharger un document du dossier sta- giaire. C 2 12.6 En tant que Responsable RH je voudrais accepter une prolongation. M 2 12.7 En tant que Responsable RH je voudrais refuser une prolongation. M 2 13 Gérer stages encadrés 13.1 En tant qu’Encadrant je voudrais consulter les stages en cours d’encadre- ment. M 2 18
  • 36. Chapitre 2. Étude et analyse globale du projet 13.2 En tant qu’Encadrant je voudrais cher- cher un stage. C 1 13.3 En tant qu’Encadrant je voudrais consulter le dossier d’un stagiaire. S 1 13.4 En tant qu’Encadrant je voudrais inter- rompre un stage. M 2 13.5 En tant qu’Encadrant je voudrais de- mander une prolongation de stage. M 3 13.6 En tant qu’Encadrant je voudrais éva- luer un stagiaire. M 8 14 Gérer sujets stages 14.1 En tant qu’Encadrant je voudrais consulter la liste des sujets M 2 14.2 En tant qu’Encadrant je voudrais cher- cher un sujet. C 1 14.3 En tant qu’Encadrant je voudrais ajou- ter un sujet. M 3 14.4 En tant qu’Encadrant je voudrais modi- fier un sujet. M 3 14.5 En tant qu’Encadrant je voudrais sup- primer un sujet. M 2 15 Consulter notifications 15.1 En tant qu’Utilisateur je voudrais consulter les notifications reçues C 5 16 Consulter offres de stage 16.1 En tant que Responsable RH je voudrais consulter les offres proposées. M 2 16.2 En tant que Responsable RH je voudrais consulter le contenu d’une offre propo- sée. M 2 19
  • 37. Chapitre 2. Étude et analyse globale du projet 2.3.3 Planification des sprints La réunion de la planification des sprints est l’un des évènements Scrum le plus important, puisqu’elle rythme tout le projet et sert à bien dérouler les différents sprints. À travers cette réunion, nous évoquons le planning de notre travail qui s’est étalé sur une période de trois mois avec une estimation de deux à trois semaines pour chaque sprint. La Figure 2.3 représente l’estimation théorique des différents sprints. Figure 2.3: Estimation théorique des sprints Conclusion Tout au long de ce chapitre, nous avons détaillé les différents besoins ainsi que l’interaction des acteurs avec le système. Par la suite nous avons choisi d’identifier l’équipe de travail et de définir notre backlog du produit qui nous a permis de préparer un terrain favorable pour les prochaines phases et de déduire la planification des sprints de notre plate-forme. Dans le chapitre suivant, nous allons commencer par le sprint0 qui présente notre environnement de travail et décrit notre acteur système « SI Mailing ». 20
  • 38. Chapitre 3 Sprint0 : Mise en place de l’environnement matériel et logiciel Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1 Environnement materiel . . . . . . . . . . . . . . . . . . . . . . . . . 22 2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Archiecture du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5 Description du système « SI Mailing » . . . . . . . . . . . . . . . . 28 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
  • 39. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel Introduction Ce chapitre est consacré à la présentation de l’architecture matérielle et logicielle de notre application, des différents outils qui constituent l’environnement de travail et des différentes technologies que nous allons utiliser tout au long de ce projet. Quant à la dernière partie, elle sera dédiée à la description de l’élaboration du système «SI Mailing», jouant le rôle d’un acteur secondaire. 3.1 Environnement materiel Nous allons identifier dans le tableau 3.1 les outils matériels utilisés pour la réalisation de notre plate-forme : Tableau 3.1: Description des machines de développement Ordinateur portable Lenovo Processeur Intel R CoreTM i7-7500U CPU @ 2.70GHz 2.90GHz Mémoire 8,00 Go Disque dur 1 To Circuit graphique NVIDIA R GeForce R 940MX Système d’exploitation Windows 10 Entreprise 64 bit Ordinateur portable Asus Processeur Intel R CoreTM i7-5500U CPU @ 2.40GHz 2.40GHz Mémoire 8,00 Go Disque dur 1 To Circuit graphique NVIDIA R GeForce R 920M Système d’exploitation Windows 10 Entreprise 64 bit 22
  • 40. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel 3.2 Environnement logiciel 3.2.1 Système d’exploitation c Windows 10 Le successeur de Windows 8.1 est un SE de la famille Windows NT développé par la société américaine Microsoft. [6] 3.2.2 Outils de développement c PhpStorm Est un éditeur performant destiné pour PHP, HTML et JS, édité par JetBrains. Il simplifie l’écriture du code, l’intégration d’un dé- bogueur et l’interfaçage avec un outil de gestion de versions ou d’administration de bases de données. c Oracle SQL Developer Un environnement de développement intégré multiplate-forme, fourni gratuitement par Oracle Corporation et utilisant la tech- nologie Java. C’est un outil graphique permettant d’interroger des bases de données Oracle à l’aide du langage SQL. [7] c ShareLaTeX Un éditeur LaTeX en ligne, permet de créer et de partager un document latex en temps réel et de le compiler en PDF. 23
  • 41. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel 3.2.3 Outil de conception c Visual Paradigm for UML Est un logiciel permettant aux programmeurs de mettre en place des diagrammes UML. Disposant d’un outil créant des différents types de schémas comme les diagrammes de cas d’utilisation, de séquences et plein d’autres diagrammes. [8] 3.2.4 Outil de gestion de versions c Bitbucket Est un service web d’hébergement et de gestion de développement logiciel utilisant les logiciels de gestion de versions Git. Il permet de mieux collaborer en distribuant les fichiers à chaque développeur et en sauvegardant l’historique de chaque modification. [9] 3.2.5 Outil de manipulation des documents électroniques c Adobe Acrobat DC Est une famille de logiciels mis au point par Adobe, il permet de manipuler des documents électroniques au format PDF, de gérer les processus de signatures électroniques et de créer et numériser des formulaires interactifs. 3.2.6 Environnement de Système de Gestion de Base de Données c Oracle Database 11g Est un SGBD relationnel édité par la société Oracle Corporation, leader mondial des bases de données. Il permet d’assurer la dé- finition et la manipulation, la sauvegarde et la restauration des données ainsi que la gestion des accès concurrents. 24
  • 42. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel 3.3 Archiecture du projet 3.3.1 Architecture matérielle Le choix de l’architecture physique est d’une importance primordiale, il influencera la per- formance du système. C’est pour cette raison, que nous optons pour une séparation de notre plate-forme en diffé- rentes couches. Nous parlons dans ce cas du modèle multi-tiers plus précisément l’architecture 3 tiers qui est également une extension du modèle Client/Serveur. En utilisant cette architecture, le système est divisé en trois parties dont le rôle de chacune est défini comme suit : • Couche présentation Elle correspond à la partie visible de l’application , appelée Interface Homme Machine. Son rôle est de réassembler les services offerts par la couche inférieure et les afficher à l’utilisateur ; • Couche métier Appelé aussi Business, c’est la couche qui exécute la logique métier, elle offre des services à la couche présentation en utilisant les données accessibles à travers la couche inférieure d’accès aux données ; • Couche d’accès aux données Elle correspond au serveur de la base de données. Sur ce troisième tiers, un SGBD est installé. Nous avons dans notre cas utilisé le SGBDR, ORACLE 11g, qui a pour rôle de stocker les données indépendamment de la logique applicative. Figure 3.1: l’architecture 3-tiers de notre application 25
  • 43. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel 3.3.2 Architecture logicielle L’une des étapes importantes dans le processus de la mise en œuvre d’une application est le choix adéquat d’un motif de conception puisqu’il facilite la communication, fait gagner en terme de rapidité et diminue d’une manière éminente les coûts. Dans ce projet, nous avons opté pour le patron de conception MVC. Son principal intérêt est la séparation des responsabilités en divisant l’interface graphique d’un programme en trois entités distinctes ayant chacune un rôle précis lors du traitement de l’information, ce qui rend l’application plus maintenable et plus évolutive. Les rôles des trois entités sont les suivants : [10] • Le modèle : Contient les données manipulées par le programme. Il assure la gestion de ces données et garantit leur intégrité ; • La vue : Fait l’interface avec l’utilisateur. Son premier rôle est d’afficher les données qu’elle a récupéré auprès du modèle et son second rôle est de recevoir toutes les actions de l’utilisateur. Ses différents événements sont envoyés au contrôleur ; • Le contrôleur : Chargé de la synchronisation du modèle et de la vue. Il reçoit tous les événements de l’utilisateur et dénclenche les actions à effectuer. Figure 3.2: Architecture MVC 26
  • 44. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel 3.4 Choix techniques c AJAX Repose sur un ensemble de technologies tels que javascript, xml, json, html et les requêtes http, destinées à réaliser des transferts de données et de rapides mises à jour du contenu d’une page Web, sans procéder au rechargement total de la page. c Bootstrap Bootstrap est une collection d’outils utiles à la création du design des sites et d’applications web. C’est un ensemble qui contient des codes HTML, CSS ainsi que des extensions JavaScript en option. [11] c jQuery Est un Framework développé en JavaScript, il possède une librairie qui propose les fonctionnalités de gestion des évènements, d’anima- tion et de manipulation des feuilles de style. c HTML5 Un langage de balisage conçu pour représenter des pages web. Son principal intérêt est le formatage de l’écriture d’un document avec des balises. c CSS3 Un langage informatique qui permet de décrire la mise en page des documents HTML dans le but d’améliorer leur aspect ergonomique et décoratif. 27
  • 45. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel c Sass Un langage de génération de feuilles de style, basé en grande partie sur CSS3, en ajoutant de nouvelles règles telles que l’utilisation des variables et la création des fonctions. c PHP PHP est un langage de script, utilisé pour produire des pages Web dynamiques via un serveur http. il offre des nombreuses possibilités telles que la gestion des sessions utilisateurs, la gestion de fichiers PDF, la gestion des e-mails en POP et IMAP et le cryptage MD5 et SHA1 [12] c PL/SQL Basé sur les paradigmes de programmation procédurale et struc- turée. Créé par Oracle et utilisé dans le cadre de bases de données relationnelles. [13] c UML Un langage de modélisation unifié qui s’utilise généralement pour la conception orientée objet. Il est constitué d’un ensemble de dia- grammes, leur principal rôle est de présenter les logiciels à déve- lopper sous une forme graphique. 3.5 Description du système « SI Mailing » Nous consacrons cette section pour montrer la réalisation du système « SI mailing » déclaré dans la partie précédente comme étant un acteur secondaire interagissant avec notre système général. Le recours à l’implémentation de ce système était notre solution pour remédier au problème de l’extraction des données à partir des pièces-jointes envoyées par les stagiaires sous la forme d’e-mails. 28
  • 46. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel Ce système permet aussi de concrétiser le processus d’envoi et de lecture des courriers électroniques ainsi que la récupération des attachements en utilisant les deux protocoles SMTP et IMAP. 3.5.1 Protocoles de messagerie utilisés c SMTP Entre l’utilisateur et son serveur, l’envoi des e-mails sur les réseaux se fait à l’aide du proto- cole SMTP. Et pour assurer ce transfert, nous avons eu recours à la bibliothèque « PHPMailer » disponible en PHP qui fournit une collection de fonctions facilitant la construction et la génération des e-mails. c IMAP Pour amener à bien le processus de la lecture des e-mails et arriver à accéder aux différents courriers électroniques envoyés de la part des stagiaires, nous avons travaillé avec des fonctions PHP qui utilisent le protocole IMAP. Le schéma representé par la figure 3.3 illustre le fonctionnement des protocoles présentés ci-dessus. Figure 3.3: Principe des échanges de messages électroniques [14] 3.5.2 PDF interactif Tous les problèmes rencontrés lors de la recherche d’une solution pour que le candidat puisse nous envoyer ses informations sans avoir un accès direct à la plate-forme nous ont amenés à 29
  • 47. Chapitre 3. Sprint0 : Mise en place de l’environnement matériel et logiciel utiliser un formulaire sous la forme d’un PDF interactif. Le formulaire doit être rempli par chaque candidat, et envoyé par e-mail, dans le but d’en extraire toutes les données nécessaires. Nous montrons ci-dessous à travers la figure 3.4 notre PDF interactif. Figure 3.4: PDF interactif Conclusion Dans ce chapitre nous avons présenté l’environnement matériel et logiciel que nous avons préparé pour la mise en place de notre système, l’architecture physique et logicielle, les différents choix techniques ainsi que le système « SI Mailing ». Dans le chapitre suivant, nous allons entamer le premier pas de la réalisation du projet : le sprint1. 30
  • 48. Chapitre 4 Sprint1 : Authentification et gestion des utilisateurs et des offres Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 32 2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 33 3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 45 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
  • 49. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Introduction Le présent chapitre consiste à décrire les différentes étapes de la réalisation du premier sprint. En premier lieu, nous allons évoquer les histoires utilisateurs. En second lieu, nous allons exposer les différents diagrammes d’analyse et de conception et par la suite, nous allons présenter la phase de réalisation ainsi que les scénarios de test. 4.1 Phase de pré-jeu : préparation 4.1.1 But Le but de ce premier sprint consiste à mettre en œuvre le processus d’authentification qui à son tour déclenche l’accomplissement de la fonctionnalité gestion des utilisateurs avec leurs différents privilèges. Ce sprint vise aussi à mettre en place la fonctionnalité de la gestion des offres de stages qui sont proposées par l’encadrant et consultables par le responsable RH. 4.1.2 Backlog du sprint Nous présentons à travers le tableau 4.1 le Backlog de ce sprint ainsi que l’estimation d’effort par jour de chaque fonctionnalité à réaliser. Tableau 4.1: Backlog du sprint1 ID Théme ID User stories Effort 1 S’authentifier 1.1 En tant qu’Utilisateur je voudrais m’authentifier pour accéder à mon es- pace. 5j 3 Gérer utilisateurs 3.1 En tant qu’Administrateur je vou- drais consulter la liste des utilisa- teurs. 1j 3.2 En tant qu’Administrateur je vou- drais consulter le profil d’un utilisa- teur. 1j 3.3 En tant qu’Administrateur je vou- drais ajouter un profil utilisateur. 1.5j 32
  • 50. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres 3.4 En tant qu’Administrateur je vou- drais modifier le profil d’un utilisa- teur. 1.5j 3.5 En tant qu’Administrateur je vou- drais supprimer un utilisateur. 0.5j 3.6 En tant qu’Administrateur je vou- drais trier la liste des utilisateurs. 0.25j 3.7 En tant qu’Administrateur je vou- drais chercher un utilisateur. 0.25j 14 Gérer sujets stages 14.1 En tant qu’Encadrant je voudrais consulter la liste des sujets. 1j 14.2 En tant qu’Encadrant je voudrais chercher un sujet. 0.25j 14.3 En tant qu’Encadrant je voudrais ajouter un sujet. 1.5j 14.4 En tant qu’Encadrant je voudrais mo- difier un sujet. 1.5j 14.5 En tant qu’Encadrant je voudrais supprimer un sujet. 0.5j 16 Consulter offres de stage 16.1 En tant que Responsable RH je vou- drais consulter les offres proposées. 1j 16.2 En tant que Responsable RH je vou- drais consulter le contenu d’une offre proposée. 1j 4.2 Phase de jeu : mise en oeuvre 4.2.1 Modélisation fonctionnelle Les besoins à réaliser dans notre premier sprint, ont été spécifiés. Nous passons maintenant à la présentation des diagrammes de cas d’utilisation qui ont pour but de donner une vue globale 33
  • 51. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres sur l’ensemble des fonctionnalités fournies par l’application, ainsi que les descriptions textuelles qui décrivent les scénarios de chaque cas. 4.2.1.1 Diagramme de cas d’utilisation global du sprint1 Figure 4.1: Diagramme de cas d’utilisation global du sprint1 4.2.1.2 Raffinement du cas d’utilisation « Gérer utilisateurs » Pour gérer les utilisateurs, un administrateur a la possibilité d’effectuer les fonctionnalités modélisées dans la figure 4.2 ci-dessous. Figure 4.2: Raffinement du cas d’utilisation « Gérer utilisateurs » 34
  • 52. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres – Description textuelle du cas d’utilisation « Ajouter un utilisateur » La description textuelle représentée dans le tableau 4.2 montre le scénario du cas cas d’uti- lisation « Ajouter un utilisateur » illustré dans la figure 4.2. Tableau 4.2: Description textuelle du cas d’utilisation « Ajouter un utilisateur » Sommaire Titre : Ajouter un profil utilisateur Auteur : Administrateur Description d’enchaînement Pré-conditions : Authentification et consultation de la liste des utilisateurs Post-conditions : Profil utilisateur ajouté Scénario Nominal 1. L’administrateur demande d’ajouter un nouveau profil ; 2. Le système récupère les informations des utilisateurs existants à partir de l’annuaire ; 3. Le système affiche les informations au niveau du formulaire à remplir ; 4. L’administrateur saisit les informations demandées pour l’ajout et confirme l’opé- ration par un clic sur le bouton « Enregistrer » ; 5. Le système valide le nom utilisateur et le mot de passe et ajoute les informations ; 6. Si valide, le système affiche un message de succès ; 7. FIN. Scénario Alternatif 1. Si l’administrateur entre des données erronées ; a. GOTO 3. 2. Si l’utilisateur existe déjà ; a. le système affiche un message d’avertissement ; b. GOTO 3. Scénario d’exceptions 35
  • 53. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres 1. Si l’administrateur ne confirme pas ou annule l’opération d’ajout en cliquant sur le bouton « Annuler » ; a. GOTO FIN. – Description textuelle du cas d’utilisation « Modifier un profil utilisateur » La description textuelle représentée dans le tableau 4.3 illustre le scénario du cas d’utilisation « Modifier un profil utilisateur » modélisé dans la figure 4.2. Tableau 4.3: Description textuelle du cas d’utilisation « Modifier un profil utilisateur » Sommaire Titre : Modifier un profil utilisateur Auteur : Administrateur Description d’enchaînement Pré-conditions : Authentification et consultation de la liste des utilisateurs Post-conditions : Profil utilisateur modifié Scénario Nominal 1. L’administrateur choisit le profil qu’il veut modifier ; 2. Le système récupère et affiche les informations du profil utilisateur choisi ; 3. L’administrateur modifie les données et confirme par un clic sur le bouton « Enre- gistrer » ; 4. Le système valide l’opération et affiche un message de succès de modification ; 5. FIN. Scénario Alternatif 1. Si l’administrateur n’a pas renseigné au moins un champ ; a. Le système affiche un message d’avertissement ; b. GOTO 2. Scénario d’exceptions 36
  • 54. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres 1. Si l’administrateur refuse de continuer l’opération de modification et l’annule ; a. GOTO FIN. 4.2.2 Conception En se basant sur les fonctionnalités modélisées dans la section précédente, nous allons passer à la conception détaillée des cas d’utilisation principaux. Dans un premier temps, nous allons élaborer les diagrammes de séquences de quelques cas d’utilisation afin de clarifier le déroule- ment des événements. Dans un second temps, nous allons détailler le diagramme de classes du sprint, qui va nous amener au schéma relationnel de notre base de données. 4.2.2.1 diagrammes de séquences détaillés Pour une bonne compréhension des composantes du premier sprint, il est indispensable de présenter les diagrammes de séquences des principaux cas d’utilisation. Ces diagrammes décrivent les scénarios de chaque cas en mettant l’accent sur le facteur chronologique, ainsi que l’interaction entre les différents objets qui le constituent. On peut distinguer trois types d’objets illustrés par le tableau 4.4 ci-dessous : Tableau 4.4: Types d’objets « Boundary » Représente l’interface affichée à l’utilisateur « Control » Assure la communication entre le modèle et la vue. « Model » Représente la persistance des données auprès du système. – Diagramme de séquence du cas d’utilisation « S’authentifier » Dans le diagramme de la figure 4.4 ci-dessous, nous détaillons l’interaction entre les utilisa- teurs et les composants du système afin de pouvoir s’authentifier. 37
  • 55. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.3: Diagramme de séquence du cas d’utilisation « S’authentifier » – Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur » Dans le diagramme de la figure 4.4 ci-dessous, nous détaillons l’interaction entre l’adminis- trateur et les composants du système utilisés au cours de l’ajout d’un utilisateur. 38
  • 56. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.4: Diagramme de séquence du cas d’utilisation « Ajouter un utilisateur » – Diagramme de séquence du cas d’utilisation « Modifier un utilisateur » Dans le diagramme de la figure 4.5 ci-dessous, nous détaillons l’interaction entre l’adminis- trateur et les composants du système utilisés au cours de la modification. 39
  • 57. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.5: Diagramme de séquence du cas d’utilisation « Modifier un utilisateur » 4.2.2.2 diagramme de classes Le diagramme de séquence présenté dans la partie précédente nous a permis de voir une vue dynamique de notre système, et afin de pouvoir présenter les différentes entités qui le composent avec leurs différentes relations d’une manière statique nous avons consacré cette partie pour définir un diagramme faisant partie des diagrammes structurels d’Uml qui est le diagramme de classes illustré par la figure 4.6 ci-dessous. 40
  • 58. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.6: Diagramme de classes du sprint 1 4.2.3 Réalisation Après avoir présenté la solution conceptuelle, nous exploitons dans ce qui suit le fruit de notre travail en exposant les différentes interfaces les plus significatives, relatives à ce premier sprint. 41
  • 59. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres c Interface d’authentification Nous commençons par présenter la première interface commune à tous les acteurs de notre système, celle relative à l’authentification, avec laquelle tous les utilisateurs sont appelés à in- troduire leurs noms d’utilisateur et leurs mots de passe pour pouvoir accéder chacun à son espace personnel. Si les informations sont invalides, le système affiche un message d’erreur, et en cas d’une ten- tative d’accès à une page de la plateforme via l’URL sans aucune identification, il fait une redirection automatique vers la page d’authentification (figure 4.7). Figure 4.7: Interface d’authentification c Interfaces des listes des utilisateurs et des offres L’administrateur peut gérer les différents profils disponibles en accédant à la liste des uti- lisateurs à travers l’interface 4.8, tandis que l’encadrant a la main de gérer et d’examiner la liste de ses offres présentée dans la figure 4.9. Chacun d’entre eux a la possibilité de faire une recherche ou un trie sur sa liste selon un critère souhaité. 42
  • 60. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.8: Interface de la liste des utilisateurs Figure 4.9: Interface de la liste des offres c Interface d’ajout d’un utilisateur Pour ajouter un nouvel utilisateur, l’administrateur clique en premier lieu sur l’icône d’ajout présentée dans la figure 4.8. Dès que le pop-up s’affiche, ce dernier sélectionne un personnel parmi ceux qui sont disponibles et remplit par la suite toutes les informations indiquées dans le formulaire présenté par l’interface 4.10. 43
  • 61. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Figure 4.10: Interface d’ajout d’un utilisateur c Interface de modification d’une offre de stage Dans le cadre de la gestion des offres, un encadrant a le droit de modifier un sujet. La figure 4.11 indique l’interface du pop-up affichant les informations de l’offre à modifier. Figure 4.11: Interface de modification d’une offre de stage 44
  • 62. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres c Interfaces du contenu d’un profil utilisateur et d’une offre À travers les deux interfaces des figures 4.12 et 4.13 ci-dessous, un administrateur a la possibilité de consulter le profil d’un utilisateur et tout encadrant peut afficher le contenu d’une offre déjà publiée. Figure 4.12: Interface d’un profil utilisateur Figure 4.13: Interface du contenu d’une offre 4.3 Phase de post-jeu : finalisation Après la réalisation du premier sprint, nous passons maintenant à la présentation des tâches de finalisation. Nous présentons ici l’avancement du travail pour savoir si nous avons pu at- teindre les objectifs définis et de se préparer pour le sprint suivant. 4.3.1 Test fonctionnel Il s’agit dans cette section de mettre l’action sur quelques cas de scénarios de tests fonc- tionnels relatifs au premier sprint en les présentant dans le tableau 6.4 suivant : Tableau 4.5: Test fonctionnel du premier sprint Cas de test Démarche Comportement attendu Résultat Test d’authentifica- tion Après l’accès à l’interface d’authentification, l’utili- sateur entre ses coordon- nées et valide. Redirection vers la page d’ac- cueil si l’utilisateur existe. Si- non un message d’erreur s’af- fiche. Conforme 45
  • 63. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Test d’ajout d’un profil utilisateur Après l’accès à la liste des utilisateurs, l’admi- nistrateur saisit les don- nées d’un profil et clique sur le bouton « Enregis- trer ». Si le profil utilisateur est déjà existant, un message d’erreur d’ajout s’affiche, sinon un mes- sage succès apparaît. Conforme Test de modifica- tion d’une offre de stage Après l’accès à la liste des offres, l’encadrant sélec- tionne le sujet à modifier et clique sur le l’icône de modification. Un formulaire contenant les données du sujet sélectionné s’affiche dans un pop-up. Dès sa confirmation, les informa- tions modifiées s’enregistrent et un message de succès de mo- dification s’affiche. Conforme Test de suppression d’une offre de stage Après l’accès à la liste des offres, l’encadrant choi- sit le sujet à supprimer en cliquant sur l’icône de suppression. Un pop-up de confirmation ap- paraît. Si l’encadrant confirme l’opération, un message de suc- cès s’affiche, sinon, en cas d’an- nulation, le système effectue une redirection vers la liste des offres. Conforme 4.3.2 Rétrospective du sprint 1 Après avoir fait la revue du sprint et la vérification des différentes fonctionnalités demandées, nous présentons dans ce qui suit l’évaluation de cet incrément à travers le tableau 4.6. 46
  • 64. Chapitre 4. Sprint1 : Authentification et gestion des utilisateurs et des offres Tableau 4.6: Rétrospective du sprint 1 Rétrospective du sprint 1 Ce qui a bien fonctionné • Authentification ; • Ajouter un(e) utilisateur / offre ; • Modifier un(e) utilisateur / offre ; • Supprimer un(e) utilisateur / offre ; • Consulter un profil utilisateur ; • Consulter un sujet ; • Chercher un utilisateur / sujet ; • Consulter une offre de stage ; • Consulter la liste des offres de stages. Ce qui n’a pas bien fonctionné rien à mentionner Ce qui doit être amélioré rien à mentionner Conclusion À travers ce chapitre, nous avons présenté la spécification des besoins, la conception illustrée par des diagrammes de séquences détaillés et un diagramme de classes ainsi que la réalisation des histoires utilisateurs du premier sprint. Après avoir testé et validé les fonctionnalités avec le Scrum Master et le Product Owner au cours de la revue du sprint, nous allons maintenant attaquer la prochaine étape : le sprint 2 47
  • 65. Chapitre 5 Sprint2 : Traitement des candidatures des stagiaires Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 49 2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 50 3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 63 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
  • 66. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Introduction Après avoir entamé le premier sprint de notre système, nous allons maintenant passer à la présentation de notre deuxième sprint. Tout au long de ce chapitre, nous allons nous intéresser à la phase du traitement des candidatures des stagiaires. Tout d’abord, nous allons présenter la première phase de préparation, celle de la réalisation et nous allons terminer enfin par la partie de la finalisation et des tests fonctionnels. 5.1 Phase de pré-jeu : préparation 5.1.1 But En partant du même principe que le sprint précédent, nous commençons par définir le but de notre deuxième sprint, qui consiste à mettre en œuvre le processus du « traitement des candidatures des stagiaires ». Ce sprint est le plus important et le plus complexe, car il contient les fonctionnalités prin- cipales du projet, où on doit réaliser le traitement des candidatures ainsi que le processus de la consultation des notifications. 5.1.2 Backlog du sprint Avant de commencer le travail, nous allons identifier dans cette partie les fonctionnalités à réaliser durant cet incrément. Le tableau 5.1 ci-dessous résume donc le backlog de notre deuxième sprint. Tableau 5.1: Backlog du sprint2 ID Théme ID User stories Effort 15 Consulter notifications 15.1 En tant qu’Utilisateur je voudrais consulter les notifications reçues. 2j 7 Traiter demandes reçues 7.1 En tant que Responsable RH je vou- drais consulter la liste des demandes non traitées. 1j 7.2 En tant que Responsable RH je vou- drais consulter le contenu d’une de- mande reçue. 2j 49
  • 67. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires 7.3 En tant que Responsable RH je vou- drais affecter un candidat à un sujet. 1j 7.4 En tant que Responsable RH je vou- drais refuser un candidat. 0.5j 7.5 En tant que Responsable RH je vou- drais actualiser la liste des demandes reçues. 5j 7.6 En tant que Responsable RH je vou- drais télécharger un document du dossier candidat. 1j 7.7 En tant que Responsable RH je vou- drais chercher une demande. 0.25j 10 Présélectionner candi- dats 10.1 En tant qu’Encadrant je voudrais consulter la liste des candidatures re- çues. 1j 10.2 En tant qu’Encadrant je voudrais consulter le profil d’un candidat. 1j 10.3 En tant qu’Encadrant je voudrais choisir un candidat. 1j 10.4 En tant qu’Encadrant je voudrais chercher un candidat. 1.25 5.2 Phase de jeu : mise en oeuvre 5.2.1 Modélisation fonctionnelle La Figure 5.1 ci-dessous, représente le diagramme de cas d’utilisation global qui modélise les fonctionnalités spécifiques à ce sprint. Et afin de mieux les assimiler nous établissons les raffinements nécessaires qui nous conduisent vers les descriptions textuelles. 50
  • 68. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires 5.2.1.1 Diagramme de cas d’utilisation global du sprint2 Figure 5.1: Diagramme de cas d’utilisation global du sprint2 5.2.1.2 Raffinement du cas d’utilisation « Traiter demandes reçues » Afin de traiter les demandes reçues, chaque responsable RH a la possibilité de visualiser la liste des demandes non traitées, de l’actualiser et d’effectuer toutes les fonctionnalités modélisées dans la figure 5.2 ci-dessous. Figure 5.2: Raffinement du cas d’utilisation « Traiter demandes reçues » – Description textuelle du cas d’utilisation « Affecter candidat » La description textuelle représentée dans le tableau 5.2 illustre le scénario du cas d’utilisation « Affecter candidat » modélisé dans la figure 5.2. 51
  • 69. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Tableau 5.2: Description textuelle du cas d’utilisation « Affecter candidat » Sommaire Titre : Affecter candidat Auteur : Responsable RH Description d’enchaînement Pré-conditions : Authentification, visualiser la liste des demandes non traitées et consulter le contenu d’une demande Post-conditions : Candidat affecté Scénario Nominal 1. Le cas d’utilisation commence lorsque le responsable RH décide d’affecter un sta- giaire en cliquant sur le bouton « Affecter » ; 2. Le système récupère la liste des sujets disponibles et la met à la disposition du responsable RH à travers une vue d’affectation renfermant un formulaire ; 3. Le responsable RH remplit le formulaire et confirme en cliquant sur le bouton « Enregistrer » ; 4. Le système modifie l’état de la demande à « En attente » ; 5. Le système insère les nouvelles informations dans la table des stages et des messages ; 6. En cas de réussite, le système affiche un message de succès ; 7. FIN. Scénario d’exceptions 1. Si le responsable ne confirme pas l’opération ; a. GOTO FIN. 5.2.1.3 Raffinement du cas d’utilisation « Présélectionner candidats » Chaque encadrant a la possibilité de préselectionner un candidat. il peut nottament consul- terla liste des candidatures reçues et effectuer toutes les fonctionnalités modélisées dans la 5.3 ci-dessous. 52
  • 70. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.3: Raffinement du cas d’utilisation « Présélectionner candidats » – Description textuelle du cas d’utilisation « Afficher profil candidat » La description textuelle représentée dans le tableau 5.3 illustre le scénario du cas d’utilisation « Afficher profil candidat » modélisé dans la figure 5.3. Tableau 5.3: Description textuelle du cas d’utilisation « Afficher profil candidat » Sommaire Titre : Afficher profil candidat Auteur : Encadrant Description d’enchaînement Pré-conditions : Authentification et accès à la liste des candidatures reçues Post-conditions : Profil candidat affiché Scénario Nominal 53
  • 71. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires 1. L’encadrant clique sur l’icône « Informations » située au niveau de l’interface des candidatures reçues ; 2. Le système récupère les informations du profil souhaité et les affiche en créant la nouvelle vue « Profil candidat » ; 3. L’encadrant choisit un candidat en cliquant sur le bouton « Choisir » ; 4. Le système récupère la liste de tous les sujets disponibles et les affiches ; 5. L’encadrant sélectionne un sujet parmi ces derniers et confirme par un clic sur le bouton « Enregistrer » ; 6. Le système insère les nouvelles informations dans la table des stages ; 7. Le système modifie l’état de la demande à « Suggérée » ; 8. Si valide, le système affiche un message de succès ; 9. FIN. Scénario d’exceptions 1. Si les différentes modifications sur la base ne s’effectuent pas ; a. Le systeme affiche un message d’erreur ; b. GOTO FIN. 5.2.2 Conception Après avoir terminé les raffinements des cas d’utilisation, nous élaborons les diagrammes de séquences et d’activités afin de mieux structurer et comprendre les interactions entre les objets manifestés au niveau de ce sprint. 5.2.2.1 diagramme d’activité Le diagramme d’activité permet de clarifier et de donner une vision sur le déroulement, l’enchaînement ainsi que le parallélisme des évènements propre à un cas d’utilisation. – Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues » Dans la figure 5.4 nous présentons les activités qui aboutissent à l’actualisation des demandes reçues. 54
  • 72. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.4: Diagramme d’activité du cas d’utilisation « Actualiser demandes reçues » 5.2.2.2 diagrammes de séquences détaillés Pour éclaircir les cas d’utilisation de ce sprint et présenter la succession chronologique des opérations réalisées par les acteurs de notre système, nous consacrons cette partie pour décrire les diagrammes de séquences. – Diagramme de séquence du cas d’utilisation « Affecter Candidat » Dans la figure 5.5 nous montrons le comportement dynamique du cas d’utilisation « Affecter Candidat » à travers son diagramme de séquence. 55
  • 73. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.5: Diagramme de séquence du cas d’utilisation « Affecter Candidat » – Diagramme de séquence du cas d’utilisation « Afficher profil candidat » Dans la figure 6.7 nous montrons le comportement dynamique du cas d’utilisation « Afficher profil candidat » à travers son diagramme de séquence. 56
  • 74. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.6: Diagramme de séquence du cas d’utilisation « Afficher profil candidat » 5.2.2.3 diagramme de classes La figure 5.7 représente l’évolution du diagramme de classes par rapport au sprint qui le précède en indiquant les nouvelles méthodes qui nous ont servi pour arriver à traiter les demandes de stage. 57
  • 75. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.7: Diagramme de classes du sprint2 5.2.3 Réalisation Pour mener à bien notre projet, les interfaces Homme/Machine doivent être faciles à utiliser tout en obéissant à des conditions d’ergonomie. Nous présentons dans ce qui suit quelques interfaces pour expliquer les fonctionnalités offertes par le deuxième sprint. 58
  • 76. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires c Interface de la liste des demandes reçues et non traitées La Figure 5.8 présente l’interface affichant le tableau des demandes reçues et non traitées, qui donne la possibilité à une recherche spécifique, à la consultation des détails d’une demande, et à l’actualisation de la liste afin de la mettre à jour. Figure 5.8: Interface de la liste des demandes reçues et non traitées c Interface des profils des candidats Les interfaces 5.9 et 5.10 présentent les différentes actions sur les profils des candidats. Le responsable RH a le droit de refuser ou d’affecter une candidature à une offre, par contre l’en- cadrant n’a qu’à choisir une demande, et chacun d’entre eux peut consulter leurs informations ainsi que leurs documents. Figure 5.9: Interface du profil candidat coté responsable 59
  • 77. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.10: Interface du profil candidat coté encadrant c Interface choisir candidat La figure 5.11 présente le pop-up affiché à l’encadrant pour choisir un stagiaire, cette dernière propose un menu déroulant, contenant les différentes offres de stage qu’il a déposé, avec un volet pour afficher les informations relatives au sujet suite à sa sélection. Figure 5.11: Interface choisir candidat 60
  • 78. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires c Interface d’affectation des stagiaires Nous présentons dans cette figure 5.12 l’interface dédiée à l’affectation des stagiaires. À partir de ces formulaires, le responsable RH a la possibilité de choisir une offre dans le but d’avoir une idée sur ses informations ainsi que de l’assigner au candidat sélectionné, et pour accomplir l’opération de l’affectation, il doit indiquer la date du rendez-vous, la durée du stage et facultativement un message de renseignement. Figure 5.12: Interface d’affectation des stagiaires c Interface des e-mails La figure 5.13 montre l’e-mail envoyé automatiquement suite à la réception d’une demande de stage. En effet pour inciter les stagiaires à remplir notre PDF interactif et envoyer leurs documents, nous proposons à travers cette interface un guide et un bouton de postulation afin de fixer l’objet de l’e-mail pour des utilisations futures. Lorsque le stagiaire respecte toutes les règles du guide et envoie correctement ses fichiers, un accusé de réception 5.14 s’envoie automatiquement. Sinon il sera averti par un courrier électronique. 61
  • 79. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Figure 5.13: Mail de réponse à une demande de stage Figure 5.14: Accusé de réception 62
  • 80. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires 5.3 Phase de post-jeu : finalisation Nous réservons cette partie pour la finalisation du présent sprint, en présentant un ensemble de cas de tests validés auprès du Product Owner. 5.3.1 Test fonctionnel le tableau 5.4 montre les différents tests fonctionnels effectués sur quelques cas d’utilisations du deuxième sprint. Tableau 5.4: Test fonctionnel du deuxième sprint Cas de test Démarche Comportement attendu Résultat Test d’affectation d’un candidat Après l’accès à la liste des demandes non trai- tées, le responsable RH consulte le contenu d’une demande, clique sur « Affecter » et enregistre l’opération après avoir rempli le formulaire. Lors de l’enregistrement, S’il y a un champ vide dans le formulaire un message d’erreur s’affiche, sinon une redirection vers la liste des demandes non traitées est effectuée et un mes- sage de succès d’affectation est affiché. Conforme Test de choix d’un candidat Aprés l’accés à la liste des candidatures reçues l’en- cadrant choisit de consul- ter le profil d’un candi- dat, clique sur le bouton « Choisir » et lui associe un sujet. Un message indiquant la sug- gestion avec succès est affiché. Conforme 5.3.2 Rétrospective du sprint 2 La vérification de tout ce qui a été réalisé au niveau de ce présent sprint, a généré l’évaluation présentée dans le tableau 5.5. 63
  • 81. Chapitre 5. Sprint2 : Traitement des candidatures des stagiaires Tableau 5.5: Rétrospective du sprint 2 Rétrospective du sprint 2 Ce qui a bien fonctionné • Actualiser demandes reçues ; • Consulter contenu demandes ; • Affecter / Refuser candidat ; • Choisir candidat. Ce qui n’a pas bien fonctionné rien à mentionner Ce qui doit être amélioré la notification en temps réel Conclusion À travers ce chapitre, nous sommes arrivées à clôturer le deuxième sprint des traitements des candidatures par la revue d’un second livrable fonctionnel, bien testé et validé par le propriétaire du produit. De ce fait, nous sommes amenées à étudier les étapes de la mise en œuvre du prochain sprint que nous allons détailler dans le chapitre suivant. 64
  • 82. Chapitre 6 Sprint3 : Affectation des stagiaires Plan Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 1 Phase de pré-jeu : préparation . . . . . . . . . . . . . . . . . . . . . . 66 2 Phase de jeu : mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . 68 3 Phase de post-jeu : finalisation . . . . . . . . . . . . . . . . . . . . . 79 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
  • 83. Chapitre 6. Sprint3 : Affectation des stagiaires Introduction Après avoir achevé l’étude et la réalisation du deuxième sprint, nous allons passer à la présentation des différentes tâches effectuées pour arriver à affecter les candidats à des offres de stages. Cela constitue l’objet de ce troisième incrément qui suit les mêmes principes des sprints précédents : nous allons mettre en place son backlog après l’explication de son but et nous allons évoquer la phase d’analyse, de conception ainsi que celle de la réalisation. 6.1 Phase de pré-jeu : préparation 6.1.1 But Le but de ce troisième sprint est d’entamer le processus d’affectation des candidats en passant en revue les différents états des demandes. Nous mettons en place la conception et la réalisation de toutes les fonctionnalités qui conduisent soit à l’acceptation d’un stagiaire tout en lui créant sa prise de fonction soit au refus de sa candidature. 6.1.2 Backlog du sprint La planification des différentes fonctionnalités qui constituent le présent incrément est pré- sentée dans le tableau 6.1 du backlog du sprint Tableau 6.1: Backlog du sprint3 ID Théme ID User stories Effort 4 Consulter demandes re- fusées 4.1 En tant que Personnel je voudrais consulter la liste des demandes refu- sées. 1j 4.2 En tant que Personnel je voudrais consulter le contenu d’une demande. 0.5j 4.3 En tant que Personnel je voudrais chercher une demande. 0.25j 8 Gérer suggestions 8.1 En tant que Responsable RH je vou- drais consulter les demandes suggé- rées. 1.5j 66
  • 84. Chapitre 6. Sprint3 : Affectation des stagiaires 8.2 En tant que Responsable RH je vou- drais consulter le profil d’un stagiaire. 0.5j 8.3 En tant que Responsable RH je vou- drais accepter une suggestion d’affec- tation. 1j 8.4 En tant que Responsable RH je vou- drais refuser une suggestion d’affecta- tion. 0.5j 9 Gérer affectations 9.1 En tant que Responsable RH je vou- drais consulter la liste des demandes suivies. 2.5j 9.2 En tant que Responsable RH je vou- drais chercher une demande. 0.25 9.3 En tant que Responsable RH je vou- drais trier les demandes. 0.25j 9.4 En tant que Responsable RH je vou- drais visualiser le dossier d’un sta- giaire. 0.5j 9.5 En tant que Responsable RH je vou- drais accepter une prise de fonction. 3j 9.6 En tant que Responsable RH je vou- drais refuser une prise de fonction. 1j 11 Gérer propositions d’En- cadrement 11.1 En tant qu’Encadrant je voudrais consulter la liste des demandes en at- tente. 1j 11.2 En tant qu’Encadrant je voudrais trier les demandes en attente. 0.25j 11.3 En tant qu’Encadrant je voudrais chercher un candidat. 0.25j 11.4 En tant qu’Encadrant je voudrais af- ficher le profil d’un stagiaire . 0.5j 67
  • 85. Chapitre 6. Sprint3 : Affectation des stagiaires 11.5 En tant qu’Encadrant je voudrais ac- cepter d’encadrer un candidat. 1.5j 11.6 En tant qu’Encadrant je voudrais re- fuser d’encadrer un candidat. 1j 6.2 Phase de jeu : mise en oeuvre 6.2.1 Modélisation fonctionnelle Pour livrer une description sur quelques scénarios possibles liés au troisième sprint, nous réservons cette partie pour présenter le diagramme de cas d’utilisation global et ses raffinements. 6.2.1.1 Diagramme du cas d’utilisation global du sprint3 Figure 6.1: Diagramme de cas d’utilisation global du sprint3 6.2.1.2 Raffinement de cas d’utilisation « Gérer suggestions » Nous présentons au niveau de la figure 6.2 le raffinement du cas d’utilisation « Gérer sugges- tions » dont le responsable RH a la possibilité d’effectuer toutes les fonctionnalités modélisées ci-dessous. 68
  • 86. Chapitre 6. Sprint3 : Affectation des stagiaires Figure 6.2: Raffinement du cas d’utilisation « Gérer suggestions » 6.2.1.3 Raffinement du cas d’utilisation« Gérer propositions d’encadrement » Le diagramme de la figure 6.3 présente le raffinement du cas d’utilisation « Gérer propo- sitions d’encadrement » en modélisant toutes les fonctionnalités qui sont à la disposition des encadrants. Figure 6.3: Raffinement du cas d’utilisation « Gérer propositions d’encadrement » – Description textuelle du cas d’utilisation « Accepter d’encadrer » La description textuelle représentée dans le tableau 6.2 montre le scénario du cas d’utilisation « Accepter d’encadrer » illustré dans la figure 6.3. Tableau 6.2: Description textuelle du cas d’utilisation « Accepter d’encadrer » Sommaire 69