rapportdestagepfe-150814170320-lva1-app6891.pdf

8/17/2019 rapportdestagepfe-150814170320-lva1-app6891.pdf

1/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 lagestion des projets, gestion de ressources

humaines Sous la plateforme Odoo


2/107

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

Gestion de projets et gestion des ressources humaines


3/107



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’ENS 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’av iez offert, je

vous dis MERCI

Au personnel adm inistratif 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


4/107



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 tr avail, 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.


5/107



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 0 5 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 collabore r 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.


6/107



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


7/107


8/107


9/107



Liste des figuresFigure 1: Logo du produit 4D v13 ......................................................................................... 17

Figure 2: Logo de 4D logiciels............................................................................................... 17Figure 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’entrepr ise « 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 ................................................................................. 57Figure 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

http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645504http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645505http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645506http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645507http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645508http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645508http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645509http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645509http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645515http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645516http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645517http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645518http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645519http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645520http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645521http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645522http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645523http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645525http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645526http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645527http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645528http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645528http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645527http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645526http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645525http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645523http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645522http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645521http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645520http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645519http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645518http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645517http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645516http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645515http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645509http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645508http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645507http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645506http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645505http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645504


10/107



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é ............................................... 89Figure 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

http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645549http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645549http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645560http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645560http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645566http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645566http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645573http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645573http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645573http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645566http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645560http://c/Users/ayoub/Desktop/Rapport%20de%20stage%20PFE.docx%23_Toc421645549


11/107



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


12/107



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


13/107



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

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_Gestion_de_Contenuhttp://fr.wikipedia.org/wiki/Syst%C3%A8me_de_Gestion_de_Contenu


14/107



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.


15/107



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


16/107



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

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é


17/107



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éveloppeursde créer à la fois des applications autonomes, client-serveur, ainsi que des

applications orientées Services (SOA) et Web sans aucune modification de

code. Plus récemment, « 4D » a créé la première plateforme de

développement « end-to-end » JavaScript permettant de créer des

applications professionnelles avec la gamme de produits «Wakanda».

La philosophie de « 4D » est la suivante : simplifier ce qui était auparavant

complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les

niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession

faible.

4D compte plus de huit filiales à l’international et de nombreux

distributeurs et représentants locaux dont « 4D Logiciels Maroc » fait partie. Les

métiers présents à « 4D Logiciels Maroc » sont similaires voir identique à ceux de

la filiale en France, et ce, allant du Support Technique et Développement

jusqu’au Contrôle Qualité pour les deux produits « Wakanda » et « 4D ».

La philosophie de 4D est la suivante : simplifier ce qui était auparavant

complexe, avec la vitesse et la puissance nécessaires pour rivaliser à tous les

niveaux, tout en offrant une valeur ajoutée inégalée et un coût de possession

faible. 4D offre également des fonctionnalités basées sur les nouvelles

Figure 1: Logo du produit WakandaFigure 3: Logo du produit 4D v13 Figure 2: Logo de 4D logiciels


18/107


19/107



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 decré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 à desapplications 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)

http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_Gestion_de_Contenuhttp://fr.wikipedia.org/wiki/Commerce_%C3%A9lectroniquehttp://fr.wikipedia.org/wiki/Point_de_ventehttp://fr.wikipedia.org/wiki/Point_de_ventehttp://fr.wikipedia.org/wiki/Commerce_%C3%A9lectroniquehttp://fr.wikipedia.org/wiki/Syst%C3%A8me_de_Gestion_de_Contenu


20/107



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 :


21/107



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

http://fr.wikipedia.org/wiki/SaaShttp://fr.wikipedia.org/wiki/SaaS


22/107



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’e xistant

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éa lisation 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


23/107



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 disper sé 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 plateformeOdoo

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


24/107



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.


25/107



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


26/107



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 pr ojetpourra 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


27/107



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


28/107



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


29/107



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 laméthode Scrum.


30/107



Chapitre 2 : La méthode Scrum

I- Comparaison des processus dedéveloppement

II- Choix du processus de

développementIII- La méthode ScrumIV- Pilotage du projet avec ScrumV- Conclusion


31/107



1. Comparaison des processus de développementLe 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, pourpouvoir 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 seretrouver 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’implantationd’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 à


32/107



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

moinsmoyennement

élevé


à long terme

dont les

financements

peuvent varier

• les utilisateurs ne

définissent pas

clairement leurs

besoins

• la spécification

des besoins est

complexe


33/107



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 duprocessus

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


à long terme

dont les

financements

peuvent varier

• les utilisateurs ne

définissent pas

clairement leurs

besoins


34/107



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

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érentesinterfaces 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 denouvelles

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


35/107



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 nedeviennent

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é sorteque 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 enessayant

d'attirer et de

maintenir


36/107



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 lesnormes

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

http://patjo82.over-blog.com/article-etude-comparee-des-differents-cycles-de-vie-de-logiciels-111005786.htmlhttp://patjo82.over-blog.com/article-etude-comparee-des-differents-cycles-de-vie-de-logiciels-111005786.htmlhttp://patjo82.over-blog.com/article-etude-comparee-des-differents-cycles-de-vie-de-logiciels-111005786.htmlhttp://patjo82.over-blog.com/article-etude-comparee-des-differents-cycles-de-vie-de-logiciels-111005786.htmlhttp://patjo82.over-blog.com/article-etude-comparee-des-differents-cycles-de-vie-de-logiciels-111005786.html


37/107



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

seulementProduit 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


38/107



Projet

Probabilité de

Succès

Faible Moyen à faible Moyen Élevé

Tableau 4: Comparaison des méthodologies de développement [Sutherland]

3. La méthode ScrumComme 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 agileDepuis 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 à unimposant 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.


39/107


40/107



4. Pilotage du projet avec ScrumCommenç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 ScrumLa 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 à 4semaines 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 gagnerbeaucoup 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.


41/107



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 r essources, un intermédiaire et non pas

un dirigeant.

ProductOwner

- 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


42/107



4.1.2. Les ÉvénementsToutes 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 permetaux 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


43/107



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.


44/107



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


45/107



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


46/107



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 BacklogUn 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 ReleasesLa 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 trava il 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.


47/107



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


48/107



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


49/107



5. ConclusionDans 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 lesoutils et les langages de conception et de développement que nous avons

utilisés durant la réalisation du système.


50/107



Chapitre 3: Technologies utilisés

I- Exigence du projet

II-

Choix de la technologieIII- Outils utilisés

IV- Conclusion


51/107



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 projetUne 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èsaux 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.


52/107



• 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 MVCUne 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 lalogique dans un serveur d'application, mais entre les deux, ce seront deux

Figure 12: Architecture MVC


53/107



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 derebaptiser 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 technologie2.1. Etude comparative entre les ERP existant sur lemarché

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


54/107



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


55/107



2.2. La plateforme OdooOdoo 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, dela 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


56/107



- 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

Documents

rapportdestagepfe-150814170320-lva1-app6891.pdf