Conception et développement d’un outil de gestion des temps

Page 1 sur 89Lecteur de document UniversityLib

Conception et développement d’un outil de gestion des temps

Software Development and Project Management · textbook

Voir tous les documents en gestion et économie

Conception et dØveloppement d’un outil de

gestion des temps

Ghada BeCheikh

2 juillet 2015

DØdicaces

A la mØmoire de mes grands parents...

A mes chers parents Fadoua et Samir...

A mon cher frŁre Khalil...

A mon oncle Khaled...

A mon cher Seif...

A Am Amor et Tata Salwa...

A mes tantes et mes oncles...

A mes cousins et cousines...

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 dnnØ le courage et la force pour rØaliser ce

travail.

Je tiens (cid:224) remercier mon encadrant (cid:224) ESPRIT, Madame Syrine Karoui, pour

son aide prØcieux, sa qualitØ d’encadrement et le savoir qu’elle m’a transmis.

Je tiens (cid:224) exprimer ma profonde reconnaissance (cid:224) l’Øgard de mon tuteur (cid:224) la

sociØtØ Sopra HR, Monsieur Walid Baklouti (cid:224) qui je prote une grande estime

pour tous les prØcieux conseils qu’il ma prodiguØ.

Mes remerciements et ma reconnaissance s’Øtendent Øgalement (cid:224) toute la famille

Sopra HR pour leur chaleureux accueil et particuliŁrement Monsieur Mohamed

Amine Issaoui, de m’avoir accordØ ce stage et accueilli au sein du groupe ISV.

Je ne manquerais pas l’occasion de remercier tous mes enseignants (cid:224) ESPRIT et

tous les membres de l’Øquipe ISV citera notamment Monsieur Bassem Akrouti.

II

Table des matiŁres

Introduction gØnØrale

1 PrØsentation gØnØrale

1.1.1

1.1.2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

1.1 PrØsentation de l’organisme d’accueil

SOPRA Group . . . . . . . . . . . . . . . . . . . . . . . . .

Sopra HR . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1 ProblØmatique . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2 Objectifs et motivations du projet . . . . . . . . . . . . . . .

1.3 Solution proposØe . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Cadre gØnØral

1

3

3

3

3

4

5

5

5

5

6

2 Gestion du projet

7

7

7

7

8

8

8

9

. . . . . . . . . . . . . . . . . . . . 10

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Choix mØthodologique . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 MØthode agile . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 Les principes agiles . . . . . . . . . . . . . . . . . . . . . . .

2.2 MØthode choisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

2.2.2 Les Øtapes de SCRUM . . . . . . . . . . . . . . . . . . . . .

2.2.3 Plani(cid:28)cation des sprints

3 SPRINT 0 : SpØci(cid:28)cation et analyse globale

12

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 (cid:201)tude prØalable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Gestion des temps et des activitØs . . . . . . . . . . . . . . . 13

3.1.2

SystŁme de pointage . . . . . . . . . . . . . . . . . . . . . . 14

3.1.3 Temps rØel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 SpØci(cid:28)cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

III

TABLE DES MATI¨RES

3.2.1

3.2.2

3.2.3

Identi(cid:28)cation des acteurs . . . . . . . . . . . . . . . . . . . . 15

Identi(cid:28)cation des besoins fonctionnels . . . . . . . . . . . . . 15

. . . . . . . . . . 16

Identi(cid:28)cation des besoins non fonctionnels

3.3 (cid:201)tat de l’art des technologies utilisØes . . . . . . . . . . . . . . . . . 17

3.3.1 API Open HR . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2 Les web services . . . . . . . . . . . . . . . . . . . . . . . . . 24

JavaScript Object Notation . . . . . . . . . . . . . . . . . . 25

3.3.3

3.4 Diagramme des cas d’utilisation gØnØral . . . . . . . . . . . . . . . . 26

3.5 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . 30

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 SPRINT 1 :Interfa(cid:231)age entre le terminal de pointage et la base

de donnØes et authenti(cid:28)cation des di(cid:27)Ørents acteurs

32

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Analyse du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Conception du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.1 Diagrammes de sØquences du sprint 1 . . . . . . . . . . . . . 36

4.3.2 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . 38

4.4 RØalisation du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 40

Interface d’authenti(cid:28)cation de l’expert

. . . . . . . . . . . . 40

Interface d’accueil de l’employØ . . . . . . . . . . . . . . . . 42

4.5 Tests et validation du sprint 1 . . . . . . . . . . . . . . . . . . . . . 42

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1

4.4.2

5 SPRINT 2 : Contr(cid:244)le d’accŁs et demande de congØ

43

Publicité

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Analyse du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1 Diagramme des cas d’utilisation (cid:19) (cid:201)laborer les tableaux de

bords de pointage (cid:20) . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.2 Diagramme des cas d’utilisation (cid:19) (cid:201)laborer les tableaux de

bords de pointage (cid:20) . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3 Diagramme des cas d’utilisation (cid:19) Demander un congØ (cid:20) . . 46

5.2 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Conception du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.1 Diagrammes de sØquences du sprint 2 . . . . . . . . . . . . . 52

5.3.2 Diagramme de classes du sprint 2 . . . . . . . . . . . . . . . 56

5.4 RØalisation du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . 58

Interface des statistiques . . . . . . . . . . . . . . . . . . . . 58

Interface de consultation du tableau de pointage . . . . . . . 58

5.4.1

5.4.2

IV

TABLE DES MATI¨RES

5.4.3

5.4.4

5.4.5

Interface de consultation du tableau des absences

. . . . . . 59

Interface de consultation du planning des absences . . . . . . 60

Interfaces graphiques de demande du congØ . . . . . . . . . . 61

5.5 Tests et validation du sprint 2 . . . . . . . . . . . . . . . . . . . . . 62

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 SPRINT 3 : Traitement des congØs et gØnØration d’un rapport

63

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.1 Analyse du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.1.1 Diagramme des cas d’utilisation (cid:19) Traiter les demandes de

congØs (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.1.2 Diagramme des cas d’utilisation (cid:19) GØnØrer un rapport (cid:20) . . 65

6.1.3 Diagramme des cas d’utilisation (cid:19) Consulter pro(cid:28)ls employØs (cid:20)

66

6.2 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3 Conception du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.3.1 Diagrammes de sØquences du sprint 3 . . . . . . . . . . . . . 69

6.4 Diagramme de classes du sprint 3 . . . . . . . . . . . . . . . . . . . 71

6.5 RØalisation du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . 73

Interface de traitement des congØs . . . . . . . . . . . . . . . 73

Interfaces de gØnØration d’un rapport . . . . . . . . . . . . . 73

Interfaces de consultation des pro(cid:28)ls employØs . . . . . . . . 75

6.6 Tests et validation du sprint 3 . . . . . . . . . . . . . . . . . . . . . 76

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.5.1

6.5.2

6.5.3

Conclusion gØnØrale

77

V

Liste des (cid:28)gures

2.1 Processus de SCRUM [5] . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2 Diagramme de GANTT : Plani(cid:28)cation des sprints . . . . . . . . . . 10

2.3 Diagramme de PERT . . . . . . . . . . . . . . . . . . . . . . . . . . 10

. . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Architecture Sopra HR [8]

. . . . . . . . . . . . . . . . 20

3.2 SchØma global des liens inter-objets [8]

3.3 Relation entre le dictionnaire et la session [8] . . . . . . . . . . . . . 21

3.4 Structure du dictionnaire [8]

. . . . . . . . . . . . . . . . . . . . . . 22

3.5 Correspondance de la structure du dictionnaire et la base de donnØes

relationnelle [8]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

. . . . . . . . . . . . . . . . . . 24

3.6 Structure de la session virtuelle [8]

3.7 Diagramme de cas d’utilisation gØnØral

. . . . . . . . . . . . . . . . 27

3.8 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Diagramme dØtaillØ du cas d’utilisation (cid:19) Pointer (cid:20) ?

. . . . . . . . 33

4.2 Diagramme de sØquences du cas d’utilisation (cid:19) Pointer (cid:20) . . . . . . 36

4.3 Diagramme de sØquences (cid:19) Se connecter (cid:224) la base de donnØes (cid:20) . . 37

4.4 Diagramme de classes du sprint 1 . . . . . . . . . . . . . . . . . . . 39

Interface d’authenti(cid:28)cation de l’expert RH . . . . . . . . . . . . . . 41

4.5

Interface d’accueil de l’expert RH . . . . . . . . . . . . . . . . . . . 41

4.6

. . . . . . . . . . . . . . . . . . . . 42

Interface d’accueil de l’employØ

4.7

5.1 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) (cid:201)la-

borer les tableaux de bords de pointage (cid:20) . . . . . . . . . . . . . . . 44

5.2 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) (cid:201)la-

borer les tableaux de bords des absences (cid:20) . . . . . . . . . . . . . . 45

5.3 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) De-

mander un congØ (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter les ta-

bleaux de bords du pointage (cid:20) . . . . . . . . . . . . . . . . . . . . . 52

VI

LISTE DES FIGURES

5.5 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter les ta-

bleaux de bords des absences (cid:20) . . . . . . . . . . . . . . . . . . . . 53

5.6 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter le planning

des absences (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.7 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter le planning

des absences (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.8 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter mes de-

mandes de congØ (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.9 Diagramme de classes du sprint 2 . . . . . . . . . . . . . . . . . . . 57

5.10 Interface des statistiques . . . . . . . . . . . . . . . . . . . . . . . . 58

5.11 Interface de consultation du tableau de pointage . . . . . . . . . . . 59

. . . . . . . . . . 60

5.12 Interface de consultation du tableau des absences

5.13 Interface de consultation du tableau des absences

. . . . . . . . . . 61

. . . . . . . . . . . . . . . . . . . . 62

5.14 Interface de demande du congØ

6.1 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) Trai-

ter les demandes de congØ (cid:20) . . . . . . . . . . . . . . . . . . . . . . 64

6.2 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) GØ-

nØrer un rapport (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3 Diagramme des cas d’utilisation dØtaillØ du cas d’utilisation (cid:19) Consul-

ter pro(cid:28)ls des employØs (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4 Diagramme de sØquences du cas d’utilisation (cid:19) Traiter les demandes

de congØ (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.5 Diagramme de sØquences du cas d’utilisation (cid:19) GØnØrer un rapport (cid:20) 70

6.6 Diagramme de sØquences du cas d’utilisation (cid:19) Consulter pro(cid:28)ls des

employØs (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.7 Diagramme de classes du sprint 3 . . . . . . . . . . . . . . . . . . . 72

Publicité

Interface de traitement des congØs . . . . . . . . . . . . . . . . . . . 73

6.8

6.9

. . . . . . . . . . . . . . . . . 74

Interface de gØnØration d’un rapport

6.10 Rapport gØnØrØ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.11 Interface de la liste des employØs

. . . . . . . . . . . . . . . . . . . 75

6.12 Interface du pro(cid:28)l d’un employØ . . . . . . . . . . . . . . . . . . . . 76

VII

Liste des tableaux

3.1 Le fonctionnement d’un systŁme de pointage [7]

. . . . . . . . . . . 15

3.2 Services web Øtendus VS services web REST [10] . . . . . . . . . . . 25

3.3 Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Description textuelle du cas d’utilisation (cid:19) Se connecter (cid:224) la base

de donnØes (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Backlog du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1 Description textuelle du cas d’utilisation (cid:19) Consulter les statistiques

de pointage (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Description textuelle du cas d’utilisation (cid:19) Consulter le tableau de

pointage (cid:20)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Description textuelle du cas d’utilisation (cid:19) Consulter les statistiques

des absences (cid:20)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4 Description textuelle du cas d’utilisation (cid:19) Consulter le tableau des

absences (cid:20)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

. 47

5.5 Description textuelle du cas d’utilisation (cid:19) Demander un congØ (cid:20)

5.6 Backlog du sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1 Description textuelle du cas d’utilisation (cid:19) Traiter les demandes de

congØ (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

. 65

6.2 Description textuelle du cas d’utilisation (cid:19) GØnØrer un rapport (cid:20)

6.3 Description textuelle du cas d’utilisation (cid:19) Consulter pro(cid:28)ls em-

ployØs (cid:20) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4 Backlog du sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

VIII

Introduction gØnØrale

Une entreprise est basØe essentiellement sur plusieurs ØlØments stratØgiques

tels que la gestion des opØrations, la gestion (cid:28)nanciŁre, la recherche, le dØveloppe-

ment, l’accroissement des marchØs et de la clientŁle etc ...

Parmi les aspects les plus di(cid:30)ciles (cid:224) traiter et (cid:224) mettre en oeuvre pour les

gestionnaires sont les aspects liØes (cid:224) la gestion des ressources humaines.

Malheureusement, les entreprises mettent souvent la gestion des ressources hu-

maines au second plan, et c’est (cid:224) cause du manque de temps et d’expØrience ainsi

que l’absence de soutien, d’encadrement et d’outils. Pourtant, il s’agit l(cid:224) d’un des

enjeux stratØgiques de la rØussite des entreprises ouvrant dans les technologies de

l’information. La prØoccupation d’une saine gestion des ressources humaines as-

sure non seulement un climat de travail motivant et stimulant, mais mobilise le

personnel dans l’atteinte des objectifs de l’organisation, maximise l’engagement

des employØs et assure l’adhØsion (cid:224) la mission.

Le succŁs des entreprises du secteur des technologies de l’information repose en

grande partie sur leur capacitØ (cid:224) conserver, (cid:224) optimiser et (cid:224) accro(cid:238)tre le savoir des

membres de leur personnel. Les connaissances, l’expertise et les idØes des employØs

amØliorent considØrablement la valeur de l’entreprise et sont des actifs importants

pour l’organisation. Les entreprises qui sont pleinement conscientes de la valeur

de leur personnel et qui investissent dans leur dØveloppement sont souvent celles

qui rØussissent le mieux (cid:224) augmenter leurs performances globales. Depuis quelques

annØes, la gestion en entreprise des congØs et du temps de travail se sont complexi-

(cid:28)Øes suite (cid:224) l’Øvolution du rythme de travail et (cid:224) l’environnement social et familial.

Elles ne relŁvent pas seulement de la gestion des ressources humaines, elles

mettent aussi en avant la volontØ d’ancrer une rØelle stratØgie d’entreprise sur le

long terme concernant l’optimisation des processus et la ma(cid:238)trise des coßts et de

rentabilitØ. Cette thØmatique est souvent apprØhendØe par les responsables au sein

de l’organisation car l’installation de logiciel de gestion des temps, des absences et

1

INTRODUCTION G(cid:201)N(cid:201)RALE

des congØs peut dØboucher sur certains con(cid:29)its sociaux qui seraient nØfastes.

C’est Øgalement le cas avec les systŁmes de pointage oø les salariØs ne com-

prennent pas forcØment le fonctionnement d’une pointeuse.

Dans ce cadre s’inscrit notre projet de (cid:28)n d’Øtudes intitulØ (cid:19) Gestion de temps (cid:20)

dont l’objectif est de concevoir une application web dans le secteur de ressources

humaines dØdiØ au client SOPRA HR. Cette derniŁre lui permet essentiellement

l’interfa(cid:231)age entre le terminal de pointage et la base de Sopra HR ainsi que l’Øla-

boration de di(cid:27)Ørentes statistiques et des tableaux de bords synthØtisant l’accŁs

en temps rØel et di(cid:27)ØrØ.

Le prØsent rapport est constituØ de six chapitres qui se rØpartissent comme

suit :

(cid:21) Le premier chapitre, intitulØ PrØsentation gØnØrale, prØsente l’organisme

d’accueil, la problØmatique ainsi que les objectifs (cid:224) atteindre et en(cid:28)n la so-

lution proposØe.

(cid:21) Le second chapitre, intitulØ Gestion du projet, est consacrØ au choix mØ-

thodologique, (cid:224) la mØthode de travail adoptØe et (cid:224) la plani(cid:28)cation du temps.

(cid:21) Le troisiŁme chapitre, intitulØ SpØci(cid:28)cation et analyse globale, prØsente

le SPRINT 0 contenant la spØci(cid:28)cation et l’analyse des besoins, l’Øtat de

l’art des technologies utilisØes, le diagramme des cas d’utilisation gØnØral, le

backlog produit de notre application et en(cid:28)n l’architecture de cette derniŁre.

(cid:21) Le quatriŁme chapitre, intitulØ Interfa(cid:231)age entre le terminal de poin-

tage et la base de donnØes, c’est le premier SPRINT, nous allons analyser

les di(cid:27)Ørents user stories de ce sprint, prØsenter les di(cid:27)Ørents t(cid:226)ches (cid:224) rØaliser

dans le backlog du sprint, faire la conception, la rØalisation et en(cid:28)n tester

notre travail.

(cid:21) Le cinquiŁme chapitre, intitulØ Contr(cid:244)le d’accŁs et demande de congØ,

dØcrire le deuxiŁme sprint dans lequel nous allons analyser ses di(cid:27)Ørents fonc-

tionnalitØs (cid:224) travers les diagrammes des cas d’utilisation, dØgager le backlog

du sprint, faire la conception nØcessaire ainsi que la rØalisation et en(cid:28)n tester

ces fonctionnalitØs.

(cid:21) Nous essayerons au niveau du sixiŁme et le dernier chapitre intitulØ Trai-

tement et gØnØration d’un rapport d’analyser et de dØ(cid:28)nir ces divers

fonctionnalitØs pour passer (cid:224) la conception et la rØalisation et terminer par

les tests nØcessaires.

En guise de conclusion, nous prØsentons le fruit de notre travail ainsi que les

perspectives d’amØlioration.

2

Chapitre 1

PrØsentation gØnØrale

Introduction

Dans ce chapitre, nous prØsenterons en premier lieu l’organisme d’accueil

et ses domaines d’activitØ. Nous prØsenterons ensuite la problØmatique et les mo-

tivations du projet, ainsi que les principaux objectifs du travail (cid:224) rØaliser. Nous

terminerons par Øvoquer la solution proposØe a(cid:28)n d’accomplir toutes les phases de

la prØsentation de notre projet.

1.1 PrØsentation de l’organisme d’accueil

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

Publicité

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

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

3

CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE

(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.

4

CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE

1.2 Cadre gØnØral

1.2.1 ProblØmatique

Plusieurs entreprises rencontrent le problŁme du retard et de dØpassement des

dØlais de pause ce qui re(cid:29)Łte nØgativement le rendement des entreprises. D’oø le

choix de la mise en place d’une application qui synthØtise les accŁs en temps rØel

et di(cid:27)ØrØ par la rØcupØration de toutes les traces d’entrØe selon les indications du

terminal de pointage.

Ces dØfaillances ont amenØ les dirigeants de Sopra HR (cid:224) lancer ce projet qui

consiste (cid:224) concevoir et dØvelopper un outil pour la gestion des temps des employØs

et ce en utilisant leur propre API Open HR. Par la suite, si le client Sopra HR

est satisfait du rØsultat atteint avec cette version, alors Sopra HR va prendre la

charge de travailler davantage sur ce projet.[2]

1.2.2 Objectifs et motivations du projet

L’objectif principal de ce projet est de concevoir et dØvelopper une applica-

tion web en JEE qui a comme but de remØdier aux problŁmes dØj(cid:224) notØs et de

rØpondre aux besoins fonctionnels de la sociØtØ consistant (cid:224) assurer l’interfa(cid:231)age

entre le terminal de pointage et la base de donnØes et a(cid:30)cher les tableaux de bord

synthØtisant ces actions.

En e(cid:27)et, cette application va permettre au client Sopra HR de contr(cid:244)ler l’accŁs

de ces employØs c’est-(cid:224)-dire faire la gestion des temps et des activitØs. Dans ce qui

suit, nous expliquerons en dØtails la notion du GTA (cid:19) Gestion des Temps et des

ActivitØs (cid:20).

1.3 Solution proposØe

Comme solution, nous avons proposØ la rØalisation d’un outil de gestion des

temps et des activitØs ; c’est un site web dans lequel :

Un simple utilisateur (employØ) peut demander un congØ qui va Œtre traitØs par

l’expert RH, il peut aussi consulter le tableau contenant ces demandes pour vØri(cid:28)er

s’ils sont validØes ou refusØes, dŁs que ces demandes sont traitØes il va recevoir des

noti(cid:28)cations.

5

CHAPITRE 1. PR(cid:201)SENTATION G(cid:201)N(cid:201)RALE

Un autre utilisateur (Expert RH) peut contr(cid:244)ler ces employØs en consultant les

statistiques de pointage, les statistiques des absences, le tableau de pointage, le

tableau des absences et le planning des absences. Il peut aussi traiter les demandes

de congØs envoyØs par les employØs et gØnØrer un rapport contenant le tableau de

pointage ou bien le tableau des absences.

Cette solution a ØtØ proposØe au membre de l’Øquipe qui va valider la solution

et la prØsenter au client Sopra HR.

AprŁs une discussion bien dØtaillØe, la solution est validØe ; nous passons par la

suite aux autres Øtapes a(cid:28)n d’aboutir notre objectif.

Conclusion

A travers ce chapitre, nous avons prØsentØ l’organisme d’accueil, sa mis-

sion et ses domaines de compØtences. Nous avons prØsentØ par la suite le cadre

gØnØral de notre projet qui consiste (cid:224) concevoir et dØvelopper l’outil (cid:19) Sopra HR

GT (cid:20) permettant la gestion des temps des employØs.

6

Chapitre 2

Gestion du projet

Introduction

La solution d’un programme informatique n’est pas unique, tout dØpend de

la mØthode de conception du langage de programmation et des technologies choisies.

En fait, selon le projet, on doit choisir la mØthode de gestion de notre projet (cid:224)

retenir et ce, a(cid:28)n de s’organiser et respecter les dØlais. En e(cid:27)et, l’un des problŁmes

majeurs soulevØs par le dØveloppement d’applications est celui de l’adaptation des

mØthodes de conception a(cid:28)n de tirer au mieux pro(cid:28)t des caractØristiques de mise

en oeuvre.

2.1 Choix mØthodologique

Suivre une mØthodologie est une premiŁre assurance pour produire des

logiciels de qualitØ qui rØpondent aux besoins des utilisateurs dans le temps avec

des coßts prØvisibles.

2.1.1 MØthode agile

En e(cid:27)et, l’agilitØ n’est qu’une approche rØactive itØrative d’organisation de

travail. Elle focalise sur la fonctionnalitØ et la satisfaction client.

Une mØthode agile se distingue par son aspect adaptatif plut(cid:244)t que prØdictif

et une plani(cid:28)cation plus souple et favorable au changement.

Ainsi, le choix des mØthodes agiles repose sur plusieurs facteurs, c’est le fait

que les meilleures idØes ne viennent pas forcØment au dØbut du projet mais au fur

et (cid:224) mesure qu’on avance dans le travail Øtape par Øtape. Par ailleurs les besoins

7

CHAPITRE 2. GESTION DU PROJET

peuvent Øvoluer pendant le projet donc on ne doit pas se limiter (cid:224) une situation

imaginØe dŁs le dØbut.

2.1.2 Les principes agiles

Ces principes sont comme suit :

• La prioritØ est de satisfaire le client par la livraison rapide et continuelle de

solutions logicielles utiles.

• IntØgrer les changements, mŒme ceux de la derniŁre minute, car ils fournissent

un avantage compØtitif (cid:224) votre client.

• (cid:201)laborez des projets autour d’individus motivØs, fournissez le support nØces-

saire et faites con(cid:28)ance.

• Les meilleures solutions Ømergent des Øquipes auto organisØes.

• RØguliŁrement, l’Øquipe fait une rØ(cid:29)exion sur les fa(cid:231)ons de devenir plus e(cid:30)-

cace, s’ajuste et modi(cid:28)e son comportement en consØquence.

Publicité

• Porter une attention continue (cid:224) l’excellence technique et (cid:224) un bon design

amØliore l’agilitØ.

• La simplicitØ est essentielle.[3]

2.2 MØthode choisie

2.2.1 SCRUM

Scrum est une mØthode agile utilisØe dans le dØveloppement de logiciels. Elle

vise (cid:224) satisfaire au mieux les besoins du client tout en maximisant les probabilitØs

de rØussite de projet. Le rØsultat du projet dØpend des rØorientations que lui donne

le client en cours de route. Un projet utilisant Scrum est composØ d’une suite

d’itØrations courtes de l’ordre de trois (cid:224) six semaines appelØes sprints. Le projet

peut Œtre rØorientØ par le client (cid:224) la (cid:28)n de chaque sprint.[4]

8

CHAPITRE 2. GESTION DU PROJET

Figure 2.1 (cid:21) Processus de SCRUM [5]

La (cid:28)gure 2.1 montre que SCRUM dØ(cid:28)nit 3 r(cid:244)les :

• Le (cid:19) Product owner (cid:20) qui porte la vision (cid:224) rØaliser (reprØsentant gØnØrale-

ment le client)

• Le (cid:19) Scrum master (cid:20) garant de l’application de la mØthodologie Scrum.

• L’Øquipe de dØveloppement qui rØalise le produit.

Cette mŒme (cid:28)gure montre que la vie d’un projet Scrum est rythmØe par un

ensemble de rØunions clairement dØ(cid:28)nies et strictement limitØes dans le temps

(timeboxing) :

• Plani(cid:28)cation du Sprint (Sprint-itØration) : au cours de cette rØunion, l’Øquipe

de dØveloppement sØlectionne les ØlØments prioritaires du (cid:19)Product owner(cid:20)

(liste ordonnancØe des exigences fonctionnelles et non fonctionnelles du pro-

jet) qu’elle pense pouvoir rØaliser au cours du sprint (en accord avec le (cid:19)Pro-

duct owner(cid:20)).

2.2.2 Les Øtapes de SCRUM

1. Le projet est organisØ en sprints. C’est pendant cette phase que les fonction-

nalitØs choisies sont dØveloppØes et que le logiciel est crØØ.

2. Le backlog du produit constitue l’ensemble du travail connu sur le projet (cid:224)

un instant t. Il est rØguliŁrement remis (cid:224) jour et les besoins qui le constituent

ont aussi rØguliŁrement la prioritØ.

3. Le travail (cid:224) faire durant un sprint est listØ dans le backlog du sprint. Le

contenu du sprint est un extrait du backlog produit. Les besoins sont priorisØs

de la mŒme fa(cid:231)on que dans le backlog du produit.

9

CHAPITRE 2. GESTION DU PROJET

4. Durant le sprint, une rØunion quotidienne appelØe daily scrum(ou mŒlØe quo-

tidienne) rassemble l’Øquipe a(cid:28)n de rØorienter le sprint. Il s’agit du point de

contr(cid:244)le de l’Øquipe.

5. (cid:192) la (cid:28)n d’un sprint, l’Øquipe livre au client un incrØment du logiciel (cid:28)ni

potentiellement livrable.

6. Ce cycle est rØpØtØ jusqu’(cid:224) ce que :

(a) La date de (cid:28)n de projet soit atteinte.

(b) Le client ne peut plus (cid:28)nancer le projet.

(c) Le client considŁre que le logiciel dØlivre su(cid:30)samment de valeur et dØcide

d ?arrŒter le dØveloppement.

2.2.3 Plani(cid:28)cation des sprints

La rØpartition des di(cid:27)Ørentes Øtapes nØcessaires (cid:224) la rØalisation du projet sur

la pØriode de stage, s’Øtendent sur cinq mois, ce planning est reprØsentØ par un

diagramme de GANTT et le diagramme de PERT. En e(cid:27)et, ces diagrammes per-

mettent de plani(cid:28)er le projet et de rendre plus simple le suivi de son avancement.

(Figure 2.2 et 2.3)

Figure 2.2 (cid:21) Diagramme de GANTT : Plani(cid:28)cation des sprints

Figure 2.3 (cid:21) Diagramme de PERT

  • Sprint 0 : Documentation et recherche bibliographique et dØcouverte des

outils (cid:224) utiliser au cours du stage avec identi(cid:28)cation des besoins par le (cid:19)

product owner (cid:20) : Product backlog.

  • Sprint 1 : Interfa(cid:231)age entre le terminal de pointage et la base de donnØes de

Sopra HR et authenti(cid:28)cation des di(cid:27)Ørents acteurs

  • Sprint 2 : Contr(cid:244)le d’accŁs des employØs
  • Sprint 3 : Traitement des demandes de congØs et gØnØration des rapports

10

CHAPITRE 2. GESTION DU PROJET

NB : La rØdaction de ce rapport a ØtØ faite en parallŁle avec toutes ces

Øtapes.

Conclusion

Dans ce chapitre, nous avons prØsentØ notre choix mØthodologique dont nous

avons choisi la mØthode agile : SCRUM. Par la suite nous avons Øclaircir la pla-

ni(cid:28)cation des sprints.

11

Chapitre 3

SPRINT 0 : SpØci(cid:28)cation et analyse

globale

Introduction

Un projet dØmarre gØnØralement par ce qu’on appelle souvent le (cid:19) sprint 0 (cid:20)

dØdiØ aux travaux prØparatoires du projet (ex : construction du product backlog et

de la vision du produit, prØparation des environnements, mise en place de l’intØgra-

tion continue, dØ(cid:28)nition de l’architecture gØnØrale du projet, initiation des acteurs

(cid:224) Scrum, etc.). Exceptionnellement, la durØe de ce (cid:19) sprint 0 (cid:20) ne respecte pas for-

cØment la durØe (cid:28)xØe prØcØdemment. Mais inutile de le faire durer trop longtemps,

souvenez-vous (cf. (cid:28)che pratique (cid:19) introduction aux mØthodes Agile (cid:20)), l’idØe est

de se lancer sans Ølaborer au prØalable un plan et une architecture millimØtrØs qui

risqueraient de nous enfermer, de nous frustrer, voire de nous coßter cher (cid:224) courts

et longs termes. L’architecture doit Œtre souple et Ømerger au (cid:28)l des sprints.

3.1 (cid:201)tude prØalable

A(cid:28)n d’atteindre les objectifs (cid:28)xØs pour notre projet, nous devrions en premier

lieu bien Øtudier l’environnement sur lequel va porter l’outil Sopra HR GT et

prØsenter certaines notions telles que la gestion des temps et des activitØs. Nous

passons ensuite (cid:224) mieux nous positionner par rapport (cid:224) l’existant. Nous nous

intØressons aussi (cid:224) prØciser les besoins fonctionnels et non fonctionnels pour la

rØalisation de notre projet.

12

CHAPITRE 3. SPRINT 0 : SP(cid:201)CIFICATION ET ANALYSE GLOBALE

3.1.1 Gestion des temps et des activitØs

Le module T&A est un moyen de contr(cid:244)ler et de gØrer (cid:28)nement la durØe du

temps de travail en fonction de la politique choisie, au sein de l’entreprise, en

matiŁre d’amØnagement des horaires.

C’est une application de gestion complØtant l’o(cid:27)re applicative Sopra HR (cid:224)

laquelle elle s’intŁgre entiŁrement.

Elle permet en particulier :

• D’utiliser certaines informations des dossiers individuels des salariØs de la

base du Personnel existante, a(cid:28)n de minimiser la saisie.

• De crØer des liens automatiques avec la gestion de la paie.

Ce module est destinØ aux responsables d’activitØs administratives ou tech-

niques et aux services de paie a(cid:28)n de leur faciliter la gestion de la rØmunØration

des individus.[6]

13

CHAPITRE 3. SPRINT 0 : SP(cid:201)CIFICATION ET ANALYSE GLOBALE

Les di(cid:27)Ørents acteurs :

Les personnes travaillant sur le module T&A, le planning et le suivi des prØ-

sences et des absences sont rØpartis, en fonction de l’organisation, entre :

• L’expert RH

• Le gestionnaire RH

3.1.2 SystŁme de pointage

Le tableau ci-dessous (Tableau 3.1) illustre le fonctionnement d’un systŁme de

pointage.

(cid:201)lØments

Badge

Description

Objet mobile portable : carte,

porte-clØs ou tØlØphone portable

Terminal

Publicité

Il s’agit plus souvent d’un bo(cid:238)ti...