Rapport de projet odoo

Mémoire de Projet de Fin d’Études
pour l’obtention du Titre
D’Ingénieur d’État en Informatique
Système d’information
Promotion 2010-2015
M. DAMIR Ayoub
Soutenance le 20 Juin 2015
Membres de jury
M. TABII Youness Encadrant ENSATé
M. LAZAAR Mohammed Professeur
M. CHRAYAH Mohamed Professeur
Année universitaire 2014-2015
La mise en place d'une solution pour la
gestion des projets, gestion de ressources
humaines Sous la plateforme Odoo

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

Dédicace
A ma mère, qui m'a comblé de son soutien et m'a voué un amour
inconditionnel. Tu es pour moi un exemple de courage et de sacrifice
continu. Que cet humble travail témoigne mon affection, mon éternel
attachement et qu'il appelle sur moi ta continuelle bénédiction.
A mon père, Aucune dédicace ne saurait exprimer l’amour,
l’estime, le dévouement et le respect que j’ai toujours eu pour vous. Rien
au monde ne vaut les efforts fournis jour et nuit pour mon éducation et
mon bien être. Ce travail est le fruit de tes sacrifices que tu as consentis
pour mon éducation et ma formation.
A mes très chers frères, je vous remercie pour votre amour, votre
soutien et vos encouragements
A toutes ma famille, pour leurs soutiens, leurs conseils partagés
Au staff professoral de l’ENSA Tétouan, je serais vaniteux si je me
devais énumérer en ces quelques lignes vos remarquables qualités
humaines et professionnelles. Veuillez trouver ici l'expression et le
témoignage de ma gratitude ressentie
A tous mes chers amis, pour le soutien que vous m’aviez offert, je
vous dis MERCI
Au personnel administratif de l'ENSA Tétouan et à sa tête M.
Kamal Eddine ELKADIRI, de nous avoir préparé à atteindre ce stade
qui m’a permis de confronter la vie professionnelle à travers ce stage

Remerciement
Avant de commencer à rédiger mon rapport, je tiens à adresser
mes sincères remerciements aux personnes qui m'ont permis de mener
à bien mon travail par leurs sincères collaborations.
Je saisie cette occasion pour remercie Mr TABII Youness notre
professeur, qui par ses conseils judicieux et son suivi permanent du
travail, a su m'éclairer sur l'itinéraire à suivre pour arriver à bout de
ce travail.
J'adresse mes sincère remerciement à Mr HILALI Redwan, EL
BOUKHARI EL KHAMLICHI Mohammed Amine, et EL MAROUFI
Amine pour l’encadrement de ce travail, pour leurs conseils, leurs
critiques, leurs encouragements, leurs disponibilités ainsi que pour
m’avoir accueilli et donné les moyens pour accomplir ce stage dans les
meilleurs conditions.
Je n'oublie pas de remercier chaleureusement mes Parents et mes
frères et mes amis pour leurs soutiens.
Je tiens mes chaleureux remerciements, aux soldats de fond, et à
tous ceux qui ont contribué de près ou de loin à l'achèvement de ce
travail, à leur tête mes parents, mes professeurs et mes amis.

Résumé
Ce rapport décrit le travail que j’ai réalisé dans le cadre de l’obtention de mon
diplôme d’ingénieur d’état en Systèmes d’informations à l’Ecole Nationale des
Sciences Appliquées Tétouan, il s’est déroulé du 3 Mars au 05 juin 2015 effectué au
sein de la société 4D Logiciel Maroc à Rabat.
Durant les quatre mois, ma mission consiste à développer une application de
gestion de projet, et gestion des ressources humaines agile avec la plateforme Odoo
dans un cadre de développement agile.
L’application va permettre aux équipes de développement de collaborer sur
des projets pilotés selon la méthodologie agile Scrum et au département ressources
humaines de bien gérer ses collaborateurs. Le but de l’application est de faciliter le
pilotage des projets et la gestion des ressources humaines en offrant une version
numérique des nombreux artefacts de la méthode Scrum (Backlog, Histoires utilisateur,
Itérations, Taches, Taskboard, contrats etc.)
Ce rapport se propose de décrire les différentes étapes par lesquelles le projet
a passé dans le but d’atteindre la solution actuelle.

Abstract
This report describes the work I've done in the context of getting my state
engineering degree in Information Systems at the National School of Applied
Sciences Tetouan, it was held from March 3 to June 15, 2015 conducted within the
company 4D Software Morocco in Rabat.
During the four months, my mission is to develop a project management
application, and management of human resources with agile Odoo platform in an
agile development framework.
The application will allow development teams to collaborate on projects
managed by Scrum agile methodology and the Human Resources Department to
manage its employees. The purpose of the application is to facilitate the
management of human resources and management projects by providing a digital
version of many artifacts of this method (Backlog User Stories, Iterations, spots,
Taskboard, contracts, etc.)
This report is to describe the various stages that the project has passed in order
to achieve the current solution.

Table des matières
DEDICACE............................................................................................................................................... 3
REMERCIEMENT....................................................................................................................................... 4
RESUME.................................................................................................................................................... 5
ABSTRACT................................................................................................................................................ 6
TABLE DES MATIERES............................................................................................................................... 7
LISTE DES FIGURES................................................................................................................................... 9
LISTE DES TABLEAUX ............................................................................................................................. 12
LISTE DES ABREVIATIONS ..................................................................................................................... 13
INTRODUCTION GENERALE.................................................................................................................. 14
CHAPITRE 1 : PRESENTATION GENERALE DU PROJET ...................................................................... 15
1. STRUCTURE ET ORGANISATION DE 4D........................................................................................................16
1.1. Aperçu de 4D ...................................................................................................................... 16
1.2. L’architecture de l’entreprise ............................................................................................ 18
2. LA PLATEFORME ODOO...........................................................................................................................19
2.1. Principales applications logicielles front office................................................................ 19
2.2. Principales applications logicielles back office .............................................................. 20
2.3. Modules d'Odoo ................................................................................................................. 20
2.4. Historique et notes des sorties............................................................................................ 21
3. CONTEXTE GENERALE DU PROJET .............................................................................................................22
3.1. Etude de l’existant ............................................................................................................... 22
3.2. Problématique..................................................................................................................... 25
3.3. La solution proposée........................................................................................................... 26
3.4. Démarche et planification................................................................................................. 28
4. CONCLUSION.........................................................................................................................................28
CHAPITRE 2 : LA METHODE SCRUM................................................................................................ 30
1. COMPARAISON DES PROCESSUS DE DEVELOPPEMENT................................................................................31
2. LE CHOIX DU PROCESSUS DE DEVELOPPEMENT...........................................................................................36
3. LA METHODE SCRUM...............................................................................................................................38
3.1 Approche agile .................................................................................................................... 38
3.2. Pourquoi Scrum ? ................................................................................................................ 39
4. PILOTAGE DU PROJET AVEC SCRUM .........................................................................................................40
4.1 Fonctionnement de Scrum ................................................................................................. 40
4.2. Outils Scrum.......................................................................................................................... 47
5. CONCLUSION.........................................................................................................................................49
CHAPITRE 3: TECHNOLOGIES UTILISES ................................................................................................ 50
1. EXIGENCE DU PROJET..............................................................................................................................51
1.1. Méthodologie de développement : La démarche MVC.............................................. 51
1.2. Pourquoi MVC ..................................................................................................................... 52
2. CHOIX DE LA TECHNOLOGIE ....................................................................................................................53
2.1. Etude comparative entre les ERP existant sur le marché............................... 53
2.2. La plateforme Odoo........................................................................................................... 55

3. OUTILS UTILISES........................................................................................................................................57
3.1. Outils de conception.......................................................................................................... 60
3.2. Outils de développement.................................................................................................. 60
4. CONCLUSION.........................................................................................................................................62
CHAPITRE 4: LES RELEASES DU PROJET SCRUM .................................................................................. 63
1. PREMIER RELEASE....................................................................................................................................64
1.1. Sprint 1 .................................................................................................................................. 64
1.2. Sprint 2 .................................................................................................................................. 73
1.3. print 3 ..................................................................................................................................... 80
2. DEUXIEME RELEASE..................................................................................................................................88
2.1. Sprint 4 .................................................................................................................................. 88
2.2. Sprint 5 .................................................................................................................................. 94
2.3. Sprint 6 ................................................................................................................................ 100
CONCLUSION GENERALE ET PERSPECTIVE ....................................................................................... 106
BIBLIOGRAPHIE ET WEBOGRAPHIE.................................................................................................... 107

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

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

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

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

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

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

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

Le contexte général du projet est une étape primordiale pour la
connaissance de l’environnement dans lequel s’est déroulé le stage de fin
d’études ainsi que la présentation du projet. Ce chapitre sera consacré tout
d’abord à la présentation de l’entreprise 4D au sein duquel j’ai effectué mon
projet.
Et par la suite une présentation de contexte générale du projet que m’a
confié 4D comme projet de fin d’études. Cette présentation inclura une étude
de l’existant, l’évocation des problématiques que j’avais à traiter, la solution
que j’ai proposée et le planning que j’avais suivi pour la réalisation de ce projet.
1. Structure et organisation de 4D
1.1. Aperçu de 4D
D’un capital de 2 millions d’euros et dont le siège social se situe à Clichy
(Ile de France), la société détenue majoritairement par son fondateur ne
regroupe pas moins de 180 collaborateurs répartis à travers le monde au sein
de ses filiales internationales. La société 4D est en effet présente aux Etats-Unis,
au Japon, en Grande-Bretagne, en Allemagne, en Suède, en Espagne ainsi
qu’en Australie. Sa présence à travers le monde est renforcée par son réseau
de distribution implanté dans plus de 40 pays.
Créée en 1984, « 4D » se distingue sur le marché informatique en
introduisant le premier système de gestion de bases de données relationnelles
graphique dénommé « 4D ». Le produit continue son évolution pour proposer
en 1987 :
 un client-serveur intégré
 un serveur Web intégré
 un système de partage d'applications dynamiques intégré

En 1997, « 4D » investit dans Internet en intégrant un serveur Web
dynamique, permettant aux développeurs de servir à la fois des applications
client-serveur et des applications Web sans aucune modification de code.
En 2004, « 4D » devient le premier produit permettant aux développeurs
de créer à la fois des applications autonomes, client-serveur, ainsi que des
applications orientées Services (SOA) et Web sans aucune modification de
code. Plus récemment, « 4D » a créé la première plateforme de
développement « end-to-end » JavaScript permettant de créer des
applications professionnelles avec la gamme de produits «Wakanda».
La philosophie de « 4D » est la suivante : simplifier ce qui était auparavant
complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les
niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession
faible.
4D compte plus de huit filiales à l’international et de nombreux
distributeurs et représentants locaux dont « 4D Logiciels Maroc » fait partie. Les
métiers présents à « 4D Logiciels Maroc » sont similaires voir identique à ceux de
la filiale en France, et ce, allant du Support Technique et Développement
jusqu’au Contrôle Qualité pour les deux produits « Wakanda » et « 4D ».
La philosophie de 4D est la suivante : simplifier ce qui était auparavant
complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les
niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession
faible. 4D offre également des fonctionnalités basées sur les nouvelles
Figure 1: Logo du produit WakandaFigure 3: Logo du produit 4D v13 Figure 2: Logo de 4D logiciels

technologies les plus populaires, tout en conservant un niveau de compatibilité
ascendante qui permet de pérenniser les investissements des clients.
1.2. L’architecture de l’entreprise
La figure ci-dessous représente l’organigramme de l’entreprise « 4D logiciels ».
Figure 4: Filiales, représentants et distributeurs locaux de 4D (source réf 1)
Figure 5: L’organigramme de l’entreprise « 4D logiciels »

2. La plateforme Odoo
Odoo est un progiciel de gestion d'entreprise (ERP) destiné à intégrer
l'ensemble des données opérationnelles et de gestion de l'entreprise dans une
base de données unique, accessible par une interface web.
Cette base de données centrale est associée à une couche
fonctionnelle très innovante qui met en relation des informations d'origines
diverses et assure un déroulement efficace des processus transversaux de
création de valeur ajoutée de l'entreprise.
Odoo, anciennement OpenERP et Tiny ERP, est à la base un progiciel
libre de gestion intégré comprenant de très nombreux modules permettant de
simplifier la gestion d’entreprise dans son ensemble. Le logiciel est sous licence
AGPL et est utilisé par plus de 2 millions d’utilisateurs à travers le monde.
À l’origine un ERP, le logiciel s’est vu étendre ses fonctionnalités à des
applications de front office (CMS, e-Commerce, Blogs, Forums, News,
Événements, LiveChat, Job offers, etc). Il apporte les applications métier dont
chacun a besoin dans l'entreprise.Cette approche modulaire facilite
l'intégration de nouvelles fonctionnalités sous la forme de modules
complémentaires.
2.1. Principales applications logicielles front office
 Créateur de site web et système de gestion de son
contenu, CMS
 Vente en ligne, Ecommerce
 Interface de point de vente (PDV)

2.2. Principales applications logicielles back office
 Gestion de relation clients (CRM & SRM)
 Gestion des ventes
 Gestion de production
 Gestion de projets
 Gestion des stocks
 Gestion des ressources humaines
 Gestion des achats
 Gestion logistique
 Gestion de manufactures
 Gestion comptable
 Gestion des dépenses
 Gestion des documents
 Générateur de factures
 Gestion et outils marketing
2.3. Modules d'Odoo
L’aspect libre du logiciel a permis le développement de nombreux
modules tiers créés par sa communauté de développeurs. Ces applications
sont pour certaines officiellement validées par l’éditeur tandis que d’autres ne
sont destinées qu’à des versions spécifiques.
 Architecture logicielle
La conception d'Odoo est orientée par une architecture MVC, des flux
de travail flexibles, une interface-utilisateur graphique dynamique, une
interface de communication interne XML-RPC, et un système personnalisable
de comptes-rendus.
D’un point de vue de l’architecture technique, Odoo est construit autour
de trois composants principaux qui communiquent entre eux par les
protocoles XML-RPC et NET-RPC :

 Le serveur odoo-server qui stocke ses données dans une base
PostgreSQL ;
 Le client odoo-client qui s'installe sur le poste de l'utilisateur
(abandonné depuis la v7) ;
 Le serveur web odoo-web qui permet une utilisation depuis un
navigateur.
Le logiciel compte 260 modules officiels et 4000 modules communautaires.
2.4. Historique et notes des sorties
Le 20 janvier 2011, OpenERP SA annonçait le lancement de la version
6.0 du logiciel, qui comprend une version à la demande (SaaS). Son
approche modulaire permet aux utilisateurs de commencer avec une
application, puis d'ajouter d'autres modules selon leurs besoins.
En décembre 2012, la version 7.0 d'OpenERP est lancée et peut être
testée en ligne, téléchargée ou vue en version de démonstration. Mai 2014:
OpenERP change de nom et devient Odoo.
Eté 2014, Odoo lance la version 8. Cette version enrichit principalement le
logiciel de nouvelles applications qui font d’Odoo un logiciel allant au-delà
d'un ERP. Ces applications sont: Marketing (gestion d'événements,
d'enquêtes de satisfactions, campagnes de mails auprès de la CRM,...), CMS
(construction d'un site internet - front-end lié au back-end - grâce au
déplacement rapide et simple de 'blocs" d'éditions), e-commerce
(application pour vente en ligne),...
 Première version stable : 2004
 Version stable actuelle : 8.0
 Version avancée : 9.0

Anciennes versions ou fin de maintenance
Anciennes versions avec maintenance étendue
Version actuelle
Versions en cours de développement
3. Contexte générale du projet
3.1. Etude de l’existant
3.1.1. Préambule
Le but de l’étude de l’existant est de déterminer les points faibles et les
points forts d’un produit actuel pour pouvoir déterminer les besoins du client,
en vue d’en prendre en considération lors de la conception et la réalisation de
la solution. Dans cette section, nous présentons une analyse des modules
proposée par la communauté Odoo, et du logiciel Jira. Ensuite, nous
formulerons une solution de la problématique.
Figure 6: L'historique des versions d’Odoo

3.1.2. Jira
Description
Site web http://www.atlassian.com/fr/software/jira/overview
Prix Entre 12 000$ et 24 000$
Avantages JIRA permet de tout faire. Il existe des centaines de plugins à
ajouter qui vous permettront, si vous trouvez qu’il manque
quelque chose, de le rajouter en quelques clics. De plus il est
largement utilisé par le monde (La fondation Apache, Skype,
Zend Framework, etc.) et son coût est dérisoire pour les
petites équipes.
Inconvénients Trop complexe. La prise en main demandera du temps. Et si
on souhaite mettre les mains dans le cambouis (modifier le
workflow par exemple), cela demandera encore plus de
temps. Il y a aussi, et son cout reste cher pour les équipes qui
ont un nombre important de collaborateur par rapport aux
autres produits qui se trouve sur le marché
Tableau 7: Tableau descriptive du produit JIRA
correspond aux attentes de plusieurs utilisateurs. Mais il reste
limité devant les besoins de 4D comme l’exploitation des données de
production dans les rapports et la gestion de ressources humaines, et donc 4D
sent qu’il est dispersé puisqu’il doit utiliser aux moins deux solution pour
répondre à ses besoins, gestion de projets et gestion de ressources humaines.
3.1.3. La gestion de projets standards sous la plateforme
Odoo
Permet la gestion de projets ainsi que les taches de chaque projet en allant
jusqu’au niveau le plus détaillé, Ce module permet de :
 Définir des projets / tâches associés à un responsable
 Suivre chaque tâche / projet selon son avancement : formulaire, Gantt
 Générer la facturation conditionnelle, selon l'avancement

 Gérer la relation avancement / temps passé (feuilles de saisie des
heures)
 Assurer un suivi budgétaire analytique du projet, associé à la
comptabilité analytique…
Un projet contient des informations générales, reliées à la comptabilité
analytique, au partenaire, etc. Ce sont les tâches qui font le projet. Chaque
tâche peut être constituée de plusieurs étapes.
Ce module offre plusieurs fonctionnalités pour les entreprises dans différents
secteur
i. Les avantages du module standard de Odoo
Odoo Project Management permet de définir des projets / tâches associés
à un responsable Suivre chaque tâche / projet selon son avancement :
formulaire, Gantt…, générer la facturation conditionnelle selon l'avancement,
gérer la relation avancement / temps passé (feuilles de saisie des heures), et
assurer un suivi budgétaire analytique du projet, associé à la comptabilité
analytique...
Les fonctionnalités présentées ne sont ni exhaustives, ni figées. Un des
atouts de l'offre OpenERP / Odoo est son ADAPTABILITE à la diversité des
besoins des entreprises.
La gestion de projet dans OpenERP / Odoo repose sur les concepts suivants :
Un project template est un modèle qui permet de générer un projet (un
projet peut aussi être converti en template) Ce projet se compose de tâches
qui vont être accomplies en exécutant des travaux. Lorsque qu'une tâche est
terminée, les travaux qui ont été inscrits dans cette tâche sont transférés dans
la timesheet (feuille de temps) du collaborateur, lorsque le collaborateur valide
sa timesheet, ses travaux sont transférés dans la comptabilité analytique et
peuvent générer une facturation.

Un projet contient des informations générales, reliées à la comptabilité
analytique, au partenaire, etc. Ce sont les tâches qui font le projet. Chaque
tâche peut être constituée de plusieurs étapes.
Le planificateur vous aide à planifier les tâches et étapes, en fonction de la
disponibilité de vos ressources. Il est possible d'échanger des e-mails liés à votre
projet, pour communiquer avec votre équipe, les clients et les fournisseurs. Un
outil collaboratif permet d'échanger et de partager les tâches avec les clients.
Vous pourrez suivre les problèmes, demandes d'assistance, questions sur les
projets tout en surveillant votre qualité de service.
ii. Les inconvénients du module standard de gestion de projets
Parmi ces limites c’est qu’il ne supporte pas la méthode Scrum avec toutes
ses notions (User story, Sprint …), il y a aussi la complexité du module Odoo qui
ne facilite pas la tâche pour l’utilisateur.
3.2. Problématique
D’après ce que nous avons vu, parmi les problèmes que nous pouvons citer
c’est :
 Perte du temps
Surtout il n’y a pas de coordination entre l’équipe et les ressources
humaines pour bien gérer le temps, et ne pas être dispersé.
 Perte d’argent
Pour que la société peut satisfaire ses besoins il doit avoir au moins 2
solutions
 Inefficacité :
Tant qu’il n y a pas une solution qui inclut la gestion de ressources humaines
et la gestion de projets alors les indicateurs ne seront plus représentative du
rendement réel des membres de chaque équipe, ce qui implique une
inefficacité de la solution.

 Perte d’opportunités
Une mal gestion peut conduire à la perte des projets, et par conséquent
la perte du client.
 Exploitation des données de production
La société ne peut pas exploiter ses données de production pour avoir
des indicateurs de la réalité et qui soient représentatives, par exemple définir
le rendement de chaque employé
 La démotivation
La démotivation des employés qui vont souffrir de la routine du travail
3.3. La solution proposée
Le projet a déroulé sur deux phases:
 Le premier release était consacrée pour la formation sur la
méthode agile SCRUM et sur la plateforme de développement
Odoo, et au réalisation de l’ensemble des fonctionnalités du
module de gestion de projets.
 Le deuxième release était dédiée au développement de
l’ensemble des fonctionnalités demandés pour la gestion de
ressources humaines et faire la liaison entre les différents modules.
Dans le cadre de développement de ce projet, on a travaillé avec la
méthode SCRUM.
L’utilisation de la méthodologie SCRUM semble être le mieux car le projet
pourra subir de nombreuses modifications durant le développement, et pour
avoir plus de métier sur le projet (c.-à-d. on va travailler dans un cadre de
développement agile SCRUM pour développer un outil SCRUM).
3.3.1 Principe de la solution
Pour résoudre les problèmes liés à la gestion des projets, On a proposé de
développer une solution qui permet la gestion des projets en offrant une
interface ergonomique et dynamique, et qui intègre toutes les composants de

la méthode SCRUM pour exploiter les résultats dans la gestion de ressources
humaines et de facturation en fin visualiser les statistiques voulus concernant la
chaine de production.
3.3.2. Objectifs de la solution
Les grandes entreprises en développement logiciel sont en croissance
constantes et poursuivent le but de livrer du logiciel de qualité qui répond au
besoin de l’utilisateur, dans les temps prescrits par le client. La problématique
de celles-ci réside en l’utilisation des méthodes de développement
traditionnelles qui ne satisfont plus entièrement aux besoins grandissants de
qualité.
SCRUM présente une solution intéressante pour les grandes entreprises qui
aimeraient gagner en flexibilité. En utilisant une méthode évolutive de
développement qui implique une plus grande participation du client dans le
processus de développement, les deux parties voient leurs chances de succès
augmentées proportionnellement à la qualité de leurs communications et de
leurs relations. En utilisant la méthodologie SCRUM dans les grandes entreprises,
la qualité du logiciel est accrue et les nouveaux besoins commandés par la
réalité changeante du client sont considérés tout au long du processus. Une
synergie qui gagnerait à être reconnue.
L’entreprise 4D parmi plusieurs grandes entreprises a commencé de
travailler avec la méthodologie SCRUM afin de livrer des produits de qualités
qui répondent aux besoins des clients.
L’objectif principal de mon projet de fin d’étude est de rendre un produit
qui va faciliter le pilotage des projets réalisés par la méthode SCRUM agile,
aussi la gestion de ressources humaines et de facturation au sein de
l’entreprise. Le développement de l’application va être conçu par la solution
Odoo (présenter dans la partie précédente).

3.4. Démarche et planification
3.4.1. Comité de pilotage du projet
Personne Role Function
M. Redouane
EL HILALI
- Pilotage du projet (4D)
- Scrum Master
Chef de service
M. Amine EL
MAROUFI
- Product owne (4D)
- Spécification fonctionnels
Ingénieur
M. Amine EL
BOUKHARI EL
KHAMLICHI
- Product owner
- Spécifications Techniques
Ingénieur
Tableau1: Comité de pilotage du projet
Ce tableau résume les différents membres de l’équipe de pilotage du projet
Personne Role Function
M. DAMIR
Ayyoub
- Participation aux Spécifications
techniques et fonctionnels
- conception et codage de la
solution
- Tests et mise en place de la solution
Elève Ingénieur
System
d’information
Ecole Nationale des
Sciences Appliquées
de Tétouan
Tableau 2 : Comité du projet
Ce tableau résume les différents membres de l’équipe des participants au
développement du projet
4. Conclusion
Dans ce chapitre qui présente le contexte général du projet, on a inauguré
le chapitre par une présentation de l’organisme d’accueil 4D, dans la
deuxième partie du chapitre on a présenté le contexte générale du projet en
commençant par une étude de l’existant, puis on a évoqués les

problématiques à traiter, après on a passé à la solution qu’on avait proposée
pour la résolution des problématiques. Et vers la fin de cette partie on a évoqué
la démarche que nous avions suivie pendant la résolution du projet ainsi que
la planification de ce dernier. Le chapitre suivant est consacré pour la
méthode Scrum.

Chapitre 2 : La méthode Scrum
I- Comparaison des processus de
développement
II- Choix du processus de
développement
III- La méthode Scrum
IV- Pilotage du projet avec Scrum
V- Conclusion

1. Comparaison des processus de développement
Le bon choix du processus de développement logiciel conduit à la
bonne réalisation du projet, c’est pour cette raison nous avons fait référence à
une comparaison entre les principaux processus de développement, pour
pouvoir choisir le meilleur processus correspondant à notre cas
CYCLE DE VIE FORCES FAIBLESSES QUAND UTILISER
CASCADE
(WATERFALLS)
• Facile à
comprendre et à
utiliser
• Adapté pour une
équipe
inexpérimentée
• Les limites de
chaque étape
sont visibles
• Facilite un
management du
projet
• La définition des
besoins est non-
évolutive
• La qualité prime
sur le coût
•Donne une fausse
impression de
l’avancée des
travaux
• Pas d’interaction
entre les phases de
développement
• L’intégration n’a
lieu qu’à la fin du
cycle
• Le client peut se
retrouver non
satisfait
• Pas de retour en
arrière d’une
phase à l’autre
• La phase de
spécification a
été très bien
faite
• La définition du
produit est
stable
• Il s’agit d’une
nouvelle version
d’un produit
existant
• L’implantation
d’un produit
existant sur une
nouvelle plate-
forme
• Une bonne
maîtrise de la
technologie
EN V
• Facile à utiliser
• Les tests sont
effectués à
chaque étape
• Une mauvaise
prise en compte
des évènements
concurrents
• Le processus n’est
pas itératif
• Les
spécifications
de besoins
doivent être
bien faites
• La solution à
développer et la
technologie à

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

interaction avec
les clients
• L’évolution du
coût de
développement
est sous contrôle
• Les utilisateurs ont
dès le départ une
vue globale du
système
• les développeurs
travaillent par
intermittence
• il est difficile de
définir les objectifs
et les points de
validation
intermédiaires
entre les
différentes étapes
• il s’agit d’une
nouvelle
gamme de
produits
• des
changements
significatifs
peuvent
intervenir à
cause par
exemple de
l’évolution de la
recherche ou de
l’exploration
PAR
INCREMENT • Le client peut
valider chaque
étape du
processus
• Utilise la méthode
Diviser Pour Régner
• La délivrance du
produit est rapide
• Le coût de
lancement du
projet est moindre
• Requière une
bonne
planification et une
bonne conception
• Requière la
définition
complète des
fonctionnalités du
• les coûts et
l’évaluation des
risques est
important
à risque au
moins
moyennement
élevé
à long terme
dont les
financements
peuvent varier
• les utilisateurs ne
définissent pas
clairement leurs
besoins

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

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

facilement
testables
• L’équipe
développe une
attitude get-it-
done
L’équipe est
implicitement
encouragée à se
comporter
comme une start-
up et l'approche
défie les normes
organisationnelles.
ou à portée de voix
du client et
d'affaires, la
productivité va en
souffrir
• Siloing de la
connaissance peut
croître si Scrum-
Master n’est pas
attentif et l’équipe
ne corrige pas
eux-mêmes
• Rétrospectives de
sprint sont inutiles si
l'équipe est pas
franche et
constructive
autocritique; et
L'approche défie les
normes
organisationnelles.
Tableau 3: Tableau comparative des différents cycles de vie
Source : http://patjo82.over-blog.com/article-etude-comparee-des-differents-
cycles-de-vie-de-logiciels-111005786.html , http://www.bobtuse.com/2009/01/whats-
swot-on-scrum.html
2. Le choix du processus de développement
En faisant liaison entre tableau comparatif et mon projet, le choix de
Scrum comme une méthodologie de pilotage pour ce projet s’est basé sur les
atouts de ce dernier. Il se résumé comme suit:
Plus de souplesse et de réactivité
La grande capacité d’adaptation au changement grâce à des itérations
courtes

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

Projet
Probabilité de
Succès
Faible Moyen à faible Moyen Élevé
Tableau 4: Comparaison des méthodologies de développement [Sutherland]
3. La méthode Scrum
Comme pour toutes les fabrications, il est important d’avoir un procédé
de fabrication du logiciel bien défini et explicitement décrit et documenté.
Les modèles de cycle de vie du logiciel décrivent à un niveau très abstrait et
idéalisé les différentes manières d’organiser la production. Les étapes, leur
ordonnancement, et parfois les critères pour passer d’une étape à une autre.
3.1 Approche agile
Depuis une quinzaine d’années, la majorité des développements de
logiciels s’appuie sur des méthodes dites “agiles”. Sous cette bannière se
regroupent plusieurs méthodes basées sur un développement itératif et
incrémental, dans lequel la recherche de solutions aux problèmes rencontrés
s’appuie sur la collaboration de pair à pair. Elle promeut des réponses rapides
et flexibles, une planification des tâches adaptatives dans des laps de temps
très courts permettant une très grande réactivité.
Les approches plus classiques tels que cycle en V ou le modèle en
cascade sont souvent mises en œuvre pour les projets répondant à un
imposant cahier des charges. Le client et le prestataire s’entendent alors sur un
contrat et si le projet prend du retard ou ne répond pas à tous les besoins à la
date butoir, des pénalités sont alors facturées au prestataire. De la même
manière si le client s’aperçoit en cours de route que certains besoins ont été
omis dans le cahier des charges, il devra alors renégocier avec le prestataire
le contrat.

Les premières méthodes agiles apparues sont EVO (Evolutionary Project
Management) (1976), RAD (développement rapide d'applications) (1991), puis
DSDM, la version anglaise du RAD (1995). Les trois méthodes agiles désormais
les plus utilisées sont : la méthode Kanban, issue de la méthode industrielle
Lean, la méthode Scrum publiée en 2001 par Ken Schwaber et Jeff Sutherland,
et la méthode XP (Extreme programming) publiée en 1999 par Kent Beck.
3.2. Pourquoi Scrum ?
On propose maintenant de zoomer sur l’une des méthodes Agile
existantes afin de vous montrer plus concrètement le fonctionnement.
Pourquoi traiter de Scrum en particulier ? Tout simplement parce que Scrum est
de très loin la méthodologie la plus utilisée parmi les méthodes Agile existantes.
Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs,
formations, vidéos, associations, conférences traitant de Scrum ne manquent
pas et bon nombre de ces ressources sont accessibles gratuitement. On
pourrait pratiquement parler d’un standard Agile. Un autre atout important :
Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.
Les experts de Scrum, même ses fondateurs, le décrivent comme un «
cadre de travail permettant de répondre à des problèmes complexes et
changeants tout en livrant de manière productive et créative des produits de
la plus grande valeur possible » Scrum propose un modèle de contrôle de
processus basé sur l'empirisme. Il s'appuie sur trois piliers.
La transparence : Scrum met l'accent sur le fait d'avoir un langage commun
entre l'équipe et le management, qui doit permettre à tout observateur
d'obtenir rapidement une bonne compréhension du projet.
L'inspection : Scrum propose de faire le point sur les différents artéfacts
produits à intervalle régulier, afin de détecter toute variation indésirable.
L'adaptation : Si une dérive est constatée pendant l'inspection, le processus
doit alors être adapté. Scrum fournit des rituels, durant lesquels cette
adaptation est possible. Il s'agit de sprint planning, de daily scrum, et de sprint
review qu’ va détailler dans la section suivante.

4. Pilotage du projet avec Scrum
Commençons tout d’abord par présenter la méthode dans sa globalité
afin de se familiariser avec le vocabulaire de Scrum.
4.1 Fonctionnement de Scrum
La première étape consiste à effectuer une première planification de
l’itération ou Sprint Planning dans le jargon des développeurs. Cette réunion
fera ressortir les éléments prioritaires de la liste des exigences fonctionnelles du
produit. Chaque exigence représente une User Story ou "histoire utilisateur".
En accord avec le client, aussi appelé Product Owner, les premières
livraisons devraient être effectuées à la fin de cette itération (qui dure de 2 à 4
semaines suivant le nombre des user stories présentent dans le Backlog). Le
backlog est l'ensemble des US à développer durant l'itération en cours.
Une autre réunion appelée Revue de Sprint ou Sprint Review est
organisée à la fin de chaque Sprint durant laquelle les développeurs
présentent au client les fonctionnalités développées. Ce dernier pourra ainsi
tout de suite donner son feedback, ce qui présente l’avantage de gagner
beaucoup de temps et d’ajuster les fonctionnalités ou les méthodes de travail
le cas échéant.
Vient ensuite une rétrospective de Sprint ou Sprint Restrospective qui
permet à tous les acteurs d’améliorer des choses et de s’améliorer également.
Une autre particularité de la méthode Scrum est la réalisation de mêlées
quotidiennes ou Daily Scrum qui permettent à l’équipe de développeurs de
synchroniser leur travail. Cette réunion qui ne dure pas plus de 15 minutes
permet à chacun de déterminer ce qu’ils ont réalisé depuis la dernière mêlée,
de ce qu’ils auront à terminer avant la prochaine Daily Scrum et d’identifier les
obstacles qui pourraient les bloquer.
La figure 12 résume le processus de fonctionnement de la méthode Scrum.

4.1.1 L’équipe et Rôles
Le Framework Scrum consiste en la définition des rôles projets, activités
ou artefacts, et réunions ou évènements, bref il définit trois rôles qui sont :
Description
Scrum
Master
- Agit comme un facilitateur.
- S’assurer de fournir à l’équipe Scrum, tout le nécessaire à leur plein
potentiel.
- C’est un coordonnateur de ressources, un intermédiaire et non pas
un dirigeant.
Product
Owner
- C’est le représentant des clients et des utilisateurs
- Définir l'ordre dans lequel les fonctionnalités seront développées
- Expliciter les user Stories du backlog du produit
- S'assure que le backlog du produit est visible et compris de l'équipe
de développement.
Scrum
team
- Se constitue des personnes qui seront chargées d’implémenter les
différents besoins du client
- des développeurs, des infographistes, des testeurs, etc.
- Spécifications Techniques
Tableau 5: Les différents roles dans la méthode Scrum
Ce shéma éxplique le fonctionnement et l’architecture de la méthode Scrum
Figure 7: Le processus du Framework Scrum

4.1.2. Les Événements
Toutes les activités (sprint, réunions de planning, revues, rétrospectives et
mêlées) décrites dans le Framework Scrum sont effectuées lors de boites de
temps.
Le sprint : est une période (constante) d'un mois au maximum, au bout
de laquelle l'équipe délivre un incrément du produit, potentiellement livrable.
Un nouveau sprint démarre dès la fin du précédent. Chaque sprint est associe
à une liste d'éléments du backlog du produit à réaliser durant ce sprint. Pour
notre projet la durée du sprint sera fixée à 2 semaines.
Daily scrum : C’est une réunion de planification qui dure 15 minutes et permet
aux développeurs de faire un point de coordination sur les tâches en cours et
sur les difficultés rencontrées.
Sprint planning Meeting : Toute l'équipe Scrum est présente à cette réunion, qui
ne dure plus de 4 heures pour notre cas, pour planifier les user stories du
backlog du produit qu'elle a décidé de traiter pendant la prochaine itération
et comment elle s'organisera pour y parvenir.
Sprint review : À la fin du sprint, l'équipe Scrum et les parties-prenantes invitées
se réunissent pour effectuer la revue de sprint, qui dure au maximum 1 heure
(pour notre cas), qui a pour objectif de valider le logiciel qui a été produit
pendant le sprint. L'équipe fait une démonstration du logiciel produit.
4.1.3. Les artefacts
Product Backlog : L’approche Scrum propose de commencer par lister les
exigences du client afin de produire le Product Backlog sous forme de liste
d’item ou User Story, cette liste contient tout ce qui pourrait être requis dans
le produit et est l'unique source des besoins pour tous les changements à
effectuer sur le produit.
Le Tableau 1 résume le backlog produit de notre application qui contient
50 User Stories

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

29 Manager Gérer les contrats des employés
30 Manager Gérer les comptes analytiques associés
aux projets
31 Manager Soumettre les heures prestées pour la
facturation.
32 Manager Créer et d'envoyer des factures aux
clients.
33 Manager Consulter et d'imprimer les factures.
34 Manager Afficher et d'imprimer les rapports des
projets.
35 Employé Gérer mes tâches.
36 Employé Afficher le burndown chart
37 Employé Demander un congé.
38 Employé Afficher une liste de mes congés avec
leurs états.
39 Employé Pointer l'entré et la sortie.
40 Employé Créer les timesheets par tâche.
41 Employé Consulter mes présences/absences.
42 Employé Soumettre mes heures prestées
(timesheets) au responsable pour la
validation
43 Employé Afficher le rapport de mes tâches.
44 Employé Imprimer mon contrat.
Chaque ligne du Product backlog représente une User Story ou histoire
utilisateur. Les éléments du backlog sont classés par priorité ce qui permet de
définir l'ordre de réalisation. Très souvent les User Stories peuvent porter
également des numéros ID afin de les distinguer plus rapidement. Le backlog
est sous la responsabilité du Product Owner. Chacun peut contribuer à
collecter des éléments, mais c'est le Product Owner qui les accepte finalement
et c'est lui qui définit les priorités.
Tableau 6: Le Backlog du projet

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

soient stable. Elle peut aussi être définie à chaque sprint avec un planning basé
sur l'engagement de l'équipe.
Concernant la vélocité de mon équipe qui se compose de un membre,
j’ai pu réaliser 8 points pendant le premier Sprint. En partant de cette vélocité
et du total de points à réaliser (85 points), on peut déterminer le nombre de
sprints qui seront nécessaires pour terminer le projet (6 sprints).
4.1.4. Les tâches du Sprint Backlog
Un item peut prendre plusieurs jours avant d’être réalisé, chaque item du
sprint backlog doit donc être découpé suivant une granularité plus fine,
appelée tâche. Ce découpage permettra ainsi aux membres de l’équipe de
se les partager. Chaque tâche est chiffrée en heure/homme correspondant à
son temps de développement, idéalement une tâche ne doit pas dépasser un
jour/homme.
La figure 16 illustre le découpage d’une User Story de notre Product Backlog.
Nous pouvons voir que cette user story estimé à 2 points, soit 16
heures/homme de travail est alors découpé en 3 tâches : la tâche 3.1, 3.2, 3.3,
qui sont réalisable respectivement en 3, 5, et 2 heures/homme.
4.1.4. Planification des Releases
La réunion de planification des sprints (Sprint planning meeting), qu’on a
vue précédemment, est l’événement le plus important dans Scrum. Le but de
cette réunion est de préparer le planning de travail et d’identifier le backlog
des sprints.
Comme on a vu dans la section précédente, mon projet pourra contenir
6 sprints avec une vélocité de 8 points, dans ce contexte nous avons choisi de
développer trois releases, chaque release contient trois Sprints de tailles de
deux semaines.

4.2. Outils Scrum
4.2.1. Taskboard
Ce tableau représente les deux Releases planifiées, chacune de ces
Releases contient 3 Sprints de tailles de 10 points, chaque Sprint est représenté
par une date de début, une date de fine et un nombre de User Stories dont
chacune de ces User Stories est représentée par un numéro d’identification ID,
un nombre de points représentant la durée estimée pour la réaliser et un
numéro de priorité, ce qui permet de définir l'ordre de réalisation.
Le Taskboard est une table de 3 colonnes, dans la première on met
toutes fiches représentant les User Stories du Sprint courant. Les 2 trois autres
colonnes représentent les états par lequel chaque tâche doit passer, chaque
ligne représente un ensemble de tâche associée à une User Story ou dans
certains cas les bugs à corriger. Dans notre exemple, les tâches débutent dans
l’état To Do, lorsqu’un membre décide de réaliser une tâche, il l’a fait passer à
l’état In progress, une fois terminée il l’a fait passer à l’état Done et finalement
lorsque toutes les taches d’une même User Story sont terminées elle passe cette
User Story à l’état final Done.
Release 1 Release 2
Figure 9: Les releases du projet

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

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

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

Après avoir décrit dans le chapitre précédent l’ensemble des
fonctionnalités du système, je vais élaborer dans ce chapitre une étude
technique qui permettra de décrire l’aspect technique de la solution à réaliser.
1. Exigence du projet
Une architecture logicielle exprime un schéma d’organisation
structurelle fondamentale pour des systèmes logiciels. Il fournit un ensemble de
sous-systèmes prédéfinis, spécifie leur responsabilité, et inclut des règles et des
guides pour organiser les relations entre eux.
L’architecture logicielle du projet subit un certain nombre de forces, le choix
d’une architecture logiciel constitue un défi technologique. En effet il faut
définir les grands objectifs technique de la future architecture, c'est-à-dire de
bien prendre en compte l’ensemble des forces qui vont s’exercer sur le future
système ainsi que la puissance de chacune d’entre elles. Les objectifs
techniques de l’architecture doit assurer sont la fiabilité, la réutilisabilité, la
disponibilité et l’évolutivité.
1.1. Méthodologie de développement : La démarche
MVC
Modèle d'architecture qui cherche à séparer nettement les couches de
présentation (UI : User Interface), métier (BLL : Business Logic Layer) et d'accès
aux données (DAL : Data Access Layer). Le but étant d'avoir une dépendance
minimale entre les différentes couches de l'application, ainsi les modifications
effectuées sur n'importe quelle couche de l’application n'affectent pas les
autres couches.
• Modèle – Encapsule le cœur fonctionnel de l'application, le domaine
logique.

• Vue – les données sont envoyées, par le modèle, à la vue qui les présente à
l’utilisateur.
• Contrôleur – reçoit les données et les transmets au modèle ou à la vue.
Une telle architecture est communément appelée architecture 3-tier ou à 3
niveaux.
1.2. Pourquoi MVC
Une architecture est une sorte d'organisation qui permet de répartir des
fonctions sur un ensemble de ressources (et/ou d'organiser le boulot pour
construire la chose correspondante).
Si les possibilités de répartition +/- optimales des fonctions sur les ressources sont
limités, le nombre d'architectures le sera aussi. Ce qui ne signifie pas une
grande variabilité.
A la base d'une application multi-utilisateurs, vous avez des IHM et
une/des fonctions de persistance (base de donnée), si l'IHM est un client lourd,
à chaque mise à jour il faudra aller sur tous les postes clients... Si vous avez 1000
utilisateurs, vous ne le ferez pas deux fois: donc navigateur et on descend la
logique dans un serveur d'application, mais entre les deux, ce seront deux
Figure 12: Architecture MVC

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

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

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

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

- Environ 2 000 000 d’utilisateurs à travers le monde en grande majorité issus des
pays émergeants
3. Outils utilisés
3.1. Python
Python est un langage de programmation objet, multi-
paradigm et multiplateformes. Il favorise programmation
impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage
dynamique fort, d'une gestion automatique de la mémoire par ramasse-
Figure 18: Single server, multi-process
Figure 19: multi server, multi process

miettes et d'un système de gestion d'exceptions ; il est ainsi similaire
à Perl, Ruby, Scheme, Smalltalk et Tcl.
Le langage Python est placé sous une licence libre proche de la licence
BSD2 et fonctionne sur la plupart des plates-formes informatiques,
des supercalculateurs aux ordinateurs centraux, de Windows à Unix en passant
par GNU/Linux, Mac OS, ou encore Android, iOS, et aussi avec Java ou
encore .NET. Il est conçu pour optimiser la productivité des programmeurs en
offrant des outils de haut niveau et une syntaxe simple à utiliser.
Il est également apprécié par les pédagogues qui y trouvent un langage où la
syntaxe, clairement séparée des mécanismes de bas niveau, permet une
initiation aisée aux concepts de base de la programmation
3.2. QWEB
QWEB est le moteur de template principal utilisé par Odoo. Il est un template
XML moteur et utilisé principalement pour générer des fragments et des pages
HTML.
Les directives de modèle sont spécifiés comme des attributs XML avec le
préfixe t-, par exemple t-si pour conditionnels, avec des éléments et d'autres
attributs étant rendu directement.
3.3. HTML5-CSS3
HTML5 (HyperText Markup Language 5) est la dernière révision majeure
d'HTML (format de données conçu pour représenter les pages web). Cette
version est en développement en 2013. HTML5 spécifie deux syntaxes d'un
modèle abstrait défini en termes de DOM : HTML5 et XHTML5. Le langage
comprend également une couche application avec de nombreuses API, ainsi
qu'un algorithme afin de pouvoir traiter les documents à la syntaxe non
conforme. Le travail a été repris par le W3C en mars 2007 après avoir été lancé

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

Ce système est concurrent d'autres systèmes de gestion de base de
données, qu'ils soient libres MariaDB, MySQL et Firebird), ou propriétaires
Oracle, Sybase, DB2, Informix etMicrosoft SQL Server). Les projets libres Apache
et Linux, PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé
sur une communauté mondiale de développeurs et d'entreprises.
3.1. Outils de conception
Microsoft Visio (officiellement Microsoft Office Visio) est un logiciel de
diagrammes et de synoptique pour Windows qui fait partie de la suite
bureautique Microsoft Office mais se vend séparément. On peut ainsi créer des
diagrammes de Gantt, des réseaux de PERT ou encore des diagrammes IDEFO.
Dans Visio, les graphiques utilisés pour créer des diagrammes sont vectoriels.
Les versions Standard et Professionnel de l'édition 2007 partagent la
même interface, mais cette dernière permet de faire des diagrammes plus
avancés, grâce à des modèles supplémentaires. Cette version offre
également une fonctionnalité unique qui permet aux utilisateurs de relier
facilement leurs diagrammes à un grand nombre de sources de données et
d'afficher les informations recueillies graphiquement.
3.1.2. Outils de développement
a. Eclipse
Eclipse IDE est un environnement de développement intégré libre(le
terme Eclipse désigne également le projet correspondant, lancé par IBM)
extensible, universel et polyvalent, permettant potentiellement de créer des
projets de développement mettant en œuvre n'importe quel langage de
programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la
bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques
spécifiques, est également utilisé pour écrire des extensions.

b. Gitlab : Solution d’hébergement de projets Git
Git, outil de gestion de versions de code source, s’est répandu très
rapidement dans la communauté Open Source, d’autre part sa rapidité, sa
flexibilité et sa fiabilité. Les solutions d’hébergement en ligne de projets Git
connaissent un énorme succès, mais leur utilisation est bien souvent payante
pour l’hébergement de projets privés. GitLab est une solution gratuite et Open
Source pour l’hébergement de projets Git privés comparable aux géants tels
que GitHub et BitBucket et qui convient aux entreprises, Développé
initialement par Linus Torvalds en 2005 pour la gestion du kernel Linux. Depuis,
Git s’est rapidement répandu, surtout dans la communauté Open Source, de
par sa rapidité, flexibilité, fiabilité et sa nature distribuée, tous des aspects qui
le distinguent d’outils plus anciens tels que Subversion (SVN).
L’hébergeur Git le plus connu et le plus utilisé est GitHub, qui offre de
l’hébergement gratuit de projets publics, et propose une version payante pour
particuliers ou entreprises, pour des projets privés. Bitbucket d’Altassian se
distingue de GitHub en offrant des projets privés gratuits pour un nombre limité
de collaborateurs par projet. Enfin, ces hébergeurs disposent tous des services
payants de déploiement de serveurs Git privés en self-hosting auprès
d’entreprises. Fortement inspiré de GitHub, est entièrement Open Source et
s’adresse COMME solution gratuite d’hébergement de projets Git.
Avant de rentrer dans les détails de mise en œuvre de GitLab, passons
en revue les fonctionnalités offertes aux utilisateurs et administrateurs.
Premièrement, et surtout, GitLab propose une interface web complète
et épurée. Toute solution d’hébergement web de projets Git permet de
visualiser ses différents projets, l’état et l’évolution des branches et l’historique
du projet, chose qui peut également être faite avec un grand nombre d’outils
de visualisation de repositories Git locaux tel que Gitk. Les solutions
d’hébergement web apportent surtout une valeur ajoutée via les services
autour de Git, COMME pour le cas de GitLab :
La collaboration entre utilisateurs :

 La revue de code, allant de l’annotation d’un ensemble de commits
jusqu’à l’annotation de lignes de code individuelles dans un COMMIT
particulier.
 Le suivi de bugs et fonctionnalités dans un bugtracker.
 La définition de milestones d’évolution du projet.
 Un système de notification par mail et flux RSS.
 Un tableau de bord inter-projets pour ne rien rater.
L’administration de projets Git :
 Tout utilisateur dispose de droits de création de repositories, dans
son namespace personnel ou dans unnamespace de groupe, pour
rassembler des repositories liés et partagés entre plusieurs utilisateurs.
 Un repository dans un namespace personnel ou de groupe est
accessible aux utilisateurs suivant un système de permissions, bien plus
riche que celui de GitHub : none, guest,REPORTER, developer et master.
 La notion d’équipe facilite l’attribution de droits d’accès à une liste de
repositories avec un certain niveau de permission à un ensemble
d’utilisateurs.
c. Jira
JIRA est un système de suivi de bugs, un système de gestion des incidents,
et un système degestion de projets développé par Atlassian Software Systems.
4. Conclusion
On a commencé ce chapitre par la présentation des exigences du
projet et l’architecture logicielle de mon système. Après on a présenté
l’architecture de développement choisi ainsi que outils utilisés pour la
réalisation de ce projet, dans le chapitre suivant nous allons détailler les
différents releases du projet.

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

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

1.1.1. Backlog
Les user stories du premier sprint
User story Estimation
En tant que utilisateur, j'ai besoin de s'authentifier afin
d’accéder à l'application
1
En tant que utilisateur j'ai besoin de gérer mon profile 1
En tant que utilisateur j'ai besoin de consulter le Dashboard
selon mes permissions
1
En tant qu'administrateur j'ai besoin de gérer les permissions 1
En tant que manager j'ai besoin de gérer les projets 2
Table 1 : Backlog du sprint 1
Lors de la réunion du sprint planning on a discuté avec le Product Owner et
le Scrum Master, chacune des user stories.
 L’authentification : l’authentification de n’importe quel utilisateur du
system.
 Gestion du profile : Tout le monde peut gérer son profile (CRUD).
 Gestion de projets : Seulement le manager qui a le droit de gérer les
projets.
 Gestion des permissions : Le manager a le droit d’attribuer ou de
restreindre les droits des utilisateurs.
1.1.1. Conception
1.1.1.1. Choix formalisme UML
Vue le déploiement de l’application et l’extension future, une
modélisation objet apparait la plus adaptée, en effet l’objet a fait ses preuves
dans la réalisation d’application Web.
Pourquoi nous avons opté pour UML :
- UML est un langage formel et normalisé
o gain de précision
o gage de stabilité
o encourage l'utilisation d'outils

- UML est un support de communication performant
o Il cadre l'analyse.
o Il facilite la compréhension de représentations abstraites complexes.
o Son caractère polyvalent et sa souplesse en font un langage
universel.
Après avoir exprimé les spécifications fonctionnelles, nous allons traduire ces
besoins nous allons traduire ces besoins-là en des diagrammes fonctionnels
UML
1.1.1.2. Vue cas d’utilisation
a. Diagramme de cas d’utilisation
Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés
pour donner une vision statique et globale du comportement fonctionnel d'un
système logiciel. Ils sont utiles pour des présentations auprès de la direction ou
des acteurs d'un projet
Le diagramme de cas d’utilisation est composé des acteurs externes et
des cas d’utilisation :
Les acteurs : Ils sont des entités externes qui interagissent avec le système,
comme une personne humaine ou un robot.
Les cas d’utilisation : est une description des interactions qui vont permettre à
l'acteur d'atteindre son objectif en utilisant le système.
La solution qu’on va réaliser va être gérer par les responsables ressources
humaines le DRH et les chefs de projet qui sont aussi des administrateurs
système, et en fin il y a les utilisateurs, dans ce sprint existe 3 diagramme de cas
d’utilisation.

Figure 20 : Diagramme de cas d’utilisation d’un utilisateur – Sprint 1
L’utilisateur peut faire la gestion de son profile et consulter le DashBoard selon
ses permissions
Figure 21: Diagramme de cas d'utilisation du Manager – Sprint 1
Pour que le manager puisse gérer ses projets, il doit premièrement s’authentifier
Figure 22: Diagramme de cas d'utilisation de l’administrateur – Sprint 1
L’administrateur peut faire un cas d’utilisation qui est spécifique, c’est la gestion
des permissions
1.1.1.3. Vue séquentielle
Les diagrammes de séquences sont la représentation graphique des
interactions entre les acteurs et le système selon un ordre chronologique dans
la formulation UML.
Le diagramme de séquences permet de cacher les interactions d'objets dans
le cadre d'un scénario d'un Diagramme des cas d'utilisation. Dans un souci de
simplification, on représente l'acteur principal à gauche du diagramme, et les

acteurs secondaires éventuels à droite du système. Le but étant de décrire
comment se déroulent les actions entre les acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant
de visualiser l'enchaînement des actions dans le temps, et de spécifier la
naissance et la mort d'objets. Les périodes d'activité des objets sont
symbolisées par des rectangles, et ces objets dialoguent par le biais de
messages.
Apres la description des cas d’utilisation, nous allons élaborer le modèle
dynamique dans lequel nous allons décrire les scénarios de quelques cas
d’utilisations, les plus importants dans ce sprint, sous forme de diagrammes de
séquence.
Figure 23: Diagramme de séquence de la gestion des projets

Figure 24 : Diagramme de séquence du cas d'utilisation : gestion des permissions
Ce diagramme montre la gestion des droits par l’administrateur
1.1.1.4. Diagramme de classes
Le diagramme de classes est considéré comme le plus important de la
modélisation orientée objet, il est le seul obligatoire lors d'une telle
modélisation.

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

Figure 25: Diagramme de classes sprint1
Le premier sprint a un diagramme de classes qui se compose de 7 classes :
User, Administrateur qui hérite de la classe user, et il y a aussi notre classe
project_scrum qui héritent de la classe project du module standard de gestion
du projet.
 Un Manager peut être responsable de plusieurs projets.
 Un projet peut avoir plusieurs utilisateurs, et un utilisateur peut être
membre dans plusieurs projets.
Au niveau de la base de données on aura une 3ème table qui va lier les
tables candidat et sujet de stage.
 La classe Project est liée à la classe Sprint qui sera présenté dans le
prochain sprint (on en parlera dans le prochain sprint).
1.1.2. Réalisation
Dans cette partie on va parler des différentes fonctionnalités réalisées
pendant ce sprint.

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

1.2. Sprint 2
En partant sur le même principe que le sprint précédent, nous
commençons par les spécifications fonctionnelles. Ensuite la conception et
finalement les tests cette fois ci ne sont pas disponibles vu que c’est la même
procédure qui se répète. Le tableau résume donc le backlog de notre premier
sprint.
1.2.1. Backlog
Les user stories du premier sprint :
En tant que manager j'ai besoin de gérer les sprints 3
En tant que manager j'ai besoin de gérer les user stories 2
En tant que manager j'ai besoin de définir la vitesse de l'équipe
(Velocity)
2
En tant que manager j'ai besoin de gérer les taches 2
Table 7 : Backlog du sprint 1.
Comme on l’a déjà mentionné, lors de la réunion du release planning on a
discuté avec le product Owner et le scrum master chacune des user stories ci-
dessus au niveau fonctionnelles pour éclaircir nos vue et les objectifs à
atteindre.
Ce sprint se compose de quatre histoires d’utilisateur ordonné par priorité :
 Gestion des Sprints : Dans chaque projet le Manager peut gérer les
sprints associé à ce projet.
 Gestion des histoires : Le manager a le droit de créer, modifier, ou
supprimer une histoire, lors de la création d’une user story le manager
doit spécifier le projet et le Sprint, et l’utilisateur peut modifier l’état de
l’histoire en la glisser dans le taskboar vers le nouveau état.
 Gestion des taches : Les taches sont gérer par les développeurs et les
managers et ils peuvent modifier l’état de la tâche en glissant la tache
vers le nouvel état (« à faire », « en cours », « déjà fait »).

 Définition de la vélocity : dans chaque projet l’administrateur a le droit
de définir la vélocity de l’équipe associé à ce projet
1.2.2. Conception
1.2.2.1. Vue cas d’utilisation : Diagramme de cas d’utilisation
Toutes les fonctions qui se trouvent dans ce sprint sont relié à
l’administrateur où il peut définir la vélocité de l’équipe, ensuite il peut entrer
dans chaque sprint pour gérer les histoires, et enfin faire la gestion des taches.
Figure 27 : Diagramme de cas d’utilisation du Manager - Sprint 2
Ce Sprint contient seulement les cas d’utilisation du Scrum Master ou Product
Owner, comme il montre la capture au-dessus
À ce niveau, nous devons présentés le diagramme de séquence des
différents cas d’utilisation déjà détaillés dans la section précédente.

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

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

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

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

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

1.3. Sprint 3
Le sprint 3, est le dernier sprint du release, avait comme but le
développement des dernières fonctionnalités nécessaires à la livraison d’un
tout premier produit prêt à être utilisé.
En suivant la même méthode adoptée pour les Sprints précédents, nous
allons détailler les différentes phases de développement.
1.3.1. Backlog
Les user stories du troisième Sprint :
En tant que manager j'ai besoin de gérer les taches 3
En tant que manager j'ai besoin d’affecter les taches aux
membres d’équipe
1
En tant que manager j'ai besoin d’afficher le burndown chart
du sprint
3
En tant que manager j'ai besoin d’afficher et imprimer le
backlog du projet
2
En tant qu’employé j'ai besoin de gérer le taskBoard 3
 Gestion des Taches : Dans chaque projet le Manager et le
développeur peuvent gérer les taches associées au sprint ouvert du
projet.
 Affectation des taches : Le manager a le droit de répartir les taches sur
les membres de chaque projet.
 BurndownChart : Le manager peut accéder à chaque Sprint et
imprimer le Burndown Chart pour visualiser l’avancement, le
déroulement de chaque Sprint durant tout le projet.
 Backlog du projet : Pour chaque projet le Manager peut imprimer le
Backlog du projet

1.3.2. Conception
1.3.2.1. Vue cas d’utilisation : Diagramme de cas d’utilisation
Figure 33 : Diagramme de cas d’utilisation du Manager
La plupart des fonctions qui se trouvent dans ce sprint sont relié à
l’administrateur où il peut définir la vélocité de l’équipe, ensuite il peut entrer
dans chaque sprint pour gérer les histoires, et enfin faire la gestion des taches.
Après l’authentification le développeur peut Gérer les taches qui
appartiennent aux histoires liés au projet.
Dans cette partie, on va détailler quelques cas d’utilisation en présentant
quelques diagrammes de séquences.
Figure 34 : Diagramme de cas d’utilisation du Développeur

Figure 35: Diagramme de séquence de la gestion des Taches
Après l’authentification Le manager peut accéder aux Sprint liés à ses
projets, ensuite accèder aux histoires, et enfin accéder au taskboard de
chaque histoire où il peut ajouter, modifier, supprimer, consulter, changer l’état
en glissant la tache vers une autre colonne.

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

Figure 37: La gestion des taches
L’utilisateur doit arriver au taskboard de chaque histoire pour faire la gestion
de ses taches.
1.3.3.2. L’affectation des taches
Figure 38: L’ajout des membres de l’équipe
Premièrement Le manager doit ajouter les membres de l’équipe au projet,
comme il est expliqué sur la capture au-dessus

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

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

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

2. Deuxième Release
Notre deuxième release est constitué de 3 sprints, c’est la deuxième version
livrable du projet. Nous allons analyser, détailler et tester les différentes phases
du release.
2.1. Sprint 4
Comme les sprints du premier release nous avons défini le but de ce Sprint qui
est dans un premier temps la gestion des congés, qui sera une configuration
du module standard de gestion de congés intégré dans la plateforme Odoo.
2.1.1. Backlog
Les user stories du quatrième Sprint :
En tant que manager, j'ai besoin de gérer les congés 1
En tant que manager, j’ai besoin de définir les soldes congés
pour chaque employé et les journées de récupération
2
En tant que manager, j'ai besoin de gérer les demandes de
congés
1
En tant que manager, j'ai besoin d’approuver ou refuser les
demandes de congés
1
En tant qu’employé j'ai besoin de créer les timesheets par
tache
2
En tant que manager j'ai besoin d’afficher les résumés de
congés
1
Ce sprint se compose de six histoires d’utilisateur ordonné par priorité :
 Gestion des congés : Le manager RH peut gérer les congés en lui
affichant un calendrier qui lui facilite la tâche.
 Les soldes de congés : Le manager RH a le droit de définir le nombre
légal de jours pour ses subordonnées.

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

Après l’authentification l’employé peut créer les timesheets qu’il a travaillés et
qui appartiennent à une tache d’un de ses projets.
Dans cette partie, on va discuter quelques cas d’utilisation en présentant
quelques diagrammes de séquences.
Figure 46: Diagramme de séquence de la gestion des Taches
Après l’authentification Le développeur peut accéder aux Sprint liés à
ses projets, ensuite accéder aux histoires, et enfin vers le Taskboard où il peut
choisir de modifier une tâche pour qu’il puisse entrer ses heures de travails.

Figure 47: Diagramme de classes sprint 4 : Gestion de congés
Ce diagramme représente la base de données du module standard d’Odoo
de gestion de congés.
2.1.3. Réalisation
Après l’étape de la conception et comme les chapitres précédents nous
allons entamer la partie réalisation du sprint, nous allons donner une idée sur
les différentes interfaces produites pendant le sprint.
2.1.3.1. La gestion des congés
Nous avons créés une interface qui soit lisible est très clair pour que le
manager peut gérer les congés sans difficultés

Figure 48: Gestion des congés
Dans le menu de gestion de cangés le Manager RH une calendrier
s’affiche en visualisant les demandes de congés avec leurs durées, en plus
filtrés employé
2.1.3.2. La validation des demandes de congés
Figure 49: La validation des demandes de congés
Le manager doit valider les congés de ses subordonnées pour qu’ils
soient affichés sur le calendrier.

2.1.3.3. La création des timesheets
Figure 50: L’inscription
Au niveau de la tache le développeur peut créer ses heures prestées en
précisant la durée, et il sera automatiquement le responsable.
2.1.4. Conclusion
Dans ce chapitre nous avons analysé, conçu, réalisé et testé le
quatrième sprint du deuxième release du projet qui a ajouté des fonctionnalités
à l’application et affiné d’autres. Il est temps de passer au cinquième et avant
dernier sprint

2.2. Sprint 5
Le sprint 5, avait comme but le développement des fonctionnalités
nécessaires à la livraison d’un produit prêt à être utilisé.
En suivant la même architecture des autres Sprints précédents, nous
allons détailler les différentes phases de développement.
2.2.1. Backlog
Les user stories du cinquième Sprint :
En tant qu’administrateur, j’ai besoin de gérer les templates du
contrat employé.
0.5
En tant qu’administrateur, j'ai besoin de gérer les templates du
contrat client
0.5
En tant que manager, j'ai besoin de suivre les
présences/absences
1
En tant que manager, j'ai besoin de gérer les pointages
(entrées/sorties)
2
En tant que manager, j'ai besoin de gérer les clients 0.5
En tant que manager, j'ai besoin de gérer les contrats clients 1
En tant que manager, j'ai besoin de gérer les contrats des
employés
0.5
En tant qu’employé, j'ai besoin de pointer l’entrée et la sortie 1
En tant qu’employé, j'ai besoin de consulter mes
présences/absences
0.5
En tant qu’employé, j'ai besoin d’imprimer mon contrat 1
 Les templates des contrats clients : L’administrateur a le droit de définir
les contrats des clients pour quel soit utilisé lors de la réduction du
contrat pour gagner du temps.

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

2.2.2. Conception
Ce diagramme montre un ensemble de cas d’utilisation qui sont confiés au
manager ressources humaines (Gestion des contrats, des pointages, des
clients, …)
Figure 64 : Diagramme de cas d’utilisation de l’administrateur – Sprint 5
Figure 51 : Diagramme de cas d’utilisation du Développeur – Sprint 5

Figure 64 : Diagramme de cas d’utilisation de l’employé – Sprint 5
Pour qu’un employé puisse imprimer son contrat, consulter ses
présences, pointer son entrée ou sa sortie il doit premièrement s’authentifier
Figure 52: Diagramme de séquence du pointage de l’employé – Sprint 5

Cette figure au-dessus on trouve le cas du pointage par un employé lors
de son entrée ou lors de sa sortie
2.2.3. Réalisation
Après la conception et comme les chapitres précédents on va
attaquer la partie réalisation en donnant une idée sur l’interface d’utilisateur.
2.2.3.1. La gestion du pointage de l’entré et de la sortie
Figure 53: Le pointage entrée/sortie
L’employé peut gérer ses pointages, en filtrant les pointages du mois
courant, de la semaine courante, et d’aujourd’hui, mais un manager doit avoir
la possibilité de gérer les pointages de toutes ses subordonnées
VI.2.2.3.2. La gestion des Templates des contrats clients

Figure 54: Les templates des contrats clients
Lors de la création du contrat, Le manager peut choisir son modèle de
contrat ou bien créer un nouveau modèle, en précisant les variables à
inclure.
2.2.4. Conclusion
Dans cette partie, j’ai détaillé les différentes étapes parcourue dans le
cinquième Sprint pour arriver à ce résultat, maintenant il est temps pour
passer au dernier Sprint.

2.3. Sprint 6
Le sprint 6, est le dernier sprint du projet, avait comme but le
développement des dernières fonctionnalités nécessaires à la livraison de la
dernière version du projet.
En partant évidement par le même principe des sprints précédents,
nous allons détailler les différentes phases de développement.
2.3.1. Backlog
Les user stories du sixième Sprint :
En tant que manager, j’ai besoin de suivre l’évolution des
heures prestées (timesheets) sur une tache ou projet
1
En tant que manager j'ai besoin de valider ou refuser les heures
prestées
1
En tant que manager j'ai besoin de soumettre les heures
prestées pour la facturation
1
En tant que manager j'ai besoin de créer et d’envoyer des
factures aux clients
1
En tant que manager, j’ai besoin de consulter et d’imprimer les
factures
1
En tant qu’employé, j’ai besoin de soumettre mes heures
prestées (timesheets) au responsable pour la validation
1
 Suivi des heures prestées : Dans chaque projet le Manager peut suivre
l’avance de chaque tâche par rapport à ses heures prestées.
 Validation des timesheets : Le manager a le droit de refuser ou de
valider les heures prestées, et les soumettre à la facturation.
 Les factures : Le manager peut imprimer et envoyer les factures aux
clients, après la validation de ces derniers.

2.3.2. Conception
Ce diagramme au-dessus montre les différents cas d’utilisation du
sixième Sprint et qui sont destinés pour un Manager RH
s
Cette figure représente les fonctions du dernier incrément et qui sont
destinés pour l’employé
Figure 56 : Diagramme de cas d’utilisation du Développeur

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

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

2.3.3.2. Suivi des heures prestées
Figure 60: Les heures prestées d’une tache
Cette capture montre le fait de visualiser l’avancement au niveau de
chaque tâche en comparant son estimation avec le total de ses heures
prestées
2.3.4. Conclusion
Dans ce chapitre nous avons analysé, conçu, réalisé et testé le deuxième
release du projet, il est alors maintenant potentiellement livrable.

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

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

Rapport de projet odoo

Contenu connexe

Tendances

En vedette

Similaire à Rapport de projet odoo

Rapport de projet odoo