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
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
9

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
10

Figure 74: Les heures prestes dune tache..................................................................... 105
11
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
12
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
13
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.
14
Chapitre 1 : Prsentation gnrale du projet
IIIIII-
15
Prsentation de lorganisme daccueil

Contexte gnrale du projet
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 :
16
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
17
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
18
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
19
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 :
20
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),...
21
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.
22
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 :
23
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.
24
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.
25
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
26
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).
27
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)
MAROUFI
- Spcification fonctionnels
M. Amine EL
- Product owner
BOUKHARI EL
- Spcifications Techniques
Ingnieur
Ingnieur
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
28
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.
29
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
30
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
CASCADE
FORCES
FAIBLESSES
(WATERFALLS)
Facile
Donne une fausse
comprendre et
impression
de
utiliser
lavance
des
Adapt pour une

quipe
Les limites de
tape
sont visibles
management
dveloppement
stable
Lintgration na
existant
non
nouvelle
dune
phase lautre
plate-
forme
La qualit prime
Une
matrise
sur le cot
bonne
de
la
technologie
EN V
Facile utiliser
Les tests sont

effectus
Une mauvaise
Les
spcifications
prise en compte
de
des
doivent
vnements
concurrents
chaque tape
Le processus nest
besoins
tre
bien faites
pas itratif
31
produit
existant sur une
Pas de retour en
arrire
produit
Limplantation
dun
satisfait
volutive
est
nouvelle version
du
non-
bien
Il sagit dune
dun
La dfinition des
La dfinition du
produit
Le client peut se
est
trs
entre les phases de
retrouver
un cycle
projet
besoins
spcification
lieu qu la fin du
Facilite
La phase de
faite
Pas dinteraction
chaque
travaux
inexprimente
QUAND UTILISER
La solution
dvelopper et la
technologie

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

interaction
avec
les clients
les dveloppeurs
travaillent
Lvolution du
cot
de
par
nouvelle
intermittence
il sagit dune
gamme
il est difficile de
de
produits
dveloppement
dfinir les objectifs
est sous contrle
et les points de
changements
validation
significatifs
ds le dpart une
intermdiaires
peuvent
vue
entre
Les utilisateurs ont

globale
du
systme
les
des
intervenir
diffrentes tapes
cause
par
exemple
de
lvolution de la
recherche ou de
lexploration
PAR
INCREMENT
Le client peut
valider
chaque
tape
du
les cots et
lvaluation des
risques
est
important
processus
pour des projets
Utilise la mthode
Diviser Pour Rgner
Require
une
risque
au
moins
bonne
moyennement
planification et une
lev
bonne conception
La dlivrance du
pour des projets
produit est rapide
long
terme
dont
les
financements
peuvent varier
Le
cot
lancement
de
du
projet est moindre
les utilisateurs ne
Require
la
dfinition
complte
dfinissent
clairement leurs
des
besoins
fonctionnalits du
33
pas
Un
produit
exploitable
systme pour une
peut
dfinition
tre dlivr tout
diffrents
moment
incrments
la spcification
des
des besoins est

complexe
il sagit dune
nouvelle
gamme
Les
clients
obtiennent
produits
les
fonctionnalits
du
systme trs tt
Le
risque
changement
des
changements
majeures
de
significatifs
du
Le cot total du
peuvent
dveloppement
intervenir
du systme nest
cause
pas ngligeable
exemple
par
de
des
lvolution de la
besoins est minimal
recherche ou de
lexploration
Dveloppe les
Les diffrentes
Sur un projet
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

sur le produit
Progrs
34
Projets Scrum sans

Product
est
actif
owner
et
sans
Pour
les
organisations
orientes
incrmental,
acteurs
produit,
facilement
conomiques
est un moyen de
mesurable
et
clairement
visible
engags
sera
Scrum
rvolutionner la
probablement
mthode dont ils
fiasco
traitent
ses

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

facilement
ou porte de voix
testables
du
Lquipe
dveloppe
attitude
d'affaires,
une
est
la
souffrir
Lquipe
et
productivit va en
get-it-
done
client
Siloing
de
la
connaissance peut
implicitement
crotre
si
Scrum-
encourage se
Master nest pas
comporter
attentif et lquipe
comme une start-
ne
up et l'approche
eux-mmes
corrige pas
dfie les normes
Rtrospectives de
organisationnelles.
sprint sont inutiles si

l'quipe
est
franche
pas
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-differentscycles-de-vie-de-logiciels-111005786.html , http://www.bobtuse.com/2009/01/whatsswot-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
36

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)
Processus dfini
Cascade
Spirale
Itratif
Spirale
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
Cot du projet
projet
Dtermin
Partiellement
Dfini durant
Dfini
durant la
Variable
le projet
durant le
planification
projet
Date de fin de
Dtermin
Partiellement
Dfini durant
Dfini
Projet
durant la
Variable
le projet
durant le
planification
projet
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
livre de
itrations
lquipe
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
37

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.
38
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.
39
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.
40
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

41
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
42

En tant que
1
Utilisateur
Je voudrais
s'authentifier afin daccder
l'application
Utilisateur
Grer mon profile
Utilisateur
Consulter le Dashboard selon mes

permissions
Administrateur
Grer les permissions
Manager
Grer les projets
Manager
Grer les sprints
Manager
Grer les user stories
Manager
Dfinir la vitesse de l'quipe (Velocity)
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.
43

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.
44
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
45
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.
46
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.
47
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.
48
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.
49
Chapitre 3: Technologies utiliss
IIIIIIIV-
50
Exigence du projet
Choix de la technologie
Outils utiliss
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.
51

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
52
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
53
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
54
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
55
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
56
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
paradigm
est
et
un
langage
multiplateformes.
de
programmation
Il
favorise
objet,
multi-
programmation
imprative structure, fonctionnelle et oriente objet. Il est dot d'un typage

dynamique fort, d'une gestion automatique de la mmoire par ramasse-
57
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
58
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.
59
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.
60
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 :
61
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.
62
Chapitre 4: Les releases du projet scrum
III-
63
Release 1
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
64
1.1.1. Backlog
Les user stories du premier sprint
User story
En tant que utilisateur, j'ai besoin de s'authentifier afin
Estimation
1
daccder l'application
En tant que utilisateur j'ai besoin de grer mon profile
En tant que utilisateur j'ai besoin de consulter le Dashboard
selon mes permissions

En tant qu'administrateur j'ai besoin de grer les permissions
En tant que manager j'ai besoin de grer les projets
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
65
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.
66
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
67
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
68
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.
69
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.
70
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.
71
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.
72
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 :
User story
Estimation
En tant que manager j'ai besoin de grer les sprints
En tant que manager j'ai besoin de grer les user stories
En tant que manager j'ai besoin de dfinir la vitesse de l'quipe
(Velocity)
En tant que manager j'ai besoin de grer les taches
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 cidessus 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 ).
73
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.
74
Figure 28: Diagramme de squence de la gestion des projets
Ce diagramme de squence explique la gestion des projets, qui est confi au

manager
75
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.
76
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 ,
77
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.
78
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.
79
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 :
User story
Estimation
En tant que manager j'ai besoin de grer les taches
En tant que manager j'ai besoin daffecter les taches aux
membres dquipe
En tant que manager j'ai besoin dafficher le burndown chart
du sprint
En tant que manager j'ai besoin dafficher et imprimer le
backlog du projet
En tant quemploy j'ai besoin de grer le taskBoard

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
80
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.
81
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.
82
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
83
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
84
Figure 39 : Laffectation de la tache
1.3.3.3. Laffichage du BurndownChart du Sprint
Figure 40 : Laffichage du BurndownChart
85
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.
86
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).
87
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 :
User story
Estimation
En tant que manager, j'ai besoin de grer les congs
En tant que manager, jai besoin de dfinir les soldes congs
pour chaque employ et les journes de rcupration

En tant que manager, j'ai besoin de grer les demandes de
congs
En tant que manager, j'ai besoin dapprouver ou refuser les
demandes de congs
En tant quemploy j'ai besoin de crer les timesheets par
tache
En tant que manager j'ai besoin dafficher les rsums de
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.
88
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

89
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.
90
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
91
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.
92
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
93
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 :
User story
Estimation
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
prsences/absences
En tant que manager, j'ai besoin de grer les pointages
(entres/sorties)
En tant que manager, j'ai besoin de grer les clients
En tant que manager, j'ai besoin de grer les contrats clients
En tant que manager, j'ai besoin de grer les contrats des
0.5
1
0.5
employs
En tant quemploy, j'ai besoin de pointer lentre et la sortie
En tant quemploy, j'ai besoin de consulter mes
1
0.5
prsences/absences
En tant quemploy, j'ai besoin dimprimer mon contrat

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.
94
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
95
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
96
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

97
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
98
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.
99
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 :
User story
Estimation
En tant que manager, jai besoin de suivre lvolution des
heures prestes (timesheets) sur une tache ou projet

En tant que manager j'ai besoin de valider ou refuser les heures
prestes
En tant que manager j'ai besoin de soumettre les heures
prestes pour la facturation

En tant que manager j'ai besoin de crer et denvoyer des
factures aux clients

En tant que manager, jai besoin de consulter et dimprimer les
factures
En tant quemploy, jai besoin de soumettre mes heures
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.
100
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
101
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
102


103
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.
104
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.
105
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.
106
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]
107

Langue

Rapportdestagepfe 150814170320 Lva1 App6891 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapportdestagepfe 150814170320 Lva1 App6891 PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Mmoire de Projet de Fin dtudes

pour lobtention du Titre

DIngnieur dtat en Informatique

La mise en place d'une solution pour la

Anne universitaire 2014-2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Aucune ddicace ne saurait exprimer lamour,

lestime, le dvouement et le respect que jai toujours eu pour vous. Rien

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

pour lencadrement de ce travail, pour leurs conseils, leurs

critiques, leurs encouragements, leurs disponibilits ainsi que pour

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Table des matires

LA METHODE SCRUM ................................................................................................ 30

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

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Liste des figures

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Liste des tableaux

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Liste des abrviations

Unified Modeling Language

Application Programming Interface

Hypertext Markup Language

Asynchronous JavaScript and XML

Model Controller View

Data Access Object

Integrated Development Environ ment

Object Relational Mapping

Standard Query Language

Systme de Gestion de Base Donnes

Affero General Public License

customer relationship management

supplier relationship management

Content management system

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

SCRUM en utilisant la plateforme

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines

Chapitre 1 : Prsentation gnrale du projet

Prsentation de lorganisme daccueil

cole Nationale Des Sciences Appliques De Ttouan 2015

Gestion de projets et gestion des ressources humaines