Rapportdestagepfe 150814172635 Lva1 App6892

Mémoire de Projet de Fin d’Études
pour l’obtention du Titre
D’Ingénieur d’État en Informatique

Système d’information
Promotion 2010-2015
La mise en place d'une solution pour la

gestion des projets, gestion de ressources
humaines Sous la plateforme Odoo
M. DAMIR Ayoub
Soutenance le 20 Juin 2015
Membres de jury
M. TABII Youness Encadrant ENSATé
M. LAZAAR Mohammed Professeur
M. CHRAYAH Mohamed Professeur
Année universitaire 2014-2015

Gestion de projets et gestion des ressources humaines
2 École Nationale Des Sciences Appliquées De Tétouan 2015

Dédicace
A ma mère, qui m'a comblé de son soutien et m'a voué un amour
inconditionnel. Tu es pour moi un exemple de courage et de sacrifice
continu. Que cet humble travail témoigne mon affection, mon éternel
attachement et qu'il appelle sur moi ta continuelle bénédiction.
A mon père, Aucune dédicace ne saurait exprimer l’amour,

l’estime, le dévouement et le respect que j’ai toujours eu pour vous. Rien
au monde ne vaut les efforts fournis jour et nuit pour mon éducation et
mon bien être. Ce travail est le fruit de tes sacrifices que tu as consentis
pour mon éducation et ma formation.
A mes très chers frères, je vous remercie pour votre amour, votre
soutien et vos encouragements
A toutes ma famille, pour leurs soutiens, leurs conseils partagés
Au staff professoral de l’ENSA Tétouan, je serais vaniteux si je me

devais énumérer en ces quelques lignes vos remarquables qualités
humaines et professionnelles. Veuillez trouver ici l'expression et le
témoignage de ma gratitude ressentie
A tous mes chers amis, pour le soutien que vous m’aviez offert, je
vous dis MERCI
Au personnel administratif de l'ENSA Tétouan et à sa tête M.

Kamal Eddine ELKADIRI, de nous avoir préparé à atteindre ce stade
qui m’a permis de confronter la vie professionnelle à travers ce stage

Remerciement
Avant de commencer à rédiger mon rapport, je tiens à adresser

mes sincères remerciements aux personnes qui m'ont permis de mener
à bien mon travail par leurs sincères collaborations.
Je saisie cette occasion pour remercie Mr TABII Youness notre

professeur, qui par ses conseils judicieux et son suivi permanent du
travail, a su m'éclairer sur l'itinéraire à suivre pour arriver à bout de
ce travail.
J'adresse mes sincère remerciement à Mr HILALI Redwan, EL

BOUKHARI EL KHAMLICHI Mohammed Amine, et EL MAROUFI
Amine pour l’encadrement de ce travail, pour leurs conseils, leurs
critiques, leurs encouragements, leurs disponibilités ainsi que pour
m’avoir accueilli et donné les moyens pour accomplir ce stage dans les
meilleurs conditions.
Je n'oublie pas de remercier chaleureusement mes Parents et mes

frères et mes amis pour leurs soutiens.
Je tiens mes chaleureux remerciements, aux soldats de fond, et à

tous ceux qui ont contribué de près ou de loin à l'achèvement de ce
travail, à leur tête mes parents, mes professeurs et mes amis.

Résumé
Ce rapport décrit le travail que j’ai réalisé dans le cadre de l’obtention de mon
diplôme d’ingénieur d’état en Systèmes d’informations à l’Ecole Nationale des
Sciences Appliquées Tétouan, il s’est déroulé du 3 Mars au 05 juin 2015 effectué au
sein de la société 4D Logiciel Maroc à Rabat.
Durant les quatre mois, ma mission consiste à développer une application de

gestion de projet, et gestion des ressources humaines agile avec la plateforme Odoo
dans un cadre de développement agile.
L’application va permettre aux équipes de développement de collaborer sur

des projets pilotés selon la méthodologie agile Scrum et au département ressources
humaines de bien gérer ses collaborateurs. Le but de l’application est de faciliter le
pilotage des projets et la gestion des ressources humaines en offrant une version
numérique des nombreux artefacts de la méthode Scrum (Backlog, Histoires utilisateur,
Itérations, Taches, Taskboard, contrats etc.)
Ce rapport se propose de décrire les différentes étapes par lesquelles le projet

a passé dans le but d’atteindre la solution actuelle.

Abstract
This report describes the work I've done in the context of getting my state
engineering degree in Information Systems at the National School of Applied
Sciences Tetouan, it was held from March 3 to June 15, 2015 conducted within the
company 4D Software Morocco in Rabat.
During the four months, my mission is to develop a project management

application, and management of human resources with agile Odoo platform in an
agile development framework.
The application will allow development teams to collaborate on projects

managed by Scrum agile methodology and the Human Resources Department to
manage its employees. The purpose of the application is to facilitate the
management of human resources and management projects by providing a digital
version of many artifacts of this method (Backlog User Stories, Iterations, spots,
Taskboard, contracts, etc.)
This report is to describe the various stages that the project has passed in order
to achieve the current solution.

Table des matières

DEDICACE ............................................................................................................................................... 3
REMERCIEMENT....................................................................................................................................... 4
RESUME.................................................................................................................................................... 5
ABSTRACT................................................................................................................................................ 6
TABLE DES MATIERES............................................................................................................................... 7
LISTE DES FIGURES ................................................................................................................................... 9
LISTE DES TABLEAUX ............................................................................................................................. 12
LISTE DES ABREVIATIONS ..................................................................................................................... 13
INTRODUCTION GENERALE .................................................................................................................. 14
CHAPITRE 1 : PRESENTATION GENERALE DU PROJET ...................................................................... 15
1. STRUCTURE ET ORGANISATION DE 4D........................................................................................................ 16

1.1. Aperçu de 4D ...................................................................................................................... 16
1.2. L’architecture de l’entreprise ............................................................................................ 18
2. LA PLATEFORME ODOO........................................................................................................................... 19
2.1. Principales applications logicielles front office................................................................ 19
2.2. Principales applications logicielles back office .............................................................. 20
2.3. Modules d'Odoo ................................................................................................................. 20
2.4. Historique et notes des sorties ............................................................................................ 21
3. CONTEXTE GENERALE DU PROJET ............................................................................................................. 22
3.1. Etude de l’existant ............................................................................................................... 22
3.2. Problématique ..................................................................................................................... 25
3.3. La solution proposée ........................................................................................................... 26
3.4. Démarche et planification................................................................................................. 28
4. CONCLUSION ......................................................................................................................................... 28
CHAPITRE 2 : LA METHODE SCRUM ................................................................................................ 30
1. COMPARAISON DES PROCESSUS DE DEVELOPPEMENT................................................................................ 31

2. LE CHOIX DU PROCESSUS DE DEVELOPPEMENT ........................................................................................... 36
3. LA METHODE SCRUM ............................................................................................................................... 38
3.1 Approche agile .................................................................................................................... 38
3.2. Pourquoi Scrum ? ................................................................................................................ 39
4. PILOTAGE DU PROJET AVEC SCRUM ......................................................................................................... 40
4.1 Fonctionnement de Scrum ................................................................................................. 40
4.2. Outils Scrum .......................................................................................................................... 47
5. CONCLUSION ......................................................................................................................................... 49
CHAPITRE 3: TECHNOLOGIES UTILISES ................................................................................................ 50
1. EXIGENCE DU PROJET .............................................................................................................................. 51

1.1. Méthodologie de développement : La démarche MVC .............................................. 51
1.2. Pourquoi MVC ..................................................................................................................... 52
2. CHOIX DE LA TECHNOLOGIE .................................................................................................................... 53
2.1. Etude comparative entre les ERP existant sur le marché ............................... 53
2.2. La plateforme Odoo ........................................................................................................... 55
3. OUTILS UTILISES ........................................................................................................................................ 57

3.1. Outils de conception .......................................................................................................... 60
3.2. Outils de développement .................................................................................................. 60
4. CONCLUSION ......................................................................................................................................... 62
CHAPITRE 4: LES RELEASES DU PROJET SCRUM .................................................................................. 63
1. PREMIER RELEASE .................................................................................................................................... 64

1.1. Sprint 1 .................................................................................................................................. 64
1.2. Sprint 2 .................................................................................................................................. 73
1.3. print 3 ..................................................................................................................................... 80
2. DEUXIEME RELEASE.................................................................................................................................. 88
2.1. Sprint 4 .................................................................................................................................. 88
2.2. Sprint 5 .................................................................................................................................. 94
2.3. Sprint 6 ................................................................................................................................ 100
CONCLUSION GENERALE ET PERSPECTIVE ....................................................................................... 106
BIBLIOGRAPHIE ET WEBOGRAPHIE .................................................................................................... 107

Liste des figures

Figure 1: Logo du produit 4D v13 ......................................................................................... 17
Figure 2: Logo de 4D logiciels............................................................................................... 17
Figure 3: Logo du produit Wakanda ................................................................................... 17
Figure 4: Filiales, représentants et distributeurs locaux de 4D (source réf 1) ................. 18
Figure 5: L’organigramme de l’entreprise « 4D logiciels » ................................................ 18
Figure 6: L'historique des versions d’Odoo ......................................................................... 22
Tableau 7: Comité de pilotage du projet .......................................................................... 28
Tableau 8 : Comité du projet ............................................................................................... 28
Tableau 9: Tableau comparative des différents cycles de vie ....................................... 36
Tableau 10: Comparaison des méthodologies de développement [Sutherland] ...... 38
Tableau 11: Les différents roles dans la méthode Scrum ................................................. 41
Figure 12: Le processus du Framework Scrum ................................................................... 41
Tableau 13: Le Backlog du projet ........................................................................................ 44
Figure 14: Des cartes de planning poker ............................................................................ 45
Figure 15: Les releases du projet .......................................................................................... 47
Figure 16 : Exemple de Taskboard....................................................................................... 48
Figure 17: Le Burndown Chart du 4ème Sprint .................................................................. 48
Figure 18: Architecture MVC ................................................................................................ 52
Figure 19: Intérêt de recherche odoo/openerp/tinyerp.................................................. 53
Figure 20: Intérêt de recherche odoo/netsuite/xtuple/compiere.................................. 54
Figure 21: Nombre de résultats sur le nombre de recherche Google pour odoo ....... 54
Figure 22: Nombre de résultats sur le nombre de recherche Google pour sap........... 55
Figure 23: L'architecture de deploiment Odoo ................................................................. 56
Figure 24: Single server, multi-process ................................................................................. 57
Figure 25: multi server; multi process ................................................................................... 57
Figure 32 : Diagramme de cas d’utilisation d’un utilisateur – Sprint 1 ............................ 67
Figure 33: Diagramme de cas d'utilisation du Manager – Sprint 1 ................................. 67
Figure 34: Diagramme de cas d'utilisation de l’administrateur – Sprint 1 ...................... 67
Figure 35: Diagramme de séquence de la gestion des projets ...................................... 68
Figure 36 : Diagramme de séquence du cas d'utilisation : gestion des permissions ... 69
Figure 37: Diagramme de classes sprint1 ........................................................................... 71
Figure 38: Gestion des projets .............................................................................................. 72

Figure 39 : Diagramme de cas d’utilisation du Manager - Sprint 2 ................................ 74

Figure 40: Diagramme de séquence de la gestion des projets ...................................... 75
Figure 41 : Diagramme de séquence du cas d'utilisation : Définir la vélocité .............. 76
Figure 42: Diagramme de classes sprint 2 .......................................................................... 77
Figure 43: Gestion des Sprints ............................................................................................... 78
Figure 44: Gestion du Backlog ............................................................................................. 79
Figure 45 : Diagramme de cas d’utilisation du Manager ................................................ 81
Figure 46 : Diagramme de cas d’utilisation du Développeur ......................................... 81
Figure 47: Diagramme de séquence de la gestion des Taches ..................................... 82
Figure 48: Diagramme de classes sprint3 ........................................................................... 83
Figure 49: La gestion des taches ......................................................................................... 84
Figure 50: L’ajout des membres de l’équipe ..................................................................... 84
Figure 51 : L’affectation de la tache .................................................................................. 85
Figure 52 : L’affichage du BurndownChart ........................................................................ 85
Figure 53 : Le BurndownChart .............................................................................................. 86
Figure 54 : Ajouter un sujet de stage ................................................................................... 86
Figure 55: Gestion du taskboard .......................................................................................... 87
Figure 56 : Diagramme de cas d’utilisation du Manager .............................................. 89
Figure 57 : Diagramme de cas d’utilisation de l’employé ............................................... 89
Figure 58: Diagramme de séquence de la gestion des Taches ..................................... 90
Figure 59: Diagramme de classes sprint 4 : Gestion de congés ..................................... 91
Figure 60: Gestion des congés ............................................................................................. 92
Figure 61: La validation des demandes de congés ......................................................... 92
Figure 62: L’inscription ........................................................................................................... 93
Figure 63 : Diagramme de cas d’utilisation du Développeur ......................................... 96
Figure 65 : Diagramme de cas d’utilisation de l’administrateur ..................................... 96
Figure 66: Diagramme de séquence du pointage de l’employé .................................. 97
Figure 67: Le pointage entrée/sortie ................................................................................... 98
Figure 68: Les templates des contrats clients ..................................................................... 99
Figure 69 : Diagramme de cas d’utilisation du Manager .............................................. 101
Figure 70 : Diagramme de cas d’utilisation du Développeur ....................................... 101
Figure 71: Diagramme de séquence de la gestion des Taches ................................... 102
Figure 72: Diagramme de classes sprint3 ......................................................................... 103
Figure 73: La création de la facture .................................................................................. 104

Figure 74: Les heures prestées d’une tache..................................................................... 105

Liste des tableaux

Tableau 1 : Comité de pilotage du projet ......................................................................... 28
Tableau 2 : Comité du projet ............................................................................................... 28
Tableau 3 : Tableau comparative des différents cycles de vie ...................................... 36
Tableau 4 : Comparaison des méthodologies de développement [Sutherland] ....... 38
Tableau 5 : Les différents roles dans la méthode Scrum .................................................. 41
Tableau 6 : Déscription des cas d’utilisation……….……….....…………………………….33

Liste des abréviations

Abréviation Désignation
4D 4th Dimension
UML Unified Modeling Language
API Application Programming Interface
HTML Hypertext Markup Language
Ajax Asynchronous JavaScript and XML
MVC Model Controller View
DAO Data Access Object
IDE Integrated Development Environ ment
ORM Object Relational Mapping
SQL Standard Query Language
SGBD Système de Gestion de Base Données
AGPL Affero General Public License
CRM customer relationship management
SRM supplier relationship management
CMS Content management system
RH Ressources Humaines
PDV Point de vente

Introduction Générale
Les entreprises en développement logiciel sont en croissance constante
et poursuivent le but de livrer du logiciel de qualité qui répond au besoin de
l’utilisateur, dans les temps prescrits par le client. Afin de répondre à ces
critères, les entreprises doivent utiliser des processus de développements
logiciel stricts. Il y a plusieurs processus disponibles qui apportent leurs
avantages et leurs inconvénients. Depuis quelques années, l’utilisation de la
méthodologie SCRUM semble gagner en popularité, mais peu d’entreprises s’y
aventurent.
SCRUM présente une solution intéressante pour les grandes entreprises
qui aimeraient gagner en flexibilité. En utilisant une méthode évolutive de
développement qui implique une plus grande participation du client dans le
processus de développement, les deux parties voient leurs chances de succès
augmentées proportionnellement à la qualité de leurs communications et de
leurs relations. En utilisant la méthodologie SCRUM dans les grandes entreprises,
la qualité du logiciel est accrue et les nouveaux besoins commandés par la
réalité changeante du client sont considérés tout au long du processus. Une
synergie qui gagnerait à être reconnue.
Mon projet de fin d’étude consiste à mettre en place une application
de gestion de projet SCRUM en utilisant la plateforme Odoo de
développement.
Ce rapport est structuré comme suit : Le premier chapitre présente le
contexte général du projet, le produit Odoo ainsi que les objectifs généraux de
ce projet. Nous allons consacrer la seconde à présenter le cadre de
développement agile dans lequel j’ai pu travailler. Cette partie permettra de
se familiariser avec la méthodologie SCRUM et son vocabulaire particulier. La
troisième partie exposera le projet, enfin la dernière partie présentera les
technologies et les logiciels dont nous avons pu nous servir durant cette mission
ainsi le travail réalisé durant chacune des itérations du projet.

Chapitre 1 : Présentation générale du projet
I- Présentation de l’organisme d’accueil

II- Contexte générale du projet
III- Conclusion

Le contexte général du projet est une étape primordiale pour la

connaissance de l’environnement dans lequel s’est déroulé le stage de fin
d’études ainsi que la présentation du projet. Ce chapitre sera consacré tout
d’abord à la présentation de l’entreprise 4D au sein duquel j’ai effectué mon
projet.
Et par la suite une présentation de contexte générale du projet que m’a

confié 4D comme projet de fin d’études. Cette présentation inclura une étude
de l’existant, l’évocation des problématiques que j’avais à traiter, la solution
que j’ai proposée et le planning que j’avais suivi pour la réalisation de ce projet.
1. Structure et organisation de 4D
1.1. Aperçu de 4D
D’un capital de 2 millions d’euros et dont le siège social se situe à Clichy

(Ile de France), la société détenue majoritairement par son fondateur ne
regroupe pas moins de 180 collaborateurs répartis à travers le monde au sein
de ses filiales internationales. La société 4D est en effet présente aux Etats-Unis,
au Japon, en Grande-Bretagne, en Allemagne, en Suède, en Espagne ainsi
qu’en Australie. Sa présence à travers le monde est renforcée par son réseau
de distribution implanté dans plus de 40 pays.
Créée en 1984, « 4D » se distingue sur le marché informatique en

introduisant le premier système de gestion de bases de données relationnelles
graphique dénommé « 4D ». Le produit continue son évolution pour proposer
en 1987 :
 un client-serveur intégré
 un serveur Web intégré
 un système de partage d'applications dynamiques intégré

En 1997, « 4D » investit dans Internet en intégrant un serveur Web

dynamique, permettant aux développeurs de servir à la fois des applications
client-serveur et des applications Web sans aucune modification de code.
Figure 3: Logo du produit 4D v13 Figure 1: Logo du produit Wakanda Figure 2: Logo de 4D logiciels
En 2004, « 4D » devient le premier produit permettant aux développeurs

de créer à la fois des applications autonomes, client-serveur, ainsi que des
applications orientées Services (SOA) et Web sans aucune modification de
code. Plus récemment, « 4D » a créé la première plateforme de
développement « end-to-end » JavaScript permettant de créer des
applications professionnelles avec la gamme de produits «Wakanda».
La philosophie de « 4D » est la suivante : simplifier ce qui était auparavant

complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les
niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession
faible.
4D compte plus de huit filiales à l’international et de nombreux

distributeurs et représentants locaux dont « 4D Logiciels Maroc » fait partie. Les
métiers présents à « 4D Logiciels Maroc » sont similaires voir identique à ceux de
la filiale en France, et ce, allant du Support Technique et Développement
jusqu’au Contrôle Qualité pour les deux produits « Wakanda » et « 4D ».
La philosophie de 4D est la suivante : simplifier ce qui était auparavant

complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les
niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession
faible. 4D offre également des fonctionnalités basées sur les nouvelles

technologies les plus populaires, tout en conservant un niveau de compatibilité

ascendante qui permet de pérenniser les investissements des clients.
Figure 4: Filiales, représentants et distributeurs locaux de 4D (source réf 1)
1.2. L’architecture de l’entreprise

La figure ci-dessous représente l’organigramme de l’entreprise « 4D logiciels ».
Figure 5: L’organigramme de l’entreprise « 4D logiciels »

2. La plateforme Odoo
Odoo est un progiciel de gestion d'entreprise (ERP) destiné à intégrer
l'ensemble des données opérationnelles et de gestion de l'entreprise dans une
base de données unique, accessible par une interface web.
Cette base de données centrale est associée à une couche

fonctionnelle très innovante qui met en relation des informations d'origines
diverses et assure un déroulement efficace des processus transversaux de
création de valeur ajoutée de l'entreprise.
Odoo, anciennement OpenERP et Tiny ERP, est à la base un progiciel

libre de gestion intégré comprenant de très nombreux modules permettant de
simplifier la gestion d’entreprise dans son ensemble. Le logiciel est sous licence
AGPL et est utilisé par plus de 2 millions d’utilisateurs à travers le monde.
À l’origine un ERP, le logiciel s’est vu étendre ses fonctionnalités à des

applications de front office (CMS, e-Commerce, Blogs, Forums, News,
Événements, LiveChat, Job offers, etc). Il apporte les applications métier dont
chacun a besoin dans l'entreprise.Cette approche modulaire facilite
l'intégration de nouvelles fonctionnalités sous la forme de modules
complémentaires.
2.1. Principales applications logicielles front office

 Créateur de site web et système de gestion de son
contenu, CMS
 Vente en ligne, Ecommerce
 Interface de point de vente (PDV)

2.2. Principales applications logicielles back office

 Gestion de relation clients (CRM & SRM)
 Gestion des ventes
 Gestion de production
 Gestion de projets
 Gestion des stocks
 Gestion des ressources humaines
 Gestion des achats
 Gestion logistique
 Gestion de manufactures
 Gestion comptable
 Gestion des dépenses
 Gestion des documents
 Générateur de factures
 Gestion et outils marketing
2.3. Modules d'Odoo

L’aspect libre du logiciel a permis le développement de nombreux
modules tiers créés par sa communauté de développeurs. Ces applications
sont pour certaines officiellement validées par l’éditeur tandis que d’autres ne
sont destinées qu’à des versions spécifiques.
 Architecture logicielle
La conception d'Odoo est orientée par une architecture MVC, des flux
de travail flexibles, une interface-utilisateur graphique dynamique, une
interface de communication interne XML-RPC, et un système personnalisable
de comptes-rendus.
D’un point de vue de l’architecture technique, Odoo est construit autour

de trois composants principaux qui communiquent entre eux par les
protocoles XML-RPC et NET-RPC :

 Le serveur odoo-server qui stocke ses données dans une base

PostgreSQL ;
 Le client odoo-client qui s'installe sur le poste de l'utilisateur
(abandonné depuis la v7) ;
 Le serveur web odoo-web qui permet une utilisation depuis un
navigateur.
Le logiciel compte 260 modules officiels et 4000 modules communautaires.
2.4. Historique et notes des sorties

Le 20 janvier 2011, OpenERP SA annonçait le lancement de la version
6.0 du logiciel, qui comprend une version à la demande (SaaS). Son
approche modulaire permet aux utilisateurs de commencer avec une
application, puis d'ajouter d'autres modules selon leurs besoins.
En décembre 2012, la version 7.0 d'OpenERP est lancée et peut être

testée en ligne, téléchargée ou vue en version de démonstration. Mai 2014:
OpenERP change de nom et devient Odoo.
Eté 2014, Odoo lance la version 8. Cette version enrichit principalement le

logiciel de nouvelles applications qui font d’Odoo un logiciel allant au-delà
d'un ERP. Ces applications sont: Marketing (gestion d'événements,
d'enquêtes de satisfactions, campagnes de mails auprès de la CRM,...), CMS
(construction d'un site internet - front-end lié au back-end - grâce au
déplacement rapide et simple de 'blocs" d'éditions), e-commerce
(application pour vente en ligne),...
 Première version stable : 2004

 Version stable actuelle : 8.0
 Version avancée : 9.0

Anciennes versions ou fin de maintenance

Anciennes versions avec maintenance étendue
Version actuelle
Versions en cours de développement
Figure 6: L'historique des versions d’Odoo

3. Contexte générale du projet
3.1. Etude de l’existant
3.1.1. Préambule
Le but de l’étude de l’existant est de déterminer les points faibles et les
points forts d’un produit actuel pour pouvoir déterminer les besoins du client,
en vue d’en prendre en considération lors de la conception et la réalisation de
la solution. Dans cette section, nous présentons une analyse des modules
proposée par la communauté Odoo, et du logiciel Jira. Ensuite, nous
formulerons une solution de la problématique.

3.1.2. Jira
Description
Site web http://www.atlassian.com/fr/software/jira/overview
Prix Entre 12 000$ et 24 000$
Avantages JIRA permet de tout faire. Il existe des centaines de plugins à

ajouter qui vous permettront, si vous trouvez qu’il manque
quelque chose, de le rajouter en quelques clics. De plus il est
largement utilisé par le monde (La fondation Apache, Skype,
Zend Framework, etc.) et son coût est dérisoire pour les
petites équipes.
Inconvénients Trop complexe. La prise en main demandera du temps. Et si
on souhaite mettre les mains dans le cambouis (modifier le
workflow par exemple), cela demandera encore plus de
temps. Il y a aussi, et son cout reste cher pour les équipes qui
ont un nombre important de collaborateur par rapport aux
autres produits qui se trouve sur le marché
Tableau 7: Tableau descriptive du produit JIRA
correspond aux attentes de plusieurs utilisateurs. Mais il reste

limité devant les besoins de 4D comme l’exploitation des données de
production dans les rapports et la gestion de ressources humaines, et donc 4D
sent qu’il est dispersé puisqu’il doit utiliser aux moins deux solution pour
répondre à ses besoins, gestion de projets et gestion de ressources humaines.
3.1.3. La gestion de projets standards sous la plateforme

Odoo
Permet la gestion de projets ainsi que les taches de chaque projet en allant
jusqu’au niveau le plus détaillé, Ce module permet de :
 Définir des projets / tâches associés à un responsable

 Suivre chaque tâche / projet selon son avancement : formulaire, Gantt
 Générer la facturation conditionnelle, selon l'avancement

 Gérer la relation avancement / temps passé (feuilles de saisie des

heures)
 Assurer un suivi budgétaire analytique du projet, associé à la
comptabilité analytique…
Un projet contient des informations générales, reliées à la comptabilité

analytique, au partenaire, etc. Ce sont les tâches qui font le projet. Chaque
tâche peut être constituée de plusieurs étapes.
Ce module offre plusieurs fonctionnalités pour les entreprises dans différents

secteur
i. Les avantages du module standard de Odoo

Odoo Project Management permet de définir des projets / tâches associés
à un responsable Suivre chaque tâche / projet selon son avancement :
formulaire, Gantt…, générer la facturation conditionnelle selon l'avancement,
gérer la relation avancement / temps passé (feuilles de saisie des heures), et
assurer un suivi budgétaire analytique du projet, associé à la comptabilité
analytique...
Les fonctionnalités présentées ne sont ni exhaustives, ni figées. Un des

atouts de l'offre OpenERP / Odoo est son ADAPTABILITE à la diversité des
besoins des entreprises.
La gestion de projet dans OpenERP / Odoo repose sur les concepts suivants :
Un project template est un modèle qui permet de générer un projet (un

projet peut aussi être converti en template) Ce projet se compose de tâches
qui vont être accomplies en exécutant des travaux. Lorsque qu'une tâche est
terminée, les travaux qui ont été inscrits dans cette tâche sont transférés dans
la timesheet (feuille de temps) du collaborateur, lorsque le collaborateur valide
sa timesheet, ses travaux sont transférés dans la comptabilité analytique et
peuvent générer une facturation.

Un projet contient des informations générales, reliées à la comptabilité

analytique, au partenaire, etc. Ce sont les tâches qui font le projet. Chaque
tâche peut être constituée de plusieurs étapes.
Le planificateur vous aide à planifier les tâches et étapes, en fonction de la

disponibilité de vos ressources. Il est possible d'échanger des e-mails liés à votre
projet, pour communiquer avec votre équipe, les clients et les fournisseurs. Un
outil collaboratif permet d'échanger et de partager les tâches avec les clients.
Vous pourrez suivre les problèmes, demandes d'assistance, questions sur les
projets tout en surveillant votre qualité de service.
ii. Les inconvénients du module standard de gestion de projets

Parmi ces limites c’est qu’il ne supporte pas la méthode Scrum avec toutes
ses notions (User story, Sprint …), il y a aussi la complexité du module Odoo qui
ne facilite pas la tâche pour l’utilisateur.
3.2. Problématique
D’après ce que nous avons vu, parmi les problèmes que nous pouvons citer
c’est :
 Perte du temps
Surtout il n’y a pas de coordination entre l’équipe et les ressources

humaines pour bien gérer le temps, et ne pas être dispersé.
 Perte d’argent
Pour que la société peut satisfaire ses besoins il doit avoir au moins 2
solutions
 Inefficacité :
Tant qu’il n y a pas une solution qui inclut la gestion de ressources humaines
et la gestion de projets alors les indicateurs ne seront plus représentative du
rendement réel des membres de chaque équipe, ce qui implique une
inefficacité de la solution.

 Perte d’opportunités
Une mal gestion peut conduire à la perte des projets, et par conséquent
la perte du client.
 Exploitation des données de production
La société ne peut pas exploiter ses données de production pour avoir

des indicateurs de la réalité et qui soient représentatives, par exemple définir
le rendement de chaque employé
 La démotivation
La démotivation des employés qui vont souffrir de la routine du travail
3.3. La solution proposée

Le projet a déroulé sur deux phases:
 Le premier release était consacrée pour la formation sur la
méthode agile SCRUM et sur la plateforme de développement
Odoo, et au réalisation de l’ensemble des fonctionnalités du
module de gestion de projets.
 Le deuxième release était dédiée au développement de

l’ensemble des fonctionnalités demandés pour la gestion de
ressources humaines et faire la liaison entre les différents modules.
Dans le cadre de développement de ce projet, on a travaillé avec la
méthode SCRUM.
L’utilisation de la méthodologie SCRUM semble être le mieux car le projet
pourra subir de nombreuses modifications durant le développement, et pour
avoir plus de métier sur le projet (c.-à-d. on va travailler dans un cadre de
développement agile SCRUM pour développer un outil SCRUM).
3.3.1 Principe de la solution

Pour résoudre les problèmes liés à la gestion des projets, On a proposé de
développer une solution qui permet la gestion des projets en offrant une
interface ergonomique et dynamique, et qui intègre toutes les composants de

la méthode SCRUM pour exploiter les résultats dans la gestion de ressources

humaines et de facturation en fin visualiser les statistiques voulus concernant la
chaine de production.
3.3.2. Objectifs de la solution

Les grandes entreprises en développement logiciel sont en croissance
constantes et poursuivent le but de livrer du logiciel de qualité qui répond au
besoin de l’utilisateur, dans les temps prescrits par le client. La problématique
de celles-ci réside en l’utilisation des méthodes de développement
traditionnelles qui ne satisfont plus entièrement aux besoins grandissants de
qualité.
SCRUM présente une solution intéressante pour les grandes entreprises qui
aimeraient gagner en flexibilité. En utilisant une méthode évolutive de
développement qui implique une plus grande participation du client dans le
processus de développement, les deux parties voient leurs chances de succès
augmentées proportionnellement à la qualité de leurs communications et de
leurs relations. En utilisant la méthodologie SCRUM dans les grandes entreprises,
la qualité du logiciel est accrue et les nouveaux besoins commandés par la
réalité changeante du client sont considérés tout au long du processus. Une
synergie qui gagnerait à être reconnue.
L’entreprise 4D parmi plusieurs grandes entreprises a commencé de

travailler avec la méthodologie SCRUM afin de livrer des produits de qualités
qui répondent aux besoins des clients.
L’objectif principal de mon projet de fin d’étude est de rendre un produit

qui va faciliter le pilotage des projets réalisés par la méthode SCRUM agile,
aussi la gestion de ressources humaines et de facturation au sein de
l’entreprise. Le développement de l’application va être conçu par la solution
Odoo (présenter dans la partie précédente).

3.4. Démarche et planification

3.4.1. Comité de pilotage du projet
Personne Role Function

M. Redouane - Pilotage du projet (4D) Chef de service
EL HILALI - Scrum Master
M. Amine EL - Product owne (4D) Ingénieur

MAROUFI - Spécification fonctionnels
M. Amine EL - Product owner Ingénieur
BOUKHARI EL - Spécifications Techniques
KHAMLICHI
Tableau1: Comité de pilotage du projet
Ce tableau résume les différents membres de l’équipe de pilotage du projet
Personne Role Function

M. DAMIR - Participation aux Spécifications Elève Ingénieur
Ayyoub techniques et fonctionnels System
- conception et codage de la d’information
solution Ecole Nationale des
- Tests et mise en place de la solution Sciences Appliquées
de Tétouan
Tableau 2 : Comité du projet
Ce tableau résume les différents membres de l’équipe des participants au

développement du projet
4. Conclusion
Dans ce chapitre qui présente le contexte général du projet, on a inauguré
le chapitre par une présentation de l’organisme d’accueil 4D, dans la
deuxième partie du chapitre on a présenté le contexte générale du projet en
commençant par une étude de l’existant, puis on a évoqués les

problématiques à traiter, après on a passé à la solution qu’on avait proposée

pour la résolution des problématiques. Et vers la fin de cette partie on a évoqué
la démarche que nous avions suivie pendant la résolution du projet ainsi que
la planification de ce dernier. Le chapitre suivant est consacré pour la
méthode Scrum.

Chapitre 2 : La méthode Scrum
I- Comparaison des processus de

développement
II- Choix du processus de
développement
III- La méthode Scrum
IV- Pilotage du projet avec Scrum
V- Conclusion

1. Comparaison des processus de développement

Le bon choix du processus de développement logiciel conduit à la
bonne réalisation du projet, c’est pour cette raison nous avons fait référence à
une comparaison entre les principaux processus de développement, pour
pouvoir choisir le meilleur processus correspondant à notre cas
CYCLE DE VIE FORCES FAIBLESSES QUAND UTILISER

CASCADE • Facile à •Donne une fausse • La phase de
(WATERFALLS) comprendre et à impression de spécification a
utiliser l’avancée des été très bien
• Adapté pour une travaux faite
équipe • Pas d’interaction • La définition du
inexpérimentée entre les phases de produit est
• Les limites de développement stable
chaque étape • L’intégration n’a • Il s’agit d’une
sont visibles lieu qu’à la fin du nouvelle version
• Facilite un cycle d’un produit
management du existant
projet • Le client peut se • L’implantation
retrouver non d’un produit
• La définition des satisfait existant sur une
besoins est non- • Pas de retour en nouvelle plate-
évolutive arrière d’une forme
phase à l’autre • Une bonne
• La qualité prime maîtrise de la
sur le coût technologie
EN V • Les
• Facile à utiliser • Une mauvaise spécifications
prise en compte de besoins
des évènements doivent être
• Les tests sont concurrents bien faites
effectués à • La solution à
chaque étape • Le processus n’est développer et la
pas itératif technologie à

utiliser doivent
• Le contrôle se fait • Une mauvaise être
progressivement à prise en compte parfaitement
chaque étape des changements connues
de la spécification • Les
des besoins changements
• Les phases de doivent être faits
validation sont • Ne contient pas avant l’analyse
prises en main très les activités • Excellent pour
tôt dans le d’analyses de les systèmes
processus de risques requérant une
développement grande sûreté
EN SPIRALE • Sans coût élevé, • les coûts et
donne des • Le temps l’évaluation des
indications sur les consacré à risques est
risques majeurs l’évaluation des important
• Les fonctions risques est trop • pour des projets
critiques à haut élevé pour des à risque au
risque sont petits projets moins
développées en • Le temps mis à moyennement
premier lieu planifier, évaluer élevé
• La conception ne les risques, fixer les • pour des projets
doit pas forcément objectifs, les à long terme
être terminée prototypes peut dont les
• Les utilisateurs être excessif financements
finaux sont • Ce modèle est peuvent varier
intimement complexe • les utilisateurs ne
associés à toutes • Une expertise en définissent pas
les étapes du évaluation des clairement leurs
développement risques est besoins
• Le nécessaire • la spécification
développement • La spirale peut des besoins est
se fait en être infinie complexe

interaction avec • les développeurs • il s’agit d’une

les clients travaillent par nouvelle
• L’évolution du intermittence gamme de
coût de • il est difficile de produits
développement définir les objectifs • des
est sous contrôle et les points de changements
• Les utilisateurs ont validation significatifs
dès le départ une intermédiaires peuvent
vue globale du entre les intervenir à
système différentes étapes cause par
exemple de
l’évolution de la
recherche ou de
l’exploration
PAR • les coûts et

INCREMENT • Le client peut l’évaluation des
valider chaque risques est
étape du important
processus • pour des projets
à risque au
• Utilise la méthode • Requière une moins
Diviser Pour Régner bonne moyennement
planification et une élevé
bonne conception • pour des projets
• La délivrance du à long terme
produit est rapide dont les
financements
peuvent varier
• Le coût de • les utilisateurs ne
lancement du • Requière la définissent pas
projet est moindre définition clairement leurs
complète des besoins
fonctionnalités du

• Un produit système pour une • la spécification

exploitable peut définition des des besoins est
être délivré à tout différents complexe
moment incréments • il s’agit d’une
nouvelle
gamme de
• Les clients produits
obtiennent les • des
fonctionnalités changements
majeures du significatifs
système très tôt • Le coût total du peuvent
développement intervenir à
du système n’est cause par
• Le risque du pas négligeable exemple de
changement des l’évolution de la
besoins est minimal recherche ou de
l’exploration
• Sur un projet
• Développe les • Les différentes utilisant de
fonctions interfaces doivent nouvelles
primordiales dès le être bien définies technologies
départ • Sur des projets
ayant une durée
de
développement
assez longue
Scrum • Scrum est centrée • Projets Scrum sans •Pour les
sur le produit Product owner organisations
•Progrès est actif et sans orientées
incrémental, acteurs produit, Scrum
facilement économiques est un moyen de
mesurable et engagés sera révolutionner la
clairement visible probablement méthode dont ils
fiasco traitent ses

pour les acteurs • Si le propriétaire du affaires.

économiques produit n'a pas Autrement dit,
• Les développeurs apprécié Scrum, c’est pour
fixeront le rythme, ne ou ne comprend augmenter la
sont pas surchargés pas le rôle du productivité et à
de travail, et propriétaire de inspirer un
bénéficient d'un rôle produit, le succès engagement;
accru est plus difficile; •Scrum dispose
• La charge du • Si le product owner du progrès
travail est réglable, ne fonctionne pas tangibles réalisés
basé sur la avec les parties par le biais
capacité de prenantes de fréquents, les
l’équipe et la rendre le backlog versions de
priorité des taches complet avec production
à réaliser toutes les incrémentales
•Les questions sont fonctionnalités, les (Sprints). En tant
généralement développeurs se que tel, il est
découvertes complaisant et idéal pour les
avant qu'ils ne désengagé sorte start-ups en
deviennent que la productivité essayant
endémiques descend d'attirer et de
• L’équipe a • Si le propriétaire du maintenir
l’autorité de produit ne se
prendre des présente pas ou
décisions apprécier dette
• L’équipe est technique
encouragée à articulée par
«consulter» avec l'équipe, des
les entreprises problèmes
Les tâches ont techniques
tendance à être peuvent se
granulaire, et par suppurer
conséquent, plus • Si les développeurs
ne pas co-localisé

facilement ou à portée de voix

testables du client et
• L’équipe d'affaires, la
développe une productivité va en
attitude get-it- souffrir
done • Siloing de la
L’équipe est connaissance peut
implicitement croître si Scrum-
encouragée à se Master n’est pas
comporter attentif et l’équipe
comme une start- ne corrige pas
up et l'approche eux-mêmes
défie les normes • Rétrospectives de
organisationnelles. sprint sont inutiles si
l'équipe est pas
franche et
constructive
autocritique; et
L'approche défie les
normes
organisationnelles.
Tableau 3: Tableau comparative des différents cycles de vie
Source : http://patjo82.over-blog.com/article-etude-comparee-des-differents-
cycles-de-vie-de-logiciels-111005786.html , http://www.bobtuse.com/2009/01/whats-
swot-on-scrum.html
2. Le choix du processus de développement

En faisant liaison entre tableau comparatif et mon projet, le choix de
Scrum comme une méthodologie de pilotage pour ce projet s’est basé sur les
atouts de ce dernier. Il se résumé comme suit:
Plus de souplesse et de réactivité
La grande capacité d’adaptation au changement grâce à des itérations

courtes

Et la chose plus importante, c’est que Scrum rassemble les deux cotés
théorique et pratique et se rapproche beaucoup de la réalité

Les besoins de mon projet sont bien définit dès le départ
La nature de cette méthode qui est bien organisé et permet de tester et
valider chaque partie du projet avant de passer à une autre
l’utilisateur qui sera impliqué dans le développement (Product owner)
Cascade Spirale Itératif Spirale
Processus défini Requis Requis Requis Planificatio
n et fin
de projet
seulement
Produit final Déterminé durant la Déterminé Défini durant Défini
planification durant la le projet durant le
planification projet
Coût du projet Déterminé Partiellement Défini durant Défini
durant la Variable le projet durant le
Date de fin de Déterminé Partiellement Défini durant Défini
Projet durant la Variable le projet durant le
Adaptable à Planification Planification À la fin de En tout
l’environnement seulement Seulement chaque temps
itération
Flexibilité et Limité – approche Limité –approche Limité – Illimité
créativité de livre de recettes livre de recettes approche durant les
l’équipe livre de itérations
recettes
Transfert de Formation avant Formation avant Formation Formation
Connaissance le début du projet le début du avant le entre les
projet début membres
du projet de
l’équipe
durant le

Projet
Probabilité de Faible Moyen à faible Moyen Élevé

Succès
Tableau 4: Comparaison des méthodologies de développement [Sutherland]
3. La méthode Scrum
Comme pour toutes les fabrications, il est important d’avoir un procédé
de fabrication du logiciel bien défini et explicitement décrit et documenté.
Les modèles de cycle de vie du logiciel décrivent à un niveau très abstrait et
idéalisé les différentes manières d’organiser la production. Les étapes, leur
ordonnancement, et parfois les critères pour passer d’une étape à une autre.
3.1 Approche agile

Depuis une quinzaine d’années, la majorité des développements de
logiciels s’appuie sur des méthodes dites “agiles”. Sous cette bannière se
regroupent plusieurs méthodes basées sur un développement itératif et
incrémental, dans lequel la recherche de solutions aux problèmes rencontrés
s’appuie sur la collaboration de pair à pair. Elle promeut des réponses rapides
et flexibles, une planification des tâches adaptatives dans des laps de temps
très courts permettant une très grande réactivité.
Les approches plus classiques tels que cycle en V ou le modèle en

cascade sont souvent mises en œuvre pour les projets répondant à un
imposant cahier des charges. Le client et le prestataire s’entendent alors sur un
contrat et si le projet prend du retard ou ne répond pas à tous les besoins à la
date butoir, des pénalités sont alors facturées au prestataire. De la même
manière si le client s’aperçoit en cours de route que certains besoins ont été
omis dans le cahier des charges, il devra alors renégocier avec le prestataire
le contrat.

Les premières méthodes agiles apparues sont EVO (Evolutionary Project

Management) (1976), RAD (développement rapide d'applications) (1991), puis
DSDM, la version anglaise du RAD (1995). Les trois méthodes agiles désormais
les plus utilisées sont : la méthode Kanban, issue de la méthode industrielle
Lean, la méthode Scrum publiée en 2001 par Ken Schwaber et Jeff Sutherland,
et la méthode XP (Extreme programming) publiée en 1999 par Kent Beck.
3.2. Pourquoi Scrum ?

On propose maintenant de zoomer sur l’une des méthodes Agile
existantes afin de vous montrer plus concrètement le fonctionnement.
Pourquoi traiter de Scrum en particulier ? Tout simplement parce que Scrum est
de très loin la méthodologie la plus utilisée parmi les méthodes Agile existantes.
Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs,
formations, vidéos, associations, conférences traitant de Scrum ne manquent
pas et bon nombre de ces ressources sont accessibles gratuitement. On
pourrait pratiquement parler d’un standard Agile. Un autre atout important :
Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.
Les experts de Scrum, même ses fondateurs, le décrivent comme un «

cadre de travail permettant de répondre à des problèmes complexes et
changeants tout en livrant de manière productive et créative des produits de
la plus grande valeur possible » Scrum propose un modèle de contrôle de
processus basé sur l'empirisme. Il s'appuie sur trois piliers.
La transparence : Scrum met l'accent sur le fait d'avoir un langage commun
entre l'équipe et le management, qui doit permettre à tout observateur
d'obtenir rapidement une bonne compréhension du projet.
L'inspection : Scrum propose de faire le point sur les différents artéfacts

produits à intervalle régulier, afin de détecter toute variation indésirable.
L'adaptation : Si une dérive est constatée pendant l'inspection, le processus

doit alors être adapté. Scrum fournit des rituels, durant lesquels cette
adaptation est possible. Il s'agit de sprint planning, de daily scrum, et de sprint
review qu’ va détailler dans la section suivante.
4. Pilotage du projet avec Scrum

Commençons tout d’abord par présenter la méthode dans sa globalité
afin de se familiariser avec le vocabulaire de Scrum.
4.1 Fonctionnement de Scrum

La première étape consiste à effectuer une première planification de
l’itération ou Sprint Planning dans le jargon des développeurs. Cette réunion
fera ressortir les éléments prioritaires de la liste des exigences fonctionnelles du
produit. Chaque exigence représente une User Story ou "histoire utilisateur".
En accord avec le client, aussi appelé Product Owner, les premières

livraisons devraient être effectuées à la fin de cette itération (qui dure de 2 à 4
semaines suivant le nombre des user stories présentent dans le Backlog). Le
backlog est l'ensemble des US à développer durant l'itération en cours.
Une autre réunion appelée Revue de Sprint ou Sprint Review est

organisée à la fin de chaque Sprint durant laquelle les développeurs
présentent au client les fonctionnalités développées. Ce dernier pourra ainsi
tout de suite donner son feedback, ce qui présente l’avantage de gagner
beaucoup de temps et d’ajuster les fonctionnalités ou les méthodes de travail
le cas échéant.
Vient ensuite une rétrospective de Sprint ou Sprint Restrospective qui

permet à tous les acteurs d’améliorer des choses et de s’améliorer également.
Une autre particularité de la méthode Scrum est la réalisation de mêlées
quotidiennes ou Daily Scrum qui permettent à l’équipe de développeurs de
synchroniser leur travail. Cette réunion qui ne dure pas plus de 15 minutes
permet à chacun de déterminer ce qu’ils ont réalisé depuis la dernière mêlée,
de ce qu’ils auront à terminer avant la prochaine Daily Scrum et d’identifier les
obstacles qui pourraient les bloquer.
La figure 12 résume le processus de fonctionnement de la méthode Scrum.

4.1.1 L’équipe et Rôles

Le Framework Scrum consiste en la définition des rôles projets, activités
ou artefacts, et réunions ou évènements, bref il définit trois rôles qui sont :
Description
Scrum - Agit comme un facilitateur.
Master - S’assurer de fournir à l’équipe Scrum, tout le nécessaire à leur plein
potentiel.
- C’est un coordonnateur de ressources, un intermédiaire et non pas
un dirigeant.
Product - C’est le représentant des clients et des utilisateurs

Owner - Définir l'ordre dans lequel les fonctionnalités seront développées
- Expliciter les user Stories du backlog du produit
- S'assure que le backlog du produit est visible et compris de l'équipe
de développement.
Scrum - Se constitue des personnes qui seront chargées d’implémenter les
team différents besoins du client
- des développeurs, des infographistes, des testeurs, etc.
- Spécifications Techniques
Tableau 5: Les différents roles dans la méthode Scrum
Figure 7: Le processus du Framework Scrum
Ce shéma éxplique le fonctionnement et l’architecture de la méthode Scrum

4.1.2. Les Événements

Toutes les activités (sprint, réunions de planning, revues, rétrospectives et
mêlées) décrites dans le Framework Scrum sont effectuées lors de boites de
temps.
Le sprint : est une période (constante) d'un mois au maximum, au bout

de laquelle l'équipe délivre un incrément du produit, potentiellement livrable.
Un nouveau sprint démarre dès la fin du précédent. Chaque sprint est associe
à une liste d'éléments du backlog du produit à réaliser durant ce sprint. Pour
notre projet la durée du sprint sera fixée à 2 semaines.
Daily scrum : C’est une réunion de planification qui dure 15 minutes et permet
aux développeurs de faire un point de coordination sur les tâches en cours et
sur les difficultés rencontrées.
Sprint planning Meeting : Toute l'équipe Scrum est présente à cette réunion, qui
ne dure plus de 4 heures pour notre cas, pour planifier les user stories du
backlog du produit qu'elle a décidé de traiter pendant la prochaine itération
et comment elle s'organisera pour y parvenir.
Sprint review : À la fin du sprint, l'équipe Scrum et les parties-prenantes invitées

se réunissent pour effectuer la revue de sprint, qui dure au maximum 1 heure
(pour notre cas), qui a pour objectif de valider le logiciel qui a été produit
pendant le sprint. L'équipe fait une démonstration du logiciel produit.
4.1.3. Les artefacts

Product Backlog : L’approche Scrum propose de commencer par lister les
exigences du client afin de produire le Product Backlog sous forme de liste
d’item ou User Story, cette liste contient tout ce qui pourrait être requis dans
le produit et est l'unique source des besoins pour tous les changements à
effectuer sur le produit.
Le Tableau 1 résume le backlog produit de notre application qui contient

50 User Stories

En tant que Je voudrais

1 Utilisateur s'authentifier afin d’accéder à
l'application
2 Utilisateur Gérer mon profile
3 Utilisateur Consulter le Dashboard selon mes
permissions
4 Administrateur Gérer les permissions
5 Manager Gérer les projets
6 Manager Gérer les sprints
7 Manager Gérer les user stories
8 Manager Définir la vitesse de l'équipe (Velocity)
9 Manager Gérer les taches
10 Manager Affecter les tâches aux membres d'équipe
11 Développeur Gérer le taskBoard
12 Manager Afficher le burndown chart du sprint.
13 Manager Afficher et imprimer le backlog du projet.
14 Manager Afficher et imprimer le backlog du sprint.
15 Administrateur Gérer les templates du contrat employé.
16 Administrateur Gérer les templates du contrat des clients.
17 Manager Gérer les congés
18 Manager Définir les soldes congés pour chaque
employé et les journées de récupération
19 Manager Gérer les demandes de congés.
20 Manager Afficher les résumés des congés
21 Manager Suivre les présences/absences
22 Manager Gérer les pointages (entrés/sorties)
23 Manager Evaluer les employés
24 Manager Suivre l'évolution des heures préstées
(timesheets) sur une tâche ou projet
25 Manager Gérer les clients.
26 Manager Gérer les contrats des clients
27 Manager Imprimer ses feuilles de prestations
28 Manager Valider/refuser les heures prestées.

29 Manager Gérer les contrats des employés

30 Manager Gérer les comptes analytiques associés
aux projets
31 Manager Soumettre les heures prestées pour la
facturation.
32 Manager Créer et d'envoyer des factures aux
clients.
33 Manager Consulter et d'imprimer les factures.
34 Manager Afficher et d'imprimer les rapports des
projets.
35 Employé Gérer mes tâches.
36 Employé Afficher le burndown chart
37 Employé Demander un congé.
38 Employé Afficher une liste de mes congés avec
leurs états.
39 Employé Pointer l'entré et la sortie.
40 Employé Créer les timesheets par tâche.
41 Employé Consulter mes présences/absences.
42 Employé Soumettre mes heures prestées
(timesheets) au responsable pour la
validation
43 Employé Afficher le rapport de mes tâches.
44 Employé Imprimer mon contrat.
Tableau 6: Le Backlog du projet
Chaque ligne du Product backlog représente une User Story ou histoire

utilisateur. Les éléments du backlog sont classés par priorité ce qui permet de
définir l'ordre de réalisation. Très souvent les User Stories peuvent porter
également des numéros ID afin de les distinguer plus rapidement. Le backlog
est sous la responsabilité du Product Owner. Chacun peut contribuer à
collecter des éléments, mais c'est le Product Owner qui les accepte finalement
et c'est lui qui définit les priorités.

Sprint Backlog : En début de sprint, un but est décidé. Pour atteindre cet
objectif, l'équipe de développement choisit lors de la réunion de planification
de sprint quels éléments du Product Backlog seront réalisés. Ces éléments sont
alors groupés dans un backlog dite Sprint Backlog.
4.1.4. Estimation des éléments du backlog

Les items du Product Backlog sont souvent des User Stories empruntées
à Extrême Programming. Ces User Stories sont estimées en points relatifs, sans
unité. L'équipe prend un item représentatif et lui affecte un nombre de points
arbitraire. Cela devient un référentiel pour estimer les autres items.
Figure 80: Exemple de user story
Par exemple, la figure 11 représente une User Story qui vaut 3 points, cette User
Story représente une complexité triple par rapport à une autre qui en vaut 1 (le
point n'est pas une mesure de charge car il deviendra arbitraire.). Pour les
valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1, 2, 3,
5, 8, 13,…), qui évitent les difficultés entre valeurs proches (8 et 9 par exemple).
Figure 8: Des cartes de planning poker
4.1.4. La vélocité
La vélocité de l'équipe, est le nombre de points que l’équipe peut
réaliser en un sprint. La vélocité peut s'estimer en regardant les sprints
précédents, à supposer que la composition de l'équipe et la durée des sprints

soient stable. Elle peut aussi être définie à chaque sprint avec un planning basé
sur l'engagement de l'équipe.
Concernant la vélocité de mon équipe qui se compose de un membre,
j’ai pu réaliser 8 points pendant le premier Sprint. En partant de cette vélocité
et du total de points à réaliser (85 points), on peut déterminer le nombre de
sprints qui seront nécessaires pour terminer le projet (6 sprints).
4.1.4. Les tâches du Sprint Backlog

Un item peut prendre plusieurs jours avant d’être réalisé, chaque item du
sprint backlog doit donc être découpé suivant une granularité plus fine,
appelée tâche. Ce découpage permettra ainsi aux membres de l’équipe de
se les partager. Chaque tâche est chiffrée en heure/homme correspondant à
son temps de développement, idéalement une tâche ne doit pas dépasser un
jour/homme.
La figure 16 illustre le découpage d’une User Story de notre Product Backlog.
Nous pouvons voir que cette user story estimé à 2 points, soit 16
heures/homme de travail est alors découpé en 3 tâches : la tâche 3.1, 3.2, 3.3,
qui sont réalisable respectivement en 3, 5, et 2 heures/homme.
4.1.4. Planification des Releases

La réunion de planification des sprints (Sprint planning meeting), qu’on a
vue précédemment, est l’événement le plus important dans Scrum. Le but de
cette réunion est de préparer le planning de travail et d’identifier le backlog
des sprints.
Comme on a vu dans la section précédente, mon projet pourra contenir

6 sprints avec une vélocité de 8 points, dans ce contexte nous avons choisi de
développer trois releases, chaque release contient trois Sprints de tailles de
deux semaines.

4.2. Outils Scrum

4.2.1. Taskboard
Release 1 Release 2
Figure 9: Les releases du projet
Ce tableau représente les deux Releases planifiées, chacune de ces

Releases contient 3 Sprints de tailles de 10 points, chaque Sprint est représenté
par une date de début, une date de fine et un nombre de User Stories dont
chacune de ces User Stories est représentée par un numéro d’identification ID,
un nombre de points représentant la durée estimée pour la réaliser et un
numéro de priorité, ce qui permet de définir l'ordre de réalisation.
Le Taskboard est une table de 3 colonnes, dans la première on met

toutes fiches représentant les User Stories du Sprint courant. Les 2 trois autres
colonnes représentent les états par lequel chaque tâche doit passer, chaque
ligne représente un ensemble de tâche associée à une User Story ou dans
certains cas les bugs à corriger. Dans notre exemple, les tâches débutent dans
l’état To Do, lorsqu’un membre décide de réaliser une tâche, il l’a fait passer à
l’état In progress, une fois terminée il l’a fait passer à l’état Done et finalement
lorsque toutes les taches d’une même User Story sont terminées elle passe cette
User Story à l’état final Done.

Figure 10 : Exemple de Taskboard
Par conséquent, plusieurs outils sont apparus en offrant la possibilité de

suivre la priorité, la traçabilité et la gestion de tout le travail associé.
4.2.2. BurndownChart
C’est également durant la réunion de Daily Scrum que l’équipe met à
jour le BurndownChart, une courbe qui permet de visualiser l’avancement de
l’équipe sur le sprint. La figure suivante représente le BurndownChart du 4ème
Sprint :
Figure 11: Le BurndownChart du 4ème Sprint
La différence entre la ligne idéale qui est en noire et celle effective qui
est en rouge peut être analysée pour en soutirer des informations précieuses.
Si la ligne effective est supérieur à la ligne idéale, cela veut dire qu'il y a plus
de travail restant que celui prévu initialement. À contrario, si la ligne est
inférieure, on aura moins de travail restant que celui planifié.

5. Conclusion
Dans ce chapitre nous avons présenté la méthodologie de travail ainsi
que nous avons préparé le plan de releases, par la suite nous allons dévoiler les
outils et les langages de conception et de développement que nous avons
utilisés durant la réalisation du système.

Chapitre 3: Technologies utilisés
I- Exigence du projet
II- Choix de la technologie
III- Outils utilisés
IV- Conclusion

Après avoir décrit dans le chapitre précédent l’ensemble des

fonctionnalités du système, je vais élaborer dans ce chapitre une étude
technique qui permettra de décrire l’aspect technique de la solution à réaliser.
1. Exigence du projet
Une architecture logicielle exprime un schéma d’organisation
structurelle fondamentale pour des systèmes logiciels. Il fournit un ensemble de
sous-systèmes prédéfinis, spécifie leur responsabilité, et inclut des règles et des
guides pour organiser les relations entre eux.
L’architecture logicielle du projet subit un certain nombre de forces, le choix

d’une architecture logiciel constitue un défi technologique. En effet il faut
définir les grands objectifs technique de la future architecture, c'est-à-dire de
bien prendre en compte l’ensemble des forces qui vont s’exercer sur le future
système ainsi que la puissance de chacune d’entre elles. Les objectifs
techniques de l’architecture doit assurer sont la fiabilité, la réutilisabilité, la
disponibilité et l’évolutivité.
1.1. Méthodologie de développement : La démarche

MVC
Modèle d'architecture qui cherche à séparer nettement les couches de
présentation (UI : User Interface), métier (BLL : Business Logic Layer) et d'accès
aux données (DAL : Data Access Layer). Le but étant d'avoir une dépendance
minimale entre les différentes couches de l'application, ainsi les modifications
effectuées sur n'importe quelle couche de l’application n'affectent pas les
autres couches.
• Modèle – Encapsule le cœur fonctionnel de l'application, le domaine
logique.

• Vue – les données sont envoyées, par le modèle, à la vue qui les présente à
l’utilisateur.
• Contrôleur – reçoit les données et les transmets au modèle ou à la vue.
Une telle architecture est communément appelée architecture 3-tier ou à 3

niveaux.
Figure 12: Architecture MVC
1.2. Pourquoi MVC

Une architecture est une sorte d'organisation qui permet de répartir des
fonctions sur un ensemble de ressources (et/ou d'organiser le boulot pour
construire la chose correspondante).
Si les possibilités de répartition +/- optimales des fonctions sur les ressources sont
limités, le nombre d'architectures le sera aussi. Ce qui ne signifie pas une
grande variabilité.
A la base d'une application multi-utilisateurs, vous avez des IHM et
une/des fonctions de persistance (base de donnée), si l'IHM est un client lourd,
à chaque mise à jour il faudra aller sur tous les postes clients... Si vous avez 1000
utilisateurs, vous ne le ferez pas deux fois: donc navigateur et on descend la
logique dans un serveur d'application, mais entre les deux, ce seront deux
implémentations différentes d'une architecture MVC construites avec des

technologies différentes et des personnes différentes. Ajoutons de la
persistance (cache) et des actions dans le client (JavaScript et Ajax), et voilà
que vous avez un peu de MVC dans le seul navigateur et qu'il serait sage de
rebaptiser cela d'un autre nom
Microsoft a essayé avec MVVM mais en fait, tout le monde s'en fout car
les technologies ne sont pas encore assez "mûres" pour tracer des frontières
'stables' qui aient une valeur ajoutée dans l'organisation de la solution ou du
travail correspondant.
2. Choix de la technologie
2.1. Etude comparative entre les ERP existant sur le
marché
Pour réaliser cette étude comparative entre les Plateformes nous avons
utilisé «Google trends », cet outils va nous permettre de savoir la fréquence de
recherche de ces termes sur le moteur de recherche Google. Ainsi les résultats
nous ont donnés une idée globale sur le Framework le plus utilisé ou autrement
dit le Framework qui a la plus grande quantité de ressources sur internet
Figure 13: Intérêt de recherche odoo/openerp/tinyerp
Ce diagramme montre le changement marque de «TinyERP» à «OpenERP » en

2008 puis vers « Odoo » en 2014, sans aucun impact significatif sur l'activité

Figure 14: Intérêt de recherche odoo/netsuite/xtuple/compiere
Pour avoir une idée sur le nombre de ressources [JAVA/.NET] qui sont archivés
dans le Datacenter de Google. On a utilisé le moteur de recherche
directement et on a obtenu les résultats suivants.
Figure 20: Nombre de résultats sur le nombre de recherche Google pour le terme sage
Figure 15: Nombre de résultats sur le nombre de recherche Google pour le terme odoo

Figure 16: Nombre de résultats sur le nombre de recherche Google pour le terme sap
Figure 20: Nombre de résultats sur le nombre de recherche Google pour le terme sage
2.2. La plateforme Odoo

Odoo est un Progiciel de Gestion intégré (PGI) en anglais Enterprise
Ressource Planning (ERP), Open Source, il permet de construire des
applications informatiques (gestion des commandes, des stocks, de la paie, de
la comptabilité, etc), modulaire et intégrée au niveau des traitements offerts
(les différents modules qui le composent sont indépendants mais parfaitement
compatibles entre eux),ainsi rigoureux et cohérent au niveau des données
gérées (partage d'une base de données unique et commune), Fournir à
l'ensemble des acteurs de l'entreprise une image unique,en plus il est
cohérente et homogène de l'ensemble de l'information, Fédérer l'ensemble
des processus de l'entreprise dans chacun des domaines qui la constituent et
ce, dans une approche transversale qui optimise sa productivité, logiciel dans
lequel le code source est à la disposition du grand public, généralement un
effort de collaboration où les programmeurs améliorent ensemble le code
source

Figure 17: L'architecture de deploiment Odoo
- Investissement ciblé sur le métier
- Respect des standards ouverts
- Indépendance vis-à-vis d'un éditeur
- Accès au code source (personnalisation)
- Développement communautaire
- Abondances de versions
- Transparence du code source
- Déficit de documentation
- Déficit de compétences
Trois tiers client / serveur / base de données, client Web en Javascript, les
modules serveurs backend en Python

Figure 18: Single server, multi-process
Figure 19: multi server, multi process
- Environ 2 000 000 d’utilisateurs à travers le monde en grande majorité issus des
pays émergeants
3. Outils utilisés
3.1. Python
Python est un langage de programmation objet, multi-

paradigm et multiplateformes. Il favorise programmation
impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage
dynamique fort, d'une gestion automatique de la mémoire par ramasse-

miettes et d'un système de gestion d'exceptions ; il est ainsi similaire

à Perl, Ruby, Scheme, Smalltalk et Tcl.
Le langage Python est placé sous une licence libre proche de la licence
BSD2 et fonctionne sur la plupart des plates-formes informatiques,
des supercalculateurs aux ordinateurs centraux, de Windows à Unix en passant
par GNU/Linux, Mac OS, ou encore Android, iOS, et aussi avec Java ou
encore .NET. Il est conçu pour optimiser la productivité des programmeurs en
offrant des outils de haut niveau et une syntaxe simple à utiliser.
Il est également apprécié par les pédagogues qui y trouvent un langage où la

syntaxe, clairement séparée des mécanismes de bas niveau, permet une
initiation aisée aux concepts de base de la programmation
3.2. QWEB
QWEB est le moteur de template principal utilisé par Odoo. Il est un template
XML moteur et utilisé principalement pour générer des fragments et des pages
HTML.
Les directives de modèle sont spécifiés comme des attributs XML avec le
préfixe t-, par exemple t-si pour conditionnels, avec des éléments et d'autres
attributs étant rendu directement.
3.3. HTML5-CSS3
HTML5 (HyperText Markup Language 5) est la dernière révision majeure
d'HTML (format de données conçu pour représenter les pages web). Cette
version est en développement en 2013. HTML5 spécifie deux syntaxes d'un
modèle abstrait défini en termes de DOM : HTML5 et XHTML5. Le langage
comprend également une couche application avec de nombreuses API, ainsi
qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non
conforme. Le travail a été repris par le W3C en mars 2007 après avoir été lancé

par le WHATWG. Les deux organisations travaillent en parallèle sur le même

document afin de maintenir une version unique de la technologie. Le W3C vise
la clôture des ajouts de fonctionnalités le 22 mai 2011 et une finalisation de la
spécification en 20141, et encourage les développeurs Web à utiliser HTML 5
dès maintenant.
Le terme CSS est l'acronyme anglais de Cascading Style Sheets qui peut se traduire
par "feuilles de style en cascade". Le CSS est un langage informatique utilisé sur
l'internet pour mettre en forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi
appelé les fichiers CSS, comprennent du code qui permet de gérer le design d'une
page en HTML.
3.4. XML
L'Extensible Markup Language (XMLnote 1, « langage à balise extensible »
en français) est un langage informatique de balisage générique qui dérive du
SGML. Cette syntaxe est dite « extensible » car elle permet de définir différents
espaces de noms, c'est-à-dire des langages avec chacun leur vocabulaire et
leur grammaire, COMME XHTML, XSLT, RSS, SVG… Elle est reconnaissable par
son usage des chevrons (< >) encadrant les balises. L'objectif initial est de
faciliter l'échange automatisé de contenus complexes (arbres, texte riche…)
entre systèmes d'informations hétérogènes (interopérabilité). Avec ses outils et
langages associés, une application XML respecte généralement certains
principes :
 La structure d'un document XML est définie et validable par un schéma

 Un document XML est entièrement transformable dans un autre
document XML.
3.5. Postgresql
PostgreSQL est un système de gestion de base de données relationnelle et

objet (SGBDRO). C'est un outillibre disponible selon les termes d'une licence de
type BSD.

Ce système est concurrent d'autres systèmes de gestion de base de

données, qu'ils soient libres MariaDB, MySQL et Firebird), ou propriétaires
Oracle, Sybase, DB2, Informix etMicrosoft SQL Server). Les projets libres Apache
et Linux, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé
sur une communauté mondiale de développeurs et d'entreprises.
3.1. Outils de conception
Microsoft Visio (officiellement Microsoft Office Visio) est un logiciel de

diagrammes et de synoptique pour Windows qui fait partie de la suite
bureautique Microsoft Office mais se vend séparément. On peut ainsi créer des
diagrammes de Gantt, des réseaux de PERT ou encore des diagrammes IDEFO.
Dans Visio, les graphiques utilisés pour créer des diagrammes sont vectoriels.
Les versions Standard et Professionnel de l'édition 2007 partagent la

même interface, mais cette dernière permet de faire des diagrammes plus
avancés, grâce à des modèles supplémentaires. Cette version offre
également une fonctionnalité unique qui permet aux utilisateurs de relier
facilement leurs diagrammes à un grand nombre de sources de données et
d'afficher les informations recueillies graphiquement.
3.1.2. Outils de développement

a. Eclipse
Eclipse IDE est un environnement de développement intégré libre(le

terme Eclipse désigne également le projet correspondant, lancé par IBM)
extensible, universel et polyvalent, permettant potentiellement de créer des
projets de développement mettant en œuvre n'importe quel langage de
programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la
bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques
spécifiques, est également utilisé pour écrire des extensions.
b. Gitlab : Solution d’hébergement de projets Git

Git, outil de gestion de versions de code source, s’est répandu très
rapidement dans la communauté Open Source, d’autre part sa rapidité, sa
flexibilité et sa fiabilité. Les solutions d’hébergement en ligne de projets Git
connaissent un énorme succès, mais leur utilisation est bien souvent payante
pour l’hébergement de projets privés. GitLab est une solution gratuite et Open
Source pour l’hébergement de projets Git privés comparable aux géants tels
que GitHub et BitBucket et qui convient aux entreprises, Développé
initialement par Linus Torvalds en 2005 pour la gestion du kernel Linux. Depuis,
Git s’est rapidement répandu, surtout dans la communauté Open Source, de
par sa rapidité, flexibilité, fiabilité et sa nature distribuée, tous des aspects qui
le distinguent d’outils plus anciens tels que Subversion (SVN).
L’hébergeur Git le plus connu et le plus utilisé est GitHub, qui offre de
l’hébergement gratuit de projets publics, et propose une version payante pour
particuliers ou entreprises, pour des projets privés. Bitbucket d’Altassian se
distingue de GitHub en offrant des projets privés gratuits pour un nombre limité
de collaborateurs par projet. Enfin, ces hébergeurs disposent tous des services
payants de déploiement de serveurs Git privés en self-hosting auprès
d’entreprises. Fortement inspiré de GitHub, est entièrement Open Source et
s’adresse COMME solution gratuite d’hébergement de projets Git.
Avant de rentrer dans les détails de mise en œuvre de GitLab, passons

en revue les fonctionnalités offertes aux utilisateurs et administrateurs.
Premièrement, et surtout, GitLab propose une interface web complète

et épurée. Toute solution d’hébergement web de projets Git permet de
visualiser ses différents projets, l’état et l’évolution des branches et l’historique
du projet, chose qui peut également être faite avec un grand nombre d’outils
de visualisation de repositories Git locaux tel que Gitk. Les solutions
d’hébergement web apportent surtout une valeur ajoutée via les services
autour de Git, COMME pour le cas de GitLab :
La collaboration entre utilisateurs :

 La revue de code, allant de l’annotation d’un ensemble de commits

jusqu’à l’annotation de lignes de code individuelles dans un COMMIT
particulier.
 Le suivi de bugs et fonctionnalités dans un bugtracker.
 La définition de milestones d’évolution du projet.
 Un système de notification par mail et flux RSS.
 Un tableau de bord inter-projets pour ne rien rater.
L’administration de projets Git :
 Tout utilisateur dispose de droits de création de repositories, dans

son namespace personnel ou dans unnamespace de groupe, pour
rassembler des repositories liés et partagés entre plusieurs utilisateurs.
 Un repository dans un namespace personnel ou de groupe est
accessible aux utilisateurs suivant un système de permissions, bien plus
riche que celui de GitHub : none, guest,REPORTER, developer et master.
 La notion d’équipe facilite l’attribution de droits d’accès à une liste de
repositories avec un certain niveau de permission à un ensemble
d’utilisateurs.
c. Jira
JIRA est un système de suivi de bugs, un système de gestion des incidents,
et un système degestion de projets développé par Atlassian Software Systems.
4. Conclusion
On a commencé ce chapitre par la présentation des exigences du
projet et l’architecture logicielle de mon système. Après on a présenté
l’architecture de développement choisi ainsi que outils utilisés pour la
réalisation de ce projet, dans le chapitre suivant nous allons détailler les
différents releases du projet.

Chapitre 4: Les releases du projet scrum
I- Release 1
II- Release 2

Le terme release peut être défini comme une version distribuée ou

livrable d'une application ou une période de temps qui permet de la produire.
Un release est constitué d'une suite d'itérations (sprint) qui se terminent quand
les incréments de ces derniers construisent un produit présentant suffisamment
de fonctions aux utilisateurs finaux.
Au cours de ce chapitre, nous allons traiter les User Stories de mes sprints
pour produire un incrément potentiellement livrable.
1. Premier Release
Ce premier release se présente comme le plus essentiel et prioritaire des
releases car il contient les fonctionnalités principales de projet, où on doit
réaliser la gestion des projets, des histoires utilisateurs, des taches, des Sprints,
des membres de projets, et il contient 3 Sprints.
1.1. Sprint 1
Une fois, nous avons défini la longueur du Sprint, il est temps de décider
quelles histoires inclure dans ce dernier. Plus précisément, quelles histoires de
notre backlog du produit seront incluses dans le backlog du sprint. Dans notre
cas les histoires sont classifiées par leurs priorités, le tableau résume donc le
backlog de mon premier sprint :
En se basant sur le point de vue du Product Owner (client), et en terme

métier nous avons défini le but de ce sprint : réaliser des fonctionnalités
basiques de la plateforme comme : la consultation du Dashboard, la gestion
des membres des équipes …

1.1.1. Backlog
Les user stories du premier sprint
User story Estimation
En tant que utilisateur, j'ai besoin de s'authentifier afin 1

d’accéder à l'application
En tant que utilisateur j'ai besoin de gérer mon profile 1
En tant que utilisateur j'ai besoin de consulter le Dashboard 1
selon mes permissions
En tant qu'administrateur j'ai besoin de gérer les permissions 1
En tant que manager j'ai besoin de gérer les projets 2
Table 1 : Backlog du sprint 1
Lors de la réunion du sprint planning on a discuté avec le Product Owner et

le Scrum Master, chacune des user stories.
 L’authentification : l’authentification de n’importe quel utilisateur du

system.
 Gestion du profile : Tout le monde peut gérer son profile (CRUD).
 Gestion de projets : Seulement le manager qui a le droit de gérer les
projets.
 Gestion des permissions : Le manager a le droit d’attribuer ou de
restreindre les droits des utilisateurs.
1.1.1. Conception
1.1.1.1. Choix formalisme UML
Vue le déploiement de l’application et l’extension future, une
modélisation objet apparait la plus adaptée, en effet l’objet a fait ses preuves
dans la réalisation d’application Web.
Pourquoi nous avons opté pour UML :
- UML est un langage formel et normalisé

o gain de précision
o gage de stabilité
o encourage l'utilisation d'outils
- UML est un support de communication performant

o Il cadre l'analyse.
o Il facilite la compréhension de représentations abstraites complexes.
o Son caractère polyvalent et sa souplesse en font un langage
universel.
Après avoir exprimé les spécifications fonctionnelles, nous allons traduire ces
besoins nous allons traduire ces besoins-là en des diagrammes fonctionnels
UML
1.1.1.2. Vue cas d’utilisation

a. Diagramme de cas d’utilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés
pour donner une vision statique et globale du comportement fonctionnel d'un
système logiciel. Ils sont utiles pour des présentations auprès de la direction ou
des acteurs d'un projet
Le diagramme de cas d’utilisation est composé des acteurs externes et

des cas d’utilisation :
Les acteurs : Ils sont des entités externes qui interagissent avec le système,
comme une personne humaine ou un robot.
Les cas d’utilisation : est une description des interactions qui vont permettre à
l'acteur d'atteindre son objectif en utilisant le système.
La solution qu’on va réaliser va être gérer par les responsables ressources

humaines le DRH et les chefs de projet qui sont aussi des administrateurs
système, et en fin il y a les utilisateurs, dans ce sprint existe 3 diagramme de cas
d’utilisation.

Figure 20 : Diagramme de cas d’utilisation d’un utilisateur – Sprint 1
L’utilisateur peut faire la gestion de son profile et consulter le DashBoard selon

ses permissions
Figure 21: Diagramme de cas d'utilisation du Manager – Sprint 1
Pour que le manager puisse gérer ses projets, il doit premièrement s’authentifier
Figure 22: Diagramme de cas d'utilisation de l’administrateur – Sprint 1
L’administrateur peut faire un cas d’utilisation qui est spécifique, c’est la gestion
des permissions
1.1.1.3. Vue séquentielle

Les diagrammes de séquences sont la représentation graphique des
interactions entre les acteurs et le système selon un ordre chronologique dans
la formulation UML.
Le diagramme de séquences permet de cacher les interactions d'objets dans

le cadre d'un scénario d'un Diagramme des cas d'utilisation. Dans un souci de
simplification, on représente l'acteur principal à gauche du diagramme, et les

acteurs secondaires éventuels à droite du système. Le but étant de décrire

comment se déroulent les actions entre les acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant

de visualiser l'enchaînement des actions dans le temps, et de spécifier la
naissance et la mort d'objets. Les périodes d'activité des objets sont
symbolisées par des rectangles, et ces objets dialoguent par le biais de
messages.
Apres la description des cas d’utilisation, nous allons élaborer le modèle
dynamique dans lequel nous allons décrire les scénarios de quelques cas
d’utilisations, les plus importants dans ce sprint, sous forme de diagrammes de
séquence.
Figure 23: Diagramme de séquence de la gestion des projets

Figure 24 : Diagramme de séquence du cas d'utilisation : gestion des permissions
Ce diagramme montre la gestion des droits par l’administrateur
1.1.1.4. Diagramme de classes

Le diagramme de classes est considéré comme le plus important de la
modélisation orientée objet, il est le seul obligatoire lors d'une telle
modélisation.

Alors que le diagramme de cas d'utilisation montre un système du point de

vue des acteurs, le diagramme de classes en montre la structure interne. Il
permet de fournir une représentation abstraite des objets du système qui vont
interagir pour réaliser les cas d'utilisation. Il est important de noter qu'un même
objet peut très bien intervenir dans la réalisation de plusieurs cas d'utilisation.
Les cas d'utilisation ne réalisent donc pas une partition des classes du
diagramme de classes. Un diagramme de classes n'est donc pas adapté (sauf
cas particulier) pour détailler, décomposer, ou illustrer la réalisation d'un cas
d'utilisation particulier.
Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel
dans le comportement du système. Le diagramme de classes modélise les
concepts du domaine d'application ainsi que les concepts internes créés de
toutes pièces dans le cadre de l'implémentation d'une application. Chaque
langage de Programmation orienté objet donne un moyen spécifique
d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas,
etc.), mais le diagramme de classes permet de modéliser les classes du
système et leurs relations indépendamment d'un langage de programmation
particulier.
Les principaux éléments de cette vue statique sont les classes et leurs
relations : association, généralisation et plusieurs types de dépendances, telles
que la réalisation et l'utilisation.

Figure 25: Diagramme de classes sprint1
Le premier sprint a un diagramme de classes qui se compose de 7 classes :

User, Administrateur qui hérite de la classe user, et il y a aussi notre classe
project_scrum qui héritent de la classe project du module standard de gestion
du projet.
 Un Manager peut être responsable de plusieurs projets.

 Un projet peut avoir plusieurs utilisateurs, et un utilisateur peut être
membre dans plusieurs projets.
Au niveau de la base de données on aura une 3ème table qui va lier les
tables candidat et sujet de stage.
 La classe Project est liée à la classe Sprint qui sera présenté dans le
prochain sprint (on en parlera dans le prochain sprint).
1.1.2. Réalisation
Dans cette partie on va parler des différentes fonctionnalités réalisées
pendant ce sprint.

1.1.2.1. Le Dashboard et la gestion des projets
Figure 26: Gestion des projets
Après l’authentification l’utilisateur est rediriger directement vers le

Dashboard de gestion des projets où il ne voit que les projets qui lui affecté
comme membre de l’équipe des développeurs, Product Owner, ou Scrum
Master, s’il est administrateur il doit avoir accés à tous les projets comme il
montre cette capture
1.1.3. Conclusion
Dans cette partie j’ai conçue réalisé et testé le premier sprint du 1er
release du projet, qui a regroupé plusieurs fonctionnalités de bases de la
plateforme, nous avons détaillés les différentes étapes adoptées par la
méthode Scrum. Dans la partie suivante on va attaquer, avec la même
approche le deuxième sprint de ce release.

1.2. Sprint 2
En partant sur le même principe que le sprint précédent, nous
commençons par les spécifications fonctionnelles. Ensuite la conception et
finalement les tests cette fois ci ne sont pas disponibles vu que c’est la même
procédure qui se répète. Le tableau résume donc le backlog de notre premier
sprint.
1.2.1. Backlog
Les user stories du premier sprint :
En tant que manager j'ai besoin de gérer les sprints 3

En tant que manager j'ai besoin de gérer les user stories 2
En tant que manager j'ai besoin de définir la vitesse de l'équipe 2
(Velocity)
En tant que manager j'ai besoin de gérer les taches 2
Table 7 : Backlog du sprint 1.
Comme on l’a déjà mentionné, lors de la réunion du release planning on a

discuté avec le product Owner et le scrum master chacune des user stories ci-
dessus au niveau fonctionnelles pour éclaircir nos vue et les objectifs à
atteindre.
Ce sprint se compose de quatre histoires d’utilisateur ordonné par priorité :
 Gestion des Sprints : Dans chaque projet le Manager peut gérer les
sprints associé à ce projet.
 Gestion des histoires : Le manager a le droit de créer, modifier, ou
supprimer une histoire, lors de la création d’une user story le manager
doit spécifier le projet et le Sprint, et l’utilisateur peut modifier l’état de
l’histoire en la glisser dans le taskboar vers le nouveau état.
 Gestion des taches : Les taches sont gérer par les développeurs et les
managers et ils peuvent modifier l’état de la tâche en glissant la tache
vers le nouvel état (« à faire », « en cours », « déjà fait »).

 Définition de la vélocity : dans chaque projet l’administrateur a le droit

de définir la vélocity de l’équipe associé à ce projet
1.2.2. Conception
1.2.2.1. Vue cas d’utilisation : Diagramme de cas d’utilisation
Toutes les fonctions qui se trouvent dans ce sprint sont relié à
l’administrateur où il peut définir la vélocité de l’équipe, ensuite il peut entrer
dans chaque sprint pour gérer les histoires, et enfin faire la gestion des taches.
Figure 27 : Diagramme de cas d’utilisation du Manager - Sprint 2
Ce Sprint contient seulement les cas d’utilisation du Scrum Master ou Product

Owner, comme il montre la capture au-dessus

À ce niveau, nous devons présentés le diagramme de séquence des
différents cas d’utilisation déjà détaillés dans la section précédente.

Figure 28: Diagramme de séquence de la gestion des projets
Ce diagramme de séquence explique la gestion des projets, qui est confié au

manager

Figure 29 : Diagramme de séquence du cas d'utilisation : Définir la vélocité
Le manager peut définir la vélocité d’une équipe pour un projet spécifique,

donc la vélocité est définie pour chaque projet.

Figure 30: Diagramme de classes sprint 2
Ce diagramme présente les nouvelles classes créé dans ce sprint, environ dix
classes qu’on va détailler
 Project_scrum : représente les projets, ses cordonnées.
 Scrum_sprint : définit les sprints associés à un projet qui peut contenir
plusieurs sprints.
 User story : une histoire comporte plusieurs taches, chaque story est
représenté pas son nom, estimation, ses taches, date début, date fin …,

et elle a une durée de vie, après une certaine date elle ne sera plus
utilisé.
 Project_task : on enregistre les taches des histoires. avec l’estimation, le
nom, priorité, description, état, il doit être relié avec le timesheet des
employées.
1.2.3. Réalisation
Dans cette partie on va parler des différentes fonctionnalités réalisées
pendant ce sprint.
1.2.3.1. La gestion des incréments
Figure 31: Gestion des Sprints
Cette interface montre les Sprint du projet où la couleur du Sprint

représente l’état du Sprint et le champ progress affiche l’avancement du
Sprint, et donc d’après cette interface l’utilisateur doit avoir une idée
générale sur l’ensemble des Sprints du projet.

1.2.3.2. La gestion du Backlog
Figure 32: Gestion du Backlog
Cette page représente l’ensemble des histoires du projet en les classifiant par
Sprint, et c’est l’espace de gestion du Backlog
1.2.4. Conclusion
Dans cette partie j’ai conçue réalisé et testé le deuxième sprint du 1er
release du projet, qui a ajouté de nouvelles fonctionnalités et compléter
d’autres. Dans la partie suivante on va attaquer, avec la même approche le
troisième et dernier Sprint de ce release.

1.3. Sprint 3
Le sprint 3, est le dernier sprint du release, avait comme but le
développement des dernières fonctionnalités nécessaires à la livraison d’un
tout premier produit prêt à être utilisé.
En suivant la même méthode adoptée pour les Sprints précédents, nous

allons détailler les différentes phases de développement.
1.3.1. Backlog
Les user stories du troisième Sprint :
En tant que manager j'ai besoin de gérer les taches 3

En tant que manager j'ai besoin d’affecter les taches aux 1
membres d’équipe
En tant que manager j'ai besoin d’afficher le burndown chart 3
du sprint
En tant que manager j'ai besoin d’afficher et imprimer le 2
backlog du projet
En tant qu’employé j'ai besoin de gérer le taskBoard 3

 Gestion des Taches : Dans chaque projet le Manager et le

développeur peuvent gérer les taches associées au sprint ouvert du
projet.
 Affectation des taches : Le manager a le droit de répartir les taches sur
les membres de chaque projet.
 BurndownChart : Le manager peut accéder à chaque Sprint et
imprimer le Burndown Chart pour visualiser l’avancement, le
déroulement de chaque Sprint durant tout le projet.
 Backlog du projet : Pour chaque projet le Manager peut imprimer le
Backlog du projet

1.3.2. Conception
1.3.2.1. Vue cas d’utilisation : Diagramme de cas d’utilisation
Figure 33 : Diagramme de cas d’utilisation du Manager
La plupart des fonctions qui se trouvent dans ce sprint sont relié à

l’administrateur où il peut définir la vélocité de l’équipe, ensuite il peut entrer
dans chaque sprint pour gérer les histoires, et enfin faire la gestion des taches.
Figure 34 : Diagramme de cas d’utilisation du Développeur
Après l’authentification le développeur peut Gérer les taches qui

appartiennent aux histoires liés au projet.

Dans cette partie, on va détailler quelques cas d’utilisation en présentant
quelques diagrammes de séquences.

Figure 35: Diagramme de séquence de la gestion des Taches
Après l’authentification Le manager peut accéder aux Sprint liés à ses

projets, ensuite accèder aux histoires, et enfin accéder au taskboard de
chaque histoire où il peut ajouter, modifier, supprimer, consulter, changer l’état
en glissant la tache vers une autre colonne.

Ce diagramme ne contient pas beaucoup de nouvelles classes se caractérise par

le fait qu’il ne contient pas beaucoup présente des nouvelles classes qui sont :
 Project_meeting : pour gérer les Daily Scrum et les différentes rencontre qui se
faient au niveau de chaque Sprint.
1.3.3. Réalisation
A ce stade on doit avoir une idée sur l’interface.
VI.1.3.3.1. La gestion des taches

Figure 37: La gestion des taches
L’utilisateur doit arriver au taskboard de chaque histoire pour faire la gestion

de ses taches.
1.3.3.2. L’affectation des taches
Figure 38: L’ajout des membres de l’équipe
Premièrement Le manager doit ajouter les membres de l’équipe au projet,

comme il est expliqué sur la capture au-dessus

Figure 39 : L’affectation de la tache
1.3.3.3. L’affichage du BurndownChart du Sprint
Figure 40 : L’affichage du BurndownChart

Figure 41 : Le BurndownChart
Le manager peut choisir d’imprimer le BurndownChart.
1.3.3.4. L’affichage et l’impression du backlog du projet
Figure 42 : Ajouter un sujet de stage
Le manager a le droit de visualiser le backlog du projet en format PDF pour

qu’il soit imprimé par la suite.

1.3.3.5. La gestion du taskboard
Figure 43: Gestion du taskboard
Le développeur peut gérer les taches qui lui appartiennent
1.3.4. Conclusion
Dans ce chapitre on a analysé, conçu, réalisé et testé le premier release
du projet, il est alors maintenant potentiellement livrable. Il est temps de passer
au prochain Release. A ce stade, on a donc réussi à développer le release 1
pour arriver à un produit fonctionnel. Les besoins fonctionnels sont affinés sprint
après sprint, et la livraison des développements après chaque sprint permet de
réorienter le projet si nécessaire.
Dans le prochain chapitre on va détailler le Release 2 du projet, bien étudier

les sprints de ce release en passant par toutes les étapes définies par Scrum
(Analyse, Etude fonctionnelle, Conception & Modélisation, Mise en oeuvre).

2. Deuxième Release
Notre deuxième release est constitué de 3 sprints, c’est la deuxième version
livrable du projet. Nous allons analyser, détailler et tester les différentes phases
du release.
2.1. Sprint 4
Comme les sprints du premier release nous avons défini le but de ce Sprint qui
est dans un premier temps la gestion des congés, qui sera une configuration
du module standard de gestion de congés intégré dans la plateforme Odoo.
2.1.1. Backlog
Les user stories du quatrième Sprint :
En tant que manager, j'ai besoin de gérer les congés 1

En tant que manager, j’ai besoin de définir les soldes congés 2
pour chaque employé et les journées de récupération
En tant que manager, j'ai besoin de gérer les demandes de 1
congés
En tant que manager, j'ai besoin d’approuver ou refuser les 1
demandes de congés
En tant qu’employé j'ai besoin de créer les timesheets par 2
tache
En tant que manager j'ai besoin d’afficher les résumés de 1
congés
Ce sprint se compose de six histoires d’utilisateur ordonné par priorité :
 Gestion des congés : Le manager RH peut gérer les congés en lui

affichant un calendrier qui lui facilite la tâche.
 Les soldes de congés : Le manager RH a le droit de définir le nombre
légal de jours pour ses subordonnées.

 Gestion des demandes de congés : Le manager a le droit gérer les

demandes de congés de ses collaborateurs (CRUD), et ensuite les
approuver ou les refuser.
 Les timesheets : L’employé a la possibilité de créer les timesheets par
tache en affichant la différence entre l’estimation de la tâche et la
somme de ses timesheet.
 Les résumés de congés : Le manager peut accéder à une page qui lui
affiche les congés filtrés par type et ensuite par employé.
2.1.2. Conception
Dans cette partie du chapitre on va parler et détailler les options de la partie
de gestion de congés.
Dans ce sprint nous avons défini les différentes fonctionnalités de la gestion de congés et qui
sont associé au Manager Ressources Humaines
Figure 45 : Diagramme de cas d’utilisation de l’employé

Après l’authentification l’employé peut créer les timesheets qu’il a travaillés et

qui appartiennent à une tache d’un de ses projets.

Dans cette partie, on va discuter quelques cas d’utilisation en présentant
quelques diagrammes de séquences.
Figure 46: Diagramme de séquence de la gestion des Taches
Après l’authentification Le développeur peut accéder aux Sprint liés à

ses projets, ensuite accéder aux histoires, et enfin vers le Taskboard où il peut
choisir de modifier une tâche pour qu’il puisse entrer ses heures de travails.

Figure 47: Diagramme de classes sprint 4 : Gestion de congés
Ce diagramme représente la base de données du module standard d’Odoo

de gestion de congés.
2.1.3. Réalisation
Après l’étape de la conception et comme les chapitres précédents nous
allons entamer la partie réalisation du sprint, nous allons donner une idée sur
les différentes interfaces produites pendant le sprint.
2.1.3.1. La gestion des congés

Nous avons créés une interface qui soit lisible est très clair pour que le
manager peut gérer les congés sans difficultés

Figure 48: Gestion des congés
Dans le menu de gestion de cangés le Manager RH une calendrier

s’affiche en visualisant les demandes de congés avec leurs durées, en plus
filtrés employé
2.1.3.2. La validation des demandes de congés
Figure 49: La validation des demandes de congés
Le manager doit valider les congés de ses subordonnées pour qu’ils

soient affichés sur le calendrier.

2.1.3.3. La création des timesheets
Figure 50: L’inscription
Au niveau de la tache le développeur peut créer ses heures prestées en

précisant la durée, et il sera automatiquement le responsable.
2.1.4. Conclusion
Dans ce chapitre nous avons analysé, conçu, réalisé et testé le
quatrième sprint du deuxième release du projet qui a ajouté des fonctionnalités
à l’application et affiné d’autres. Il est temps de passer au cinquième et avant
dernier sprint

2.2. Sprint 5
Le sprint 5, avait comme but le développement des fonctionnalités
nécessaires à la livraison d’un produit prêt à être utilisé.
En suivant la même architecture des autres Sprints précédents, nous

allons détailler les différentes phases de développement.
2.2.1. Backlog
Les user stories du cinquième Sprint :
En tant qu’administrateur, j’ai besoin de gérer les templates du 0.5

contrat employé.
En tant qu’administrateur, j'ai besoin de gérer les templates du 0.5
contrat client
En tant que manager, j'ai besoin de suivre les 1
présences/absences
En tant que manager, j'ai besoin de gérer les pointages 2
(entrées/sorties)
En tant que manager, j'ai besoin de gérer les clients 0.5
En tant que manager, j'ai besoin de gérer les contrats clients 1
En tant que manager, j'ai besoin de gérer les contrats des 0.5
employés
En tant qu’employé, j'ai besoin de pointer l’entrée et la sortie 1
En tant qu’employé, j'ai besoin de consulter mes 0.5
présences/absences
En tant qu’employé, j'ai besoin d’imprimer mon contrat 1

 Les templates des contrats clients : L’administrateur a le droit de définir

les contrats des clients pour quel soit utilisé lors de la réduction du
contrat pour gagner du temps.

 Les présences et les absences : Le manager peut consulter les

présences de tous ses collaborateurs.
 Le pointage : Le manager peut suivre les pointages de ses
subordonnées.
 Gestion des clients : Le manager a le droit de gérer les clients
 Gestion des contrats client : Lors de la création d’un projet, un contrat
est créé automatiquement avec le projet, pour gagner du temps et le
manager peut la consulter, modifier, supprimer…
 Le pointage : L’employée doit avoir la possibilité pour pointer l’entrée
et la sortie
 Les présences : L’employée peut acceder à ses présences et ses
absences
 Impression du contrat : L’employé a besoin d’imprimer son contrat

2.2.2. Conception
Figure 51 : Diagramme de cas d’utilisation du Développeur – Sprint 5
Ce diagramme montre un ensemble de cas d’utilisation qui sont confiés au

manager ressources humaines (Gestion des contrats, des pointages, des
clients, …)
Figure 64 : Diagramme de cas d’utilisation de l’administrateur – Sprint 5

Figure 64 : Diagramme de cas d’utilisation de l’employé – Sprint 5
Pour qu’un employé puisse imprimer son contrat, consulter ses

présences, pointer son entrée ou sa sortie il doit premièrement s’authentifier
Figure 52: Diagramme de séquence du pointage de l’employé – Sprint 5

Cette figure au-dessus on trouve le cas du pointage par un employé lors

de son entrée ou lors de sa sortie
2.2.3. Réalisation
Après la conception et comme les chapitres précédents on va
attaquer la partie réalisation en donnant une idée sur l’interface d’utilisateur.
2.2.3.1. La gestion du pointage de l’entré et de la sortie
Figure 53: Le pointage entrée/sortie
L’employé peut gérer ses pointages, en filtrant les pointages du mois

courant, de la semaine courante, et d’aujourd’hui, mais un manager doit avoir
la possibilité de gérer les pointages de toutes ses subordonnées
VI.2.2.3.2. La gestion des Templates des contrats clients

Figure 54: Les templates des contrats clients
Lors de la création du contrat, Le manager peut choisir son modèle de

contrat ou bien créer un nouveau modèle, en précisant les variables à
inclure.
2.2.4. Conclusion
Dans cette partie, j’ai détaillé les différentes étapes parcourue dans le
cinquième Sprint pour arriver à ce résultat, maintenant il est temps pour
passer au dernier Sprint.

2.3. Sprint 6
Le sprint 6, est le dernier sprint du projet, avait comme but le
développement des dernières fonctionnalités nécessaires à la livraison de la
dernière version du projet.
En partant évidement par le même principe des sprints précédents,

nous allons détailler les différentes phases de développement.
2.3.1. Backlog
Les user stories du sixième Sprint :
En tant que manager, j’ai besoin de suivre l’évolution des 1

heures prestées (timesheets) sur une tache ou projet
En tant que manager j'ai besoin de valider ou refuser les heures 1
prestées
En tant que manager j'ai besoin de soumettre les heures 1
prestées pour la facturation
En tant que manager j'ai besoin de créer et d’envoyer des 1
factures aux clients
En tant que manager, j’ai besoin de consulter et d’imprimer les 1
factures
En tant qu’employé, j’ai besoin de soumettre mes heures 1
prestées (timesheets) au responsable pour la validation
 Suivi des heures prestées : Dans chaque projet le Manager peut suivre
l’avance de chaque tâche par rapport à ses heures prestées.
 Validation des timesheets : Le manager a le droit de refuser ou de
valider les heures prestées, et les soumettre à la facturation.
 Les factures : Le manager peut imprimer et envoyer les factures aux
clients, après la validation de ces derniers.

2.3.2. Conception
Ce diagramme au-dessus montre les différents cas d’utilisation du

sixième Sprint et qui sont destinés pour un Manager RH
Figure 56 : Diagramme de cas d’utilisation du Développeur
Cette figure représente les fonctions du dernier incrément et qui sont

destinés pour l’employé

VI.2.3.2.2. Vue séquentielle

Les diagrammes de séquences de cette partie sont très similaires aux
sprints précédents, nous allons nous limité à un seul diagramme.
Figure 57: Diagramme de séquence de la gestion des Factures


Ce diagramme représente le dernier diagramme de classes de la gestion des

projets, les nouvelles classes qui sont :
 Project_meeting : pour gérer les Daily Scrum et les différentes
rencontres qui se font au niveau de chaque Sprint.
 Actor : Représente les acteurs de chaque histoire utilisateur
2.3.3. Réalisation
2.3.3.1. La création et l’envoie des factures
Figure 59: La création de la facture
Cette Capture représente une facture qui est créé par le responsable
en sélectionnant un ensemble des heures prestées, en cliquant sur une
facture on peut l’imprimer ou bien la modifier.

2.3.3.2. Suivi des heures prestées
Figure 60: Les heures prestées d’une tache
Cette capture montre le fait de visualiser l’avancement au niveau de

chaque tâche en comparant son estimation avec le total de ses heures
prestées
2.3.4. Conclusion
Dans ce chapitre nous avons analysé, conçu, réalisé et testé le deuxième
release du projet, il est alors maintenant potentiellement livrable.

Conclusion générale et perspective
Ce stage a été sous plusieurs aspects riches d’enseignements, nous

avons commencé dans un premier lieu par comprendre le contexte général
de notre application et identifier les différentes exigences de notre futur
système. Nous avons préparé par la suite notre planning de travail en
respectant les priorités de nos besoins suite à une discussion entre l'équipe.
Dans le cadre de mon projet de fin d’études, nous avons conçu et
développé une solution qui permet de gérer la totalité des ressources liées aux
projets sous la méthode Scrum. Le présent manuscrit détaille toutes les étapes
par lesquelles nous sommes passés pour arriver aux résultats attendus. Nous
avons essayé tout au long de notre travail de construire notre application
incrément par incrément en utilisant la méthodologie Scrum.
À l'heure actuelle, l'application est prête à être utilisée, on peut donc
affirmer que le but qui m’avait été fixé a été atteint. Le contact avec le monde
de la recherche m’a permis de progresser dans de nombreux domaines,
notamment sur le thème de l’analyse de données.
On est satisfait du travail réalisé durant ce stage, tous les principaux
objectifs ont pu être atteints. Le travail que nous avons réalisé devrait être mis
en production durant le mois de juillet. Ce stage m’a permis d’approfondir et
mettre en pratique les connaissances acquises durant mon cursus à l’ENSA de
Tétouan. J’ai également découvert le travail avec la méthode Scrum ainsi la
programmation en Python et JavaScript avec la plateforme Odoo.
Finalement, mon travail ne s’arrête pas à ce niveau, en effet plusieurs
fonctionnalités peuvent être ajoutées notamment les rapports.
En conclusion, mon stage m'a permis de mettre en œuvre des compétences
scolaires, professionnelles et humaines pour un sujet intéressant. J'ai de plus
acquis de nouvelles dans le domaine du développement de l’entreprise.

Bibliographie et webographie
Bibliographie
o Daliel Reis – Odoo developpement essentials

o Openerp - Openerp technical memento
o Nicolas Bessi - Odoo new API guideline Documentation
o Marijn Haverbeke – Eloquent Javascript
Webographie
o https://www.odoo.com/documentation/8.0/ [2015-02-28]
o https://doc.odoo.com/ [2015-03-01]
o https://www.odoo.com/documentation/8.0/howtos/
[2015-04-02]
o http://useopenerp.com/v8/ [2015-03-15]
o https://apps.openerp.com/apps [2015-03-01]
o https://www.odoo.com/fr_FR/forum/help-1 [2015-03-15]

Rapportdestagepfe 150814172635 Lva1 App6892

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapportdestagepfe 150814172635 Lva1 App6892

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de Projet de Fin d’Études

pour l’obtention du Titre

D’Ingénieur d’État en Informatique

La mise en place d'une solution pour la

M. TABII Youness Encadrant ENSATé

M. LAZAAR Mohammed Professeur

M. CHRAYAH Mohamed Professeur

Année universitaire 2014-2015

2 École Nationale Des Sciences Appliquées De Tétouan 2015

A mon père, Aucune dédicace ne saurait exprimer l’amour,

A toutes ma famille, pour leurs soutiens, leurs conseils partagés

Au staff professoral de l’ENSA Tétouan, je serais vaniteux si je me

Au personnel administratif de l'ENSA Tétouan et à sa tête M.

3 École Nationale Des Sciences Appliquées De Tétouan 2015

Avant de commencer à rédiger mon rapport, je tiens à adresser

Je saisie cette occasion pour remercie Mr TABII Youness notre

J'adresse mes sincère remerciement à Mr HILALI Redwan, EL

Je n'oublie pas de remercier chaleureusement mes Parents et mes

Je tiens mes chaleureux remerciements, aux soldats de fond, et à

4 École Nationale Des Sciences Appliquées De Tétouan 2015

Durant les quatre mois, ma mission consiste à développer une application de

L’application va permettre aux équipes de développement de collaborer sur

Ce rapport se propose de décrire les différentes étapes par lesquelles le projet

5 École Nationale Des Sciences Appliquées De Tétouan 2015

During the four months, my mission is to develop a project management

The application will allow development teams to collaborate on projects

6 École Nationale Des Sciences Appliquées De Tétouan 2015

Table des matières

TABLE DES MATIERES............................................................................................................................... 7

LISTE DES FIGURES ................................................................................................................................... 9

LISTE DES TABLEAUX ............................................................................................................................. 12

LISTE DES ABREVIATIONS ..................................................................................................................... 13

INTRODUCTION GENERALE .................................................................................................................. 14

CHAPITRE 1 : PRESENTATION GENERALE DU PROJET ...................................................................... 15

1. STRUCTURE ET ORGANISATION DE 4D........................................................................................................ 16

CHAPITRE 2 : LA METHODE SCRUM ................................................................................................ 30

1. COMPARAISON DES PROCESSUS DE DEVELOPPEMENT................................................................................ 31

CHAPITRE 3: TECHNOLOGIES UTILISES ................................................................................................ 50

1. EXIGENCE DU PROJET .............................................................................................................................. 51

3. OUTILS UTILISES ........................................................................................................................................ 57

CHAPITRE 4: LES RELEASES DU PROJET SCRUM .................................................................................. 63

1. PREMIER RELEASE .................................................................................................................................... 64

CONCLUSION GENERALE ET PERSPECTIVE ....................................................................................... 106

BIBLIOGRAPHIE ET WEBOGRAPHIE .................................................................................................... 107

8 École Nationale Des Sciences Appliquées De Tétouan 2015

Liste des figures

9 École Nationale Des Sciences Appliquées De Tétouan 2015

Figure 39 : Diagramme de cas d’utilisation du Manager - Sprint 2 ................................ 74

10 École Nationale Des Sciences Appliquées De Tétouan 2015

Figure 74: Les heures prestées d’une tache..................................................................... 105

11 École Nationale Des Sciences Appliquées De Tétouan 2015

Liste des tableaux

12 École Nationale Des Sciences Appliquées De Tétouan 2015

Liste des abréviations

UML Unified Modeling Language

API Application Programming Interface

HTML Hypertext Markup Language

Ajax Asynchronous JavaScript and XML

MVC Model Controller View

DAO Data Access Object

IDE Integrated Development Environ ment

ORM Object Relational Mapping

SQL Standard Query Language

SGBD Système de Gestion de Base Données