Conception et dØveloppement d’un outil de
simulation budgØtaire
SeifAllah Methnani
2 juillet 2015
DØdicaces
A mes chers parents Salwa et Amor...
A ma chŁre soeur Alia et mon cher frŁre Ali...
A mes amies et amis...
A tous ceux que j’aime...
I
Remerciments
Je rends gr(cid:226)ce (cid:224) Dieu de m’avoir donnØ le courage et la force pour rØaliser ce
travail.
Je tiens (cid:224) exprimer ma profonde gratitude envers Monsieur Mohamed Amine
Issaoui pour m’avoir pris en stage, ainsi qu’(cid:224) Monsieur Walid Baklouti pour m’avoir
encadrØ et orientØ durant mon projet de (cid:28)n d’Øtudes. Bien sßr, je les remercie
Øgalement pour leurs nombreux conseils ainsi que pour leurs patiences.
Je tiens (cid:224) remercier mon encadrant (cid:224) ESPRIT, Madame Zouhour Hammouda,
pour son aide prØcieux, sa qualitØ d’encadrement et le savoir qu’elle m’a transmis.
Je tiens (cid:224) remercier Øgalement Mesdames Messieurs les membres de jury pour
avoir acceptØs de participer (cid:224) l’Øvaluation de ce modeste travail.
Mes remerciements vont (cid:224) mes enseignants (cid:224) ESPRIT pour tous ce qui m’ont
donnØe au (cid:28)l de l’annØe thØorique des conseils judicieux.
J’exprime toute ma gratitude (cid:224) toute ma famille : (cid:19) vous vous Œtes dØpensØs
pour moi sans compter. En reconnaissance de tous les sacri(cid:28)ces consentis par tous
et chacun pour me permettre d’atteindre cette Øtape de ma vie. Avec toute ma
tendresse (cid:20).
Mes remerciements s’adressent aussi (cid:224) tous mes amis pour leurs encourage-
ments, leur soutien de tous les instants et la con(cid:28)ance qu’ils m’ont accordØ.
II
Table des matiŁres
Introduction gØnØrale
1
1 PrØsentation gØnØrale
1.1.1
1.1.2
1.2 Cadre gØnØral
3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
. . . . . . . . . . . . . . . . .
1.1 PrØsentation de l’organisme d’accueil
3
SOPRA Group . . . . . . . . . . . . . . . . . . . . . . . . .
3
Sopra HR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.1 ProblØmatique . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2.2 Objectif du projet . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3 Choix mØthodologique . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3.1 La mØthode de gestion du projet : SCRUM . . . . . . . . . .
5
1.3.2 Cycle de vie d’un logiciel . . . . . . . . . . . . . . . . . . . .
6
1.4 MØthodologies de conception . . . . . . . . . . . . . . . . . . . . . .
8
1.4.1 MERISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.4.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
9
1.4.3 La dØmarche adoptØe . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 (cid:201)tude prØalable
11
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 (cid:201)tat des lieux . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Solution existante . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2
2.1.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Solution proposØe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Analyse et spØci(cid:28)cation des besoins
15
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Identi(cid:28)cation des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1
I
TABLE DES MATI¨RES
Sopra HR
3.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . 16
3.2.1 Les besoins fonctionnels
3.2.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . 16
3.3 SpØci(cid:28)cation des besoins . . . . . . . . . . . . . . . . . . . . . . . . 17
SpØci(cid:28)cation gØnØrale . . . . . . . . . . . . . . . . . . . . . . 17
SpØci(cid:28)cation dØtaillØe . . . . . . . . . . . . . . . . . . . . . . 19
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1
3.3.2
4 Conception
25
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
. . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Conception gØnØrale
4.1.1 Architecture de l’application . . . . . . . . . . . . . . . . . . 25
. . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . 27
4.2.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . 31
4.2.3 Diagrammes de sØquences dØtaillØs
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Conception dØtaillØe
5 ImplØmentation
39
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 Environnement matØriel
5.2 Environnement logiciel
. . . . . . . . . . . . . . . . . . . . . . . . . 40
. . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Technologies utilisØs
5.3.1 API Open HR . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Les web services . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.3
JavaScript Object Notation . . . . . . . . . . . . . . . . . . 48
Interfaces Homme-Machine . . . . . . . . . . . . . . . . . . . . . . . 50
Advertisement
5.4
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Conclusion gØnØrale
60
II
Liste des (cid:28)gures
1.1 Les itØrations selon la mØthode SCRUM [4] . . . . . . . . . . . . . .
1.2 MØthodologie de conception adoptØe
6
. . . . . . . . . . . . . . . . . 10
2.1 Principe gØnØral de l’application . . . . . . . . . . . . . . . . . . . . 14
3.1 Acteur principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Diagramme des cas d’utilisation de l’application (cid:19) Simulation bud-
gØtaire (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Diagramme dØtaillØ du cas d’utilisation (cid:19) Visualiser la projection
des valeurs (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Diagramme dØtaillØ du cas d’utilisation (cid:19) Consulter l’historique de
simulation (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Diagramme dØtaillØ du cas d’utilisation (cid:19) Se connecter (cid:224) la base de
donnØes de Sopra HR (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Diagramme dØtaillØ du cas d’utilisation (cid:19) Simuler embauche (cid:20) . . . 22
3.7 Diagramme dØtaillØ du cas d’utilisation (cid:19) Simuler terminaison (cid:20) . . 23
4.1 Architecture logique de l’aplication : 3-tiers . . . . . . . . . . . . . . 26
4.2 Diagramme de paquetages . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Diagramme de sØquence (cid:19) Se connecter (cid:224) la base de donnØes de
Sopra HR (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Diagramme de sØquence (cid:19) Visualiser la projection des valeurs d’em-
bauche (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Diagramme de sØquence (cid:19) Visualiser la projection des valeurs de
terminaison (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7 Diagramme de sØquence (cid:19) Simuler terminaison (cid:20) . . . . . . . . . . . 35
4.8 Diagramme de sØquence (cid:19) Simuler embauche (cid:20) . . . . . . . . . . . . 36
4.9 Diagramme de sØquence (cid:19) Consulter le tableau de bords du budget
salarial (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.10 Diagramme de sØquence (cid:19) Consulter historique de simulation (cid:20) . . . 38
III
LISTE DES FIGURES
Sopra HR
5.1 Architecture de Sopra HR . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 SchØma global des liens inter-objets . . . . . . . . . . . . . . . . . . 43
5.3 Relation entre le dictionnaire et la session . . . . . . . . . . . . . . 44
5.4 Structure du dictionnaire
. . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Correspondance de la structure du dictionnaire et la base de donnØes
relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Structure de la session virtuelle . . . . . . . . . . . . . . . . . . . . 47
Interface d’authenti(cid:28)cation . . . . . . . . . . . . . . . . . . . . . . . 50
5.7
Interface du choix de la simulation . . . . . . . . . . . . . . . . . . 51
5.8
5.9
Interface du choix des dØpartements . . . . . . . . . . . . . . . . . . 52
5.10 Interface de saisie des paramŁtres de l’embauche . . . . . . . . . . . 53
5.11 Interface de la liste des recrues . . . . . . . . . . . . . . . . . . . . . 53
5.12 Interface de la simulation budgØtaire de l’embauche . . . . . . . . . 54
5.13 Interface de la liste des employØs pour la terminaison . . . . . . . . 55
5.14 Interface des employØs sortant en retraite . . . . . . . . . . . . . . . 56
5.15 Interface de saisie des paramŁtres de terminaison . . . . . . . . . . 57
5.16 Interface de la simulation budgØtaire de la terminaison . . . . . . . 58
5.17 Interface de la projection des valeurs du budget salarial . . . . . . . 59
IV
Liste des tableaux
3.1 Description textuelle du cas d’utilisation (cid:19) Visualiser la projection
des valeurs (cid:20)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Description textuelle du cas d’utilisation (cid:19) Consulter l’historique de
simulation (cid:20)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Description textuelle du cas d’utilisation (cid:19) Se connecter (cid:224) la base
de Sopra HR (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Description textuelle du cas d’utilisation (cid:19) Simuler embauche (cid:20)
. . 22
3.5 Description textuelle du cas d’utilisation (cid:19) Simuler terminaison (cid:20) . 23
5.1 Con(cid:28)guration matØrielle . . . . . . . . . . . . . . . . . . . . . . . . 39
. . . . . . . . . . . 48
5.2 Services web Øtendus VS services web REST [7]
V
Introduction gØnØrale
Le domaine de gestion des ressources humaines est per(cid:231)u comme une nou-
velle discipline par rapport aux autres sciences. Il s’est accentuØ notamment (cid:224)
l’issue de la rØvolution industrielle, en raison de la genŁse des jeunes entreprises
qui avaient des besoins accrus de gestion de leurs ressources sociaux et humaines et
rØcemment (cid:224) cause de l’accroissement de la lØgislation du travail, le dØveloppement
de l’informatique, l’internationalisation, la responsabilitØ sociale de l’entreprise, la
globalisation, etc... )
Depuis cet essor, la fonction de la GRH ou de gestion de ressources humaines,
n’a cessØ d’Øvoluer pour devenir en(cid:28)n une grande fonction de l’entreprise (cid:224) l’instar
de la production, de la (cid:28)nance et du marketing.
La GRH s’est avØrØe un levier clØ pour le succŁs de la fonction organisationnelle
et opØrationnelle au sein d’une entreprise pour pouvoir administrer, mobiliser,
maximiser l’utilisation des ressources humaines impliquØes dans l’activitØ d’une
organisation, et faire accro(cid:238)tre la productivitØ de l’entreprise.
Suite (cid:224) l’accØlØration technologique et (cid:224) la globalisation que l’Øconomie a vØcu
ces derniŁres annØes, des altØrations fondamentales de l’environnement (cid:224) marquer
l’existence de l’Øconomie tunisien. L’entreprise tunisienne est ainsi confrontØe (cid:224) une
concurrence de plus en plus serrØe dans le cadre de la globalisation de l’Øconomie.
Parmi les solutions envisagØes, les mØthodes de gestion et la place de choix
donnØ (cid:224) la ressource humaines dans leurs rØussites ont (cid:28)ni par considØrer le facteur
humain comme une ressource fondamentale, en mettant en place un systŁme de
gestion des ressources humaines, qui a considØrablement ØvoluØ derniŁrement.
Avec l’essor technologique que vit le monde ces derniŁres annØes, toute or-
ganisation ne peut acquØrir un niveau de compØtitivitØ ØlevØ qu’en investissant
judicieusement dans le crØneau le plus rentable : La Ressource Humaine
1
INTRODUCTION G(cid:201)N(cid:201)RALE
Sopra HR
C’est dans ce cadre que s’inscrit notre application de (cid:28)n d’Øtude intitulØ (cid:19)
Simulation BudgØtaire (cid:20) dont l’objectif est de concevoir une application web dans
le secteur de Ressource Humaine dØdiØe au client de Sopra HR, lui permettant la
prØvision de l’in(cid:29)uence de recrutement ou de terminaison sur le budget salarial et
interprØtant les rØsultats par des graphes.
Pour ce faire nous procØdons par une Øtude thØorique a(cid:28)n de mieux cerner le
contexte de notre travail. Cette Øtude fait partie des objectifs de notre rapport qui
est subdivisØ en cinq chapitres :
Le premier chapitre est consacrØ (cid:224) la mise en relief du cadre de dØveloppement
de notre application.
Dans le second chapitre nous e(cid:27)ectuons une Øtude de l’existant a(cid:28)n d’Øtudier
d’une maniŁre critique de la solution existante traitant la problØmatique de notre
projet.
Dans le chapitre suivant, baptisØ l’analyse et la spØci(cid:28)cation des besoins, nous
identi(cid:28)ons les besoins fonctionnels auxquels doit rØpondre notre application, en les
modØlisant (cid:224) travers les diagrammes de cas d’utilisation.
Advertisement
Quant au quatriŁme chapitre, il porte une dØmonstration de la conception
adoptØe pour rØpondre aux besoins prØcØdemment citØs.
Finalement, au cinquiŁme chapitre nous (cid:28)nissons par faire illustrer les dØtails
de la rØalisation de notre travail
2
Chapitre 1
PrØsentation gØnØrale
Introduction
Nous commen(cid:231)ons dans ce premier chapitre par une mise en contexte de notre
projet, en spØci(cid:28)ant le cadre de son Ølaboration ainsi que la mØthodologie suivie
pour rØaliser ce travail.
1.1 PrØsentation de l’organisme d’accueil
Nous prØsentons dans cette partie l’entreprise d’accueil en prØcisant son
propriØtaire ainsi que ses di(cid:27)Ørents secteurs d’activitØ.
1.1.1 SOPRA Group
Sopra group, acteur majeur du conseil, des services technologiques et de
l’Ødition de logiciels en Europe, accompagne ses clients dans la rØussite de la trans-
formation de leurs mØtiers et systŁmes d’informations. CrØØ en Janvier 1968 par
Pierre Pasquier, Fran(cid:231)ois Odin et LØo Gantelet, (cid:28)gure parmi les plus anciennes
Entreprises de Services du NumØrique (ESN) en Europe. La sociØtØ s’est, dŁs l’ori-
gine, positionnØe sur l’ensemble des mØtiers des services informatiques (cid:224) valeur
ajoutØe et innovation dans les solutions apportØes, qualitØ industrielle et perfor-
mance des services dØlivrØs, Sopra Group est le partenaire de rØfØrence des grandes
entreprises et organisations qui recherchent le meilleur usage du numØrique pour
assurer leur dØveloppement et leur compØtitivitØ.
(cid:192) (cid:28)n Juin 2013, le Groupe compte plus de 16 000 collaborateurs. Il a rØalisØ un
chi(cid:27)re d’a(cid:27)aires en 2012 de 1,217 milliard d’euros. Sopra Group (SOP) est cotØ sur
3
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
NYSE Euronext Paris. La sociØtØ a Øgalement dØveloppØ un savoir-faire dans le
mØtier de l’Ødition de logiciels et crØØ deux sociØtØs spØcialisØes : Axway Software
(cotØe en bourse en 2011) et Sopra Banking Software.
Cependant, elle est spØcialisØe dans le dØveloppement des demandes clients de
conception de produits personnalisØs en relation avec diverses sphŁres du guide de
l’Øconomie et de l’Internet pour une gamme d’industries incluant : le textile, l’h(cid:244)-
tellerie, l’Øducation (cid:224) distance et la fourniture des systŁmes ERP. Cette approche
dans exigence particuliŁre de la part du client.
Le 4 avril 2013, HR ACCESS est devenu la propriØtØ de Sopra.[1]
1.1.2 Sopra HR
Sopra HR Software, (cid:28)liale de Sopra Steria, o(cid:27)re des solutions RH complŁtes,
parfaitement adaptØes aux besoins des Directions des Ressources Humaines et aux
organisations de moyennes et grandes tailles.
Ses solutions, PlØiades et HR Access, rØpondent aux enjeux des entreprises
publiques comme privØes, dans tous les secteurs d’activitØ et couvrent les sujets de
Gestion Administrative et Paie, Gestion des Temps et des ActivitØs, Gestion des
Talents, Core HR International, Pilotage et Performance, Espaces Collaboratifs...
Elles sont proposØes en mode on-premise ou services d’outsourcing et tiennent
compte des nouveaux usages, notamment mobiles.
Sopra HR est prØsent dans 10 pays - Allemagne, Belgique, Espagne, France, Ita-
lie, Luxembourg, Maroc, Suisse, Royaume Uni et Tunisie - et fournit ses solutions
(cid:224) plus de 850 clients qui les dØploient dans plus de 54 pays.
Pour rØpondre aux nouveaux enjeux de ses clients, Sopra HR investit fortement
en Recherche et DØveloppement, renforce constamment son expertise sur les nou-
velles tendances : l’impact du numØrique sur la fonction RH, l’engagement social
et sociØtal au coeur des solutions RH.
Sopra HR privilØgie l’Øcoute de ses clients dans la volontØ d’apporter le meilleur
niveau de service et de conseil. Les clubs utilisateurs dØj(cid:224) prØsents dans les dif-
fØrentes gØographies, participent activement Øgalement (cid:224) ces programmes de rØ-
(cid:29)exion.[2]
4
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
1.2 Cadre gØnØral
1.2.1 ProblØmatique
La sociØtØ Sopra HR dØpense beaucoup d’argent dans le domaine de recherche
et d’analyse informatique dØcisionnelle a(cid:28)n d’aborder une meilleure entreprise d’oø
le choix de la mise en place d’une application de simulation budgØtaire c(cid:244)tØ res-
sources humaines qui d’aprŁs un tableau de bord contenant plusieurs indicateurs
qui rØsultent des graphes superposant l’estimØ (cid:224) l’actuel, aide (cid:224) bien prendre des
dØcisions concernant l’embauche et le licenciement des employØs selon l’in(cid:29)uence
sur le budget.
1.2.2 Objectif du projet
L’objectif principal de ce projet consiste (cid:224) concevoir et dØvelopper une appli-
cation web en JEE pour simuler les variations budgØtaires salariales qui a comme
but de remØdier aux problŁmes dØj(cid:224) notØs et de rØpondre aux besoins fonctionnels
du client de SOPRA HR. Permettant de prØvoir l’in(cid:29)uence de l’embauche ou de
la terminaison sur le budget salarial.
1.3 Choix mØthodologique
La qualitØ d’un logiciel informatique est le plus important facteur dans le dØ-
veloppement logiciel, les mØthodes agiles donnent une grande envergure (cid:224) cet as-
pect. L’objectif principal des mØthodes agiles donc est de guider les dØcisions et la
conduite d’un projet informatique.
Plusieurs mØthodes agiles ont vu le jour derniŁrement, parmi les plus connu
on cite : Scrum, EXtreme Programming (XP), Rational Uni(cid:28)ed Process (RUP),
Feature Driven Development (FDD), etc.
La mØthode adoptØe dans la conduite de notre projet est la mØthode SCRUM
pour plusieurs raisons que nous allons citer dans les prochaines parties.
1.3.1 La mØthode de gestion du projet : SCRUM
SCRUM est la mØthode agile la plus connue et utilisØe dans la gestion des
projets informatiques. Sa mise en place Øtait pour pallier aux problŁmes du non
satisfaction de client ou pire pour les problŁmes de retard de livraison ou de dØ-
passement du budget.
5
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
SCRUM donc est une mØthode e(cid:30)cace pour guider un projet jusqu’(cid:224) arriver (cid:224)
son terme. Elle se caractØrise par dØcortiquer le projet en morceaux qui sont des
itØrations appelØs (cid:19) Sprints (cid:20) de courte durØe de un mois maximum.
SCRUM s’appuie sur un formalisme rØduit :
• R(cid:244)les : Product owner, Scrum master et une Øquipe
• Timeboxes : Plani(cid:28)cation de release, plani(cid:28)cation de sprint, scrum quotidien,
revue de sprint et introspection
• ArtØfacts : Backlog du produit, plan de produit, plan du sprint, burdown/burnup
de release, burndown/burnup de sprint [3]
Par rapport (cid:224) des autres approches, SCRUM s’avŁre lØger, facile (cid:224) ma(cid:238)triser et
(cid:224) apprendre mais Øgalement ExtrŒmement di(cid:30)cile (cid:224) entreprendre.
Toute au long de notre projet on a essayØ d’Œtre (cid:28)dŁle et conforme aux plupart
des ØvŁnements et de timeboxes prØsents dans cette mØthode pour s’approcher au
plus (cid:224) satisfaire les besoins de notre client et respecter les dØlais de livraison.(Figure
1.1)
Figure 1.1 (cid:21) Les itØrations selon la mØthode SCRUM [4]
1.3.2 Cycle de vie d’un logiciel
Le cycle de vie d’un logiciel vise (cid:224) diviser le dØveloppement d’un logiciel en plu-
sieurs parties pour suivre l’avancement du dØveloppement logiciel de sa conception
6
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
jusqu’(cid:224) sa disparition. L’objectif d’un tel dØcoupage est de pouvoir dØtecter les er-
reurs au (cid:28)l de dØveloppement et de vØri(cid:28)er constamment la conformitØ du logiciel
avec son cahier de charge ainsi que son adØquation avec les besoins exprimØs. Le
dØcoupage entra(cid:238)ne un gain de productivitØ autant pour ces clients que pour les
fournisseurs, amØliore considØrablement la qualitØ du produit et conduit (cid:224) une
Advertisement
bonne estimation des coßts associØs.
Le cycle de vie du logiciel comprend gØnØralement au minimum les Øtapes
suivantes :
• DØ(cid:28)nitions des objectives :
Cette Øtape consiste (cid:224) dØ(cid:28)nir la (cid:28)nalitØ du projet et son inscription dans une
stratØgie globale.
• Analyse des besoins et faisabilitØ :
C’est-(cid:224)-dire l’expression, le recueil et la formalisation des besoins du deman-
deur (le client) et l’ensemble des contraintes, puis l’estimation de la faisabilitØ
de ces besoins.
• SpØci(cid:28)cation ou conception gØnØrale :
Il s’agit de l’Ølaboration de spØci(cid:28)cation de l’architecture gØnØrale du logiciel.
• Conception dØtaillØe :
Cette Øtape consiste (cid:224) dØ(cid:28)nir prØcisØment chaque sous-ensemble du logiciel.
• Codage (implØmentation ou programmation) :
C’est la traduction dans un langage de programmation des fonctionnalitØs
dØ(cid:28)nis lors des phases de conception.
• Test unitaires :
Ils permettent de vØri(cid:28)er individuellement que chaque sous-ensemble du lo-
giciel est implØmentØ conformØment aux spØci(cid:28)cations.
• IntØgration :
L’objectif est de s’assurer de l’interfa(cid:231)age des di(cid:27)Ørents ØlØments (modules)
du logiciel. Elle fait l’objet de tests et intØgration consignØs dans un docu-
ment.
• Quali(cid:28)cation (ou recette) :
C’est-(cid:224)-dire la vØri(cid:28)cation de la conformitØ du logiciel aux spØci(cid:28)cations ini-
tiales.
• Documentation :
Elle vise (cid:224) produire les informations nØcessaires pour l’utilisation du logiciel
et pour des dØveloppements ultØrieurs.
• Mise en production :
C’est le dØploiement sur site du logiciel.
• Maintenance :
Elle comprend toutes les actions correctives (maintenance corrective) et Øvo-
7
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
lutives (maintenance Øvolutive) sur le logiciel.
La sØquence et la prØsence de chacune de ces activitØs dans le cycle de vie
dØpend du choix d’un modŁle de cycle de vie entre le client et l’Øquipe de dØ-
veloppement. Le cycle de vie permet de prendre en compte, en plus des aspects
techniques, l’organisation et les aspects humains.
Ils existent plusieurs modŁles de cycles de vie d’un logiciel tels que : ModŁle en
cascade, en V, en spiral, par incrØment etc...
1.4 MØthodologies de conception
1.4.1 MERISE
MERISE (MØthode d’(cid:201)tude et de RØalisation Informatique pour les systŁmes
d’entreprises) est une mØthode d’analyse et de rØalisation des systŁmes d’informa-
tion qui est ØlaborØe en plusieurs Øtapes : schØma directeur, Øtude prØalable, Øtude
dØtaillØe et la rØalisation. Elle est aussi une mØthode de conception, de modØlisation
et d’analyse des projets informatiques a(cid:28)n de concevoir un systŁme d’information
organisationnel pour en faire ressortir les points auxquels on s’intØresse.
Merise s’intØresse plus vers la comprØhension et la formalisation des besoins
des mØtiers que vers la rØalisation de logiciel. Il est plus proche de l’ingØnierie du
SI mØtier que du gØnie logiciel. Merise est idØal pour :
• La modØlisation des donnØes en vue de la construction d ?une base de donnØes
relationnelle.
• La modØlisation des processus mØtiers d’un SI automatisØ en partie par du
logiciel.
• Le formalisme des besoins utilisateur dans le cadre de cahier des charges
utilisateur, en vue de la conception d’un logiciel adaptØ.
1.4.2 UML
UML (Langage de ModØlisation Uni(cid:28)Ø) est un langage pour la modØlisation
des projets informatiques basØ sur la notion d’orientØ objet.
L’idØe est d’utiliser des diagrammes de modØlisation a(cid:28)n de donner une re-
prØsentation abstraite des objets rØels ou bien virtuelles, en mettant en relief,
l’interaction et le comportement des di(cid:27)Ørents composants du systŁme.
8
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
L’UML forme un grand atout pour le langage orientØ objet ce qui a permis de
s’imposer en tant que mØthode de dØveloppement d’objet et d’Œtre reconnu par
plusieurs entreprises.
UML est convenable pour :
• Concevoir et dØployer une architecture logiciel dØveloppØe dans un langage
objet (Java, C++, VB.net)
• ModØliser les donnØes (le modŁle de classe rØduit sans mØthodes et stØrØotypØ
en entitØs)
• ModØliser le fonctionnement mØtier (le diagramme d’activitØ et de cas d’uti-
lisation) qui sont des formalismes trŁs anciens
1.4.3 La dØmarche adoptØe
Nous allons adopter UML comme langage de modØlisation puisque nous allons
utiliser le concept de l’orientØ objet, (cid:224) travers la technologie JAVA en plus d’autres
langages de balisage et de style, pour dØvelopper l’application (cid:19) Estimation bud-
gØtaire (cid:20). Ainsi, la mØthodologie de conception adoptØe se base sur le choix des
digrammes UML adØquats.
9
CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE
Sopra HR
Nous avons utilisØ six diagrammes de cas d’utilisation, leurs diagrammes de
sØquence et d’et un diagramme de classes gØnØral. Le schØma suivant reprØsente
notre mØthodologie de conception.(Figure 1.2)
Figure 1.2 (cid:21) MØthodologie de conception adoptØe
Notre outil de conception UML est le logiciel (cid:19) Draw.io (cid:20).
C’est un outil d’Ødition de diagrammes UML que nous avons utilisØ pour la crØation
des diagrammes de cas d’utilisation, du digramme de classes de l’application et des
diagrammes de sØquence. Il est distinguØ par ses interfaces pratiques et faciles (cid:224)
manipulØ, sa capabilitØ d’endurer UML2 et aussi il est gratuit.
Conclusion
Ce chapitre constitue une partie introductive de notre projet. En premier lieu,
une prØsentation du cadre gØnØral a ØtØ Øtablie, en Øvoquant notamment notre
objectif ainsi que les di(cid:27)Ørentes Øtapes et rami(cid:28)cations. La problØmatique a permis
Øgalement de mettre en relief les raisons qui ont contribuØes (cid:224) la naissance de notre
projet, ainsi que les di(cid:27)Ørentes caractØristiques de la nouvelle solution. En deuxiŁme
lieu, nous avons dØcrit notre choix mØthodologiques et technologique. En(cid:28)n, nous
avons prØsentØ la dØmarche adoptØe de notre application.
10
Chapitre 2
(cid:201)tude prØalable
Introduction
La rØalisation de tout projet se base sur une Øtape principale qui est l’Øtude de
l’existant. Cette Øtude nous permet de mieux comprendre les besoins de l’entreprise
et dØterminer les problØmatiques actuelles que notre application doit faire face a(cid:28)n
de proposer la solution adØquate, et de s’orienter vers les technologies possibles pour
la rØalisation de nos objectifs. Il faut donc pour bien cerner le problŁme, analyser
en dØtails l’existant. Dans le prØsent chapitre, nous allons repØrer les principales
caractØristiques de l’existant que nous venons d’introduire dans le chapitre prØcØ-
dent. Nous prØsentons alors une analyse des applications existantes dans le but de
dØgager leurs limites et de justi(cid:28)er le dØveloppement du futur systŁme.
2.1 Analyse de l’existant
2.1.1 (cid:201)tat des lieux
Les Direction des Ressources Humaines, aujourd’hui doivent rØpondre (cid:224) des
enjeux humains, organisationnels et (cid:28)nanciers. Sur le plan (cid:28)nancier, le coßt de la
Advertisement
masse salariale reprØsente parfois plus de la moitiØ des charges de fonctionnement
d’une sociØtØ. Il est dont extrŒmement important pour elles de mettre en place une
gestion de la rØmunØration et une analyse de la masse salariale.
Simulation de la masse salariale :
Le budget de masse salariale est une prØvision basØe sur des ØlØments projetØs
et des hypothŁses simulØes.
11
CHAPITRE 2. (cid:201)TUDE PR(cid:201)ALABLE
Sopra HR
La projection consiste (cid:224) reconduire les donnØes du passØ et (cid:224) rØaliser le suivi sur les
mŒmes bases par extrapolation : (cid:19) que va donner l’Øvolution de la masse salariale,
toutes choses Øgales par ailleurs ? (cid:20)
La simulation, consiste (cid:224) tester des hypothŁses et voir les incidences, les impacts
sur la masse salariale.
En e(cid:27)et, il est important de prendre en compte, pour gØrer e(cid:30)cacement la
masse salariale, des particularitØs individuelles et de leurs Øvolutions (anciennetØ,
primes, reclassements,..) et de proroger leurs situations dans le temps ; c’est-(cid:224)-dire
utiliser le principe de gestion ØvŁnementielle de la donnØe. Ce qui permettra des
projections et simulations prØcises, facilitØes et partagØes pour des analyses et donc
des prises de dØcision (cid:28)ables et rapides.
2.1.2 Solution existante
Beaucoup d’entreprises utilisent encore la moyenne des couts standards (moyennes
de rØmunØrations) : "Globalement juste et prØcisØment faux" ou bien "rejouent"
la paie : processus trŁs lourd et peu (cid:28)able. Les solutions majoritairement utilisØes
sont trop souvent :
• Excel avec tous les inconvØnients engendrØs (solution chronophage, source
d’erreurs, pas adaptØe (cid:224) une grande volumØtrie,..).
• Quelques modules de simulation RH proposØs par certains Øditeurs de SIRH
(ils (cid:19) rejouent (cid:20) la paie et ne permettent pas un rØel pilotage de la MS).
• Des solutions de Business Intelligence gØnØralistes sur lesquelles sont faits
des dØveloppements spØci(cid:28)ques longs (ces solutions ne gŁrent pas la datation
des ØvŁnements individuels et ne sont pas adaptØs pour piloter la complexitØ
de la MS)
2.1.3 Critique de l’existant
TrŁs souvent, les projections et simulations sont di(cid:30)ciles et peu (cid:28)ables car :
• Beaucoup de ressaisies d’informations.
• De multiples contributeurs avec des hypothŁses non centralisØes.
• Di(cid:30)cultØs (cid:224) proroger la situation individuelle (prise en compte des particu-
laritØs individuelles), ?
12
CHAPITRE 2. (cid:201)TUDE PR(cid:201)ALABLE
Sopra HR
2.2 Solution proposØe
En termes de l’analyse approfondie de l’existant, plusieurs limites de logiciel
d’estimation budgØtaire prØsent sur scŁne ont surgi. Ce dernier prØsente des limites
fonctionnelles et opØrationnelles qui ont un impact nØgatif sur sa performance, sa
maintenabilitØ ainsi que sa (cid:28)abilitØ. Dans le souci d’apporter une valeur ajou-
tØe et un meilleur fonctionnement aux utilisateurs de l’application ØchØante, nous
proposons une solution complŁte qui rØpond aux besoins suivants :
• La facilitØ d’utilisation : Notre solution actuelle consiste (cid:224) Œtre facile (cid:224) ma-
nipuler, (cid:224) comprendre, (cid:224) apprendre et (cid:224) Œtre exploitØe. Une utilisation incor-
recte ne doit pas entra(cid:238)ner un dysfonctionnement.
• La (cid:28)abilitØ : Notre logiciel doit rendre des rØsultats corrects quelles que
soient les conditions de son exploitation. Nous sommes amenØs (cid:224) diminuer
et (cid:224) minimiser au maximum la tolØrance pannes.
• La performance : Le rapport entre la quantitØ de ressources utilisØes (moyens
matØriels, temps personnel), et la quantitØ de rØsultats dØlivrØs doit Œtre rai-
sonnable, mŒme en cas d’utilisation intensive. Pour remØdier aux problŁmes
de l’existant, la nouvelle solution consiste (cid:224) Œtre plus adaptØe au produit
Sopra HR c’est-(cid:224)-dire ne nØcessite pas une intØgration.
• La maintenabilitØ et la portabilitØ : Notre solution doit Œtre nØcessairement
capable de s’adapter aux nouveaux changements avec le moindre cout et
e(cid:27)ort. En outre, l’extensibilitØ de notre solution et son aptitude (cid:224) ajouter
des nouvelles fonctions, est une qualitØ majeure (cid:224) laquelle nous devons faire
attention en cours de la conception.
• Interface ergonomique : L’application doit Œtre menØe d’une interface qui
rØpond aux critŁres d’ergonomie des interfaces. Notre interface interactive
doit Œtre facile (cid:224) utiliser et (cid:224) apprendre, adØquat aux caractØristiques phy-
siologiques, perceptives et cognitives des utilisateurs. L’interface doit Œtre
intuitive, signi(cid:28)cative et utilisable, en n’oubliant pas de le prØsenter de ma-
niŁre agrØable de fa(cid:231)on (cid:224) soutenir la motivation de l’utilisateur.
13
CHAPITRE 2. (cid:201)TUDE PR(cid:201)ALABLE
Sopra HR
La (cid:28)gure suivante (Figure 2.1) reprØsente le principe gØnØrale de notre appli-
cation.
Figure 2.1 (cid:21) Principe gØnØral de l’application
1. Chargement des donnØes (cid:224) partir de la base de donnØes de Sopra HR
2. Extraction des donnØes chargØes (cid:224) l’aide de l’API OpenHR
3. Traitement des donnØes extraites
4. A(cid:30)chage des interprØtations demandØes
Conclusion
Tout au long de ce chapitre, nous avons expliquØ la notion de la simulation
budgØtaire dans le domaine des ressources humaines. Dans une autre partie, nous
avons menØ une Øtude concise sur l’existant, ses caractØristiques et ses dØfaillances.
AprŁs l’Øtude de l’existant, la seconde partie de ce chapitre a ØtØ consacrØe (cid:224) la
prØsentation de la solution adoptØe qui va satisfaire nos besoins tout en respectant
les contraintes a(cid:28)n d’aboutir (cid:224) une solution pertinente de notre problØmatique.
14
Chapitre 3
Analyse et spØci(cid:28)cation des besoins
Introduction
Le prØsent chapitre nous permet d’identi(cid:28)er les fonctionnalitØs de notre futur
systŁme pour chaque type d’utilisateur, et ceci en recensant les besoins fonctionnels
et d’apprØhender la liste des exigences traduites par les besoins non fonctionnels.
Ceci se fera par l’identi(cid:28)cation des acteurs et la dØ(cid:28)nition de tous les besoins qui
seront modØlisØs par le diagramme de cas d’utilisation gØnØrale.
3.1
Identi(cid:28)cation des acteurs
Nous avons identi(cid:28)Ø un seul type d’utilisateur.(Figure 3.1)
• Directeur des ressources humaines
Figure 3.1 (cid:21) Acteur principal
15
CHAPITRE 3. ANALYSE ET SP(cid:201)CIFICATION DES BESOINS
Sopra HR
3.2 Analyse des besoins
3.2.1 Les besoins fonctionnels
Le futur systŁme doit permettre (cid:224) l’utilisateur (cid:19) Directeur Ressources Hu-
maines (cid:20) de :
1. Se connecter (cid:224) la base de Sopra HR
2. S’authenti(cid:28)er
3. Visualiser la projection des valeurs
4. Consulter l’historique de simulation
5. Choisir une option de simulation
(a) Simuler embauche
(b) Simuler terminaison
6. Con(cid:28)gurer les paramŁtres de simulation
3.2.2 Les besoins non fonctionnels
Les besoins non fonctionnels reprØsentent les contraintes et les exigences impli-
cites auxquels les systŁme doit rØpondre. Parmi ces besoins on cite :
• Con(cid:28)dentialitØ et sØcuritØ
Les donnØes traitØes par le directeur ressources humaines sont soumises (cid:224) des
chartes de con(cid:28)dentialitØ et conditio...