107
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

Rapport de projet odoo

Embed Size (px)

Citation preview

Page 1: 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

Page 2: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

Page 3: Rapport de projet odoo

3 É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

Page 4: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 5: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 6: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 7: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 8: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 9: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 10: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 11: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 12: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 13: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 14: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 15: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 16: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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é

Page 17: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 Wakanda Figure 3: Logo du produit 4D v13 Figure 2: Logo de 4D logiciels

Page 18: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 »

Page 19: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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)

Page 20: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

Page 21: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 22: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 23: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 24: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 25: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 26: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 27: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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).

Page 28: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 29: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 30: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 31: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 à

Page 32: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

• 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é

• pour des projets

à long terme

dont les

financements

peuvent varier

• les utilisateurs ne

définissent pas

clairement leurs

besoins

• la spécification

des besoins est

complexe

Page 33: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

• pour des projets

à risque au

moins

moyennement

élevé

• pour des projets

à long terme

dont les

financements

peuvent varier

• les utilisateurs ne

définissent pas

clairement leurs

besoins

Page 34: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

• 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

Page 35: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 36: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 37: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 38: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 39: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 40: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 41: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 42: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 43: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 44: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 45: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 46: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 47: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 48: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 49: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 50: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

Chapitre 3: Technologies utilisés

I- Exigence du projet

II- Choix de la technologie

III- Outils utilisés

IV- Conclusion

Page 51: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 52: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

• 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

Page 53: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 54: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 55: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 56: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

- 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

Page 57: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

- 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

Page 58: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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é

Page 59: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 60: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 61: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

Page 62: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 63: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

Chapitre 4: Les releases du projet scrum

I- Release 1

II- Release 2

Page 64: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 …

Page 65: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 66: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 67: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 68: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 69: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 70: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 71: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 72: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 73: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

User story Estimation

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 »).

Page 74: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

1.2.2.2. Vue séquentielle

À 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.

Page 75: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 76: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 77: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

1.2.2.2. Diagramme de classes

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 …,

Page 78: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 79: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 80: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

User story Estimation

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

Table 8 : Backlog du sprint 3.

Lors de la réunion du sprint planning on a discuté avec le Product Owner et

le Scrum Master, chacune des user stories.

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

Page 81: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

1.3.2.2. Vue séquentielle

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

Page 82: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 83: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

1.3.2.3. Diagramme de classes

Figure 36: Diagramme de classes sprint3

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

Page 84: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 85: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

Figure 39 : L’affectation de la tache

1.3.3.3. L’affichage du BurndownChart du Sprint

Figure 40 : L’affichage du BurndownChart

Page 86: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 87: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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).

Page 88: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

User story Estimation

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

Table 9 : Backlog du sprint 3.

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.

Page 89: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

2.1.2.1. Vue cas d’utilisation

Dans cette partie du chapitre on va parler et détailler les options de la partie

de gestion de congés.

Figure 44 : Diagramme de cas d’utilisation du Manager

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é

Page 90: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

2.1.2.2. Vue séquentielle

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.

Page 91: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

2.1.2.3. Diagramme de classes

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

Page 92: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 93: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 94: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

User story Estimation

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

Table 10 : Backlog du sprint 5.

Lors de la réunion du sprint planning on a discuté avec le Product Owner et

le Scrum Master, chacune des user stories.

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.

Page 95: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 96: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

2.2.2. Conception

2.2.2.1. Vue cas d’utilisation

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

Page 97: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

2.2.2.2. Vue séquentielle

Figure 52: Diagramme de séquence du pointage de l’employé – Sprint 5

Page 98: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 99: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 100: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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 :

User story Estimation

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

Table 11 : Backlog du sprint 6.

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.

Page 101: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

2.3.2. Conception

2.3.2.1. Vue cas d’utilisation

Figure 55 : Diagramme de cas d’utilisation du Manager

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

Page 102: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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

Page 103: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

2.3.2.3. Diagramme de classes

Figure 58: Diagramme de classes sprint6

Page 104: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 105: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 106: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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.

Page 107: Rapport de projet odoo

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

Gestion de projets et gestion des ressources humaines

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]