1
Dédicaces
Au symbole de douceur, de tendresse, d’amour et
d’affection, ma mère pour son soutien incessant.
A mon père, pour les sacrifices qu’il a consentis pour
mon éducation.
Que ce travail soit le témoignage de l'amour que je lui avoue.
A mon cher frère Amin qui qui m'a été d'un soutien
indéniable, que dieu te procure bonne santé et une longue
vie.
A mes chers amis qui m'ont soutenue, encouragée et
m'ont surtout permis de travailler dans une atmosphère
joviale.
Soumow
2
Remerciements
C'est avec un grand plaisir que je réserve cette page en signe de gratitude
et de profonde reconnaissance à tous ceux qui m'ont aidé à la réalisation de ce
travail.
Tout d’abord, je tiens à remercier la société OXIA qui m’a accueilli. En
effet j’ai eu le plaisir et l’honneur de travailler au sein d’une aussi grande
entreprise.
J'adresse mes sincères remerciements à mon encadreur Mr Amine
Laroussi, pour sa disponibilité, sa générosité, son encadrement de qualité et pour
tous ses conseils judicieux tout au long de mon projet.
Je remercie également mon encadreur à la Faculté des sciences de Tunis,
Mr Samir Elloumi pour son aide précieux, sa qualité d'encadrement et le savoir
qu'il m'a transmis.
Mes remerciements et reconnaissances s'étendent également à toute la
famille OXIA pour leur chaleureux accueil et particulièrement Mr Khaled Ben
Driss, Directeur Technique chez OXIA, pour sa disponibilité, sa clairvoyance et
son expérience qu’il nous a fait partager, et Mr Mohamed Karim Lili,
développeur chez OXIA, pour tous ses conseils et son soutien moral incessant.
Enfin, je tiens à remercier l'équipe de développeurs, constitué de Mr
Hassen Khalifa et Mr Jed Miled, avec qui j’ai travaillé tout au long de ce projet,
nous avons formé une équipe soudée et homogène dans le but de réussir notre
projet.
3
Table des matières
CHAPITRE 1 PRESENTATION DU CADRE DU PROJET ........................................ 12
INTRODUCTION .................................................................................................................. 13
1. PRESENTATION DE L’ORGANISME D’ACCUEIL .................................................. 13
1.1. MISSION .......................................................................................................................... 13
1.2. DOMAINES DE COMPETENCES .......................................................................................... 14
1.2.1. Finance .................................................................................................................... 14
1.2.2. Solutions de Gestion d’Entreprises ......................................................................... 14
1.2.3. e-business ................................................................................................................ 14
1.2.4. Télécommunications ............................................................................................... 14
2. ETUDE DE L’EXISTANT ................................................................................................ 14
3. CRITIQUE DE L’EXISTANT .......................................................................................... 15
4. SOLUTION PROPOSEE .................................................................................................. 15
5. METHODOLOGIE DU TRAVAIL ................................................................................. 16
5.1 METHODE AGILE .............................................................................................................. 16
5.1.1 Définition .................................................................................................................. 16
5.1.2 Valeurs des méthodes Agiles .................................................................................... 16
5.1.3 Principes des méthodes Agiles ................................................................................. 16
5.2 CHOIX DE LA METHODE AGILE SCRUM .......................................................................... 17
5.2.1 Définition .................................................................................................................. 17
5.2.2 Justification du choix ................................................................................................ 17
5.2.3 Mise en œuvre .......................................................................................................... 18
5.2.4 Planification .............................................................................................................. 19
5.2.5 Gestion des besoins .................................................................................................. 20
5.3 CHOIX CONCEPTUELS ....................................................................................................... 21
4
5.3.1 Choix de l’approche Objet ........................................................................................ 21
5.3.2 Langage de modélisation : UML .............................................................................. 22
5.3.3 Outils logiciel de conception .................................................................................... 22
CONCLUSION ....................................................................................................................... 23
CHAPITRE 2 SPECIFICATION DES BESOINS ........................................................... 24
INTRODUCTION .................................................................................................................. 25
1. SPECIFICATION INFORMELLE .................................................................................. 25
1.1. BESOINS FONCTIONNELS................................................................................................. 25
1.2. BESOINS NON FONCTIONNELS ......................................................................................... 26
2 IDENTIFICATION DES CAS D’UTILISATION ........................................................... 26
2.1 Définition ..................................................................................................................... 26
2.2 Diagrammes des cas d’utilisation : Framework .......................................................... 27
2.3 Diagrammes des cas d’utilisation : Workflow Recrutement ....................................... 28
3. VUE DYNAMIQUE : DIAGRAMME D’ACTIVITES .................................................. 34
3.1 DIAGRAMME D’ACTIVITE : FLUX DE TRAVAIL DE RECRUTEMENT .................................... 35
CONCLUSION ....................................................................................................................... 36
CHAPITRE 3 CONCEPTION DE LA SOLUTION ....................................................... 37
INTRODUCTION .................................................................................................................. 38
1. VUE STATIQUE : DIAGRAMME DE CLASSE ........................................................... 38
DESCRIPTION DU DIAGRAMME DE CLASSE .............................................................................. 40
2. DIAGRAMME DE SEQUENCE ...................................................................................... 42
2.1. DIAGRAMME DE SEQUENCE FRAMEWORK ....................................................................... 43
2.1.1. Diagramme de séquence : Administrateur Recrutement ......................................... 43
2.3. DIAGRAMME DE SEQUENCE WORKFLOW RECRUTEMENT ................................................ 45
2.3.1. Diagramme de séquence : Authentification ............................................................. 45
2.3.2. Diagramme de séquence : Chargé Recrutement ...................................................... 47
5
2.3. Diagramme de séquence : Evaluateur ........................................................................ 53
CONCLUSION ....................................................................................................................... 54
CHAPITRE 4 REALISATION ........................................................................................... 55
INTRODUCTION .................................................................................................................. 56
1. PRESENTATION DE L’ARCHITECTURE .................................................................. 56
1.1 CHOIX DE L’ARCHITECTURE ............................................................................................. 56
1.2 STRUCTURE DE L’APPLICATION ........................................................................................ 57
1.2.1 Présentation Layer .................................................................................................... 57
1.2.2 Service Layer ............................................................................................................ 58
1.2.3. Business Layer ......................................................................................................... 58
1.2.4. Data Layer ............................................................................................................... 58
1.2.5. Framework ............................................................................................................... 58
1.3 SCHEMA DE DEPENDANCE ENTRE COUCHES ...................................................................... 58
2. ENVIRONNEMENT DE DEVELOPPEMENT ............................................................. 60
2.1. ENVIRONNEMENT MATERIEL ........................................................................................... 60
2.2. ENVIRONNEMENT LOGICIEL ............................................................................................ 60
2.2.1 Framework utilisé ..................................................................................................... 60
2.2.2 Technologies de développement .............................................................................. 62
2.2.3 Langage de développement ...................................................................................... 64
2.2.4 Logiciels utilisés ....................................................................................................... 65
3. SCENARIOS D’EXECUTION ......................................................................................... 68
3.1 INTERFACES DU FRAMEWORK .......................................................................................... 68
3.1.1 Authentification ........................................................................................................ 68
3.1.2 Interface principale ................................................................................................... 69
3.1.3 Paramétrage des acteurs du workflow Recrutement ................................................. 70
3.1.4 Paramétrage des autorisations du workflow Recrutement ....................................... 71
6
3.1.5 Interface d’aide à la saisie : Recherche F12 ............................................................. 71
3.2 PRINCIPALES INTERFACES DU WORKFLOW RECRUTEMENT .............................................. 72
3.2.1 Ecran Candidat ......................................................................................................... 72
3.2.2 Ecran Test/Entretien ................................................................................................. 75
4. GESTION DU PROJET .................................................................................................... 77
CONCLUSION ....................................................................................................................... 78
CONCLUSION GENERALE ............................................................................................... 80
ANNEXES ............................................................................................................................... 82
ANNEXE A : DIAGRAMME DE FLUX DE CANDIDAT ................................................ 83
ANNEXE B : SCHEMATIQUEMENT WORKFLOW RH .............................................. 84
ANNEXE C : UML ................................................................................................................ 85
GLOSSAIRE ........................................................................................................................... 87
7
Liste des figures
Figure 1.1 : Logo de OXIA ..................................................................................................... 13
Figure 1.2 : Vue globale du processus Scrum ....................................................................... 21
Figure 1.3 : Emblème de SYBASE PowerAMC ................................................................... 22
Figure 2.1 : Diagramme des cas d’utilisation Framework .................................................. 27
Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement » ................ 30
Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement » .................................... 31
Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction » ................................. 33
Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur » ............................................. 34
Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement................................. 35
Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement .................................. 39
Figure 3.2 : Diagramme de séquence : Administration ....................................................... 43
Figure 3.3 : Diagramme de séquence : Authentification ..................................................... 45
Figure 3.4 : Diagramme de séquence : Insertion Candidat ................................................. 47
Figure 3.5 : Diagramme de séquence : Affichage Candidat ................................................ 49
Figure 3.6 : Diagramme de séquence : Planification Entretien .......................................... 51
Figure 3.7 : Diagramme de séquence : Réalisation Entretien ............................................. 53
Figure 4.1 : Architecture commune d’une application ........................................................ 56
Figure 4.2 : Structure en couche du Framework OXIADOTNET ..................................... 57
Figure 4.3 : Schéma de dépendance entre couches ............................................................... 59
Figure 4.4 : Logo Microsoft .NET .......................................................................................... 60
8
Figure 4.5 : Logo Microsoft Entreprise Library 5.0 ............................................................ 61
Figure 4.6 : Microsoft Visual Studio 2010 Ultimate ............................................................. 65
Figure 4.7 : Microsoft Expression Blend 4 ............................................................................ 66
Figure 4.8 : Oracle ................................................................................................................... 67
Figure 4.9 : Tortoise SVN ....................................................................................................... 67
Figure 4.10 : Interface d’authentification ............................................................................. 68
Figure 4.11 : Interface Principale .......................................................................................... 69
Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement ................................... 70
Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement ......................... 71
Figure 4.14 : Fenêtre d’aide à la saisie .................................................................................. 71
Figure 4.15 : Interface Candidat ............................................................................................ 72
Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles ...................................... 73
Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience ....................... 73
Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications .................................. 73
Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience .... 74
Figure 4.20 : Ecran Candidat pour offre .............................................................................. 74
Figure 4.21 : Ecran Candidat : Offre à Faire ....................................................................... 75
Figure 4.23 : Ecran Entretien non planifié ........................................................................... 76
Figure 4.24 : Ecran planifier Entretien ................................................................................. 76
Figure 4.25 : Ecran Test planifié ............................................................................................ 77
Figure 4.26 : Diagramme de Gantt ........................................................................................ 78
9
Figure A.1 : Diagramme de flux de candidat ........................................................................ 83
Figure B.1 : Schématiquement workflow RH ....................................................................... 84
Figure C.1 : Emblème officiel d’UML ................................................................................... 85
10
Introduction Générale
La gestion des ressources humaines occupe aujourd'hui une place prépondérante au
sein de l'entreprise. Sa stratégie permet ainsi aux entreprises de diminuer les risques sociaux
internes à l'organisation comme les grèves, les plans sociaux, les conflits inter salariés. Un
secteur aujourd'hui considéré comme un des maillons les plus importants de l'entreprise. Au
niveau du management général, on cherche à optimiser l'apport des ressources humaines à
partir des éléments par lesquels on agit habituellement sur celles-ci : compétence, motivation,
information, organisation, gestion des groupes.
Le but des ressources humaines est donc de maintenir une gestion efficace des
employés, autant qualitative que quantitative, pour permettre à l’entreprise de prospérer grâce
à un personnel compétent et en nombre suffisant, Ce qui fait de la performance de la fonction
RH (ressources humaines) le cœur des préoccupations actuelles des DRH (direction
ressources humaines). La mesure de la performance dépend naturellement des objectifs fixés à
la fonction.
De ce fait le recrutement, l’une des missions confiées à la fonction RH, s’annonce une
tache de plus en plus ardue, exigeant plus de fiabilité et un temps de gestion minimale avec un
taux de certitudes et d’exactitude maximale.
C’est dans ce cadre que s’inscrit notre projet de fin d’études réalisé chez « OXIA
Tunisie », intitulé : « Conception et réalisation d’une Application de flux de travail de
recrutement ».
Le présent travail se veut une contribution à la mise en place d’une application pour
automatiser les activités du service recrutement. Pour mener à bien la réalisation de cet
objectif, une étude théorique du concept « Flux de travail de Recrutement» s’impose dans le
but de cerner les principales fonctionnalités et comprendre les besoins de la société.
Afin d’illustrer la démarche de notre travail, nous vous présenterons dans ce qui suit
l’organisation générale du rapport. Le présent rapport s’articule autour de cinq chapitres :
Dans le premier chapitre, nous vous exposerons le cadre du projet à travers une
présentation de la société, une étude minutieuse de l’existant (description et critique), pour
enfin conclure avec la solution proposée et la méthodologie utilisée.
11
Le deuxième chapitre sera consacré à la spécification des besoins en termes de besoins
fonctionnels et non-fonctionnels.
Dans le troisième chapitre qui concerne le volet de la conception, on présentera les
différents diagrammes statiques et dynamiques.
Le dernier chapitre sera consacré à la réalisation. L’architecture globale de la solution,
L'environnement matériel et logiciel détaillé du travail seront présentés, ainsi que quelques
captures d’écrans de l'application développée.
Pour conclure, nous présentons les connaissances acquises durant ce stage et nous
proposons comme extension logique de ce projet un ensemble de perspectives.
12
CHAPITRE 1
PRESENTATION DU CADRE DU PROJET
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
13
Introduction
Dans ce premier chapitre, nous présentons l’organisme d’accueil qui est la société
« OXIA », à travers sa Mission, les services qu’elle offre ainsi que les domaines de
compétences qui font sa renommée.
1. Présentation de l’organisme d’accueil
1.1. Mission
Figure 1.1 : Logo de OXIA
OXIA [1] est une société d’ingénierie informatique spécialiste dans les solutions
intégrées d’entreprise. Elle agit sur le marché Tunisien, Européen, et Africain. Elle combine le
savoir-faire métier et l’expertise technique avec des méthodes rigoureuses de conduite de
projet.
OXIA est présente dans les domaines de la finance, la gestion intégrée d’entreprise
(ERP), la logistique, le transport (Supply Chain), le e-business et le conseil en
télécommunication. Elle est forte d’une expertise technique dans divers domaines
technologiques : les architectures d’entreprise, la plate-forme Java, la plate-forme .NET, les
Web Services, l’intégration de systèmes (EAI) sans oublier les technologies client/serveur et
4GL traditionnelles.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
14
L’offre d’OXIA s’articule autour du conseil stratégique, le conseil en organisation et
processus, le conseil technologique et la mise en œuvre de solutions progicielles et
spécifiques.
OXIA est notamment certifiée ISO9001:2000 par l’AFAQ pour l’ensemble de ses activités, et
elle est actuellement engagée dans une certification CMMI niveau 3 avec certification SEI.
1.2. Domaines de compétences
1.2.1. Finance
OXIA a acquis une forte expérience dans les domaines du leasing, du factoring et de
l’intermédiation boursière et intervient en tant que cabinet de conseil, d’ingénierie
informatique, et d’intégration de progiciels dans ces trois domaines.
1.2.2. Solutions de Gestion d’Entreprises
OXIA apporte à ses clients une approche qui vise à accroître leur compétitivité et leur
profitabilité. Nous les aidons dans la définition de leur nouveau positionnement stratégique à
travers notre offre de management consulting.
1.2.3. e-business
Une démarche méthodique et des outils performants, fruit d’un processus continu de
recherche et développement, vous permettent de tirer profit du meilleur des technologies
internet afin de mettre en œuvre vos applications B2B, B2C, A2A…
1.2.4. Télécommunications
OXIA a développé une offre de conseil et de pilotage de projets dans le domaine des
télécommunications Voix/Données, et mis l’accent sur les opportunités d’optimisation ou de
réduction des coûts télécoms de ses clients.
2. Etude de l’existant
Le « Système Ressources Humaines » exerce ses activités à travers des requêtes et des
actions offertes par le système d’information actuel OPM. Ce dernier n’offre pas des services
adéquats pour le processus Flux de travail de Recrutement.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
15
La planification, la modification, la mise à jour et suivi sont assurés à travers des
fichiers Excel, des fiches papier préparées manuellement et la communication se base par
mail à travers les dossiers de Outlook.
3. Critique de l’existant
Actuellement, la méthode de gestion des recrutements dans le système des ressources
humaines présente plusieurs inconvénients :
La manipulation avec les fichiers Excel, des fiches ; la communication avec les
dossiers Outlook, ne répond pas à un besoin vital de la Gestion ressource humaine qui
est le suivi du candidat dans tous les états du Flux de travail de Recrutement.
Risque manifestement présent des erreurs humaines : inattention, oubli, réplication,
perte de document.
Absence d’un système automatisé robuste pouvant couvrir les activités du Flux de
travail de Recrutement, les états des candidats, des tests et des entretiens, de leur suivi
et de leur historique.
Absence de contrôle sur le droit d’accès aux fichiers.
Absence de stockage de données dans des bases de données pour garantir leur sécurité
et leur intégrité.
4. Solution proposée
Dans le but d'accomplir la tache recrutement dans les meilleures des conditions
possibles, notre application vise une amélioration de la gestion des différents candidats, des
tests et des entretiens et du Flux de travail de Recrutement. Notre projet touche au service
ressources humaine ainsi que celui de développement logiciel vu qu'il met à la disposition de
la société une plateforme .net propriétaire et interne. Une interface graphique ergonomique
fondée sur une conception orientée objet engendrant une facilité de gestion tout en satisfaisant
toutes les normes d'accès en préservant les droit d'accès et les privilège de saisie, sauvegarde,
modification et mise à jour, en fait une authentification primaire et primordiale déclenche le
processus de contrôle des droits. Une configuration assez simple et compréhensible offrant à
l'administrateur un environnement complet et sécurisé de gestion de la tache recrutement.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
16
5. Méthodologie du travail
La méthodologie adaptée pour la gestion de notre projet a été choisie par le directeur
technique Mr Khaled Ben Driss. Le choix s’est porté sur une méthodologie Agile : Scrum
Dans ce qui suit nous allons définir la méthodologie, pour ensuite présenter ses valeurs
et ses principes. Nous allons aussi justifier l’utilisation de la méthode Agile Scrum.
5.1 Méthode Agile
5.1.1 Définition
Les méthodes Agiles [2] sont des ensembles de pratiques appliquées principalement
sur les projets de développement informatique. Ce sont des méthodes qui se veulent plus
pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur
(client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle
du besoin du client et non les termes d'un contrat de développement. La notion de méthode
agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé
par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant
qu'auteur de leur propre méthode.
5.1.2 Valeurs des méthodes Agiles
Les quatre valeurs fondamentales Agiles [3] sont :
l’interaction avec les personnes que les processus et les outils.
un produit opérationnel qu’une documentation pléthorique.
la collaboration avec le client que la négociation de contrat.
la réactivité face au changement que le suivi d'un plan.
5.1.3 Principes des méthodes Agiles
Ces 4 valeurs se déclinent en 12 principes généraux [4] communs à toutes les méthodes
agiles :
Satisfaction Client en livrant régulièrement des logiciels utiles
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
17
Accepter les changements au cours de développement
livraison fréquente de logiciel (2 à 4 semaines)
Collaboration quotidienne entre le client et les développeurs
Motivation des personnes
Croire en la capacité des développeurs
Conversation face à face
Un logiciel fonctionnel est la meilleure façon de mesurer la progression du projet
Les équipes doivent s'auto-organiser
5.2 Choix de la méthode Agile SCRUM
5.2.1 Définition
Scrum[5] est une méthode agile pour la gestion de projets (principalement le
développement des logiciels). Elle a été conçue pour améliorer grandement la productivité
dans les équipes auparavant paralysées par des méthodologies plus lourdes. Par contre, elle ne
couvre aucune technique d'ingénierie du logiciel, c’est pourquoi il est nécessaire de lui joindre
une méthodologie complémentaire comme l’eXtreme Programming (méthode agile) ou bien
tout simplement les méthodologies de conception d’UML.
5.2.2 Justification du choix
Le choix s’est porté sur Scrum pour plusieurs raisons :
Présence de 2 stagiaires (en plus de moi-même) pour la réalisation de nos projets de
fin d’études. Ainsi nous avons pu former une petite équipe de développeurs.
Le besoin de développer un nouveau Framework propriétaire à OXIA à base de la
technologie .NET et pouvoir en profiter éventuellement après pour le développement
d’autres modules. Ce projet pourrait remplacer le système d’information actuelle OPM
(développé avec Centura à base de C++).
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
18
La nature des projets de fin d’études : en effet, il s’agit de répondre à des besoins en
interne, c’est ce qui facilite la communication avec le client.
5.2.3 Mise en œuvre
5.2.3.1 Définitions des rôles
La première étape est de définir les rôles au sein de l’équipe :
Le directeur de produit (Product Owner) : Mr. Amine Laroussi, chef projet à OXIA
et ayant pour tâche de maintenir à jour le Système d’informations d’OXIA. Il est le
représentant des clients et utilisateurs. C'est à lui que revient la tâche de définir l'ordre
dans lequel les fonctionnalités seront développées ainsi que la prise des décisions
importantes concernant l'orientation du projet. Il se trouve au même bureau que
l’équipe de développeurs.
L’équipe : elle est composée de trois développeurs dont je fais partie. Cette équipe a
eu comme tâche de réaliser le Framework dans lequel on intégrera les différentes
applications dont l’une est le Flux de travail de Recrutement.
Les tâches Framework sont :
Création de l’interface Graphique de l’Application en WPF4.
Intégration du Flux de travail de WF4 au Framework.
Integration du WCF4 (Windows Communication Foundation)
Conception et réalisation d’une fonction d’aide à la saisie.
Documentation et Utilisation d’Enterprise Library 5 dans le
Framework.
Documentation et Choix de design pattern pour la couche d’accès aux
données
Le facilitateur (ScrumMaster) : ce rôle est également assuré par Mr Amine Laroussi,
il s’est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
19
Les intervenants (Stakeholders) : Ce sont les personnes qui souhaitent avoir une vue
sur le projet sans réellement s'investir dedans.
o Khaled Ben Driss : Directeur Technique à OXIA, avec qui nous avons des
réunions bihebdomadaire, et qui a suivi de près l’avancement du projet.
o Imed Ayadi : Directeur Général à OXIA, avec qui nous avons eu une réunion
pour la validation des besoins du projet.
Les clients (Customers): Ceux à qui est offerte l’application.
o Dorra Bouziri : Directeur Ressources Humaines, avec qui nous avons eu trois
réunions pour définir les besoins fonctionnelles de l’application.
o Selma Bellouma : Chargée Recrutement, avec qui nous avons eu deux
réunions pour définir les besoins directes de l’application.
5.2.4 Planification
Scrum permet de définir trois niveaux de planification :
sprint
release/projet
quotidien
5.2.4.1 Les sprints
Scrum est un processus itératif : les itérations sont appelées des sprints qui durent
généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste de
fonctionnalités à réaliser (appelées items de backlog de produit). Ces items sont décomposés
par l'équipe en tâches élémentaires de quelques heures ; les items de backlog de sprint.
Dans notre projet, nous avons opté pour des sprints de deux semaines, suffisant pour
avancer dans nos tâches respectives.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
20
5.2.4.2 Releases
Il s’agit de regrouper les itérations (sprints) en unité plus grande portant généralement une
définition sémantique. Dans notre cas, on peut distinguer 3 releases :
Documentation et définitions de besoins.
Conception et réalisation du Framework.
Conception et réalisation du module Flux de travail Recrutement.
5.2.4.3 Quotidien
C’est une réunion quotidienne avec notre ScrumMaster afin de faire un point sur ce
qui a été réalisé la veille, ce que nous devons à faire dans la journée. C’est aussi l’occasion de
discuter des difficultés rencontrées lors de nos tâches respectives.
5.2.5 Gestion des besoins
5.2.5.1 Backlog de produit
Après avoir récolté les besoins fonctionnels des clients, le directeur de produit établit
une liste de fonctionnalités à réaliser, appeléeBacklog de produit.
5.2.5.2 Backlog de sprint
Au départ d’un sprint, Nous choisissons quels items du Backlog de produit seront
réalisés lors de ce sprint. Les items sont décomposés alors en liste de tâches élémentaires.
Chaque tâche est estimée en heures ou en jours. On constitue ainsi le Backlog de sprint.
Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du Backlog de sprint et
les réalise.
Exemple : documentation et réalisation d’un tutoriel sur Enterprise Library 5 en un seul sprint
Item de Backlog de produit : documentation sur Enterprise Library 5 et réalisation
d’un tutoriel
Durée du sprint : 2 semaines
Durée de BackLog sprint : 4 heures
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
21
Tâches élémentaires : étudier 5 blocks d’Enterprise Library 5, pour chaque block, il
faut :
o Se documenter
o Réaliser des tests
o Réaliser une démonstration
o Mettre à jour le tutoriel
Le schéma suivant nous donne une idée globale du processus Scrum.
Figure 1.2 : Vue globale du processus Scrum
5.3 Choix conceptuels
5.3.1 Choix de l’approche Objet
Nous avons adopté une approche objet comme mode de conception de notre système
et ce pour les raisons suivantes:
Les concepts de base de l’approche objet sont stables, normalisés et largement
approuvés.
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
22
L’approche objet permet de bénéficier d’une panoplie d’outils et de langages
performants facilitant le développement.
La modélisation par objet correspond étroitement au monde réel. Il est par conséquent
plus souple pour les modifications.
Contrairement à l’approche fonctionnelle, l’approche objet représente une solution
destinée à faciliter l’évolution d’applications complexes telles que notre application
”Flux de travail de Recrutement”.
5.3.2 Langage de modélisation : UML
Ayant opté pour une approche objet, le choix d’UML [voir Annexe 3] nous semble une
évidence. En effet, il est reconnu comme étant le standard industriel par excellence de la
modélisation objet. Cela est d’autant plus probant quand nous prenons connaissance qu’UML
unifie à la fois les notations et les concepts orientés objet.
5.3.3 Outils logiciel de conception
Afin de modéliser notre travail en langage UML, nous avions eu recourt à un logiciel
complet de modélisation du nom de « Power AMC » dans sa version 15.
PowerAMC, le n°1 de la modélisation de données, est un outil tout-en-un de modélisation
d'entreprise et de gestion des métadonnées destiné à documenter l'architecture d'entreprise.
Figure 1.3 : Emblème de SYBASE PowerAMC
PowerAMC est un environnement graphique de modélisation d'entreprise très simple d'emploi
qui permet d'effectuer les tâches suivantes :
Modélisation intégrée via l'utilisation de méthodologies et de notations standards :
Chapitre 1 : PRESENTATION DU CADRE DU PROJET
23
o Données (E/R, Merise)
o Métiers (BPMN, BPEL, ebXML)
o Application (UML)
o Génération automatique de code via des Template personnalisables
o SQL (avec plus de 50 SGBD)
o Java
o .NET
Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes
existants
Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de
gestion des versions très complètes pour permettre un développement multi-
utilisateurs
Fonctionnalités de génération et de gestion de rapports automatisés et personnalisables
Un environnement extensible, qui vous permet d'ajouter des règles, des commandes,
des concepts et des attributs à vos méthodologies de modélisation et de codage.
Conclusion
Dans ce chapitre, nous avons introduit l’entreprise d’accueil « OXIA » en présentant sa
procédure actuelle de recrutement. Nous avons ensuite procédé à une critique de l’existant et
nous avons proposé diverses solutions.
Dans le prochain chapitre, nous allons étudier la spécification de notre projet et nous allons
dresser des diagrammes de cas d’utilisation qui vont décrire les besoins de ce système ainsi
qu’un diagramme d’activité qui va mettre au point l’enchaînement du workflow recrutement.
24
CHAPITRE 2
SPECIFICATION DES BESOINS
Chapitre 2 : SPECIFICATION DES BESOINS
25
Introduction
Ce chapitre renferme une description des besoins du processus recrutement en
spécifiant ceux fonctionnels et non fonctionnels. On y étudiera en premier lieu les différents
diagrammes de cas d'utilisations pour aboutir à une description détaillée du diagramme
d'activité du flux de la tache recrutement.
1. Spécification informelle
L’objectif de ce projet est de concevoir et de réaliser une application de Flux de travail
de Recrutement permettant d’exercer les différentes activités au sein du processus
«Ressources Humaines ».
Comme toute autre application, notre application devrait répondre à certains besoins et
assurer plusieurs fonctionnalités, dégagées suite à des réunions avec les analystes métier, le
chef de projet et du responsable de la société.
1.1. Besoins fonctionnels
Les Besoins fonctionnels de notre application « Flux de travail recrutement » se présentent
comme suit :
- Gérer les candidats : création, modification, suppression.
- Gérer les tests : planification, réalisation, décision.
- Gérer les entretiens : planification, réalisation, décision.
- Gérer le suivi de l’état du candidat dans toutes les étapes : pour test, pour entretien,
retenu à chaud, rejeté, recruté.
- Faciliter la recherche du candidat, du test ou de l’entretien à travers des filtres.
- Assurer l’historique pour une meilleure gestion des statistiques de l’application.
Chapitre 2 : SPECIFICATION DES BESOINS
26
1.2. Besoins non fonctionnels
Les besoins non-fonctionnels décrivent le comportement du système dans tous ses
aspects, se focalisant principalement sur les contraintes de temps de réponse de l’organisme
d’accueil (OXIA) vis à vis au client (OXIA). Le développement de l’application qui doit
respecter une architecture en couches, comprend la mise en place d’un Framework à travers
lequel il faut développer le «Flux de travail Recrutement» en tant que module tout en
garantissant l'extensibilité de l'application pour lui permettre accueillir d’autres modules,
d’autres couches, d’autres interfaces.
En fait, parmi les caractéristiques prises en charge dans l'application, on mentionne la
sécurité qui est un besoin primordiale pour préserver l’intégrité des données. On cite aussi la
maintenabilité cohérente et la moins couteuse possible. En effet, la clarté et la lisibilité du
code selon les normes de codage propre à la société, ouvre les horizons de son évolution et
amélioration aisée surtout avec des interfaces ergonomique simples à paramétrer.
En d'autres termes l'application doit faciliter à tous les coups la tache de recrutement
en supportant à la fois un flux de données large et une intervention de plusieurs utilisateurs ce
qui organise la tâche et minimise le temps de réponse des requêtes de l’utilisateur doit être le
plus optimisé que possible pour gagner en productivité.
2 Identification des cas d’utilisation
2.1 Définition
Un cas d’utilisation modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée notable aux acteurs.
Il représente une séquence d’actions réalisées par le système. L’identification des cas
d’utilisation se fait en cherchant :
Les tâches que l’acteur veut que le système exécute.
Les tâches de création, sauvegarde, modification, suppression ou consultation des
données dans le système par l’acteur.
Chapitre 2 : SPECIFICATION DES BESOINS
27
Les tâches que l’acteur fera pour informer le système des changements soudains ou
externes.
Les informations que l’acteur doit connaître sur certains événements du système.
L’ensemble des fonctionnalités du futur système est déterminé en examinant les
besoins fonctionnels de chaque acteur, exprimés sous forme de familles d’interactions
dans les cas d’utilisation.
Dans ce qui suit nous présentons les cas d’utilisation pour chaque acteur défini
précédemment.
2.2 Diagrammes des cas d’utilisation : Framework
Figure 2.1 : Diagramme des cas d’utilisation Framework
Ce diagramme des cas d’utilisation du Framework (figure 2.1) par l’application « Flux de
travail de recrutement » trace la relation entre notre application et le Framework qu’on a
conçu afin de satisfaire ces besoins :
Chapitre 2 : SPECIFICATION DES BESOINS
28
Utilisation de contrôles personnalisés comme le « OXIATextBox » qui hérite du
contrôle textBox de WPF et lui ajoute des méthodes propriétaires au Framework et
utilisables par la suite dans les différentes applications.
Utilisation de la fonction d’aide à la saisie, recherche F12 : c’est une fonction qui
facilite la recherche en cliquant sur F12 dans le champ personnalisé du Framework, la
fonction de recherche affiche une liste d’attributs souhaités selon ce champ-là.
Utilisation d’un seul « ToolBar » du Framework, dont les boutons contiennent des
méthodes qui facilitent l’utilisation et le traitement de l’application qui sera intégrée
par la suite.
Utilisation d’un menu générique à partir de la base de donnée et utilisable par toutes
les applications du Framework.
Les droits de l’accès sont gérés par la fenêtre authentification du Framewrok, elle gère
ainsi la gestion des profils.
Le Framework gère l’historique de toutes les opérations effectuées dans les
applications et les stocke dans la base de données par opération, date, heure et
utilisateur.
Le Framework gère la gestion des favoris, c’est une option donnée aux utilisateurs de
l’application intégrée dans le Framework, ils peuvent sauvegarder une opération qu’ils
voient répétitive par exemple une recherche avec un certain filtrage.
2.3 Diagrammes des cas d’utilisation : Workflow Recrutement
2.3.1 Identification des acteurs
Un acteur est un rôle joué par des entités externes qui interagissent directement avec le
système étudié. L’identification des acteurs se fait en cherchant :
- Les utilisateurs qui fournissent, utilisent ou retirent des informations du système.
- Les utilisateurs qui sont intéressés par un besoin donné.
- Les utilisateurs qui maintiennent le système.
- Les ressources externes du système.
Chapitre 2 : SPECIFICATION DES BESOINS
29
- Les autres systèmes qui devront interagir avec le système.
Les spécifications fonctionnelles que nous avons dégagées nous nous ont permises d’identifier
les acteurs principaux suivants :
Administrateur : Il est le super-utilisateur du système, il possède tous les droits et
privilèges. Il est chargé de paramétrer l’application en affectant les rôles aux différents
utilisateurs. Il se réserve aussi tous les droits d’ajout, de saisie, de mise à jour,
d’édition et de suppression des fiches des candidats, des tests et des entretiens.
Chargé Recrutement : Personne appartenant au processus« Ressources Humaines »
et à qui est offerte l’application en premier lieu. Le chargé recrutement ajoute et met à
jour les fiches des candidats ; planifie les tests et les entretiens, suit le Flux de travail
de Recrutement dans tous ses états.
Assistante de Direction : Personne appartenant au processus « Direction », et à
laquelle a été affectée une action. Cette personne aide ne peut que mettre à jour
l’action qui lui concerne.
Evaluateur : Cette personne a pour tâche d’évaluer le candidat lors de l’entretien, elle
ne peut que modifier la fiche de l’entretien.
Utilisateur : Cette personne doit pouvoir visualiser, une fois authentifiée, la liste des
candidats et les informations les concernant.
Et les acteurs secondaires suivants :
SGBD : Le système de gestion de base de données utilisé pour le stockage des
données manipulées. Le SGBD contient aussi la liste des utilisateurs qui manipulent
l’application et la nature de leur droit d’accès.
Chapitre 2 : SPECIFICATION DES BESOINS
30
2.3.1 Diagramme du système « Flux de travail de Recrutement »
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<SGBD>
Oracle 8i
Administrateur
Chargé Recrutement
Assistante de Direction
Evaluateur
Utilisateur
Gerer les candidats
Consulter
Evaluer
S'authentifier
Gerer les Tests
Gerer les Entretiens
Parametrer l 'application
Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement »
La relation entre les différents acteurs est une relation de généralisation, ceci implique
l’héritage des cas d’utilisations entre acteurs :
- L’acteur « Utilisateur » : ne peut que consulter l’application.
- L’acteur « Evaluateur » : Il ne peut que modifier la fiche entretien.
- L’acteur « Assistante de Direction » : Gérer les tests en plus des cas d’utilisation
précédemment expliqués avec l’ « Utilisateur ».
- L’acteur « Chargé Recrutement » : Il un rôle fondamentale il gère le candidat, les
tests et les entretiens.
- L’acteur « Administrateur » : c’est le super utilisateur, il peut tout faire ainsi que le
paramétrage de l’application.
Les différents cas d’utilisation seront détaillés par acteur dans la partie suivante.
Chapitre 2 : SPECIFICATION DES BESOINS
31
2.3.3 Cas de l’acteur « Chargé Recrutement »
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Chargé Recrutement
Recherche Candidat
Creer Candidat
Planifier Test
Réaliser Test
Planifier Entretien
Réaliser Entretien
Décision Candidat
Modifier Canddiat
Supprimer Candidat
Annuler Test
Annuler Entretien
Gérer Candidat
Gérer Test
Gérer Entretien
Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement »
Description
Après son authentification, le « Chargé Recrutement » est responsable de
- Gérer le candidat
Créer le candidat
Chapitre 2 : SPECIFICATION DES BESOINS
32
Modifier le candidat
Rechercher le candidat
Supprimer le candidat
Décision du candidat : il s’agit en effet du statut du candidat à savoir pour
test, pour entretien, retenu à chaud, recruté, rejeté.
- Gérer le test
Planifier test
Réalisation test
Annuler test
- Gérer l’entretien
Planifier entretien
Réalisation entretien
Annuler entretien
Chapitre 2 : SPECIFICATION DES BESOINS
33
2.3.4 Cas de l’acteur « Assistante de Direction »
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Assistante de Direction
Recherche Candidat
Creer Candidat
Planifier Test
Réaliser Test
Annuler Test
Gérer Candidat
Gérer Test
Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction »
Apres son authentification, l’assistante de direction est responsable de :
- Gérer candidat
Créer candidat.
Recherche candidat.
- Gérer test
Planifier test.
Réaliser test.
Annuler test.
Chapitre 2 : SPECIFICATION DES BESOINS
34
2.3.5 Cas de l’acteur « Administrateur »
<<include>>
<<include>>Administrateur
Attribuer les autorisations aux profils
Creer les autorisations
Gérer les autorisations
Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur »
Description du Cas d’Utilisation « Gérer autorisations »
L’administrateur se charge d’attribuer des autorisations aux personnes concernées qui
accèdent à l’application.
L’administrateur a aussi tous les droits qu’a le chargé recrutement.
3. Vue Dynamique : Diagramme d’activités
Les diagrammes d’activités [10] permettent de mettre l’accent sur les traitements. Ils
sont adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils
permettent ainsi de représenter graphiquement le comportement d’une méthode ou le
déroulement d’un cas d’utilisation. Dans ce qui suit nous allons présenter le diagramme
d’activité du Flux de travail de Recrutement.
Chapitre 2 : SPECIFICATION DES BESOINS
35
3.1 Diagramme d’activité : Flux de travail de Recrutement
[Expérience > 3]
[Expérience < 3]
[Test Réussi]
[Candidat pour Entretien][Test echoué]
[CV rejeté]
Creer Candidat
Décision CVRéaliser Test
Réaliser EntretienDécision Test
Décision Entretien
Recruter CandidatPlacer Candidat Retenu à Chaud
Rejeter Candidat sur CV
Rejeter Candidat sur Entretien
Rejeter Candidat sur Test
Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement
Description :
Ce diagramme d’activité (figure 2.6) représente le diagramme d’activité du flux de travail de
recrutement.
Apres la création du candidat, une opération de filtrage de cv se fait pour choisir les candidats
les plus adéquats aux différents profils proposés par OXIA. Suivant le nombre d’années
d’expérience, le candidat est soit mis dans le panier pour test, soit pour entretien.
Si le candidat réussi le test, il est mis pour entretien.
Apres chaque entretien, une note est donné au candidat et une décision est prise ; le candidat
est donc soit redirigé une autre fois vers un autre entretien, soit rejeté, soit mis à chaud, soit
recruté.
Chapitre 2 : SPECIFICATION DES BESOINS
36
Conclusion
Dans ce chapitre, nous avons passé en revue les différents besoins exprimés par l’entreprise.
Cela nous a permis de définir la spécification fonctionnelle et non fonctionnelle du système
visé. Dans une deuxième partie, nous avons présenté la phase d’analyse qui nous a conduits à
élaborer les diagrammes de cas d’utilisations ainsi que le diagramme d’activité du flux de
travail du recrutement. Dans le chapitre suivant nous allons concevoir notre système en se
basant sur le langage de modélisation UML.
37
CHAPITRE 3
CONCEPTION DE LA SOLUTION
Chapitre 3 : CONCEPTION
38
Introduction
Dans le présent chapitre, on se base sur le langage UML pour la conception de notre
système d’information. Pour commencer, nous présenterons une conception générale du
système contenant le digramme des classes du système. Ensuite, nous passerons à une
spécification détaillée des fonctionnalités que le système doit assurer contenant l’ensemble
des digrammes de séquences présentant les principales fonctions du système.
1. Vue statique : Diagramme de Classe
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces d'un système ainsi que les différentes relations entre celles-ci. Ce diagramme
fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et
dynamiques.
Une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les
éléments de cet ensemble sont les instances de la classe. C’est aussi un ensemble de fonctions
et de données (attributs) qui sont liées ensembles par un champ sémantique. Les classes sont
utilisées dans la programmation orientée objet. Elles permettent de modéliser un programme
et ainsi de découper une tâche complexe en plusieurs petits travaux simples.
Chapitre 3 : CONCEPTION
39
0..
11
..1
0..
11
..1
1..
1
0..
*
0..
10
..*
1..
1
0..
*
1..
1
0..
*
1..
1
0..
*
1..
1
0..
*
1..
1
0..
*
1..
1
0..
*
0..
10
..*
0..
10
..* 0..
1
0..
*
1..
1
0..
*
1..
*
0..
*
1..
*
0..
*
1..
*
1..
*
1..
*
0..
*
1..
1
0..
*
0..
*
1..
1
Ca
nd
ida
t
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
id_
ca
nd
ida
t
em
ail
_ca
nd
ida
t
pre
no
m_
ca
nd
iat
no
m_
ca
nd
ida
t
sta
tut_
ca
nd
ida
t
sou
rce
_ca
nd
ida
t
CV
_ca
nd
ida
t
Le
ttre
Mo
tiva
tio
n_
ca
nd
ida
t
Da
teN
ais
san
ce
Lie
uN
ais
san
ce
sexe
situ
atu
tio
nfa
mil
le
CIN
_ca
nd
ida
t
Te
lep
ho
ne
1
Te
lep
ho
ne
2
Bu
lle
tin
Ad
ress
e
Ba
c
An
ne
Ba
c
Mo
ye
nn
eB
ac
No
teM
ath
Ba
c
No
teP
hysi
qu
eB
ac
No
teP
hil
oB
ac
No
teF
ran
ça
isB
ac
De
bu
tExp
eri
en
ce
Nb
An
ne
eE
xp
eri
en
ce
Sta
ge
Oxia
SIV
P
Da
teC
rea
tio
nC
an
did
at
: d
ecim
al
: st
rin
g
: st
rin
g
: st
rin
g
: st
rin
g
: st
rin
g
: b
yte
: b
yte
: D
ate
Tim
e
: st
rin
g
: st
rin
g
: st
rin
g
: in
t
: in
t
: in
t
: st
rin
g
: st
rin
g
: st
rin
g
: in
t
: fl
oa
t
: fl
oa
t
: fl
oa
t
: fl
oa
t
: fl
oa
t
: D
ate
Tim
e
: in
t
: st
rin
g
: st
rin
g
: D
ate
Tim
e
Use
r
- - - - - -
use
r_id
no
m
pre
no
m
pa
ssw
ord
pro
fil_
id
em
ail
: st
rin
g
: st
rin
g
: st
rin
g
: st
rin
g
: in
t
: st
rin
g
Sta
ge
- - - - - -
id_
sta
ge
suje
t_st
ag
e
typ
e_
sta
ge
socie
te_
sta
ge
da
ted
eb
ut_
sta
ge
da
tefi
n_
sta
ge
: in
t
: st
rin
g
: st
rin
g
: st
rin
g
: D
ate
Tim
e
: D
ate
Tim
e
Re
fere
nce
- - - - - -
id_
refe
ren
ce
no
m_
refe
ren
ce
socie
te_
refe
ren
ce
em
ail
_re
fere
nce
tele
ph
on
e_
refe
ren
ce
pre
no
m_
refe
ren
ce
: in
t
: st
rin
g
: st
rin
g
: st
rin
g
: in
t
: st
rin
g
Ce
rtif
ica
tio
n
- - - - -
id_
ce
rtif
ica
tio
n
Ca
teg
ori
e_
ce
rtif
ica
tio
n
Co
de
_ce
rtif
ica
tio
n
Att
ach
e_
ce
rtif
ica
tio
n
Typ
e_
ce
rtif
ica
tio
n
: in
t
: st
rin
g
: in
t
: st
rin
g
: st
rin
g
Pro
fil
- -
id_
Pro
fil
de
scri
pti
on
_p
rofi
l
: d
ecim
al
: st
rin
g
Eva
lua
teu
r_E
xte
rne
- - - - -
Eva
lua
teu
rExte
rne
_id
No
m_
Eva
lExte
rne
Pre
no
m_
Eva
lExte
rne
En
tre
pri
seE
va
lExte
rne
Po
ste
Eva
lExte
rne
: d
ecim
al
: st
rin
g
: st
rin
g
: st
rin
g
: st
rin
g
BA
- - - -
bA
_Id
de
scri
pti
on
BA
ab
revia
tio
nB
A
dir
ecte
urB
A
: in
t
: st
rin
g
: st
rin
g
: U
ser
BU
- - - -
bU
_Id
de
scri
pti
on
BU
ab
revia
tio
nB
U
dir
ecte
urB
U
: in
t
: st
rin
g
: st
rin
g
: U
ser
En
tre
tie
n
- - - - - - - - -
en
tre
tie
nid
da
tee
ntr
eti
en
lie
ue
ntr
eti
en
he
ure
En
tre
tie
n
Sta
tutE
ntr
eti
en
No
teE
ntr
eti
en
Re
ma
rqu
esE
ntr
eti
en
De
cis
ion
En
tre
tie
n
Da
teP
lan
ific
ati
on
En
tre
tie
n
: d
ecim
al
: D
ate
Tim
e
: st
rin
g
: T
ime
Sp
an
: st
rin
g
: st
rin
g
: st
rin
g
: st
rin
g
: D
ate
Tim
e
Dip
lom
e
- - - - -
id_
dip
lom
e
No
m_
dip
lom
e
Inst
itu
tio
n_
dip
lom
e
An
ne
e_
dip
lom
e
Pa
ys_
dip
lom
e
: in
t
: st
rin
g
: st
rin
g
: in
t
: st
rin
g
Te
st
- - - - - - - - - -
id_
test
typ
e_
test
Da
te_
test
lie
u_
test
he
ure
_te
st
sta
tut_
test
rem
arq
ue
s_te
st
no
te_
test
an
ima
teu
r_te
st
Da
teP
lan
ific
ati
on
Te
st
: d
ecim
al
: st
rin
g
: D
ate
Tim
e
: st
rin
g
: T
ime
Sp
an
: st
rin
g
: st
rin
g
: in
t
: U
ser
: D
ate
Tim
e
Mo
tsC
les
- -
id_
mo
tscle
s
de
scri
pti
on
_m
ots
cle
s
: in
t
: st
rin
g
Off
reC
an
did
at
- - - -
Da
teE
ntr
ée
So
ua
ité
e
Da
teE
ntr
ée
Co
nfi
rmé
e
Ca
nd
ida
t
Cre
ate
urO
ffre
: D
ate
Tim
e
: D
ate
Tim
e
: C
an
did
at
: U
ser
Eva
lua
teu
rIn
tern
e
-P
ost
e:
stri
ng
Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement
Chapitre 3 : CONCEPTION
40
Description du diagramme de classe
La classe Candidat
Elle définit le candidat par son identifiant, nom, prénom, date de naissance, lieu de naissance,
sexe, CIN email, statut, source, cv, lettre de motivation et d’autres attributs.
Cette classe est lié à la classe User afin de préciser l’utilisateur qui a créé le candidat ; elle est
également lié à la classe diplôme, stage, référence, certification, mots clés, offre candidat,
profils, test et entretien.
La classe User
Elle définit l’utilisateur OPM (OXIA Project Manager) à travers user_id, nom, prénom,
password, profil_id et email. La table qui représente cette classe existe déjà dans la base de
données de OXIA.
La classe Test
Elle définit le Test que subit le candidat au cours du flux de travail de recrutement et cela par
un id, type, date, lieu, statut, remarques, note, animateur et date de planification. Elle est en
liaison avec la classe Candidat et la classe User pour préciser l’utilisateur qui planifie le Test
ainsi que l’animateur du Test.
La classe Entretien
Elle définit l’entretien que subit le candidat au cours du flux de travail de recrutement et cela
par un id, date, lieu, statut, note, remarques, décision et date de planification. Elle est en
liaison avec la classe Candidat, Evaluateur interne et Evaluateur externe.
La classe EvaluateurInterne
La classe EvaluateurInterne hérite de la classe User car l’évaluateur interne est un utilisateur
de OXIA. On lui ajoute l’attribut poste.
La classe EvaluateurExterne
Elle est définit par un id, nom, prénom, entreprise et poste. Elle est en liaison avec la classe
Entretien.
Chapitre 3 : CONCEPTION
41
La classe MotsCles
Elle est définit par id et description. Elle est en liaison avec la classe Candidat. Elle représente
les mots clés du candidat.
La classe Diplôme
Elle définit les diplômes du candidat par un id, nom, institution, année et pays.
La classe Certification
Elle définit les certifications du candidat par un id, catégorie, code, type et un booléen pour
voir si la certification est attachée ou pas au compte OXIA.
La classe Reference
Elle définit les références du candidat par id, nom, prénom, société, email et téléphone.
La classe Stage
Elle définit les stages du candidat par id, sujet, type, société, date début et date fin du stage.
La classe OffreCandidat
Elle définit l’offre du candidat, les attributs sont date entrée souhaitée, date entrée confirmée,
candidat et créateur. Elle est en liaison avec la classe Candidat et la classe User.
La classe BA
Elle définit la classe BA(Business Area) par un BA_id, descriptionBA, abreviationBA et
directeurBA. La table qui représente cette classe existe déjà dans la base de données de
OXIA.
La classe BU
Elle définit la classe BU (Business Unit) par un BU_id, descriptionBU, abreviationBU. La
table qui représente cette classe existe déjà dans la base de données de OXIA.
La classe Profil
Elle définit les profils potentiels que peut avoir le candidat, ces profils sont selon les BA BU.
Chapitre 3 : CONCEPTION
42
2. Diagramme de séquence
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation UML (Unified
Modeling Language).
On montre ces interactions dans le cadre d'un scénario d'un diagramme des cas d'utilisation.
Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et
les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se
déroule les actions entre les acteurs ou objets.
Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets :
Message simple : le message n'a pas de spécificité particulière d'envoi et de réception.
Message avec durée de vie : l'expéditeur attend une réponse du récepteur pendant un
certain temps et reprend ses activités si aucune réponse n'a lieu dans un délai prévu.
Message synchrone : l'expéditeur est bloqué jusqu'au signal de prise en compte par le
destinataire. Les messages synchrones sont symbolisés par des flèches barrées.
Message asynchrone : le message est envoyé, l'expéditeur continue son activité que le
message soit parvenu ou pris en compte ou non. Les messages asynchrones sont
symbolisés par des demi-flèches.
Par la suite, on va choisir les scénarios les plus importants et on va les modéliser par des
diagrammes de séquences.
Chapitre 3 : CONCEPTION
43
2.1. Diagramme de séquence Framework
2.1.1. Diagramme de séquence : Administrateur Recrutement
Figure 3.2 : Diagramme de séquence : Administration
Chapitre 3 : CONCEPTION
44
Acteur : Administrateur.
But : Paramétrage du workflow Recrutement.
Enchaînement nominal :
L’administrateur introduit les paramètres souhaités : les autorisations par rôle et les acteurs de
l’application.
Ces paramètres passent par les différentes couches de l’application.
En effet, à partir de l’interface de paramétrage les données passent par la classe
« RecrutementProcessComponent »s dans la couche « UIProcessComponents », par la suite,
par la couche service WCF. Ils passent après par la classe
« ParametrageBusinessComponent » dans la couche « BusinessComponent », enfin par la
classe « ParametrageDAO » pour lancer la requête vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le
succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que
l’opération a échoué.
Chapitre 3 : CONCEPTION
45
2.3. Diagramme de séquence Workflow Recrutement
2.3.1. Diagramme de séquence : Authentification
Co
uch
e
Se
rvic
e W
CF
Intr
od
uir
e (
log
in,p
ass
wo
rd)
Ge
tUse
rById
BC
(lo
gin
,pa
ssw
ord
)
Ge
tUse
rById
(lo
gin
,pa
ssw
ord
)
Exé
cu
tio
n R
eq
ue
te S
ele
ct(
)
Ve
rifi
ca
tio
n
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Ge
tUse
rbyID
PC
(lo
gin
,pa
ssw
ord
)
Ge
tUse
rById
S(l
og
in,p
ass
wo
rd)
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Uti
lisa
teu
r
Ecra
n A
uth
en
tifi
ca
tio
nS
GB
D:S
erv
ice
Au
ten
tifi
ca
tio
n:A
uth
en
tifi
ca
tio
n B
usi
ne
ss C
om
po
ne
nt
:Use
rDA
O:A
uth
en
tifi
ca
tio
nP
roce
ssC
om
po
ne
nt
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
alt
Intr
od
uir
e (
log
in,p
ass
wo
rd)
Ge
tUse
rById
BC
(lo
gin
,pa
ssw
ord
)
Ge
tUse
rById
(lo
gin
,pa
ssw
ord
)
Exé
cu
tio
n R
eq
ue
te S
ele
ct(
)
Ve
rifi
ca
tio
n
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Ge
tUse
rbyID
PC
(lo
gin
,pa
ssw
ord
)
Ge
tUse
rById
S(l
og
in,p
ass
wo
rd)
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n R
éu
ssie
Au
the
nti
fica
tio
n E
ch
ou
ée
Au
the
nti
fica
tio
n E
ch
ou
ée
Figure 3.3 : Diagramme de séquence : Authentification
Chapitre 3 : CONCEPTION
46
Acteur : Utilisateur.
But : S’authentifier par un login et un password.
Enchaînement nominal :
1. Consulter l’application.
2. Introduire le login et le password.
3. Vérifier le login et le password dans la base de données en passant par les différentes
couches de l’application.
4. Accepter le login et le password
Enchaînement Alternatif :
Le système cherche dans la base de données, ne trouve pas de correspondance et retourne à
l'utilisateur un message d'erreur.
Chapitre 3 : CONCEPTION
47
2.3.2. Diagramme de séquence : Chargé Recrutement
2.3.2.1 Insertion Candidat C
ou
ch
e
Wo
rkfl
ow
WF
Inse
rtio
nC
an
did
at(
)
Se
nd
Re
ply
Ca
nd
ida
t()
Inse
rtC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te I
nse
rt()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Re
ce
ive
Ca
nd
ida
t()
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtC
an
did
atP
C()
Inse
rtC
an
did
atS
()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
ch
arg
é r
ecru
tem
en
t
SG
BD
:UI
Ca
nd
ida
t:W
ork
Flo
w R
ecru
tem
en
t:C
an
did
at
Bu
sin
ess
Co
mp
on
en
ts:C
an
did
at
DA
O:R
ecru
tem
en
tPro
ce
ssC
om
po
ne
nts
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
alt
Inse
rtio
nC
an
did
at(
)
Se
nd
Re
ply
Ca
nd
ida
t()
Inse
rtC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te I
nse
rt()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Re
ce
ive
Ca
nd
ida
t()
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtC
an
did
atP
C()
Inse
rtC
an
did
atS
()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Figure 3.4 : Diagramme de séquence : Insertion Candidat
Chapitre 3 : CONCEPTION
48
Acteur : Chargé Recrutement.
But : Insérer un candidat.
Enchaînement nominal :
La chargée recrutement introduit les informations concernant le candidat : nom, prénom, date
de naissance, diplôme, etc…
Ces informations seront stockés dans l’entité business « Candidat » de la couche
« BusinessEntities », ensuite, l’entité candidat passera par les différentes couches de
l’application dont la couche Workflow qui assurera le dialogue avec la couche DAO et la base
de donnée.
En effet, à partir de l’interface d’insertion les données passent par la classe
« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,
par la couche Workflow service WF. Ils passent après par la classe
« CandidatBusinessComponent » dans la couche « BusinessComponent », enfin par la classe
« CandidatDAO » pour lancer la requête insert vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le
succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que
l’opération a échoué
Chapitre 3 : CONCEPTION
49
2.3.2.2 Affichage Candidat
Co
uch
e
Se
rvic
e W
CF
Aff
ich
erC
an
did
at(
)
Aff
ich
erC
an
did
atB
C()
Aff
ich
erC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te S
ele
ct(
)
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Aff
ich
erC
an
did
atP
C()
Aff
ich
erC
an
did
atS
()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
ch
arg
é r
ecru
tem
en
t
SG
BD
:UI
Ca
nd
ida
t:S
erv
ice
Re
cru
tem
en
t:C
an
did
at
Bu
sin
ess
Co
mp
on
en
t:C
an
did
at
DA
O:R
ecru
tem
en
tPro
ce
ssC
om
po
ne
nts
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
alt
Aff
ich
erC
an
did
at(
)
Aff
ich
erC
an
did
atB
C()
Aff
ich
erC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te S
ele
ct(
)
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Aff
ich
erC
an
did
atP
C()
Aff
ich
erC
an
did
atS
()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Figure 3.5 : Diagramme de séquence : Affichage Candidat
Chapitre 3 : CONCEPTION
50
Acteur : Chargé Recrutement.
But : Afficher le candidat.
Enchaînement nominal :
La chargée recrutement choisit le type d’affichage de la liste des candidats par statut :
candidat soumis, pour test, pour entretien, retenu à chaud, pour décision, recruté, rejeté ou
tous les candidats.
Pour afficher la liste des candidats, cette demande doit passer par les différentes couches de
l’application.
En effet, à partir de l’interface de présentation, les données passent par la classe
« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,
par la couche service WCF. Ils passent après par la classe « CandidatBusinessComponent »
dans la couche « BusinessComponent », enfin par la classe « CandidatDAO » pour lancer la
requête insert vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le
succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que
l’opération a échoué.
Chapitre 3 : CONCEPTION
51
2.3.2.3 Planification Entretien
Co
uch
e
Wo
rkfl
ow
WF
Pla
nif
ierE
ntr
eti
en
()
Inse
rtC
an
did
atB
C()
Inse
rtC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te I
nse
rt()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtC
an
did
atP
C()
Inse
rtC
an
did
atS
()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
ch
arg
é r
ecru
tem
en
t
SG
BD
:UI
En
tre
tie
n:W
ork
flo
w R
ecru
tem
en
t:E
ntr
eti
en
Bu
sin
ess
Co
mp
on
en
t:E
ntr
eti
en
DA
O:R
ecru
tem
en
tPro
ce
ssC
om
po
ne
nts
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
alt
Pla
nif
ierE
ntr
eti
en
()
Inse
rtC
an
did
atB
C()
Inse
rtC
an
did
atD
AO
()
Exé
cu
tio
n R
eq
ue
te I
nse
rt()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Inse
rtC
an
did
atP
C()
Inse
rtC
an
did
atS
()
Inse
rtio
n R
éu
ssie
Inse
rtio
n R
éu
ssie
Inse
rtio
n E
ch
ou
ée
Inse
rtio
n E
ch
ou
ée
Figure 3.6 : Diagramme de séquence : Planification Entretien
Chapitre 3 : CONCEPTION
52
Acteur : Chargé Recrutement.
But : Planifier un Entretien.
Enchaînement nominal :
La chargée recrutement introduit les informations nécessaires à la planification de l’entretien :
candidat, date, heure, lieu et évaluateur.
La planification est en fait l’insertion de nouvel entretien dans la base de donnée, pour ce
faire, un passage par toutes les couches de l’application est obligatoire surtout le passage par
la couche Workflow Service WF qui va créer une instance du workflow sur laquelle va se
faire le flux du travail.
En effet, à partir de l’interface de planification, les données passent par la classe
« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,
par la couche workflow service WF. Ils passent après par la classe
« EntretienBusinessComponent » dans la couche « BusinessComponent », enfin par la classe
« EntretienDAO » pour lancer la requête insert vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le
succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que
l’opération a échoué.
Chapitre 3 : CONCEPTION
53
2.3. Diagramme de séquence : Evaluateur
Co
uch
e
Wo
rkfl
ow
WF
Ré
ali
sati
on
En
tre
tie
n()
Se
nd
Re
ply
En
tre
tie
n()
Mo
dif
ierE
ntr
eti
en
DA
O()
Exé
cu
tio
n R
eq
ue
te U
pd
ate
()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Re
ce
ive
En
tre
tie
n()
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Mo
dif
ierE
ntr
eti
en
PC
()
Mo
dif
ierE
ntr
eti
en
S()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Eva
lua
teu
r
SG
BD
:UI
Fic
he
En
tre
tie
n:W
ork
flo
w R
ecru
tem
en
t:E
ntr
eti
en
Bu
sin
ess
En
titi
es
:En
tre
tie
nD
AO
:Re
cru
tem
en
tPro
ce
ssC
om
po
ne
nts
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
alt
Ré
ali
sati
on
En
tre
tie
n()
Se
nd
Re
ply
En
tre
tie
n()
Mo
dif
ierE
ntr
eti
en
DA
O()
Exé
cu
tio
n R
eq
ue
te U
pd
ate
()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Re
ce
ive
En
tre
tie
n()
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Mo
dif
ierE
ntr
eti
en
PC
()
Mo
dif
ierE
ntr
eti
en
S()
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n R
éu
ssie
Op
éra
tio
n E
ch
ou
ée
Op
éra
tio
n E
ch
ou
ée
Figure 3.7 : Diagramme de séquence : Réalisation Entretien
Chapitre 3 : CONCEPTION
54
Acteur : Evaluateur.
But : Réaliser un Entretien.
Enchaînement nominal :
L’évaluateur introduit les informations nécessaires à la fiche de l’entretien ainsi que la note
qu’il a attribué au candidat.
L’évaluation est en fait la modification d’un entretien existant dans la base de données.
Néanmoins, on doit passer par toutes les couches de l’application pour faire les modifications
nécessaires.
En effet, à partir de l’interface de réalisation de l’entretien, les données passent par la classe
« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,
par la couche service WCF. Ils passent après par la classe « EntretienBusinessComponent »
dans la couche « BusinessComponent », enfin par la classe « EntretienDAO » pour lancer la
requête insert vers la base de données.
La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le
succès de l’opération.
Enchaînement Alternatif :
Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que
l’opération a échoué
Conclusion
Dans ce chapitre, nous avons réalisé les principaux diagrammes représentatifs du déroulement
de notre application ainsi que ses aspects statiques et comportementaux. Ceci nous a permis
de déterminer la façon à travers laquelle nous allons réaliser une application répondant aux
besoins déjà spécifiés.
Dans le chapitre suivant nous présenterons les étapes de réalisation de notre application ainsi
que quelques interfaces représentatives de notre travail.
55
CHAPITRE 4
REALISATION
Chapitre 4 : REALISATION
Introduction
Après l’étude conceptuelle du système, nous passons à l’étape suivante; celle du
développement. Nous commençons par présenter les outils matériels et logiciels qui nous
ont permis de développer notre système, ensuite nous allons présenter une vue globale sur
ce dernier, et enfin une présentation de ses principales fenêtres.
1. Présentation de l’architecture
1.1 Choix de l’architecture
Pour la conception de l’architecture, nous avons suivi le guide des bonnes pratiques de
Microsoft pour la conception des architectures d’applications [11]. L’architecture suivante
(figure 4.1) présente le modèle de référence exhaustive pour toute application à développer
avec le langage .NET.
Figure 4.1 : Architecture commune d’une application
Chapitre 4 : REALISATION
57
1.2 Structure de l’application
Parmi toutes ces couches, pour le besoins de notre application, nous avons implémenté les
couches suivantes :
Presentation Layer
Service Layer
Business Layer
Data Layer
Framework.
Figure 4.2 : Structure en couche du Framework OXIADOTNET
1.2.1 Présentation Layer
La couche Présentation est constituée de deux composants :
UI Components : C'est le composant visuel de l'interface. Elle permet d'afficher les
informations à l'utilisateur. Ce sont par exemple les pages ASP.NET, les WinForms, dans
notre cas des interfaces conçues en WPF.
Chapitre 4 : REALISATION
58
UI Process Components : Il permet dans la plupart des cas, l'interaction de l'utilisateur avec le
système qui suit un processus connu. Par exemple, l'utilisateur va choisir une catégorie de
produits avant de sélectionner un produit particulier dans cette liste.
1.2.2 Service Layer
Service Interfaces : Ce composant ouvre le logique métier du système en exposant les services
disponibles. C'est grâce à cette interface qu'on va pouvoir " attaquer " le cœur de l'application.
Cette interface définit les modèles de communication en tenant compte des formats de
données, des exceptions. Dans notre cas, nous avons exposé les services à travers une couche
de communication WCF.
1.2.3. Business Layer
Business Components: Ce composant implémente les règles métier. C’est ici où est
implémenter la logique du métier.
Business Entity: Les composants de l'application doivent pouvoir s'échanger des données. Cet
échange peut se faire par différents formats. Cela peut être des données sérialisés (DataSets,
DataReaders, XML...) ou directement des classes. Ces classes sont appelées aussi POCO,
elles sont sollicitées partout dans l’application.
1.2.4. Data Layer
Data Access Components : C’est le composant qui accède directement à la base de données.
Nous l’avons conçu selon le patron de conception DAO. Il contient les requêtes SQL
permettant de manipuler les données de la base de données.
1.2.5. Framework
Cette dernière couche contient toutes les fonctionnalités propriétaires à notre
application : Contrôles, fonction d’aide à la saisie, gestionnaire d’exceptions, gestionnaire de
journalisation…
1.3 Schéma de dépendance entre couches
Le schéma suivant (figure 4.3) met en évidence la dépendance entre couches lors de la
conception de l’application.
Chapitre 4 : REALISATION
59
Figure 4.3 : Schéma de dépendance entre couches
La liaison entre les différentes couches : (flèche « Référence ») est utilisée pour
décrire les interdépendances entre couches.
Exemple : la couche « Business Components » référence la couche « Business
Entities ».
La couche « Business Entities » contient les entités utilisées partout dans le système.
C’est pourquoi elle est référencée par toutes les autres couches.
La couche « Business Components » contient les classes métier de notre application.
Scénario : obtenir les informations d’un test.
La classe concernée au niveau de la couche « Business Components » : TestBC. Cette classe
a besoin des entités candidat, Test, User se trouvant au niveau de la couche « Business
Entities », d’où l’importance du référencement.
Chapitre 4 : REALISATION
60
2. Environnement de développement
2.1. Environnement matériel
L’environnement matériel qu’on a utilisé se présente comme suit :
Processeur : Intel® Dual Core CPU T2080 @ 1.73 GHz
Mémoire RAM : 3 Go
Disque Dur : 120 Go
Carte Graphique : Mobile Intel 45 Express Chipset Family
Système d’Exploitation : MS Windows SEVEN 32-bit.
2.2. Environnement logiciel
2.2.1 Framework utilisé
.NET Framework 4.0
Figure 4.4 : Logo Microsoft .NET
Le Framework .NET est un produit Microsoft, société avec laquelle OXIA est
partenaire. Ce choix rentre dans une stratégie d’entreprise désirant implémenter entièrement
son système d’information à base de Framework .NET. Notre projet constitue ainsi un projet
pilote pour d’autres entreprises de plus grande taille.
Le choix s’est porté sur la version 4.0.Microsoft a annoncé la version 4 du Framework
.NET le 12 avril. Cette version offre comme nouveautés :
Autorisations des paramètres nommés et optionnels
Chapitre 4 : REALISATION
61
Prise en charge totale des langages IronPython, IronRuby et F #.
Prise en charge d’un sous-ensemble du Framework .NET et ASP.NET avec la variante
"Server Core" de Windows Server 2008 R2.
Intégration de la plate-forme de modélisation Oslo.
Inclusion de nouveaux types de travailler avec précision arbitraire arithmétique
(System.Numerics.BigInteger) et les nombres complexes
(System.Numerics.Complex).
Microsoft Enterprise Library 5.0
Figure 4.5 : Logo Microsoft Entreprise Library 5.0
Enterprise Library [12] est un Framework contenant plusieurs blocs d'application. Ils
permettent de résoudre les problèmes courants auxquels on est confronté lorsqu'on développe
un projet. Les applications blocs encapsulent les méthodes de développement recommandées
par Microsoft (" best practices "). Enterprise Library contient 6 blocks d'application :
Caching
Cryptography
Data Access
Exception Handling
Logging
Security
Enterprise Library inclut également un ensemble de fonctions fondamentales, notamment
des services de configuration, d'instrumentation et de création d'objets. Ces fonctions sont
utilisées par tous les autres blocs d'application.
Chapitre 4 : REALISATION
62
Il y a plusieurs avantages à utiliser le Framework Enterprise Library :
Uniformité : Tous les blocs d'application utilisent les design patterns.
Extensibilité : Les blocs d'application permettent d'être personnalisés en offrant la
possibilité d'ajouter du code dans les classes fournies.
Facile d'utilisation : Enterprise Library contient un outil graphique de configuration,
une installation simple, une documentation utilisateur et des exemples d'application.
Intégration : Les blocs d'application d'Enterprise Library sont conçus pour
communiquer ensemble.
Gratuité : Enterprise Library est redistribué gratuitement.
Pour le besoin de notre application nous avons utilisé tous les blocks sauf celui de
cryptographie :
Accès à la base de données (Block Data Access Application)
Gestion d’accès des utilisateurs par les autorisations (Block Security Application)
Gestion des exceptions (Block Exception Handling Application)
Journalisation des exceptions et des événements sur des fichiers (Block Logging
Application)
Enregistrement des données dans le cache de l’application (Block Caching
Application)
Le choix s’est porté sur la version 5 d’Enterprise Library car c’est la seule version qui
fonctionne avec le Framework .NET 4.0. Cette version d’Enterprise Library a été publiée le
20 Avril 2010.
2.2.2 Technologies de développement
WPF (Windows Presentation Foundation)
Windows Presentation Foundation (WPF) [13] est un sous-système graphique conçu pour le
rendu des interfaces utilisateur dans les applications basées sur Windows. Conçu pour
Chapitre 4 : REALISATION
63
supprimer les dépendances sur le vieillissement du sous-système GDI, WPF est construit sur
DirectX, qui fournit l'accélération matérielle et permet les fonctions modernes de l'interface
utilisateur telles que la transparence, dégradés et transformations. WPF fournit un modèle de
programmation cohérent pour générer des applications et offre une séparation claire entre
l'interface utilisateur et le logique métier.
WPF offre également un nouveau langage de balisage, appelé XAML, qui est un autre
moyen pour définir les éléments d'interface utilisateur et les relations avec les autres éléments
de l’interface utilisateur. WPF peut être déployé sur le bureau ou hébergé dans un navigateur
web. Il permet également le contrôle riche, la conception et le développement des aspects
visuels de programmes Windows. Il vise à unifier un certain nombre de services applicatifs :
interface utilisateur, dessins 2D et 3D, documents fixes et adaptatives, typographie avancée,
graphiques vectoriels, raster graphique, animation, la liaison de données, audio et la vidéo.
WPF est inclus avec Windows 7, Windows Vista et Windows Server 2008 et est également
disponible pour Windows XP Service Pack 2 ou ultérieur et Windows Server 2003.
WCF (Windows Communication Foundation)
Windows Communication Foundation (WCF) [7] est la nouvelle technologie de
développement d’applications distribuées interopérables, fiables et sécurisées. L’objectif de
WCF est d’unifier les modes de communication que l’on a aujourd’hui à notre disposition
(services web, accès à distance, etc.) grâce à un nouveau modèle de programmation orienté
services.
WCF est utilisé dans notre application au niveau de la couche, son fonctionnement
consiste à implémenter des contrats de services permettant ainsi de relier la couche Business
Layer (Business Component) à la couche présentation (UI process Component).
WF4 (Windows Workflow Foundation)
Windows Workflow Foundation (WF) [8] est une technologie de Microsoft pour la
définition, l'exécution et la gestion des workflows. Tout d'abord, cette technologie a été
publiée en novembre 2006 dans le cadre du .NET Framework 3.0.
Chapitre 4 : REALISATION
64
Un programme basique de workflow est comme les programmes traditionnels qui
permettent de coordonner les travaux et d'effectuer des opérations mais a quelques différences
près :
Les Workflows utilisent un modèle déclaratif d'écriture de programmes en reliant un
ensemble prédéfinies d'activités plutôt qu'un modèle de programmation impératif
d'écriture.
Les Workflows peuvent gérer un travail de longue durée par la persistance d’un
magasin durable, comme une base de données, lorsque inactif et se charger encore une
fois quand il y a du travail à effectuer.
Un Workflow peut être modifiée dynamiquement lors de l'exécution lorsque de
nouvelles conditions nécessitent qu’un workflow se comporte différemment que
lorsqu'il a été créé.
Les Workflows fournissent une séparation distincte des règles métier et de code de
l'application hôte, ce qui la rend plus facile à modifier.
Un Workflow prend en charge les workflows séquentiels pour les systèmes avec une
logique séquentielle et workflows de machine d'état pour les systèmes basés sur
l'événement logique.
Les Workflows ont généralement une contrepartie visuelle qui permet une description de
l'organigramme de leur logique
2.2.3 Langage de développement
Langage C#
Le C# (prononcé C-Sharp) est un langage de programmation orienté objet à typage
fort, créé par la société Microsoft, et notamment par l’un de ses employés, Anders Hejlsberg,
le créateur du langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant
d'utiliser toutes ses capacités. C# 4.0 est la dernière version de la programmation langage C#,
elle a été publiée le 12 avril 2010.C’est la version que nous avons utilisé pour notre
développement.
Chapitre 4 : REALISATION
65
Langage XAML
XAML [11] est un langage déclaratif basé sur le langage XML. Prononcé Zammel, ces
initiales correspondent à eXtensible Application MarkupLanguage.
XAML facilite le travail du développeur et permet d'écrire une application client
Windows aussi aisément qu'une application web. L'idée est en effet de séparer la déclaration
des objets d'un programme du code sous-jacent comme cela est déjà le cas dans les
applications Web de type ASP.NET.
Dans le cas de XAML pour WPF, le développement de l'interface utilisateur étant
confié à des designers, Microsoft propose à ceux-ci le logiciel Expression Interactive
Designer pour manipuler cette interface. XAML inclut également des fonctionnalités pour
manipuler des objets en trois dimensions, de manière analogue à X3D.
2.2.4 Logiciels utilisés
Microsoft Visual Studio 2010 Ultimate
Figure 4.6 : Microsoft Visual Studio 2010 Ultimate
Microsoft Visual Studio 2010 Ultimate est la suite complète d'outils de gestion du cycle de
vie application permettant aux équipes de garantir des résultats de qualité, de la conception au
déploiement. Si vous créez de nouvelles solutions ou améliorer les applications existantes,
Visual Studio 2010 Ultimate permet de vous faire vivre un nombre croissant de plates-formes
et de technologies de ciblage de votre vision — y compris l’informatique dans les nuages et le
calcul parallèle.
Visual Studio 2010 Ultimate présente divers fonctionnalités :
Application Lifecycle Management (ALM)
Chapitre 4 : REALISATION
66
Débogage et diagnostics
Outils de test
Architecture et modélisation
Développement de base de données
Environnement de développement intégré
Prise en charge des plates-formes de développement
Team Foundation Server
Lab Management
Abonnement MSDN
Microsoft Expression Blend® 4
Figure 4.7 : Microsoft Expression Blend 4
Microsoft Expression Blend est l'outil professionnel de conception d'interfaces utilisateurs de
Microsoft pour créer des interfaces graphiques riches orientées Web pour des applications de
bureau mêlant le meilleur du Web et du poste de travail. Expression Blend est écrit en
utilisant le .NET Framework 3.0 et le Windows Presentation Foundation (WPF).
Le nom de code de ExpressionBlend était Sparkle. À l'origine le produit a été annoncé en tant
que Microsoft Expression Interactive Designer, avant qu'il ne soit renommé en Expression
Blend en décembre 2006.
Expression Blend supporte le moteur des textes de WPF avec une typographie OpenType
avancée, le ClearType, les gadgets 2D vectorisés, et les gadgets 3D avec accélération
matérielle par l'intermédiaire de DirectX. Expression Blend est écrit entièrement en Windows
Chapitre 4 : REALISATION
67
Presentation Foundation à l'opposé des anciennes technologies comme le GDI ou GDI+.
Expression Blend fait partie de la suite Microsoft Expression Studio.
Oracle 8i
Figure 4.8 : Oracle
Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis
l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifié de système
de gestion de base de données relationnel-objet (SGBDRO).
Oracle est un SGBD permettant d'assurer :
La définition et la manipulation des données
La cohérence des données
La confidentialité des données
L'intégrité des données
La sauvegarde et la restauration des données
La gestion des accès concurrents
TortoiseSVN
Figure 4.9 : Tortoise SVN
C’est un logiciel client de SVN (Système de gestion des versions). Il a permis à tous
les membres de l’équipe de développeurs de travailler sur un seul projet commun hébergé sur
un serveur.
En s'intégrant dans l'explorateur de Windows, TurtoiseSVN offre aux utilisateurs de
Windows une interface graphique permettant de réaliser la plupart des tâches qu'offre SVN en
ligne de commande.
Chapitre 4 : REALISATION
68
L'explorateur Windows s'enrichit des fonctionnalités suivantes :
Superposition d'icône aux répertoires et fichiers permettant de visualiser
instantanément l'état (à jour, modifié, en conflit...)
Menu contextuel permettant de faire la mise à jour et de confirmer la modification, à
l'échelle d'un fichier, d'une sélection de fichiers ou encore d'un répertoire
Possibilité d'ajouter en mode détails de l'explorateur des colonnes de type numéro de
révision
3. Scénarios d’exécution
3.1 Interfaces du Framework
Dans cette partie, nous allons décrire les différentes interfaces propre au Framework qu’on a
conçu, et donc ces interfaces sont utilisées par toutes les applications intégrées dans le
Framework, dont notre application « Workflow Recrutement ».
3.1.1 Authentification
Figure 4.10 : Interface d’authentification
Cette interface (figure 4.10) est la première fenêtre lors du lançant l’application.
L’utilisateur est invité à saisir son login et mot de passe pour pouvoir accéder. Une fois
authentifié l’utilisateur accède à la fenêtre principale de l’application.
Chapitre 4 : REALISATION
69
3.1.2 Interface principale
Figure 4.11 : Interface Principale
Cette interface (Figure 4.11) constitue la première interface lancée une fois
l’utilisateur authentifié. Chaque utilisateur possède un ensemble d’autorisations. Une
autorisation est une combinaison entre un profil et un module.
Le menu à gauche (1) permet d’afficher les modules auxquels l’utilisateur est autorisé.
En cliquant sur un module, une liste de liens apparaît dans la barre à gauche (2). Ces liens
sont ordonnés dans un ordre hiérarchique sous forme d’arbre.
En cliquant sur un lien, la fenêtre associée apparaît à l’interface principale dans la zone
(4).
La barre d’outils (3) offre plusieurs possibilités à travers des boutons dont l’activation
dépend de l’écran en cours. Parmi ces fonctionnalités, on peut trouver : Le retour à la page
d’accueil, l’enregistrement, la recherche, la mise en forme, l’impression, l’ajout, la
modification, le rafraîchissement des valeurs de l’écran, la suppression, l’affichage de
l’historique, l’export sous format Word (.doc), l’export sous format Excel (.xls), la validation,
l’annulation, l’ajout à la liste de favoris, l’affichage d’informations.
1
2
4
3
Chapitre 4 : REALISATION
70
3.1.3 Paramétrage des acteurs du workflow Recrutement
Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement
A travers cette interface (figure 4.12), le paramétrage devient une tache simple et facilement
accessible. En effet, elle permet d’ajouter, modifier ou supprimer un utilisateur dans la liste de
rôles du workflow recrutement et ceci en cliquant avec le bouton droit de la souris
directement sur la grille qui contient les utilisateurs de chaque profil.
Chapitre 4 : REALISATION
71
3.1.4 Paramétrage des autorisations du workflow Recrutement
Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement
A travers cette interface (figure 4.13), le paramétrage des autorisations devient une tache
simple et facilement accessible. En effet, il suffit de cocher le droit de chaque profil ensuite
cliquer sur valider dans la ToolBar.
3.1.5 Interface d’aide à la saisie : Recherche F12
Figure 4.14 : Fenêtre d’aide à la saisie
Cette interface (figure 4.14) est conçue pour faciliter la recherche.
Chapitre 4 : REALISATION
72
En effet, après avoir placer le curseur de la souris sur le champs de texte souhaité pour la
recherche, en cliquant sur F12, une liste d’attributs souhaités s’affiche.
3.2 Principales interfaces du Workflow Recrutement
3.2.1 Ecran Candidat
Figure 4.15 : Interface Candidat
Cet écran (figure 4.15) s’affiche quand on clique sur Candidat dans le menu à gauche.
La grille au milieu affiche la liste de candidats selon le statut du candidat souhaité : candidat
soumis, pour test, pour entretien, pour offre, retenu à chaud, recruté ou rejeté.
Chapitre 4 : REALISATION
73
3.2.1.1 Ecran Ajout Candidat
Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles
Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience
Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications
Chapitre 4 : REALISATION
74
Ces écran (figure 4.16, 4.17 et 4.18) sont conçu pour ajouter un candidat, ajouter tous les
détails des candidats : ses informations personnelles, son niveau académique, son expérience,
ses stages, ses références et ses certifications.
3.2.1.2 Ecran Affichage et Modification Candidat
Les écrans d’affichage et de modification sont les mêmes que ceux de l’insertion avec en plus
la possibilité de choisir l’ID du candidat au début pour pouvoir afficher directement les détails
de ce candidat.
3.2.1.3 Ecran Recherche Candidat
Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience
Ces écrans (figure 4.19) sont conçus pour faciliter la recherche du candidat selon des filtres
informations personnelles et synthèse expérience professionnelle. L’utilisateur introduit les
paramètres de recherche qu’il veut et ensuite il clique sur valider. Il obtient comme résultat
une liste de candidats selon les informations qu’il a introduites.
3.2.1.4 Candidat pour Offre
Figure 4.20 : Ecran Candidat pour offre
Chapitre 4 : REALISATION
75
Cet écran (figure 4.20) sert à choisir les candidats pour offre. Quand on clique sur le bouton
valider après avoir choisi le candidat pour offre, un autre écran s’affiche : écran offre à faire
(figure 4.21).
Cet écran précise des informations concernant le profil à proposer au candidat.
Figure 4.21 : Ecran Candidat : Offre à Faire
3.2.1.5 Ecrans Candidat pour Test/pour Entretien/Recruté/Rejeté
Ces écrans contiennent tous des grilles de données qui affiche chacune la liste de candidat
selon son statut. Chaque écran contient également la tache suivante à faire.
Exemple : la tâche qui suit l’état « pour Test » c’est la planification du Test.
3.2.2 Ecran Test/Entretien
Figure 4.22 : Ecran Test/Entretien
Chapitre 4 : REALISATION
76
Cet écran (figure 4.22) s’affiche quand on clique sur Test(ou Entretien) sur le menu de
gauche.
La grille au milieu affiche la liste de tests (ou d’entretiens) selon le statut du Test (ou de
l’entretien).
3.2.2.1 Ecran Test/Entretien non Planifié
Figure 4.23 : Ecran Entretien non planifié
Cet écran (figure 4.23) affiche les entretiens non planifiés, si on coche les entretiens à
planifier et on clique sur valider, un écran de planification du test ou de l’entretien (figure
4.24) s’affiche permettant d’introduire les différentes informations concernant le test ou
l’entretien.
Figure 4.24 : Ecran planifier Entretien
Chapitre 4 : REALISATION
77
3.2.2.2 Ecran Test/Entretien Planifié
Figure 4.25 : Ecran Test planifié
Cet écran (figure 4.25) affiche la liste des candidats qui ont un test planifié. Dans la grille de
données, on peut cocher les cases « Réaliser le Test », « Reporter le Test » ou « Annuler le
Test » ensuite cliquer sur le bouton valider pour valider le choix et passer à l’état suivant du
workflow.
3.2.2.3 Ecran Test/Entretien Réalisé/Reporté/Annulé
Ces écrans sont semblables. Ils contiennent une grille de données qui affiche les candidats
suivant le statut du test ou de l’entretien : réalisé, reporté ou annulé.
4. Gestion du projet
Etant gérer par le processus Scrum, notre projet est organisé en sprints d’une durée de
deux semaines, une durée que notre ScrumMaster a jugée raisonnable pour que tous les
membres de l’équipe réalisent leurs tâches respectives. À chaque sprint, nous étions amenés à
réaliser un item de Backlog produit. La liste suivante présente les Backlog produit :
Apprentissage et Documentation (Langage WPF, WF, Enterprise Library 5, Couche
Persistance)
Chapitre 4 : REALISATION
78
Conception et réalisation du Framework (Interface IHM, ToolBar avec Interface en
WPF, ToolBox en WPF générée à partir de la Base de données).
Conception et Réalisation flux de travail de Recrutement (Développement des entités
POCO, Développement de la Couche DAO, Diagramme de classes, Développement
des interfaces)
En parallèle, nous avons élaboré ce rapport de Projet de fin d’études.
A noter également qu’après chaque réunion avec le client, il nous est demandé de
préparer un compte rendu de réunion et de mettre à jour le document de spécifications
fonctionnelles. La démarche suivie pour élaborer ce document se base principalement sur des
captures d’écrans pour illustrer les différentes fonctionnalités de l’application, chaque capture
est accompagnée d’un tableau décrivant les paramètres illustrés par l’écran.
La figure ci-dessous (figure 4.26), présente un diagramme de Gantt, qui est
l’illustration des efforts impartis à chaque phase du projet.
Figure 4.26 : Diagramme de Gantt
Conclusion
Cette dernière partie de rapport nous a permis de présenter l’architecture adoptée pour
structurer notre application. Nous avons aussi présenté l’environnement matériel et logiciel de
l’application, notamment l’utilisation des Framework .NET 4.0 avec les outils les plus
récents.
Chapitre 4 : REALISATION
79
Nous avons ensuite enchaîné avec la partie démonstration qui rassemble quelques captures
d’écran de l’application développée. La fin du chapitre a été consacrée à la présentation de
notre planning de projet en diagramme de Gantt.
Conclusion Générale
L’objectif de notre projet de fin d’étude consiste en la modélisation et la mise en œuvre des
Processus workflow de la gestion de recrutement avec le Framework Windows Workflow
Foundation. Un tel projet vise à construire une plateforme solide « OXIADOTNET »,
propriétaire à la société, intégrant une diversité d’autres modules bénéficiant ainsi de la
richesse et de la fluidité du Framework .NET.
Durant notre projet, nous avons eu pour mission, dans une première étape, l’étude du
Framework WF4 en mettant l’accent sur ses services et son environnement d’exécution, puis
nous avons procédé au recensement des besoins et évoqué les fonctionnalités que OxiaDotNet
peut offrir.
Dans la deuxième étape, nous avons modélisé les processus métiers de la gestion du
recrutement. La dernière étape consistait en la mise en œuvre d’une application WPF qui gère
la totalité des taches relatives au recrutement et dont le service ressource humaine en est
responsable.
Ainsi, au terme de ce projet, nous sommes parvenues à mener une étude analytique et
conceptuelle du Framework OXIADOTNET et achever la modélisation des processus métiers.
Outre, nous avons réussi à nous familiariser avec le développement des Workflows sous WF4
en implémentant l’application hôte des processus Workflows.
Ce projet de fin d’étude a constitué, pour nous, une occasion intéressante d’acquérir de
nouvelles connaissances dans le domaine de gestion de recrutement, la modélisation des
processus Workflows et leurs mise en œuvre sur le Framework Windows Workflow
Foundation 4.
En perspective, nous essayerons de compléter l’implémentation des fonctionnalités conformes
au processus de recrutement de départ. Et améliorer au fur et à mesure l’intégralité des taches
du service ressources humaine.
81
Bibliographie/Netographie
Netographie
[1] http://www.oxiasoft.com
[2] http://fr.wikipedia.org/wiki/Méthode_agile
[3] http://agilemanifesto.org
[4] http://agilemanifesto.org/principles.html
[5] http://fr.wikipedia.org/wiki/Scrum
[6] http://www.mountaingoatsoftware.com
[7] http://msdn.microsoft.com/fr-fr/netframework/aa663324.aspx
[8] http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
[9] http://www.commentcamarche.net/contents/oracle/oracintro.php3
Bibliographie
[10] UML 2 par la pratique, 4ème
édition, Pascal ROQUES Editions Eyrolles
[11] Microsoft Application Architecture Guide 2nd
Edition, ISBN: 9780735627109 Microsoft
Corporation
[12] The Definitive guide of Microsoft Enterprise Library, Keenan Newton ISBN: 10: 1-59059-
655-2
[13] WPF par la pratique, Thomas Lebrun ISBN : 978-2-212-12422-4 Editions Eyrolles
82
Annexes
83
Annexe A : Diagramme de flux de candidat
Processus Recrutement
Dire
ctio
n R
esso
urc
es
Hu
ma
ine
s
Re
sp
on
sa
ble
Te
ch
niq
ue
co
mp
te
Dire
cte
ur
En
ga
ge
me
nt/
Op
éra
tio
ns/S
SC
DG
BA
Ma
na
ge
r
Besoin en recrutement Gestion des entretiens Finalisation du recrutement Intégration Evaluation Titularisation
Besoin en
recrutement
Demande
d’ouverture
de poste
Validation
OK
Recherche de
profils
Réception des
candidatures
Réalisation des
entretiens de
recrutement(3)
Boîte RHAnnonce
Presse
Sites
emploi/
Atuge
Validation
OK
Décision de
recrutement
NOK
Fiche
évaluation
entretien
NOK
Préparation offre
& éléments
contractuels
Offre emploi Contrat de
travail
Préparation arrivée
nouvelle recrue
(compte réseau,droits
d’accès, boîte
mail...etc
Intégration
générale
Intégration
Spécifique
Evaluation poste
recrutement après
3 moisFiche
évaluation
Arrêt du contrat
Décision
NOK
Description de
Poste
Plan
intégration
Plan
intégration
Figure A.1 : Diagramme de flux de candidat
84
Annexe B : Schématiquement workflow RH
Figure B.1 : Schématiquement workflow RH
85
Annexe C : UML
Figure C.1 : Emblème officiel d’UML
UML [10] est la forme contractée de « Unified Modeling Language », qui peut se
traduire en français par langage unifié pour la modélisation. UML représente l’état de l’art des
langages de modélisation objet. Il fournit les fondements pour spécifier, construire, visualiser
et décrire un système logiciel. Pour cela, UML se base sur une sémantique précise et sur une
notation graphique expressive. Il définit des concepts de base et offre également des
mécanismes d’extension de ces concepts.
UML est un langage de modélisation objet. En tant que tel, il facilite l’expression et la
communication de modèles en fournissant un ensemble de symboles (la notation) et de règles
qui régissent l’assemblage de ces symboles (la syntaxe et la sémantique).
UML n’est pas un langage propriétaire : il est accessible à tous et les fabricants
d’outils ainsi que les entreprises de formation peuvent librement en faire usage. La volonté
d’ouverture, la richesse de la notation et la définition sémantique précise des éléments de
modélisation font d’UML un langage de modélisation général simple, sans être simpliste pour
autant.
Dans UML chaque diagramme permet d’exprimer certains points d’un même
problème. La combinaison de plusieurs digrammes permettra donc d’avoir une vue complète
du système informatique. Ainsi en fonction du problème à résoudre, il convient de choisir les
diagrammes adéquats à utiliser. UML définit neuf types de diagrammes dont nous détaillerons
ceux que nous utiliserons dans la suite :
86
Diagramme de cas d’utilisation : Les cas d'utilisations [9] décrivent le comportement du
système du point de vue utilisateur sous la forme d'actions et de réactions. Un cas d'utilisation
indique une fonctionnalité du système déclenché par un acteur externe au système. Ce genre
de diagramme permet de mettre en place et de comprendre les besoins du client. Dans le
diagramme, interviennent trois éléments : les acteurs, le système et les cas d'utilisation.
L'acteur représente un rôle joué par une personne ou un autre système qui interagit avec le
système en cours de modélisation. Un cas d'utilisation regroupe plusieurs scénarios
d'utilisation du système.
Diagramme de classe : Le diagramme de classes [9] est le point central dans un
développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités
manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure
d’un code orienté objet ou, à un niveau de détail plus important, les modules du langage de
développement.
Diagramme de déploiement : il indique comment l’application sera distribuée entre les
différents composants matériels.
Diagramme de séquence : Les diagrammes de séquences permettent de représenter des
collaborations entre objets selon un point de vue temporel, on y met l'accent sur la
chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer
un cas d'utilisation.
Diagramme d’état/transition : il modélise les aspects contrôle et temps du système.
Diagramme d’activité : UML permet de représenter graphiquement le comportement d'une
méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une
variante des diagrammes d'états-transitions).
Diagramme de collaboration : il modélise la communication possible entre les classes dans
un scénario particulier.
Diagramme des composants.
Diagramme d’objets.
87
Glossaire
RH: Ressources Humaines
DRH: Direction Ressources Humaines
RRH: Responsable Ressources Humaines
CV: Curriculum Vitae
LM: Lettre de Motivation
RDV: Rendez-vous
BA: Business Area
BU: Business Unity
CMMI: Capability Maturity Model integration
DAO: Data Access Object
ENTLIB: Enterprise Library
ISBN: (International Standard Book Number)
Netographie: Bibliographie du net, synonyme de webographie
POCO: Plain Old CLR Object
SCRUM: Terme emprunté au rugby et signifie mêlée
SGBDR: Système de Gestion de Base de Données Relationnel
SQL: StructuredQueryLanguage, utilisée pour la manipulation des données d’une Base de
données
SSII: Société de Services en Ingénierie Informatique
88
SVN: SubVersion, système de gestion des versions.
UML: Unified Modeling Language
XAML: eXtensible Application Markup Language
XML: eXtensible Markup Language
WCF: Windows Communication Foundation
WPF: Windows Presentation Foundation
WF: Workflow Foundation
Top Related