Rapportdestagepfe 150814170320 Lva1 App6891 PDF

Mmoire de Projet de Fin dtudes
pour lobtention du Titre
DIngnieur dtat en Informatique

Systme dinformation
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
Anne universitaire 2014-2015

Gestion de projets et gestion des ressources humaines
2 cole Nationale Des Sciences Appliques De Ttouan 2015

Ddicace
A ma mre, 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 tmoigne mon affection, mon ternel
attachement et qu'il appelle sur moi ta continuelle bndiction.
A mon pre, Aucune ddicace ne saurait exprimer lamour,

lestime, le dvouement et le respect que jai 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 trs chers frres, je vous remercie pour votre amour, votre
soutien et vos encouragements
A toutes ma famille, pour leurs soutiens, leurs conseils partags
Au staff professoral de lENSA Ttouan, je serais vaniteux si je me

devais numrer en ces quelques lignes vos remarquables qualits
humaines et professionnelles. Veuillez trouver ici l'expression et le
tmoignage de ma gratitude ressentie
A tous mes chers amis, pour le soutien que vous maviez offert, je
vous dis MERCI
Au personnel administratif de l'ENSA Ttouan et sa tte M.

Kamal Eddine ELKADIRI, de nous avoir prpar atteindre ce stade
qui ma permis de confronter la vie professionnelle travers ce stage

Remerciement
Avant de commencer rdiger mon rapport, je tiens adresser

mes sincres remerciements aux personnes qui m'ont permis de mener
bien mon travail par leurs sincres 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'itinraire suivre pour arriver bout de
ce travail.
J'adresse mes sincre remerciement Mr HILALI Redwan, EL

BOUKHARI EL KHAMLICHI Mohammed Amine, et EL MAROUFI
Amine pour lencadrement de ce travail, pour leurs conseils, leurs
critiques, leurs encouragements, leurs disponibilits ainsi que pour
mavoir accueilli et donn les moyens pour accomplir ce stage dans les
meilleurs conditions.
Je n'oublie pas de remercier chaleureusement mes Parents et mes

frres et mes amis pour leurs soutiens.
Je tiens mes chaleureux remerciements, aux soldats de fond, et

tous ceux qui ont contribu de prs ou de loin l'achvement de ce
travail, leur tte mes parents, mes professeurs et mes amis.

Rsum
Ce rapport dcrit le travail que jai ralis dans le cadre de lobtention de mon
diplme dingnieur dtat en Systmes dinformations lEcole Nationale des
Sciences Appliques Ttouan, il sest droul du 3 Mars au 05 juin 2015 effectu au
sein de la socit 4D Logiciel Maroc Rabat.
Durant les quatre mois, ma mission consiste dvelopper une application de

gestion de projet, et gestion des ressources humaines agile avec la plateforme Odoo
dans un cadre de dveloppement agile.
Lapplication va permettre aux quipes de dveloppement de collaborer sur

des projets pilots selon la mthodologie agile Scrum et au dpartement ressources
humaines de bien grer ses collaborateurs. Le but de lapplication est de faciliter le
pilotage des projets et la gestion des ressources humaines en offrant une version
numrique des nombreux artefacts de la mthode Scrum (Backlog, Histoires utilisateur,
Itrations, Taches, Taskboard, contrats etc.)
Ce rapport se propose de dcrire les diffrentes tapes par lesquelles le projet

a pass dans le but datteindre 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 matires

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. Aperu de 4D ...................................................................................................................... 16
1.2. Larchitecture de lentreprise ............................................................................................ 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 lexistant ............................................................................................................... 22
3.2. Problmatique ..................................................................................................................... 25
3.3. La solution propose ........................................................................................................... 26
3.4. Dmarche 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. Mthodologie de dveloppement : La dmarche 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 dveloppement .................................................................................................. 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, reprsentants et distributeurs locaux de 4D (source rf 1) ................. 18
Figure 5: Lorganigramme de lentreprise 4D logiciels ................................................ 18
Figure 6: L'historique des versions dOdoo ......................................................................... 22
Tableau 7: Comit de pilotage du projet .......................................................................... 28
Tableau 8 : Comit du projet ............................................................................................... 28
Tableau 9: Tableau comparative des diffrents cycles de vie ....................................... 36
Tableau 10: Comparaison des mthodologies de dveloppement [Sutherland] ...... 38
Tableau 11: Les diffrents roles dans la mthode 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 4me Sprint .................................................................. 48
Figure 18: Architecture MVC ................................................................................................ 52
Figure 19: Intrt de recherche odoo/openerp/tinyerp.................................................. 53
Figure 20: Intrt de recherche odoo/netsuite/xtuple/compiere.................................. 54
Figure 21: Nombre de rsultats sur le nombre de recherche Google pour odoo ....... 54
Figure 22: Nombre de rsultats 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 dutilisation dun utilisateur Sprint 1 ............................ 67
Figure 33: Diagramme de cas d'utilisation du Manager Sprint 1 ................................. 67
Figure 34: Diagramme de cas d'utilisation de ladministrateur Sprint 1 ...................... 67
Figure 35: Diagramme de squence de la gestion des projets ...................................... 68
Figure 36 : Diagramme de squence 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 dutilisation du Manager - Sprint 2 ................................ 74

Figure 40: Diagramme de squence de la gestion des projets ...................................... 75
Figure 41 : Diagramme de squence du cas d'utilisation : Dfinir la vlocit .............. 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 dutilisation du Manager ................................................ 81
Figure 46 : Diagramme de cas dutilisation du Dveloppeur ......................................... 81
Figure 47: Diagramme de squence de la gestion des Taches ..................................... 82
Figure 48: Diagramme de classes sprint3 ........................................................................... 83
Figure 49: La gestion des taches ......................................................................................... 84
Figure 50: Lajout des membres de lquipe ..................................................................... 84
Figure 51 : Laffectation de la tache .................................................................................. 85
Figure 52 : Laffichage 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 dutilisation du Manager .............................................. 89
Figure 57 : Diagramme de cas dutilisation de lemploy ............................................... 89
Figure 58: Diagramme de squence de la gestion des Taches ..................................... 90
Figure 59: Diagramme de classes sprint 4 : Gestion de congs ..................................... 91
Figure 60: Gestion des congs ............................................................................................. 92
Figure 61: La validation des demandes de congs ......................................................... 92
Figure 62: Linscription ........................................................................................................... 93
Figure 63 : Diagramme de cas dutilisation du Dveloppeur ......................................... 96
Figure 65 : Diagramme de cas dutilisation de ladministrateur ..................................... 96
Figure 66: Diagramme de squence du pointage de lemploy .................................. 97
Figure 67: Le pointage entre/sortie ................................................................................... 98
Figure 68: Les templates des contrats clients ..................................................................... 99
Figure 69 : Diagramme de cas dutilisation du Manager .............................................. 101
Figure 70 : Diagramme de cas dutilisation du Dveloppeur ....................................... 101
Figure 71: Diagramme de squence de la gestion des Taches ................................... 102
Figure 72: Diagramme de classes sprint3 ......................................................................... 103
Figure 73: La cration de la facture .................................................................................. 104

Figure 74: Les heures prestes dune tache..................................................................... 105

Liste des tableaux

Tableau 1 : Comit de pilotage du projet ......................................................................... 28
Tableau 2 : Comit du projet ............................................................................................... 28
Tableau 3 : Tableau comparative des diffrents cycles de vie ...................................... 36
Tableau 4 : Comparaison des mthodologies de dveloppement [Sutherland] ....... 38
Tableau 5 : Les diffrents roles dans la mthode Scrum .................................................. 41
Tableau 6 : Dscription des cas dutilisation.......33

Liste des abrviations

Abrviation Dsignation
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 Systme de Gestion de Base Donnes
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 Gnrale
Les entreprises en dveloppement logiciel sont en croissance constante
et poursuivent le but de livrer du logiciel de qualit qui rpond au besoin de
lutilisateur, dans les temps prescrits par le client. Afin de rpondre ces
critres, les entreprises doivent utiliser des processus de dveloppements
logiciel stricts. Il y a plusieurs processus disponibles qui apportent leurs
avantages et leurs inconvnients. Depuis quelques annes, lutilisation de la
mthodologie SCRUM semble gagner en popularit, mais peu dentreprises sy
aventurent.
SCRUM prsente une solution intressante pour les grandes entreprises
qui aimeraient gagner en flexibilit. En utilisant une mthode volutive de
dveloppement qui implique une plus grande participation du client dans le
processus de dveloppement, les deux parties voient leurs chances de succs
augmentes proportionnellement la qualit de leurs communications et de
leurs relations. En utilisant la mthodologie SCRUM dans les grandes entreprises,
la qualit du logiciel est accrue et les nouveaux besoins commands par la
ralit changeante du client sont considrs tout au long du processus. Une
synergie qui gagnerait tre reconnue.
Mon projet de fin dtude consiste mettre en place une application
de gestion de projet SCRUM en utilisant la plateforme Odoo de
dveloppement.
Ce rapport est structur comme suit : Le premier chapitre prsente le
contexte gnral du projet, le produit Odoo ainsi que les objectifs gnraux de
ce projet. Nous allons consacrer la seconde prsenter le cadre de
dveloppement agile dans lequel jai pu travailler. Cette partie permettra de
se familiariser avec la mthodologie SCRUM et son vocabulaire particulier. La
troisime partie exposera le projet, enfin la dernire partie prsentera les
technologies et les logiciels dont nous avons pu nous servir durant cette mission
ainsi le travail ralis durant chacune des itrations du projet.

Chapitre 1 : Prsentation gnrale du projet
I- Prsentation de lorganisme daccueil

II- Contexte gnrale du projet
III- Conclusion

Le contexte gnral du projet est une tape primordiale pour la

connaissance de lenvironnement dans lequel sest droul le stage de fin
dtudes ainsi que la prsentation du projet. Ce chapitre sera consacr tout
dabord la prsentation de lentreprise 4D au sein duquel jai effectu mon
projet.
Et par la suite une prsentation de contexte gnrale du projet que ma

confi 4D comme projet de fin dtudes. Cette prsentation inclura une tude
de lexistant, lvocation des problmatiques que javais traiter, la solution
que jai propose et le planning que javais suivi pour la ralisation de ce projet.
1. Structure et organisation de 4D
1.1. Aperu de 4D
Dun capital de 2 millions deuros et dont le sige social se situe Clichy

(Ile de France), la socit dtenue majoritairement par son fondateur ne
regroupe pas moins de 180 collaborateurs rpartis travers le monde au sein
de ses filiales internationales. La socit 4D est en effet prsente aux Etats-Unis,
au Japon, en Grande-Bretagne, en Allemagne, en Sude, en Espagne ainsi
quen Australie. Sa prsence travers le monde est renforce par son rseau
de distribution implant dans plus de 40 pays.
Cre en 1984, 4D se distingue sur le march informatique en

introduisant le premier systme de gestion de bases de donnes relationnelles
graphique dnomm 4D . Le produit continue son volution pour proposer
en 1987 :
un client-serveur intgr
un serveur Web intgr
un systme de partage d'applications dynamiques intgr

En 1997, 4D investit dans Internet en intgrant un serveur Web

dynamique, permettant aux dveloppeurs 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 dveloppeurs

de crer la fois des applications autonomes, client-serveur, ainsi que des
applications orientes Services (SOA) et Web sans aucune modification de
code. Plus rcemment, 4D a cr la premire plateforme de
dveloppement end-to-end JavaScript permettant de crer 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 ncessaires pour rivaliser tous les
niveaux, tout en offrant une valeur ajoute ingale et un cot de possession
faible.
4D compte plus de huit filiales linternational et de nombreux

distributeurs et reprsentants locaux dont 4D Logiciels Maroc fait partie. Les
mtiers prsents 4D Logiciels Maroc sont similaires voir identique ceux de
la filiale en France, et ce, allant du Support Technique et Dveloppement
jusquau Contrle 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 ncessaires pour rivaliser tous les
niveaux, tout en offrant une valeur ajoute ingale et un cot de possession
faible. 4D offre galement des fonctionnalits bases sur les nouvelles

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

ascendante qui permet de prenniser les investissements des clients.
Figure 4: Filiales, reprsentants et distributeurs locaux de 4D (source rf 1)
1.2. Larchitecture de lentreprise

La figure ci-dessous reprsente lorganigramme de lentreprise 4D logiciels .
Figure 5: Lorganigramme de lentreprise 4D logiciels

2. La plateforme Odoo
Odoo est un progiciel de gestion d'entreprise (ERP) destin intgrer
l'ensemble des donnes oprationnelles et de gestion de l'entreprise dans une
base de donnes unique, accessible par une interface web.
Cette base de donnes centrale est associe une couche

fonctionnelle trs innovante qui met en relation des informations d'origines
diverses et assure un droulement efficace des processus transversaux de
cration de valeur ajoute de l'entreprise.
Odoo, anciennement OpenERP et Tiny ERP, est la base un progiciel

libre de gestion intgr comprenant de trs nombreux modules permettant de
simplifier la gestion dentreprise dans son ensemble. Le logiciel est sous licence
AGPL et est utilis par plus de 2 millions dutilisateurs travers le monde.
lorigine un ERP, le logiciel sest vu tendre ses fonctionnalits des

applications de front office (CMS, e-Commerce, Blogs, Forums, News,
vnements, LiveChat, Job offers, etc). Il apporte les applications mtier dont
chacun a besoin dans l'entreprise.Cette approche modulaire facilite
l'intgration de nouvelles fonctionnalits sous la forme de modules
complmentaires.
2.1. Principales applications logicielles front office

Crateur de site web et systme 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 dpenses
Gestion des documents
Gnrateur de factures
Gestion et outils marketing
2.3. Modules d'Odoo

Laspect libre du logiciel a permis le dveloppement de nombreux
modules tiers crs par sa communaut de dveloppeurs. Ces applications
sont pour certaines officiellement valides par lditeur tandis que dautres ne
sont destines qu des versions spcifiques.
Architecture logicielle
La conception d'Odoo est oriente par une architecture MVC, des flux
de travail flexibles, une interface-utilisateur graphique dynamique, une
interface de communication interne XML-RPC, et un systme personnalisable
de comptes-rendus.
Dun point de vue de larchitecture 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 donnes 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 annonait 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 dcembre 2012, la version 7.0 d'OpenERP est lance et peut tre

teste en ligne, tlcharge ou vue en version de dmonstration. 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 dOdoo un logiciel allant au-del
d'un ERP. Ces applications sont: Marketing (gestion d'vnements,
d'enqutes de satisfactions, campagnes de mails auprs de la CRM,...), CMS
(construction d'un site internet - front-end li au back-end - grce au
dplacement rapide et simple de 'blocs" d'ditions), e-commerce
(application pour vente en ligne),...
Premire version stable : 2004

Version stable actuelle : 8.0
Version avance : 9.0

Anciennes versions ou fin de maintenance

Anciennes versions avec maintenance tendue
Version actuelle
Versions en cours de dveloppement
Figure 6: L'historique des versions dOdoo

3. Contexte gnrale du projet
3.1. Etude de lexistant
3.1.1. Prambule
Le but de ltude de lexistant est de dterminer les points faibles et les
points forts dun produit actuel pour pouvoir dterminer les besoins du client,
en vue den prendre en considration lors de la conception et la ralisation de
la solution. Dans cette section, nous prsentons une analyse des modules
propose par la communaut Odoo, et du logiciel Jira. Ensuite, nous
formulerons une solution de la problmatique.

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 quil 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 cot est drisoire pour les
petites quipes.
Inconvnients 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 lexploitation des donnes de
production dans les rapports et la gestion de ressources humaines, et donc 4D
sent quil est dispers puisquil doit utiliser aux moins deux solution pour
rpondre 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
jusquau niveau le plus dtaill, Ce module permet de :
Dfinir des projets / tches associs un responsable

Suivre chaque tche / projet selon son avancement : formulaire, Gantt
Gnrer la facturation conditionnelle, selon l'avancement

Grer la relation avancement / temps pass (feuilles de saisie des

heures)
Assurer un suivi budgtaire analytique du projet, associ la
comptabilit analytique
Un projet contient des informations gnrales, relies la comptabilit

analytique, au partenaire, etc. Ce sont les tches qui font le projet. Chaque
tche peut tre constitue de plusieurs tapes.
Ce module offre plusieurs fonctionnalits pour les entreprises dans diffrents

secteur
i. Les avantages du module standard de Odoo

Odoo Project Management permet de dfinir des projets / tches associs
un responsable Suivre chaque tche / projet selon son avancement :
formulaire, Gantt, gnrer la facturation conditionnelle selon l'avancement,
grer la relation avancement / temps pass (feuilles de saisie des heures), et
assurer un suivi budgtaire analytique du projet, associ la comptabilit
analytique...
Les fonctionnalits prsentes ne sont ni exhaustives, ni figes. 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 modle qui permet de gnrer un projet (un

projet peut aussi tre converti en template) Ce projet se compose de tches
qui vont tre accomplies en excutant des travaux. Lorsque qu'une tche est
termine, les travaux qui ont t inscrits dans cette tche sont transfrs dans
la timesheet (feuille de temps) du collaborateur, lorsque le collaborateur valide
sa timesheet, ses travaux sont transfrs dans la comptabilit analytique et
peuvent gnrer une facturation.

Un projet contient des informations gnrales, relies la comptabilit

analytique, au partenaire, etc. Ce sont les tches qui font le projet. Chaque
tche peut tre constitue de plusieurs tapes.
Le planificateur vous aide planifier les tches et tapes, en fonction de la

disponibilit de vos ressources. Il est possible d'changer des e-mails lis votre
projet, pour communiquer avec votre quipe, les clients et les fournisseurs. Un
outil collaboratif permet d'changer et de partager les tches avec les clients.
Vous pourrez suivre les problmes, demandes d'assistance, questions sur les
projets tout en surveillant votre qualit de service.
ii. Les inconvnients du module standard de gestion de projets

Parmi ces limites cest quil ne supporte pas la mthode Scrum avec toutes
ses notions (User story, Sprint ), il y a aussi la complexit du module Odoo qui
ne facilite pas la tche pour lutilisateur.
3.2. Problmatique
Daprs ce que nous avons vu, parmi les problmes que nous pouvons citer
cest :
Perte du temps
Surtout il ny a pas de coordination entre lquipe et les ressources

humaines pour bien grer le temps, et ne pas tre dispers.
Perte dargent
Pour que la socit peut satisfaire ses besoins il doit avoir au moins 2
solutions
Inefficacit :
Tant quil n y a pas une solution qui inclut la gestion de ressources humaines
et la gestion de projets alors les indicateurs ne seront plus reprsentative du
rendement rel des membres de chaque quipe, ce qui implique une
inefficacit de la solution.

Perte dopportunits
Une mal gestion peut conduire la perte des projets, et par consquent
la perte du client.
Exploitation des donnes de production
La socit ne peut pas exploiter ses donnes de production pour avoir

des indicateurs de la ralit et qui soient reprsentatives, par exemple dfinir
le rendement de chaque employ
La dmotivation
La dmotivation des employs qui vont souffrir de la routine du travail
3.3. La solution propose

Le projet a droul sur deux phases:
Le premier release tait consacre pour la formation sur la
mthode agile SCRUM et sur la plateforme de dveloppement
Odoo, et au ralisation de lensemble des fonctionnalits du
module de gestion de projets.
Le deuxime release tait ddie au dveloppement de

lensemble des fonctionnalits demands pour la gestion de
ressources humaines et faire la liaison entre les diffrents modules.
Dans le cadre de dveloppement de ce projet, on a travaill avec la
mthode SCRUM.
Lutilisation de la mthodologie SCRUM semble tre le mieux car le projet
pourra subir de nombreuses modifications durant le dveloppement, et pour
avoir plus de mtier sur le projet (c.--d. on va travailler dans un cadre de
dveloppement agile SCRUM pour dvelopper un outil SCRUM).
3.3.1 Principe de la solution

Pour rsoudre les problmes lis la gestion des projets, On a propos de
dvelopper une solution qui permet la gestion des projets en offrant une
interface ergonomique et dynamique, et qui intgre toutes les composants de

la mthode SCRUM pour exploiter les rsultats 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 dveloppement logiciel sont en croissance
constantes et poursuivent le but de livrer du logiciel de qualit qui rpond au
besoin de lutilisateur, dans les temps prescrits par le client. La problmatique
de celles-ci rside en lutilisation des mthodes de dveloppement
traditionnelles qui ne satisfont plus entirement aux besoins grandissants de
qualit.
SCRUM prsente une solution intressante pour les grandes entreprises qui
aimeraient gagner en flexibilit. En utilisant une mthode volutive de
dveloppement qui implique une plus grande participation du client dans le
processus de dveloppement, les deux parties voient leurs chances de succs
augmentes proportionnellement la qualit de leurs communications et de
leurs relations. En utilisant la mthodologie SCRUM dans les grandes entreprises,
la qualit du logiciel est accrue et les nouveaux besoins commands par la
ralit changeante du client sont considrs tout au long du processus. Une
synergie qui gagnerait tre reconnue.
Lentreprise 4D parmi plusieurs grandes entreprises a commenc de

travailler avec la mthodologie SCRUM afin de livrer des produits de qualits
qui rpondent aux besoins des clients.
Lobjectif principal de mon projet de fin dtude est de rendre un produit

qui va faciliter le pilotage des projets raliss par la mthode SCRUM agile,
aussi la gestion de ressources humaines et de facturation au sein de
lentreprise. Le dveloppement de lapplication va tre conu par la solution
Odoo (prsenter dans la partie prcdente).

3.4. Dmarche 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) Ingnieur

MAROUFI - Spcification fonctionnels
M. Amine EL - Product owner Ingnieur
BOUKHARI EL - Spcifications Techniques
KHAMLICHI
Tableau1: Comit de pilotage du projet
Ce tableau rsume les diffrents membres de lquipe de pilotage du projet
Personne Role Function

M. DAMIR - Participation aux Spcifications Elve Ingnieur
Ayyoub techniques et fonctionnels System
- conception et codage de la dinformation
solution Ecole Nationale des
- Tests et mise en place de la solution Sciences Appliques
de Ttouan
Tableau 2 : Comit du projet
Ce tableau rsume les diffrents membres de lquipe des participants au

dveloppement du projet
4. Conclusion
Dans ce chapitre qui prsente le contexte gnral du projet, on a inaugur
le chapitre par une prsentation de lorganisme daccueil 4D, dans la
deuxime partie du chapitre on a prsent le contexte gnrale du projet en
commenant par une tude de lexistant, puis on a voqus les

problmatiques traiter, aprs on a pass la solution quon avait propose

pour la rsolution des problmatiques. Et vers la fin de cette partie on a voqu
la dmarche que nous avions suivie pendant la rsolution du projet ainsi que
la planification de ce dernier. Le chapitre suivant est consacr pour la
mthode Scrum.

Chapitre 2 : La mthode Scrum
I- Comparaison des processus de

dveloppement
II- Choix du processus de
dveloppement
III- La mthode Scrum
IV- Pilotage du projet avec Scrum
V- Conclusion

1. Comparaison des processus de dveloppement

Le bon choix du processus de dveloppement logiciel conduit la
bonne ralisation du projet, cest pour cette raison nous avons fait rfrence
une comparaison entre les principaux processus de dveloppement, 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 spcification a
utiliser lavance des t trs bien
Adapt pour une travaux faite
quipe Pas dinteraction La dfinition du
inexprimente entre les phases de produit est
Les limites de dveloppement stable
chaque tape Lintgration na Il sagit dune
sont visibles lieu qu la fin du nouvelle version
Facilite un cycle dun produit
management du existant
projet Le client peut se Limplantation
retrouver non dun produit
La dfinition des satisfait existant sur une
besoins est non- Pas de retour en nouvelle plate-
volutive arrire dune forme
phase lautre Une bonne
La qualit prime matrise de la
sur le cot technologie
EN V Les
Facile utiliser Une mauvaise spcifications
prise en compte de besoins
des vnements doivent tre
Les tests sont concurrents bien faites
effectus La solution
chaque tape Le processus nest dvelopper et la
pas itratif technologie

utiliser doivent
Le contrle se fait Une mauvaise tre
progressivement prise en compte parfaitement
chaque tape des changements connues
de la spcification Les
des besoins changements
Les phases de doivent tre faits
validation sont Ne contient pas avant lanalyse
prises en main trs les activits Excellent pour
tt dans le danalyses de les systmes
processus de risques requrant une
dveloppement grande sret
EN SPIRALE Sans cot lev, les cots et
donne des Le temps lvaluation des
indications sur les consacr risques est
risques majeurs lvaluation des important
Les fonctions risques est trop pour des projets
critiques haut lev pour des risque au
risque sont petits projets moins
dveloppes en Le temps mis moyennement
premier lieu planifier, valuer lev
La conception ne les risques, fixer les pour des projets
doit pas forcment objectifs, les long terme
tre termine prototypes peut dont les
Les utilisateurs tre excessif financements
finaux sont Ce modle est peuvent varier
intimement complexe les utilisateurs ne
associs toutes Une expertise en dfinissent pas
les tapes du valuation des clairement leurs
dveloppement risques est besoins
Le ncessaire la spcification
dveloppement La spirale peut des besoins est
se fait en tre infinie complexe

interaction avec les dveloppeurs il sagit dune

les clients travaillent par nouvelle
Lvolution du intermittence gamme de
cot de il est difficile de produits
dveloppement dfinir les objectifs des
est sous contrle et les points de changements
Les utilisateurs ont validation significatifs
ds le dpart une intermdiaires peuvent
vue globale du entre les intervenir
systme diffrentes tapes cause par
exemple de
lvolution de la
recherche ou de
lexploration
PAR les cots et

INCREMENT Le client peut lvaluation des
valider chaque risques est
tape du important
processus pour des projets
risque au
Utilise la mthode Require une moins
Diviser Pour Rgner bonne moyennement
planification et une lev
bonne conception pour des projets
La dlivrance du long terme
produit est rapide dont les
financements
peuvent varier
Le cot de les utilisateurs ne
lancement du Require la dfinissent pas
projet est moindre dfinition clairement leurs
complte des besoins
fonctionnalits du

Un produit systme pour une la spcification

exploitable peut dfinition des des besoins est
tre dlivr tout diffrents complexe
moment incrments il sagit dune
nouvelle
gamme de
Les clients produits
obtiennent les des
fonctionnalits changements
majeures du significatifs
systme trs tt Le cot total du peuvent
dveloppement intervenir
du systme nest cause par
Le risque du pas ngligeable exemple de
changement des lvolution de la
besoins est minimal recherche ou de
lexploration
Sur un projet
Dveloppe les Les diffrentes utilisant de
fonctions interfaces doivent nouvelles
primordiales ds le tre bien dfinies technologies
dpart Sur des projets
ayant une dure
de
dveloppement
assez longue
Scrum Scrum est centre Projets Scrum sans Pour les
sur le produit Product owner organisations
Progrs est actif et sans orientes
incrmental, acteurs produit, Scrum
facilement conomiques est un moyen de
mesurable et engags sera rvolutionner la
clairement visible probablement mthode dont ils
fiasco traitent ses

pour les acteurs Si le propritaire du affaires.

conomiques produit n'a pas Autrement dit,
Les dveloppeurs apprci Scrum, cest pour
fixeront le rythme, ne ou ne comprend augmenter la
sont pas surchargs pas le rle du productivit et
de travail, et propritaire de inspirer un
bnficient d'un rle produit, le succs engagement;
accru est plus difficile; Scrum dispose
La charge du Si le product owner du progrs
travail est rglable, ne fonctionne pas tangibles raliss
bas sur la avec les parties par le biais
capacit de prenantes de frquents, les
lquipe et la rendre le backlog versions de
priorit des taches complet avec production
raliser toutes les incrmentales
Les questions sont fonctionnalits, les (Sprints). En tant
gnralement dveloppeurs se que tel, il est
dcouvertes complaisant et idal pour les
avant qu'ils ne dsengag sorte start-ups en
deviennent que la productivit essayant
endmiques descend d'attirer et de
Lquipe a Si le propritaire du maintenir
lautorit de produit ne se
prendre des prsente pas ou
dcisions apprcier dette
Lquipe est technique
encourage articule par
consulter avec l'quipe, des
les entreprises problmes
Les tches ont techniques
tendance tre peuvent se
granulaire, et par suppurer
consquent, plus Si les dveloppeurs
ne pas co-localis

facilement ou porte de voix

testables du client et
Lquipe d'affaires, la
dveloppe une productivit va en
attitude get-it- souffrir
done Siloing de la
Lquipe est connaissance peut
implicitement crotre si Scrum-
encourage se Master nest pas
comporter attentif et lquipe
comme une start- ne corrige pas
up et l'approche eux-mmes
dfie les normes Rtrospectives de
organisationnelles. sprint sont inutiles si
l'quipe est pas
franche et
constructive
autocritique; et
L'approche dfie les
normes
organisationnelles.
Tableau 3: Tableau comparative des diffrents 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 dveloppement

En faisant liaison entre tableau comparatif et mon projet, le choix de
Scrum comme une mthodologie de pilotage pour ce projet sest bas sur les
atouts de ce dernier. Il se rsum comme suit:
Plus de souplesse et de ractivit
La grande capacit dadaptation au changement grce des itrations

courtes

Et la chose plus importante, cest que Scrum rassemble les deux cots
thorique et pratique et se rapproche beaucoup de la ralit

Les besoins de mon projet sont bien dfinit ds le dpart
La nature de cette mthode qui est bien organis et permet de tester et
valider chaque partie du projet avant de passer une autre
lutilisateur qui sera impliqu dans le dveloppement (Product owner)
Cascade Spirale Itratif Spirale
Processus dfini Requis Requis Requis Planificatio
n et fin
de projet
seulement
Produit final Dtermin durant la Dtermin Dfini durant Dfini
planification durant la le projet durant le
planification projet
Cot du projet Dtermin Partiellement Dfini durant Dfini
durant la Variable le projet durant le
Date de fin de Dtermin Partiellement Dfini durant Dfini
Projet durant la Variable le projet durant le
Adaptable Planification Planification la fin de En tout
lenvironnement seulement Seulement chaque temps
itration
Flexibilit et Limit approche Limit approche Limit Illimit
crativit de livre de recettes livre de recettes approche durant les
lquipe livre de itrations
recettes
Transfert de Formation avant Formation avant Formation Formation
Connaissance le dbut du projet le dbut du avant le entre les
projet dbut membres
du projet de
lquipe
durant le

Projet
Probabilit de Faible Moyen faible Moyen lev

Succs
Tableau 4: Comparaison des mthodologies de dveloppement [Sutherland]
3. La mthode Scrum
Comme pour toutes les fabrications, il est important davoir un procd
de fabrication du logiciel bien dfini et explicitement dcrit et document.
Les modles de cycle de vie du logiciel dcrivent un niveau trs abstrait et
idalis les diffrentes manires dorganiser la production. Les tapes, leur
ordonnancement, et parfois les critres pour passer dune tape une autre.
3.1 Approche agile

Depuis une quinzaine dannes, la majorit des dveloppements de
logiciels sappuie sur des mthodes dites agiles. Sous cette bannire se
regroupent plusieurs mthodes bases sur un dveloppement itratif et
incrmental, dans lequel la recherche de solutions aux problmes rencontrs
sappuie sur la collaboration de pair pair. Elle promeut des rponses rapides
et flexibles, une planification des tches adaptatives dans des laps de temps
trs courts permettant une trs grande ractivit.
Les approches plus classiques tels que cycle en V ou le modle en

cascade sont souvent mises en uvre pour les projets rpondant un
imposant cahier des charges. Le client et le prestataire sentendent alors sur un
contrat et si le projet prend du retard ou ne rpond pas tous les besoins la
date butoir, des pnalits sont alors factures au prestataire. De la mme
manire si le client saperoit en cours de route que certains besoins ont t
omis dans le cahier des charges, il devra alors rengocier avec le prestataire
le contrat.

Les premires mthodes agiles apparues sont EVO (Evolutionary Project

Management) (1976), RAD (dveloppement rapide d'applications) (1991), puis
DSDM, la version anglaise du RAD (1995). Les trois mthodes agiles dsormais
les plus utilises sont : la mthode Kanban, issue de la mthode industrielle
Lean, la mthode Scrum publie en 2001 par Ken Schwaber et Jeff Sutherland,
et la mthode XP (Extreme programming) publie en 1999 par Kent Beck.
3.2. Pourquoi Scrum ?

On propose maintenant de zoomer sur lune des mthodes Agile
existantes afin de vous montrer plus concrtement le fonctionnement.
Pourquoi traiter de Scrum en particulier ? Tout simplement parce que Scrum est
de trs loin la mthodologie la plus utilise parmi les mthodes Agile existantes.
Elle est donc la plus prouve, documente et supporte. Livres, blogs,
formations, vidos, associations, confrences traitant de Scrum ne manquent
pas et bon nombre de ces ressources sont accessibles gratuitement. On
pourrait pratiquement parler dun standard Agile. Un autre atout important :
Scrum est simple comprendre. Sa matrise est en revanche difficile.
Les experts de Scrum, mme ses fondateurs, le dcrivent comme un

cadre de travail permettant de rpondre des problmes complexes et
changeants tout en livrant de manire productive et crative des produits de
la plus grande valeur possible Scrum propose un modle de contrle 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 comprhension du projet.
L'inspection : Scrum propose de faire le point sur les diffrents artfacts

produits intervalle rgulier, afin de dtecter toute variation indsirable.
L'adaptation : Si une drive est constate 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 dtailler dans la section suivante.
4. Pilotage du projet avec Scrum

Commenons tout dabord par prsenter la mthode dans sa globalit
afin de se familiariser avec le vocabulaire de Scrum.
4.1 Fonctionnement de Scrum

La premire tape consiste effectuer une premire planification de
litration ou Sprint Planning dans le jargon des dveloppeurs. Cette runion
fera ressortir les lments prioritaires de la liste des exigences fonctionnelles du
produit. Chaque exigence reprsente une User Story ou "histoire utilisateur".
En accord avec le client, aussi appel Product Owner, les premires

livraisons devraient tre effectues la fin de cette itration (qui dure de 2 4
semaines suivant le nombre des user stories prsentent dans le Backlog). Le
backlog est l'ensemble des US dvelopper durant l'itration en cours.
Une autre runion appele Revue de Sprint ou Sprint Review est

organise la fin de chaque Sprint durant laquelle les dveloppeurs
prsentent au client les fonctionnalits dveloppes. Ce dernier pourra ainsi
tout de suite donner son feedback, ce qui prsente lavantage de gagner
beaucoup de temps et dajuster les fonctionnalits ou les mthodes de travail
le cas chant.
Vient ensuite une rtrospective de Sprint ou Sprint Restrospective qui

permet tous les acteurs damliorer des choses et de samliorer galement.
Une autre particularit de la mthode Scrum est la ralisation de mles
quotidiennes ou Daily Scrum qui permettent lquipe de dveloppeurs de
synchroniser leur travail. Cette runion qui ne dure pas plus de 15 minutes
permet chacun de dterminer ce quils ont ralis depuis la dernire mle,
de ce quils auront terminer avant la prochaine Daily Scrum et didentifier les
obstacles qui pourraient les bloquer.
La figure 12 rsume le processus de fonctionnement de la mthode Scrum.

4.1.1 Lquipe et Rles

Le Framework Scrum consiste en la dfinition des rles projets, activits
ou artefacts, et runions ou vnements, bref il dfinit trois rles qui sont :
Description
Scrum - Agit comme un facilitateur.
Master - Sassurer de fournir lquipe Scrum, tout le ncessaire leur plein
potentiel.
- Cest un coordonnateur de ressources, un intermdiaire et non pas
un dirigeant.
Product - Cest le reprsentant des clients et des utilisateurs

Owner - Dfinir l'ordre dans lequel les fonctionnalits seront dveloppes
- Expliciter les user Stories du backlog du produit
- S'assure que le backlog du produit est visible et compris de l'quipe
de dveloppement.
Scrum - Se constitue des personnes qui seront charges dimplmenter les
team diffrents besoins du client
- des dveloppeurs, des infographistes, des testeurs, etc.
- Spcifications Techniques
Tableau 5: Les diffrents roles dans la mthode Scrum
Figure 7: Le processus du Framework Scrum
Ce shma xplique le fonctionnement et larchitecture de la mthode Scrum

4.1.2. Les vnements

Toutes les activits (sprint, runions de planning, revues, rtrospectives et
mles) dcrites dans le Framework Scrum sont effectues lors de boites de
temps.
Le sprint : est une priode (constante) d'un mois au maximum, au bout

de laquelle l'quipe dlivre un incrment du produit, potentiellement livrable.
Un nouveau sprint dmarre ds la fin du prcdent. Chaque sprint est associe
une liste d'lments du backlog du produit raliser durant ce sprint. Pour
notre projet la dure du sprint sera fixe 2 semaines.
Daily scrum : Cest une runion de planification qui dure 15 minutes et permet
aux dveloppeurs de faire un point de coordination sur les tches en cours et
sur les difficults rencontres.
Sprint planning Meeting : Toute l'quipe Scrum est prsente cette runion, qui
ne dure plus de 4 heures pour notre cas, pour planifier les user stories du
backlog du produit qu'elle a dcid de traiter pendant la prochaine itration
et comment elle s'organisera pour y parvenir.
Sprint review : la fin du sprint, l'quipe Scrum et les parties-prenantes invites

se runissent 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 dmonstration du logiciel produit.
4.1.3. Les artefacts

Product Backlog : Lapproche Scrum propose de commencer par lister les
exigences du client afin de produire le Product Backlog sous forme de liste
ditem 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 rsume le backlog produit de notre application qui contient

50 User Stories

En tant que Je voudrais

1 Utilisateur s'authentifier afin daccder
l'application
2 Utilisateur Grer mon profile
3 Utilisateur Consulter le Dashboard selon mes
permissions
4 Administrateur Grer les permissions
5 Manager Grer les projets
6 Manager Grer les sprints
7 Manager Grer les user stories
8 Manager Dfinir la vitesse de l'quipe (Velocity)
9 Manager Grer les taches
10 Manager Affecter les tches aux membres d'quipe
11 Dveloppeur Grer 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 Grer les templates du contrat employ.
16 Administrateur Grer les templates du contrat des clients.
17 Manager Grer les congs
18 Manager Dfinir les soldes congs pour chaque
employ et les journes de rcupration
19 Manager Grer les demandes de congs.
20 Manager Afficher les rsums des congs
21 Manager Suivre les prsences/absences
22 Manager Grer les pointages (entrs/sorties)
23 Manager Evaluer les employs
24 Manager Suivre l'volution des heures prstes
(timesheets) sur une tche ou projet
25 Manager Grer les clients.
26 Manager Grer les contrats des clients
27 Manager Imprimer ses feuilles de prestations
28 Manager Valider/refuser les heures prestes.

29 Manager Grer les contrats des employs

30 Manager Grer les comptes analytiques associs
aux projets
31 Manager Soumettre les heures prestes pour la
facturation.
32 Manager Crer 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 Grer mes tches.
36 Employ Afficher le burndown chart
37 Employ Demander un cong.
38 Employ Afficher une liste de mes congs avec
leurs tats.
39 Employ Pointer l'entr et la sortie.
40 Employ Crer les timesheets par tche.
41 Employ Consulter mes prsences/absences.
42 Employ Soumettre mes heures prestes
(timesheets) au responsable pour la
validation
43 Employ Afficher le rapport de mes tches.
44 Employ Imprimer mon contrat.
Tableau 6: Le Backlog du projet
Chaque ligne du Product backlog reprsente une User Story ou histoire

utilisateur. Les lments du backlog sont classs par priorit ce qui permet de
dfinir l'ordre de ralisation. Trs souvent les User Stories peuvent porter
galement des numros ID afin de les distinguer plus rapidement. Le backlog
est sous la responsabilit du Product Owner. Chacun peut contribuer
collecter des lments, mais c'est le Product Owner qui les accepte finalement
et c'est lui qui dfinit les priorits.

Sprint Backlog : En dbut de sprint, un but est dcid. Pour atteindre cet
objectif, l'quipe de dveloppement choisit lors de la runion de planification
de sprint quels lments du Product Backlog seront raliss. Ces lments sont
alors groups dans un backlog dite Sprint Backlog.
4.1.4. Estimation des lments du backlog

Les items du Product Backlog sont souvent des User Stories empruntes
Extrme Programming. Ces User Stories sont estimes en points relatifs, sans
unit. L'quipe prend un item reprsentatif et lui affecte un nombre de points
arbitraire. Cela devient un rfrentiel pour estimer les autres items.
Figure 80: Exemple de user story
Par exemple, la figure 11 reprsente une User Story qui vaut 3 points, cette User
Story reprsente 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 premires valeurs de la suite de Fibonacci (1, 2, 3,
5, 8, 13,), qui vitent les difficults entre valeurs proches (8 et 9 par exemple).
Figure 8: Des cartes de planning poker
4.1.4. La vlocit
La vlocit de l'quipe, est le nombre de points que lquipe peut
raliser en un sprint. La vlocit peut s'estimer en regardant les sprints
prcdents, supposer que la composition de l'quipe et la dure des sprints

soient stable. Elle peut aussi tre dfinie chaque sprint avec un planning bas
sur l'engagement de l'quipe.
Concernant la vlocit de mon quipe qui se compose de un membre,
jai pu raliser 8 points pendant le premier Sprint. En partant de cette vlocit
et du total de points raliser (85 points), on peut dterminer le nombre de
sprints qui seront ncessaires pour terminer le projet (6 sprints).
4.1.4. Les tches du Sprint Backlog

Un item peut prendre plusieurs jours avant dtre ralis, chaque item du
sprint backlog doit donc tre dcoup suivant une granularit plus fine,
appele tche. Ce dcoupage permettra ainsi aux membres de lquipe de
se les partager. Chaque tche est chiffre en heure/homme correspondant
son temps de dveloppement, idalement une tche ne doit pas dpasser un
jour/homme.
La figure 16 illustre le dcoupage dune User Story de notre Product Backlog.
Nous pouvons voir que cette user story estim 2 points, soit 16
heures/homme de travail est alors dcoup en 3 tches : la tche 3.1, 3.2, 3.3,
qui sont ralisable respectivement en 3, 5, et 2 heures/homme.
4.1.4. Planification des Releases

La runion de planification des sprints (Sprint planning meeting), quon a
vue prcdemment, est lvnement le plus important dans Scrum. Le but de
cette runion est de prparer le planning de travail et didentifier le backlog
des sprints.
Comme on a vu dans la section prcdente, mon projet pourra contenir

6 sprints avec une vlocit de 8 points, dans ce contexte nous avons choisi de
dvelopper 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 reprsente les deux Releases planifies, chacune de ces

Releases contient 3 Sprints de tailles de 10 points, chaque Sprint est reprsent
par une date de dbut, une date de fine et un nombre de User Stories dont
chacune de ces User Stories est reprsente par un numro didentification ID,
un nombre de points reprsentant la dure estime pour la raliser et un
numro de priorit, ce qui permet de dfinir l'ordre de ralisation.
Le Taskboard est une table de 3 colonnes, dans la premire on met

toutes fiches reprsentant les User Stories du Sprint courant. Les 2 trois autres
colonnes reprsentent les tats par lequel chaque tche doit passer, chaque
ligne reprsente un ensemble de tche associe une User Story ou dans
certains cas les bugs corriger. Dans notre exemple, les tches dbutent dans
ltat To Do, lorsquun membre dcide de raliser une tche, il la fait passer
ltat In progress, une fois termine il la fait passer ltat Done et finalement
lorsque toutes les taches dune mme User Story sont termines elle passe cette
User Story ltat final Done.

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

suivre la priorit, la traabilit et la gestion de tout le travail associ.
4.2.2. BurndownChart
Cest galement durant la runion de Daily Scrum que lquipe met
jour le BurndownChart, une courbe qui permet de visualiser lavancement de
lquipe sur le sprint. La figure suivante reprsente le BurndownChart du 4me
Sprint :
Figure 11: Le BurndownChart du 4me Sprint
La diffrence entre la ligne idale qui est en noire et celle effective qui
est en rouge peut tre analyse pour en soutirer des informations prcieuses.
Si la ligne effective est suprieur la ligne idale, cela veut dire qu'il y a plus
de travail restant que celui prvu initialement. contrario, si la ligne est
infrieure, on aura moins de travail restant que celui planifi.

5. Conclusion
Dans ce chapitre nous avons prsent la mthodologie de travail ainsi
que nous avons prpar le plan de releases, par la suite nous allons dvoiler les
outils et les langages de conception et de dveloppement que nous avons
utiliss durant la ralisation du systme.

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

Aprs avoir dcrit dans le chapitre prcdent lensemble des

fonctionnalits du systme, je vais laborer dans ce chapitre une tude
technique qui permettra de dcrire laspect technique de la solution raliser.
1. Exigence du projet
Une architecture logicielle exprime un schma dorganisation
structurelle fondamentale pour des systmes logiciels. Il fournit un ensemble de
sous-systmes prdfinis, spcifie leur responsabilit, et inclut des rgles et des
guides pour organiser les relations entre eux.
Larchitecture logicielle du projet subit un certain nombre de forces, le choix

dune architecture logiciel constitue un dfi technologique. En effet il faut
dfinir les grands objectifs technique de la future architecture, c'est--dire de
bien prendre en compte lensemble des forces qui vont sexercer sur le future
systme ainsi que la puissance de chacune dentre elles. Les objectifs
techniques de larchitecture doit assurer sont la fiabilit, la rutilisabilit, la
disponibilit et lvolutivit.
1.1. Mthodologie de dveloppement : La dmarche

MVC
Modle d'architecture qui cherche sparer nettement les couches de
prsentation (UI : User Interface), mtier (BLL : Business Logic Layer) et d'accs
aux donnes (DAL : Data Access Layer). Le but tant d'avoir une dpendance
minimale entre les diffrentes couches de l'application, ainsi les modifications
effectues sur n'importe quelle couche de lapplication n'affectent pas les
autres couches.
Modle Encapsule le cur fonctionnel de l'application, le domaine
logique.

Vue les donnes sont envoyes, par le modle, la vue qui les prsente
lutilisateur.
Contrleur reoit les donnes et les transmets au modle ou la vue.
Une telle architecture est communment appele architecture 3-tier ou 3

niveaux.
Figure 12: Architecture MVC
1.2. Pourquoi MVC

Une architecture est une sorte d'organisation qui permet de rpartir des
fonctions sur un ensemble de ressources (et/ou d'organiser le boulot pour
construire la chose correspondante).
Si les possibilits de rpartition +/- optimales des fonctions sur les ressources sont
limits, 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 donne), 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
implmentations diffrentes d'une architecture MVC construites avec des

technologies diffrentes et des personnes diffrentes. 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 "mres" pour tracer des frontires
'stables' qui aient une valeur ajoute 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 raliser cette tude comparative entre les Plateformes nous avons
utilis Google trends , cet outils va nous permettre de savoir la frquence de
recherche de ces termes sur le moteur de recherche Google. Ainsi les rsultats
nous ont donns une ide globale sur le Framework le plus utilis ou autrement
dit le Framework qui a la plus grande quantit de ressources sur internet
Figure 13: Intrt 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: Intrt de recherche odoo/netsuite/xtuple/compiere
Pour avoir une ide sur le nombre de ressources [JAVA/.NET] qui sont archivs
dans le Datacenter de Google. On a utilis le moteur de recherche
directement et on a obtenu les rsultats suivants.
Figure 20: Nombre de rsultats sur le nombre de recherche Google pour le terme sage
Figure 15: Nombre de rsultats sur le nombre de recherche Google pour le terme odoo

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

Odoo est un Progiciel de Gestion intgr (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 intgre au niveau des traitements offerts
(les diffrents modules qui le composent sont indpendants mais parfaitement
compatibles entre eux),ainsi rigoureux et cohrent au niveau des donnes
gres (partage d'une base de donnes unique et commune), Fournir
l'ensemble des acteurs de l'entreprise une image unique,en plus il est
cohrente et homogne de l'ensemble de l'information, Fdrer 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, gnralement un
effort de collaboration o les programmeurs amliorent ensemble le code
source

Figure 17: L'architecture de deploiment Odoo
- Investissement cibl sur le mtier
- Respect des standards ouverts
- Indpendance vis--vis d'un diteur
- Accs au code source (personnalisation)
- Dveloppement communautaire
- Abondances de versions
- Transparence du code source
- Dficit de documentation
- Dficit de comptences
Trois tiers client / serveur / base de donnes, 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 dutilisateurs travers le monde en grande majorit issus des
pays mergeants
3. Outils utiliss
3.1. Python
Python est un langage de programmation objet, multi-

paradigm et multiplateformes. Il favorise programmation
imprative structure, fonctionnelle et oriente objet. Il est dot d'un typage
dynamique fort, d'une gestion automatique de la mmoire par ramasse-

miettes et d'un systme 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 conu pour optimiser la productivit des programmeurs en
offrant des outils de haut niveau et une syntaxe simple utiliser.
Il est galement apprci par les pdagogues qui y trouvent un langage o la

syntaxe, clairement spare des mcanismes de bas niveau, permet une
initiation aise 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 gnrer des fragments et des pages
HTML.
Les directives de modle sont spcifis comme des attributs XML avec le
prfixe t-, par exemple t-si pour conditionnels, avec des lments et d'autres
attributs tant rendu directement.
3.3. HTML5-CSS3
HTML5 (HyperText Markup Language 5) est la dernire rvision majeure
d'HTML (format de donnes conu pour reprsenter les pages web). Cette
version est en dveloppement en 2013. HTML5 spcifie deux syntaxes d'un
modle abstrait dfini 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 aprs avoir t lanc

par le WHATWG. Les deux organisations travaillent en parallle sur le mme

document afin de maintenir une version unique de la technologie. Le W3C vise
la clture des ajouts de fonctionnalits le 22 mai 2011 et une finalisation de la
spcification en 20141, et encourage les dveloppeurs Web utiliser HTML 5
ds 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 grer le design d'une
page en HTML.
3.4. XML
L'Extensible Markup Language (XMLnote 1, langage balise extensible
en franais) est un langage informatique de balisage gnrique qui drive du
SGML. Cette syntaxe est dite extensible car elle permet de dfinir diffrents
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 systmes d'informations htrognes (interoprabilit). Avec ses outils et
langages associs, une application XML respecte gnralement certains
principes :
La structure d'un document XML est dfinie et validable par un schma

Un document XML est entirement transformable dans un autre
document XML.
3.5. Postgresql
PostgreSQL est un systme de gestion de base de donnes relationnelle et

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

Ce systme est concurrent d'autres systmes de gestion de base de

donnes, qu'ils soient libres MariaDB, MySQL et Firebird), ou propritaires
Oracle, Sybase, DB2, Informix etMicrosoft SQL Server). Les projets libres Apache
et Linux, PostgreSQL n'est pas contrl par une seule entreprise, mais est fond
sur une communaut mondiale de dveloppeurs 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 sparment. On peut ainsi crer des
diagrammes de Gantt, des rseaux de PERT ou encore des diagrammes IDEFO.
Dans Visio, les graphiques utiliss pour crer des diagrammes sont vectoriels.
Les versions Standard et Professionnel de l'dition 2007 partagent la

mme interface, mais cette dernire permet de faire des diagrammes plus
avancs, grce des modles supplmentaires. Cette version offre
galement une fonctionnalit unique qui permet aux utilisateurs de relier
facilement leurs diagrammes un grand nombre de sources de donnes et
d'afficher les informations recueillies graphiquement.
3.1.2. Outils de dveloppement

a. Eclipse
Eclipse IDE est un environnement de dveloppement intgr libre(le

terme Eclipse dsigne galement le projet correspondant, lanc par IBM)
extensible, universel et polyvalent, permettant potentiellement de crer des
projets de dveloppement mettant en uvre n'importe quel langage de
programmation. Eclipse IDE est principalement crit en Java ( l'aide de la
bibliothque graphique SWT, d'IBM), et ce langage, grce des bibliothques
spcifiques, est galement utilis pour crire des extensions.
b. Gitlab : Solution dhbergement de projets Git

Git, outil de gestion de versions de code source, sest rpandu trs
rapidement dans la communaut Open Source, dautre part sa rapidit, sa
flexibilit et sa fiabilit. Les solutions dhbergement en ligne de projets Git
connaissent un norme succs, mais leur utilisation est bien souvent payante
pour lhbergement de projets privs. GitLab est une solution gratuite et Open
Source pour lhbergement de projets Git privs comparable aux gants tels
que GitHub et BitBucket et qui convient aux entreprises, Dvelopp
initialement par Linus Torvalds en 2005 pour la gestion du kernel Linux. Depuis,
Git sest rapidement rpandu, surtout dans la communaut Open Source, de
par sa rapidit, flexibilit, fiabilit et sa nature distribue, tous des aspects qui
le distinguent doutils plus anciens tels que Subversion (SVN).
Lhbergeur Git le plus connu et le plus utilis est GitHub, qui offre de
lhbergement gratuit de projets publics, et propose une version payante pour
particuliers ou entreprises, pour des projets privs. Bitbucket dAltassian se
distingue de GitHub en offrant des projets privs gratuits pour un nombre limit
de collaborateurs par projet. Enfin, ces hbergeurs disposent tous des services
payants de dploiement de serveurs Git privs en self-hosting auprs
dentreprises. Fortement inspir de GitHub, est entirement Open Source et
sadresse COMME solution gratuite dhbergement de projets Git.
Avant de rentrer dans les dtails de mise en uvre de GitLab, passons

en revue les fonctionnalits offertes aux utilisateurs et administrateurs.
Premirement, et surtout, GitLab propose une interface web complte

et pure. Toute solution dhbergement web de projets Git permet de
visualiser ses diffrents projets, ltat et lvolution des branches et lhistorique
du projet, chose qui peut galement tre faite avec un grand nombre doutils
de visualisation de repositories Git locaux tel que Gitk. Les solutions
dhbergement web apportent surtout une valeur ajoute via les services
autour de Git, COMME pour le cas de GitLab :
La collaboration entre utilisateurs :

La revue de code, allant de lannotation dun ensemble de commits

jusqu lannotation de lignes de code individuelles dans un COMMIT
particulier.
Le suivi de bugs et fonctionnalits dans un bugtracker.
La dfinition de milestones dvolution du projet.
Un systme de notification par mail et flux RSS.
Un tableau de bord inter-projets pour ne rien rater.
Ladministration de projets Git :
Tout utilisateur dispose de droits de cration de repositories, dans

son namespace personnel ou dans unnamespace de groupe, pour
rassembler des repositories lis et partags entre plusieurs utilisateurs.
Un repository dans un namespace personnel ou de groupe est
accessible aux utilisateurs suivant un systme de permissions, bien plus
riche que celui de GitHub : none, guest,REPORTER, developer et master.
La notion dquipe facilite lattribution de droits daccs une liste de
repositories avec un certain niveau de permission un ensemble
dutilisateurs.
c. Jira
JIRA est un systme de suivi de bugs, un systme de gestion des incidents,
et un systme degestion de projets dvelopp par Atlassian Software Systems.
4. Conclusion
On a commenc ce chapitre par la prsentation des exigences du
projet et larchitecture logicielle de mon systme. Aprs on a prsent
larchitecture de dveloppement choisi ainsi que outils utiliss pour la
ralisation de ce projet, dans le chapitre suivant nous allons dtailler les
diffrents releases du projet.

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

Le terme release peut tre dfini comme une version distribue ou

livrable d'une application ou une priode de temps qui permet de la produire.
Un release est constitu d'une suite d'itrations (sprint) qui se terminent quand
les incrments de ces derniers construisent un produit prsentant suffisamment
de fonctions aux utilisateurs finaux.
Au cours de ce chapitre, nous allons traiter les User Stories de mes sprints
pour produire un incrment potentiellement livrable.
1. Premier Release
Ce premier release se prsente comme le plus essentiel et prioritaire des
releases car il contient les fonctionnalits principales de projet, o on doit
raliser 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 dfini la longueur du Sprint, il est temps de dcider
quelles histoires inclure dans ce dernier. Plus prcisment, quelles histoires de
notre backlog du produit seront incluses dans le backlog du sprint. Dans notre
cas les histoires sont classifies par leurs priorits, le tableau rsume donc le
backlog de mon premier sprint :
En se basant sur le point de vue du Product Owner (client), et en terme

mtier nous avons dfini le but de ce sprint : raliser des fonctionnalits
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

daccder l'application
En tant que utilisateur j'ai besoin de grer 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 grer les permissions 1
En tant que manager j'ai besoin de grer les projets 2
Table 1 : Backlog du sprint 1
Lors de la runion du sprint planning on a discut avec le Product Owner et

le Scrum Master, chacune des user stories.
Lauthentification : lauthentification de nimporte quel utilisateur du

system.
Gestion du profile : Tout le monde peut grer son profile (CRUD).
Gestion de projets : Seulement le manager qui a le droit de grer les
projets.
Gestion des permissions : Le manager a le droit dattribuer ou de
restreindre les droits des utilisateurs.
1.1.1. Conception
1.1.1.1. Choix formalisme UML
Vue le dploiement de lapplication et lextension future, une
modlisation objet apparait la plus adapte, en effet lobjet a fait ses preuves
dans la ralisation dapplication Web.
Pourquoi nous avons opt pour UML :
- UML est un langage formel et normalis

o gain de prcision
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 comprhension de reprsentations abstraites complexes.
o Son caractre polyvalent et sa souplesse en font un langage
universel.
Aprs avoir exprim les spcifications fonctionnelles, nous allons traduire ces
besoins nous allons traduire ces besoins-l en des diagrammes fonctionnels
UML
1.1.1.2. Vue cas dutilisation

a. Diagramme de cas dutilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utiliss
pour donner une vision statique et globale du comportement fonctionnel d'un
systme logiciel. Ils sont utiles pour des prsentations auprs de la direction ou
des acteurs d'un projet
Le diagramme de cas dutilisation est compos des acteurs externes et

des cas dutilisation :
Les acteurs : Ils sont des entits externes qui interagissent avec le systme,
comme une personne humaine ou un robot.
Les cas dutilisation : est une description des interactions qui vont permettre
l'acteur d'atteindre son objectif en utilisant le systme.
La solution quon va raliser va tre grer par les responsables ressources

humaines le DRH et les chefs de projet qui sont aussi des administrateurs
systme, et en fin il y a les utilisateurs, dans ce sprint existe 3 diagramme de cas
dutilisation.

Figure 20 : Diagramme de cas dutilisation dun utilisateur Sprint 1
Lutilisateur 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 grer ses projets, il doit premirement sauthentifier
Figure 22: Diagramme de cas d'utilisation de ladministrateur Sprint 1
Ladministrateur peut faire un cas dutilisation qui est spcifique, cest la gestion
des permissions
1.1.1.3. Vue squentielle

Les diagrammes de squences sont la reprsentation graphique des
interactions entre les acteurs et le systme selon un ordre chronologique dans
la formulation UML.
Le diagramme de squences permet de cacher les interactions d'objets dans

le cadre d'un scnario d'un Diagramme des cas d'utilisation. Dans un souci de
simplification, on reprsente l'acteur principal gauche du diagramme, et les

acteurs secondaires ventuels droite du systme. Le but tant de dcrire

comment se droulent les actions entre les acteurs ou objets.
La dimension verticale du diagramme reprsente le temps, permettant

de visualiser l'enchanement des actions dans le temps, et de spcifier la
naissance et la mort d'objets. Les priodes d'activit des objets sont
symbolises par des rectangles, et ces objets dialoguent par le biais de
messages.
Apres la description des cas dutilisation, nous allons laborer le modle
dynamique dans lequel nous allons dcrire les scnarios de quelques cas
dutilisations, les plus importants dans ce sprint, sous forme de diagrammes de
squence.
Figure 23: Diagramme de squence de la gestion des projets

Figure 24 : Diagramme de squence du cas d'utilisation : gestion des permissions
Ce diagramme montre la gestion des droits par ladministrateur
1.1.1.4. Diagramme de classes

Le diagramme de classes est considr comme le plus important de la
modlisation oriente objet, il est le seul obligatoire lors d'une telle
modlisation.

Alors que le diagramme de cas d'utilisation montre un systme du point de

vue des acteurs, le diagramme de classes en montre la structure interne. Il
permet de fournir une reprsentation abstraite des objets du systme qui vont
interagir pour raliser les cas d'utilisation. Il est important de noter qu'un mme
objet peut trs bien intervenir dans la ralisation de plusieurs cas d'utilisation.
Les cas d'utilisation ne ralisent donc pas une partition des classes du
diagramme de classes. Un diagramme de classes n'est donc pas adapt (sauf
cas particulier) pour dtailler, dcomposer, ou illustrer la ralisation 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 systme. Le diagramme de classes modlise les
concepts du domaine d'application ainsi que les concepts internes crs de
toutes pices dans le cadre de l'implmentation d'une application. Chaque
langage de Programmation orient objet donne un moyen spcifique
d'implmenter le paradigme objet (pointeurs ou pas, hritage multiple ou pas,
etc.), mais le diagramme de classes permet de modliser les classes du
systme et leurs relations indpendamment d'un langage de programmation
particulier.
Les principaux lments de cette vue statique sont les classes et leurs
relations : association, gnralisation et plusieurs types de dpendances, telles
que la ralisation 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 hrite de la classe user, et il y a aussi notre classe
project_scrum qui hritent 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 donnes on aura une 3me table qui va lier les
tables candidat et sujet de stage.
La classe Project est lie la classe Sprint qui sera prsent dans le
prochain sprint (on en parlera dans le prochain sprint).
1.1.2. Ralisation
Dans cette partie on va parler des diffrentes fonctionnalits ralises
pendant ce sprint.

1.1.2.1. Le Dashboard et la gestion des projets
Figure 26: Gestion des projets
Aprs lauthentification lutilisateur est rediriger directement vers le

Dashboard de gestion des projets o il ne voit que les projets qui lui affect
comme membre de lquipe des dveloppeurs, Product Owner, ou Scrum
Master, sil est administrateur il doit avoir accs tous les projets comme il
montre cette capture
1.1.3. Conclusion
Dans cette partie jai conue ralis et test le premier sprint du 1er
release du projet, qui a regroup plusieurs fonctionnalits de bases de la
plateforme, nous avons dtaills les diffrentes tapes adoptes par la
mthode Scrum. Dans la partie suivante on va attaquer, avec la mme
approche le deuxime sprint de ce release.

1.2. Sprint 2
En partant sur le mme principe que le sprint prcdent, nous
commenons par les spcifications fonctionnelles. Ensuite la conception et
finalement les tests cette fois ci ne sont pas disponibles vu que cest la mme
procdure qui se rpte. Le tableau rsume 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 grer les sprints 3

En tant que manager j'ai besoin de grer les user stories 2
En tant que manager j'ai besoin de dfinir la vitesse de l'quipe 2
(Velocity)
En tant que manager j'ai besoin de grer les taches 2
Table 7 : Backlog du sprint 1.
Comme on la dj mentionn, lors de la runion 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 dutilisateur ordonn par priorit :
Gestion des Sprints : Dans chaque projet le Manager peut grer les
sprints associ ce projet.
Gestion des histoires : Le manager a le droit de crer, modifier, ou
supprimer une histoire, lors de la cration dune user story le manager
doit spcifier le projet et le Sprint, et lutilisateur peut modifier ltat de
lhistoire en la glisser dans le taskboar vers le nouveau tat.
Gestion des taches : Les taches sont grer par les dveloppeurs et les
managers et ils peuvent modifier ltat de la tche en glissant la tache
vers le nouvel tat ( faire , en cours , dj fait ).

Dfinition de la vlocity : dans chaque projet ladministrateur a le droit

de dfinir la vlocity de lquipe associ ce projet
1.2.2. Conception
1.2.2.1. Vue cas dutilisation : Diagramme de cas dutilisation
Toutes les fonctions qui se trouvent dans ce sprint sont reli
ladministrateur o il peut dfinir la vlocit de lquipe, ensuite il peut entrer
dans chaque sprint pour grer les histoires, et enfin faire la gestion des taches.
Figure 27 : Diagramme de cas dutilisation du Manager - Sprint 2
Ce Sprint contient seulement les cas dutilisation du Scrum Master ou Product

Owner, comme il montre la capture au-dessus

ce niveau, nous devons prsents le diagramme de squence des
diffrents cas dutilisation dj dtaills dans la section prcdente.

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

manager

Figure 29 : Diagramme de squence du cas d'utilisation : Dfinir la vlocit
Le manager peut dfinir la vlocit dune quipe pour un projet spcifique,

donc la vlocit est dfinie pour chaque projet.

Figure 30: Diagramme de classes sprint 2
Ce diagramme prsente les nouvelles classes cr dans ce sprint, environ dix

classes quon va dtailler
Project_scrum : reprsente les projets, ses cordonnes.
Scrum_sprint : dfinit les sprints associs un projet qui peut contenir
plusieurs sprints.
User story : une histoire comporte plusieurs taches, chaque story est
reprsent pas son nom, estimation, ses taches, date dbut, date fin ,

et elle a une dure de vie, aprs une certaine date elle ne sera plus
utilis.
Project_task : on enregistre les taches des histoires. avec lestimation, le
nom, priorit, description, tat, il doit tre reli avec le timesheet des
employes.
1.2.3. Ralisation
Dans cette partie on va parler des diffrentes fonctionnalits ralises
pendant ce sprint.
1.2.3.1. La gestion des incrments
Figure 31: Gestion des Sprints
Cette interface montre les Sprint du projet o la couleur du Sprint

reprsente ltat du Sprint et le champ progress affiche lavancement du
Sprint, et donc daprs cette interface lutilisateur doit avoir une ide
gnrale sur lensemble des Sprints du projet.

1.2.3.2. La gestion du Backlog
Figure 32: Gestion du Backlog
Cette page reprsente lensemble des histoires du projet en les classifiant par
Sprint, et cest lespace de gestion du Backlog
1.2.4. Conclusion
Dans cette partie jai conue ralis et test le deuxime sprint du 1er
release du projet, qui a ajout de nouvelles fonctionnalits et complter
dautres. Dans la partie suivante on va attaquer, avec la mme approche le
troisime et dernier Sprint de ce release.

1.3. Sprint 3
Le sprint 3, est le dernier sprint du release, avait comme but le
dveloppement des dernires fonctionnalits ncessaires la livraison dun
tout premier produit prt tre utilis.
En suivant la mme mthode adopte pour les Sprints prcdents, nous

allons dtailler les diffrentes phases de dveloppement.
1.3.1. Backlog
Les user stories du troisime Sprint :
En tant que manager j'ai besoin de grer les taches 3

En tant que manager j'ai besoin daffecter les taches aux 1
membres dquipe
En tant que manager j'ai besoin dafficher le burndown chart 3
du sprint
En tant que manager j'ai besoin dafficher et imprimer le 2
backlog du projet
En tant quemploy j'ai besoin de grer le taskBoard 3

Gestion des Taches : Dans chaque projet le Manager et le

dveloppeur peuvent grer les taches associes au sprint ouvert du
projet.
Affectation des taches : Le manager a le droit de rpartir les taches sur
les membres de chaque projet.
BurndownChart : Le manager peut accder chaque Sprint et
imprimer le Burndown Chart pour visualiser lavancement, le
droulement 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 dutilisation : Diagramme de cas dutilisation
Figure 33 : Diagramme de cas dutilisation du Manager
La plupart des fonctions qui se trouvent dans ce sprint sont reli

ladministrateur o il peut dfinir la vlocit de lquipe, ensuite il peut entrer
dans chaque sprint pour grer les histoires, et enfin faire la gestion des taches.
Figure 34 : Diagramme de cas dutilisation du Dveloppeur
Aprs lauthentification le dveloppeur peut Grer les taches qui

appartiennent aux histoires lis au projet.

Dans cette partie, on va dtailler quelques cas dutilisation en prsentant
quelques diagrammes de squences.

Figure 35: Diagramme de squence de la gestion des Taches
Aprs lauthentification Le manager peut accder aux Sprint lis ses

projets, ensuite accder aux histoires, et enfin accder au taskboard de
chaque histoire o il peut ajouter, modifier, supprimer, consulter, changer ltat
en glissant la tache vers une autre colonne.

Ce diagramme ne contient pas beaucoup de nouvelles classes se caractrise par

le fait quil ne contient pas beaucoup prsente des nouvelles classes qui sont :
Project_meeting : pour grer les Daily Scrum et les diffrentes rencontre qui se
faient au niveau de chaque Sprint.
1.3.3. Ralisation
A ce stade on doit avoir une ide sur linterface.
VI.1.3.3.1. La gestion des taches

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

de ses taches.
1.3.3.2. Laffectation des taches
Figure 38: Lajout des membres de lquipe
Premirement Le manager doit ajouter les membres de lquipe au projet,

comme il est expliqu sur la capture au-dessus

Figure 39 : Laffectation de la tache
1.3.3.3. Laffichage du BurndownChart du Sprint
Figure 40 : Laffichage du BurndownChart

Figure 41 : Le BurndownChart
Le manager peut choisir dimprimer le BurndownChart.
1.3.3.4. Laffichage et limpression 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

quil soit imprim par la suite.

1.3.3.5. La gestion du taskboard
Figure 43: Gestion du taskboard
Le dveloppeur peut grer les taches qui lui appartiennent
1.3.4. Conclusion
Dans ce chapitre on a analys, conu, ralis 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 russi dvelopper le release 1
pour arriver un produit fonctionnel. Les besoins fonctionnels sont affins sprint
aprs sprint, et la livraison des dveloppements aprs chaque sprint permet de
rorienter le projet si ncessaire.
Dans le prochain chapitre on va dtailler le Release 2 du projet, bien tudier

les sprints de ce release en passant par toutes les tapes dfinies par Scrum
(Analyse, Etude fonctionnelle, Conception & Modlisation, Mise en oeuvre).

2. Deuxime Release
Notre deuxime release est constitu de 3 sprints, cest la deuxime version
livrable du projet. Nous allons analyser, dtailler et tester les diffrentes phases
du release.
2.1. Sprint 4
Comme les sprints du premier release nous avons dfini le but de ce Sprint qui
est dans un premier temps la gestion des congs, qui sera une configuration
du module standard de gestion de congs intgr dans la plateforme Odoo.
2.1.1. Backlog
Les user stories du quatrime Sprint :
En tant que manager, j'ai besoin de grer les congs 1

En tant que manager, jai besoin de dfinir les soldes congs 2
pour chaque employ et les journes de rcupration
En tant que manager, j'ai besoin de grer les demandes de 1
congs
En tant que manager, j'ai besoin dapprouver ou refuser les 1
demandes de congs
En tant quemploy j'ai besoin de crer les timesheets par 2
tache
En tant que manager j'ai besoin dafficher les rsums de 1
congs
Ce sprint se compose de six histoires dutilisateur ordonn par priorit :
Gestion des congs : Le manager RH peut grer les congs en lui

affichant un calendrier qui lui facilite la tche.
Les soldes de congs : Le manager RH a le droit de dfinir le nombre
lgal de jours pour ses subordonnes.

Gestion des demandes de congs : Le manager a le droit grer les

demandes de congs de ses collaborateurs (CRUD), et ensuite les
approuver ou les refuser.
Les timesheets : Lemploy a la possibilit de crer les timesheets par
tache en affichant la diffrence entre lestimation de la tche et la
somme de ses timesheet.
Les rsums de congs : Le manager peut accder une page qui lui
affiche les congs filtrs par type et ensuite par employ.
2.1.2. Conception
Dans cette partie du chapitre on va parler et dtailler les options de la partie
de gestion de congs.
Dans ce sprint nous avons dfini les diffrentes fonctionnalits de la gestion de congs et qui
sont associ au Manager Ressources Humaines
Figure 45 : Diagramme de cas dutilisation de lemploy

Aprs lauthentification lemploy peut crer les timesheets quil a travaills et

qui appartiennent une tache dun de ses projets.

Dans cette partie, on va discuter quelques cas dutilisation en prsentant
quelques diagrammes de squences.
Figure 46: Diagramme de squence de la gestion des Taches
Aprs lauthentification Le dveloppeur peut accder aux Sprint lis

ses projets, ensuite accder aux histoires, et enfin vers le Taskboard o il peut
choisir de modifier une tche pour quil puisse entrer ses heures de travails.

Figure 47: Diagramme de classes sprint 4 : Gestion de congs
Ce diagramme reprsente la base de donnes du module standard dOdoo

de gestion de congs.
2.1.3. Ralisation
Aprs ltape de la conception et comme les chapitres prcdents nous
allons entamer la partie ralisation du sprint, nous allons donner une ide sur
les diffrentes interfaces produites pendant le sprint.
2.1.3.1. La gestion des congs

Nous avons crs une interface qui soit lisible est trs clair pour que le
manager peut grer les congs sans difficults

Figure 48: Gestion des congs
Dans le menu de gestion de cangs le Manager RH une calendrier

saffiche en visualisant les demandes de congs avec leurs dures, en plus
filtrs employ
2.1.3.2. La validation des demandes de congs
Figure 49: La validation des demandes de congs
Le manager doit valider les congs de ses subordonnes pour quils

soient affichs sur le calendrier.

2.1.3.3. La cration des timesheets
Figure 50: Linscription
Au niveau de la tache le dveloppeur peut crer ses heures prestes en

prcisant la dure, et il sera automatiquement le responsable.
2.1.4. Conclusion
Dans ce chapitre nous avons analys, conu, ralis et test le
quatrime sprint du deuxime release du projet qui a ajout des fonctionnalits
lapplication et affin dautres. Il est temps de passer au cinquime et avant
dernier sprint

2.2. Sprint 5
Le sprint 5, avait comme but le dveloppement des fonctionnalits
ncessaires la livraison dun produit prt tre utilis.
En suivant la mme architecture des autres Sprints prcdents, nous

allons dtailler les diffrentes phases de dveloppement.
2.2.1. Backlog
Les user stories du cinquime Sprint :
En tant quadministrateur, jai besoin de grer les templates du 0.5

contrat employ.
En tant quadministrateur, j'ai besoin de grer les templates du 0.5
contrat client
En tant que manager, j'ai besoin de suivre les 1
prsences/absences
En tant que manager, j'ai besoin de grer les pointages 2
(entres/sorties)
En tant que manager, j'ai besoin de grer les clients 0.5
En tant que manager, j'ai besoin de grer les contrats clients 1
En tant que manager, j'ai besoin de grer les contrats des 0.5
employs
En tant quemploy, j'ai besoin de pointer lentre et la sortie 1
En tant quemploy, j'ai besoin de consulter mes 0.5
prsences/absences
En tant quemploy, j'ai besoin dimprimer mon contrat 1

Les templates des contrats clients : Ladministrateur a le droit de dfinir

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

Les prsences et les absences : Le manager peut consulter les

prsences de tous ses collaborateurs.
Le pointage : Le manager peut suivre les pointages de ses
subordonnes.
Gestion des clients : Le manager a le droit de grer les clients
Gestion des contrats client : Lors de la cration dun projet, un contrat
est cr automatiquement avec le projet, pour gagner du temps et le
manager peut la consulter, modifier, supprimer
Le pointage : Lemploye doit avoir la possibilit pour pointer lentre
et la sortie
Les prsences : Lemploye peut acceder ses prsences et ses
absences
Impression du contrat : Lemploy a besoin dimprimer son contrat

2.2.2. Conception
Figure 51 : Diagramme de cas dutilisation du Dveloppeur Sprint 5
Ce diagramme montre un ensemble de cas dutilisation qui sont confis au

manager ressources humaines (Gestion des contrats, des pointages, des
clients, )
Figure 64 : Diagramme de cas dutilisation de ladministrateur Sprint 5

Figure 64 : Diagramme de cas dutilisation de lemploy Sprint 5
Pour quun employ puisse imprimer son contrat, consulter ses

prsences, pointer son entre ou sa sortie il doit premirement sauthentifier
Figure 52: Diagramme de squence du pointage de lemploy Sprint 5

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

de son entre ou lors de sa sortie
2.2.3. Ralisation
Aprs la conception et comme les chapitres prcdents on va
attaquer la partie ralisation en donnant une ide sur linterface dutilisateur.
2.2.3.1. La gestion du pointage de lentr et de la sortie
Figure 53: Le pointage entre/sortie
Lemploy peut grer ses pointages, en filtrant les pointages du mois

courant, de la semaine courante, et daujourdhui, mais un manager doit avoir
la possibilit de grer les pointages de toutes ses subordonnes
VI.2.2.3.2. La gestion des Templates des contrats clients

Figure 54: Les templates des contrats clients
Lors de la cration du contrat, Le manager peut choisir son modle de

contrat ou bien crer un nouveau modle, en prcisant les variables
inclure.
2.2.4. Conclusion
Dans cette partie, jai dtaill les diffrentes tapes parcourue dans le
cinquime Sprint pour arriver ce rsultat, 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
dveloppement des dernires fonctionnalits ncessaires la livraison de la
dernire version du projet.
En partant videment par le mme principe des sprints prcdents,

nous allons dtailler les diffrentes phases de dveloppement.
2.3.1. Backlog
Les user stories du sixime Sprint :
En tant que manager, jai besoin de suivre lvolution des 1

heures prestes (timesheets) sur une tache ou projet
En tant que manager j'ai besoin de valider ou refuser les heures 1
prestes
En tant que manager j'ai besoin de soumettre les heures 1
prestes pour la facturation
En tant que manager j'ai besoin de crer et denvoyer des 1
factures aux clients
En tant que manager, jai besoin de consulter et dimprimer les 1
factures
En tant quemploy, jai besoin de soumettre mes heures 1
prestes (timesheets) au responsable pour la validation
Suivi des heures prestes : Dans chaque projet le Manager peut suivre
lavance de chaque tche par rapport ses heures prestes.
Validation des timesheets : Le manager a le droit de refuser ou de
valider les heures prestes, et les soumettre la facturation.
Les factures : Le manager peut imprimer et envoyer les factures aux
clients, aprs la validation de ces derniers.

2.3.2. Conception
Ce diagramme au-dessus montre les diffrents cas dutilisation du

sixime Sprint et qui sont destins pour un Manager RH
Figure 56 : Diagramme de cas dutilisation du Dveloppeur
Cette figure reprsente les fonctions du dernier incrment et qui sont

destins pour lemploy

VI.2.3.2.2. Vue squentielle

Les diagrammes de squences de cette partie sont trs similaires aux
sprints prcdents, nous allons nous limit un seul diagramme.
Figure 57: Diagramme de squence de la gestion des Factures


Ce diagramme reprsente le dernier diagramme de classes de la gestion des

projets, les nouvelles classes qui sont :
Project_meeting : pour grer les Daily Scrum et les diffrentes
rencontres qui se font au niveau de chaque Sprint.
Actor : Reprsente les acteurs de chaque histoire utilisateur
2.3.3. Ralisation
2.3.3.1. La cration et lenvoie des factures
Figure 59: La cration de la facture
Cette Capture reprsente une facture qui est cr par le responsable

en slectionnant un ensemble des heures prestes, en cliquant sur une
facture on peut limprimer ou bien la modifier.

2.3.3.2. Suivi des heures prestes
Figure 60: Les heures prestes dune tache
Cette capture montre le fait de visualiser lavancement au niveau de

chaque tche en comparant son estimation avec le total de ses heures
prestes
2.3.4. Conclusion
Dans ce chapitre nous avons analys, conu, ralis et test le deuxime
release du projet, il est alors maintenant potentiellement livrable.

Conclusion gnrale et perspective
Ce stage a t sous plusieurs aspects riches denseignements, nous

avons commenc dans un premier lieu par comprendre le contexte gnral
de notre application et identifier les diffrentes exigences de notre futur
systme. Nous avons prpar par la suite notre planning de travail en
respectant les priorits de nos besoins suite une discussion entre l'quipe.
Dans le cadre de mon projet de fin dtudes, nous avons conu et
dvelopp une solution qui permet de grer la totalit des ressources lies aux
projets sous la mthode Scrum. Le prsent manuscrit dtaille toutes les tapes
par lesquelles nous sommes passs pour arriver aux rsultats attendus. Nous
avons essay tout au long de notre travail de construire notre application
incrment par incrment en utilisant la mthodologie Scrum.
l'heure actuelle, l'application est prte tre utilise, on peut donc
affirmer que le but qui mavait t fix a t atteint. Le contact avec le monde
de la recherche ma permis de progresser dans de nombreux domaines,
notamment sur le thme de lanalyse de donnes.
On est satisfait du travail ralis durant ce stage, tous les principaux
objectifs ont pu tre atteints. Le travail que nous avons ralis devrait tre mis
en production durant le mois de juillet. Ce stage ma permis dapprofondir et
mettre en pratique les connaissances acquises durant mon cursus lENSA de
Ttouan. Jai galement dcouvert le travail avec la mthode Scrum ainsi la
programmation en Python et JavaScript avec la plateforme Odoo.
Finalement, mon travail ne sarrte pas ce niveau, en effet plusieurs
fonctionnalits peuvent tre ajoutes notamment les rapports.
En conclusion, mon stage m'a permis de mettre en uvre des comptences
scolaires, professionnelles et humaines pour un sujet intressant. J'ai de plus
acquis de nouvelles dans le domaine du dveloppement de lentreprise.

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 150814170320 Lva1 App6891 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rapportdestagepfe 150814170320 Lva1 App6891 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Mmoire de Projet de Fin dtudes

pour lobtention du Titre

DIngnieur dtat en Informatique

La mise en place d'une solution pour la

M. TABII Youness Encadrant ENSAT

M. LAZAAR Mohammed Professeur

M. CHRAYAH Mohamed Professeur

Anne universitaire 2014-2015

2 cole Nationale Des Sciences Appliques De Ttouan 2015

A mon pre, Aucune ddicace ne saurait exprimer lamour,

A toutes ma famille, pour leurs soutiens, leurs conseils partags

Au staff professoral de lENSA Ttouan, je serais vaniteux si je me

Au personnel administratif de l'ENSA Ttouan et sa tte M.

3 cole Nationale Des Sciences Appliques De Ttouan 2015

Avant de commencer rdiger mon rapport, je tiens adresser

Je saisie cette occasion pour remercie Mr TABII Youness notre

J'adresse mes sincre 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 Appliques De Ttouan 2015

Durant les quatre mois, ma mission consiste dvelopper une application de

Lapplication va permettre aux quipes de dveloppement de collaborer sur

Ce rapport se propose de dcrire les diffrentes tapes par lesquelles le projet

5 cole Nationale Des Sciences Appliques De Ttouan 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 Appliques De Ttouan 2015

Table des matires

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 Appliques De Ttouan 2015

Liste des figures

9 cole Nationale Des Sciences Appliques De Ttouan 2015

Figure 39 : Diagramme de cas dutilisation du Manager - Sprint 2 ................................ 74

10 cole Nationale Des Sciences Appliques De Ttouan 2015

Figure 74: Les heures prestes dune tache..................................................................... 105

11 cole Nationale Des Sciences Appliques De Ttouan 2015

Liste des tableaux

12 cole Nationale Des Sciences Appliques De Ttouan 2015

Liste des abrviations

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