Rapport finale

Rapport finale
Table de matiéres Liste des figures..........................................................................................................................5 Liste des tableaux.......................................................................................................................7 Introduction Générale.................................................................................................................8 Chapitre 1 : Contexte du projet ................................................................................................10 Introduction ............................................................................................................................10 1. Cadre du projet ...............................................................................................................10 1.1 IIT.............................................................................................................................10 1.1.1. Présentation ......................................................................................................10 1.1.2. Génie Logiciel et Informatique Décisionnelle........................................................10 1.2. L’organisme d’accueil.................................................................................................11 1.2.1. Présentation générale de PROXYM-GROUPE........................................................11 1.2.2. Présentation de PROXYM-IT...............................................................................13 2. Présentation du projet ....................................................................................................14 2.1. Sujet.........................................................................................................................14 2.2. Problématique ...........................................................................................................14 3. Etude de l’existant...........................................................................................................15 3.1. Présentation de l’existant...........................................................................................15 3.2. Critique de l’existant..................................................................................................15 4. L'objectif du projet .........................................................................................................15 5. Solution proposée ............................................................................................................16 6. Méthodologie....................................................................................................................18 6.1. Choix de la démarche de conception...........................................................................18 6.2. Méthodologie envisagée.............................................................................................19 Conclusion...............................................................................................................................27 Chapitre 2 Sprint 0 : Organisation et choix technologique ......................................................28 Introduction ............................................................................................................................28 1. Aspet fonctionnel.............................................................................................................28 1.1. Définition des exigences.............................................................................................28 1.1.1. Les besoins fonctionnels.....................................................................................28 1.1.2. Les besoins non fonctionnels ..............................................................................29 1.2. Cas d’utilisation global ...............................................................................................30 1.2.1. Identification des acteurs....................................................................................30
Gestion d’évaluationannuelle des compétences 2 1.2.2. Diagramme de cas d’utilisation global..................................................................30 1.3. Product Backlog.........................................................................................................32 1.4. Diagramme de paquetages.........................................................................................34 2. Aspet technique ...............................................................................................................36 2.1 Présentation de l’environnement................................................................................36 2.1.1. Environnement matériel.....................................................................................36 2.1.2. Environnement logiciel.......................................................................................36 2.2. Choix techniques .......................................................................................................39 2.2.1. Choix dulangage................................................................................................39 2.2.2. Les caractéristiques de JAVA...............................................................................40 2.3. Architecture JEE.........................................................................................................40 2.4. Framework................................................................................................................41 2.4.1. Spring................................................................................................................41 2.4.2. JUnit 5...............................................................................................................43 2.4.3. Hibernate ..........................................................................................................44 2.4.4. Angular 7...........................................................................................................44 2.5. Outils........................................................................................................................45 2.5.1. Npm..................................................................................................................45 2.5.2. Swagger-ui.........................................................................................................45 Conclusion...............................................................................................................................45 Chapitre 3 Sprint 1 : Authentification et gestion de la grille d’évaluation...............................46 Introduction ............................................................................................................................46 1. Objectif du sprint ............................................................................................................46 3. Sprint Backlog .................................................................................................................46 4. Spécification et analyse du sprint Backlog....................................................................47 4.1. User story 1...............................................................................................................47 3.1.1. Maquettage.......................................................................................................47 3.1.2. Diagramme de cas d’utilisation « gérerles grilles d’évaluations »..........................51 3.1.3. Diagramme de classes ........................................................................................52 3.1.4. Diagramme de séquence « gérerles grilles d’évaluations »...................................54 3.1.5 . Réalisationet validation......................................................................................59 3.2. User story 2...............................................................................................................63 3.2.1. Maquettage.......................................................................................................63 3.2.2. Diagramme de cas d’utilisation « authentification » .............................................64 3.2.3. Diagramme de classes ........................................................................................65
Gestion d’évaluationannuelle des compétences 3 3.2.4. Diagramme de séquence « authentification » ......................................................66 3.2.5. Réalisationet validation......................................................................................66 5. Conclusion........................................................................................................................67 Chapitre 4 Sprint 2 : Assignation et évaluation........................................................................68 Introduction ............................................................................................................................68 1. Objectif du sprint ............................................................................................................68 2. Sprint Backlog .................................................................................................................68 3. Spécification et analyse du sprint Backlog....................................................................69 3.1 User story 1...............................................................................................................69 3.1.1. Maquettage.......................................................................................................69 3.1.2. Diagramme de cas d’utilisation « gérer les rôles».................................................70 3.1.3. Diagramme de séquence « gérer des rôle »..........................................................72 3.1.4. Réalisationet validation......................................................................................73 3.2. User story 2....................................................................................................................74 3.2.1. Maquettage........................................................................................................74 3.2.2. Diagramme de cas d’utilisation « Affecter les grilles d’évaluations » ......................76 3.2.3. Diagramme de classes.........................................................................................77 3.2.4. Diagramme de séquence « Assignation des grilles d’évaluations ».........................79 3.2.5. Réalisation et validation...........................................................................................81 3.3. User story 3....................................................................................................................83 3.3.1. Maquettage........................................................................................................83 3.3.2. Diagramme de cas d’utilisation « Saisir une évaluation ».......................................83 3.3.3. Diagramme de classes ........................................................................................84 3.3.4. Diagramme de séquence « évaluation du collaborateur ».....................................85 3.3.5. Réalisation et validation...........................................................................................86 3.4. User story 4....................................................................................................................87 3.4.1. Maquettage.............................................................................................................87 3.4.2. Diagramme de cas « évaluation du manager ».....................................................88 3.4.3. Diagramme de séquence « évaluation du manager»............................................89 3.4.4. Réalisationet validation......................................................................................90 3.5. User story 5....................................................................................................................90 3.5.1. Maquettage.......................................................................................................90 3.5.2. Diagramme de cas d’utilisation « Saisir l’évaluation finale »..................................91 3.5.3. Diagramme de séquence « évaluation RH » .........................................................92 3.5.4. Réalisationet validation......................................................................................93
Gestion d’évaluationannuelle des compétences 4 Conclusion...............................................................................................................................93 Chapitre 5 Sprint 3 : Gestion du Reporting..............................................................................94 Introduction ............................................................................................................................94 1. Objectif du sprint ............................................................................................................94 2. Sprint Backlog .................................................................................................................94 3. Spécification et analyse du sprint Backlog....................................................................95 3.1 User story 1 et 2 ........................................................................................................95 3.1.1. Maquettage user story 1.....................................................................................95 3.1.2. Maquettage user story 2......................................................................................96 3.1.3. Diagramme de cas d’utilisation user story 1 et 2...................................................97 3.1.4. Réalisationet validation......................................................................................98 3.2. User story 3..................................................................................................................100 3.2.1. Maquettage...........................................................................................................100 3.2.2. Réalisation et validation.........................................................................................101 3.3. User story 4..................................................................................................................102 3.3.1. Maquettage.....................................................................................................102 3.3.2. Diagramme de cas d’utilisation « Planifier les dates d’évaluations finales »..........102 3.3.3. Diagramme de classes ......................................................................................104 3.3.4. Diagramme de séquence « Planification des dates d’évaluation » .......................105 3.3.5. Réalisationet validation....................................................................................106 3.4. User story 5..................................................................................................................107 3.4.1. Maquettage...........................................................................................................107 3.4.2. Réalisation et validation.........................................................................................108 4. Les services Web globaux :...........................................................................................109 Conclusion.............................................................................................................................109 Conclusion générale ...............................................................................................................110 Bibliographie ..........................................................................................................................111
Gestion d’évaluationannuelle des compétences 5 Liste des figures FIGURE 1 :QUELQUES CHIFFRES CLES DE PROXYM-GROUP..............................................................................................................11 FIGURE 2 :HISTORIQUEDE PROXYM-GROUP [1]............................................................................................................................12 FIGURE 3 :DOMAINES D’INTERVENTIONS DE PROXYM-IT................................................................................................................13 FIGURE 4 : LES DIFFERENTS METIERS DE PROXYM-IT.......................................................................................................................13 FIGURE 5 :L’ARCHITECTURE MICRO-SERVICES...............................................................................................................................17 FIGURE 6 :DEMARCHEDECONCEPTION ADOPTEE...........................................................................................................................19 FIGURE 7 :CYCLEDEVIEEN SCRUM.............................................................................................................................................23 FIGURE 8 :COLLABORATION DEL’EQUIPE.......................................................................................................................................25 FIGURE 9 :PLANNING POKER - LES REGLES DU JEU..........................................................................................................................26 FIGURE 10 :DIAGRAMMEDECAS D’UTILISATION GLOBAL...............................................................................................................31 FIGURE 11 : DIAGRAMMEDEPAQUETAGES..................................................................................................................................34 FIGURE 12 :ARCHITECTURE GLOBALE DENOTRE APPLICATION.........................................................................................................36 FIGURE 13 :MAQUETTE « LISTEDES GRILLES D’EVALUATION ».......................................................................................................48 FIGURE 14 :MAQUETTE « CREATION DES GRILLES D’EVALUATION,ETAPE 1 » .................................................................................48 FIGURE 15 :MAQUETTE « CREATION DES GRILLES D’EVALUATION,ETAPE 2 » .................................................................................49 FIGURE 16 :MAQUETTE « DETAIL DEGRILLED’EVALUATION »........................................................................................................50 FIGURE 17 :CAS D'UTILISATION « GERER LES GRILLES D’EVALUATIONS »..........................................................................................51 FIGURE 18 :DIAGRAMMEDECLASSES............................................................................................................................................54 FIGURE 19 :DIAGRAMMEDE SEQUENCE « CREATION D’UNEGRILLED’EVALUATION »......................................................................56 FIGURE 20 :DIAGRAMMEDE SEQUENCE « MODIFICATION D’UNEGRILLED’EVALUATION »..............................................................57 FIGURE 21 :DIAGRAMMEDE SEQUENCE « SUPPRESSION D’UNEGRILLED’EVALUATION ».................................................................58 FIGURE 22 :INTERFACE « LISTEDES GRILLES D’EVALUATION »........................................................................................................60 FIGURE 23 :INTERFACE « AJOUTER LACATEGORIE ET LES NIVEAUX D’UNEGRILLED’EVALUATION »..................................................61 FIGURE 24 :INTERFACE « LES MODULES,LES COMPETENCES,LES ECHELLES D’EVALUATION » ...........................................................62 FIGURE 25 :INTERFACE « AJOUTER LES NOTES MOYENNES » ..........................................................................................................62 FIGURE 27 :MAQUETTE « AUTHENTIFICATION »...........................................................................................................................63 FIGURE 28 :CAS D’UTILISATION « AUTHENTIFICATION ».................................................................................................................64 FIGURE 29 :DIAGRAMMEDECLASSES............................................................................................................................................65 FIGURE 30 :DIAGRAMMEDESEQUENCE« AUTHENTIFICATION »....................................................................................................66 FIGURE 31 :INTERFACE « AUTHENTIFICATION »............................................................................................................................67 FIGURE 32 :MAQUETTE « PAGED’ATTENTE »................................................................................................................................69 FIGURE 33 :MAQUETTE « GESTION DES ROLES »............................................................................................................................70 FIGURE 34 :CAS D'UTILISATION « GERER LES ROLES ».....................................................................................................................70 FIGURE 35 :DIAGRAMMEDESEQUENCE « GERER LES ROLES » .......................................................................................................72 FIGURE 36 :INTERFACE « PAGED’ATTENTE » ................................................................................................................................73 FIGURE 37 :INTERFACE « GESTION DES ROLES » ............................................................................................................................74 FIGURE 38 :MAQUETTE « LISTEDES COLLABORATEURS »...............................................................................................................75 FIGURE 39 :MAQUETTE « AFFECTATION DES GRILLES D’EVALUATION »..........................................................................................75 FIGURE 40 :CAS D'UTILISATION « AFFECTER LES GRILLES D’EVALUATIONS »....................................................................................76 FIGURE 41 :DIAGRAMMEDE CLASSES ...........................................................................................................................................78 FIGURE 42 :DIAGRAMMEDESEQUENCE « ASSIGNATION DES GRILLES D’EVALUATION »..................................................................79 FIGURE 43 :DIAGRAMMEDESEQUENCE « MODIFIER DES GRILLES D’EVALUATION ASSIGNEES ».......................................................80 FIGURE 44 :INTERFACE « LISTEDES COLLABORATEURS »................................................................................................................81 FIGURE 45 :INTERFACE « ASSIGNATION DES GRILLES D’EVALUATION »...........................................................................................82
Gestion d’évaluationannuelle des compétences 6 FIGURE 46 :MAQUETTE « EVALUATION DECOLLABORATEUR » ......................................................................................................83 FIGURE 47 :DIAGRAMMECAS D’UTILISATION « SAISIR UNEEVALUATION » ....................................................................................83 FIGURE 48 :DIAGRAMMEDECLASSES............................................................................................................................................84 FIGURE 49 :DIAGRAMMEDE SEQUENCE « EVALUATION DU COLLABORATEUR » ..............................................................................85 FIGURE 50 :INTERFACE « EVALUATION DU COLLABORATEUR ».......................................................................................................86 FIGURE 51 :INTERFACE « ECHELLES D’EVALUATIONS »...................................................................................................................87 FIGURE 52 :MAQUETTE « EVALUATION DE MANAGER » ................................................................................................................87 FIGURE 53 :DIAGRAMMECAS D’UTILISATION « SAISIR SAGRILLED’EVALUATION ».........................................................................88 FIGURE 54 :DIAGRAMMEDE SEQUENCE « EVALUATION DU MANAGER » ........................................................................................89 FIGURE 55 :INTERFACE « EVALUATION DU MANAGER ».................................................................................................................90 FIGURE 56 :MAQUETTE « EVALUATION DE RH » ..........................................................................................................................90 FIGURE 57 :DIAGRAMMECAS D’UTILISATION « SAISIR L’EVALUATION FINALE »..............................................................................91 FIGURE 58 :DIAGRAMMEDESEQUENCE « EVALUATION RH»........................................................................................................92 FIGURE 59 :INTERFACE « EVALUATION DU RH» ...........................................................................................................................93 FIGURE 60 :MAQUETTE « D’EVALUATION COURANTE ».................................................................................................................95 FIGURE 61 :MAQUETTE « HISTORIQUED’EVALUATION »...............................................................................................................96 FIGURE 62 :MAQUETTE « DETAIL D’EVALUATION ».......................................................................................................................96 FIGURE 63 :CAS D'UTILISATION « CONSULTER LES EVALUATIONS ».................................................................................................97 FIGURE 64 :INTERFACE « EVALUATION ACTUEL » ..........................................................................................................................98 FIGURE 65 :INTERFACE « HISTORIQUED’EVALUATION »................................................................................................................99 FIGURE 66 :INTERFACE « DETAIL D’EVALUATION ».....................................................................................................................100 FIGURE 67 :MAQUETTE « LISTES DES COLLABORATEURS » .........................................................................................................101 FIGURE 68 :INTERFACE « LISTES DES COLLABORATEURS »...........................................................................................................101 FIGURE 69 :MAQUETTE « PLANIFICATION DES DATES D’EVALUATIONS »......................................................................................102 FIGURE 70 :CAS D'UTILISATION « PLANIFIER LES DATES D’EVALUATIONS FINALES ».......................................................................102 FIGURE 71 :DIAGRAMMEDECLASSES.........................................................................................................................................104 FIGURE 72 :DIAGRAMMEDESEQUENCE « PLANIFICATION DES DATES D’EVALUATIONS »..............................................................105 FIGURE 73 :INTERFACE « AGENDAPOUR LAPLANIFICATION DES DATES D’EVALUATIONS »............................................................106 FIGURE 74 :FORMULAIRE « PLANIFICATION DES DATES D’EVALUATIONS »...................................................................................107 FIGURE 75 :MAQUETTE « CONSULTATION DES DATES D’EVALUATIONS ».....................................................................................107 FIGURE 76 :INTERFACE « AGENDAPOUR LACONSULTATION DES DATES D’EVALUATIONS »...........................................................108 FIGURE 77 :INTERFACE « VERIFICATION DEDATE DEREUNION POUR UN UTILISATEUR »...............................................................108 FIGURE 78 :PAGE « SERVICES WEB » AVEC SWAGGER-UI...........................................................................................................109
Gestion d’évaluationannuelle des compétences 7 Liste des tableaux TABLEAU 1 : ETUDE COMPARATIVEENTRE APPROCHETRADITIONNELLEET APPROCHE AGILE............................................................21 TABLEAU 2 : ETUDE COMPARATIVEENTRE LES METHODES AGILES....................................................................................................22 TABLEAU 3 :« PRODUCTBACKLOG »............................................................................................................................................34 TABLEAU 4 : SPRINT BACKLOG.......................................................................................................................................................47 TABLEAU 5 : LES CLASSES INDISPENSABLES.....................................................................................................................................53 TABLEAU 6 : LES CLASSES INDISPENSABLES AJOUTER.......................................................................................................................65 TABLEAU 7 :« SPRINT BACKLOG »................................................................................................................................................69 TABLEAU 8 : LES CLASSES INDISPENSABLES AJOUTER.......................................................................................................................78 TABLEAU 9 : LES CLASSES INDISPENSABLES AJOUTER.......................................................................................................................84 TABLEAU 10 :« SPRINT BACKLOG »..............................................................................................................................................95 TABLEAU 11 : LES CLASSES INDISPENSABLES AJOUTER..................................................................................................................104
Gestion d’évaluationannuelle des compétences 8 Introduction Générale De nos jours, l’évaluation fait partie de notre vie quotidienne, le fait de dire j’aime, ou je n’aime pas, veut dire qu’on évalue quelque chose subjectivement sans le savoir. Dans le monde des organisations, un nouveau concept s’impose, c’est celui de l’évaluation du personnel. Cette dernière influence bien le fonctionnement interne de l’entreprise ainsi que son développement. Pour se faire l’entreprise a besoin de dynamisme et d’innovation de la part des salariés, car la Ressource Humaine est un élément essentiel dans chaque entreprise. Ceci pousse les Direction de Ressource Humaine à évaluer les compétences de leurs employés pour déterminer s’ils sont aptes à exercer les tâches qui leurs sont assignées, ou, dans le cas échéant, les envoyés en formation pour se former. Dans le langage courant évaluer peut signifier : juger, peser, estimer, apprécier ou mesurer, Selon J. CARDINET : « Evaluer, c'est se situer par rapport au but ; prendre des informations sur le résultat déjà atteint, c'est une démarche fondamentale de toute activité qui tend vers un but. » De plus, pour mettre en place une performance économique, en adaptation aux changements technologiques, et réaliser les objectifs, l'entreprise est contrainte de valoriser, développer et fidéliser ses salariés pour un meilleur engagement et implication. Ce qui fait que les ressources humaines, dans ce nouveau contexte, constitue une richesse importante et une source de compétitivité et de performance et non un coût ou une charge comme le prétend la gestion des ressources humaines traditionnelle. Les évaluations font partie intégrante du fonctionnement d'une entreprise et constituent un des aspects de la gestion des compétences. Elles permettent de faire le point sur les capacités et les rendements du personnel dans l'entreprise afin de donner une idée au manager et au collaborateur des compétences réelles de la personne évaluée. Aussi, les évaluations ont d'autres portées qui se manifestent en termes de développement, et de fidélisation du personnel, de fixation des objectifs .... Ainsi, dans le grand ensemble que représente la gestion des compétences, l'évaluation des compétences elle aussi se constitue par plusieurs aspects ou caractéristiques. Pour mener à bien une évaluation, il faudrait déjà définir le type ou la méthode d'évaluation pour la structure ou l'organisation car chaque organisation a ses propres règles, sa culture, ses objectifs ....
Gestion d’évaluationannuelle des compétences 9 Dans ce contexte, PROXYM-IT ; la société qui m’a accueilli tout au long de mon stage, veut mettre en place une application pour gérer les évaluations annuelles des compétences. Le présent rapport décrit les phases du déroulement du projet et il est organisé en cinq chapitres. Le premier chapitre définit le contexte général du projet, il est composé de deux sections : la première présente l’organisme d’accueil ainsi que le cadre et les objectifs du projet, l’étude de l’existant et la solution proposée, la seconde définit le choix de la méthodologie de travail. Le second chapitre du rapport est le sprint 0. Il est consacré à la spécification des besoins fonctionnels et l’analyse qui permettent un repérage des besoins fonctionnels et opérationnels du futur système. Ce chapitre décrit aussi les outils et les technologies utilisés avant de présenter les écrans de l’utilisation du système. A partir du troisième chapitre sprint 1 nous nous intéressons s’intéressera à mettre le point sur les différentes phases de développement en se basant sur la méthodologie SCRUM. Par conséquent, Le quatrième chapitre c’est le sprint 2 et le cinquième chapitre présente le sprint 3. Nous clôturons ainsi la phase de réalisation pour en tirer les conclusions retenues et en ouvrir les horizons a des éventuelles améliorations.
Gestion d’évaluationannuelle des compétences 10 Chapitre 1 : Contexte du projet Introduction Ce chapitre présente d’une manière générale le contexte de travail et les objectifs de notre projet de fin d’études. Pour cela, nous commençons par présenter le cadre du projet. Puis, nous présentons la démarche de la conception et la méthodologie au long de notre travail. 1. Cadre du projet 1.1 IIT 1.1.1. Présentation L’IIT, Institut International de Technologie est une Université privée Tunisienne agrée par le Ministère de l’Enseignement Supérieur et de la Recherche Scientifique. Il a été inauguré le 23 Août 2012. Il a pour principal objectif l'employabilité, qui consiste pour elle à tout mettre en œuvre pour permettre à l'étudiant d'être immédiatement opérationnel au terme de ses études tout en développant en lui, la capacité d’évoluer dans de nouveaux métiers qu’il aura à exercer. L’université se compose de deux grandes écoles d’enseignement supérieur : 1. International School of Business (ISB), 2. Institut International de Technologie (IIT). Il y a deux filières pour le diplôme informatique : Génie Logiciel et Informatique Décisionnelle et Génie des Télécommunications. 1.1.2. Génie Logiciel et Informatique Décisionnelle La filière Génie Logiciel et Informatique Décisionnelle a pour objectif de former des ingénieurs maîtrisant les méthodes d’analyse et de conduite de projets informatiques ainsi que les langages et les outils menant au développement de logiciels. Les futurs diplômés de cette filière auront acquis la compétence et l’expérience pour suivre et piloter toutes les étapes du cycle de vie d’un projet leur permettant ainsi de s’intégrer parfaitement à des équipes de développement, ou encore d’assurer la responsabilité de chef de projet.
Gestion d’évaluationannuelle des compétences 11 1.2.L’organisme d’accueil 1.2.1. Présentation générale de PROXYM-GROUPE Figure 1 : Quelques chiffres clés de Proxym-Group PROXYM-GROUP est une société de services informatique fondée en janvier 2006 spécialisée dans les nouvelles technologies de l’informatique et de la communication. Sa direction commerciale est située à Lyon en France alors que sa direction technique est localisée à la technopole de Sousse en Tunisie. PROXYM-GROUP dispose d’une équipe de haut niveau composé d’ingénieurs issus de différentes formations élaborées au sein des écoles d’ingénieurs tunisiennes et françaises. La figure 1 expose quelques chiffres clés de Proxym-Group. (Proxym- Group) [1] Les entités de Proxym-Group sont :  ProxymIT : Un des leaders dans le secteur IT notamment les solutions convergentes autour du Web, Mobile et Systèmes d’information.  Valomnia : fondé en 2006, le groupe se spécialise dans les solutions d’entreprises, les projets e-gouvernement et e-administration, les applications mobiles et web et les ERP.  NaviaCom : Fournit une connectivité M2M entièrement gérée et des solutions télématiques aux entreprises et aux opérateurs.
Gestion d’évaluationannuelle des compétences 12  CalysIT : Fournit un produit qui gère, via un système informatique développé, les hôpitaux et les dossiers des patients par un pilotage quasi-parfait de l’ensemble du système de santé.  E Deleguation : Une agence digitale spécialisée en webmarketing et création de site internet.  ProxymFrance : Spécialiste dans les réalisations des applications web et mobiles et la transformation des systèmes d’informations.  Chifco : spécialisée dans le domaine de l’internet des Objets, le Machine Learning, le Big Data et la Business. Proxym Group est l'un des rares acteurs informatiques à réussir sur les marchés d'Europe et du Moyen-Orient. Ces marchés complémentaires ont permis à proxym d'étendre ses compétences à l'expérience utilisateur, à la conception graphique, à l'analyse commerciale, à la conception de solutions d'entreprise, à l'expertise bancaire, etc. Aujourd'hui, Proxym prépare son nouveau plan d'expansion (2018-2020) pour l'Afrique dans les domaines de la banque, de la santé en ligne et du gouvernement intelligent [1]. La figure 2 présente l’expansion de Proxym-Group. Figure 2 : Historique de Proxym-Group [1]
Gestion d’évaluationannuelle des compétences 13 1.2.2. Présentation de PROXYM-IT Les domaines d’interventions du Proxym-IT sont présentés dans la figure suivante. Figure 3 : Domaines d’interventions de Proxym-IT Proxym-IT travaille actuellement sur plusieurs axes à savoir le commerce électronique, le e- gouvernement, la santé, les réseaux sociaux, le secteur bancaire, etc. (voir figure 4). Figure 4 : Les différents métiers de Proxym-IT Proxym-IT est composé de :  Direction générale : La société Proxym-IT est gérée par M. Wassel Berrayana, un ancien responsable qualité de Sun Microsystems, qui cumule les fonctions du chef de projet et du directeur exécutif.
Gestion d’évaluationannuelle des compétences 14  Le service administratif et financier : effectue l’administration des opérations financières de Proxym-IT et la gestion des affaires administratives et financières des employés.  Le département APPS (Applications) : réalise des applications pour les entreprises telles que les sites web des entreprises, personnels, des portails, des intranets et extranets via les technologies : .NET, SharePoint, ERP et JEE ...  Le département Mobile : réalise des applications logicielles pour les appareils mobiles servant dans différents domaines, tels que la gestion de réseaux, la gestion des payements mobiles, la gestion bancaire et la géolocalisation via les technologies : iPhone, Android….  Le département WEB2.0 : Ce département intervient dans la réalisation d’applications Web.2.0, des boutiques E-Commerce et des sites web via des technologies et des plateformes avancées telles que Magento, Drupal, Joomla. 2. Présentation du projet 2.1.Sujet Chaque année, le groupe PROXYM-IT fait l’évaluation de ses salariés au niveau comportementale et technique en se basant sur des critères spécifiques qui aide à l’amélioration des performances et aussi à ajuster la rémunération du personnel, c’est grâce à cette technique que les décideurs puissent distinguer les personnes qui méritent d’être récompensées. Dans ce cadre, l’administration de PROXYM-IT m’a proposé de développer une application de gestion des évaluations annuelles des compétences. Mon projet de fin d’étude s’intitulé développement d’une application web de « gestion d’évaluation annuelles des compétences » est réalisé dans le but d’obtention d’un diplôme d’ingénieur en informatique option génie logiciel et informatique décisionnelle au sein de l’institut I.I.T. 2.2.Problématique Dans la société PROXYM-IT, la gestion d’évaluation annuelle des compétences pose un grand problème que ce soit pour le responsable ou pour les collaborateurs car l’opération de gestion des évaluations des compétences est une opération manuelle qui s’effectue sur des simples fichiers Excel. Ce qui cause des problèmes de différents types.
Gestion d’évaluationannuelle des compétences 15 3. Etude de l’existant 3.1.Présentation de l’existant L’étude de l’existant est une phase importante pour bien comprendre le système actuel et définir ses objectifs. Actuellement, la société Proxym-IT effectue l’évaluation des compétences d’une manière manuelle, étant donné que la responsable de ressource humaine stocke toutes les informations comme les grilles1, les échelles 2et les rapports 3d’évaluations sur des fichiers Excel. Aussi elle doit vérifier la date d’embauche de chaque collaborateur pour planifier les dates d’évaluations. 3.2.Critique de l’existant Les inconvénients majeurs que nous avons constatés se résument dans les points suivants :  La responsable de ressource humaine passe énormément de temps pour la construction des grilles d’évaluations.  La responsable de ressource humaine passe énormément de temps pour planifier les dates d’évaluations.  Difficulté d’accéder à l’historique des évaluations de chaque collaborateur qui sont très important pour faciliter au manager l’affectation des prochaines évaluations.  Les collaborateurs rencontrent des difficultés pour consulter l’historique de leurs évaluations.  Toutes les informations d’évaluation ne sont pas enregistrées dans une source de données unique. 4. L'objectif du projet Nous allons présenter dans ce qui suit les objectifs visés pour améliorer la gestion d’évaluation. Ces objectifs se résument dans les points suivants : 1 La grille d’évaluation présente les règles de compétences qui se compose par les différents modules comportementale et technique. 2 L’échelle d’évaluation présente les différentes notes pour mesurer chaque compétence. 3 Le rapport d’évaluation c’est le résultat de l’évaluation finale.
Gestion d’évaluationannuelle des compétences 16  Définir et maintenir des grilles d'évaluations selon différentes postes (développeur, senior, intégrateur).  Assigner les grilles aux collaborateurs.  Planifier des dates d’évaluation.  Effectuer l’auto-évaluation par les collaborateurs.  Effectuer l’évaluation hiérarchique.  Effectuer l’évaluation finale.  Accéder à l'historique des évaluations.  Générer des rapports d’évaluation.  Authentifier les utilisateurs avec gestion des droits d'accès.  Posséder une base de données unique. 5. Solution proposée Afin de pallier aux défaillances observées, notre mission était d’informatiser le processus de gestion des évaluations annuelles des compétences du PROXYM-IT. Pour cela, nous optons à développer une application web dynamique qui va être exploitée par plusieurs intervenants et son principal objectif est l’évaluation des compétences. Nous avons proposé aussi de suivre l’architecture micro-service. En effet, ce style d’architecture logicielle permet de découper une application complexe en un ensemble de services indépendants et faiblement couplés dont chaque service réalise une fonction précise. La figure 5 présente l’architecture micro-services.
Gestion d’évaluationannuelle des compétences 17 Figure 5 : L’Architecture Micro-services Les micro-services sont une approche d’architecture et de développement d’une application composée de petits services, l’idée étant de découper un grand problème en petites unités implémentée sous forme de micro-services et chaque service est responsable d’une fonctionnalité. [5] Chaque micro-service est développé, testé et déployé séparément des autres et tourne dans un processus séparé. Ils sont faiblement couplés puisque chaque micro-service est physiquement séparé des autres. [5] La seule relation entre les différents micro-services est l’échange de données effectué à travers les différentes APIs qu’ils exposent. (SOAP, REST, RMI, CORBA, JMS, …). Lorsqu’on les combine, ces micro-services peuvent réaliser des opérations très complexes. [5] Chaque micro service peut être conçu à l’aide de n’importe quel outil et développé avec n’importe quel langage et technologie. Il est facile a testé, a déployé et a livré. [5] Chaque Micro-service est parfaitement autonome : il a sa propre base de données, son propre serveur d'application (Tomcat, jetty, etc.), ses propres librairies et ainsi de suite. La plupart du temps ces Micro-services sont chacun dans un container Docker, ils sont donc totalement indépendants y compris vis-à-vis de la machine sur laquelle ils tournent. [5] Parmi les avantages [5] de l’utilisation de l’architecture micro-services, nous citons :
Gestion d’évaluationannuelle des compétences 18  La facilité de maintenabilité et de vérification de chaque micro-service.  L’utilisation de plusieurs plateformes et langages de programmation.  La diminution du degré de complexité grâce à la décomposition de l’application.  La factorisation et la réutilisation des micro-services.  La distribution des micro-services qui peuvent être exécutés sur la même machine ou être isolés sur une machine distincte.  La résilience grâce à la décomposition en processus systèmes techniquement indépendants. Cela assure la continuité du service lorsqu’une panne survient. 6. Méthodologie 6.1.Choix de la démarche de conception La conception présente une traduction des besoins. Afin de formaliser ces spécifications, nous avons utilisé le langage UML. UML (Unified Modeling Langage), est un langage de modélisation des systèmes standard, qui utilise des diagrammes pour représenter chaque aspect d'un système : statique, dynamique, .... En s'appuyant sur la notion de l’orienté objet qui est un véritable atout pour ce langage.[2] Dans la démarche suivie, comme présente dans la figure 4, nous exprimerons les besoins des clients recueillis à l'aide d'un diagramme de cas d'utilisation, pour permettre de les découper en fonctionnalités. Ensuite, nous répertorierons les objets à manipuler dans le système pour construire le diagramme de classes. Enfin, chacune de cas d’utilisation sera détaillée avec le diagramme de séquence, afin de décrire précisément l'enchainement des messages entre les utilisateurs et le système lors de la réalisation d'une fonctionnalité.
Gestion d’évaluationannuelle des compétences 19 Figure 6 : Démarche de conception adoptée 6.2.Méthodologie envisagée Le cycle de vie d’un logiciel (en anglais software life-cycle), désigne toutes les étapes du développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes mises en œuvre. Pour chaque produit (ou application) conçu et développé nous choisissons une démarche pour la suivre tout au long du projet que l’on appel cycle de vie du produit. Il existe plusieurs types de cycles de vie. (Cycle de vie en V, en cascade, spirale, ...). Le concept de méthodologie vient remplacer le cycle de vie et l’enrichi par une démarche organisationnelle du projet. La méthodologie permet ainsi de structurer, planifier et contrôler le processus de développement. Pour meilleur choix de la méthodologie adéquate, nous proposons de mener une étude comparative sur les méthodologies existante.
Gestion d’évaluationannuelle des compétences 20 Suite à cette étude comparative, nous avons dégagées le tableau 1 Qui présente la différence entre les méthode classique (cascade, Spirale, etc…) et les méthodes agiles (Scrum, XP, etc…) [22]. Thème Approche traditionnelle Approche Agile Cycle de vie En cascade ou en V, sans rétroaction possible, phases séquentielles. Itératif et incrémental. Planification Prédictive, caractérisée par des plans plus ou moins détaillés sur la base d’un périmètre et d’exigences définies et stables au début du projet. Adaptative avec plusieurs niveaux de planification macro et micro planification) avec ajustements si nécessaires au fil de l’eau en fonction des changement survenus. Documentation Produite en quantité importante comme support de communication, de validation et contractualisation. Réduite au strict au profit d’incréments fonctionnels opérationnels pour obtenir le feedback du client. Equipe Une équipe avec des ressources spécialisées, dirigées par un chef de projet. Une équipe responsable où l’initiative de la communication sont privilégiées, soutenus par le chef de projet. Qualité Contrôle qualité à la fin du cycle de développement. Le client découvre le produit fini. Un contrôle qualité et permanent, au niveau du produit et des ressources. Le client visualise les résultats tôt et fréquemment. Changement Resistance voire opposition au changement processus lourds de gestion des changements acceptés. Accueil favorable au changement inéluctable, intégré dans le processus. Suivi de l’avancement Mesure de la conformité aux plans initiaux. Analyse des écarts. Un seul indicateur d’avancement : le nombre de fonctionnalités implémentées et le travail restant à faire. Gestion des risques Processus distinct, rigoureux, de gestion des risques. Gestion des risques intégrée dans le processus global, avec responsabilisation de chacun dans l’indentification et la résolution des risques. Pilotage par les risques.
Gestion d’évaluationannuelle des compétences 21 Tableau 1 : Etude comparative entre Approche traditionnelle et Approche Agile Le tableau 2 décrit les méthodologies de développement ainsi que les points forts et les points faibles de chaque méthodologie [23]. Mesure succès Respect des engagements initiaux en termes de cout, de budget et de niveau de qualité. Satisfaction client par la livraison de valeur ajoutée. Description Points Forts Points faibles RUP (Rational Unified Process) - Le RUP est à la fois une méthodologie et un outil prêt à l'emploi (documents types partagés dans un référentiel Web). - Adapté pour des projets qui comportent plus de 10 personnes. - Itératif. - Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes… - Coûteux à personnaliser. - Très axé processus, au détriment du développement : peu de place pour le code et la technologie. XP (eXtreme Programming) - Méthode agile - Ensemble de « Best Practices » de développement (Idéal pour le travail en groupe). - Cible des projets de moins de dix personnes. - Itératif. - Simple à mettre en œuvre. - Fait une large place aux aspects techniques : prototypes, règles de développement, tests… - Une approche dénuée de modélisation. - Ne couvre pas les phases en amont et en aval au développement : capture des besoins, support, maintenance, tests d'intégration… - Assez flou dans sa mise en œuvre. Scrum - La méthode s'appuie sur le découpage d'un projet en « sprint », ainsi que l'auto- organisation de l'équipe de développement. - Réunions journalières. - Favoriser la notion de travail en équipe solidaire. - Adaptabilité aux modifications. - La méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Pour l'utiliser, il est nécessaire de la compléter avec des pratiques de qualité du logiciel. Par exemple, on
Gestion d’évaluationannuelle des compétences 22 Tableau 2 : Etude comparative entre les méthodes agiles Suite à l’étude comparative nous avons remarqué que les trois méthodologies étudiées permettent le travail itératif pour un meilleur suivi de l’avancement global du projet, et chacune met l’accent sur une phase bien déterminée du projet. Nous avons opté pour la méthodologie SCRUM qui est décrit par la figure 7 car elle satisfait les conditions suivantes : - Scrum convient aux équipes ayant un nombre de développeurs réduits. Ceci est le cas car le travail est individuel. - Le client est impliqué dans le développement de l’application : La consultation du client est nécessaire dès l’achèvement d’une tâche. - La progression des tâches s’effectue pendant une durée de développement courte. - Chaque sprint commence par une estimation suivie d'une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé, et contribue à augmenter la valeur d'affaires du produit. pourra utiliser pour résoudre les problèmes de l'Extrême de programmation.
Gestion d’évaluationannuelle des compétences 23 De nos jours, nous présentons dans ce qui suit une ample description de la méthodologie choisie à savoir SCRUM. Figure 7 : Cycle de vie en SCRUM Scrum est une méthode agile de type organisationnelle la plus répandue à ce jour créée par Ken Schwaber. Elle se base sur trois piliers essentiels : la transparence, l’inspection et l’adaptation.[7] 1. La transparence : un standard commun doit être élaboré pour permettre une compréhension partagée. 2. L’inspection : des vérifications sont à effectuer régulièrement. 3. L’adaptation : en cas de dérive constatée lors de l’inspection, des ajustements sont décidés. Elle se mélange très bien à d’autres méthodes agiles ou apparentées agiles comme kanban, extrême programming, Lean startup, …. En outre SCRUM est une méthode agile dédiée à la gestion de projets. Son objectif est d'améliorer la productivité des équipes. Scrum ne propose aucune pratique de développement, juste des pratiques de management et d’organisation du travail. Il s'agit en fait d'un cadre de gestion de projets bien adapté aux projets de développement logiciel dont les besoins peuvent évoluer au cours du temps. Il ne limite pas son champ d’application aux seuls projets informatiques : ses principes sont applicables pour toute activité visant à produire un résultat satisfaisant le client final. [8]
Gestion d’évaluationannuelle des compétences 24 Scrum identifie trois acteurs : 1. Le Product Owner (Directeur de Produit) : C’est le représentant des clients et des utilisateurs ; il a pour mission de : - Expliciter les éléments (Items) du carnet du produit (Product Back log). - Définir l’ordre dans lequel les fonctionnalités seront développées. - Prendre les décisions importantes concernant l’orientation du projet. 2. Le Scrum Master : C’est le responsable de la compréhension, de l’adhésion et de la mise en oeuvre de la méthode. Ses principaux rôles sont : - Coacher l’équipe de développement. - Écarter les éléments extérieurs pouvant perturbés l’équipe. - Résoudre les problèmes non techniques de l’équipe. 3. L’Equipe : Ce sont les personnes qui prennent en charge le développement du produit. Scrum est aujourd’hui l’une des méthodes agiles les plus populaires. Elle se caractérise par des itérations (appelées Sprints) qui durent de 2 à 4 semaines au maximum. Scrum définit également trois artefacts : 1. Le Product Backlog (Carnet de produit) : est la liste des fonctionnalités du logiciel. Les éléments du backlog sont rédigés sous forme de « User Stories » (un User Story est une forme simplifiée et faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métiers du produit. 2. Le Sprint Backlog : contient un ensemble d’éléments sélectionnés depuis le « Product Backlog » pour être développés au cours du Sprint. 3. Le Burndown Chart, qui est une représentation graphique très simple de l’avancement et le reste à faire du Sprint. Autre notion de Scrum, ce sont les 5 types de cérémonies qu’il identifie : 1. La planification de Sprint (Sprint planning), consiste à préparer et ordonner par priorité les User-Stories par le « Product Owner » et à la fin de la réunion une liste des user stories est sélectionnée pour le Sprint.
Gestion d’évaluationannuelle des compétences 25 2. La mêlée quotidienne (Daily Scrum) : c’est une réunion quotidienne qui dure entre 5 et 15 minutes. L’objectif essentiel de cette réunion est de répondre à ces trois questions :  Qu’est-ce que nous avons accompli hier ?  Qu’est-ce que nous allons faire aujourd’hui ?  Quels obstacles entravent nos progrès ? 3. La revue de sprint (Sprint Review), qui consiste pour l’essentiel, au terme de chaque Sprint, à faire une démonstration publique du résultat du Sprint avec le Product Owner et éventuellement avec les clients ou les utilisateurs afin d'en tirer les conséquences pour la suite du projet. 4. La rétrospective de sprint (Sprint Retrospective), qui réunit l’équipe Scrum au terme de chaque Sprint afin d’identifier les erreurs commises lors du Sprint précédent et de définir un plan d’actions en vue d’améliorer le processus. 5. Backlog Raffinement Meeting : l’équipe de développement estime l’effort nécessaire pour les user stories restants. Ainsi, le Product Owner pourrait les réorganiser avant la prochaine réunion (Sprint Planning Meeting). Les items dont le scope est assez large doivent être éclatés et raffinés. Cette réunion pourrait être nommé Backlog Maintenance, Backlog Grooming, ou encore Backlog Estimation Meeting. Estimation des coûts : Figure 8 : collaboration de l’équipe L’estimation des charges pour la réalisation d’une action ou d’une fonctionnalité est certainement l’une des tâches les plus complexes de la gestion d’un projet. La méthode agile SCRUM fournit à l’équipe de développement un outil particulièrement efficace pour réaliser des estimations de charges de réalisation : le planning poker SCRUM.
Gestion d’évaluationannuelle des compétences 26 Le principe du planning poker SCRUM : Figure 9 : Planning Poker - les règles du jeu Le planning poker SCRUM va réunir l’équipe du projet autour du Scrum Master qui va faire en sorte de faciliter les différents échanges qui pourront avoir lieux entre les participants autour des fonctionnalités étudiées. Tout l’intérêt du planning poker est que chacun est libre de s’exprimer comme il l’entend, et qu’il sera donc possible de croiser les différentes sources d’informations et les différents avis.[9] L’estimation des charges va porter sur un ensemble de fonctionnalités présentes dans le « Product Backlog » et identifiées par le « Product Owner » comme étant prioritaires et devant être embarquées dans le prochain « Sprint ». Le planning poker a donc lieu avant le démarrage d’un sprint afin de déterminer le coût de chaque fonctionnalité et lesquelles pourront effectivement être réalisées. [9] Lors de l’estimation de la charge de réalisation d’une fonctionnalité, les participants vont utiliser un jeu de cartes spécialement adapté à l’évaluation de la durée d’exécution et de la complexité des tâches. Les cartes comportent les valeurs suivent la suite de Fibonacci : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, « ∞ » et « ? ». [9] Une valeur de 0 représente une fonctionnalité déjà mise en place, ou ne demandant pas d’effort particulier. Les valeurs ½ et 1 peuvent être utilisées pour des tâches particulièrement simples, 3 et 5 pour des tâches un peu plus complexes. Au-delà, la réalisation demande des travaux plus conséquents ou plus complexes. [9] La valeur 100 représente une grande complexité et un grand nombre d’heures de travail. La carte portant le symbole « ∞ » (infini) représente toute tâche valant plus de 100 [9]. Il s’agit donc d’un travail particulièrement long ou complexe nécessitant une attention particulière.
Gestion d’évaluationannuelle des compétences 27 La carte portant le symbole « ? » indique que l’on n’est pas en mesure, dans l’état actuel des connaissances de l’équipe, d’effectuer une estimation pour la réalisation de cette fonctionnalité [9]. Conclusion Ce chapitre a été le point de départ pour la présentation de mon projet, dans la mesure où il décrit son contexte général en présentant l’organisme d’accueil PROXYM-IT, le cadre du projet, les objectifs généraux à atteindre, les étapes de leurs mises en œuvre et la méthodologie adoptée.
Gestion d’évaluationannuelle des compétences 28 Chapitre 2 Sprint 0 : Organisation et choix technologique Introduction Suite à une étude détaillée menée dans le chapitre précédent, nous avons opté pour une solution qui se base sur la méthodologie SCRUM. Ce chapitre sera donc consacré pour donner une idée claire sur la Sprint 0 du projet : c’est la période précédant le premier sprint. Elle est dédiée à l’organisation du projet : prise de connaissance avec le produit et avec les attentes des utilisateurs, et la création du backlog. 1. Aspet fonctionnel 1.1.Définition des exigences La modélisation du système commence par l’identification des acteurs et des cas d’utilisation et se poursuit par leur description à fin d’aboutir à une meilleure compréhension de la modélisation. L’application envisagée doit satisfaire les besoins fonctionnels qui seront exécutés par le système et les besoins non fonctionnels qui perfectionnent la qualité logicielle du système. 1.1.1. Les besoins fonctionnels L’analyse des besoins fonctionnels consiste à définir d’une manière complète les diverses fonctions de l’application à réaliser, ainsi que les informations manipulées. Ces besoins se résument dans les points suivants :  Gestion des Grilles d’évaluation : la responsable de ressource humaine doit créer, modifier, supprimer les grilles d’évaluations qui se compose par les étapes suivantes : o Création de la catégorie de la grille qui est relié à une catégorie socio-professionnelle. o Définir les différents niveaux pour la grille. o Etablir les différents modules de compétences. o Mise en place des compétences de chaque module. o Mise en place de l’échelle d’évaluations de chaque compétence. o Mettre les notes moyennes de chaque compétence pour chaque niveau.
Gestion d’évaluationannuelle des compétences 29  Gestion des rôles : chaque utilisateur peut accéder à l’application selon les droits d’accès.  Évaluation des développeurs : chaque développeur doit remplir la grille d’évaluation en mettant des notes pour chaque compétence.  Évaluation hiérarchique : le manager doit évaluer ses collaborateurs.  Assignation des grilles d’évaluations : le manager doit affecter à ses collaborateurs des grilles d’évaluations.  Planification des dates d’évaluation : la GRH doit assigner une date de réunion pour prendre les décisions des notes finales de l’évaluation annuelle avec le manager et ses collaborateurs.  Évaluation finale : au sein de la réunion d’évaluation, la GRH doit négocier avec le manager et son collaborateur afin de mettre les notes et le calcul du score finale.  PV de réunion : il présente le résultat d’évaluation finale pour savoir si le collaborateur se mérite d’une augmentation de la catégorie.  Accès à l’historique des évaluations : les utilisateurs peuvent consulter l’historique de leurs évaluations. 1.1.2. Les besoins non fonctionnels Les besoins non fonctionnels présentent les exigences internes pour le système qui sont primordiales pour atteindre notre objectif. Parmi ces besoins nous citons :  L’ergonomie : l’application web doit présenter des interfaces utilisateurs conviviales bien structurées du point de vue contenu informationnel. Cet effet est assuré par la combinaison du texte et du graphique avec un bon choix des couleurs et du style d’écriture.  Vérification des paramètres manipulés : l’application doit permettre la vérification des différents paramètres manipulés.  Facilité d’utilisation : l’application web doit être simple à utiliser.  Performance : l’application doit avoir des temps de réponse assez faibles pour permettre la réalisation des différentes étapes du travail de manière conviviale.  Maintenance : Le code doit être facile à maintenir pour des raisons de réutilisation et de modification.
Gestion d’évaluationannuelle des compétences 30  Fiabilité : l’application doit toujours être en mesure de fonctionner correctement, il ne doit pas y avoir des problèmes de fonctionnement ou des cas limites qui donnent des résultats non souhaités ou erronés. 1.2. Cas d’utilisation global Un cas d’utilisation est un moyen pour collecter et décrire les besoins des acteurs du système, nous commençons par identifier les acteurs ensuite nous avons donné un modelé de cas d’utilisation globale. 1.2.1. Identification des acteurs Un acteur représente un ensemble cohérent de rôles joués par des entités extrêmes (les personnes en interactions avec les cas d’utilisation) qui interagissent directement avec l’application. De ce fait, les acteurs de cette application sont :  La responsable RH : C’est l’acteur qui, une fois authentifié, utilise le système que ce soit pour une simple consultation ou pour la gestion des grilles d’évaluation, la gestion des rôles et planifier les dates d’évaluation.  Collaborateur : C’est l’acteur qui, une fois authentifié, peut faire son évaluation et consulter son historique d’évaluations.  Manager : C’est l’acteur qui, une fois authentifié, peut faire son évaluation et l’évaluation de ses collaborateurs, affecter des grilles d’évaluation à ses collaborateurs et consulter son historique d’évaluations. 1.2.2. Diagramme de cas d’utilisation global Le diagramme de cas d’utilisation modélise des interactions entre les utilisateurs et le système. Il définisse le comportement, les conditions et les contraintes, c’est une représentation des fonctionnalités du système suivant les points de vue des utilisateurs.
Gestion d’évaluationannuelle des compétences 31 Figure 10 : Diagramme de cas d’utilisation global
Gestion d’évaluationannuelle des compétences 32 1.3. Product Backlog Le Product backlog est un recueil des besoins qui peut évoluer au fur et à mesure que le produit ou le service est développé. Il est composé par des user stories plus ou moins abouties. Ce n'est pas un document exhaustif, Au contraire, nous pouvons toujours ajouter des détails descriptifs ou des critères d’acceptation supplémentaires. Avec le Product backlog, les intentions du projet se transforme en commandes explicites. Cette approche fonctionnelle réunit sur des affichettes tout ce que doit savoir l’équipe agile :  Les besoins.  Les améliorations.  Les correctifs à apporter. Le Backlog alors est un grand tableau listant les fonctionnalités prévues pour le produit et leur état d’avancement (en attente de développement, prévu, en cours, fini, …). Chacune est placée par ordre de priorité de haut en bas, celle en haut étant la prochaine fonctionnalité à développer. La rédaction d’une user story rend le besoin utilisateur simple et compréhensible. Cette phrase doit seulement contenir trois éléments descriptifs : Qui ❔ Quoi ❔ Pourquoi ❔ 1. Le contexte → En tant que « rôle » 2. La fonction → je veux « fonctionnalité » 3. Le bénéfice → afin de (pour) « raison / objectif » Et en tant que qualité de coach agile, on inspecte les user stories etles tâches grâce aux grilles de critères INVEST et SMART. La grille des critères INVEST permet de motiver les membres de l’équipe à modifier ou à mieux reformuler l'énoncé d'une user story. Une bonne user story est : 1. Independent → pas de dépendance entre les user stories. 2. Negotiable → la user story peut être arbitrée par le client et l'équipe. 3. Valuable → un besoin est toujours associé à la user story. 4. Estimable → l’équipe doit être en capacité d'estimer l’user story. 5. Small → la user story est décrite précisément. 6. Testable → les critères d’acceptation de user story sont atteignables. Les user stories sont décrites synthétiquement. Encourager l’équipe à détailler les tâches dont la réalisation est imminente.
Gestion d’évaluationannuelle des compétences 33 Nous pouvons alors évaluer la pertinence des tâches avec la grille de critères SMART : 1. Specific → toute votre équipe comprend ce qu’il y a à faire. 2. Mesurable → votre équipe sait comment s’assurer que la tâche est réalisée. 3. Achievable → votre équipe dispose de tous les moyens pour réaliser la tâche. 4. Relevant → la tâche participe bien à la concrétisation de la user story. 5. Time Bound → la tâche a une durée connue et limitée de travail. ID User Stories Priorité Temps 1  En tant que responsable RH je veux gérer les grilles d’évaluations pour que les collaborateurs puissent faire leurs évaluations. 1 21 J 2  En tant que responsable RH je veux planifier les dates des réunions finales pour que chaque développeur puisse terminer la phase d’évaluation de l’année courant. 11 8 J 3  En tant que responsable RH je veux gérer les rôles pour que chaque utilisateur ait ses propres permissions. 3 5 J 4  En tant que Manager je veux assigner les grilles d’évaluations de mes collaborateurs pour que ces derniers sachent leurs grilles assigner. 4 8 J 5  En tant que collaborateur je veux faire mon évaluation pour envoyer au GRH la partie d’auto-évaluation. 5 5 J 6  En tant que manager je veux remplir la grille d’évaluation de mes collaborateurs pour envoyer au responsable RH la partie d’évaluation hiérarchique. 6 5 J 7  En tant que responsable RH je veux faire une réunion pour l’évaluation finale de chaque collaborateur avec son manager pour savoir si le collaborateur se mérite d’une augmentation ou non. 7 5 J 8  En tant qu’utilisateur je veux consulter les grilles qui m’a été assignée pour faire l’évaluation. 8 3 J 9  En tant que collaborateur je veux consulter mon historique d’évaluation pour avoir une idée sur les anciennes grilles. 9 3 J 10  En tant que Manager je veux voir l’historique d’évaluation de mes collaborateurs pour avoir une idée sur les grilles assignées avant. 10 3 J
Gestion d’évaluationannuelle des compétences 34 11  En tant que responsable RH je veux consulter le calendrier pour savoir les dates des réunions. 12 5 J 12  En tant qu’utilisateur je veux m’authentifier pour pouvoir utiliser l’application. 2 8 J Tableau 3 : « Product backlog » 1.4. Diagramme de paquetages Un diagramme de paquetages est un diagramme UML qui fournit une représentation graphique de haut niveau de l'organisation de notre application et qui permet d’identifier les relations existantes entre les modules composant le système. La figure 11 illustre le diagramme de paquetages de notre application : Figure 11 : Diagramme de paquetages
Gestion d’évaluationannuelle des compétences 35 On connait tous le vieil adage « Diviser pour mieux régner », et le développement d’application est une science qui se prête plutôt bien à cette maxime. Et d’ailleurs on le voit encore plus vite en programmation orientée objet. Donc, comme le diagramme ci-dessus le montre, notre application est composée de 4 modules :  skills-evaluation-common : ce module peut être développé en tant que librairie indépendante (skills-evaluation-common.jar) et inclus dans les autres sous-projets selon leur besoin. Il peut contenir des classes utiles que tous les modules ont besoin.  skills-evaluation-persistance : ce module représente la couche d'accès aux données (également appelée DAO pour Data Access Object) chargée de l'accès aux données et de leur manipulation, indépendamment du SGBD choisi. Et il fournit les données stockées dans la base de données au niveau du module service. En appliquant seulement le patron de conception4 DAO5, la plupart du temps les méthodes des CRUD sont répétées et redéfinies dans chacun des DAO, la seule différence notable est le type des objets que ces méthodes prennent en paramètre.  skills-evaluation-service : c’est le module métier qui contient tous les services de l’application. Et il transite les informations entre les vues et la couche d’accès aux données (DAO). Dans une architecture en couche de service le patron de conception DAO doit être couplé avec un autre patron de conception intitulé GenericService qui permet aussi de ne pas répéter la glue code des services et les écrire une fois pour toutes dans un GenericService.  skills-evaluation--infrastructure : ce module contient les fichiers de configuration de création des infrastructures sur lesquels l’application peut être déployée. Docker va se baser sur ces fichiers pour créer les infrastructures complètes (système d’exploitation, serveur d’application, serveur de base des données…), et c’est le principe d’infrastructure.  Une chose importante est que chaque couche n'appelle que la couche immédiatement en dessous d'elle et n'a aucune connaissance des couches supérieures, comme l’illustre la figure 12. 4 Un patron de conception (Design Pattern) est une solution à un problème récurrent dans un contexte donné.On peut considérer un patron de conception comme une formalisation de bonnes pratiques, ce qui signifie qu'on privilégie les solutions éprouvées. 5 DAO est l'acronyme de Data Access Object. C'est un modèle de conception qui propose de découpler l'accès à une source de données.
Gestion d’évaluationannuelle des compétences 36 Figure 12 : Architecture globale de notre application 2. Aspet technique 2.1 Présentation de l’environnement Afin d’accomplir notre projet, nous avons eu recours à un environnement matériel et logiciel. 2.1.1. Environnement matériel Pour réaliser ce projet, nous avons utilisé l’ordinateur suivant :  Un PC ASUS possédant une RAM de capacité 8 GB/GO.  Un processeur Intel® Core™ i5 de fréquence d’horloge 2,20 GHz.  Système d’exploitation Windows 64 bits. 2.1.2. Environnement logiciel L’environnement logiciel que nous avons utilisé est constitué de : Draw.io : draw.io c’est un outil open source pour la création des diagrammes sur le navigateur web [6].
Gestion d’évaluationannuelle des compétences 37 Trello : Trello est un outil de gestion de projet en ligne, lancé en septembre 2011, et inspiré par la méthode Kanban de Toyota. Il est basé sur une organisation des projets en planches listant des cartes, chacune représentant des tâches. Les cartes sont assignables à des utilisateurs et sont mobiles d'une planche à l'autre, traduisant leur avancement [10]. PostgreSQL : PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD. Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils soient libres (comme MariaDB et Firebird), ou propriétaires (comme Oracle, MySQL, Sybase, DB2, Informix et Microsoft SQL Server). Comme les projets libres Apache et Linux, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et d'entreprises. [11] Apache Tomcat : Apache Tomcat est un conteneur web libre de servlets et JSP. Issu du projet Jakarta, c'est un des nombreux projets de l’Apache Software Foundation. Il implémente les spécifications des servlets et des JSP du Java Community Process, est paramétrable par des fichiers XML et des propriétés, et inclut des outils pour la configuration et la gestion. Il comporte également un serveur HTTP.[12]
Gestion d’évaluationannuelle des compétences 38 IntelliJ : IntelliJ, c’est l’environnement de travail qui permet la création des composants de notre application. IntelliJ IDEA également appelé « IntelliJ », « IDEA » ou « IDJ » est un environnement de développement intégré (en anglais Integrated Development Environment - IDE) de technologie Java destiné au développement de logiciels informatiques. Il est développé par JetBrains (anciennement « IntelliJ ») et disponible en deux versions, l'une communautaire, open source, et l'autre propriétaire, protégée par une licence commerciale. Tous deux supportent les langages de programmation Java, Kotlin, Groovy et Scala.[13] Il offre un ensemble de fonctionnalités comme :  L’auto-complétions intelligente.  Assistance spécifique au cadre  La ré-factorisation du code.  La détection de code dupliqué.  Le débogage du code. Serveur de gestion de versions : Git / GitLab Un gestionnaire de version est un logiciel permettant de stocker l’ensemble des fichiers de code source constituant un projet informatique. Il peut être centralisé où il existe un unique dépôt des versions faisant référence tels que Subversion et CVS, ou décentralisé où il existe plusieurs dépôts pour un même logiciel tels que Git, Mercural. [14]  Git C’est un logiciel de gestion de version distribué, très puissant et récent, il a été créé par Linus Torvalds, qui est entre autres l’homme à l’origine de Linux. Il se distingue par sa rapidité et sa gestion des branches qui permettent de développer en parallèle de nouvelles fonctionnalités. [14]
Gestion d’évaluationannuelle des compétences 39 La particularité qui marque Git est le fait de permettre à avoir plusieurs branches locales qui peuvent être totalement indépendantes les unes des autres. Leur création, fusion et suppression ne prend que quelques secondes. Les principales commandes [15] utilisées avec ce SGV sont :  clone : obtenir une copie d’un dépôt Git existant  checkout : récupérer une branche ou un chemin de l'arbre de travail  status : afficher l'état de la copie de travail, c'est à dire les fichiers qui ont été modifiés par rapport au référentiel.  add : préparer un fichier ou un répertoire à être ajouté sur le serveur  delete : préparer un fichier ou un répertoire à être supprimé du serveur  commit : envoyer les fichiers et les répertoires modifiés au serveur  GitLab GitLab est un serveur Git plus moderne et complet, il est une forge fonctionnant sur GNU/Linux. Il permet de gérer des dépôts Git ainsi que les utilisateurs et leurs droits d'accès aux dépôts. [14] 2.2. Choix techniques 2.2.1. Choix du langage JAVA : Les applications Java sont compilées en byte code (les fichiers *.class) destinées à être interprétées plus tard par la machine virtuelle de Java (Java Virtual Machine (JVM)). Il ne s’agit donc pas de code machine, mais d’un code intermédiaire. Une application Java est, en règle générale, un ensemble de fichiers .class regroupés dans un paquetage (package). Ce paquetage prend la forme d’une archive compressée avec le standard zip renommée en JAR, ou WAR s’il s’agit d’une application web. Une application Java peut ainsi être déployée sur n’importe quelle plateforme compatible Java (c’est-à-dire avec un Java Runtime Environment JRE) installé) sans être recompilée. On dit alors que les applications Java sont portables au niveau binaire.
Gestion d’évaluationannuelle des compétences 40 2.2.2. Les caractéristiques de JAVA  Fiabilité Java a été conçue pour que les programmes qui l'utilisent soient fiables sous différents aspects. Sa conception encourage le programmeur à traquer préventivement les éventuels problèmes, à lancer des vérifications dynamiques en cours d'exécution et à éliminer les situations génératrices d'erreurs... La seule et unique grosse différence entre C++ et Java réside dans le fait que ce dernier intègre un modèle de pointeur qui écarte les risques d'écrasement de la mémoire et d'endommagement des données.  Sécurité Java a été conçue pour être exploité dans des environnements serveur et distribués. Dans ce but, la sécurité n’a pas été négligée. Java permet la construction de systèmes inaltérables et sans virus.  Portable A la différence du C/C++, on ne trouve pas les aspects de dépendance de la mise en œuvre dans la spécification. Les tailles des types de données primaires sont spécifiées, ainsi que le comportement arithmétique qui leur est applicable. 2.3. Architecture JEE L’utilisation de la technologie JEE nous permet de bénéficier de ses principales caractéristiques qui sont :  Un seul langage : Java.  Une grande variété de plateformes et de systèmes d’exploitation sont capables de faire fonctionner une application JEE.  Il existe un grand nombre d’IDE déférents pour le développement. Il existe plusieurs Framework pour le développement d’une application avec la technologie J2EE.
Gestion d’évaluationannuelle des compétences 41 2.4. Framework 2.4.1. Spring SPRING est un Framework complet d’applications Java/Java EE, il est effectivement un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur d'application J2EE. Il prend donc en charge la création d'objets et la mise en relation d'objets par l’intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets. [4] Spring s’appuie [4] principalement sur l’intégration de trois concepts clés : 1. L’inversion de contrôle est assurée de deux façons différentes : la recherche de dépendances et l'injection de dépendances. 2. La programmation orientée aspect. 3. Une couche d’abstraction. La couche d’abstraction permet d’intégrer d’autres Framework et bibliothèques avec une plus grande facilité. Cela se fait par l’apport ou non de couches d’abstraction spécifiques à des Framework particuliers. Il est ainsi possible d’intégrer un module d’envoi de mails plus facilement. [4] Ce Framework, grâce à sa couche d’abstraction, ne concurrence pas d’autres Framework dans une couche spécifique d’un modèle architectural Modèle-Vue-Contrôleur mais s’avère être un Framework multicouche pouvant s’insérer au niveau de toutes les couches. [4] La programmation orientée aspect : La programmation orientée aspect (Aspect Oriented Programming ou AOP) est un paradigme de programmation qui permet de traiter séparément.  Les préoccupations transversales (Cross Cutting Concerns), qui relèvent souvent des aspects techniques (Journalisation, Sécurité, Transaction, …).  Des préoccupations métiers, qui constituent le cœur d'une application. Elle Permet aussi de séparer le code métier du code technique.
Gestion d’évaluationannuelle des compétences 42 L’inversion de contrôle : 1. La recherche de dépendance : consiste pour un objet à interroger le conteneur, afin de trouver ses dépendances avec les autres objets. C’est un cas de fonctionnement similaire aux EJB. 2. L’injection de dépendances : cette injection peut être effectuée de trois manières possibles :  L’injection de dépendance via le constructeur.  L’injection de dépendance via les modificateurs (setters).  L’injection de dépendance via une interface.  Spring Security Spring Security est une infrastructure Java/Java EE qui fournit des fonctionnalités d’authentification, d’autorisation et de sécurité pour les applications. Parmi les Fonctionnalités d'authentification de clé de spring Security on trouve LDAP que nous avons déjà utilisé dans notre application. LDAP est souvent utilisé par les organisations comme référentiel central d'informations utilisateur et comme service d'authentification. Il peut également être utilisé pour stocker les informations de rôle pour les utilisateurs de l'application.[16] Il existe de nombreux scénarios différents pour la configuration d'un serveur LDAP afin que le fournisseur LDAP de Spring Security soit entièrement configurable. Il utilise des interfaces de stratégie distinctes pour l'authentification et la récupération de rôle et fournit des implémentations par défaut pouvant être configurées pour gérer un large éventail de situations.[16] - Utilisation de LDAP avec Spring Security : L'authentification LDAP dans Spring Security peut être divisée en plusieurs étapes. L’obtention LDAP unique de « nom distinctif » ou DN, du nom de connexion. Cela impliquera souvent d'effectuer une recherche dans l'annuaire, à moins que le mappage exact des noms d'utilisateur sur les DN soit connu à l'avance. .[16]
Gestion d’évaluationannuelle des compétences 43 Authentification de l'utilisateur, soit en tant que tel, soit en effectuant une opération de « comparaison » à distance du mot de passe de l'utilisateur avec l'attribut password dans l'entrée de répertoire du nom distinctif. .[16] Chargement de la liste des autorités pour l'utilisateur. L'exception est lorsque l'annuaire LDAP est uniquement utilisé pour extraire des informations utilisateur et s'authentifier localement sur celui-ci. Cela peut ne pas être possible car les répertoires sont souvent configurés avec un accès en lecture limité pour des attributs tels que les mots de passe utilisateur. .[16] 2.4.2. JUnit 5 JUnit est un Framework mature pour permettre l'écriture et l'exécution de tests automatisés. JUnit 5 est une réécriture intégrale du Framework ayant plusieurs objectifs [17] tel que :  Le support et l'utilisation des nouvelles fonctionnalités de Java 8 : par exemple, les lambdas peuvent être utilisés dans les assertions.  Une nouvelle architecture reposant sur plusieurs modules.  Le support de différents types de tests.  Un mécanisme d'extension qui permet l'ouverture vers des outils tiers ou des API. Les classes de tests JUnit 5 sont similaires à celles de JUnit 4 : basiquement, il suffit d'écrire une classe contenant des méthodes annotées avec @Test. Cependant, JUnit 5 est une réécriture complète de l'API contenue dans des packages différents de ceux de JUnit 4. [17] JUnit 5 apporte cependant aussi son lot de nouvelles fonctionnalités :  Les tests imbriqués.  Les tests dynamiques.  Les tests paramétrés qui offrent différentes sources de données.  Un nouveau modèle d'extension.  L’injection d'instances en paramètres des méthodes de tests.
Gestion d’évaluationannuelle des compétences 44 2.4.3. Hibernate Hibernate est un Framework de mapping objet-relationnel ou de persistance objet de données. IL permet de réaliser le mapping entre des objets Java et une base de données relationnelle et assure ainsi la persistance des données. Hibernate s'occupe donc de transcrire des classes Java dans les tables de bases de données (et des types de données Java dans les types de données SQL). [18] 2.4.4. Angular 7 Angular est une Framework JavaScript permet de créer la partie frontend des applications web de type SPA (Single Page Application réactive). Une SPA est une application qui contient une seule page HTML (index.html) récupérée du serveur. .[19] Pour naviguer entre les différentes parties de cette application, JavaScript est utilisé pour envoyer des requêtes http (AJAX) vers le serveur pour récupérer du contenu dynamique généralement au format JSON. Ce contenu JSON est ensuite affiché coté client au format HTML dans la même page. Pour développer une application Angular il est recommandé d’utiliser Type Script qui sera compilé et traduit en JavaScript. TypeScript est un langage de script structuré et orienté objet qui permet de simplifier le développement d’applications Java Script. C’est un langage de programmation libre et open source développée par Microsoft qui a pour but d'améliorer et de sécuriser la production de code JavaScript car il est un sur-ensemble de JavaScript (c'est-à-dire que tout code JavaScript correct peut être utilisé avec TypeScript). .[19] Le code TypeScript est transcompilé en JavaScript, pouvant ainsi être interprété par n'importe quel navigateur web ou moteur JavaScript. TypeScript permet un typage statique optionnel des variables et des fonctions, la création de classes et d'interfaces, l'import de modules, tout en conservant l'approche non contraignante de JavaScript. Il supporte la spécification ECMAScript 6.[19]
Gestion d’évaluationannuelle des compétences 45 2.5. Outils 2.5.1. Npm Npm est le gestionnaire de paquets officiel de Node.js. C’est le plus grand registre de logiciel au monde. Il permet de gérer les dépendances pour une application. Mon application {coté client} contiennent un dossier nommé « nodeModules » qui contient toutes les dépendances de l’application. En effet, les dépendances sont des bouts de code publiés par des développeurs sous npm qui effectuent une tâche spécifique, que nous utilisons pour gagner le temps. Toutes les dépendances sont indiquées dans un fichier nommé «package.json».[20] 2.5.2. Swagger-ui Swagger est une spécification formelle entourée d’un grand écosystème d’outils (Core, Codegen, Editor, UI… etc.) qui permet de documenter, décrire, produire, visualiser et consommer des APIs REST. Cet outil permet aux différents utilisateurs (Frontend) et aux ordinateurs de découvrir et de comprendre les capacités des services Restful (Backend) sans accéder au code source.[21] Conclusion Le but de ce chapitre est le recueil de la spécification des besoins fonctionnels du système. Lors de la capture des besoins, nous avons décrit, d’une manière globale, le comportement du système, exprimé sous la forme de cas d’utilisation et d’acteurs et nous avons clôturé par définir l’environnement du projet, en mettant l’accent sur les technologies utilisées.
Gestion d’évaluationannuelle des compétences 46 Chapitre 3 Sprint 1 : Authentification et gestion de la grille d’évaluation Introduction Dans ce sprint nous allons commencer par l’élaboration de son objectif et de mettre en évidence les besoins à satisfaire. Nous allons nous intéresser au développement de l’interfaces principales de notre application ; de la construction de la grille d’évaluation et de l’authentification après avoir exposé le Backlog du sprint. Nous allons d’abord décrire la conception. Ensuite nous allons présenter la partie réalisation. 1. Objectif du sprint Ce sprint présent le démarrage de notre projet, nous avons commencé par implémenter le module de construction de la grille et le module d’authentification. 3. Sprint Backlog Le Sprint Backlog est un extrait plus développé et détaillé du Product Backlog correspond à tout le périmètre qui doit être produit au cours du présent sprint. Il est présenté sous forme d'un tableau (scrum board) pour rendre visible toute la gestion de l'itération. Afficher les user Stories du sprint, ainsi que les tâches décrivant les actions définies par l'équipe de développement. User Stories Priorité  En tant que RH je veux gérer les grilles d’évaluations pour que les collaborateurs puissent faire leurs évaluations. 1 Taches Durée - Créer une grille d’évaluation (Front et back) 7J - Modifier une grille d’évaluation (Front et back) 7J - Supprimer une grille d’évaluation (Front et back) 5J - Lister les grilles d’évaluations (Front et back) 2J  En tant qu’utilisateur je veux s’authentifier pour puisse utiliser l’application. 2
Gestion d’évaluationannuelle des compétences 47 Tableau 4 : Sprint Backlog 4. Spécification et analyse du sprint Backlog 4.1. User story 1 3.1.1. Maquettage Le Maquettage est la démarche qui consiste à réaliser un prototype. Ce prototype est un exemplaire incomplet et non définitif de ce que pourra être le produit ou l'objet final. le maquettage est une technique encore très utilisée dans la conception centrée sur l'utilisateur. Cette technique aide les parties prenantes d'un projet (concepteurs, développeurs) à concevoir l’application qui répondent aux attentes et besoins des utilisateurs finaux. Il s'agit le plus souvent des premières idées brutes jetées, faites d'esquisses et de dessins, représentant l'agencement et les zones de contenus. Nous parlons également de maquette fil de fer ou wireframe (Le wireframe ou maquette fonctionnelle est un schéma utilisé lors de la conception d'une interface utilisateur pour définir les zones et composants qu'elle doit contenir). Par la suit, nous avons présenté quelques maquettes concernant :  Liste des grilles d’évaluation  Création des grilles d’évaluation  Détail d’une grille d’évaluation Taches Durées - Création de l’interface d’authentification 2J - Création du service d’authentification 3J - Configuration LDAP 3J
Gestion d’évaluationannuelle des compétences 48 La figure 13 présente la maquette de la liste des grilles d’évaluation : Figure 13 : Maquette « liste des grilles d’évaluation » Les deux figures (figures 14) et 15 présentent les maquettes de la création d’une grille d’évaluation : Cette phase consiste en trois étapes, la première (figure 14) permet de définir la catégorie et les sous catégories. Figure 14 : Maquette « création des grilles d’évaluation, étape 1 »
Gestion d’évaluationannuelle des compétences 49 La deuxième phase (figure 15) permet de définir les modules, les compétences, et les échelles d’évaluation et les notes moyennes. Figure 15 : Maquette « création des grilles d’évaluation, étape 2 » La troisième phase (figure 16) permet de présenter les détails d’une grille d’évaluation crée :
Gestion d’évaluationannuelle des compétences 50 Figure 16 : Maquette « détail de grille d’évaluation »
Gestion d’évaluationannuelle des compétences 51 3.1.2. Diagramme de cas d’utilisation « gérer les grilles d’évaluations » Figure 17 : cas d'utilisation « gérer les grilles d’évaluations » Nom du cas d’utilisation Ajouter une grille d’évaluation Objectif Permettre la création d’une grille d’évaluation en introduisant toutes les informations nécessaires Acteur Responsable Ressource Humaine Flot de données Saisir toutes les informations nécessaires et valider Pré Conditions Responsable Ressource Humaine identifié et consulté la liste des grilles d’évaluation. Post Conditions Grille d’évaluation créée Exception Catégorie de grille déjà existante, Format erronés des données saisies, connexion refusée.
Gestion d’évaluationannuelle des compétences 52 Nom du cas d’utilisation Modifier une grille d’évaluation Objectif Permettre la mise à jour d’une grille d’évaluation. Acteur Responsable Ressource Humaine. Flot de données Message de confirmation de modification. Pré Conditions Choix d’une grille d’évaluation. Post Conditions Grille modifiée. Exception Format fausse des données saisies, connexion refusée. Nom du cas d’utilisation Supprimer une grille d’évaluation Objectif Permettre la suppression d’une grille d’évaluation Acteur Responsable Ressource Humaine Flot de données Message de confirmation de suppression Pré Conditions Choix d’une grille d’évaluation Post Conditions Grille supprimée Exception Connexion refusée 3.1.3. Diagramme de classes En général, le diagramme de classes représente la structure statique d’un modèle, à savoir les éléments (classes et types), la structure interne des éléments et leurs relations les uns par rapport aux autres. Ce diagramme (figure 18) représente les classes, les paquetages ou les interfaces connectés par des relations statiques. Il constitue donc un élément très important de la modélisation car il permet essentiellement de :  Définir qu’elles seront les composantes du système.  Représenter l'organisation des données dans les systèmes d'information.  Structurer le travail de développement de manière très efficace.
Gestion d’évaluationannuelle des compétences 53 a. Description des classes Dans cette partie nous allons procéder au recensement des classes indispensables pour remplir les fonctionnalités de ce user story. Le « tableau 5 » présente ces classes et leurs descriptions : Classe Description Grid-Evaluation  Représente les différents types des grilles d’évaluations de Proxym. Level  Représente l'ensemble des niveaux de chaque grille d’évaluation. Skill-Module  Présente les modules de chaque grille d’évaluation. Skill  Présente les compétences de chaque module d’une grille d’évaluation. Scale-Evaluation  Représente les échelles des évaluations de chaque grille crée. Average-Note  Présente les notes moyennes de chaque compétence pour chaque niveau d’une grille d’évaluation. Tableau 5 : Les Classes indispensables b. Diagramme Ce diagramme est composé essentiellement de classes et de relations entre les classes qui constituent la future application et servent à en décrire les principales méthodes ainsi que leurs attributs et leurs comportements comme le montre la figure 18. Ce diagramme évolue d’un sprint à un autre. Il subit dès amélioration au cours du sprint.
Gestion d’évaluationannuelle des compétences 54 Figure 18 : Diagramme de classes 3.1.4. Diagramme de séquence « gérer les grilles d’évaluations » Le diagramme de séquence permet de représenter les vues dynamiques du système. Il s'agit de la représentation des interactions entre les objets selon un point de vue temporel en mettant l’accent sur la chronologie des envois de messages. Le diagramme est structuré de la manière suivante :

Rapport finale

Recommended

More Related Content

Slideshows for you(19)

Similar to Rapport finale(20)

More from Hassen BEN SLIMA(9)

Recently uploaded(20)

Rapport finale