École Supérieure Privée des Sciences Appliquées et de

Management
Université SESAME

Rapport du projet personnel encadré

Réalisation de système d’information GFI

(RH)
Réalisé par

KETATA Marwen
SGHIR Amine
MERSNI Wael
TAAMALLAH Houssem

Année Universitaire 2019 - 2020

 Remerciement

Au terme de ce travail, nous adressons nos vifs remerciements à Monsieur Houssem JMAL,
notre encadrant, pour son suivi, sa disponibilité, son aide précieuse et ses conseils qui nous
ont été d’une utilité indéniable.
Nous exprimons également toutes nos gratitudes à tous nos enseignants de SESAME pour la
formation qu’ils nous ont donnés.
Nous tenons à remercier Madame Amal BOUAZIZ qui a accepté d’évaluer ce travail.
Enfin, nous remercions ceux et celles qui ont participé de près ou de loin à l’élaboration du
présent travail et principalement pour leur service et pour leur soutien moral tout au long de
la préparation de cette projet.

1
Remerciement .......................................................................................................................................... 1
Introduction Générale .............................................................................................................................. 5
Chapitre 1 ................................................................................................................................................ 6
Cadre général de projet ............................................................................................................................ 6
1. Introduction.................................................................................................................................. 7
2. Présentation de projet ................................................................................................................... 7
2.1. Présentation .......................................................................................................................... 7
2.2. Valeurs ................................................................................................................................. 8
2.3. Qualité .................................................................................................................................. 8
2.4. Service ................................................................................................................................. 9
3. Analyse du contexte ..................................................................................................................... 9
4. Problématique ............................................................................................................................ 10
5. Solution proposée ....................................................................................................................... 10
6. Méthodologie adoptée ................................................................................................................ 11
6.1. Comparaison entre l’approche Agile et l’approche classique .................................................... 11
6.2. Présentation de SCRUM ..................................................................................................... 12
6.3. Les rôles SCRUM ............................................................................................................... 13
7. Conclusion ................................................................................................................................. 13
Chapitre 2 .............................................................................................................................................. 14
Planification : Sprint 0 ........................................................................................................................... 14
2.1. Introduction ............................................................................................................................ 15
2.2. Backlog du produit ............................................................................................................. 15
2.3. Identification des besoins .................................................................................................... 18
2.3.1. Identification des acteurs et de fonctionnalités ............................................................. 18
2.3.2. Les besoins fonctionnels ............................................................................................. 19
2.3.3. Les besoins non fonctionnels ....................................................................................... 19
2.4. Diagramme de cas d’utilisation global................................................................................. 19
2.5. Diagramme des classes global ............................................................................................. 20
2.6. Planification des sprints ...................................................................................................... 21
2.6.1. DevOps ....................................................................................................................... 22
2.7. Environnement de travail .................................................................................................... 24
2.7.1. Environnement matériel .............................................................................................. 24
2
 2.7.2. Environnement de développement ............................................................................... 24
2.7.3. Environnement logiciel ............................................................................................... 25
2.8. Architecture générale de l’application ................................................................................. 27
3. Conclusion ................................................................................................................................. 28
Chapitre 3 .............................................................................................................................................. 29
Mise en œuvre du projet ......................................................................................................................... 29
1. Introduction................................................................................................................................ 30
2. Mise en œuvre du Release 1 ....................................................................................................... 30
2.1. Sprint 1 ............................................................................................................................... 30
2.1.1. Backlog du Sprint ....................................................................................................... 30
2.1.2. Diagramme de cas d’utilisation ................................................................................... 32
2.1.3. Conception .................................................................................................................. 33
2.1.3.1. Diagramme de classe ............................................................................................... 33
2.1.4. Réalisation .................................................................................................................. 34
3. Mise en œuvre du Release 2 ....................................................................................................... 36
3.1. Sprint 2 ............................................................................................................................... 37
3.1.1. Backlog du Sprint ....................................................................................................... 37
3.1.2. Diagramme de cas d’utilisation ................................................................................... 38
3.1.3. Conception .................................................................................................................. 38
3.1.3.1. Diagramme d’activité .............................................................................................. 38
3.1.3.2. Diagramme des classes de sprint 2 ........................................................................... 39
3.1.4. Réalisation .................................................................................................................. 40
4. Conclusion ................................................................................................................................. 42
Conclusion générale ............................................................................................................................... 43
Références ............................................................................................................................................. 44
Netographie ........................................................................................................................................... 45

3
Liste des figures
Figure 1 : Logo GFI.....................................................................................................................................................7
Figure 2: Interface MYCYN...................................................................................................................... 10
Figure 3: Méthodologie agile vs. Classique............................................................................................... 11
Figure 4: Méthode Scrum........................................................................................................................... 12
Figure 5 : Rôles dans SCRUM................................................................................................................... 13
Figure 6 : Diagramme de cas d'utilisation global....................................................................................... 20
Figure 7: Diagramme de Classe Global...................................................................................................... 21
Figure 8: Planification des sprints...........................................................................................................................22
Figure 9 : Planification du Sprint 1 avec DevOps...................................................................................... 23
Figure 10 : Planification du Sprint 2 avec DevOps.................................................................................... 24
Figure 11 : Data Base First Approche........................................................................................................ 27
Figure 12: Architecture de l’application..................................................................................................... 28
Figure 13: Diagramme de cas d'utilisation du sprint 1............................................................................... 33
Figure 14 : Diagramme de classe du sprint 1............................................................................................. 34
Figure 15 : Interface de consultation.......................................................................................................... 35
Figure 16 : Interface d’ajout....................................................................................................................... 35
Figure 17 : Interface de modification......................................................................................................... 36
Figure 18 : Interface de suppression........................................................................................................... 36
Figure 19 : Diagramme de cas d'utilisation de sprint 2............................................................................... 38
Figure 20: Diagramme d'activité de gérer demande congé......................................................................... 39
Figure 21: Diagramme de classe du sprint 2.............................................................................................. 40
Figure 22 : Interface de tableau de bord..................................................................................................... 41
Figure 23 : Interface de validation congé................................................................................................... 41

Liste des Tableaux

Table 1: Backlog du produit....................................................................................................................... 15
Table 2 : Les différents acteurs interagissant avec notre système............................................................... 18
Table 3: Backlog du Sprint 1...................................................................................................................... 30
Table 4: Backlog du Sprint 2...................................................................................................................... 37

4
 Introduction Générale

Actuellement, le monde connaît une avance technologique considérable dans tous les secteurs et
cela à l’aide de l’informatique, qui joue un rôle important dans le développement de nombreuses
entreprises et organisations.
Avant, nous enregistrons toutes les informations manuellement sur des supports en papier. Ce qui
engendrait beaucoup de problèmes tel que la perte de temps considérable dans la recherche de ces
informations ou la dégradation de ces dernières [1].
Notre projet de spécialité consiste à la création d’un application web de Gestion des ressources
humaines pour la société GFI. L’apport le plus important de notre projet sera à la fois pour tous
les employés de la société qui peut gérer les données facilement. Ainsi, qu’à l’administrateur qui
peut gérer aussi bien tous les fonctionnalités du systéme.
Le présent rapport est structuré en trois chapitres comme suit :

• Le premier chapitre intitulé Cadre général du projet sera consacré à la présentation du

projet, avec une étude des problématiques avec les solutions proposées, ensuite nous
présenterons une comparaison entre quelques méthodologies.

• Le deuxième chapitre, intitulé Planification « Sprint 0 », nous nous intéressons à définir le

backlog produit, et à présenter une vue architecturale et conceptuelle globale de notre
application. C’est également à ce niveau que nous présenterons les outils et technologies
utilisés pour le développement.

• Le dernier chapitre, intitulé Mise en œuvre du projet se concentrera sur l’étude et la

réalisation des sprints de notre projet. Dans chaque sprint, nous commencerons, par le «
Backlog du Sprint » qui décrit les tâches à faire et ensuite nous présenterons le diagramme
de classe, les des cas d’utilisation et le diagramme d’activité. Enfin, nous illustrerons
l’exécution de notre application par des captures écrans
Finalement, nous clôturerons ce rapport par une conclusion générale.

5
 Chapitre 1
Cadre général de projet

6
1. Introduction

Dans ce chapitre, nous allons tout d’abord mettre le projet dans son cadre, nous présenterons
l’établissement dans lequel nous avons réalisé le projet. Ensuite, nous allons aussi exposer
l’étude sur les avantages et les inconvénients des applications similaires existantes.

2. Présentation de projet
2.1. Présentation

Cynapsys GFI, l’ESN (entreprise de service numérique) tunisienne fondée en 2004 et déjà
présente dans plusieurs pays à travers ses filiales en Europe et en Afrique, est un acteur
majeur dans le secteur de l’ingénierie de l’informatique avec plus de 150 collaborateurs, 7
millions d’euros de chiffre d’affaire et plus de 100 références dans 16 pays. Cynapsys
intervient principalement par de l’assistance technique IT, de la TMA, du développement
logiciel et mène des activités de RDI. Le groupe GFI confirme son intérêt pour la Tunisie et
ses compétences techniques et humaines et juge que Cynapsys peut participer activement
dans la stratégie du développement à l’international du groupe du monde de l’IT en
développant plusieurs centres de services en Tunisie.

Figure 1 : Logo GFI

7
 2.2. Valeurs
Le Groupe Cynapsys GFI, ESN Entreprise de Service du Numérique, marque un point
d’honneur à mener l’intégralité de ses missions dans le strict respect de certaines valeurs qui
représentent les piliers de son activité :

• Performance
Lorsque la passion, l’investissement et la bonne qualification de chacun sont catalysés et
mis en

Valeur par une organisation et des moyens adaptés, la performance devient un résultat
naturel.

• Orientation client
Nous nous efforçons de saisir les besoins réels de nos clients et d’y répondre au mieux,
par des recommandations et des réalisations porteuses de progrès, élaborées sans céder
aux facilités de nos habitudes. ²

• Rigueur
Notre recherche de l’excellence et notre goût pour l’évolution nous poussent chaque
jour à améliorer la qualité de nos services informatiques avec le souci du détail et le
sens des responsabilités.

2.3. Qualité

La totale implication 120 collaborateurs basés aussi bien à Tunis, qu’à Paris ou
Frankfurt, donnent toute l’ampleur des directives prioritaires de la Politique Qualité de
Cynapsys qui visent l’amélioration continue de :

• La satisfaction de nos clients.

• La réactivité face aux besoins, exigences et attentes.
• La gestion des projets.
• Les compétences techniques de nos collaborateurs.
• La performance de notre entreprise.
• Le niveau de la qualité globale.
Cynapsys est engagée depuis 2011 dans la démarche de Responsabilité Sociétale de
l’Entreprise (RSE) qui lie :

• L’optimisation des coûts en rapport avec les impacts environnementaux.

• Les bonnes pratiques de la gestion des carrières et la gestion de la
connaissance.
8
L’adéquation entre les priorités financières et les bonnes pratiques de partenariat d’affaires

2.4. Service

Coté service GFI offre six service :

• Ingénierie informatique.
• TMA : La Tierce Maintenance Applicative est la maintenance appliquée à un
logiciel et assurée par un prestataire externe dans le domaine des technologies de
l’information et de la communication.
• Assistance technique.
• Test et validation.
• Formation
• RDI : Recherche, Développement et Innovation.

3. Analyse du contexte

MyCyn est une application web qui décrit le système d’information de l’entreprise GFI, elle permet de
gérer les ressources humaines, matérielles et logicielles, de données et de réseaux de communication et
diffuse l’information au sein de l’entreprise. Dans ce contexte, un utilisateur quel que soit son rôle (admin
ou simple employé), peut se connecter à cette application avec un nom d’utilisateur et mot de passe afin
de gérer des ressources bien précise. Par exemple, pour un simple employé, il peut faire la gestion des
taches, réserver des ressources et formuler les ordres de missions et les demande de congés. Par contre, un
admin a beaucoup d’autre privilège, tel que le panneau de paramétrage pour les gestions des employés,
des clients, des pôles et des profils

9
 Figure 2: Interface MYCYN

4. Problématique

Depuis sa création en 2004, GFI ne fait que grandir. Elle gagne de plus en plus de projet et par
conséquent, elle recrute de plus en plus de personnel. Cet accroissement génère un volume de données
très important en constante évolution, devenant ingérable pour une gestion sans assistance informatique
performante.

Initialement, la société utilisait un système d’information basique développé avec JAVA JEE. Au fur et à
mesure des années et de l’augmentation de la quantité de données stockées dans sa base de données [1], ce
système d’information est devenu progressivement un facteur de ralentissement tant au niveau de
l’efficacité de son interface web que sa rapidité d’exécution.

5. Solution proposée

Afin de résoudre les problématiques précédentes notre application doit répondre

au condition suivante :

• Centraliser l’information et les données

• Migration vers des technologie plus performante
• Amélioré les vues des interfaces et des Dashboard

10
6. Méthodologie adoptée

Pour pouvoir choisir la bonne méthodologie, il faut avoir une idée sur les avantages et les
inconvénients de quelques- unes et savoir ainsi laquelle répond aux contraintes et aux exigences de
notre projet. Ci-dessous nous présentons un aperçu sur les différentes méthodologies.

6.1. Comparaison entre l’approche Agile et l’approche classique

Depuis toujours, les projets sont gérés avec des méthodologies classiques qui se caractérisent
par recueillir les besoins, définir le produit, le développer et le tester avant de le livrer. Ces
méthodologies sont appelées aussi –les approches prédicatives. En effet, comme son nom
l’indique, il s’agit ici de prévoir des phases séquentielles où il faut valider l’étape précédente pour
passer à la suivante. On doit alors s’engager sur un planning précis de réalisation du projet en
prévoyant des jalons de débuts et fins de phases ainsi que les tâches à effectuer.
De plus, elles sont axées principalement sur le périmètre du projet, son coût et sa planification.
Les méthodes Agiles quant à elles font des méthodes "classiques" une contrainte. Ainsi on voit le
coût, le périmètre et la planification comme des contraintes sur lesquelles on va se focaliser tout
en étudiant en parallèle la valeur ajoutée cliente et la qualité du produit livre. On ne choisit pas
directement de livrer un projet, on s’assure d’apporter la valeur cliente nécessaire avec un
produit de qualité en optimisant nos coûts, notre temps et surtout les risques liés au projet. Le
client obtient donc une place importante au sein d’une organisation Agile. Son avis est compté et
respecté. Les protagonistes (internes et externes) doivent accepter l’apprentissage et doivent être
préparés au changement) [3]. La figure 1 présente une Comparaison entre la méthode classique
et la méthode Agile.

Figure 3: Méthodologie agile vs. Classique

11
Brièvement, les méthodologies agiles sont basées sur 4 valeurs clé qui les différencient
des approches classiques [4] :
• L’interaction avec les personnes plutôt que les processus et les outils,
• Un produit opérationnel plutôt qu’une documentation pléthorique,
• La collaboration avec le client plutôt que la négociation de contrat,
• La réactivité face au changement plutôt que le suivi d’un plan.
Par conséquent, on a choisi d’adopter une méthodologie agile car elle définit un cadre moins
rigide que les méthodes traditionnelles et elle est plus pragmatique que ces derniers de sorte
qu’elle assure la satisfaction du client en facilitant la gestion du projet, améliorant la qualité
de développement et s’adaptant mieux aux imprévus du projet.

6.2. Présentation de SCRUM

Scrum [5] est une méthode agile qui vise à satisfaire au mieux les besoins du client tout en
maximisant les probabilités de réussite du projet. Elle suppose que le développement d’un
logiciel n’est pas prévisible et ne peut donc pas suivre de processus défini. Ainsi, le résultat du
projet n’est pas connu au départ, il dépend des réorientations que lui donne le client en cours
de route.
Comme le client classe lui- même les fonctionnalités par ordre d’importance, il est
certain d’obtenir un logiciel à forte valeur ajoutée en fin de projet. La figure 2 montre de
quoi se compose SCRUM.

Figure 4: Méthode Scrum

Le principe de base de Scrum est de se focaliser de façon régulière sur un ensemble de
fonctionnalités à réaliser appelées Sprints. Chaque Sprint possède des buts à atteindre à partir
desquels sont choisies les fonctionnalités à implémenter. Ces fonctionnalités sont définies
sous forme d’User Story. Un sprint aboutit toujours sur la livraison d’un produit partiellement
fonctionnel [5–].
Justification du choix :
Le choix de la méthodologie Scrum fournit plusieurs avantages pour les clients :

12
 • La méthodologie scrum fournit au client de tester l’application des que le développeur
finit la premier partie de chaque sprint. Ainsi garantie le travail concret avec le client.
Nous minimisons les problèmes de compréhension de la conception. En plus le client
peut ajouter ou modifier des fonctionnalités au début ou à la fin de chaque sprint,
• Scrum assure une qualité de produit grâce à la transparence du processus nous pouvons
visualiser des lacunes d’un livrable et l’amélioration se fera dès le prochain livrable.

6.3. Les rôles SCRUM

SCRUM définit trois rôles principaux :
• Le « Product Owner » qui porte la vision du produit à réaliser (représentant
généralement le client) ;
• Le « Scrum Master » garant de l’application de la méthodologie Scrum ;
• Le « Scrum Team » L’équipe de développement qui réalise le produit.
La figure 3présente les rôles dans SCRUM.

Figure 5 : Rôles dans SCRUM

7. Conclusion

Tout au long de ce chapitre, nous avons présenté une brève description du projet à réaliser, en
déterminant la problématique et en proposant la solution envisagée pour faire face à la
situation actuelle. Par la suite nous avons présenté une étude de quelques méthodologies de
développements existants pour effectuer le choix de la méthodologie qui sera adoptée pour le
développement de notre système.
Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et non fonctionnels,
la spécification du Backlog de produit et la préparation du planning de travail.
13
 Chapitre 2
Planification : Sprint 0

14
2.1. Introduction

Dans ce chapitre, nous allons tout d’abord, présenter le backlog du produit qui regroupe toutes
les exigences à réaliser par notre système. Ensuite, nous allons passer à la phase d’analyse de la
solution et la détermination des besoins fonctionnels et non fonctionnels. Après, nous décrivons
la spécification du diagramme de cas d’utilisation général. Enfin, nous présentons la planification
des sprints ainsi que l’environnement de développement.

2.2. Backlog du produit

Le backlog de produit est la liste des fonctionnalités attendues par notre application. Il
contient toutes les tâches qui seront développées par l’équipe. Elles y sont classées par priorité
ce qui permet de définir l’ordre de réalisation. Les tâches ainsi que ces priorités sont dégagées
suite à des réunions avec le client et le chef de projet.
Le backlog de produit permet de produire le plan de chaque sprint qui contient les
différentes fonctionnalités qu’on estime finir à la date précisée pour le sprint.
La complexité de la réalisation de chaque user story est ceci selon la suite de Fibonacci.
Cette dernière est une suite d’entiers, dont chaque terme est la somme de deux précédents, en
considérants les deux termes initiaux 0 et 1. Le début de cette suite est : 0, 1, 2, 3, 5, 8, 13 et
l’infini [6].
La priorité de l’user story selon la valeur métier et l’ordre de réalisation.
Table 1: Backlog du produit

consulter les projets.

ajouter les projets.

modifier les projets.

supprimer les projets.

consulter les clients.

ajouter les client.

modifier les clients.

supprimer les clients.

consulter les employés.

15
modifier les employés.

supprimer les employés.

consulter les groupes d’activité.

ajouter les groupes d’activité.

modifier les groupes d’activité.

supprimer les groupes d’activité.

ajouter les domaines.

modifier les domaines.

consulter les domaines.

supprimer les domaines.

ajouter les types budget.

modifier les types budget.

consulter les types budget.

supprimer les types budget.

une demande congé.

modifier les demandes congé.

consulter les demandes congé.

supprimer les demandes congé.

validercongé. ou refuser les demandes

ajouter les pô les.

modifier les pô les.

consulter les pô les.

supprimer les pô les.

ajouter les fonctionnalités.

modifier les fonctionnalités.

consulter les fonctionnalités.

16
 supprimer les fonctionnalités.

ajouter les activités.

modifier les activités.

consulter les activités.

supprimer les activités.

ajouter les types projet.

modifier les types projet.

consulter les types projet.

supprimer les types projet.

ajouter les équipes projet.

modifier les équipes projet.

consulter les équipes projet.

supprimer les équipes projet.

ajouter les secteurs.

modifier les secteurs.

consulter les secteurs.

supprimer les secteurs.

turnover ajouter homme jours turnover.

modifier homme jours turnover.

consulter homme jours turnover.

AO ajouter pourcentage charge AO.

modifier pourcentage charge AO.

consulter pourcentage charge AO.

ajouter les jours fériés.

modifier les jours fériés.

consulter les jours fériés.

17
 supprimer les jours fériés.

ajouter les horaires.

modifier les horaires.

consulter les horaires.

supprimer les horaires.

ajouter les tâ ches.

modifier les tâ ches.

consulter les tâ ches.

supprimer les tâ ches.

2.3. Identification des besoins

L’identification des besoins comprend l’identification des acteurs et la détermination des

besoins fonctionnels et les besoins non fonctionnels.

2.3.1. Identification des acteurs et de fonctionnalités

Dans ce qui suit, nous allons présenter les différents acteurs interagissant avec notre système. En
effet, un acteur peut consulter et ou modifier directement l’état du système, en émettant ou en
recevant des messages éventuellement porteurs de données.
Les principaux acteurs du notre système projeté ainsi que ses rôles sont présentés dans la table
2 suivant :
Table 2 : Les différents acteurs interagissant avec notre système

Administrateur système
Employé
demander des congés, consulter et ajouter des tâ ches

18
2.3.2. Les besoins fonctionnels

L’application doit fournir les fonctionnalités suivantes :

• Administrateur
 Gérer les projets
 Valider les demandes congés.
 Consultation des statistiques.
 Paramétrage de l’application.
 Suivie des tâches.
• Employé
 Gérer les demandes congés.
 Gérer les tâches.
 Consultation et modification des données personnelles.

2.3.3. Les besoins non fonctionnels

En plus des besoins fonctionnels explicités, le produit livré à la fin de chaque sprint doit
pouvoir assurer les exigences non fonctionnelles suivantes :
• Intégrité : une partie essentielle de n’importe quelle application est de s’assurer
que toutes les opérations effectuées sont exécutées correctement,
• Ergonomie et simplicité : il faut prendre en considération tous les types des utilisateurs
pour cette raison notre application doit être simple à manipuler contenant les données
nécessaires pour effectuer une opération,
• Sécurité : Elle est assurée par un système d’authentification et d’autorisation
pour protéger les données personnelles,
• Performance et efficacité : Contenir un minimum d’erreurs, satisfaire les
spécifications et remplir ses missions, permette d’effectuer les opérations rapidement et
de manière efficace pour gagner du temps,
• Testabilité : Faciliter les procédures de test permettant de s’assurer de l’adéquation
des fonctionnalités.

2.4. Diagramme de cas d’utilisation global

Le diagramme de cas d’utilisation, présenté par la figure 6, permet de synthétiser les

spécifications générales de notre application ainsi que les fonctionnalités de chaque utilisateur de
système.

19
 Figure 6 : Diagramme de cas d'utilisation global

2.5. Diagramme des classes global

20
 Figure 7: Diagramme de Classe Global

2.6. Planification des sprints

Une fois nous avons terminé le backlog du produit, nous avons établi la réunion de
planification. Le but de cette réunion est de construire le backlog de sprint en se basant sur le
backlog de produit réalisé par le Product owner.
A la fin, nous avons identifié, les durées prévisionnelles du travail à effectuer durant chaque sprint.
Pour notre projet nous avons devisé le travail en deux sprints. Pour le premier contient les tâches de
développement de paramétrages d’une durée d’un mois alors que le deuxième sprint

21
contient la gestion des tâches, congé et tableau de bord par une durée d’un mois. La figure
8 montre la répartition des sprints relative à notre système.
Nous avons utilisé DevOps pour la planification de notre projet.

Plan du release Plan du release

Estimation: De 15/11/19 au 15/12/19 Estimation: De 15/04 au 27/04

Sprint 1 Sprint 2

1. Gérer les clients

2. Gérer les employés
3. Gérer les domaines
4. Gérer les types budget
5. Gérer les groupes d’activité
6. Gérer les pôles 1. Gérer les tâches
7. Gérer les fonctionnalités 2. Gérer les demandes
8. Gérer les activités congé
9. Gérer les secteurs 3. Gérer les projets
10. Gérer les types de frais
4. Consulter tableau
11. Gérer les hommes
jours turnover de bord
12. Gérer les pourcentages AO
13. Gérer les jours fériés
14. Gérer les horaires

444
Figure 8: Planification des sprints

2.6.1. DevOps

DevOps regroupe des personnes, des processus et des technologies qui permettent une livraison
continue de valeur aux clients. DevOps, nom composé du terme dev (pour développement) et
du terme ops (pour opérations), est une pratique de développement logiciel qui unifie les
opérations de développement et les opérations informatiques. Cette pratique permet la
coordination et la collaboration entre des disciplines autrefois cloisonnées. Les équipes
d’ingénierie qualité et de sécurité font également partie de l’équipe élargie du modèle DevOps.
DevOps inclut des activités principales, notamment la planification et le suivi, le développement, les
builds et les tests, la livraison, le monitoring et les opérations. Ces activités, ainsi que les outils et
technologies DevOps, aident à automatiser le cycle de vie des applications. Les
22
processus auparavant manuels et lents pour vos équipes, tels que la mise à jour du code ou la
mise en service d’un nouvel environnement, peuvent être réalisés rapidement et en continu
lorsque vous utilisez les outils et pratiques DevOps. Par ailleurs, il est plus facile de respecter
les standards de sécurité et de fiabilité qui sont intégrés au processus.
Avec DevOps, votre organisation est équipée pour fournir de meilleurs produits, plus rapidement.
En associant des personnes, des processus et des technologies à des pratiques et outils partagés,
vous bénéficiez de temps de développement réduits, d’un Time-to-Market plus rapide et d’une
qualité produit accrue [7].
Les figures 9 et 10 présentent, respectivement, la planification des Sprints 1 et 2.

Figure 9 : Planification du Sprint 1 avec DevOps

23
 Figure 10 : Planification du Sprint 2 avec DevOps

2.7. Environnement de travail

L’analyse des besoins techniques couvre la spécification des technologies à utiliser ainsi que la
structure applicative pour donner une vision globale sur l’architecture de notre projet Avant de
se lancer dans la conception et l’implémentation de notre projet nous allons décrire
l’environnement et les outils du travail. On va commencer par définir l’environnement matériel,
ensuite l’environnement de développement puis on passe à celui logiciel qui est bien riche.

2.7.1. Environnement matériel

Tout au long de notre projet, nous avons eu à notre disposition 3 ordinateurs portables
qui disposent de la configuration suivante :
• LENOVO: Intel Core i7 @ 1TO, Ram: 8, 00 Go,
• ASUS: Intel Core i7 @ 1TO, Ram: 8, 00 Go,
• LENOVO: Intel Core i5 @ 2TO, Ram: 8, 00 Go,
• Système d’exploitation : Windows 10.

2.7.2. Environnement de développement

24
Visual Studio 2017 : Visual Studio est un ensemble complet d’outil de
développement permettant de générer plusieurs types des applications Windows [8].

SQL SERVER 2017 : SQL Server est un système de gestion de base de données
et commercialisé par la société Microsoft.

SQL Server Management Studio 2017 : est un environnement intégré qui permet d’avoir accès, de
configurer, de gérer, d’administrer et de développer tous les composants de SQL Server [9].
Visual Studio Code : est un éditeur de code extensible développé par Microsoft pour
Windows, Linux et macOS2.

2.7.3. Environnement logiciel

• ASP.NET Core 2.0 :

ASP.NET Core est une jeune plateforme de développement, dont la première version stable à vue
le jour en juin 2016. Elle a été créée pour répondre aux besoins des développeurs dans la mise en
place d'applications Web modernes multiplateformes pouvant cibler le cloud et le mobile.

ASP.NET Core a donc été développé avec à l'esprit l'ouverture, les performances et la légèreté :

• le Framework est développé en open source avec la participation de la communauté. Son

code source est disponible sur GitHub;
• il est multiplateforme et peut fonctionner sur Windows, Linux et Mac ;

25
• il est indépendant de tout environnement de développement. Pas besoin de Visual Studio
pour créer une application ASP.NET Core ;
• il est développé autour de la modularité. De ce fait, une application ASP.NET Core est
publiée uniquement avec le nécessaire pour son fonctionnement. Ce qui rend la
plateforme un candidat de choix pour le cloud, où l'espace de stockage utilisé est facturé.

• Angular :
Angular est un Framework JavaScript côté client qui permet de réaliser des applications
de type « Single Page Application ». Il est basé sur le concept de l’architecture MVC
(Model View Controller) qui permet de séparer les données, les vues et les différentes
actions que l’on peut effectuer.

• HTML5 : définit deux syntaxes de DOM : HTML5 et XHTML5. Cette version apporte
de nouvelles possibilités en termes de création d’ « applications Web riches »
bénéficiant de l’intégration d’éléments multimédias et d’interactivité.

• Bootstrap: est un Framework CSS3, HTML5 et JavaScript, créé par les développeurs
de Twitter .Il comporte un système de grille de 12 colonnes efficace, permettant de
mettre en ordre l’aspect visuel d’une page web. Il apporte du style pour les boutons, les
formulaires, la navigation et permet ainsi de concevoir un site Web rapidement et avec
peu de lignes de code ajoutées.

• CSS3: est un langage de style permettant d’améliore le contenu des pages Web.

26
 • Entity Framework : est un outil permettant de créer une couche d’accès aux
données DAL pour Data Access Layer) liée à une base de données relationnelle.

Le but de cette solution de mapping est d’offrir une couche d’interfaçage qui sera
l’intermédiaire entre la base de données et le développeur [10].

Dans notre application, nous avons utilisé l’approche Data Base First, présenté par
la figure 9.

Figure 11 : Data Base First Approche

2.8. Architecture générale de l’application

Avant de se lancer dans la conception et le développement, nous allons préparer notre

architecture. La figure 10 présente l’architecture de notre projet.
Notre application est divisée en deux parties :

• La partie Front, développé avec Angular, des maquettes web permet aux utilisateurs de
gérer les différentes entités.

• La partie Back, développé avec ASP.Net Core, qui adopte le modèle MVC avec une
séparation entre le modèle de données, la vue et les traitements, alors on peut
appliquer cette sémantique de Model-View-Controller avec :

o Modèle : les modèles sont les entités de notre application. Ils sont également
des tables SQLServer,
o Vue : les vues sont définies en fichiers HTML dans Angular,
o Contrôleur : le contrôleur est web API.

27
 Figure 12: Architecture de l’application

3. Conclusion

À la fin de cette phase, nous avons effectué une présentation en clair de nos besoins et de la
solution proposée. En premier lieu nous avons identifié le backlog du produit. Ensuite, nous
avons présenté la spécification des besoins ainsi que la conception générale. Enfin, nous avons
exposé l’environnement matériel et logiciel de notre projet. Dans le chapitre suivant nous
allons passer à la mise en œuvre des releases de notre projet.

28
 Chapitre 3

Mise en œuvre du projet

29
1. Introduction

Dans ce chapitre nous avons choisi d’entamer la mise en œuvre de notre projet. Dans la
première partie nous présentons la première release, le Sprint 1, et dans la seconde la deuxième
release, Sprints 2, en organisant le travail sur trois phases principales qui sont l’analyse, la
conception, et la réalisation.

2. Mise en œuvre du Release 1

Dans cette partie, nous présentons la réalisation du premier sprint.

2.1. Sprint 1

Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du produit
sera réalisé. Tous les sprints d’une release ont une durée constante et ne se chevauchent jamais,
c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce
dernier qui doit être un tableau descriptif qui précise la charge du travail pour chaque tâche en
nombre de jours.
2.1.1. Backlog du Sprint

La table 3 décrit les Stories de notre backlog du sprint.

Table 3: Backlog du Sprint 1

consulter les clients.

ajouter les client.

modifier les clients.

supprimer les clients.

consulter les employés.

ajouter les employés.

modifier les employés.

supprimer les employés.

consulter les groupes d’activité.

30
 modifier les groupes d’activité.

supprimer les groupes d’activité.

ajouter les domaines.

modifier les domaines.

consulter les domaines.

supprimer les domaines.

ajouter les types budget.

modifier les types budget.

consulter les types budget.

supprimer les types budget.

ajouter les pô les.

modifier les pô les.

consulter les pô les.

supprimer les pô les.

ajouter les fonctionnalités.

modifier les fonctionnalités.

consulter les fonctionnalités.

supprimer les fonctionnalités.

ajouter les activités.

modifier les activités.

consulter les activités.

supprimer les activités.

ajouter les secteurs.

modifier les secteurs.

consulter les secteurs.

supprimer les secteurs.

31
 modifier homme jours turnover.

consulter homme jours turnover.

AO ajouter pourcentage charge AO.

modifier pourcentage charge AO.

consulter pourcentage charge AO.

12 Gérer les jours fériés ajouter les jours fériés.

modifier les jours fériés.

consulter les jours fériés.

supprimer les jours fériés.

13 Gérer les horaires ajouter les horaires.

modifier les horaires.

consulter les horaires.

supprimer les horaires.

2.1.2. Diagramme de cas d’utilisation

Dans cette partie nous présentons la phase d’analyse qui répond à la question « que fait
l’utilisateur d’application ». La réponse de cette question se traduit par la présentation
du diagramme des cas d’utilisation.
La figure 13 présente le diagramme de cas d’utilisation du sprint 1.

32
 Figure 13: Diagramme de cas d'utilisation du sprint 1

2.1.3. Conception

La conception est la deuxième activité dans un Sprint. Elle est présentée par le diagramme
des cl.

2.1.3.1. Diagramme de classe

La figure 14 traduit le diagramme de classe utilisé pour le développement du premier sprint.

33
 Figure 14 : Diagramme de classe du sprint 1

2.1.4. Réalisation

Cette partie est consacrée à l’exposition du travail achevé à travers des captures d’écrans de
différentes interfaces développées pendant ce sprint. La figure 15 présente l’interface de
consultation et la figure 16 montre l’interface d’ajout.

34
 Figure 15 : Interface de consultation

Figure 16 : Interface d’ajout

La figure 17 présente l’interface de modification et 18 l’interface de suppression.

35
 Figure 17 : Interface de modification

Figure 18 : Interface de suppression

3. Mise en œuvre du Release 2

36
Après avoir terminé le premier release de notre projet, nous pouvons maintenant passer
au deuxième release.

3.1. Sprint 2

Le but principal de Sprint 2 est de mettre en œuvre les stories qui sont présentées par le
tableau de Backlog.
3.1.1. Backlog du Sprint

La table 4 décrit les Stories de notre backlog du sprint.

Table 4: Backlog du Sprint 2

consulter les projets.

ajouter les projets.

modifier les projets.

supprimer les projets.

une demande congé.

modifier les demandes congé.

consulter les demandes congé.

supprimer les demandes congé.

validercongé. ou refuser les demandes

ajouter les types projet.

modifier les types projet.

consulter les types projet.

supprimer les types projet.

ajouter les équipes projet.

modifier les équipes projet.

consulter les équipes projet.

supprimer les équipes projet.

37
 modifier les tâ ches.

consulter les tâ ches.

supprimer les tâ ches.

3.1.2. Diagramme de cas d’utilisation

La figure 19 représente le diagramme de cas d’utilisation du sprint 2.

Figure 19 : Diagramme de cas d'utilisation de sprint 2

3.1.3. Conception

Après avoir terminé le diagramme de cas d’utilisation du deuxième sprint. Nous passons
à présenter le diagramme d’activité de cette partie.
3.1.3.1. Diagramme d’activité

La figure 20 présente le diagramme d’activité de Gérer demande congé.

38
 Figure 20: Diagramme d'activité de gérer demande congé

3.1.3.2. Diagramme des classes de sprint 2

La figure 21 présente le diagramme de classe du sprint 2.

39
 Figure 21: Diagramme de classe du sprint 2

3.1.4. Réalisation

Dans cette partie nous présentons l’interface de tableau de bord, figure 22, et l’interface
de validation congé, figure 23.

40
Figure 22 : Interface de tableau de bord

Figure 23 : Interface de validation congé

41
4. Conclusion

Durant ce chapitre, nous avons présenté les deux releases de notre projet. Tout d’abord, nous
avons commencé par le premier release qui a été consacré pour la partie paramétrage. Nous
avons défini notre ligne de travail grâce au Backlog du sprint. Ensuite, nous avons fait l’analyse
détaillée de ce dernier pour aboutir enfin à l’étude conceptuelle et la réalisation de cette itération.
Le même travail a été effectué durant le deuxième release.

42
 Conclusion générale
Notre projet de spécialité encadré consiste à créer une application web de gestion des ressources
humaines pour la société GFI.
Pour réaliser ce travail, nous avons commencé par une analyse qui consiste à définir le
contexte général ainsi que la méthodologie du travail adopté. Ensuite, nous avons analysé et
spécifié les besoins fonctionnels et non fonctionnels, après avoir étudié l’existant, aux quels
devra répondre notre solution. Dans une étape suivante, nous avons présenté l’environnement
de travail, les outils et les technologies utilisés tout au long de notre projet. Puis, nous avons
détaillé notre conception à travers les diagrammes de cas d’utilisation, le diagramme de classe
et les diagrammes d’activité. Finalement, nous avons décrit notre application à travers des
captures d’écran.
Ce projet nous a permis d’approfondir nos connaissances théoriques, acquises tout le long de
notre formation, par la pratique des nouvelles technologies. Ce projet nous a permis de
maîtriser le langage de modélisation UML, le Framework Asp.Net Core et Angular ainsi que la
manipulation d’une base de données SQLServer.

43
 Références
[1] https://www.memoireonline.com/04/14/8816/Mise-en-place-d-un-nouveau-ERP--
Enterprise-Resource-Planning--Cas-de-la-societe-Bouchamaoui-ind.html
[2] https://www.gfi.world/fr-fr/

[3] J. Tabaka., La gestion de projet : methodes classiques vs methodes agiles. ACCESS-DEV.

Fev.2013. Adresse : http://www.access-dev.com/access-dev/lagestion-de-projet-methodesclassiques-vs-
methodes-agiles/.
[4] E.deCASI.(Novembre.2016).Lesméthodesagilessont-ellesunearnaque?
https://manurenaux.wp.imt.fr/2013/09/30/les-methodes-agiles-sontelles-une-arnaque/.
[5] igm.univ. (Mars 2015). Scrum : qu’est ce que c’est? http://www-
igm.univ-mlv.fr/~dr/XPOSE2008/SCRUM/presentation.php.
[6] F. Lothon, Guide de démarrage scrum. L’Agiliste. Jan. 2010. http://www.agiliste.fr/guide-
de-demarrage-scrum/.
[7] J.-P. Davalan., Suite de fibonacci mise en évidence. jm.davalan. Jan.
2002. http://jm.davalan.org/divers/fibonacci/f03.html.
[8] https://azure.microsoft.com/en-us/solutions/

[9] Télécharger SQL Server Management Studio (SSMS). Jan. 2017. https://msdn.microsoft.com/fr-
fr/library/mt238290.aspx.
[10] J.-P..,Un nouvel environnement de programmation pour android. Cellenza.2-janvier-
2014. http://blog.cellenza.com/evenements/asp-net-mvc-fromzero-to-hero/.

44
 Netographie
https://dev.azure.com/

https://www.gfi.world/fr-fr/

https://angular.io/

https://material.angular.io/components/categories

https://primefaces.org/primeng/#/

https://stackoverflow.com/

https://github.com/

45